你的评测集是一张用户早已离开的流量快照

你发布了一个模型升级。评估套件的分数从 87% 提升到了 91%。更新日志信手拈来，领导层纷纷鼓掌，然而那些真正重要的仪表盘——用户满意度、工单升级率、点踩率——却毫无动静。毫无起色。甚至可能略微变差了。

这是 AI 工程中最令人迷惑的失败模式之一，因为表面上没有任何东西坏掉。评估运行正常。数字是真实的。在你测试的 600 个示例中，模型确实有所改进。问题在于，这 600 个示例是你构建套件那一周的流量快照，而在那之后的几个月里，你的用户已经走出了画面。

评估集并不是对质量的衡量。它是对特定输入分布下质量的衡量。当你引用一个基准测试数字而不说明其计算分布时，就相当于在报告温度却不说明温度计放在哪里。数字很精确，数字也毫无用处，而在这两个事实之间的鸿沟，正是数周工程心血无声消失的地方。

生产流量是河流，而非湖泊

当你组建评估集时，你会从用户当时的活动中采样。你对它进行整理、标注、冻结，并将其提交到代码库。从那时起，它就是一个静态的制品。它不再改变。

但你的用户并不会表现出同样的“礼貌”。生产流量是一条流动的河流，它至少以三种不同的方式在移动。

它移动是因为用户发现了新的用例。你为重置密码和账单问题构建了一个支持智能体。六周后，人们开始往里面粘贴完整的错误日志，并要求它诊断集成问题。没人在意许可。流量组合在你眼皮底下发生了偏移，而你的评估集仍然认为它的任务是重置密码。

它移动是因为用户抛弃了旧的模式。曾经占评估集 30% 的查询类型，现在可能只占实时流量的 4%，原因可能是你发布了一个无需模型即可处理该问题的 UI 更改，或者是因为竞争对手教会了用户用不同的方式来表达。你的评估仍然花费 30% 的权重去给一个几乎没人问的问题评分。

它移动是因为用户进行对抗性的边界探测。并不总是恶意的——通常只是出于好奇。他们找到了让模型困惑的措辞，并且因为这种困惑很有趣，所以他们会一直这么做。生产中的难题会随着时间推移而累积。而你评估集里的难题，在编写它们的那天就被固定在了琥珀中。

因此，基准测试的提升衡量的是用户早已离开的分布上的进展。这确实是提升，但它只是发生在了一个空无一人的地方。

当满意度下降时，套件依然显示绿色

这种情况最危险的版本是无声的。没有警报，没有失败的 CI 检查，没有红色的数字。评估套件处于通过状态。它甚至比以前通过得更干脆。那个绿色的勾号正在造成实质性的损害，因为它是领导层用来判断 AI 功能是否健康的依据。

算一笔账。假设在你构建评估集时，它对生产流量的代表性为 85%。每个月，偏移都会侵蚀这一点——新的用例、废弃的模式、改变的措辞——让代表性下降几个百分点。两个季度后，也许只有 55% 的评估内容仍能反映用户的实际发送。你那 91% 的得分，现在只是基于略多于一半的现实情况，而剩下的部分全靠运气。

与此同时，你的评估不再覆盖的那一半生产流量，恰恰是增长的那一半，因为增长本身就是导致偏移的原因。评估最明亮的地方，恰恰是活动最稀薄的地方。有团队报告称，模型在静态套件上表现良好，同时却在悄无声息地积累细微的答案退化、缓慢的检索衰减和边缘案例幻觉——所有这些在汇总数据中都是不可见的，因为汇总数据是基于陈旧输入计算出来的。

你不会收到警报。你会看到一系列看起来正常的每周评估报告，以及来自真实人类指标的缓慢、难以归因的下降。等到有人将这两者联系起来时，评估套件已经失去了公信力，而重建对一个数字的信任比重建数字本身要难得多。

幸存者陷阱：你的评估过度代表了已解决的问题

还有第二种更微妙的扭曲，它是一种幸存者偏差。

当你构建评估集时，你倾向于在其中填充你可以自信标注的查询。你需要一个标准答案（ground-truth）来进行评分，因此你会倾向于那些有清晰、可验证答案的问题——而这些问题往往是当前模型已经处理得很好的。那些真正困难、模糊、甚至不知道答案在哪里的查询更难标注，因此它们要么被采样不足，要么被悄悄丢弃。

结果就是一个偏向已解决问题的评估集。这在机器学习领域相当于通过研究返航的轰炸机来决定在哪里加装装甲：你看到的是那些成功返航的飞机。进入你评估集的查询就是那些“返航”的、易于标注的部分。而那些“坠毁”的——混乱的、新奇的、真正令人困惑的输入——从未进入数据集，因此评估无法察觉它们。

加载中…