标注偏移：评估集如何逐渐无法衡量你交付的产品

上个季度评分 92% 的评估集（eval set）现在评分达到了 94%，团队称之为进步。事实并非如此。该评估集中的标签是根据标注员脑海中早已模糊的准则（rubric）编写的。模型评分所针对的产品已经发生了变化。标准已经发生了变化。标注员自身的校准（calibration）也发生了变化。表面上 2% 的提升，实则是静态产物与动态产品之间无声的差距，且只要团队不更新，这种差距每周都会扩大。

标注漂移（Annotation drift）是成熟 LLM 评估方案中一种隐蔽的失效模式。它不会表现为回归（regression）——回归是简单的情况，因为数值会下降，从而触发人员调查。它表现为一个持续显示绿色的数字，而其原本衡量的内容在底层已经腐烂。已经建立了评估集、编写了准则并招募了标注员的团队面临的风险最大，因为他们信任自己构建的系统，从而停止了对基础的审计。

你脑海中的准则并非纸面上的准则

准则是一种书面产物。标注员实际应用的准则是一个模糊的后验分布，它基于他们看过的示例、与负责人的交流、他们裁定的边缘案例，以及他们对产品预期功能的潜移默化的偏好。这两套准则起初是一致的，随后便产生分歧——这不是因为谁做错了什么，而是因为每周标注员都会看到书面准则未曾预料到的新失效模式，并对此做出判断。下一周，他们会对类似案例做出略有不同的判断，因为对第一次决策的记忆已经衰退。到了第三个月，两个标注员看同一个案例会产生分歧，且谁也无法根据书面准则说清原因——他们会根据记住的案例来解释决策，而不是遵循的规则。

从业者称之为“准则漂移”（rubric drift），这在评分者间一致性（inter-rater reliability）指标中表现得最明显。Cohen's kappa 和 Krippendorff's alpha 是标准工具——它们衡量在排除偶然性后，两个标注员达成一致的频率。生产级数据集的一致性目标通常在 0.7 以上，低于这个数值，你就没有准则，而是两个同名的不同准则。需要关注的不是绝对一致性数值，而是斜率。如果一个方案在 1 月份的一致性是 0.82，到 4 月份变成了 0.71，这并不意味着标注水平下降了，而是标注员之间产生了漂移，且由于没人重新衡量而未被察觉。

解决办法是程序化的：建立一种校准仪式，让两个标注员独立对同一组案例样本进行评分，将分歧带到会议上讨论，每一个源于书面准则歧义的分歧都转化为对准则的修订。准则变成了一个版本化的产物——比如代码库中的 rubric_v3.7.md，并附带变更日志。每个评估结果都打上评分时所依据的准则版本标签。当有人问“这个评估结果与上季度相比有可比性吗”时，答案是版本差异（diff），而不是猜测。

产品在变，评估没变

标注漂移的另一半来自相反的方向：标签是稳定的，但被标注的对象发生了变化。评估集是在产品处理 5 种意图时组建的。现在产品可以处理 11 种。用户预期是根据一个响应需要 30 秒的智能体来校准的；而新的智能体以流式方式在 8 秒内响应，用户现在将其与不同的心理基准进行对比。评估集中的“好”标签在 10 月份意味着特定的含义，而到了 5 月份，即使没人修改准则，其含义也已经不同了。

这就是概念漂移（concept drift），是详尽记录的模型端概念漂移问题的评估集版本。行业报告中反复出现的 HR 聊天机器人示例极具启发性：一个聊天机器人通过了涵盖标准工资问题的离线评估集 99% 的测试，公司在周一推出了新的股权计划，到了周二，生产环境的流量就被归权计划（vesting-schedule）问题所主导，而这些问题在评估集中根本不存在。评估得分仍然是 99%。产品在生产环境中却失败了。这种脱节源于评估集未能追踪产品的能力边界。

解决这一问题的原则是滚动更新。评估集的一定比例——比如每季度 10%–20%——被淘汰并替换为从近期生产轨迹中提取的新案例。淘汰的案例进入存档，而不是丢进垃圾桶，因为你可能想问“我们在旧分布上的表现变差了吗”，而这个问题需要保留旧数据集的可读性。新案例根据当前准则进行标注，每当发布新功能时，都要重新检查准则本身。评估集变成了一种具有已知半衰期的折旧资产，就像训练数据、文档以及任何绑定到动态产品的产物一样。

两种失败模式的叠加

最危险的情况是两种漂移同时发生，因为它们会互相掩盖。如果只有评分准则（rubric）发生漂移，评估得分就会变得更加嘈杂——标注员意见不一、一致性指标下降，随后会有人介入调查。如果只有产品发生漂移，评估就会开始遗漏重要的能力——生产事故会暴露评估未能捕捉到的故障，随后也会有人介入调查。但当两者同时漂移时，评估得分会保持异常稳定。标注员在没有书面记录的情况下，针对产品的新行为重新进行了自我校准，纸面上的评分准则不再符合标注员的实际操作，而仪表盘上的得分衡量的是发生漂移的标注员与发生漂移的产品之间一种未经记录的默契。一切看起来都很健康，实则不然。

这在评估程序中相当于一支水银柱已经断裂的温度计。读数很稳定，但温度计已经坏了。你只有在与另一支温度计进行对比时才会发现问题——在评估语境下，这意味着当一名新标注员加入时，他们的评分与现有团队产生巨大分歧；或者当利益相关者审查样本案例时，询问为什么一个在他们看来显然很糟糕的结果会被判定为“好”。到那时，团队已经根据一个损坏的仪器做了数月的决策，而本能的反应（重新培训新标注员以匹配现有团队）恰恰是错误的——因为现有团队才是漂移的源头。

防御性的做法是维护一个标签永不变动的案例“锚点集（anchor set）”。这些是团队经过详尽讨论、评分准则应用明确无误的案例，任何分歧都是评分准则或标注员发生漂移的信号。每个批次、每个标注员都要对锚点集进行评分，与标准标签的一致性就是校准指标。当一致性下降时，团队就得到了一个明确的信号——这比生产事故早，也比愤怒的利益相关者早——表明测量系统需要维护了。

没人预算的组织成本

修复标注漂移最难的部分在于，这项工作在结构上是缺乏资金支持的。评估集是在项目期间构建的。构建是一个带有交付物的预算条目，而维护则不是。标注员的人力编制是针对构建阶段而申请的；一旦构建完成，负责评估的团队就必须永远保留一部分标注员时间，而这部分分配在每个季度的规划讨论中都会与下一个项目的构建产生竞争。维护总是输家，因为维护不会交付任何可见的东西。当团队意识到评估已经腐烂时，刷新它所需的预算已经超过了维护它所需的预算，而此时与领导层的对话变成了“为什么这个坏了”，而不是“让我们继续资助它”。

一种有效的重新构思是将评估集视为具有折旧性的基础设施，而不是一次性资产。云基础设施有维护预算，文档也有维护预算，评估集也不例外。一个合理的起点是每年预算原始构建成本的 10–15% 作为维护费用——包括定期的标注工时、定期的评分准则修订周期以及定期的刷新批次。这个数字只是粗略估计，应该根据团队随时间变化的漂移指标进行校准，但原则是不可动摇的：一个未经维护的评估集的有效寿命大约只有一年，预算零维护就是预算在与时间赛跑。

领导层的诉求与工程诉求不同。工程侧想要工具——评分准则版本控制、标注者间一致性仪表盘、锚点集、刷新工具。领导层想要一份契约：一份书面协议，承诺评估程序每季度报告漂移指标，评分准则具有版本，且评估集有记录在案的刷新频率。契约是在团队人员流动中幸存下来的保障。没有契约的工具会被下一任经理降低优先级，而没有工具的契约只是演戏。两者缺一不可。

构建顺序

如果一个团队现在拥有评估集但没有针对标注漂移的防御措施，成本最低的第一步是测量。抽取最近的一个批次，让两名标注员对相同的一百个案例进行重新评分。计算一致性，并将其与构建时的任何基线进行比较。如果数字下降了，这就是表面证据。然后抽取十几个存在分歧的案例并共同阅读——一旦两名标注员看着同一个案例并意识到他们脑子里的答案不同，漂移的源头通常就显而易见了。

第二步是为评分准则设置版本。目前存在的任何评分准则都成为 v1.0。此后的每一次更改都会提升版本。每一个评估结果都要打上标签。这是一个只需一天的工程项目，在有人第一次问“这与上季度有可比性吗”时，它就能回本。

第三步是建立锚点集。抽出二十个团队达成共识的案例，锁定标签，每个批次都进行评分。与锚点一致性的指标就是预警系统。

第四步是确定刷新频率。设定一个季度日期。淘汰 10–20% 的旧集合，用生产环境追踪的样本替换，根据当前的评分准则进行标注，并跟踪一致性。

这些举措都不是什么深奥的技术。如果团队将评估集视为测量基础设施而非交付物，他们自然会设计出这些东西。它们之所以没被建立，是因为它们所防止的失败模式是无声的，而无声的失败在结构上很难获得资金支持。那些无论如何都要资助它们的团队，其评估得分在一年后依然具有意义。

对工程师来说，结论很简单：评估集不等于评分准则。评分准则不等于标注。标注不等于产品。这个链条中的每一个环节都会发生漂移，如果不考虑漂移，测量系统最终报告的数字将失去任何意义。工作重点不在于防止漂移——漂移是系统的属性，而不是一个 bug。工作的重点是对其进行监测，以便在数字失去意义的那天，是图表变红，而不是利益相关者偶然发现。