Eval 测试集是滞后指标：你的绿色仪表盘只反映上季度的失败

每一个成熟的 AI 团队构建其评估套件的方式都如出一辙，而且几乎没有人会公开说出那个潜台词。生产环境中出现了一个故障。有人写了一份复盘报告。一名工程师将该事故提炼为一个测试用例，将其添加到评估套件中，于是仪表盘再次变绿。重复这个循环一年，你就会拥有几百个案例、一个令人满意的通过率，以及一个足以让你在演示幻灯片上感到无比安心的数字。

潜台词是：那个评估套件其实是一个博物馆。每一件展品都是团队已经挺过来的故障类别。98% 的通过率证明了你的系统可以抵御过去 —— 抵御那些已经发生过的特定破坏方式 —— 而对于模型迁移、提示词编辑或用户行为转变即将引入的新型故障模式，它几乎给不出任何参考。评估集是一个披着先行指标外衣的滞后指标。

这很重要，因为团队会根据那个数字做出 go/no-go 的决策。你正准备将 gpt-4o 换成更新的模型，或者重写系统提示词，或者发布检索算法的变更。评估套件显示为绿色，绿色被解读为“安全”。但这个套件从来就不是为了测试你刚刚做出的改变而构建的。它的存在是为了防范已经发生过的事情。信心与覆盖率已悄然脱节，而仪表盘无法告诉你这一点。

评估套件是如何变成博物馆的

这种机制并非源于疏忽。恰恰相反 —— 它是指向单一方向的勤勉。

由事故驱动的测试增长其实是一种非常好的实践。当回归问题逃逸到生产环境时，将其捕获为永久测试用例正是自律团队该做的。问题不在于团队增加了回归案例，而在于对于大多数团队来说，回归案例是 唯一 被添加的案例。事故队列成了评估套件的唯一作者，因此套件的形态完全由已经发生的错误决定。

思考一下这个筛选过程过滤掉了什么。一个故障模式只有在满足以下条件时才能进入套件：(1) 已在生产中发生，(2) 被注意到，(3) 重要到需要记录下来。所有那些罕见的、缓慢滋生的、悄然退化的，或者单纯还没发生的故障类别，在结构上对这个过程是不可见的。评估套件并不是故障空间的样本。它是故障 历史 的样本 —— 而历史是这个空间中一个带有偏见的、滞后的、受幸存者偏差加权的切片。

《AI 评估现状》（State of AI Evaluation）的研究提出了一个相关的观点，使这一点更加清晰：在实践中，评估覆盖率表现为生产质量的先行指标，而事故量则是滞后指标。大多数团队将这两个角色搞反了。他们将评估通过率视为前瞻性的安全信号，而通过率本身却是根据滞后数据组装而成的。真正的先行指标 —— 评估套件实际上探测了多少潜在故障空间 —— 却是一个没人计算的数字。

为什么绿色仪表盘在迁移之日会撒谎

只要系统保持稳定，滞后指标的问题大多是无害的。只要底层没有变动，昨天的故障类别对今天来说就是不错的预测指标。

危险恰恰发生在有变动的时候。而在一个 LLM 产品中，变动最频繁的地方往往正是评估套件最不擅长覆盖的地方。

提示词编辑就是最明显的例子。行业关于 LLM 生产事故的报告总是指向同一个元凶：微小的、出发点良好的提示词更改导致了很大一部分故障。为了“改善对话流畅度”而增加的三个词，可能会在几小时内导致结构化输出错误率激增，因为提示词是在概率系统中运行的未经测试的代码。你的回归套件里有针对 上一次 提示词引发故障的案例，但它没有针对下一次故障的案例，因为下一次故障取决于你尚未进行的特定编辑中的特定词汇。

模型迁移的情况更糟，因为变更面巨大且不透明。新的模型版本可能会同时改变格式化行为、推理路径、拒绝边界、语气以及受延迟影响的输出截断。你的评估套件检查的是之前出过问题的少数行为。它默默地假设所有其他行为都会平移。迁移后的高通过率并不是因为新模型安全，而是因为评估套件一直只在询问一个很小的、由历史决定的行为子集 —— 而迁移之日正是该子集失去代表性的时刻。

这种失败还有一种更隐蔽的表现形式：评估过拟合。当同样的固定案例被反复用于调优提示词和挑选模型时，你开始针对评估套件而非现实进行优化。这是穿上白大褂的古德哈特定律（Goodhart's law）—— 一旦指标变成了目标，它就不再具备衡量价值了。Scale AI 的 GSM1k 实验具体展示了这一点：用同样难度的新题目重新构建基准测试，那些在原始测试中拿高分的模型得分明显下降。一个从不更新的评估套件不仅会漏掉新的故障，还会慢慢变得无法诚实地衡量旧的故障。

建立新颖性预算

解决方案并不是停止收集事故案例。而是不要让事故队列成为 唯一 的贡献来源。一个想要成为领先指标的测试套件，必须投入刻意的努力来探测团队尚未见过的失败类型。称之为“新颖性预算”——即在评估投入中保留固定比例用于探索，而非仅仅用于回归测试。

几项实践可以使这一预算变得具体。

将你的覆盖率指标一分为二。 单一的通过率会掩盖“后视镜”问题。将每个评估案例标记为 守卫型（锁定已知的、先前观察到的失败）或 探索型（探测尚未发生过事故的领域）。现在你可以报告两个数字，领导层一眼就能看出这个套件是 95% 的“博物馆”还是 5% 的“前沿”。如果探索性案例少到可以忽略不计，那么你的信心完全是基于过去校准的——你终于可以用数字而不是凭感觉来说明这一点了。

定期进行对抗性检查。 定期指派一名工程师——或一个模型——以现有测试套件尚未覆盖的方式来破坏功能。这是针对你自己产品的红队测试，而不是针对越狱（jailbreaks）。好消息是它是可扩展的：给生成器提供已记录失败的种子，然后通过改写、同义词替换和语境变化，将它们扩展到原始案例从未覆盖的邻近场景中。坦率地说，自动生成器往往会出现模式坍缩和早期饱和，生成的变体容易聚集在种子案例周围。将机器视为覆盖率的倍增器，将人类视为真正新颖性的源头，而不是相反。

针对变更进行生成，而不仅仅针对历史。 当你准备迁移模型或重写提示词（prompt）时，正是编写针对 变更面（新版本可能改变的格式、拒绝和推理行为）的探索性案例的时机，而不是仅仅重新运行历史套件并盲目相信那片“绿灯”。在高风险变更期间，评估工作量应该大幅增加，因为此时历史套件的代表性最低。

有意识地让旧案例失效。 十八个月前编写的回归案例可能守护的是一条已不存在的代码路径、一个早已重写的提示词，或者是产品已经停用的用户流程。陈旧的案例并非没有成本：它们虚增了通过率，消耗了 CI 时间，并创造了虚假的安全感。给源自事故的切片设置明确的有效期——定期根据当前产品现状重新验证它们，或者让它们自然淘汰。一个只会增长的套件最终会变成一个没人相信具体案例价值的套件。

真正应该关注的内容

这是决策规则。评估通过率作为回归守卫是没问题的，在捕捉已知错误的再次出现方面也确实有用。但对于测试套件并非为此设计的变更，它并不是一份安全证书。不要把“全绿”解读为“可以发布”，而应将其解读为“没有 已知的 失败类型再次出现”——这是一个严谨程度较低，但远为诚实的表述。

真正值得写在汇报 PPT 上的数字不是通过率。而是探索与守卫的比例：你的评估投入中有多少是在探测未知领域，有多少是在复核已知领域。这个比例才是你真正的领先指标。一个拥有 98% 通过率但只有 3% 探索比例的团队并不安全——该团队是根据一个已经过时两个季度的威胁模型来衡量其信心的。

评估套件总会有一部分像博物馆，这没关系。博物馆很有用，只是不要靠它来导航。也要资助探险，记录下你投入了多少资金，并在答案是“几乎没有”时让每个人都看到。