评估疲劳周期：为何AI质量度量在上线后走向崩溃

AI评估的命运遵循着一条可以预测的弧线。冲刺零阶段：所有人都认同评估至关重要。上线周：套件运行顺畅，演示效果完美。第六周：CI任务开始被跳过。第十周：有人调高了失败阈值以消除告警。第四个月：绿色仪表盘已毫无意义，人人心知肚明，却无人点破。

这就是评估疲劳周期，它几乎普遍存在。尽管业界在自动化评估工具上持续投入多年，其市场渗透率仍仅有38%——这意味着大多数团队依然依赖人工审查作为主要的质量门控。当下一个模型版本升级，或本周Prompt已是第三次更改时，这些人工审查往往第一个被牺牲掉。

崩溃并非随机发生，它遵循一种可预测的衰退模式，在每个阶段都有可识别的失效模式。理解这一模式，是打破它的前提。

衰退的四个阶段

阶段一：上线高峰期。 在产品上线前的几周，团队对评估投入了高度关注。他们发现回归问题，迭代Prompt，打磨评估标准。每个人都将评估套件视为真正的工程制品。这是系统正常运转的时期。

阶段二：首次跳过。 上线后，节奏发生了变化。一个Prompt的单行修复在周五下午被推送上线。运行完整的评估套件需要20分钟，还要为LLM API花费真实的费用。有人决定"就这一次"跳过——逻辑是：我们没有改变任何核心内容，不过是调整了一下措辞。这个判断是错误的，但这个决定是隐形的。没有人收到通知。短期内也没有任何问题暴露。

阶段三：阈值膨胀。 数周后，评估套件发现了一个真实的回归问题，但它并未表现为用户可见的投诉。修复底层行为很困难，而提高通过阈值却很简单。团队选择了后者。这种情况发生一次，然后两次，直到阈值不再反映"我们承诺的质量水平"，而是"我们的模型当前的实际表现"。评估已经倒置——它如今追踪的是输出结果，而非约束它。

阶段四：僵尸仪表盘。 CI任务按计划运行，亮起绿灯，却无人查看。新功能上线时没有对应的评估覆盖。评估数据集已有九个月未更新，它是针对已不存在的Prompt和早已改变的行为构建的。团队在潜意识里已经学会：绿色徽章没有任何预测价值。他们不再在评估失败时提交事件报告，也不再在评估通过时欢呼庆祝。

这是大多数团队默默经历的状态。生产质量在一千次微小决策中逐渐退化，而每一次单独来看都显得无害。

为何衰退在结构上几乎是必然的

评估套件的衰退，与监控仪表盘的衰退原因相同：权属分散、缺乏强制门控，以及将指标与后果关联起来的反馈回路缺失。

没有明确的负责人。 当某个功能由一个团队负责时，该团队对其评估负责。但当权属分裂——ML团队负责模型，产品团队负责Prompt，DevOps团队负责部署流水线——没有任何人端到端地负责评估的生命周期。每个小组都可以在套件落后时将责任推给别人。在实践中，共同负责等于无人负责。

没有部署门控。 如果评估是可选的，它最终就会真的变成可选的。在截止日期压力下，团队会优化速度。如果CI门控不能在评估出现回归时阻止部署，那么短期内跳过的代价是零，长期代价则是隐形的。理性行为者在承受压力时会选择跳过。系统没有任何强制机制来对抗这一点。

跳过没有代价。 在运转良好的代码库中，跳过单元测试有立竿见影的后果：CI构建失败，PR无法合并，有人被叫醒处理告警。AI评估通常缺乏上述所有强制节点。代码无论如何都会上线。质量退化足够缓慢，以至于逐周来看感知不到。当回归终于对用户可见时，它已经积累了数月，根因早已无从追溯。

雪上加霜的是，漂移是悄无声息的。一个曾经能正确完成94%分类任务的LLM，不会宣布它已降至87%。它只是开始产生更多被漏过的边缘案例，更多技术上正确但语气微妙偏离的答案，更多遗漏了用户所依赖的细微差别的摘要。每个单独的失败都能得到解释。规律只在汇总时才可见，而这需要没有人在看的那些监控工具。

打破周期的基础设施模式

长期维持有效评估体系的团队，靠的是结构性选择，而非文化动员。你无法靠激励手段让团队保持持续的评估卫生习惯；你必须让维护评估成为阻力最小的路径。

将评估作为部署阻断器。 最重要的单一改变是将评估集成到CI/CD流水线中，作为硬性门控。当代码或Prompt的变更触发超过固定阈值的回归时，部署失败。不是"这里有份报告供你审阅"，而是"此PR在你解决回归问题之前无法合并"。这从根本上改变了激励结构。工程师习惯于在上线前修复失败的测试，他们不习惯忽视失败的评估——但前提是评估必须与测试具有同等的强制权重。

阈值必须被设定和守护。调高阈值的冲动，必须像团队对待"禁用某条安全lint规则"的提案一样处理：可以做，但需要明确的理由、一次审查，以及决策的书面记录。

为每个评估套件指定明确的负责人。 每个评估套件需要一个具体的人与之绑定。不是一个团队，不是一个工作组——是一个人，将此纳入其绩效背景，当覆盖率下降时被通知，并负责随着Prompt演进而保持数据集的时效性。这听起来有些官僚，但这是唯一能在组织人员变动中存活下来的权属模型。"ML团队负责评估"意味着无人负责；"小林负责摘要评估套件"才意味着真正的责任。

自动化的每周回归报告并广泛分发。 在CI门控之外，一份每周报告应自动发送到工程和产品负责人可见的渠道，展示每个评估套件的趋势线。目的不是创建行动项，而是在危机爆发前让漂移可见。如果提取流水线的精确率六周内下降了三个百分点，这是现在就应该进行的对话——而不是等到第四个月客户来投诉。趋势可见性，才能将潜在的质量债务转化为主动意识。

将评估覆盖率作为被追踪的指标。 就像代码覆盖率追踪被测试执行到的代码比例一样，评估覆盖率应追踪被评估涵盖的功能和行为比例。当新功能上线但没有对应的评估用例时，这个指标就会陈旧。追踪它会创造一种结构性的强制作用：当有人新增一个工具调用或检索路径时，流程会问"这个的评估用例在哪里？"覆盖率无法保证正确性，就像行覆盖率无法保证正确性一样，但它能防止评估套件在悄无声息中停止代表真实系统的常见失败。

软件测试类比的启示

与传统软件测试的类比不仅仅是比喻，在操作层面也有实际意义。软件行业花了数十年才明白：没有强制执行的测试会衰退，没有问责制的权属会扩散，与事件不挂钩的质量仪表盘只是装饰品。同样的教训适用于AI评估，但这个行业还处于软件测试的"2000年代初期"——大多数团队尚未将这些经验内化。

评估驱动开发将TDD的纪律适配到概率性系统：先编写正确性规范，在构建功能之前搭建评估框架，将评估失败视同构建失败。实施这一纪律的团队报告了更快的迭代周期，因为回归会立即浮现，而不是在被后续变更叠加放大的数周后才被发现。

实施模式：快速、廉价的评估（几十个典型用例，在两分钟内运行完毕）在每次提交时运行；全面评估（完整数据集、对抗性用例、多轮场景）在夜间或发布候选版上运行。这映射了单元测试与集成测试的分层结构——在不牺牲覆盖率的前提下使CI可控。

可持续评估基础设施的样貌

一个在上线六个月后仍然运转的评估体系，具备以下可观测的特征：

• 评估套件覆盖系统的每一个主要行为面，每个领域都有指定的负责人。
• 新功能在没有对应评估覆盖的情况下无法上线——这在PR审查流程中被强制执行。
• CI门控在超出既定阈值的回归时使构建失败，而调高阈值需要明确的负责人签字。
• 每周趋势报告自动发送，领导层可见，展示覆盖率、通过率和阈值随时间的变化。
• 评估数据集每季度针对生产流量更新——真实的失败案例成为测试用例，过时的用例被清除。

这些并不新奇。这正是软件团队用于测试基础设施的同一套纪律。AI团队之所以默认不这样做，是因为评估工具还比较年轻，失败模式不够直接可见，组织模板尚不存在。

40%的智能体AI项目将在未来两年被取消。大多数失败的原因不是模型能力不足，而是团队停止了对模型在生产环境中实际行为的度量，并失去了判断何时发生漂移的能力。评估疲劳周期是可以预防的。它需要在上线之前就做出结构性选择——趁团队还有足够的注意力和组织意愿去执行它们的时候。

在需要它之前就建好门控。在一个利益相关者已经学会忽视仪表盘的系统中，事后强制推行只会难上加难。