评估集衰退：为什么你的基准在构建六个月后会变得具有误导性
你花了三周时间精心整理一套高质量的评估集。你编写了测试用例来覆盖产品经理担心的边缘情况，从内测用户中采样了真实查询，并得到了一个团队认可的准确率数字。六个月后，这个数字仍然出现在每周的仪表盘上。你刚刚发布了一次在评估中表现出色的模型更新，用户却在提交工单。
问题不在于模型退步了。问题在于你的评估集几个月前就已经不再代表现实——而没有人注意到。
这种失败模式有个名字：评估集衰退。它几乎发生在每一个生产AI团队身上，而且几乎从不会在用户行为中出现可见损失之前被发现。
评估集衰退的真实面貌
评估集是你构建它时用户分布的冻结快照。真实流量并不是冻结的。用户会演变他们表达请求的方式。新的使用场景会涌现。在你的内测用户群中不存在的边缘情况，在你的大规模发布用户群中变得普遍。你的产品定位发生变化，吸引了具有不同期望的不同用户画像。
你的静态评估集与实时分布之间的差异并非随机的——它是有方向性且不断加速的。它会产生以下结果：
误导性的绿色指标。 你的评估套件通过率为91%。真实用户却很沮丧。差异在于你的评估用例来自六个月前的查询模式，而当前流量已经以评估无法测试的方式演变。你在衡量用户曾经问过的问题上的性能。
不可见的失败类别涌现。 生产环境会随着时间积累新的失败模式——措辞模式、请求格式、边缘情况——而这些都早于你的评估集。当你问"这次模型更新是否导致了退步？"时，你的评估只能对比它在你构建时所了解的失败模式。新型失败是不可见的。
基准饱和而无能力提升。 当团队持续针对同一个评估集迭代模型时，他们最终会对其过拟合。分数攀升至98-99%。真实性能停滞或下降。评估不再具有区分度——它正在被"作弊"，即使没有人刻意为之。
关于合成基准的研究发现，它们只能捕获出现在实际用户行为中60-70%的失败。随着评估集老化，这个差距会越来越大。
机制：为什么用户行为会漂移
理解漂移发生的原因有助于你预测它在哪里漂移得最快。
词汇和措辞演变。 用户根据他们观察到的有效方式调整语言。如果早期用户发现某些措辞能产 生更好的响应，他们就会分享这些模式。后来的用户采纳它们。措辞分布从你在内测中看到的发生了变化。你用旧惯用法编写的评估用例不再具有代表性。
用户群组成变化。 面向机器学习工程师推出的产品与同一产品在10倍规模下以企业运营团队为主要用户时，查询分布完全不同。为第一个群组构建的评估集不能代表第二个群组。
使用场景演变。 用户发现了产品未预料到的应用。这些应用涉及不同的请求格式、领域词汇和成功标准，超出了你最初设计的预期。评估集对此没有覆盖。
领域知识时效性。 在涉及当前事件的任何内容中——定价、法规、技术规格、人员——评估用例中的基准事实可能仅仅因为时间流逝就变得不正确。你现在在测试模型是否同意过时的事实。
衰退速度因领域而异。金融新闻、软件工具和当前事件等高变动领域可能在数周内让评估集过时。基础数学推理或通用文档摘要等稳定领域衰退较慢——但它们仍然会衰退。
衡量衰退：如何判断你的评估在说谎
第一步是让漂移变得可见。大多数团队只有在生产事故发生后才意识到评估已经衰退。有更早期的信号。
生产-评估语义距离。 将最近生产查询的样本和评估用例的样本嵌入到同一个向量空间中。测量质心距离和两个分布之间的重叠。如果向量空间正在发散，你的评估覆盖的是与流量不同的领域。这可以作为每 周检查自动化执行。
覆盖热力图。 按主题、意图和措辞模式对生产查询进行聚类。衡量每个聚类中有多少比例有对应的评估用例。你会发现实时流量中整片区域没有评估覆盖——这些就是你的盲点。覆盖热力图将衰退从抽象变为具体：你可以指出你目前无法衡量的具体查询类型。
随时间变化的多样性指标。 跟踪传入流量与评估集的n-gram熵和语义多样性。当流量多样性指标向上偏离评估多样性指标时，用户正在探索评估未覆盖的领域。Vendi分数和嵌入不相似性指标在这里很有用，因为它们不需要标注——它们直接对查询分布进行操作。
统计漂移测试。 在滚动基础上对嵌入查询分布应用Kolmogorov-Smirnov或种群稳定性指数测试。PSI值超过大约0.2表明存在需要调查的可操作漂移。这些测试借鉴自传统ML监控，但直接适用于LLM输入分布。
一个正常运行时间为99.2%、延迟健康的客户支持机器人，其幻觉检测分数在一个季度内可能从94%下降到82%，而没有任何基础设施警报触发。这种质量漂移对基础设施监控是不可见的——只有当你针对生产流量的新鲜样本运行质量评估时才能发现它。
修复方案：滚动评估维护
将评估集视为永久性工件是问题的根源。解决方案是将评估维护视为持续的工程职能，而不是一次性任务。
持续生产采样。 代表性评估用例最可靠的来源是生产流量。建立一个管道，以可配置的速率（通常是5-10%的流量）采样实时查询 ，通过质量过滤器路由它们，并将它们输入候选评估池。从这个池中，自动化和轻量级人工审查的组合选择案例提升到活跃评估集中。关键属性：你的评估分布不断从实时分布中刷新。
样本优先级排序很重要。你不想添加与现有案例语义相似的评估案例——这会浪费容量并虚增覆盖率而不减少盲点。向以下方向加权新样本选择：（a）现有覆盖率低的查询类型，（b）当前模型显示高不确定性的案例，以及（c）从生产反馈信号中浮现的失败案例。
滚动退役过时案例。 在不删除旧案例的情况下添加新案例会使评估集膨胀，而不会提高其代表性。审核你的评估案例的年龄和近期相关性。来自已废弃产品流程、过时主题领域或重构前提示格式的案例应该退役。一个有用的启发：任何基准事实依赖于六个月前的知识或产品状态的案例都应该接受退役审核。
结构化刷新节奏。 与其进行临时更新，不如建立定期评估审查周期。对于大多数团队来说，每月审查可以覆盖大部分衰退风险，而不会成为维护负担。更高速度的领域可能需要双周周期。审查应该回答：（a）上个月生产中出现了哪些评估未覆盖的失败类型，（b）流量的哪些区域评估覆盖率低，以及（c）哪些现有案例已经过时。
时序分布偏移是可预测的：如果你能衡量评估分布偏离实时流量的程度，你就可以预测它何时会达到不可接受的偏差阈值。明确设定该阈值，而不是等待用户投诉来为你定义它。
评估集版本控制。 你的评估集是模型评估管道的依赖项。它应该像代码一样进行版本控制。当你发布模型质量数字时，评估版本应该同时固定。这使得回答以下问题成为可能："质量真的提高了，还是我们只是更新了 评估？"以及"上季度运行的评估对实时流量的覆盖率是多少？"
评估集版本控制还支持回顾性分析。当生产事故发生时，你可以重新运行事故发生时的评估集版本，并与当前评估集进行比较。如果事故时期的评估显示没有退步，这就是评估存在盲点的证据——而不是模型没问题的证据。
不该做什么
一些团队认为能解决评估衰退但实际上不能的模式：
在不使其多样化的情况下扩展评估集。 添加500个与现有案例语义相似的新案例不会改善覆盖率。在添加每批新案例之前，应使用多样性指标来衡量其增量价值。
仅依赖静态案例上的LLM作为评判者的评估。 如果评判提示和评估案例都是静态的，你引入了第二个衰退向量：随着产品的质量定义演变，评判者本身可能会根据过时的标准进行评估。刷新评估案例时也刷新评判者标准。
将A/B测试指标作为评估覆盖率的代理。 A/B测试衡量实时分布的聚合行为信号，但它们是滞后的、嘈杂的，并且不能提供模型在哪里失败的案例级洞察。它们是评估维护的补充，而不是替代品。
将衰退视为模型问题。 "我们的评估没问题，模型行为出乎意料"这种框架几乎总是倒置的。模型在真实流量上运行。评估没有在测量真实流量。从评估是错的这个假设开始。
组织挑战
评估 维护是乏味的。它不会发布功能。它不会改善模型分数。它以标注时间和基础设施的形式产生成本，而不产生明显的输出工件。因此，它几乎普遍地资金不足，直到生产出现问题。
反驳论点很简单：在过时评估集上运行的代价是无法衡量的模型质量投资、数周未被发现的退步，以及本可在预发布阶段捕获的生产事故。评估维护是保险，像大多数保险一样，在你需要它之前看起来很贵。
做得好的团队将评估集新鲜度视为一级质量指标，与模型准确率一起报告。当覆盖热力图显示实时流量中某个区域没有评估覆盖时，该差距会收到一张工单。当生产-评估语义距离超过阈值时，警报会触发。评估集被视为一个活动系统，而不是一个已完成的工件。
不这样做的团队将继续遭遇同样的失败模式：在六个月前就停止代表生产的基准上，充满信心的绿色评估分数。
实际的起点：拿出你当前的评估集，将其与一周的生产查询一起嵌入，并渲染一个覆盖热力图。盲点会立即显而易见。问题在于你是否建立一个流程来弥补它们，还是等待在生产中发现它们。
