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

你的 RAG 流水线在理论上看起来很扎实：分块很清晰，向量库已建立索引，延迟也在可接受范围内。但用户一直在抱怨结果是错的 —— 并不是完全错误，而是在关键细节上“稍微”有些偏差。检索到的片段讨论了正确的概念，但时间点不对。它涵盖了正确的主题，但司法管辖区不对。它提到了正确的产品，但缺少了使其真正有用的库存信号。

这就是嵌入微调鸿沟。通用嵌入模型被训练用来编码语义相似性 —— 即两个文本意思大致相同的属性。但这并不等同于相关性。相关性是特定于领域的、对上下文敏感的，并且对于在互联网规模的通用语料库上训练的模型来说通常是不可见的。

几乎每个经历过初期演示阶段的微调项目，都会重蹈同一个覆辙：团队遭遇质量平台期，决定需要更多数据，增加了 50% 的样本，重新训练，却发现模型要么一如既往地平庸，要么明显变差了。增加数据的直觉对大多数软件问题是对的——更多信号通常有帮助。但微调存在一个预训练所没有的饱和区间，大多数从业者并不能识别自己何时进入了这个区间。

2024 年一项在 Qasper 数据集上测试 LLM 微调的研究发现，将训练集从 500 条扩展到 1,000 条后，Mixtral 的准确率得分从 4.04 跌至 3.28，完整性得分从 3.75 跌至 2.58。这不是超参数问题，而是数据饱和：模型开始记忆分布噪声，而非学习可泛化的模式。团队在引擎已经淹没之后，继续往里加燃油。

一家企业软件公司的团队在客户支持工单上微调了一个 7B 模型。目标指标——解决准确率——提高了 12 个百分点。团队发布了它。三周后，产品出现了谁也没预料到的第二种失败模式：模型悄然失去了处理多步问题的能力。用户会问一些稍超出支持领域的问题，得到的是自信但逻辑混乱的回答。模型牺牲了它不知道自己需要的广度，换取了它能够衡量的深度。

这就是泛化悬崖（generalization cliff）：紧随窄领域微调而来的隐性能力退化。与崩溃或超时不同，它不产生错误。模型仍然响应。它只是在与训练分布相邻的任务上表现变差——而这些任务从未出现在评估套件中。

当一个团队在客服工单、内部Slack记录或专有代码上对大模型进行微调时，通常本能地将数据摄取视为单向门：数据进去，更好的模型出来。但实际并非如此。一名研究人员只需API访问权限和200美元，就能系统地将原文逐字提取出来，其中往往包括模型本不应对外呈现的内容。这并非理论上的边缘案例——这是已被记录的攻击模式，已在包括全球部署最广泛的语言模型在内的生产系统上得到演示。

核心问题在于，微调模型在隐私立场上与基础模型有着本质区别。它们在规模更小、更具特征性的数据集上训练，个别样本远比基础模型行为更容易被区分——而这种可区分性正是攻击者所利用的。

大多数团队发现“零样本墙”（zero-shot wall）的过程都如出一辙：一个新的边界案例导致模型出错，他们向提示词（prompt）中添加一个示例，问题解决了。三个月后，他们已经累积了 40 个示例，消耗了 6,000 个 token 的上下文，性能指标数周没有变化，而那个清楚每个示例来源的提示词工程师刚刚离职了。

少样本提示（Few-shot prompting）非常具有诱惑力，因为它见效快。你观察到一个失败案例，添加一个演示示例，失败就消失了。反馈循环很紧凑，而且胜利感觉是无成本的。你没有注意到的是，随后的每一个示例带来的收益都在递减——到某个阶段，你为了那些几乎可以忽略不计的改进，付出了大量的 token、延迟和认知开销。

这就是“零样本墙”：它不是性能断崖式下跌的硬限制，而是一个收益锐减的区域。在这个区域，上下文学习（in-context learning）对于你的任务已经达到了天花板，剩下的唯一手段就是微调（fine-tuning）。

我在上个季度交谈过的一个团队发布了一个微调模型，该模型在内部评估中比基础模型高出 4 分，但在接下来的 6 周内，他们却眼睁睁地看着排名前三的客户流失。评估结果没问题。聚合指标没问题。微调模型只是恰好在中位数用户（即询问简短事实性问题的小型企业买家）身上表现出色，而在企业法律客群中悄悄退化了，而后者那些长篇、包含大量引证的查询才是真正的营收驱动力。没有人按照客户等级对评估进行切片分析，因为建模端的人并不知道客户等级至关重要。

大多数关于微调的讨论都处于两个极端之一。一端是“一个微调统治所有”的方法，它在所有客户数据的混合体上训练单个专业化模型，并冲刷掉了原本在基础模型中区分各细分市场的特定客群行为。另一端是“单客户微调”方法，它为每个租户训练一个单独的适配器（adapter），这在客户数量少于 100 个时在运维上是可以忍受的，但在达到几百个左右时就会崩溃。一个有趣的中间地带——由少数几个客群感知微调模型来服务细分的客群——在大多数生产实践手册中是缺失的。

我在上个季度交流过的一个团队在 8 周内发布了 4 轮偏好微调（preference fine-tuning）。每一轮，他们相对于上一个 Checkpoint 的离线胜率都在上升。每一轮，他们的 LLM-as-judge 都确认模型变得更好了。每一轮，他们的留存曲线（retention curve）都下垂得更厉害了一点。到第 4 轮时，裁判（judge）表示模型比 v0 基准提升了 71%；而用户的流失速度比开始前快了 9%。这就是一段话总结的 RLAIF 毁灭循环（doom loop），而残酷的是：该团队的流水线在技术上没有任何错误。

来自 AI 反馈的强化学习（RLAIF）—— 即使用更强的模型来生成你以前付钱请人标记的偏好标签 —— 是现代后训练（post-training）中最具经济合理性的决策之一。AI 生成的标签每个不到 1 美分；而人工标签则需要 1 美元甚至更多，对于特定领域的工作，价格通常是这个数字的 10 倍。在偏好数据集规模（数十万对数据）下，这就是六位数预算与五位数预算的区别。已发布的 RLAIF 基准测试显示，在摘要和对话任务上，其胜率在统计学上与 RLHF 无法区分。数学计算的结果是：切换到 RLAIF。

在单位成本方面，数学计算是对的；但在你购买的内容本质上，它错了。你买的不是偏好数据。你买的是裁判的偏好，并将其投影到你的数据上 —— 经过多轮训练，这种区别就体现为“与用户对齐”和“与另一个模型的审美对齐”之间的鸿沟。

当你的第一个微调模型上线生产环境时，你的权重就成了一种你的隐私计划从未编目过的新型记录。进入训练组合的客户服务记录不再仅仅是数据库中你可以 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）：即你所使用的语言模型的原始规模不再是限制因素的临界点。这是一个有经验数据支持的真实现象，大多数团队在遇到它时却浑然不觉——因为“使用更大的模型”这一反射动作成本低、速度快，并且在项目早期往往非常有效。