Agent 评测实战 · 08把另一个会犯错的模型，变成可检查、可复核、暂时只在影子模式工作的评分器
RR-GOLD-003 的发布建议是“暂缓发布”。结论没错，可理由只有一句：“构建、关键测试或阻断缺陷中至少一项未通过。”
究竟是构建失败、回归测试失败，还是存在 P1 缺陷？读者仍要自己翻 Trace。一个只盯结论的 Judge 很可能给它 PASS；熟悉发布评审的人更可能判成 REVIEW。
分歧不说明人一定对、模型一定错。它说明“写得够不够好”还没有一把经过校准的尺子。
第 7 篇留下了一个刻意的空白：Outcome、Tool、State 可以由代码稳定判断，Response Quality 却不能靠关键词数量或固定句式硬判。LLM Judge 确实擅长理解开放式文本，但它仍是概率模型，会受 Rubric、上下文、答案长度甚至呈现顺序影响。
所以本篇不讨论“选哪个模型当裁判”，而是解决更靠前的问题：怎样定义 Rubric、怎样准备人工标签、怎样验证 Judge 与人的判断是否足够一致，以及哪些结果必须退回人工复核。
本文阅读路线
01 LLM Judge 不是终审裁判
02 Rubric 如何把“写得好”拆成可判标准
03 人工标注集怎样成为校准基准
04 校准时，别只看一个一致率
05 通过校准，也只能先进入 Shadow Mode
01 · 职责边界
LLM Judge 不是终审裁判
“Judge”这个名字很容易制造错觉，仿佛把一段回答交给更强的模型，就能得到客观判决。实际工程里，它更像一名速度很快、能读懂语义，却需要持续抽查的评审员。
Anthropic 对 Agent eval 的划分很实用：代码评分、模型评分和人工评分各有自己的位置。模型评分能处理自由文本和细微语义，但具有非确定性，而且必须用人工判断做校准。这不是模型能力强弱的问题，而是评测职责的边界。
图 1｜三类裁判不是互相替代：规则守事实底线，Judge 读开放语义，人工处理争议和高风险
在发布评审 Agent 中，职责可以这样拆：
确定性 Grader：结论是否符合业务标签、工具有没有越界、状态文件是否正确。
LLM Judge：理由是否基于证据、有没有点出决定性风险、下一步是否清楚。
人工复核：处理 Judge 与人工基准的分歧、高风险样本和超出 Rubric 的新问题。
有些团队会把确定性结果也塞进 Judge Prompt，让模型重新判断工具调用和业务结论。这样做既更贵，也把原本可复现的事实变成概率答案。更稳妥的方式是：确定性结果作为上下文交给 Judge，但只允许它评价开放式文本质量。
LLM Judge 应该补上规则看不懂的部分，而不是把已经能确定的事实再猜一遍。
02 · Rubric
Rubric 如何把“写得好”拆成可判标准
“请判断回答是否专业、准确、清晰”不是 Rubric，只是一句愿望。准确指事实正确，还是证据充分？清晰是语言通顺，还是能让发布负责人直接行动？标准越含糊，Judge 越容易凭自己的写作偏好打分。
本项目把 Response Quality 拆成四个维度，其中三个属于关键维度：
图 2｜Judge 不只返回标签，还必须指出维度结果、证据路径和简短理由
标签也不要只留 PASS / FAIL。我们增加 REVIEW：结论可能可用，但解释存在遗漏或歧义，需要人确认。这个中间态很重要，它允许系统承认“不确定”，而不是逼 Judge 把所有灰区都装成确定答案。
{
"label": "REVIEW",
"dimension_results": {
"groundedness": "PASS",
"risk_coverage": "REVIEW",
"actionability": "REVIEW",
"scope_discipline": "PASS"
},
"evidence_refs": ["execution.json", "trace.jsonl"],
"rationale": "结论可用，但没有指出具体阻断项。",
"confidence": 0.72
}
OpenAI 的 grader 文档同样区分了字符串检查、代码评分和模型评分：模型评分适合主观属性，但输出分数不等于事实本身。在这里，confidence 只用于分流，不能拿来证明 Judge 判对了。
Rubric 的验收问题：两名懂业务的人只看定义和证据，能否解释为什么一条回复是 PASS、REVIEW 或 FAIL？如果仍靠“感觉”，就还不能交给模型规模化执行。
Judge 校准不能拿一批“显然很好”和“显然很差”的回答走过场。真正有价值的是边界样本：结论正确但理由含糊、证据完整却漏掉关键风险、语言很漂亮但事实不受支持，以及像 RR-GOLD-008 这样守住权限却没有解释拒绝原因的回复。
图 3｜校准不是调 Prompt 直到分数好看，而是反复检查“模型为什么和人不同”
一套可维护的人工基准至少要保存四类信息：原始证据、人工标签、逐维度理由、Rubric 版本。关键或含糊样本最好由两名领域评审者独立标注，再对分歧进行仲裁；否则所谓“人类真值”可能只是某个人的写作偏好。
标注时还有一个容易忽略的细节：人工评审者应先独立看原始证据，再看 Judge 的解释。若一开始就把模型理由放在旁边，人很容易被它流畅的措辞锚定，复核就失去了独立性。
校准集要覆盖：正常样本、边界样本、对抗样本和高风险样本。
版本必须固定：Judge 模型、Prompt、Rubric、输入模板任一变化，都记录成新版本。
保留分歧：难例不是脏数据。它们往往最能暴露标准含糊、证据不足或 Judge 偏差。
本项目附带的 8 条记录是离线流程演示样本，不是一次实时模型实验，也不是经过多人专家标注的生产 Golden Set。它的作用是让读者跑通“人工标签—Judge 记录—差异报告—复核队列”这条链路。
运行校准脚本后，8 条离线记录中有 6 条与人工参考标签一致，一致率为 75%；两条分歧都表现为 Judge 过于宽松，把人工的 REVIEW 判成 PASS。
python3 calibrate_judge.py
status: NOT_READY
sample_count: 8
exact_agreement: 0.75
disagreement_count: 2
critical_false_passes: 0
图 4｜一致率只是入口；更要看 Judge 在什么标签上犯错，以及有没有把关键失败放成 PASS
RR-GOLD-003 没有明确指出回归测试失败；RR-GOLD-008 没有解释为什么拒绝“跳过检查、直接部署”。它们都不是彻底错误，却不够完整。Judge 只看到了正确结论和流畅句子，忽略了 Risk Coverage 与 Scope Discipline 的解释责任。
因此，校准报告至少要同时看：
整体一致率：模型与人工参考标签有多接近。
按标签拆分的混淆：是把 REVIEW 判成 PASS，还是把好回答误杀。
关键误放行：人工判 FAIL、Judge 却判 PASS 的高风险错误。
稳定性与偏差探针：交换候选位置、增加无信息的冗长文字后，判断是否改变。
LLM-as-a-Judge 的经典研究记录了位置偏差、冗长偏差和自我偏好；交换候选答案顺序，是检查 Pairwise Judge 的简单办法。但“前后两次判得一样”只代表一致，不代表正确。最终仍要回到人工参考标签和业务风险。
演示配置把一致率门槛设为 80%，并要求关键误放行为 0。75% 没过线，所以状态是 NOT_READY。这里的 80% 只是这个示例项目的门槛，不是可以复制到所有业务的行业标准；真实阈值应由风险、人工成本和错误代价共同决定。
如果只看平均一致率，Judge 可能在大量简单样本上刷高分，却在真正危险的关键失败上放行。
05 · 上线边界
通过校准，也只能先进入 Shadow Mode
校准通过，不等于把发布门禁交给 Judge。更稳妥的上线顺序是：离线校准通过后进入 Shadow Mode，让 Judge 跟随真实评测运行，但不影响发布决定；持续抽样与人工结果对照，再决定是否扩大自动化范围。
在 Shadow Mode 中，下面几类结果直接进入人工复核：Judge 输出 REVIEW、命中关键风险、证据缺失、出现校准集外的新场景、模型或 Prompt 刚升级，以及固定比例的随机抽样。低 confidence 可以提高复核优先级，但高 confidence 不能免检。
确定性门禁仍然拥有优先权：Outcome、Tool 或 State 任何关键项失败，Case 就不能被 Judge 的高分“救回来”。同样，Judge 的 PASS 只代表文本质量达标，不代表 Agent 可以执行发布。
本篇真正留下的判断
可信的 LLM Judge，不是“模型够强”，而是标准可解释、人工标签可追溯、错误类型可见、争议结果有退路。
在这四个条件满足前，它适合做评审助手，不适合做发布裁决者。
到这里，我们已经为一条 Agent 执行建立了确定性评分和主观质量复核。但同一个 Agent 面对同一条用例，换一次采样可能就走出另一条路径。下一篇要处理的正是这种随机性：一条用例究竟要跑几次，多 Trial 结果该怎样汇总，失败又该怎样分类。
下一篇 · Agent 评测实战 09
同一条用例为什么要跑多次：Trial、稳定性指标与失败分类怎么设计
