超越 ROUGE 和 BLEU：校准 LLM-as-a-Judge 评估方法

先明确边界

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

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

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

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",
  "dimension_scores": {
    "correctness": 0,
    "evidence_support": 0
  },
  "supported_claim_ids": ["c1"],
  "unsupported_claim_ids": ["c2"],
  "uncertainty": "low|medium|high",
  "reason_codes": ["missing_evidence"]
}

使用 Parser 校验 JSON，拒绝未知枚举，限制理由长度，并将格式错误单独记为评估错误。Judge 的解释是调试证据，不是可信证明。

校准 Judge

位置与顺序

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

from dataclasses import dataclass

@dataclass(frozen=True)
class PairVerdict:
    winner: str  # "A", "B", "TIE", or "REVIEW"

def reconcile(first: PairVerdict, swapped: PairVerdict) -> str:
    if first.winner == "A" and swapped.winner == "B":
        return "A"
    if first.winner == "B" and swapped.winner == "A":
        return "B"
    if first.winner == swapped.winner and first.winner in {"A", "B", "TIE"}:
        return first.winner
    return "REVIEW"

这能发现顺序敏感性，但不能消除所有偏差。

人工锚点与控制案例

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

不要发布通用一致率阈值。可接受错误取决于伤害、可逆性和人工复核成本。

应测试的偏差

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

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

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 + 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 分数当真值；
• 强迫所有答案匹配一个参考答案；
• 要求隐藏推理作为审计日志；
• 允许候选内容控制 Judge Prompt；
• 未做 Schema 校验就解析模型 JSON；
• 使用不同 Prompt、Tool 或 Retrieval Context 比较模型；
• 把不同维度平均成一个数字；
• 无删除和访问控制地长期保存原始评估数据；
• 用 ROUGE/BLEU 评估事实或策略正确性；
• 用 Judge 授权资金、访问、删除或外部写入。

实践清单

• [ ] 定义构念、证据、可接受替代答案和 Oracle。
• [ ] 客观可验证时优先使用 Exact 或执行检查。
• [ ] Judge 输出小型、有界、结构化并经过 Schema 校验。
• [ ] 随机化 Pair 顺序并允许平局和证据不足。
• [ ] 按风险和任务切片使用人工控制案例校准。
• [ ] 测试长度、自我偏好、格式、身份和 Prompt Injection 偏差。
• [ ] 分开 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
• FAVA: Fine-grained AI-generated Text Factuality Evaluation
• HELM: Holistic Evaluation of Language Models
• NIST AI Risk Management Framework