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

有数据时，微调模型很容易。残酷之处在于产品诞生之前的那个时刻：你需要个性化来吸引用户，但又需要用户才能积累个性化数据。大多数团队要么完全跳过微调（"以后再加"），要么花数周手工收集标注样本。两种方式都行不通。前者产出一个用户一眼就能看穿的通用模型，后者慢到等你有了数据，任务早已演变。

合成种子数据能解决这个问题——但前提是你必须清楚它在哪里会失效。

大多数尝试使用 RLHF 微调语言模型的团队在开始之前就放弃了。典型案例是 OpenAI 的 InstructGPT：33,000 个偏好对、13,000 个有监督演示、一个专门的外包团队，以及一个需要数周时间才能稳定的强化学习流水线。如果这就是门槛，那么大多数产品团队根本玩不起这个游戏。

他们错了。现在的门槛已经没那么高了。2024–2025 年的研究共识已经悄然改变：数据质量胜过数据量，DPO 完全取代了 RL 基础设施，而最有价值的偏好信号其实已经流经你的产品，只是未被记录。看起来是研究团队的问题，实际上是埋点（instrumentation）问题。

你的模型是基于去年的数据训练的。它在两个月前进行了内部评估，并在一个月后正式发布。当你得知用户遇到故障时，你已经落后于模型运行所需的现实世界六个月了。这种差距并非部署问题，而是反馈循环的问题。大多数团队不仅没有闭合这个循环，甚至根本没有对其进行衡量。

当模型表现不佳时，本能反应往往是归咎于模型架构或训练数据。但更深层次的问题通常在于反馈系统的延迟。从用户经历故障到该故障影响你的模型，这中间需要多长时间？大多数团队如果说实话，其实并不知情。行业分析表明，如果模型在六个月或更长时间内没有获得针对性更新，其在面对新数据分布时的错误率会上升 35%。原因并非模型本身在衰减——而是世界在前行，而模型却停滞不前。

这条流水线在纸面上看起来很合理：你有一个目标任务，没有人工标注样本，但有一个能力强大的大模型可用。于是你用该模型生成标签，再用这些标签微调一个更小的模型。发布，重复。

没有人足够重视的问题是：当你的标注模型和目标模型在同一批互联网数据上训练时会发生什么？而如今，它们越来越多地确实如此。

大多数构建 AI 功能的团队认为，一旦产品发布，用户反馈就会成为后续可以利用的资源。记录点赞和点踩信号，积累足够的量，最终进行微调。现实情况更为棘手：一年的反应记录并不等同于一年的对齐质量训练数据。这两者之间的差距，正是对齐技术——RLHF、DPO、RLAIF——要么拯救你，要么令你措手不及的地方。

这篇文章不是对对齐研究的综述。它是一份面向工程师的决策指南，旨在帮助你从数据收集的角度理解这些技术的需求，从而确保你今天部署的埋点确实能够支持你计划在六个月后进行的微调。

你的团队花了三个迭代周期标注了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，你的适配器现在运行在一个从未为之设计的基础上，且没有任何迁移路径。