你的黄金标签是从你的模型中学到的：通过生产环境泄漏导致的评估集污染

你的评估套件通过了。质量仪表板显示为绿色。一周后，用户正在悄悄流失，没人能解释原因。评估集并没有通过犯错来撒谎——它的谎言在于它是一面镜子。你用来评分的标签，可以追溯到正是由你试图评估的那个模型家族生成或过滤的。通过这项评估并不是质量的证明。它证明了你的模型与其过去的输出是一致的。

这是成熟 LLM 流水线中一种隐蔽的失败模式：通过生产泄漏导致的评估集污染。这不同于著名的基准测试污染（即在 GSM8K 上训练的模型又在 GSM8K 上进行评分）——那个故事已经被讲烂了。更微妙的一种发生在下游。你的黄金标签来自用户反馈、来自先看到模型草稿的人类标注员、来自 RLHF 奖励追踪、来自 LLM-as-judge（模型即评委）的偏好数据。这些流水线中的每一个都将当前模型习语的指纹带回到了你的“基准真值”中。几个季度下来，测试集悄悄地记住了你模型的偏好，评估变成了一个自我表扬的循环。

令人痛苦的部分在于：从外部看，这个循环看起来很健康。覆盖率在增长，评审一致性在提高，分数呈上升趋势。你的仪表板追踪的每一个信号都证实了评估集正在改进。而仪表板看不见的是，改进的方向已经从“用户想要的”转向了“模型学会生成的”。

三种发生泄漏的生产流水线

污染很少通过一条粗管道进入。它通过三条细管道泄漏，每一条单独看起来都是合理的，但共同作用下却具有腐蚀性。

作为标签的用户反馈。 点赞/点踩、重新生成率、对回复的停留时间——产品团队理所当然地挖掘这些信号并将其提升为评估输入。隐藏的假设是“用户认可”意味着“客观正确”。其实不然。用户认可的是符合他们先入为主的观念、措辞方式以及模型训练他们去预期的长度惯例的输出。如果你的模型上个季度趋向于冗长的列表式回答，用户就会适应，他们的点赞现在就会奖励同样的模式。将这些作为标签推广，你的评估集现在就会将“冗长且列表多”编码为正确。一个更简洁、更好的模型得分反而会更低。你会将其解读为退化而不予发布。

看到草稿的人类标注员。 常见的标注 UI 会显示模型的候选回复，并要求标注员进行编辑、接受或排序。这感觉很高效——标注员锚定在草稿上，只纠正明显的错误。这种锚定效应就是污染媒介。关于 RLHF 标注陷阱的研究准确地记录了这一点：如果标注员依赖模型输出作为起点，他们的“黄金”标签就会继承模型特定的表述、结构选择和失败盲点。标签教会模型去生成标注员已经预期会看到的内容，而那正是模型自己的草稿。独立标注——标注员在看到任何模型输出之前先写出答案——既昂贵又缓慢，所以几乎没人能坚持这样做。漂移就是这样开始的。

RLHF 和评审模型工件。 在 RLHF 期间收集的偏好对、奖励模型分数以及 LLM-as-judge 评估都带有生成候选方案的模型的风格偏好。重新使用这些偏好追踪来构建你的评估或奖励塑造，评估集就会变成产生候选方案的策略的反映。奖励模型、策略和评估集之间的交叉污染尤为阴险，因为这三者共享同一个祖先，而这个祖先在普通工程团队会查看的任何地方都没有记录。后续几代模型将根据前一代编写的准则进行评分。

这里的任何一条流水线，单独来看都会引入适度的偏斜。结合在一起并运行一年，它们产生的评估集在统计上与“该模型家族生成的、经过表面正确性过滤的输出”别无二致。

为什么这个循环感觉像是进步

一旦你识破了自我表扬循环的机制，它就变得显而易见。在每一次迭代中：模型生成输出，这些输出中经过过滤的一部分变成标签，标签进入评估，评估被用来决定发布哪些下一代模型。因此，对下一个模型的选择压力就是“匹配上一个模型的过滤输出”。运行几次，偏好漂移就会向一个方向复合增长。

最近关于自我消耗执行循环的研究表明，当训练数据部分源自模型自身的输出时，在增量微调下，非创造性的偏好偏差增长得更快。评估案例是同样的动态，只是运行得更慢、更隐蔽，因为评估是用于发布决策，而不是权重更新。这个循环并不是一次性地训练模型变得更像它自己。它训练的是筛选过程去拒绝任何不像现任模型的东西。

大多数团队首先注意到的症状不是低质量，而是无声的停滞。评估分数可靠地上升，但现实世界的结果指标（任务完成率、用户留存率、投诉率）不再与评估指标的变化相关联。这种脱钩就是烟雾信号。当你的评估变成了一面镜子，提高评估分数需要新模型向旧模型的习语收敛；而提高结果指标则需要相反的做法。你无法同时做到这两点。

第二个症状是来自你家族之外的挑战者模型在你的内部评估中表现得出奇地差，即使它们的公共基准测试数据更好。团队通常将其解释为“我们有更高的标准”或“我们的评估捕捉到了通用基准测试遗漏的东西”。有时确实如此。但更多时候，是你的评估奖励了你现任模型家族特定的措辞和输出形式，而挑战者模型因为用不同的声音提供了有效的答案而受到惩罚。

解决问题的溯源规范

解决方法并非是对标签进行一次神奇的轮换，而是将评估集溯源视为一等工程资产，投入与训练数据集同等的严谨度。有三个实践比任何具体的工具选择都更重要。

为每个标签标注来源元数据。 评估集中的每一项都应该记录其标签的来源：是独立编写的、模型输出的事后人工审核、用户反馈、裁判模型评分，还是合成生成的。为每个标签标记标注方法、它看到的模型版本（如果有）、标注者角色以及日期。没有这些元数据，你就无法审计污染情况，也无法回答那个至关重要的问题：“我们目前的评估集中，有多少比例在标注之前接触过模型的输出？” 对于大多数团队来说，一旦进行诚实的测量，这个比例通常会超过 80%。仅凭这一点通常就足以迫使团队采取行动。

轮换窗口。 像对待安全凭证一样对待评估——旧标签的权威性会衰减，而不仅仅是相关性。限制来自任何单一标注生成周期的评估集份额（例如，来自上一个模型版本部署期间生成的标签不得超过 30%）。即使旧片段看起来仍然有效，也要按节奏淘汰它们。轮换不是为了扔掉好的数据，而是为了确保没有任何单一模型的指纹主导信号。

对抗性重置种子。 定期委托从未见过任何模型输出的独立标注者制作一小部分评估集。为此支付昂贵的费用。保持这一小块比例虽小但起支撑作用：它是你的污染金丝雀。当重置种子部分的得分与主线评估的得分背离时，你就知道主线已经漂移了。当它们保持一致时，你就赢得了在下一个季度继续信任主线的权利。重置种子的数据也可以作为晋升挑战者模型的一个合理的验收标准：它在未受污染的部分是否击败了现有的模型，而不仅仅是在主线部分？

一种更强但不太常见的做法是：具备污染抵御能力的再生，即根据新鲜的、带有日期标记的世界知识而不是冻结的历史答案来重建评估项。这对于大多数团队来说是杀鸡用牛刀，但对于事实会变动的领域——法规、定价、产品状态——这是保持评估有意义的唯一方法。最近关于自动化构建具备污染抵御能力的数据集的工作采取了这种方法，即使你不全面采用，也值得关注。

组织层面的失效模式

如果组织架构与之对抗，那么任何溯源实践都不会起作用。最具预测性的污染信号不是技术性的，而是编写 Prompt 的团队是否同时也编写了对这些 Prompt 进行评分的评估。当他们是同一个团队时，选择压力是无法抗衡的：一个偶然与评估评分方式一致的 Prompt 更改总是会“胜出”，因为评估在设计时就考虑到了该 Prompt 的输出。

在结构上分离 Prompt 编写和评估编写是廉价的，但在文化上很难。 Prompt 团队想要奖励他们直觉的评估；评估团队想要测试 Prompt 团队没想过要优化的东西。这种张力是功能，而不是缺陷。如果没有张力，你就拥有了一个走过场的流程，而你报告的质量就是 Prompt 团队认为本季度质量该有的样子。

对于无法完全分离角色的精简团队，可以使用一个轻量级版本：强制要求标注评估项的人不是编写（或迭代）生成该项的 Prompt 的人，并且标注者要在不同 Prompt 版本之间轮换，这样就不会有任何单一标注者成为单一 Prompt 作者的风格回声室。这虽然不如真正的分离稳健，但比默认的“一个工程师写 Prompt、运行它、查看输出并觉得看起来不错”要好得多。

一个常见且代价昂贵的错误是将这种分离完全委托给“LLM 作为裁判”（LLM-as-judge）系统，理由是“裁判是独立的”。与生成器同族的裁判模型共享大部分风格先验；将其作为质量的仲裁者只是通过不同的管道洗白了同样的污染。裁判模型对规模化有用，对独立性没用。如果你使用它们，请将它们与人工标注的重置种子部分配对进行校准，并将两者之间的背离视为污染警报，而不是一个需要被修补掉的裁判模型 Bug。

下周该关注什么

评估集污染是一种缓慢的失效——它永远不会在凌晨 3 点给你打报警电话。但通过几个具体的检查，可以在一次会议中发现它。首先，审计你当前评估集中有多少项具有来源元数据字段；如果答案是“零”或“我不知道”，那就是你要做的项目。其次，计算你最近六次评估增量与最近六次结果指标增量之间的相关性。如果相关性低于 0.3，说明你已经脱节了，追求评估数值对你的用户没有任何帮助。第三，委托制作一小块独立标注的数据，并针对它运行你最近发布的三个模型。如果排序与你内部评估的排序不同，你就拿到了证据。

需要内化的一点：评估不是测试，而是关于你认为“什么是好的”的压缩陈述。当这个陈述是由你正在评估的模型编写（即使是间接编写）时，评估就不再是外部检查，而变成了反馈放大器。工作重点不是构建一个更聪明的评估，而是保持“什么是好的”的定义权与被评分输出的定义权在结构上分离。搞好流水线和组织架构，评估自然会水到渠成。搞错了它们，再多的评分标准工程也无法阻止镜子里的幻象胜出。