LLM-as-a-Judge：校准、偏差与发布门禁

TL;DR

LLM-as-a-Judge 是概率型测量工具，不是真相来源。只有在评估构念明确、证据边界清楚、Judge Contract 可复现、人工控制集完备且错误画像已知时，才能使用它。确定性 Oracle 和人工 Oracle 在适用范围内仍是权威依据。Pairwise 评估必须先把左右位置标签还原为稳定候选 ID，再合并换序结果，否则位置偏差会被误记成内容赢家。

核心结论

• 先定义构念，再选评估器。 ROUGE、BLEU、精确检查、代码执行、人工评审和 Judge 模型回答的是不同问题。
• 版本化完整 Judge Contract。 数据、Rubric、模型、Prompt、Parser、证据、采样与环境共同决定一次测量。
• 按切片衡量错误。 只看准确率或相关系数，可能掩盖少数高风险样本上的误通过。
• 换序标签不是候选身份。 只有把两轮结果归一化到不可变候选 ID 后，才能判断赢家是否稳定。
• 缓解措施不是正确性证明。 随机换序、多 Judge 和结构化输出能暴露或降低部分故障，但不会自动生成 Ground Truth。

先明确边界

ROUGE、BLEU 和 Exact Match 按明确的字符串或 Token 规则比较候选与参考答案。LLM Judge 估计候选是否满足 Rubric。二者都不是有用性、真实性、安全性或授权的通用度量。

使用能回答问题的最小评估器：

评估器是测量仪器，需要构念、协议、已知失败模式和校准。

固化 Judge Contract

只有完整评估契约可识别，Judge 结果才具备复现条件。只记录模型名和一段 Rubric 不够。

每份报告都应版本化：

judge_contract:
  dataset_revision: "sha256:cases-and-labels"
  slice_schema_revision: "sha256:slice-definitions"
  rubric_revision: "sha256:criteria-and-anchors"
  judge_model: "provider/model@immutable-version"
  judge_prompt_revision: "sha256:prompt"
  parser_revision: "git-commit"
  evidence_policy_revision: "git-commit"
  sampling_revision: "git-commit"
  inference_parameters:
    temperature: 0
    max_output_tokens: 256
  environment_revision: "container-or-lockfile-digest"

同时记录候选制品 ID、生成 Prompt、检索快照、工具结果与运行时间。任一字段变化都会产生新的测量序列；未做桥接实验时，不应把新旧 Judge 分数拼成同一条趋势线。

ROUGE 和 BLEU 仍然有用的地方

当词面重合本身属于契约时，词面指标仍然有价值：

• 参考答案可比的翻译回归；
• 抽取式摘要；
• 关键词或实体抽取；
• 模板化输出；
• 发现稳定格式的意外变化。

当任务允许多种有效表达、需要事实验证或包含多个质量维度时，它们会变弱。应把它们作为一个切片，而不是完整质量分数。

先定义评估构念

写 Judge Prompt 前先定义：

1. 用户或业务结果；
2. 评估器可以使用的证据；
3. 必需事实或字段；
4. 禁止的声明和动作；
5. 可接受的替代答案；
6. Abstention 或升级行为；
7. 如果存在，使用哪个权威 Oracle。

Rubric 应描述可观察行为，而不是模糊的“智能程度”：

Correctness:
  pass: 每个重要声明都得到提供的证据或获批来源支持
  fail: 任一重要声明与证据矛盾或编造来源

Instruction following:
  pass: 必需字段存在且遵守约束
  fail: 缺少必需字段或提出禁止动作

Evidence quality:
  pass: 每个高影响声明都对应引用证据 Span
  review: 证据不完整或声明有歧义

Rubric 不是授权策略，Server 侧 Policy 仍然权威。

三种 Judge 模式

逐点评分

将一个回答与 Rubric 比较，适合采样监控和回归切片。容易运营，但 Model 或 Rubric 变化会造成绝对分数漂移。

两两对比

比较同一案例的两个回答，适合受控 A/B 实验。结果是相对偏好，不是绝对质量保证；应随机化顺序并允许平局。

参考或证据引导

将回答的声明与参考答案、源文档、预期结构或执行结果比较。前提是不能把参考答案当作唯一有效措辞，并且需要单独识别无证据新增内容。

将 Judge 指令与候选内容、证据分开。候选文本可能包含针对评估器的 Prompt Injection。

安全的输出契约

要求小型结构化结论，不要求隐藏思考过程：

{
  "verdict": "pass|fail|review",
  "dimensions": {
    "correctness": "pass|fail|review",
    "evidence_support": "pass|fail|review"
  },
  "evidence_ids": ["source-v7#paragraph-12"],
  "failed_claim_ids": ["c2"],
  "reason_codes": ["missing_evidence"]
}

使用 Parser 校验 JSON，拒绝未知值，限制数组和字符串长度，并把格式错误视为评估错误。evaluation_error 应由编排层而不是模型输出。Judge 的解释和自报不确定性只适合调试，不是经过校准的概率或可信证明。

校准 Judge

位置与顺序

两两测试应随机化 A/B 顺序，并抽样交换顺序重跑：

from dataclasses import dataclass

@dataclass(frozen=True)
class PairVerdict:
    winner: str  # LEFT、RIGHT、TIE 或 REVIEW


def candidate_id(
    verdict: PairVerdict,
    order: tuple[str, str],
) -> str:
    if verdict.winner == "LEFT":
        return order[0]
    if verdict.winner == "RIGHT":
        return order[1]
    if verdict.winner in {"TIE", "REVIEW"}:
        return verdict.winner
    return "EVALUATION_ERROR"


def reconcile(
    first: PairVerdict,
    first_order: tuple[str, str],
    swapped: PairVerdict,
    swapped_order: tuple[str, str],
) -> str:
    first_choice = candidate_id(first, first_order)
    swapped_choice = candidate_id(swapped, swapped_order)
    if "EVALUATION_ERROR" in {first_choice, swapped_choice}:
        return "EVALUATION_ERROR"
    if "REVIEW" in {first_choice, swapped_choice}:
        return "REVIEW"
    if first_choice == swapped_choice:
        return first_choice
    return "REVIEW"


cases = [
    ("A wins both orders", "LEFT", "RIGHT", "candidate-a"),
    ("B wins both orders", "RIGHT", "LEFT", "candidate-b"),
    ("stable tie", "TIE", "TIE", "TIE"),
    ("left-position preference", "LEFT", "LEFT", "REVIEW"),
    ("right-position preference", "RIGHT", "RIGHT", "REVIEW"),
    ("one review", "REVIEW", "RIGHT", "REVIEW"),
    ("malformed verdict", "BROKEN", "RIGHT", "EVALUATION_ERROR"),
]

for name, first_winner, swapped_winner, expected in cases:
    actual = reconcile(
        PairVerdict(first_winner),
        ("candidate-a", "candidate-b"),
        PairVerdict(swapped_winner),
        ("candidate-b", "candidate-a"),
    )
    assert actual == expected, (name, actual, expected)

不可变候选 ID 才是比较身份，LEFT、RIGHT、A 或 B 都只是展示标签。这能发现一种顺序敏感性，但不能消除所有偏差。

人工锚点与控制案例

维护由人工审核的控制集，覆盖容易、歧义、对抗和高风险案例。按任务切片比较 Judge 与人工标签，记录样本数和不确定区间。当 Model、Prompt、Rubric、Parser 或数据分布变化时重新校准。

例如，MT-Bench 与 Chatbot Arena 论文报告的 80% 以上一致率只属于其 Judge 模型、Prompt、Benchmark、人工投票协议和研究日期；G-Eval 的相关性也只属于其自然语言生成任务与协议。两者都不是可迁移的准确率阈值。可接受错误取决于伤害、可逆性和人工复核成本。

报告校准记录，而不是一个总一致率：

失败样本很少时，Accuracy 仍可能很高；相关系数很高时，发布阈值附近的决策仍可能出错。应保留样本数和置信区间，检查关键切片，不要把不兼容维度平均成一个总分。

应测试的偏差

• 对长度和风格的偏好；
• 位置与顺序；
• 对 Judge 所属 Model Family 的自我偏好；
• 即使参考答案错误仍然服从参考答案；
• 对格式或身份线索的敏感性；
• 不愿标记证据不足；
• 候选内容或检索内容中的 Prompt Injection。

隐藏无关 Metadata，随机化候选顺序，并在控制集加入简洁但正确的答案。

Rubric 顺序也是输入变量。Rubric-based Judge 研究显示，分数描述的位置与多项标准的排列顺序都可能改变输出，而且偏差方向与缓解收益取决于 Judge 模型和数据集。随机或均衡排列可以审计这种影响，但发现或降低顺序效应，不等于证明 Judge 已对齐目标构念。

RAG 评估

分别评估 Retrieval 和 Generation：

测量 Faithfulness 时，不要让 Judge 使用外部常识。提供问题、有界证据、回答和 Claim ID。一个事实即使普遍正确，如果没有被检索上下文支持，仍可能是 Retrieval 失败。

确定性与人工 Oracle

代码执行、Schema、算术、Policy、权限和副作用优先使用确定性检查。歧义、高影响或新颖案例使用人工复核。Judge 适合在有校准证据时做可扩展分流和比较。

评审团不会自动产生真相，多个 Judge 可能共享同一种偏差。出现分歧时保留分歧或升级，不要制造看似精确的平均值。

成本、隐私与采样

Judge 输入经常包含用户问题、检索文档和模型回答。发送给 Provider 前：

• 最小化并脱敏个人或机密数据；
• 记录 Purpose、留存、驻留和删除行为；
• Hash 或替换标识符；
• 限制 Context 和理由大小；
• 默认 Telemetry 不存原始候选文本；
• 区分估算成本和 Provider 账单。

按风险和统计目的选择采样。固定“每次都评估”或固定采样比例并不普适。高影响案例可能需要完整 Metadata 和人工复核，低风险流量可以使用分层样本。

CI/CD 发布门禁

版本化以下全部内容：

task set + data digest + prompt + rubric + judge model
parser + evidence policy + oracle + sampling + environment + report

可以使用这样的流程：

contract checks
  -> deterministic scenarios
  -> replay comparison
  -> abuse and privacy cases
  -> calibrated judge triage
  -> human review of disagreement
  -> cost/latency check
  -> canary and rollback

门禁应表达不变量和工作负载预算。不要只因为一个没有不确定性或切片分析的 Judge 平均分变化，就阻断发布。

Judge 本身也需要发布状态：

shadow
  -> 收集校准证据
  -> 仅批准指定维度和切片
  -> 通过人工控制集持续监控
  -> 契约变化、漂移或错误预算超限时暂停

某个 Judge 获批评估英文客服摘要，不代表它也获批评估法律建议、其他语言、工具轨迹或安全策略。未知或缺少支持的切片应返回 review，而不是输出一个自信分数。

常见失败模式

• 把 Judge 分数当真值；
• 强迫所有答案匹配一个参考答案；
• 要求隐藏推理作为审计日志；
• 允许候选内容控制 Judge Prompt；
• 未做 Schema 校验就解析模型 JSON；
• 使用不同 Prompt、Tool 或 Retrieval Context 比较模型；
• 未恢复候选身份就合并 Pairwise 换序标签；
• 把 Rubric 随机换序当成位置偏差已经解决的证明；
• 把不同维度平均成一个数字；
• 无删除和访问控制地长期保存原始评估数据；
• 用 ROUGE/BLEU 评估事实或策略正确性；
• 用 Judge 授权资金、访问、删除或外部写入。

实践清单

• [ ] 定义构念、证据、可接受替代答案和 Oracle。
• [ ] 客观可验证时优先使用 Exact 或执行检查。
• [ ] Judge 输出小型、有界、结构化并经过 Schema 校验。
• [ ] 随机化 Pair 顺序并允许平局和证据不足。
• [ ] 合并结果前，把 Pairwise 标签归一化到不可变候选 ID。
• [ ] 按风险和任务切片使用人工控制案例校准。
• [ ] 报告误通过、误拒绝、复核覆盖、换序一致性和切片支持度。
• [ ] 测试长度、自我偏好、格式、身份和 Prompt Injection 偏差。
• [ ] 审计 Rubric 分数选项位置与多标准顺序。
• [ ] 分开 Retrieval、Evidence Support、Answer Correctness 和 Safety。
• [ ] 有目的地脱敏、采样、留存和删除评估数据。
• [ ] 版本化任务集、Rubric、Prompt、Judge、Parser、Oracle 和报告。
• [ ] 将 Judge 证据与滥用测试、成本/延迟预算、审批、Canary 和 Rollback 结合。

总结

LLM-as-a-Judge 有用的前提，是把它当作经过校准但会出错的测量工具。ROUGE 和 BLEU 在它们真正测量的契约中仍然有价值；确定性和人工 Oracle 在适用处仍然权威。成熟的评估体系要让不确定性可见、保护评估数据，并拒绝把流畅的模型结论包装成正确性、安全性或权限的证明。

一手来源

• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
• G-Eval: NLG Evaluation using GPT-4
• Am I More Pointwise or Pairwise? Revealing Position Bias in Rubric-Based LLM-as-a-Judge
• FAVA: Fine-grained AI-generated Text Factuality Evaluation
• HELM: Holistic Evaluation of Language Models
• OpenAI：Evaluation Best Practices
• NIST AI Risk Management Framework