你的评测套件是一座博物馆：生产故障应当成为明天的测试用例

大多数 AI 团队只会构建一次评测套件——在上线前的冲刺阶段，他们精心设计了边界场景用例，记录预期输出，经过评审后发布。六个月后，套件仍然通过。然而，模型在实际生产流量上已经悄然退步，而评测框架却是在那些流量出现之前编写的。它仍然在评判作者提出问题的答案，而非用户真正在问的问题。

这就是"博物馆问题"：一个在某个时间点策划的评测套件会不断积累文物。它证明系统能处理某人预期的场景，却无法覆盖真正让它崩溃的场景。

解决方案并非在前期编写更多测试用例，而是构建一个反馈闭环，将每一次生产故障自动转化为永久性回归测试——让套件的覆盖范围与真实使用的复杂性同步增长。

冻结的评测框架及其无声失效的原因

静态评测框架受一种幸存者偏差的影响。你为已经思考过的失败场景编写用例，这意味着框架很擅长捕捉已知失败模式的回归。而未知的失败模式——当数千名用户触及系统边界时涌现出来的那些——永远不会进入套件，除非有人在事后手动添加。

实际上，手动添加几乎无法跟上节奏。当生产中出现糟糕的输出时，本能反应是修复模型或提示词然后继续前进。回归测试是零散添加的，要等工程师有时间时，或者在第三次发生后觉得够紧迫了才会添加。到正式记录该用例时，根本原因可能早已修复，而在下一个功能截止日期压力下，这种系统化的积累习惯也就逐渐侵蚀殆尽。

结果是：套件的过时程度与你的产品增长成正比。用户越多，边界用例越多。边界用例越多，失败模式越多。如果评测框架不消化这些失败，其覆盖率就会不断偏离现实。

还有一个更隐蔽的问题：公开基准会泄漏，内部基准则会积累针对基准的特定优化。当团队在微调或提示词工程期间针对基准进行调整时，他们实际上是在教模型通过那些具体用例，而非泛化到底层能力。由生产故障构建的自我强化评测框架则难以过拟合，因为这些用例总是来自新颖的用户行为，而非固定测试作者的想象。

四步反馈闭环

自我进化评测套件的机制归结为四个需要自动按序执行的操作：捕获、去重、评分和提升。

捕获意味着拦截生产故障，并保留足够的上下文以重建测试用例。这里的故障不一定是错误——任何低于自动评分器质量阈值的输出（延迟、格式违规、用户点了差评、LLM 评判分数偏低）都算。捕获系统需要存储完整的输入、输出、系统操作链路，以及故障信号。

现代 LLMOps 平台通过异步评分来实现这一点：它们记录请求，根据质量标准异步评估，并标记低于阈值的用例——对响应延迟零影响。

去重是大多数团队跳过、事后又为评测套件膨胀付出代价的环节。当生产繁忙时，同一失败模式每天可能出现数十次。如果每个被标记的用例都不加过滤地提升到评测套件，套件就会充斥语义重复——同一"用户用非正式语言询问退款政策"边界用例的 30 个变体。语义去重通过嵌入被标记的故障并聚类来解决这个问题：只有在嵌入空间中与现有用例距离足够远的用例才会被提升。阈值是可调的——在套件较小时可以严格去重，随着覆盖率成熟、新用例变得真正更难找到时再放宽。

评分不仅决定是否应该添加新用例，还决定它在评测运行中应获得多大权重。暴露新颖失败模式的用例获得更高权重，代表已充分覆盖常见模式的用例获得较低权重。评分信号可来自难度估算（模型通过该用例需要几次尝试？）、嵌入空间中的唯一性，或触发该用例的生产影响严重性。这正是评测套件开始表现得像主动学习系统的地方：它优先为每计算成本提供最多诊断信号的用例分配注意力。

提升是最后一步：经过去重和评分的用例被添加到框架中，带有来源标签（生产故障、时间戳、严重性）、通过/失败标签，以及——如果能确定真实预期输出的话——预期响应。对于真实答案模糊的用例，LLM 评判者承担这一角色。研究表明，强大的 LLM 评判者与人类评分者的一致率约为 85%（包括成对比较和单输出质量评分），即使评判者并不完美，对于大多数评测任务也足够了。

悖论：生产最混乱时，覆盖率增长最快

生产驱动评测套件最违反直觉的特性是：其增长率在你最希望高增长时最高——高流量、功能上线和模型升级期间——这些正是系统承受最多新颖压力的时刻。

加载中…