快照评估衰减：当绿色的 CI 不再意味着你的产品仍然可用

六个月的绿色 CI 掩盖了一个事实：大约 40% 的评估集（eval set）已不再代表用户在产品中的实际行为。测试套件仍在运行，裁判（judge）仍在打分，仪表盘依然闪烁着绿光。但这些案例是针对查询分布、语料库、工具界面和监管文本编写的，而这些内容早已发生了变化——现在的绿色运行意味着“昨天的产品在昨天的现实中依然有效”，而这并不是你付费让 CI 回答的问题。

这就是“快照评估退化”（snapshot eval decay），它是 AI 评估中最缓慢、最昂贵的失败模式。说它缓慢，是因为套件从未失败——陈旧性表现为无法区分模型优劣，而不是构建变红。说它昂贵，是因为当有人意识到评估通过的模型切换导致了生产环境回归时，团队已经建立了一年之久的“评估通过即发布”的肌肉记忆，而这一记忆是建立在一个早已悄然失效的资产之上的。

静态测试套件在传统软件中有一种常见的失败模式：套件通过了，但产品以没人测试过的方式崩溃了。快照评估退化则更糟糕，因为案例本身并没有变坏——它们依然能正确测试某些东西。问题在于底层世界已经发生了变化。这些案例在问：“给定一封来自第二季度的客户支持邮件，模型是否创建了正确的工单？”模型确实创建了正确的工单。但客户不再那样写邮件了。他们开始粘贴 Slack 对话，开始上传截图，开始使用评估集从未见过的俚语。测试套件发出的信号——“我们可以安全发布”——曾经是真实的。现在，它只是某个星期的策展案例留下的遗留产物。

发生偏移的四个层面

将评估退化视为四个相互重叠的分布，它们在不同的时间尺度上发生偏移，而评估集通常会锚定在编写当天最容易捕获的那个分布上。

首先是 查询分布（query distribution） ——即用户的实际提问。这一层变化最快，因为它随营销活动、病毒式内容、季节性模式和新用户群体而波动。一个最初服务于高级后端工程师的编程助手，在不到一个季度的时间内，其服务对象可能就变成了提问方式完全不同的初学者，或者是直接粘贴错误信息而没有上下文的培训班毕业生。发布时固化的评估集永远看不到这些变化。

其次是 语料库（corpus） ——即系统检索的文档。知识库会被编辑，政策文本会被修订，产品目录会增长。询问“我们的退货政策是什么？”的评估案例是根据编写该案例时的政策文本进行评分的。从那以后，政策可能已经修改了 11 次。案例依然通过，因为裁判提示词（judge prompt）仍然期望旧的表述。模型在生产环境中却是错误的。

第三是 上游工具输出（upstream tool outputs） ——即 Agent 调用的 API 返回的数据形状。后端团队会添加字段、弃用枚举值、更改分页方式，或从同步响应切换到稍后解析的任务 ID。评估案例模拟的是旧的形状。Agent 通过了评估，但在生产环境中崩溃了，因为新的形状包含了一个提示词从未考虑过的可空字段。

第四是 规则集（rule set） ——即模型应该遵循的监管文本、合规语言、品牌指南或内部政策。这一层的变化频率较低，但影响巨大：例如 GDPR 的修正案、新的披露要求或更新的风格指南。评估集编码了旧规则，裁判执行的也是旧规则。即使模型在评估中表现完美，其输出也可能在发布的第一周就被法务部门标记。

大多数团队根据其中一个层面（通常是发布时的查询分布）构建评估集，而任由其他层面在未经检查的情况下发生偏移。这套评估集越来越演变成对“旧产品在旧语境下”的评估，却披着令人放心的视觉外壳。

退化如何隐藏在绿色套件中

陷阱在于，这一切看起来都不像失败。软件领域的失败通常有视觉特征——红色的标记、堆栈追踪或 Slack 频道里的警报。而评估退化看起来像成功。案例依然在执行，裁判依然在评分。仪表盘上的总数甚至随着时间的推移略有上升，因为团队不断为新功能添加案例，而新案例往往很容易通过。

真正悄然消失的是 区分度（discriminative power）。一套有用的评估集必须能够区分“模型 A 对该产品优于模型 B”还是“模型 A 更差”。这需要案例足够困难，以激发出不同候选模型之间的行为差异。当世界发生变化时，两件事会同时发生。生产环境中出现了评估集完全覆盖不到的新失败模式——模型在 CI 看不见的地方变差了。而旧案例往往变得极其简单：底层模型在两年前觉得困难的输入上已经有了显著提升，现在每个候选模型都能轻松拿满分。分数依然很高，但信息含量已经崩塌。

如果你进行测量，是可以检测到这一点的。诊断标准是：你的评估集是否依然能在你选择的候选模型之间产生有意义的方差。如果你在评估集上将生产模型替换为去年的前沿模型，而分数下降不到 1%，那么该套件已经丧失了区分优劣的能力。信号消失了，绿色的构建不再能证明任何事情。

加载中…