评判器校准与元评测

元评测坍缩模式。

元评测坍缩指的是这样一种情况：你用来给其他模型输出打分的评判器自身发生了漂移，而榜单还在产出貌似合理的数字，可底层信号已经与"任何人类眼里的质量"脱钩。这种失败有一种典型形状。第一天，你把评判器指向一份评分标准，用一份小规模的人标集校准；一致率落在 88–92% 区间，你把管线上线，接下来几周评测分数与投诉箱里的坊间抱怨吻合。然后评判器模型被悄悄更新（厂商推了新快照、宿主换了路由、或者你自己的 prompt 在工程师改动中渐渐漂了），打分分布挪了几个点。什么警报都不响，因为你在评的只是"被测系统"，不是评判器本身。一个月后，评测分数涨了三分，客服工单翻了一倍。评测一直在跑。它只是没在测任何真实的东西。

这种模式在"生产流量上滚动的七天窗口"里最容易看到。每天取同样的 500 条轨迹、用当前评判器打分，画分数直方图。健康管线里，直方图每周会有些许晃动，但均值与形状是稳定的。坍缩管线里，均值单调漂移——评判器谄媚化时始终朝上，评判器挑刺时朝下——而人类投诉率朝相反方向走。经典评测文献（见 evals-101 概念）把这称作"测试集污染"，当作一次性卫生问题处理。在 LLM-as-judge 场景里这不是卫生问题，而是"活系统问题"，因为评判器自己也是一个行为会变的模型。

另一个值得点名的症状是从业者开始叫做"位置坍缩"的东西：让评判器比较两个候选输出 A 和 B，它在人类金标上的准确率跌到接近 50%，而自一致性（同一对、同一 prompt、不同次运行）仍然很高。评判器不再区分质量，而是开始区分某些偶然因素——长度、格式、首位置偏差——自一致性检查看不到这些。LLM-as-judge 运维文把这当作实现注脚处理；到 2026 年，它已是一级警报。

85–90% 一致底线。

业内收敛下来的数字是"LLM 评判器与人类金标 85–90% 一致"，而人们最初会伸手去够的数字（95% 以上）之所以错，理由值得内化。人类标注员之间在同一批任务上的一致率本身就在 88–93% 区间。如果你把评判器调到与某个单一标注员 96% 一致，你几乎必然把评判器过拟合到了那个标注员的特异性——同一批"两位人类会意见不一"的样本上，评判器现在会与其中一位吻合而与另一位不一致。评判器不是"比人更好"，而是"与某一个人更一致"，这是当你无法把那位特定人类派上生产时的错误优化目标。

底线是 85%（不是 80%）也很关键，理由相反。低于 85%，评判器与金标实质分歧太频繁，以至于评判器给两个系统打出 3 分之差时，这 3 分差已经小于评判器自身的噪声底；你没法用分数排序。高于 90%，你几乎总是在把边际校准成本花在"标注员特异性问题"上，而不是真实质量信号上。85% 与 90% 之间，就是那条评分可信到"给真实差距超过几分的两个系统排序"、又不会被信到"给差距在噪声内的两个系统排序"的工作区间。"带噪声的排序"正是一份生产评测分数真正擅长的事，而 85–90% 是它保持擅长的区间。

两条实践推论。第一，要跟踪的一致率指标应是 Cohen's kappa 或类别均衡准确率，而不是原始准确率，因为大多数评测评分标准是不均衡的（"通过"类是绝对多数）。第二，金标集必须包含"分歧样本"——两位标注员正当地不一致的那些——因为这些恰恰是评判器要被评的样本。只由"三位人类都同意"的样本构成的金标集，会接受一个带隐性位置偏差的评判器。

建立金标集。

金标集是整套纪律的承重件，中位数团队在这上面投入得远远不够。经验上奏效的规模是"每个评分维度 100–300 条样本"。低于 100，评判器-金标一致率的置信区间宽到能藏下整整一个点的漂移；高于 300，边际的标注员工时在校准侧几乎买不到东西，把这份工时投到"评分标准质量"上更划算。从生产轨迹里采样，按你已知的失败模式（短回答、工具错误恢复、拒答、越狱尝试）与"你还不知道的"（一份从日志尾部均匀采样的随机切片）做分层。不要只从失败样本里采——只由失败构成的金标集无法察觉"学会永远预测失败"的评判器。

每条至少两位人类打标，用第三位或"书面裁决规则"处理分歧。跟踪金标集自身的标注员间一致率；那个数字就是任何 LLM 评判器针对本金标集所能达到的上限。把这个上限与每一份评判器分数一起在内部公示，因为工程师否则会去追"超过人类上限"的一致数字，把随之而来的过拟合当作进步。RAG 评测一文就检索金标集讲了同样的话；记忆评测就记忆专用探针讲了同样的话。跨表面同一模式：金标集是"人人都知道该投入却少有人真投入"的东西，直到评判器在他们身上坍缩。

给金标集打版本。每条样本有 ID、每一条标签的标注员 ID、标注时间戳，以及一个指向"评分标准版本"的指针。当评分标准变化时（它一定会变），你要"重标受影响样本"而不是"迁移分数"。当生产分布变化时（新功能、新客户段），你要"扩展金标集"而不是"重新解释旧标签"。没有版本历史的金标集，就是一份会悄悄腐坏的金标集。

月度重校准节奏。

重校准是一件"排期事件"，不是"事故响应"。经生产验证站得住的节奏是月度，加上"分数漂移报警"触发的紧急重校准通道（见 STEP 5）。月度足够短，能在厂商侧模型更新与缓慢的 prompt 漂移滚成大问题之前抓到；月度足够长，让每年的标注员成本（大致十二轮、每轮 100–300 条）留在一位专职评测员的预算内。周度重校准听着勤奋，成本却是四倍，且很少能查到月度节奏加漂移报警查不到的问题。

一次重校准实际动到的东西比多数团队预期的要少。你不重标整份金标集；你用当前评判器"重打分"，然后重新计算一致率指标。若一致率在工作区间内，评判器通过，本月的校准记录就是一行条目。若一致率跌破底线，你就诊断（prompt 漂移、模型漂移、分布漂移、金标集腐坏），并在三种动作里选一种：调评判器 prompt、回滚到已固化的评判器模型、扩展金标集。重校准期间不动评分标准——评分标准变更是另一件更低频的事件，会触发自己的金标集重标。

每次重校准的产出是一份签名的校准记录：评判器模型+版本、评判器 prompt 哈希、金标集版本、一致率指标、通过/未通过。把记录留着；下一次有人问"功能 X 的评测分数是从什么时候开始真的有意义、又是从什么时候开始不再有意义"的时候你会想要它。没有校准历史的管线答不了这个问题，而诚实的答案——"我们不知道数字从哪天起不再是真的"——是多数跳过这一步的团队的落点。

报警与回滚。

值得电话报警的两条告警。第一条是"一致率跌破底线"：滚动七天的评判器-金标一致率低于 85%，管线进入"分数不可信"状态，阻断任何"评测把关"的部署。第二条是"分数-投诉背离"：评测分数趋势与用户投诉趋势在滚动 14 天窗口里的差异超过某阈值，无论朝哪个方向。第一条抓典型的评判器模型回归；第二条抓元评测坍缩——评判器与金标集一起漂了、内一致性检查已经查不出来的情形。

回滚纪律是多数团队第一次警报响起时匆忙拍板的设计决策。请提前定好。回滚目标是一份已固化的评判器配置——模型版本、prompt、评分标准、金标集版本——它是上一次通过校准时的"已知良好"版本。回滚评判器不回滚被测系统；你继续发产品，你只是不再让评测把关做发布决策，直到校准恢复。这里最常见的错误是把评判器告警当作被测系统告警，冻结产品部署直到评测修好，结果是训练团队"关警报"而不是"修评判器"。

judge_calibration:
  gold_set:
    id: gold-set-v7
    size: 240
    dimensions: [factuality, task_success, refusal_appropriateness]
  judge:
    model: prometheus-2-8x7b
    prompt_hash: sha256:9f4a...
  agreement_floor: 0.85
  alarms:
    - name: agreement_below_floor
      window: 7d
      metric: cohens_kappa
      threshold: < 0.85
      action: page + block_eval_gate
    - name: score_vs_complaints_divergence
      window: 14d
      metric: abs(score_trend - inv(complaint_trend))
      threshold: > 0.15
      action: page + open_recalibration
  recalibration_cadence: monthly
  pinned_rollback: judge-config-v6

上面这份看板配置写的是"你想在监控栈里出现的形状"，不是具体某个工具。要紧的是：两条告警都提前定义、都各有固化的回滚目标、都各有负责人。实践中，评判器校准的负责人不应与被测系统的负责人是同一个人；同一个人的路线图仰赖分数上涨时，把评判器告警解释成"只是噪声"的动机太大。

工具：Prometheus 2、JudgeBench、RubricEval。

三个开源工具已成为这套纪律的实践支柱。Prometheus 2 是一族经过微调、专为"产出带解释的校准过评分标准分数"训练的评判模型（7B 与 8x7B）；它的价值不在"原始准确率上胜过 GPT-4 级评判器"，而在"打分分布在模型更新之间是稳定的（因为由你自持）、且每次判分的成本比前沿模型评判器低一到两个数量级"。用它跑高流量生产评测——前沿模型评判器一周就会烧光评测预算的那种。

JudgeBench 是一份"给评判器用的基准"——一份精选的偏好对，"正确"的偏好已知，用来度量评判器的原始判别能力。当你选评判器模型、或者重校准发现无法解释的一致率下滑时跑 JudgeBench，把"评判器变笨了"和"金标集漂了"区分开。RubricEval 是缺失的那块补丁：一份面向"按显式评分标准打分并按维度分解"的开放评测框架，让评判器每一维的分数可被审视，而不是被折叠成一个数字。

认真跑这套栈的团队常见的模式是"双评判器管线"：便宜的 Prometheus 2 评判器给每条生产轨迹打分，供滚动漂移看板用；更贵的前沿模型评判器只给分层采样（比如 5–10% 的轨迹）打分，供重校准与金标集扩展管线用。便宜那一位是你会电话报警的对象；贵那一位是你诊断时用的对象。二者都不是你发产品的依据——那份依据是人类金标集，上面这套体系存在的全部理由，就是让便宜评判器报的数字仍然跟得上"金标集会说什么"。

# tools/calibrate_judge.py — run monthly, or on alarm.
from pathlib import Path
from sklearn.metrics import cohen_kappa_score

def calibrate(judge, gold_set, floor=0.85):
    preds = [judge.score(item.input, item.output) for item in gold_set.items]
    truth = [item.human_label for item in gold_set.items]
    kappa = cohen_kappa_score(truth, preds)

    record = {
        "gold_set": gold_set.version,
        "judge_model": judge.model_id,
        "judge_prompt_hash": judge.prompt_hash,
        "agreement_kappa": kappa,
        "floor": floor,
        "pass": kappa >= floor,
    }
    Path("calibration/history").write_calibration_record(record)
    if not record["pass"]:
        raise CalibrationFailure(record)  # pages on-call; blocks eval gate.
    return record

上面这份代码有意写得很短。整套纪律有意都很短。承重的不是代码，而是承诺：一份带版本的金标集、一条书面写下的底线、一个月度节奏、一组提前定义好的告警加固化回滚目标，以及一位不是"发被测系统那位"的负责人。本文里每一种坍缩模式都始于跳过这五条承诺中的一条；每一支经受住生产评测接触的团队都留住了五条全部。