Chapter 06

自测：把零散知识逼成可调用的判断力

前五章建立了概念、方法、流程、工具、运行期 Evaluator（B）——这一章不引入新知识，只做一件事：用三层梯度的题把它们从"读过"变成"用得出来"。题目按难度递增，最后一层是跨章判别，对应真实工作里的取舍。

这一章怎么用

  • 每道题先合上教程动笔，写完再展开文末答案——直接看答案等于把这页当再读一遍，没有检索就没有巩固。
  • 三层梯度：概念层（回忆）→ 原理层（解释机制）→ 应用判别层（在场景里选型）。卡在哪一层，回哪一章。
  • 应用判别层是这份教程的"综合项目替身"，每道题都要求横跨两章以上。
难 易 概念层 回忆 · 理解 — 对应第 1 章 原理层 解释机制 · 权衡 — 第 2 章 应用判别层 判别 · 迁移 — 跨 01–05
图 5.1题库的三层梯度，越往上越接近真实工作。注意：底层"概念层"题最多也最像背诵，但顶层"应用判别层"才是面试和落地真正考的——能背出 pointwise 定义，不代表知道这个场景该不该用它。

5.1概念层（对应第 1 章）

  1. 用一句话区分"评测体系（A）"和"运行期 Evaluator（B）"，各举一个例子。→ §1.1
  2. 为什么不能对 agent 的输出直接做 assertEqual？说出三个结构性原因。→ §1.2
  3. 评测的四层分别是什么？哪一层最常被忽略，导致回归藏在里面？→ §1.3
  4. faithfulness 和 context recall 分别测 RAG 的什么？它们属于四层里的哪一层？→ §1.3
  5. "exact match 给『Paris』和『法国首都』打 0.0 分"说明了什么问题？这个问题逼出了第 2 章的哪种方法？→ §1.2

5.2原理层（对应第 2 章）

  1. pointwise / pairwise / reference-guided 三种 LLM-as-a-judge 模式各适合什么情形？pairwise 的主要代价是什么？→ §2.2
  2. position bias 的标准缓解法是什么？为什么"交换顺序、两次都判赢才算赢"比"两次分数取平均"更对？→ §2.3
  3. G-Eval 为什么要用 token 概率加权（Σ p(sᵢ)·sᵢ），而不是直接取模型吐出的那个整数分？→ §2.4
  4. 你的 judge 和人类标注的裸一致率是 82%。这够不够说明 judge 可信？还要补看哪两件事？→ §2.6
  5. 为什么"1–5 Likert 评分"常常不如"从错误分析里提炼出的具体二元 pass/fail 判据"？→ §2.5

5.3应用判别层（跨 01–05，综合项目替身）

每题都要求横跨两章以上。先说清你选什么，再说清为什么、以及放弃了什么。

  1. 客服 agent 选 prompt：两个 prompt 版本，任务没有标准答案，要选更好的那个。你用 pointwise 还是 pairwise？judge 该选哪类模型？为什么不能用和 generator 同款的模型？跨 §2.2 + §2.3
  2. 账单暴涨：agent 上线后，离线 outcome 准确率没掉，但每月 API 账单涨了 3 倍。是哪一层 eval 漏了？为什么只看聚合的 outcome 分看不出来？跨 §1.3 + §3.3
  3. "下周建好 50 道题"：老板要你一周内沉淀一个 50 题的回归集。按本教程的立场，你动手做的第一件事是什么？为什么不是直接写 50 道题？跨 §3.4 + §2.5
  4. "90% 通过率"：你的 agent 在某基准上报告 90% 通过率，资深面试官追问可靠性。你怎么回答才显示你真的懂？至少点到两个概念。跨 §4.3 + §4.4
  5. 给个人情报员 Agent 评组件层：要评这个研究/简报 agent 的 RAG 组件层，你会建哪类样本、用哪些指标？其中 faithfulness 具体防住的是什么失败？跨 §3.5 + §1.3 + §2.1
  6. 给 agent 加运行期自评（B）：你想让 agent 生成后自评打分来提质量，却发现 generator 和 evaluator 是同一个 GPT-4o。最大风险是什么？上线这个 B 之前必须先做哪一步？跨 §5.3 + §5.4 + §2.3
亲手画一张图

合上教程，在纸上画评测的四层模型——只画 4 个堆叠 / 嵌套的框，并在每层旁边写一个"你最熟的那个 agent 在这层会犯的真实失败"。画完回到 §1.3 对照：你有没有把"换模型后最终答案没变、但 token 成本翻倍"这种失败放进轨迹层？大多数人会漏掉它，因为它在最外层的 outcome 分上完全看不见。

进阶挑战 · 刚好够不着

给你自己的 judge 设计一次"验证验证者"实验

挑一个你想用 LLM-as-a-judge 打分的真实任务。写出：① 你会标注多少条 golden set、谁来标；② 你用什么指标衡量 judge 和人类的一致（提示：不是裸百分比）；③ 如果两个标注员自己只同意 70%，你对 judge 的一致率上限有什么预期；④ judge 不达标时，你先改 rubric 还是先换 judge 模型，依据是什么。写完对照 §2.6。

提示（卡住再展开）

第 ③ 问是关键：judge 不可能比人类标注者之间更一致——人-人一致率是 judge 一致率的天花板。所以如果连专家都只同意 70%，要么是任务定义 / rubric 本身模糊（回去改判据），要么这个维度本就主观、不该用单一分数硬评。

§答案（先把三层都做完再展开）

展开全部答案

概念层

  1. A = 评测体系：开发期、离线的一套度量手段，对固定数据集跑、产出分数与回归报告，目的是防回归、让迭代有据（例：CI 里跑一个 50 题回归集）。B = 运行期 Evaluator：推理时在 agent 循环里"生成→评判→改进"的那个角色，目的是提升单次输出质量（例：Reflexion 让模型口头自评再重试）。同样"用模型打分"，但时机和目的完全不同。
  2. ① 非确定性：同样输入每次输出不同，没有固定期望值可断言；② 多步轨迹：planning→tool→reflect，错可能出在任何一环，最终答案对不代表过程对；③ 开放式无唯一正解：一份简报 / 一段总结没有 ground truth，且存在语义等价问题——意思对但字符串不等。
  3. 四层：结果层 outcome（任务最终成没成）/ 轨迹层 trajectory（过程对不对、工具选得对不对、几步、多少成本）/ 组件层 component（拆开某个零件单独评，如 RAG 检索）/ 安全合规层 safety（幻觉、毒性、格式、敏感词）。最常被忽略的是轨迹层——大多数人只看最外层 outcome，成本 / 绕路 / 工具误用的回归全藏在里面。
  4. faithfulness 测答案有没有脱离检索到的内容去编造（忠实度）；context recall 测该被召回的相关内容是否真的召回了（召回率）。两者都属于组件层（RAG 检索质量）。
  5. 说明表层词汇重叠类指标在语义等价上失效——意思相同、措辞不同就被判 0 分。这逼出了LLM-as-a-judge：用一个会"读懂意思"的模型按 rubric 打分，而不是比字符串。

原理层

  1. pointwise：按 rubric 给单个输出打分，O(n) 可扩展，适合大规模粗筛，但绝对分会漂移、抓不住小差距；pairwise：判 A/B 谁更好，信号最细、最适合"选版本"，代价是 O(n²) 调用且对顺序敏感；reference-guided：把 gold answer 塞进 prompt，只在有客观解（数学 / 代码）时可用，但能显著提升可靠性。pairwise 的主要代价是调用量二次方增长。
  2. 缓解法：交换 A/B 的呈现顺序各判一次，只有两个顺序都判同一个赢家才算赢，否则记平局。它比取平均更对，因为这是一道一致性闸门——若调换顺序结论就翻转，说明这次判定是被位置带偏的、不可信，应当作平局丢弃，而不是把一个可信结果和一个不可信结果平均成一个似是而非的数。
  3. 因为 LLM 只吐整数，且在 1–5 里某一位数字（如"3"）的概率独大，导致分数方差极小、大量平局，与人类评分的相关性差。按 token 概率加权求期望，把离散整数变成连续分，能拉开细微差距、提升与人类的相关性（G-Eval 在 SummEval 上 ρ≈0.514）。
  4. 不够。裸一致率会被随机一致和类别不均衡抬高——80% 裸一致可能只相当于 Cohen's κ≈0.62。还要补看：① Cohen's κ（去掉随机一致后的真实一致）；② 人-人一致率这个天花板——judge 不可能比人类标注者彼此更一致。
  5. 因为 Likert 分级判据模糊，两个评分员对"3 分还是 4 分"理解不同，judge 也会噪声大、不可复现；而从真实错误里提炼的二元判据把"好不好"拆成一串"有没有犯这个具体错误"的是非题，可复现、可定位、可回归。补充：判据是边看数据边迭代出来的（criteria drift），不是一次写死的。

应用判别层

  1. 用 pairwise——"选更好的版本"正是 pairwise 的主场，且开放式任务没有 gold answer，pointwise 的绝对分不可靠。judge 选一个和 generator 不同家族的强模型，并交换顺序消 position bias。不能用同款模型，因为 self-enhancement bias（judge 偏爱自己家族的输出）外加共享盲点——同款模型会一起在同一个错误上犯错却给高分。
  2. 漏的是轨迹层（trajectory）里的 cost。聚合 outcome 分只回答"答得对不对"，不记录"花了多少 token / 几次工具调用"；换模型后最终答案可能没变，但单次轨迹从 3 步膨胀到 10 步，这种成本回归只有 per-case 记录 n_tokens / n_toolcalls 才看得见。
  3. 先做错误分析：人工读 20–50 条真实 trace，把发现的失败归类。不是直接写题，因为凭空写的题测的是"你想象的错误"，而真实分布里的错误往往不在你的想象里；rubric 和数据集都应当由读 trace 发现的真实失败来定义（Hamel 的 error-analysis-first 立场）。"先沉淀 20 query"的正确读法是"先读 trace，再沉淀由真实失败构成的 20 query"。
  4. 要点：① 单次 pass@1 掩盖非确定性，"90%"下一次跑可能就不是了，应报 pass^k（k 次是否全过）这类可靠性指标；② 高位榜单分要警惕数据污染与饱和（SWE-bench 顶部已 ~0.94）；③ 还应同时看成本（HAL 在 ICLR 2026 把可靠性和成本摆到和能力同等位置）。能点到 pass^k 与污染 / 成本，就显示你超出了"刷榜"层面。
  5. 样本：覆盖正常主题简报 + 边界（冷门主题召回稀疏、非英文源、信息极少时不该硬编）+ 对抗（抓取网页里藏指令注入、转载需去重、矛盾来源）+ 敏感（监管 / 政治类需正确路由或拒答）。指标：组件层用 faithfulness（每条 [n] 引用都能在源文档里找到吗）+ context recall（关键事件漏没漏）+ dedup 生效率。faithfulness 具体防住的是"带着引用编造"——简报里挂了 [n] 看着有据，实际那句话源里根本没有，这种最伤可信度。
  6. 最大风险：generator==evaluator 同模型 → self-enhancement bias 拉满 + 共享盲点，agent 会自信地把"错得很流畅"的输出判为通过、收敛到错误答案。上线前必须先用 A 校准这个 B——拿人工标注的 golden set 量评判器判定与人工的 Cohen's κ，不达标就别接进循环（一个乱判的 B 比没有更糟）；理想情况再给评判器换一个不同家族的模型。