52 篇博文 含有标签「fine-tuning」

你的团队花了三个迭代周期标注了5万条领域样本。你在前沿模型上运行了LoRA微调。评估指标提升了。然后一位同事稍微改变了提示词的措辞，模型又回到了你以为已经抑制的行为。这不是数据集问题——这就是预训练的阴影。

实践者不断重新发现的核心洞察是：微调教会模型如何在新语境中说话，但无法改写模型根本知识或倾向。在预训练期间编码的行为、偏见和事实先验是一个引力场——微调只能在其周围轨道运行，很难真正逃脱。

大多数运行持续微调的团队都以同样的方式发现了污染问题：每周评估指标持续提升，团队欢欣鼓舞，然后某个用户反馈模型"变差了"。一旦深入排查，你才意识到你的评估基准已经悄悄地泄漏到训练数据中好几个月了。每一个看起来像能力提升的指标，其实不过是记忆。

数字比直觉更糟糕。LLaMA 2 的 MMLU 样本中有超过 16% 被污染——其中 11% 属于严重污染（超过 80% 的词元重叠）。GPT-2 在被污染的基准上比干净基准的得分高出 15 个百分点。这不是边缘案例。在持续微调循环中，污染是默认结果，除非你从架构层面明确加以防范。

一个团队在路线优化任务上测试 Gemini 3 Flash，零样本准确率达 93%。他们开始添加示例，性能一路攀升——但在添加到八个示例时，准确率骤降至 30%。这不是噪声，而是少样本饱和曲线的猛烈反噬。这是大多数工程师只有在部署了一个四个示例时看起来正常、十二个示例时却出现问题的提示之后才会发现的故障模式。

"更多示例严格意味着更好"的直觉是错的。跨 12 个 LLM 和数十种任务类型的数据显示了三种截然不同的失败模式：稳定平台期（收益趋于平缓）、峰值回归（收益先升后崩）和选择诱导崩溃（更换示例检索策略后收益蒸发）。理解自己处于哪种模式，会改变你构建提示的方式、何时放弃少样本方案，以及是否应该转向微调。

微调模型上线六个月后，监管机构问道："哪些训练样本来自已撤回同意的用户？"你翻开一张电子表格，搜遍 Slack 归档，最终靠标注批次邮件和一份自第一个冲刺后就未更新的 README 来重建历史。这是常态，而非例外。对 44 个主要指令微调数据集的审计发现，超过 70% 的许可证标记为"未指定"，许可证类别实际应用的错误率超过 50%。溯源问题是结构性的，而且总在你最承受不起的时候爆发。

本文讲的是在需要之前就建立微调数据溯源注册表——包括模式设计、驱动需求的审计场景，以及使其可操作而不变成额外负担的生产模式。

大多数决定微调模型的团队在写下第一行训练代码之前，都会花上几周时间争论该使用哪种方法。这种争论很少触及核心问题。真正的问题不是 “SFT 还是 DPO？”，而是 “我试图缩小什么样的差距？”

有监督微调（SFT）、人类反馈强化学习（RLHF）和直接偏好优化（DPO）并不是解决同一个问题的竞争性方案。每种方法针对的是不同的失败模式。在 SFT 足以解决问题时选择 RLHF 会浪费数月时间。而当问题实际上是偏好不匹配时选择 SFT，则会产生一个表达流利但在生产环境中暴露问题之前很难察觉到错误模型。

这篇文章提供了一个决策框架。它将每种方法映射到其解决的具体问题上，解释了哪些信号预示着哪种方法将占主导地位，并提供了一套诊断方法论，帮助你在开始训练之前识别出实际存在的差距。

每一项微调工作最终都会达成同样的直觉：更好的数据意味着更好的模型，而更好的数据意味着更高质量的样本。因此，团队会构建复杂的标注流水线，以过滤掉平庸的输出，只保留金标准回复，并基于让他们引以为傲的数据集进行训练。然而，由此产生的模型在那些最初推动项目启动的具体用例中表现不佳。这种失败如此普遍，以至于值得拥有一个专属名称：课程陷阱（curriculum trap）。

这个陷阱在于 —— 仅策划你最好、最自信、最权威的输出并不能教会模型变得更好。它教会模型的是无论是否合理都要表现出自信。你创造出的东西在演示中看起来令人印象深刻，但在生产环境中却漏洞百出，因为生产环境充满了你的策划过程系统性排除掉的混乱边缘情况。

对语言模型进行微调能给你带来竞争优势——直到提供商在你的适配器之下更新了基础模型。此时，两种情况之一会发生：你的服务因形状不匹配错误而崩溃，或者——更危险的是——它开始静默输出降级结果，而你的监控系统毫无异常。大多数团队发现第二种情况，往往是在用户投诉"AI 变蠢了"之后。

这就是适配器兼容性悬崖。你在模型版本 N 上训练了一个 LoRA 适配器，提供商发布了版本 N+1，你的适配器现在运行在一个从未为之设计的基础上，且没有任何迁移路径。

用模型自身的输出训练模型，再用该模型的输出训练下一个模型，三代之内你就构建了一台逐渐变笨的机器。这就是模型崩溃——一个退化过程，其中每一代合成训练数据都会缩窄分布，直到模型遗忘罕见但重要的长尾模式。Nature 上的一项里程碑式研究证实了从业者的经验观察：即使微小比例的合成数据污染（低至千分之一的样本）也会引发词汇、句法和语义多样性的可测量退化。

然而合成数据并非可选项。真实世界的标注数据昂贵且在专业领域稀缺，在前沿模型所需的规模下日益枯竭。2025-2026 年成功交付微调模型的团队并非在回避合成数据——他们正在设计管道架构以确保生成过程不会崩溃。一个高效管道与一个自我中毒管道之间的区别在于多样性保持、验证循环以及知道何时该停下来。

一家金融科技团队花了三个月时间，根据其内部合规文档（数千份监管 PDF、政策更新和程序指南）对模型进行了微调。结果差强人意。模型仍然会对具体的规则编号产生幻觉。它忘记了最近的政策变化。而唯一真正重要的指标（即顾问是否足够信任它的答案从而停止反复核对）几乎没有变化。两周后，另一个团队在同样的文档语料库上构建了一个 RAG 流水线。顾问们在一周内就开始信任它了。

微调团队并没有犯技术错误。他们犯了一个定义性错误：他们试图用一种行为修改工具来解决知识检索问题。

大多数工程师都低估了微调成本，低估程度达三到五倍。训练运行只是账单中最小的一部分。数据整理、实验失败、部署基础设施以及持续的模型维护才是预算真正的去向。跳过这类计算的团队往往会在投入微调项目数月后才意识到，一个设计良好的 few-shot 示例提示词本可以在一周内解决问题。

本篇文章将深入探讨完整的经济账——微调在整个生命周期中的实际成本、LoRA 和 PEFT 何时能让这笔账划算，以及一个基于真实生产数据在微调和提示词工程之间进行选择的决策框架。

你使用 GPT-4 生成了 50,000 个合成的指令遵循示例，在这些示例上微调了一个较小的模型并将其部署，结果看起来非常棒。六个月后，你的团队重复了这一过程——只不过这次为了节省成本，你使用微调后的模型来生成示例。第二个模型的评估结果略低，但在噪声范围内。你以同样的方式微调了下一个版本。到第四次迭代时，你的模型输出呈现出一种奇怪的同质化。用户反馈它听起来像机器人。它在处理任何不符合狭窄模板的内容时都显得很吃力。你最强大的微调模型已经变成了最糟糕的一个。

这就是模型崩溃（model collapse）——当大语言模型（LLM）使用其他 LLM 生成的数据进行训练时，会发生渐进式的、自我强化的退化。这并非理论上的风险。它是一种有据可查的故障模式，具有可衡量的机制，并且越来越有可能影响那些在没有仔细思考反馈动态的情况下就将合成数据生成常态化的团队。

大多数构建 LLM 产品的工程团队都遵循相同的路径：提示基础模型，遇到性能瓶颈，然后立即将微调作为解决方案。这种本能反应往往是错误的。

微调是一个强大的工具。它可以释放真实的性能提升，在大规模应用中降低推理成本，并让你对模型行为进行精确控制。但它也带来了隐性成本——在数据、时间、基础设施和持续维护方面——团队通常会系统性地低估这些成本。在许多情况下，提示工程或检索增强（RAG）本可以让他们更快、更便宜地达成目标。

本文为你提供了一个具体的框架，告诉你每种方法在何时胜出，其依据是最近的基准测试和生产经验。