六个月的绿色 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%，那么该套件已经丧失了区分优劣的能力。信号消失了，绿色的构建不再能证明任何事情。
更难的诊断是你的评估集是否依然能相对于你真实的生产日志产生有意义的方差。采样数千条最近的生产交互，通过评估流水线重新运行，并将分数分布与你精心策划的评估集进行比较。如果生产环境明显更难，说明你的评估集正在针对产品的“幻影”进行校准。如果生产环境明显更简单，说明评估集已经偏移到了测试那些没人会真正遇到的边缘案例上。
滚动更新的纪律 将评测集视为快照是个错误。将其视为一个活的产物，就像对待你的生产系统一样，才是解决之道——这包含了一些成功团队趋于一致的几个具体组成部分。
案例的过期日期。 每个案例都携带一个“上次根据生产实际验证”的元数据字段。超过阈值（通常以六个月为起点，对于快速迭代的产品则更短）的案例会被重新审查：用户的措辞是否仍具代表性？在当前的语料库下，预期的答案是否仍然正确？未通过重新审查的案例会被重写或停用。通过的案例则更新其时间戳。这听起来很像官僚程序，事实也确实如此——但这正是保持测试套件诚实所需的纪律，就像变更日志保持 Schema 诚实一样。
查询分布漂移检测。 定期对生产查询样本进行向量化（embed），并将其分布与评测集的向量分布进行比较。当发散度超过阈值时，你就获得了一个量化信号，表明真实用户已经进入了评测集未覆盖的领域。这与在生产中检测模型输出的漂移不同——它是在检测测试输入与实时输入之间的差距。当该信号触发时，操作是根据评测集缺失的生产区域对新案例进行采样。
自动停用无区分度的案例。 跟踪 CI 历史中每次模型运行的单案例结果。如果某个案例连续三个月让所有候选模型都得到相同的分数，那么它就不再起作用了——它只是噪音。要么用覆盖相同失败模式的更难案例替换它们，要么将其移除。本能会让你保留它们，因为“它们通过了”，但一个任何模型都能通过的测试不是真正的测试。
以生产追踪（Trace）作为新案例的默认来源。 通过凭空想象来策划评测案例是扩展测试套件最慢、最具偏见的方式。对生产追踪进行采样——尤其是那些被在线评委（online judges）、用户报告或升级触发器标记的追踪——速度更快，更具代表性，并且生成的案例措辞与你的模型必须处理的实际用户措辞相匹配。在这个模式下，评测团队的工作不再是“编写测试案例”，而是更多地转变为“策划、标注并规范化生产中已经产生的案例”。
根据能力面（Capability Surfaces）对评测案例进行版本化。 当产品获得新能力时——如视觉、代码执行、多轮工具调用、更长的上下文窗口——历史案例是在模型无法以这些新方式失败的体制下编写的。你需要根据能力面对评测集进行版本化，就像根据 API 契约对测试套件进行版本化一样。在视觉能力发布之前编写的案例明确地不测试视觉；必须编写新案例来涵盖该能力引入的新失败模式。
没人想谈的预算对话 大多数评测团队获得的资金是为了增加覆盖率，而不是为了维护它。预算框架是“我们发布了一个功能；我们需要相关的评测案例”——而更换腐坏案例、停用无区分度案例以及将生产数据重新采样到套件中的工作，在某些东西崩溃之前是不可见的。随后，评测团队会因为一个“全绿但陈旧”的套件批准了回归而被指责，而通常的反应是要求增加更多案例，这反而加剧了问题。
坦诚的谈话应该是：评测套件的维护成本与产品、语料库和用户群的变化率成正比。一个静态套件在编写完成后几乎不产生任何成本，但在 12 个月后也几乎不产生任何信号。根据我们的经验，一个维护良好的套件每年约占其初始创建成本的 20% 到 30%，并能无限期地产生信号。那些没有为维护部分编列预算的团队通常会在第 9 个月左右发现，他们拥有一个漂亮、昂贵但完全无法提供有效信息的评测套件——而回到有用套件的路径几乎等同于重新编写它。
这也是反击高管们通过案例数量来衡量评测健康状况的直觉的时刻。“我们有 4,000 个评测案例”听起来很唬人，但与该套件是否仍具有区分度几乎无关。一个拥有 400 个维护良好的案例、其中一半是从上一季度生产中重新采样的团队，比一个拥有 4,000 个在上线时编写且从未触碰过的案例的团队能产生更多的信号。真正重要的数字是每个案例的区分力，并根据案例最近验证的时间进行加权。
当你严肃对待衰退时会发生什么 最有用的转变是停止将“评测集通过了”作为“我们是否应该发布”的答案。这种说法一直被过度承载了——它混淆了“这个候选模型在具有代表性的工作片段上优于基准”与“这个候选模型在生产中是安全的”。一个维护良好的评测集可以支持第一个断言。一个陈旧的评测集两者都无法支持，而假装它可以，正是整篇文章所讨论的失败模式。
第二个转变是将评测集的新鲜度视为与模型准确率同等的一等指标。跟踪套件中案例的中位年龄。跟踪上一季度从生产中重新采样的案例比例。跟踪评测输入与实时输入之间的向量发散度。将这些数字与你的模型质量数字放在同一个仪表盘上。当新鲜度跌破阈值时，将其视为质量回归——因为事实就是如此，即使套件运行结果依然是全绿。
第三个转变更难、也更慢：建立起将评测集视为会老化、需要维护并具有生命周期的承重基础设施的肌肉记忆。大多数团队已经为他们的生产代码建立了这种肌肉记忆。几乎没有团队为他们的测试建立这种意识。弥合这一差距的团队最终会获得快速发布且极少生产回归的罕见组合；而没有建立这种意识的团队则是在迷雾中前行，将那盏已无法照亮道路的、显示为绿色的 CI 灯当作唯一的指引。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
