Chapter 05
运行期 Evaluator：把判分搬进 agent 的循环（B 面）
前四章讲的全是 A——开发期、离线的评测体系。这一章补上第 1 章特意划出去的另一半：B，运行期 Evaluator。重点不是重教 Reflexion / Self-RAG 的机制（那些在别处），而是说清一件没人讲透的事：B 用的就是第 2 章那套 LLM-as-judge，所以它继承全部偏差；而且 B 自己是一个必须用 A 来验证的组件。
本章你将建立的认识
- 运行期 Evaluator（B）是什么：把"判分"从离线测试集搬进 agent 推理循环，每次任务实时跑——evaluator-optimizer 是它的通用形态。
- B 就是 LLM-as-judge 换了个位置，所以第 2 章的三大偏差原样继承，其中 generator==evaluator 同模型是最危险配置。
- A 与 B 的接口：B 是一个判分器，它准不准要用 A（golden set + κ）量；一个乱判的 B 比没有更糟。
5.1运行期 Evaluator 是什么
B = 把"判分"放进 agent 的推理循环里，让模型边做边给自己的中间产物打分、据此决定要不要重做。
LLM 第一次的输出常常"差一点"——代码跑不过、简报漏了关键条件。与其把这个半成品直接交付，不如在循环内加一道关：生成一版 → 评判这版 → 不达标就带着反馈重写。这道"关"就是 B。它和 A 的根本区别在时机：A 在开发期对固定数据集跑、产出回归报告；B 在每一次真实任务的推理过程中跑、产出一个更好的当次输出。
B 最通用的形态叫 evaluator-optimizer（Anthropic 在《Building Effective Agents》里给的名字）：一个角色负责生成，另一个角色负责评判，两者迭代到评判通过为止。图 5.1 是这个回路。
5.2B 的几种形态（机制在别处，这里给地图）
evaluator-optimizer 是骨架，套上不同的"评判什么 / 何时评"就长成了几个有名字的模式。它们的机制分散在其它教程里讲过，这一章不重复，只把它们摆进同一张表，让边界清楚。
| 形态 | 评判什么 | 何时触发 | 机制详见 |
|---|---|---|---|
| evaluator-optimizer | 整个输出达没达到评判标准 | 每次任务，迭代到通过 | agent-interview §3.5 |
| Reflexion | 这一回合哪里错了（口头自我批评） | 失败后，把批评存进记忆再重试 | agent-reasoning-patterns §2.4 |
| Self-RAG | 要不要检索 / 检索回来的相不相关 | 检索前后，模型自评 token 控制 | rag §4.3 |
| CRAG（Corrective RAG） | 检索质量够不够（够 / 模糊 / 不够） | 检索后，差就触发改写或转网搜 | rag §4.3 |
| LATS | 树搜索里每个节点的好坏 | 搜索展开时，给候选打分剪枝 | agent-reasoning-patterns §3.1 |
这五个名字差异只在"评判什么、何时触发"两栏。把这两栏抽掉，剩下的都是同一句话：在循环里插一个 LLM-as-judge，用它的判分驱动下一步。记住这个骨架，遇到任何新名字（下个月还会有），先问它"评判什么、何时触发"，就能归位。
5.3B 继承 A 第 2 章 judge 的全部偏差
既然 B 的评判器就是 LLM-as-judge，第 2 章列的三大偏差（§2.3）原样搬过来，而且在运行期更隐蔽——因为没有离线分数摆在面前，没人盯着它判得对不对。
- verbosity bias：评判器偏爱更长的草稿，于是 evaluator-optimizer 每迭代一轮输出往往更啰嗦，而不是更好。
- position / 自我一致性：同一版草稿评判器多次给的判定未必一致，循环会在"通过 / 不通过"之间抖动。
- self-enhancement bias：评判器偏爱自己模型家族的输出——而在 B 里，生成器和评判器常常就是同一个模型。
当生成器和评判器是同一个模型，self-enhancement bias 拉满：它在评判自己刚写的东西。更糟的是共享盲点——一个"错得很流畅"的草稿，写它的模型看不出错，评判它的同款模型一样看不出，于是循环高高兴兴地收敛到一个错误答案。这正是第 2 章那条警告在运行期的版本。缓解：评判器换一个不同家族的模型，或退回到有真值的 grounding（让 Observation 而不是另一个 LLM 来当裁判，见 Reflexion 的接地）。
还有一条比偏差更根本的限制：评判标准模糊时，越反思越跑偏。当任务没有清晰的对错判据，评判器的自我批评本身就不可靠，多迭代几轮反而把对的改错。所以 B 不是默认开关。
一个 evaluator-optimizer 跑了 5 轮，每轮评判器都说"还能更好"，输出越来越长。这是哪个偏差在作祟？该怎么改？
展开答案（先停 10 秒）
verbosity bias：评判器把"更长"误当成"更好"，于是给越长的草稿越高分，循环朝啰嗦的方向收敛。改法：在评判 rubric 里显式加入"简洁度 / 是否有冗余"作为一条二元判据（回到 §2.5 错误驱动的判据），或设一个硬迭代上限 + 长度预算，别让循环自己决定停。
5.4B 本身要用 A 来验证
B 是一个判分器；判分器准不准，要用第 2 章那套校准方法（golden set + Cohen's κ）量出来。
这是 A 和 B 真正接上的地方，也是这一章存在的理由。开发期的离线评测（A）不只是用来评 agent 的最终产物——它还是用来验证 B 这个运行期评判器的工具。一个没被校准过的 evaluator，会在循环里自信地把对的草稿判成"不达标"、把错的判成"通过"。这样的 B 比没有 B 更糟：它增加了成本，还引入了一个你看不见的错误源。
落到第 3 章那个个人情报员 Agent 上：如果给它加一个运行期评判器，让简报生成后自评"每条 [n] 引用是否真的有据"，那么这个评判器本身要先进 golden set——拿一批人工标过"忠实 / 编造"的简报喂给它，量它和人工判定的 κ。κ 不达标，这个运行期自评就是噪声，接进循环只会帮倒忙。
5.5什么时候上 B，什么时候别
B 不免费：每迭代一轮就多一组"生成 + 评判"调用，token 和延迟成倍涨。是否划算，取决于三个问题，图 5.3 是判定路径。
这条判据和第 3 章那个"先做错误分析"的立场一致：B 只在你已经通过读 trace 摸清了"什么算好、什么算坏"之后才值得上——清晰的判据是 B 能工作的前提，而清晰的判据恰恰来自 A 那一侧的错误分析。
§本章 self-check
先合上教程把答案写下来，再展开对照。
- 用一句话说清 A 和 B 在"时机"上的根本区别。
- evaluator-optimizer 里那个"评判器"，本质上是第 2 章的什么东西？这句话能推出哪一个最危险的配置？
- 为什么说"一个没被校准过的运行期 Evaluator 比没有它更糟"？
- 什么情况下绝对不该上 B？说出那个最硬的前置条件。
答案（先做完再展开）
- A 在开发期对固定数据集离线跑、防回归；B 在每次真实任务的推理过程中实时跑、提升当次输出。同样用模型打分，时机完全不同。
- 就是 LLM-as-judge。由此推出最危险配置：生成器和评判器是同一个模型——self-enhancement bias 拉满 + 共享盲点，循环会自信地收敛到错误答案。
- 因为它会在循环里自信地误判——把对的草稿判"不达标"反复重写、把错的判"通过"交付。它既加了成本，又引入一个没人盯着的错误源；而你以为加了它质量会更好。所以 B 上线前必须用 A（golden set + κ）校准。
- 评判标准模糊时绝对不上——判据不清，评判器的自我批评不可靠，越迭代越跑偏，B 是负价值。清晰判据是 B 工作的硬前提。
给个人情报员 Agent 设计一个"安全"的运行期 Evaluator
第 3 章给这个 agent 建了离线评测。现在要给它加一个运行期自评：简报生成后，自己检查"每条 [n] 引用是否在源里真的存在"。请写出：① 这个评判器该不该用和生成器同款的模型，为什么；② 上线前你怎么用 A 校准它（标多少、量什么）；③ 一个会让这个自评变成负价值的具体场景。写完对照 §5.4 与 §5.5。
提示（卡住再展开）
①"引用是否在源里存在"其实是个有真值的判据（能逐条核对），接近 reference-based，self-enhancement 风险小，但仍建议评判器换一个模型以防共享盲点。②标 30–100 条人工判过"忠实/编造"的简报，量评判器判定与人工的 Cohen's κ。③负价值场景：当源文档本身被指令注入污染，"存在于源里"被满足但内容是恶意的——此时这个自评给出虚假的安心。