控制面板显示评估者间一致性（Inter-rater agreement）为 0.71。模型团队正在庆祝，因为新提示词的得分比基准高出两分。没人注意到，六个月前，同样的 0.71 是由对评分标准（Rubric）理解完全一致的标注者产生的。而今天，这个数值是由三位标注者产生的，他们对“有帮助”（helpful）的定义存在默契的分歧，而这些分歧恰好在指标上相互抵消。你的评估工具已经分化为一组隐性标准的联盟，而仪表盘上的数字只是他们博弈后的加权平均值。
这就是标注者校准差距（Annotator Calibration Gap）。这是一种失败模式：为了对 LLM 评测器无法可靠处理的案例进行评分而建立的人工评估池，逐渐偏离了团队原本设定的衡量目标。模型并没有变差，是评估工具变差了。由于指标依然呈现为一个整洁的数字，没人会察觉，直到发布出现偏差，事后分析才发现，在过去的两个季度里，“有帮助”对三位不同的标注者意味着三种完全不同的东西。
运行人工评估并不难。难的是保持人工评估计划与产品意图同步，并保持与模型迭代相同的节奏。大多数团队将评分标准视为一次性的培训产物，并将标注者池视为可替换的劳动力。这两个假设都会在几个月内失效。接下来的内容将介绍如何保持评估工具的真实性，以及当这种自律失效时，哪些失败模式会悄悄使评估信号失效。
为什么评分标准会分化
仅仅写在文档里并在入职时阅读一次的评分标准，在接触到真实的生产数据时是无法维持的。前一百次评分是干净的：标注者按照书面标准执行，在 Slack 中询问澄清问题，并趋于一致。到第一千次评分时，每个人都积累了一套私人的边缘案例库——那些模糊的拒绝、技术正确但回避问题的回答、礼貌的错误响应——并且开始根据个人直觉而非评分标准来解决这些问题。这些直觉在个人内部是相关的，但在人与人之间是不相关的。每个标注者变得内部一致，但外部发散。
你可以通过自我一致性检查来检测这一点：将同一个案例间隔四周分别交给同一个标注者进行评分，并对比结果。内化了评分标准的稳定标注者，与其过去自我的契合度大约在 0.85 或更高。而私人直觉发生漂移的标注者，与其过去自我的契合度大约只有 0.6，这个差距的大小正是你在仪表盘上即将面对的标准分化程度。
分化也源于默许的标准澄清。一个新的边缘案例出现在队列中，一位资深标注者在团队聊天中给出了回答，这种解释被那个星期在线的人吸收了。现在，实践中的评分标准就是页面上的标准加上未成文的多年 Slack 讨论记录。六个月后，一名新标注者加入，阅读了页面文档，产出的评分看起来像噪声，但实际上是对原始标准的忠实解读。团队的直觉是新标注者错了。事实是，评分标准已经产生了分支且从未合并。
这就是为什么你会看到 Krippendorff's alpha 值在 0.6–0.7 范围内，这在纸面上看起来可以接受，但却掩盖了在关键案例上的灾难性分歧。Alpha 是一个全局平均值。而决定你的发布是否应该上线的案例——即处于可接受行为边界的模糊案例——恰恰是标注者分歧最大的地方，也正是对整个标注池进行平均会产生无意义数字的地方。
锚点案例：将评分标准转化为可运行的测试
最高杠杆的干预措施是维护一套小规模、固定的锚点案例（Anchor Cases），每位标注者都会定期（通常是每月）对其进行评分。20 到 50 个示例就足够了。这套案例经过精心挑选，覆盖了评分标准的完整决策面：明确的正例、明确的负例，以及刻意集中的、历史上导致分歧的边界案例。每个锚点案例都有一个由校准负责人维护的规范标签（Canonical Label）。
锚点案例有三个功能。它们为每位标注者提供了一个私人信号，表明他们是否偏离了评分标准。它们为校准负责人提供了每位标注者的漂移轨迹，从而在生产信号退化之前识别出谁需要重新培训。此外，它们还让团队能够检测到评分标准本身已经过时：当多个标注者同时觉得规范标签不对时，评分标准就需要真正的修订，而不是在 Slack 里简单解释。
这种做法的一个变体在数据标注中已经是标准做法，即黄金集植入（Gold-set Seeding），将已知答案的项目混入实时队列。Agentic-eval 版本的区别在于两点：首先，黄金案例不是隐藏的——标注者知道哪些是锚点案例，因为目标是校准，而不是监视。其次，规范标签不是一成不变的；它们每季度复核一次，变更被视为标准版本更新事件，而不是标签纠错。如果某个锚点案例的规范标签发生了变化，那么在旧版本下计算的所有指标都应与当前对比进行隔离。
盲审交叉评分：让分歧显性化
流程的另一半是盲审交叉评分 (blind cross-rating)：固定比例的生产环境数据——通常为 5% 到 10%——由两名评分员独立评分，他们看不到彼此的标签。产生的差异进入校准队列，由高级评分员每周进行审查。审查员并不是在判定哪个评分员是正确的；他们是在判定这种分歧揭示了评分准则（rubric）的哪些问题。
大多数分歧可以归入以下三类之一。第一类是追踪数据中真实的歧义，这意味着该案例应该成为锚点案例或触发评分准则的澄清。第二类是某位评分员的误读，这意味着需要进行个人反馈。或者——也是最有用的——第三类是评分准则的缺失，即准则没有预见到这种情况，导致两位评分员都做出了合情合理但互不兼容的判断。评分准则缺失是这一流程中价值最高的发现，因为它们是导致评估分化的隐形源头。当你识别出一个缺失时，你需要编写新的标准，对评分准则进行版本化，并根据新版本对相关的历史追踪数据进行重新评分。
将分歧视为信号而非噪声，是大多数团队尚未完成的认知转换。默认的反应是计算 Cohen's kappa 或 Krippendorff's alpha，看到一个数字，然后要么庆祝，要么惊慌。而专业的做法是观察哪些案例导致了分歧，以及这种分歧反映了评估工具的什么问题。如果一个样本池的 alpha 值为 0.65，但分歧集中在已知的边界类别上，这比 alpha 值为 0.80 但分歧随机散布在各类案例中的样本池更健康——前者是一个具有已知局限性的测量工具，而后者是一个你无法描述其失效方式的工具。
评分准则版本化：作为发布产物
人工评估中最昂贵的 bug 是在实验中途由于评分准则的澄清而悄然改变了评估信号。团队正在基准提示词和候选提示词之间进行 A/B 测试。一位高级评分员在 Slack 上发了一条澄清：“对于模糊的拒绝，即便没有字面回答，也要优先选择那些能满足用户潜在目标的回答。”一半的评分员看到了这条消息并更新了他们的行为，而另一半没有。在接下来的两周里，候选提示词的分数慢慢攀升。发布决策：通过。事后分析：候选提示词并没有更好；只是评分准则在一类候选提示词刚好处理得略有不同的案例上收紧了，分数的提升来自于评估工具的移动，而不是模型。
解决方法是将评分准则视同模型和提示词一样：作为一个版本化的发布产物。每一次修改——即使是“澄清”——都要升级版本号。追踪数据存储中的每一次评分都带有生成它时所依据的评分准则版本。跨版本的指标比较在层面上是被禁止的，除非有人明确选择加入并确认其影响。评分员培训是迁移步骤：当评分准则版本变更时，评分员要重新参加锚点案例测试，在他们重新通过测试之前生成的评分会被标记为过渡状态。
这听起来像是额外的开销，直到你因为这类隐性迁移而损失一个季度的工作。一旦你经历过，这听起来就像是最便宜的保险。Vertex AI 的托管评分指标已经在内部对其标准进行了版本化，原因正是如此——一旦评分准则在没有版本升级的情况下发生变异，评分员培训与下游指标之间的契约就会瞬间破裂。
真正重要的指标
如果你只能带一个人工评估程序的数字去参加领导层评审，不要带评分员间的一致性。带上与锚点案例标准答案的一致性 (agreement-with-canonical-on-anchor-cases)，并按评分员细分，附带趋势线。评分员间的 alpha 值告诉你评分员是否彼此一致，这是必要但不充分的。他们可能会在错误的评分准则上达成一致。与标准锚点的一致性告诉你，他们是否正在向团队预期的评分准则收敛，这才是真正的契约。
这两个数字的背离具有启发性。高评分员间 alpha 值加上低标准一致性，意味着评分员群体已经分化成一种与产品意图不符的内部语言——一群紧密的羊群正走向错误的方向。低 alpha 值加上高标准一致性，意味着评分员个人是准确的，但对边缘案例的理解不同——这通常意味着评分准则存在你尚未编写的空白。两者都高意味着评估程序是健康的。两者都低意味着你拥有的不是测量工具，而是一个来源不明的标签生成流水线，你在其上运行的任何 A/B 测试都只是装点门面。
更深层次的认识是，人工评估是一种测量工具，而工具需要按照与其测量的系统相同的节奏进行校准。当模型每周都在迭代，而评分准则只是在进行临时澄清时，你的评估工具的漂移速度比它要测量的对象还要快。你通常可以通过向任何人工评估程序提一个问题来发现这一点：上一次评分准则版本化是什么时候？上一次每个评分员重新参加锚点案例测试是什么时候？如果答案是“我们并不真的那样做”，那么仪表盘上的指标意义就比它们看上去要小，而你根据这些指标所决定的发布，其实是在根据噪声做决策。
下个季度前需要部署的工作
如果你有一个人工评估项目，且尚未遇到分歧悬崖（bifurcation cliff），你早晚会遇到的。按优先级排列的干预措施包括：每月对固化的锚点案例库进行评分，并追踪每位评估者的漂移情况；对 5% 到 10% 的生产环境 Trace 进行盲审交叉评分，并开展每周分歧评审；将评分标准（rubric）版本化并同步至 Trace 存储库；以及在仪表盘上设置一个指标，报告每位评估者在锚点案例上与标准答案的一致性，这应当与评估者间信度（inter-rater alpha）并列显示（而非取而代之）。这些都不是什么新颖的研究。但这一切决定了一个人工评估项目是能产生可靠的发布信号，还是产生一个被自信地测错的数字。
在建立人工评估池后，直觉往往是关注评估者的吞吐量、队列延迟和单个标签的成本。这些固然重要，但它们无法保护你免受“评估工具悄然失效”这种故障的影响。保持评估者校准的工作，就是保持评估信号真实性的工作。跳过这一步，一年后你就会阅读到一篇复盘报告，开头写着：“我们曾深信那个指标，但该指标在过去六个月里衡量的其实是别的东西。”
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
