05. LLM-as-judge、verifier 与人类校准

本章回答：什么时候该让 LLM 当裁判，什么时候应该写确定性验证器，以及如何知道你的 judge 值不值得信任。

学习目标

读完本章，你应该能：

区分 assertion、verifier、LLM judge、人类标签的适用场景。
写出一个窄域 binary LLM judge 的设计原则。
用人类标签校准 judge，避免 raw agreement 陷阱。
解释 LLM judge 的常见偏差和 agent trajectory judge 的局限。

本章导读

LLM-as-judge 很容易让人产生一种轻松感：既然很多质量无法用代码判断，那就让另一个更强的模型来判断好了。这个想法并不荒唐，很多场景确实需要 judge。但危险在于，judge 的输出也只是一个模型行为，而不是从天而降的客观事实。

一个没有校准的 judge，就像一个没有培训过的新标注员。它可能偏爱更长的回答，可能被自信的语气说服，可能漏掉少数但严重的失败，也可能因为 rubric 写得含糊而给出看似稳定、实则空洞的分数。更麻烦的是，judge 的错误常常披着“自动化评估”的外衣，让团队误以为人工判断已经被替代了。

所以本章的基本态度是克制的：能写 verifier 的地方，先写 verifier；必须用 judge 的地方，把 judge 当成需要培训、校准和审计的标注员。它可以提高吞吐量，但不能替你拥有产品判断。

Judge 与 Verifier 光谱

先说结论

如果一个失败可以用代码、数据库查询、单元测试或状态 diff 判断，就不要让 LLM judge 判断。LLM judge 的位置是：处理无法稳定程序化的语义或主观质量，并且必须被人类标签校准。

这条规则来自实践中的成本和可靠性排序：

确定性断言最便宜、最稳定、最适合 CI。
状态 verifier最接近真实 outcome，适合 agent 和 coding task。
LLM judge可扩展，但有偏差，需要校准和监控。
人类评审最贵，但不可替代，负责定义标准、校准 judge 和审计高风险样本。

这个排序背后有一个很朴素的工程原则：不要用更不稳定的东西去判断本来可以稳定判断的事情。判断 JSON 是否能解析，不需要 LLM；判断财务系统里是否生成了报销草稿，也不需要 LLM；判断单元测试是否通过，更不需要 LLM。LLM judge 的能力很强，但它引入了新的随机性、偏差和成本。只有当问题本身需要语义理解、业务语境或主观标准时，才值得把它请上场。

很多团队会反过来做：先写一个“综合质量 judge”，再让它解释所有失败。这样得到的分数看似统一，实际很难修复。一个好的 eval 系统更像一组窄而清楚的检查器：格式用断言，状态用 verifier，政策边界用规则和 judge 组合，复杂语义再交给校准过的 LLM judge。

Verifier：能验证就不要猜

verifier 是能程序化判断成功与否的 scorer。典型例子：

JSON schema 检查。
字符串、正则、字段范围检查。
SQL 查询检查数据库最终状态。
运行单元测试。
比较文件 diff。
检查某个 tool call 是否发生。
检查某个外部系统是否产生 side effect。

Verifier 的优势

稳定：同样输入得到同样结果。
便宜：不需要额外模型调用。
可解释：失败通常能定位到具体断言。
适合 CI：可以阻断 PR 或发布。
可复用为 reward：很多 verifier 可以直接变成 RL environment 的 reward function。

SWE-bench 的 FAIL_TO_PASS / PASS_TO_PASS 就是典型 verifier：修复应该让原来失败的测试通过，同时不能破坏原来通过的测试AwesomeEvalsPatterns2026。

verifier 的好处不只是“更客观”，而是它通常更接近系统真正要完成的事。一个 coding agent 的补丁写得再漂亮，如果测试不通过，用户不会得到修复；一个客服 agent 的回复再礼貌，如果订单状态没变，任务也没有完成。verifier 把评价从“看起来像成功”拉回“世界是否真的改变”。

Verifier 的局限

可能过度严格，误杀合理等价答案。
如果只检查局部，可能漏掉副作用。
一旦被用于训练，loophole 会被 reward hacking 放大。
复杂环境搭建成本高。

所以 verifier 不是“写了就完事”，也需要审计。特别是把 verifier 用作 RL reward 时，要假设 agent 会找漏洞。

verifier 的局限同样不能忽视。过窄的 verifier 会奖励捷径：测试只覆盖一个输入，agent 就可能硬编码；状态检查只看目标字段，agent 就可能破坏其他字段；字符串检查只看关键词，模型就可能输出关键词但没有完成真实动作。一个成熟 verifier 往往需要同时检查正向成功和负向副作用，并保留人工审计样本。

LLM-as-judge：适合不可完全程序化的判断

LLM judge 适合这些场景：

回答是否忠实于给定 context。
是否应该向用户追问。
语气是否冒犯或不专业。
是否违反业务政策。
是否有效完成了多步骤轨迹。
摘要是否保留关键事实。
解释是否自洽且覆盖关键点。

但 LLM judge 不应是一个“万能质量分”。Hamel 的建议是：每个 judge 只判断一个具体 failure mode，并输出 binary PASS/FAILHamelJudge2025。Eugene Yan 也强调 binary 或 pairwise 通常比连续打分更可靠YanJudgeTalk2024。

把 judge 设计成窄域二元判断，会让它更像一个受训标注员，而不是一个“品味裁判”。例如不要问“这个回答质量好吗”，而要问“当报销信息缺少项目编号或超预算说明时，助手是否仍然提交或声称可以提交报销单”。前一个问题太大，judge 可能被语气、长度、格式吸引；后一个问题有明确证据和边界，也更容易用人工标签校准。

一个好 judge 的结构

一个窄域 binary judge 至少应包含：

清楚的判定对象：评估 assistant reply、完整 trace，还是最终状态摘要？
单一 criterion：一次只判断一个失败模式。
输入数据边界：哪些上下文可用，哪些不能推测。
先推理后 verdict：让 judge 先分析，再输出 PASS/FAIL。
few-shot critiques：使用领域专家写的例子和理由。
固定输出格式：便于解析。
人工校准集：至少几十到上百条人工标签。
TPR/TNR 报告：不要只报 agreement。

示例模板：

你正在评估一个差旅报销助手是否犯了“信息不足时仍提交报销单”错误。

数据：
- 用户请求：{user_message}
- 政策上下文：{policy_context}
- 当前单据状态：{expense_state}
- 助手回复：{assistant_reply}

判定标准：
如果项目编号、发票附件或超预算说明缺失，而助手仍然调用提交工具，或明确声称报销单已经可以提交，则 FAIL。
如果助手先追问缺失信息、草拟说明但等待员工确认，或明确说明暂不能提交，则 PASS。

请先给出简短 reasoning，再在最后一行只输出 PASS 或 FAIL。

few-shot critique 比长 rubric 更重要

实践中，judge 的真实信号常来自 few-shot examples，尤其是带领域专家解释的 critiques，而不是一大段抽象 rubricAwesomeEvalsPatterns2026。

好的 few-shot：

FAIL 示例：
用户说：“帮我把这次上海出差报销了，酒店发票我稍后补。”
上下文：项目编号缺失，酒店金额超过政策上限，附件缺少 hotel receipt。
助手：“我已经为你提交报销单，财务会处理。”
Critique：FAIL。缺少项目编号、超预算说明和酒店发票，助手不应提交或声称已提交。

PASS 示例：
用户说：“帮我把这次上海出差报销了，酒店发票我稍后补。”
上下文：项目编号缺失，酒店金额超过政策上限，附件缺少 hotel receipt。
助手：“我可以先整理草稿，但还需要项目编号、酒店发票，以及超预算业务说明；确认后我再提交。”
Critique：PASS。明确指出缺失信息，没有提交，并给出下一步。

few-shot 应来自错误分析中的真实样本，而不是凭空编造。这样 judge 才贴近你的产品。

few-shot critique 的价值，在于它把抽象标准变成可模仿的判断过程。很多 rubric 写得很长，却没有告诉 judge 遇到边界情况时该怎么取舍。真实样本中的 critique 会展示这种取舍：为什么某个回答虽然礼貌但仍然失败，为什么某个回答虽然简短但合规，为什么某个含糊请求必须先追问。对产品 eval 来说，这些解释往往比标签本身更重要。

校准：用混淆矩阵看 judge

假设你有 100 条人工标签，其中 20 条真实 FAIL，80 条真实 PASS。某 judge 预测结果：

	人工 FAIL	人工 PASS
Judge FAIL	16	8
Judge PASS	4	72

则：

TPR = 16 / (16 + 4) = 0.80
TNR = 72 / (72 + 8) = 0.90
Precision = 16 / (16 + 8) = 0.67

是否可用取决于场景。如果这是安全泄露 judge，TPR 0.80 可能太低；如果这是低风险风格 judge，可能可以接受但要控制告警量。

校准 judge 时，团队实际在做的是风险定价。false negative 是漏掉真实失败，false positive 是误杀正常样本。隐私、支付、越权、医疗法律等场景通常更害怕漏报；风格、简洁度、轻微语气问题则更害怕误报过多导致团队忽略告警。没有绝对通用的阈值，只有与业务风险相匹配的阈值。

Raw agreement 陷阱

如果 95% 样本都通过，一个永远输出 PASS 的 judge 有 95% agreement，但 TPR 是 0。Hamel/Shreya 的 walkthrough 用这个例子说明，judge 校准必须分开看真实失败和真实通过HamelShreya2026。

所以报告 judge 时至少给出：

样本数。
正负样本比例。
TP、FP、TN、FN。
TPR、TNR、precision。
典型 false positives。
典型 false negatives。
judge prompt 与模型版本。

LLM judge 的常见偏差

Eugene Yan 的 LLM evaluator 总结和 MT-Bench/Chatbot Arena 相关研究都指出，judge 会出现多类偏差YanLLMEvaluators2024 ZhengMTBench2023：

偏差	表现	缓解
位置偏差	pairwise 中偏向第一个或第二个答案	随机交换顺序，取平均
冗长偏差	偏向更长、更自信的回答	明确惩罚无关内容，使用 reference
自我偏好	偏向同模型生成文本	换 judge model，做交叉评估
权威/格式偏差	被引用、格式、语气误导	要求 grounded evidence
代理推理偏差	相信 agent 自己的错误 reasoning	不给或弱化 agent reasoning，要求查证外部状态
类别不平衡	少数失败被漏掉	按 TPR/TNR 校准，过采样失败

单轮回答 judge 已经有偏差，多步 agent judge 更难。AgentRewardBench 对 web-agent trajectory judge 做反向评估，发现当前 LLM judges 容易 over-credit 成功，没有一个 judge precision 超过 70%；而官方 rule-based evaluators 则常 under-report success，因为它们过度依赖 exact match，召回率只有 55.9%AgentRewardBench2025。

这说明：

LLM trajectory judge 不适合作为唯一真相。
规则评分器也不一定是 ground truth。
最可靠做法通常是组合：状态 verifier + trajectory diagnostics + 抽样人工审计。

多步 trajectory judge 特别容易被“过程叙事”迷惑。agent 可能写出看似合理的计划，甚至在 reasoning 中自称已经检查了某个状态，但真实浏览器页面或数据库并没有相应变化。反过来，规则评分器也可能因为只承认一种路径而低估成功。组合评估的意义，就是让不同 scorer 互相制衡：状态 verifier 看最终结果，trajectory diagnostics 看关键约束，人工审计检查边界和误判。