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

在任何严肃的微调项目进入到第九个月时，你的训练语料库的作者数量可能已经超过了你的代码库。合成生成流水线编写了数百万个示例。供应商标注公司从你从未见过的劳动力那里贡献了 8 万行数据。一位工程师在上周二添加了 47 个示例，以修复他们在评估（eval）中发现的回归问题。一个抓取任务每天晚上将生产环境的追踪记录（traces）拉取到一个“补充”的 parquet 文件中。二月份有人扔进 S3 的一个 CSV 文件仍然在那里，仍然处于训练组合中，而编写该文件的人已经在三月份离职了。

现在看看你的应用程序代码仓库。每一行代码都可以追溯到具体的作者。每一次变更都经过了至少一名审核者的 PR。提交（Commits）是经过签名的。主分支（Main branch）是受保护的。合并需要第二个人参与。这里有审计日志。如果审计员询问 payment_processor.py 的第 47 行是谁写的，你可以在几秒钟内给出答案。

如果他们问产生模型 v2.3 的语料库中的第 47 个示例是谁写的，诚实的回答是“2024 年第二季度的 Mechanical Turk 批次，供应商未知，理由缺失。”你的微调语料库是比代码库权限更高的部署表面——它直接决定了生产环境中模型的行为——而你正在通过存储桶（bucket）发布它，却通过经过审查的 PR 发布代码。威胁模型被倒置了。

一位客户提交了一份主体访问请求（Subject-Access Request），要求删除他们的数据。数据工程师清理了生产数据库、分析仓库、支持工单存档以及冷备。法务团队在数据清单中列出的每个系统都反馈清理完毕。随后，房间里有人提出了一个没人想第一个回答的问题：那模型呢？

三个月前，该客户的支持记录被用于一次微调运行。从那时起，由此生成的适配器（Adapter）就一直在为其他客户提供预测服务，其中嵌入了该客户的措辞、账户名称，偶尔甚至还有权重中的原句。你可以证明数据仓库中的数据已删除。但你无法证明模型中的数据已删除 —— 团队中最诚实的那位成员会大声说出这一点。

2024年1月4日，OpenAI 下线了 /fine-tunes 接口。每一个基于 Ada、Babbage、Curie 和 Davinci 微调的模型都停止了响应。那些花费数月在这些模型上构建生产系统的团队——精心设计的提示、标注的数据集、标签流水线——一觉醒来发现收到的是 HTTP 404。微调模型没有迁移，学到的行为没有迁移，领域专业知识就此消失。

这不是小概率事件。2024年8月，Google 彻底关闭了 PaLM API，没有任何向后兼容的宽限期。与 OpenAI 至少允许现有 GPT-3.5 微调模型继续运行（只是禁止新的训练任务）不同，Google 的关闭意味着生产推理在同一天停止。如果你的微调 PaLM 模型处于关键路径上，你就遭遇了服务中断。

你的微调模型在评估套件上达到了 93% 的准确率。你将其上线。三周后，一位客户发来截图：模型以十足的自信回答了一个从未出现在训练数据中的问题——而且答错了。这并非通常意义上的幻觉，而是一段记忆。一种在预训练阶段烙入权重的模式，在微调从未覆盖的分布上死灰复燃。这就是预训练残留（pretraining residue），也是生产微调中最容易被忽视的故障模式之一。

微调调整的是权重，而不是从头重新训练模型。在万亿 token 规模预训练期间形成的模式——校准机制、置信度信号、世界模型先验——依然留存于权重之中。无论你的微调数据集多么精心策划，它都只是叠加在更深层先验之上的薄薄一层。当输入落在你的微调分布之外时，模型不会说"我不知道"，而是回溯到预训练，自信地给出答案。

你的 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”工作流的产物。