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

当你的第一个微调模型上线生产环境时，你的权重就成了一种你的隐私计划从未编目过的新型记录。进入训练组合的客户服务记录不再仅仅是数据库中你可以 DELETE 的一行 —— 它现在被冗余且不可提取地编码进了你的 API 所提供的参数中。原始记录可以从 S3 中擦除，从你的仓库中抹去，并从你的 RAG 索引中删除，而模型仍会继续使用该客户的姓名、账户 ID 或病史片段来完成提示词。你的销售团队签署的数据保护协议 (DPA) 承诺你会履行删除请求。但没有人问过 ML 团队这在技术上是否可行。

关于 PII 提取的研究表明，这并非假设。PII-Scope 基准报告显示，在现实的查询预算下，针对预训练模型的对抗性提取率最高可增加五倍；而使用自提示校准的成员推理攻击已将微调模型的 AUC 从 0.7 提升至 0.9。Llama 3.2 1B 是一个被广泛复制的小型基座模型，已被证明会记住其训练集中存在的敏感记录。对于任何在生产追踪数据上发布微调模型的人来说，结论是生硬的：你不能假设你的权重已经忘记了。

这一点很重要，因为大多数微调流水线是由 ML 工程师设计的，他们优化的是损失 (loss)，而不是由优化 GDPR 第 17 条款的数据主管设计的。结果产生了一个法律地位模糊、来源极少被记录、且不存在“删除用户 X”工作流的产物。

一名高级工程师在六个月前离职了。她负责管理用于路由客户支持工单的分类器适配器——这是一个基于 847 个手动标注样本训练的 32 秩 LoRA，挂载在一个还有 43 天就要停用的基础模型上。没人记得为什么从最初的 2,000 个样本中选出了这 847 个。训练数据存在一个 S3 存储桶里，由于其生命周期策略，超过一年的对象会被自动清除。她的笔记本电脑已被抹除。那个微调笔记本（notebook）中有一个单元格调用了一个预处理函数，该函数是从她个人的 dotfiles 仓库导入的，而现在那个仓库是私有的。

这就是“孤儿适配器”（Orphan Adapter）——一个比其维护者、数据甚至其所基于的基础模型寿命更长的微调模型。它存在于你的生产栈中，路由着真实的流量，而团队中没人能重新构建它。停用邮件并没有制造这场危机，它只是揭露了危机。

第一个迹象几乎总是相同的：你的内部评估仪表盘显示一片绿色，奖励模型（reward-model）分数正在攀升，DPO 损失趋势向好——而一位 Zoom 会议上的客户耸耸肩说：“它现在听起来像 ChatGPT。”训练团队中没有人想听到这样的话。评估结果显示模型更好了。交付上一批偏好数据的标注员也说模型更好了。但用户告诉你的是真话，而仪表盘在撒谎。出问题的并不是某一个标签。出问题的是你的偏好数据不再属于你了。

这就是合成偏好陷阱。标注预算被压缩，有人提议使用一个更强大的模型来对第二个模型的补全结果进行排序，实验发布了，在一段时间内，这看起来像是一顿免费的午餐。学生模型在每一轮对话中都学着听起来更像老师，而且由于你的奖励模型是基于受老师影响的数据训练的，你的奖励模型会欣然表示同意。用户看到的产品读起来和任何其他基于相同前沿 API 构建的产品完全一样。你原以为通过微调买到的差异化，已经在不知不觉中被蒸馏掉了。

一家医疗公司每天用 GPT-4 处理 10,000 份文档，年度账单高达 5 万美元。在用前沿模型的输出对一个 270 亿参数的开源模型进行微调后，相同的工作量仅需 5,000 美元——节省了 90%。这个小模型在他们的特定任务上还比前沿模型高出 60%，因为它已经见过数千个完全正确行为的示例。

这就是现代形式的知识蒸馏：你一次性支付前沿模型 API 费用来生成训练数据，然后永远运行一个小型专用模型。这个算法之所以成立，是因为当你拥有权重时推理成本很低，而且在有足够示例的情况下，特定任务的模型能在窄任务上胜过通用模型。

但"收集输出、微调、上线"并不是完整的方案。大多数尝试蒸馏的团队都会遇到三堵隐形墙之一：劣质的合成数据导致学生学到错误行为，缺乏可靠信号来判断学生何时真正就绪，或者生产环境中出现无声的质量崩溃，直到用户抱怨才被发现。本文涵盖决定蒸馏是否成功的流程决策。

在一个运行时间足够长的 AI 项目中，几乎都会出现一种模式。团队构建了一个原型，演示效果看起来不错，但在生产环境中，输出结果不够一致。有人建议切换到最新的前沿模型——用 GPT-4o 代替 GPT-3.5，用 Claude Opus 代替 Sonnet，用 Gemini Ultra 代替 Pro。有时这会有所帮助，但最终这种方法会不再奏效。团队发现，他们为每次推理支付了 5-10 倍的费用，延迟增加了一倍，而任务准确率仍然停留在 78%，而不是他们需要的 90%。

这就是潜在能力上限（latent capability ceiling）：即你所使用的语言模型的原始规模不再是限制因素的临界点。这是一个有经验数据支持的真实现象，大多数团队在遇到它时却浑然不觉——因为“使用更大的模型”这一反射动作成本低、速度快，并且在项目早期往往非常有效。

这个方案听起来简洁明了：为每种专项技能分别微调轻量级LoRA适配器——一个处理专业语气，一个处理JSON格式化，一个处理医学术语，一个负责安全护栏——然后在推理时将它们组合起来。团队上线了这套设计，开发阶段运行良好，但到了生产环境却频频崩溃：两个适配器开始争夺同一权重区域，输出质量骤降，最终与未经训练的基础模型毫无二致。不是略有下降，而是彻底退化。

本文探讨适配器组合在实际应用中的表现、朴素合并为何屡屡失败，以及哪些策略在生产规模下真正有效。

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

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

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

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

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

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

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

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

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

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

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

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