22. Evaluating the Evaluator：评测器也必须被评测
高级方法论 · 4～6 小时
学习目标
- 理解 False Positive / False Negative 对 Agent 排名的影响
- 验证 Judge 与 State Checker
- 建立 Evaluator Test Set 与版本治理
前置知识
- 第 9～15 章
本章产物： 建立一套 Evaluator Gold Set，并报告准确性和分歧。
22.1 Eval 的最大盲点：默认 Scorer 是对的
如果 Evaluator 把失败判成成功，Agent 会学会或优化到错误目标。
所以：
Agent Eval
↓
Evaluator Eval必须成为正式流程。
22.2 Evaluator Gold Set
选择一批 Case/Run，经过：
- 专家确认；
- 环境直接验证；
- 双人复核；
得到可信标签。
然后测：
precision
recall
false positive
false negative
agreement22.3 False Success 比 False Failure 更危险
对发布门禁而言：
Agent fail → Evaluator PASS可能把危险版本放上线。
因此高风险 Evaluator 应重点优化 False Positive。
22.4 State Checker 也会错
例如：
只检查 status == cancelled却没检查错误订单被取消。
这就是 Evaluator Coverage 问题。
22.5 Reward Hacking / Shortcut
如果 Agent 发现只需要创建一个文件名就能 PASS，而不需要完成内容，就会出现 Benchmark Gaming。
所以 Evaluator 必须验证真正目标，而不是表面 proxy。
22.6 Judge Drift
更换 Judge Model 后，同一历史 Trace 可能得分变化。
正确流程：
old judge
new judge
gold set
agreement
threshold recalibration22.7 Benchmark 也是产品
Benchmark 需要：
- Issue；
- version；
- regression test；
- evaluator unit tests；
- release note；
- known limitations。
22.8 验收问题
- 什么是 Evaluator False Success？
- 为什么 State Checker 也需要测试？
- 更换 Judge Model 后为什么不能直接沿用旧阈值？