黄金数据集衰减问题：当你的评估集成为负担时

大多数团队将他们的黄金评估集（golden eval set）视为宪法——持久、权威且变动成本极高。他们花数周时间挑选案例，请领域专家进行标注，并将其接入 CI。然后，他们就转去忙别的事了。

六个月后，评估套件显示通过率为 87%，但用户却在抱怨输出结果支离破碎。评估指标并没有倒退——它们只是腐化了。该数据集测量的仍然是 10 月份重要的数据。它只是不再测量现在重要的数据。

这就是黄金数据集腐化问题（golden dataset decay problem），它比大多数团队愿意承认的更为普遍。

腐化是如何发生的（在无人察觉的情况下）

评估集不会剧烈地失效。它们通过三个重叠的机制悄无声息地侵蚀。

提示词泄漏（Prompt leakage） 是最隐蔽的一种。每当你使用评估案例来调试失败——调整提示词、修改系统消息、优化检索参数时——你都在含蓄地针对该案例进行优化。没有人打算对评估集进行过拟合。但当一个团队在六个月内反复迭代同一组 200 个案例的黄金集时，这些案例就不再是盲测案例了。提示词是围绕它们塑造的，模型配置也是针对它们调优的。在某种程度上，你的评估测量的其实是你对自己测试套件的背诵程度。

精选组合（Cherry-picked composition） 随着时间的推移加剧了这一问题。当工程师向评估集中添加新案例时，通常会抓取一个代表近期失败的案例。这很合理。但“代表近期失败”会倾向于那些团队已经很好理解的案例——即符合当前系统应有表现心理模型的案例。而那些真正困难的长尾案例、专家也存在分歧的模糊查询、生产环境中出现但不符合任何已知模式的输入——这些很少能进入黄金集，因为它们难以标注且难以达成共识。

标注模式僵化（Label schema ossification） 是第三种机制。当你构建评估集时，你根据当时对任务的理解定义了什么是“正确”。你的标注指南写道：好的回答要简洁、引用来源并回答字面上的问题。一年后，你的用户希望系统在回答前先询问澄清性问题，因为你发现字面解释会导致昂贵的错误。但标注模式没有跟上。你的评估仍然在奖励旧的行为。你的通过率看起来不错，因为系统正在完全按照旧的准则行事。

这些机制共同创造了一个数据集，它测量的是你已经解决的分布，而不是你的系统今天所面临的分布。

检测漂移

第一个挑战是识别你的评估集何时偏离了生产环境。有几个信号可以可靠地反映这一点。

分数天花板蠕变（Score ceiling creep） 是最早的预警。当你的通过率稳步攀升至 90% 以上，但用户结果或生产指标没有任何相应改善时，你可能已经使评估集饱和了。基准测试不再能区分是你的系统变好了，还是你的团队变得更擅长应对评估了。公共基准测试也呈现出同样的模式——前沿模型现在在 HumanEval 和 GSM8K 上的表现超过了 90%，这就是为什么这些基准测试在比较顶尖系统时已不再有用。

嵌入分布差异（Embedding distribution divergence） 则更为严谨。将你的黄金评估案例进行嵌入，并对近期生产查询的随机样本进行嵌入。计算 Jensen-Shannon 散度或直接绘制聚类图。如果两个分布发生了显著偏离——如果生产查询形成的聚类在你的黄金集中没有体现——那么你的评估测试的就是错误的输入。这项检查可以作为监控流水线的一部分自动化运行，每周针对滚动生产样本进行。

裁判校准漂移（Judge calibration drift） 适用于使用 LLM-as-judge 评分的情况。定期从评估集中抽取 50 个案例，请领域专家手动重新评分。将其与 LLM 裁判的分数进行比较。如果一致性降至 80% 以下，要么是你的裁判发生了漂移（通常由裁判模型的更新引起），要么是嵌入在裁判提示词中的评分标准不再符合专家的直觉。无论哪种情况，你都需要重新校准。

失败模式覆盖缺口（Failure mode coverage gaps） 是最具操作性的信号。当工程师调查生产环境中的失败时，他们应该按根本原因标记每个失败。跟踪每种根本原因类型在评估集中是否有代表。如果某一类失败在生产中反复出现，但在评估中覆盖率为零，那么你的黄金集就存在系统性的盲点。这通常表明失败发生在长尾部分——这些案例在你构建评估集时感觉太像边缘案例，没被添加进去。

保持评估集的真实性

目标并不是每季度重建一次评估集。那太昂贵且会破坏连续性。目标是维护一个能够优雅降级的数据集——你可以识别陈旧性、轮换新案例并在不从头开始的情况下进行去污染。

过期标记（Expiry tagging） 是成本最低的干预措施。当你向黄金集添加案例时，为其标记创建日期和过期日期——通常为 90 天。在过期前，审核员会重新验证该案例：在当前的标注指南下，标签是否仍然正确？这个案例是否仍具有生产场景的代表性？未通过重新验证的案例将被更新或停用。这不能消除所有的腐化，但它强制了与数据集的定期接触，而不是任其石化。

生产采样流水线（Production sampling pipelines） 从源头上解决了精选问题。与其等待工程师手动添加案例，不如构建一个流水线，定期从生产流量中提取随机样本，通过你的 LLM 裁判运行它们，并标记裁判自身意见不一的情况（置信度低、重复运行时评分不一）。这些高不确定性的生产案例是评估集中最有价值的补充——它们代表了你当前系统无法干净处理的案例，且它们来自实际分布，而非团队的心理模型。

污染检查（Contamination checks） 防止提示词泄漏破坏评分。在每次重大的提示词更改之前，运行一次重叠检查：计算修改后的提示词与评估集中每个案例之间的嵌入相似度。高相似度分数的案例应标记为待审核，因为它们可能是你的提示词曾隐性针对其进行优化的案例。这种检查的一种更严格的版本是“补全测试”——要求模型补全评估查询的开头。如果它能准确补全，该案例可能已经泄漏到了微调数据或提示词构建中。

版本化的评估拆分（Versioned eval splits） 借鉴了传统机器学习的做法。维护一个你永远不会为了迭代而触碰的固定预留集（holdout split）——仅用于最终评估。在日常开发中使用一个轮换池。定期将生产采样中的案例提升到轮换池中，并按预定节奏从轮换池中刷新预留集。这镜像了训练/验证/测试的纪律，并将其应用于评估集管理而非模型训练。

监控触发机制

与其按照固定时间表运行评估集（eval set）维护，不如根据特定触发条件运行，这样更可靠。定期维护往往容易被降低优先级，而基于触发器的维护则在真正关键的时刻发生。

当以下任一情况发生时，请重新构建或大幅轮换你的评估集：

• 你的系统提示词（system prompt）、模型或主要检索配置发生了变化。这些是转折点，此时旧的评估集衡量的是一个已不复存在的系统。
• 生产环境失败率上升超过 10-15%，而你的评估通过率没有相应变化。这两个数字之间的差距是一个信号，表明你的评估已不再能追踪用户的真实体验。
• 黄金数据集（golden set）与近期生产流量之间的嵌入偏移（embedding divergence）超过了你在评估处于健康状态时设定的阈值。该基准为你提供了一个参考点，用于区分正常的漂移和令人担忧的偏移。
• 你的团队发布了一个开启了新查询界面或涉及新用户画像（user persona）的功能。新的用户群体会带来不同的输入分布，你现有的黄金数据集将无法覆盖它们。

每个触发器都应启动一个结构化的响应：采样生产数据、检查覆盖范围缺口、淘汰过时示例、添加新示例、重新运行校准。这个过程通常只需要几天，而不是几周。

实践中的具体操作

一个适用于中等规模团队的实用评估维护系统如下：

一个包含 200-400 个示例的核心黄金数据集，并标记了创建日期和过期标识。一个每日运行的生产采样作业，随机抽取 50 条查询，使用 LLM 评判员（judge）评分，并将不确定的案例写入审核队列。一个每周运行的脚本，检查黄金数据集与上周生产样本之间的嵌入偏移，如果偏移超过阈值则发出警报。一个每月一次的评审会议，由两名工程师花费两小时处理审核队列——淘汰过期示例、晋升（promote）高价值生产示例，并更新标注指南以反映任何 Schema 变更。

这四个轻量化流程结合在一起，可以防止由于“隐性腐烂”将有价值的评估套件变成一种合规演戏（compliance theater）。

底层原理

根本问题在于评估集被视为基础设施，而不是“活的”制品（living artifacts）。基础设施是一次性构建并被动维护的，而活的制品需要主动管理——定期关注它们是否仍然代表它们声称代表的内容。

九个月前精心构建的黄金数据集，默认情况下现在已经不再是一个好的黄金数据集。它记录了你的团队在九个月前对问题的理解。它是否仍然有用，取决于从那时起问题、用户和系统发生了多大变化。

大多数团队只有在生产环境告急，而评估套件却亮起绿灯时才会发现这一点。到那时，评估现实与生产现实之间的差距已经拉大了好几个月。解决办法不仅仅是添加更多示例，而是建立节奏和工具，从源头上防止差距产生。

评估债务（Eval debt）会悄无声息地产生复利。那些能够领先的团队，是将“这个评估是否仍在衡量我们认为它衡量的东西？”视为一个需要严谨回答的工程问题，而不是一个耸耸肩就能回答的修辞性问题。