评估集腐化：为什么评估分数在上升，而用户满意度在下降

评估分数连续两个季度呈上升趋势。仪表盘是一片绿色，回归测试套件自三月以来从未标记过真实的失败，团队交付 prompt 更改的速度也变快了，因为评估（eval）给出了清晰的通过/失败答案。与此同时，用户反馈的质量正在下滑。NPS 下降了 4 分，支持队列里堆满了没人标记过的失败模式，产品负责人开始质疑：如果客户这么生气，为什么评估结果看起来却这么好？

评估集没有撒谎。它正在回答六个月前它被构建时要回答的问题，针对的是发布周存在的流量分布。产品已经发生了偏移。用户群体已经发生了偏移。发布时团队未预见到的长尾用例现在占了流量的三分之一。评估集仍在衡量第一周的世界，而团队正在用昨天的产品对今天的模型求平均值。

这就是评估集腐化（eval set rot）。它是现代 AI 工程中最隐蔽的失败模式之一，而且随着评估集的变大而变得更糟，因为维护它的人将“更多用例”误认为是“更好的覆盖”。

评估集是一个样本，且采样策略是隐形的

工程师在构建评估集时做的第一件事就是将其视为一个固定的对象。一个 JSON 文件文件夹、一个测试运行器、一个通过率。CI 流水线根据通过率来控制合并。当报告 bug 时，团队会添加新的用例。评估集在增长。每个人都感觉良好。

没人追踪的是这套评估集背后的隐形采样策略。一个评估用例之所以进入该集合，是因为某人在某个时刻认为它很重要。发布时的策略可能是“我们从调研访谈中预期的首要用例”。一个月后变成了“用例加上一些我们要防止回归的 bug”。六个月后变成了“任何人手动标记过的所有内容，并根据抱怨最响亮的团队进行加权”。

那不是采样策略。那是累积。这种区别很重要，因为评估分数只有相对于样本才有意义，而一个毫无原则的样本会产生一个毫无原则的分数。团队报告的是一个与实际分布没有合理关系的数字，他们已经失去了回答“如果我们的模型通过了评估，用户会更开心吗？”这个问题的能力。

一个有用的评估集应该有一个书面的、版本化的采样策略。新工程师能在五分钟内读完并理解：这个集合包含 N 个用例，从定义的时间窗口内的生产追踪中提取，按以下意图类别分层，并带有这些目标权重，遵循以下排除规则，并按以下频率刷新。如果你不能为当前的评估集写出这样的一段话，那么你就没有评估集。你只有一堆文件夹。

隐藏在综合通过率下的两种失败模式

站会上报告的数字是综合通过率。这个数字掩盖了两种需要不同修复方法的不同失败模式。

第一种是校准偏移（calibration drift）。集合中的用例在发布时是生产流量的合理替代方案，但生产流量已经发生了偏移。该集合仍然通过是因为用例本身没有改变，且模型没有在这些用例上发生回归，但该集合现在回答的是团队不再关心的问题。修复方法是根据当前的生产分布重新对集合进行采样。

第二种是简单用例累积（easy-case accumulation）。随着时间的推移，新的用例被添加进来，主要来自 bug 报告。Bug 报告往往偏向于那些足够明显、有人能写出清晰预期输出的用例。困难用例——开放式生成、多轮对话的歧义、合法的评判者也会产生分歧的用例——添加得更慢，因为它们更难标记。几个月后，简单用例的相对权重就会上升。通过率上升不是因为模型变好了，而是因为评估变简单了。修复方法是建立删除机制和按群体加权，而不是增加更多用例。

大多数团队两者都没注意到。他们看到数字呈上升趋势，就假设系统正在改进。架构上的认识是：综合通过率是两种独立动态的有损总结，一个健康的评估程序应该同时报告这两者。

影子集：检测分布偏移的并行工具

修复校准偏移的原则是并行运行两个评估集。

黄金集（gold set）是团队信任的产物。它控制发布。它是精心策划、手动标记并按季度刷新的。它的工作是回归检测：这次模型更改是否破坏了我们明确承诺保留的行为？

影子集（shadow set）在每个周期都根据最近生产流量的分层样本重新构建。它还不足以被信任到可以控制发布。它的工作是分布偏移检测：这次模型更改在看起来像用户今天实际发送的用例上，表现是否有所不同？

有趣的指标不是任何一个集合单独的通过率，而是它们之间的分歧。当黄金集和影子集一致时，黄金集仍然是生产环境的忠实代表。当它们的分歧超过阈值时，黄金集已经陈旧，需要刷新。这种分歧信号告诉团队何时该投入精力重新生成黄金集，而不是按照一个或过于激进或不够激进的固定时间表进行刷新。

将项目从影子集晋升到黄金集的机制至关重要。影子集会产生噪音。代表为期一周的营销活动的一波用例并不是稳定的新模式。晋升规则应该要求：一个影子用例类别必须在多个采样周期中以有意义的权重存在，然后才能在黄金集中获得一席之地。否则，黄金集会继承上个月声音最大的任何东西，分歧信号也会随之瓦解。

直接衡量漂移，而不是等待投诉

大多数团队通过客户投诉渠道发现评估退化（eval rot）：支持工单堆积，高管询问原因，然后团队开始排查。到那时，产品已经为这种退化付出了代价。其实有一些直接的衡量方法可以更早地发现它。

最简单的方法是覆盖率指标：目前的评估集分布与生产环境分布的匹配程度如何？以下是几种实际的实现方式：

• 意图类别 KL 散度 (Intent-category KL divergence)：将生产追踪数据和评估案例分类到相同的意图分类体系中，然后计算两个分布之间的 KL 散度。当它超过阈值时，说明评估集已经发生了漂移。
• 嵌入空间覆盖率 (Embedding-space coverage)：对生产查询和评估案例进行嵌入（embedding），然后衡量有多少比例的生产嵌入云处于任何评估案例的微小半径内。覆盖率下降就是信号。
• 分群通过率与流量占比 (Per-cohort pass-rate vs. traffic share)：跟踪每个用户分群（cohort）的通过率，并根据其在实时流量中的占比进行加权。当一个规模虽小但价值很高的分群流量占比增加，但在评估集中几乎没有代表性时，即使总体通过率看起来不错，该分群的指标也已经对该分群失去了意义。

这些指标都不是完美的。基于 Token 频率的 KL 散度在应对细微语义转变时表现得很糟糕，这是众所周知的。嵌入覆盖率对嵌入模型的偏差很敏感。分群加权则依赖于一个本身也会发生漂移的分群分类体系。重点不在于找到一个标准的指标，而在于监测某些东西来揭示评估集与实时流量之间的差距，而不是等到这种差距转化为用户的痛苦。

分层、删除以及你可以辩护的策略

对于那些一直任由评估集漂移的团队，需要建立的纪律大致如下：

• 分层重新采样 (Stratified resampling)。每次更新都从生产追踪中提取新的案例，并在功能界面、用户群和意图类别之间进行分层。每一层的权重都要记录下来并进行审查。它们不一定是经验性的流量占比——高价值群体通常值得被超额代表，而长尾用例需要一个保底比例，否则它们会从评估集中完全消失。
• 删除纪律。不再代表任何生产分群的案例将被停用。这是团队最抵触的部分，因为这感觉像是扔掉了工作成果，但一个包含 2,000 个案例的集合中，如果有 600 个案例描述的是去年就被弃用的功能，那么它们只是在毫无意义地干扰分数。一个有用的规则：如果连续两个更新周期内都没有生产追踪匹配某个案例的模式，那么该案例就是待退休的候选。
• 分群切片 (Per-cohort slices)。在报告总体通过率的同时，也要报告每个有意义的分群切片。仪表板应能立即显示不同分群之间的差异，这样小规模高价值细分市场的回退就无法隐藏在健康的总体数据之下。
• 权重是显式的，而非自然产生的。当添加一个新案例时，团队要决定它是进入一个新分群、扩展现有分群，还是替换旧案例。否则，每当有人运行 git add 时，每个分群的相对权重都会发生漂移。

行业报告显示，退化率达到了显著水平——2025 年的一项 LLMOps 调查指出，保持不变的模型在六个月后，即使不考虑上游模型 API 的变化，其在新数据上的错误率也跳升了约 35%。数字本身并不如其形态有趣：退化是渐进的，在总体数据中是不可见的，并且会随着评估策略与实时分布之间差距的扩大而加剧。

架构层面的认知

评估集是一个测量工具。就像任何工具一样，它也存在校准漂移问题。一个没有重新校准流程的团队，其实际测量的东西并不是他们以为在测量的东西，而且工具在未校准状态下运行得越久，读数就会变得越发“自信地错误”。

这重新定义了大多数实际决策：

• “我们的评估集应该有多少个案例？”是个错误的问题。正确的问题是“我们的集合执行的是什么采样策略，该策略是否仍然匹配我们关心的分布？”
• “我们应该把这个 Bug 报告添加到评估集吗？”变成了“这个案例是否代表了一个稳定的分群，还是一个会扭曲策略的孤例？”
• “为什么用户不满意时评估结果还是绿色的？”变成了“我们的黄金集 (gold set) 与全新的影子集 (shadow set) 之间存在什么分歧，差距在哪一边？”

做得好的团队会像基础设施团队对待监控一样对待评估集：将其视为具有 SLO、发布流程和停用政策的生产级软件。做得不好的团队则将评估集视为一个测试固件文件夹，不断累积案例，直到分数被那些容易标记的案例所左右，并在六个月后发现，那个全绿的仪表板是公司里最昂贵的谎言。

向前迈进的步骤是微小且具体的。选择一个更新频率——每季度是一个合理的默认选择，如果你流量变化很快，可以改为每月。建立一个影子集。跟踪分歧。当分歧超过你的阈值时，更新黄金集，并记录发生了什么变化以及原因。这种纪律并不光鲜。但这就是一个随着产品增长而赢得信任的评估方案，与一个悄然停止衡量任何东西的评估方案之间的区别。