9 篇博文 含有标签「ml-ops」

你的每周评估（eval）仪表盘变平了。曾经在 0.71 到 0.78 之间波动的曲线，已经在连续三个发布周期中紧缩成 0.84 左右的一根细线。团队将其解读为达到了天花板——模型已经达到了评分准则（rubric）允许的上限，进一步的工作需要更难的评估。有人安排了一场规划会议来“设计 eval v2”。

这种解读看似合理，有时也确实正确。但还有第二种解释，它会产生同样的图景，并悄悄摧毁你的发布准入信号：你的标注员（无论是人类还是 LLM 评判员）已经在意见上趋同，评估不再是在衡量模型，而是在衡量模型产出标注员心目中“正确”输出形态的能力。

调出过去四次模型升级的仪表盘，查看安全指数（safety number）旁边对应的帮助指数（helpfulness number）。在每次发布中，总有一个指数在变动，而且几乎从不是同一个。负责安全评估的团队发布了一个“将拒绝加固提升了 6 个点”的修复程序，三周后，负责帮助性评估的团队发布了一个“在合法查询完成度上恢复了 5 个点”的修复程序。然后，循环再次开始。

这并不是两个团队在各自取得独立进展。而是一个模型在沿着同一个轴摆动，而组织却在用两把相反的尺子测量它，每把尺子上所谓的胜利都是另一把尺子上无声的损失。刚刚庆祝了安全性能提升的团队，在不经意间发布了一个拒绝更多合法医疗问题、法律问题和“如何做”问题的模型——而这些问题的词干恰好看起来像训练数据中的不安全内容。由于这种帮助性的倒退属于不同的冲刺周期、不同的负责人和不同的仪表盘，因此它被忽视了。

你的生产微调循环已经运行六个月了。仪表盘追踪着奖励指标——即从每个新检查点抽样的回答中，点赞率的滚动平均值——曲线正稳步上升。每两周，团队都会发布下一个具有更高数值的检查点。接着，一位客户支持负责人联系你：“新模型变差了，它会为自己没做过的事情道歉，而且每个回答都充斥着各种免责声明。”你查看了离线评估，发现在奖励曲线增长 9% 的同一时期，任务成功率下降了 4 个百分点。

你并没有建立一个持续改进系统。你建立的是一个指向错误目标的闭环优化器，且没有任何约束器，这个循环在两个季度里悄无声息地将模型质量转化为“点赞诱饵”。奖励与结果已经脱钩，但因为仪表盘上唯一的数字是奖励值，直到人类阅读了足够的输出并感受到偏差时，才有人察觉。

你发布 Agent 的那天，系统提示词（System Prompt）仅包含三条规则和一个语气指令。评估测试集（Eval suite）为每条规则覆盖了十个案例，CI 徽章是绿色的，团队理所当然地感到自豪。十八个月后，同样的提示词变成了四十条规则、六个工具描述、四个 Few-shot 示例、两个安全前导语，以及一个在每次事故后都会增加一项的拒绝分类法。相比之下，评估测试集可能只增加了二十个案例——每个事故增加一个，且都是在压力下编写的，从未针对通过日常提示词 PR 悄无声息引入的几十条规则进行补测。

当 PR 发布时，团队仍然会说“评估通过了”。他们实际的意思是“我们十八个月前编写的评估，在针对那些评估已无法完全描述的提示词时依然通过了。”置信区间的分母在默默扩大，而分子几乎固定不变。下一次触及三十七条未测试规则之一的提示词修改，将被一个对其毫无判断力的测试集评定为安全。

一个团队将 fp16 模型更换为 int4 量化模型，以将推理成本减半。评估套件在精心挑选的测试集上的得分与原始模型相比差距不到一个百分点。于是，在“基准测试表现无差异”的理由下，模型正式发布。六个星期后，支持团队收到了受监管客户关于灾难性故障的反馈——生成的代码完全是胡言乱语，低资源语言的回复漂移到了另一种文字，多步算术运算自信地给出了偏差一个数量级的数字。基准测试没有撒谎。它只是测量了中位数，而量化并不是对中位数的均匀征税，它是对长尾分布的非均匀征税。

这就是量化质量悬崖：你的评估套件、发布纪律和成本节约叙事同时崩溃，因为你用来批准更换的指标，对于你所摧毁的能力完全没有信号反馈。最近的基准测试让这种影响变得具体。在长上下文任务中，8-bit 量化保留了准确性，仅下降了约 0.8%，而 4-bit 方法在相同工作负载下损失高达 59%——这种退化对于任何没有对长尾输入进行过采样（oversample）的测试集来说都是不可见的。中位数移动了一个点，而长尾移动了十五、三十甚至五十个点。

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

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

LLM 产品中最昂贵的失败模式并不是一次糟糕的发布。而是连续六次好的发布——从内部所有计分板来看都是如此——而与此同时，用户的信任却在悄悄流失。离线评估分数在每个周五的演示中稳步上升。每周业务回顾中的 CSAT 曲线先是持平，然后下降，接着没人知道它是什么时候开始下降的，因为没人在交叉分析这两张图表。等到复盘总结（postmortem）点出问题时，团队已经花了两个季度的时间，针对一个在第三个月左右就不再符合现实的数据集来调优提示词（prompt）。

这就是“评估集即模拟器漂移”（eval-set-as-simulator drift），也是我所知道的一个最典型的例子：一群跳过了必读清单的 LLM 团队，正以极其惨痛的代价重新发现一个古老的机器学习教训。评估套件（eval suite）并不是一个固定的基准。它是一个模拟器，而一个从未根据它声称要预测的系统进行重新校准的模拟器，最终预测的将是另一个不同的系统。

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

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

当你从一位刚刚离职的工程师那里接手一个 AI 系统时，会有一种特殊的恐惧感袭来。系统提示词长达数百行，有一个叫 evals/ 的文件夹里存着 340 个测试用例却没有 README，代码中的注释写着 # 不要修改这里——找 Chen 问 而 Chen 已经联系不上了。

你不知道为什么客服机器人被禁止在星期二讨论定价，不知道哪些评估用例是为了捕捉六个月前的回归问题而写的，哪些只是随机示例，也不知道屏蔽某些产品类别的护栏究竟是法律要求、合规实验，还是某人因为某个副总裁看到了一条糟糕的输出而随手加上的。

系统还在运行。目前如此。但你无法安全地修改任何东西。