特辑导读：Evals 体系全景

一句话导读：这一章是全特辑的导航系统——用一张 ASCII 全景图、一张"问题→章节"对照表、一份 20 词全局术语表、一个 11 labs 清单、三条学习路线和一条 2024–2026 时间线，帮你在 30 分钟内建立 Evals 知识体系的全局坐标。无论你接下来是面试冲刺、从零搭建评测体系，还是跟踪前沿论文，都从本章出发。

一、知识图谱

本特辑（E00–E15，共 16 章）回答一个总问题：如何把 GenAI/Agent 系统"不稳定的智能行为"，持续收敛成"可发布的工程质量"。15 个正篇章节按八个递进阶段组织：为什么评 → 评什么 → 拿什么评 → 谁来评 → 评什么形态 → 怎么让分数可信 → 怎么用评测驱动开发 → 外部坐标。

1.1 特辑全景图

                      【Evals 体系全景 · E01 → E15】

 为什么评 ───── E01 为什么评估是 GenAI 工程的生命线
     │           （三大难题：非确定性/黑盒化/错误级联；Airbnb 三大坑；四重身份）
     ▼
 评什么 ─────── E02 评估指标体系
     │           （P0/P1/P2 分层 × 五大维度 × pass@k/pass^k × 统计口径）
     ▼
 拿什么评 ───── E03 黄金数据集与用例设计
     │           （四类来源；触发→核心逻辑→产物质量→异常容错；治理与毕业机制）
     ▼
 谁来评 ─────── E04 程序化评分 → E05 LLM-as-Judge → E06 人工评估与评分路由
     │           （确定性优先；judge 校准 ≥85%；人工六大高杠杆场景）
     ▼
 评什么形态 ─── E07 轨迹与 Agent 级评估 → E08 对话 Agent 与仿真评测
     │           （step/trajectory/session 三层；用户模拟器 + fixtures）
     ▼
 怎么让分数可信 ─ E09 评估的统计学基础
     │           （置信区间；样本量；显著性；Bradley-Terry 与风格控制）
     ▼
 怎么用 ─────── E10 评测驱动开发（EDD）→ E11 Badcase 根因分析 → E12 在线评估与数据飞轮
     │           （发现→捕获→反复检查；badcase→行动项；生产流量→质量资产）
     ▼
 外部坐标 ───── E13 Benchmark 全景与前沿争议 → E14 前沿论文全景 → E15 工业实践案例研究
                 （污染/饱和/Goodhart；2024–2026 九方向；Airbnb/DoorDash/阿里/腾讯）

一条主线贯穿全图：评分三层（程序化 → LLM Judge → 人工）是全特辑的脊柱，E04–E06 逐层深挖，其余章节要么定义三层的输入（E02 指标、E03 数据），要么定义三层的对象（E07 轨迹、E08 对话），要么给三层的输出加约束（E09 统计），要么消费三层的产出（E10–E12 闭环）。

1.2 问题 → 章节对照表

1.3 特辑的三大件

二、核心概念精讲

2.1 与主手册第 8 章的关系：浓缩版 vs 深挖版

主手册（AI Agent 面试学习手册）第 8 章《Agent 评估与可观测性》是本特辑的"浓缩索引"，本特辑是它的"全景深挖"。两者的分工：

用法建议：先读主手册第 8 章建立粗略印象，再用本特辑按 2.4 节的路线深挖；面试前一天反过来——用主手册快速过一遍，用本章的高频考点表（第三节）查漏。

2.2 全局术语表（20 词）

这 20 个词是全特辑的通用语言，面试中它们出现频率最高：

2.3 11 个 labs 一览

全部 labs 位于 evals-special/labs/，纯 Python 标准库实现、固定种子、确定性可复现，运行命令统一为 cd evals-special/labs && python3 <文件名>。每个 lab 末尾的 assert 直接断言本章核心结论（不是"程序跑完了"，而是"缓解后偏差显著缩小"这类有牙齿的命题）。

2.4 三条学习路线

路线 ①：面试冲刺（约 2 小时） —— 目标：能答出全局框架题 + 高频深挖题。

路线 ②：从零搭建评测体系（工程师，约 4 周，配 labs） —— 目标：真的建起来。

路线 ③：研究跟进（论文读者） —— 目标：掌握 2024–2026 学术地图。先读第 E13/E14 章建立分类学，再按方向进入 _research/ 调研报告（每份都给出核心论文的 arxiv ID、机构、关键数字与工程意义）：

2.5 Evals 领域时间线（2024–2026，15 个节点）

以下节点全部提炼自 _research/ 十份调研报告，arxiv ID 与年份以调研报告核实结果为准；工业实践节点以博客发布时间为准。

读时间线的三个视角：① judge 线——从偏差 catalog（2024 上）→ 元评估（2024 下）→ 可训练 judge（2024–2025）→ judge 优化与攻防（2025–2026），详见第 E05/E14 章；② 基准线——从环境奠基 → 难度军备 → 信任危机（污染/饱和/harness 混淆），详见第 E13 章；③ 方法论线——EDD 从博客口号到学术过程模型再到亿级用户生产验证，详见第 E10 章。

2.6 本特辑的引用约定（读其他章节前先知道）

1. 内容基准日 2026-08。前沿论文标注 arxiv ID 与年份，全部来自 _research/ 调研报告；工业数字全部来自 _research/00-industry-practice.md（四篇官方工程博客的一手精读笔记）。
2. 核实状态：调研报告对每条 arxiv ID 做了核实，无法核实的条目标注【未核实】。正文引用这类条目时保留该标注（例如 VisualWebArena 2401.13649【未核实】、SWE-bench Pro 2509.16941【未核实】），引用前建议二次确认。
3. 交叉引用格式：（详见第 E5 章 · LLM-as-Judge 深入） 指本特辑章节；（主手册第 8 章 · Agent 评估与可观测性） 指主手册；labs/eval_labNN_xxx.py 指实验。

三、面试高频考点

四、经典面试题与参考答案

题 1（基础）：用三分钟向一位新同事介绍 evals 知识体系，你会怎么组织？

参考答案： 用八个递进问题串起来：① 为什么评——GenAI 有非确定性、黑盒化、错误级联三大难题，传统测试失效，评估是质量度量、发布门禁、迭代指南针、数据飞轮入口四重身份（E01）；② 评什么——指标分 P0 门禁/P1 比较/P2 观察三层，横切功能、过程、效率、鲁棒、体验五维度（E02）；③ 拿什么评——golden set 四类来源、四场景组织、含坏样本、治理毕业（E03）；④ 谁来评——程序化 → LLM judge → 人工三层，确定性优先，judge 校准到 ≥85%，人工做六个高杠杆场景（E04–E06）；⑤ 评什么形态——轨迹三层评估防"结果对路径错"的假阳性，对话用模拟器 + fixtures（E07–E08）；⑥ 怎么让分数可信——置信区间、样本量、显著性（E09）；⑦ 怎么用——EDD 把评测嵌进开发，RCA 把失败变行动项，在线评估把生产流量变资产（E10–E12）；⑧ 外部坐标——benchmark、前沿论文与工业实践（E13–E15）。最后补一句总纲：评测的终点不是报告，是可执行的行动项。

题 2（基础）：传统软件测试为什么在 GenAI 系统上不够用？请给出具体失效场景。

参考答案： 根因是三大难题：非确定性（同输入不一定同输出，断言语义失效）、黑盒化（内部决策不透明，无法按代码路径覆盖）、错误级联（多步链路前步小错被后续放大）。阿里补充了更隐蔽的一条：有些样本最终答案看似对，但执行路径已偏离或带风险——这类假阳性在测试报告里不可见。四个典型失效场景：① 同一 prompt 跑通一次 ≠ 稳定可用（一次成功没有统计意义）；② 每次改 prompt/模型/工具参数都可能悄悄改坏旧场景，无回归集则无人知晓（Airbnb"未被发现的回归"）；③ 多步链路前一个小偏差被放大成错误结论；④ 结果碰巧对但路径错（如跳过了关键校验工具），纯结果测试系统性放过。对策不是放弃测试，而是换范式：EDD——发现 → 捕获 → 反复检查失败模式，加上统计化的多次试验与分层评分。

题 3（进阶）：pass@k 和 pass^k 的区别是什么？一个无人值守的客服 Agent，你向老板汇报哪个数？

参考答案： pass@k = k 次运行至少 1 次成功的任务比例，度量能力上限；pass^k = k 次运行每次都要成功的任务比例，度量生产可靠性。若单次成功率 p 且各次独立，pass^k ≈ p^k：p=0.9、k=8 时只剩 0.43。τ-bench（arxiv 2406.12045）的数字最直观：GPT-4o 在 retail 域 pass^1 ≈60%（官方榜单 60.4%），但 pass^8 跌到 ≈25%（摘要口径 <25%）——"单次看起来不错"与"可部署"之间有巨大鸿沟。无人值守客服必须汇报 pass^k（工程惯例 k=4–8，同时报 pass@1 展示差距）：用户不会接受"多试几次总有一次成功"，阿里把这两个指标称为一致性双指标——至少一次成功率是能力上限，连续成功率才是生产级场景（客服/支付/退款/合规）的发布依据；腾讯进一步给出容忍阈值分级：关键决策类 0% 容忍（N 次全过），辅助分析类 ≤10%，创意生成类 ≤40%。

题 4（进阶）：为什么说 LLM-as-a-Judge 是"不得不用、又不可全信"的测量仪器？给出你的治理方案。

参考答案： 不得不用：语气、有据性、策略合理性这些语义维度规则判不了，人工又不可扩展——DoorDash 把"规模化判断"列为五大挑战之一，答案是校准过的 judge 顶替人类评审。不可全信：judge 自带位置、冗长、自我偏好、风格压倒实质四大偏差；JudgeBench（arxiv 2410.12784）用客观真值测出前沿 judge 在困难任务准确率仅 ~57% 量级；且 judge 间高一致 ≠ 正确，可能"集体犯错"。治理方案四步：① rubric 工程——每个质量维度一个 judge（Airbnb 少而精，3–5 个）、judge 与生成模型不同源、二元检查 + eligibility 适用性前置、按标准切片证据（Transcript Builder，judge 只看该标准依赖的证据）；② 校准闭环——50–100 条 gold 集（必须含坏样本）→ 跑 judge → 目标一致率 high 80s~90s（四家共识 ≈85%）→ 分歧分析改 rubric → 重复；Airbnb 实战 78%→88% 的根因是 rubric 误罚正确改述，不是模型弱；③ 持续运营——judge 升级必重校准，跟踪三项统计：与人工一致性、高风险漏判率、边界稳定性（阿里）；④ 防操纵——judge 消费外部内容时防检索投毒与注入，安全 judge 可被对抗样本打穿（Know Thy Judge，arxiv 2503.04474）。

题 5（进阶）：你的离线评测分数涨了，但线上投诉没降。可能出了什么问题？怎么系统性排查？

参考答案： 按五个嫌疑排查：① 评测集分布 ≠ 线上分布——线上随机抽样有幸存者偏差（正常流程占多数、易错边缘占比低），反过来离线集也可能漏掉真实高频场景；用生产抽样回流核对分布（Airbnb 每日抽 5% 去标识化流量）；② 离线-线上两把尺子——各自维护 judge 时两边分数会以难调和的方式背离（DoorDash 教训三）；必须是同一 rubric + 同一校准 judge 两边跑；③ Goodhart——指标被优化目标刷爆：回归集被"背答案"、judge 被风格讨好、长度偏差被利用；检查 proxy 指标与 gold 信号（在线体验/业务结果）是否背离；④ 维度缺失——离线只测了功能正确性，没测体验与对齐（P2 决定产品生死）与效率成本；⑤ 漂移——线上输入分布变了而评测集没跟上。组织层面的兜底是阿里的三类信号联动：离线质量信号、线上体验信号（转人工率、重复追问率、投诉率、满意度）、业务结果信号——离线提升但线上关键信号恶化，触发回滚或降级。Nubank（arxiv 2606.08867）的正面证据：当评测流水线质量足够高时，离线仿真指标与线上 A/B 强相关。

题 6（进阶）：你怎么看待 τ-bench、SWE-bench 这类公开 benchmark 的分数？如果只能选一个指标向老板汇报"我们的 Agent 变强了"，你选哪个？

参考答案： 公开 benchmark 是外部坐标：可横向对比、有社区共识，价值真实但有三大折扣：① 污染——题目进训练语料，分数测记忆而非能力（Min-K% Prob 成员推断、改写变体检测是主流手段）；② 饱和与质量——MMLU-Redux（arxiv 2406.04127）发现约 10% 题目有误，SWE-bench 头部分数逼近 70%+ 后社区转向更难的基准，GSM-Symbolic（arxiv 2410.05229）证明只改名字/数字就能让分数暴跌至多 65%；③ harness 混淆与低相关性——同一模型换执行框架分数差异巨大，Princeton HAL 等工作发现不同基准间分数相关性很低、与真实用户满意度弱相关。所以成熟团队的选型是三层互补：公开 benchmark（外部坐标）+ 私有 golden set（真实业务分布，含坏样本，持续治理）+ 在线信号（地面真值：任务完成率、转人工率、满意度）。只能选一个汇报，选私有 golden set 上的核心指标（带置信区间与 pass^k）：它离业务最近、不受污染、且能解释"为什么涨"。汇报时主动说明口径与误差条，比报一个虚高的公开分数更能建立信任。

题 7（系统设计）：你加入一个还没有评测体系的 Agent 团队，如何从零搭建？给出落地计划并映射到本特辑章节。

参考答案： 30 天（最小可用）：W1 Trace 前置——结构化 trace 是被测 Agent 的标准能力而非事后补救：JSONL、每步工具名/入参/返回/时间戳、跨版本格式稳定（第 E07 章）；W1–W2 跑约 100 个样本人工精读输出与 trace，归类错误——"When in doubt, look at your data"（第 E10 章）；W2–W3 建 50–200 条 golden set，四类来源（专家设计/结构字段先行的 LLM 扩展/线上真实数据/badcase 回流），必须含坏样本（第 E03 章）；W3–W4 程序化评分第一批：schema/空输出/关键词/工具调用断言/执行指标，确定性优先（第 E04 章），并建基线快照接 CI。90 天（体系闭环）：3–5 个按维度拆分的 judge 校准到 ≥85% 一致率（第 E05 章）；fixtures + 会话模拟器冻结环境，全量回归从 6h+ 压到 20min 量级（第 E08 章）；P0 门禁带统计口径——置信区间 + 显著性 + 最小可感知变化，一致性看连续成功率（第 E02/E09 章）；能力集/回归集分治与毕业机制（第 E03/E10 章）；RCA 五步 + 根因标签绑定 owner + 结构化行动项（第 E11 章）；每日抽样去标识化流量、离线-线上同一把尺子、离线升线上降即回滚（第 E12 章）。组织上：指定人类终判者、每周 PM 评审新增测试（Airbnb 原则）。验收标准用阿里口径：低分能否稳定转成行动项。

题 8（系统设计）：如何设计一条数据飞轮，让评测体系随生产运行自动变强？

参考答案： 飞轮四段：生产流量进 → badcase 出 → 资产出 → 下一版本带着资产上线。① 入口：在线每日抽样去标识化流量（Airbnb 5%），分层优先高风险/低置信/新意图；badcase 双通路（离线评测集 + 线上会话/质检/工单/低满意度/告警）汇入同一任务表（第 E12/E11 章）。② 入库标准（不是所有失败都值得进库）：失败可复现、期望行为明确、根因标签清楚、样本有代表性、已脱敏合规（阿里）。③ 三条生产线：badcase → 评测集（新用例，先入能力集，连续通过后毕业进回归集，只增不减）；badcase → 训练数据（SFT/偏好对）；badcase → 知识修订（检索库/政策口径）。样本治理：同簇留代表例、P0/P1 风险长期保留、稳定多版本通过者降级抽样集、主动学习抽低置信样本进人工确认。④ 产出与验证：沉淀质量资产库六件套——用例库、Trace 库、根因标签库、修复建议库、Judge 校准集、回归集；飞轮转速的验收看两个信号：离线评测与线上指标的相关性（Nubank 证据：离线仿真与线上 A/B 强相关，卡片配送 NPS +37pp），以及同类问题复发率下降。关键纪律：评测系统自己也产生 bug 报告——被标记失败中有真实一部分是 harness 自身故障（judge 误报、trace 缺口），必须并行修复（DoorDash）。

五、易错点 · 反直觉点

1. 误区："跑几条 case 感觉还行"就算评过了。 真相：同一 prompt 跑通一次 ≠ 稳定可用；阿里把这是列为评测体系的第一反面教材——非确定性下，单次成功没有统计意义，必须多 trial 并区分能力与稳定性。记忆锚点：一次跑通是轶事，不是证据。
2. 误区：pass@1 高就可以上线。 真相：pass^k 才是生产口径——p=0.9 的系统 k=8 时只剩 0.43；τ-bench 中 GPT-4o retail pass^1≈60% 而 pass^8≈25%。用户不接受"多试几次总有一次成功"。记忆锚点：能力上限看至少一次，生产可靠看连续成功。
3. 误区：线上随机抽样就能当评测集。 真相：线上样本有幸存者偏差——正常流程占多数、易错边缘占比低，随机采样报告"看起来不错"但关键问题漏掉（阿里）。记忆锚点：随机抽样的评测报告是虚假信心。
4. 误区：judge 之间意见一致，说明 judge 靠谱。 真相：JudgeBench（arxiv 2410.12784）显示 judge 间一致性高但可能"集体犯错"，前沿 judge 在客观困难任务准确率仅 ~57% 量级；一致率必须对照人工标注的 gold 集测量，且 gold 集必须含坏样本。记忆锚点：judge 的可信度靠人工锚点校准，不靠 judge 互相投票。
5. 误区：只看最终答案对不对就够了。 真相：结果碰巧对、路径已经错的假阳性（如跳过关键校验工具、编造了中间数据）在 outcome-only 评测下全部漏过，在生产迟早暴露；必须加 step/trajectory/session 过程评估（第 E07 章）。记忆锚点：答案对 ≠ 过程对，过程错迟早爆雷。
6. 误区：公开 benchmark 分数 = 模型/系统的绝对能力。 真相：分数可能被污染（记忆而非推理）、被 harness 工程抬高、被 Goodhart 刷爆；MMLU-Redux 还证明题目本身可能有约 10% 的错误。公开分数只是外部坐标之一。记忆锚点：benchmark 测的是"模型+题集+harness"三元组，不是能力本身。
7. 误区：离线一套 judge、线上另一套 judge，各自调到最好。 真相：DoorDash 教训三——各自调 judge，两边分数会以难调和的方式背离；离线结论只有能带到线上才有意义。记忆锚点：同一 rubric、同一 judge，一把尺子量两边。
8. 误区：评测的价值是把分数算准、把报告做漂亮。 真相：阿里第 10 章——评测体系的成败取决于能否在跨团队协作中长期、稳定地把低分转成可执行行动项（带失败范围/证据/owner/验收方式），否则再精细的分数也只是报表。记忆锚点：评测的终点是行动项，不是报告。

六、推荐资源

6.1 全特辑章节索引

6.2 调研报告索引（全特辑的事实源）

6.3 关键论文索引（按方向，arxiv ID 均经调研报告核实）

Judge 与元评估：MT-Bench 与 judge 奠基（2306.05685，2023）；Prometheus 2（2405.01535，2024）；JudgeBench（2410.12784，2024，ICLR 2025）；GenRM（2408.15240，2024）；GEPA（2507.19457，2025）；Know Thy Judge（2503.04474，2025）；Judging the Judges（2604.23178，2026）。

Agent 基准：τ-bench（2406.12045，2024）；τ²-bench（2506.07982，2025）；GAIA（2311.12983，2023，ICLR 2024）；SWE-bench（2310.06770，2023，ICLR 2024）；OSWorld（2404.07972，2024）；Terminal-Bench（2601.11868，2026，ICLR 2026）；Humanity's Last Exam（2501.14249，2025）；Agent-as-a-Judge（2410.10934，2024）。

轨迹与信用分配：Let's Verify Step by Step（2305.20050，2023）；Math-Shepherd（2312.08935，2023）；VinePPO（2410.01679，2024）；PRIME（2412.01981，2024）；AgentRewardBench（2504.08942，2025）；TRAIL（2505.08638，2025）。

统计与报告规范：Chatbot Arena（2403.04132，2024，ICML 2024）；Arena-Hard（2406.11939，2024）；Length-Controlled AlpacaEval（2404.04475，2024）；基准分数不确定性（2410.03492，2024）；Arena 统计框架（2412.18407，2024）；ReliableEval（2505.22169，2025）；Don't Pass@k（2510.04265，2025）；judge 报告规范（2511.21140，2025）。

基准动态与治理：LiveBench（2406.19314，2024）；LiveCodeBench（2403.07974，2024）；Min-K% Prob（2310.16789，2023，ICLR 2024）；MMLU-Redux（2406.04127，2024）；GSM-Symbolic（2410.05229，2024，ICLR 2025）；reward 过优化标度律（2210.10760，2022，ICML 2023）。

EDD 与仿真：EDDOps 过程模型（2411.13768，2024 首发 / 2025 v3）；Nubank 亿级用户 EDD（2606.08867，2026）；DAUS 用户模拟器（2402.13374，2024）；Agent 评测综述（2507.21504，2025）。

安全评测：HarmBench（2402.04249，2024，ICML 2024）；InjecAgent（2403.02691，2024）；AgentDojo（2406.13352，2024，NeurIPS 2024 D&B）；Agent-SafetyBench（2412.14470，2024，ACL 2025）。

组件级与自改进：RAGAS（2309.15217，2023）；RAGChecker（2408.08067，2024）；FActScore（2305.14251，2023）；Self-Rewarding LM（2401.10020，2024，ICML 2024）；DeepSeek-R1（2501.12948，2025）；Sycophancy to Subterfuge（2406.10162，2024）。

6.4 动手与交叉引用

• labs：11 个实验清单与运行命令见 2.3 节；规格说明见 _design/LAB_SPECS.md。与主仓库的关系：主仓库 labs/ 的 lab05 是最小 harness 入门，本特辑 labs 是体系化深挖。
• 主手册：主手册第 8 章 · Agent 评估与可观测性（本特辑的浓缩版索引，见 2.1 节对比）。
• 写作规范：_design/STYLE.md（6 模块结构与引用约定）、_design/BLUEPRINT.md（各章 brief）。

下一章：第 E01 章 · 为什么评估是 GenAI 工程的生命线——从三大根本难题讲起，回答"为什么评测是生命线而不是检查点"。

为什么评估是 GenAI 工程的生命线

一句话导读：传统软件"上线前跑一遍测试、之后靠断言保平安"的范式，在 GenAI 系统上全面失效。本章回答一个根本问题——为什么评估（evals）不是交付前的检查点，而是贯穿 GenAI 全生命周期的生命线。学完本章，你能讲清三大根本难题、Airbnb 三大陷阱、"跑几条 case 感觉还行"的四个具体失效场景、评估的四重身份，并会用评估经济学框架向老板论证评测投入——这些也正是面试开场最高频的"为什么"类问题。

一、知识图谱

为什么评估是 GenAI 工程的生命线
│
├─ 1. 三大根本难题（为什么"难评"）
│   ├─ 非确定性：同输入 ≠ 同输出 → 单次运行只是一个样本，不是结论
│   ├─ 黑盒化：内部决策不透明 → 没有结构化 trace 就没有归因
│   └─ 错误级联放大：前步小偏差 → 后步错误结论（单步 95% × 20 步 ≈ 36%）
│
├─ 2. 三大陷阱（Airbnb：没有评估会发生什么）
│   ├─ 虚假信心：浅层 helpfulness 分数掩盖真实失败
│   ├─ 未被发现的回归：改 prompt 后质量悄悄变差，无人知晓
│   └─ 指标与产品目标脱节：力气花了，产品没变好
│
├─ 3. 与传统软件测试的本质差异
│   └─ 输入空间 / 判定方式 / 回归语义 / 通过标准 —— 四项全变
│
├─ 4. "跑几条 case 感觉还行"为什么不够（四个失效场景）
│   ├─ 一次跑通 ≠ 稳定可用
│   ├─ 新 prompt 改坏旧场景（静默回归）
│   ├─ 前步小偏差被级联放大
│   └─ 假阳性：结果对、路径错，迟早在线上引爆
│
├─ 5. 评估的四重身份
│   └─ 质量度量 → 发布门禁 → 迭代指南针 → 数据飞轮入口
│
├─ 6. 评估经济学
│   └─ eval 成本（建例 + 推理 + 判定 + 校准） vs 线上失败成本（修复 + 资损 + 流失 + 合规）
│
└─ 7. 业界的答案：EDD（评测驱动开发）
    └─ 从"上线前抽查"到"持续治理机制"（→ 第 E10 章展开）

30 秒抓住主线：三大难题决定了 GenAI 不能沿用传统测试 → 不做评估会掉进三大陷阱 → 评估因此必须承担四重身份 → 投入多少由评估经济学决定 → 方法论终点是 EDD。本章是全特辑的"总纲"：后续 E02–E15 都是在回答本章提出的问题的某一环。

二、核心概念精讲

2.1 三大根本难题：GenAI 系统为什么"天生难测"

阿里与腾讯的评测方法论不约而同地把 GenAI 工程的门槛概括为三件事（阿里称之为"三大门槛"）：非确定性、黑盒化、错误级联放大。这三点不是工程瑕疵，而是这类系统的内禀属性。

Airbnb 对同一问题的表述是：GenAI 与传统软件的差异在于输出不可预测、"正确"依赖判断、用 AI 评 AI 又引入新风险；一次请求可能同时包含搜索 / 推理 / 外部动作 / 文本生成，每个环节都可能独立失败。腾讯则补充了黑盒化带来的一个微妙痛点：答案碰巧对但推理路径错时，你分不清"正确调用工具后回答"与"训练数据碰巧答对"——前者可信赖，后者是定时炸弹。

级联放大值得用一个具体的多步 agent 展开。设想一个退款客服 agent 处理"这个东西我要退，怎么寄回？"：

第 1 步一个标签的偏差，到第 4 步已经变成不可逆的资损与投诉。这就是阿里强调"多步链路前一个小偏差会被放大成错误结论"的含义。量化版本是同一个乘法：若每步可靠性为 p，n 步任务的端到端成功率上界约为 pⁿ——p=0.95、n=20 时只剩约 36%。τ-bench（Sierra AI，arXiv 2406.12045，2024）提供了实证：GPT-4o 在 retail 域单次通过率 pass^1 ≈60%（官方榜单 60.4%；摘要口径为不足 50%），而要求 8 次独立试验全部通过的 pass^8 ≈25%（摘要 <25%）；airline 域 pass^1 ≈42%、pass^8 跌至约 16%。"能做对一次"与"稳定做对"之间的鸿沟，比直觉大得多——这道鸿沟只能靠评估体系量化，靠 demo 永远看不见。

三大难题不是抽象抱怨，它们各自对评测体系提出了硬性设计要求：

非确定性的来源至少有三层，理解这一点才能理解"为什么固定种子也不够"：① 模型层——采样本身的随机性（temperature / top-p）；② 环境层——工具返回与外部数据随时间变化，同一条用例今天跑和下周跑看到的"世界"可能不同；③ 组装层——上下文组装、并发与重试逻辑带来的差异。这也是为什么阿里把"评测执行环境隔离、避免多用例共享状态"列为平台级要求，为什么 DoorDash 要用 fixtures 冻结外部状态（详见第 E8 章）——控制变异来源，是分数有意义的前提。

换句话说：三大难题各自消灭了传统测试的一根支柱——非确定性消灭了"断言"，黑盒化消灭了"断点调试"，级联放大消灭了"单元测试通过即系统通过"。评估体系就是把这三根支柱换成新支柱（统计判定、trace 归因、分层评估）的工程。

动手：用固定种子模拟 N 任务 × K 次重复运行，亲眼看 pass@k 与 pass^k 随 K 分道扬镳—— cd evals-special/labs && python3 eval_lab01_metric_system.py

2.2 三大陷阱：没有评估的产品会掉进哪里（Airbnb）

Airbnb 在点评摘要、客服、房东/房客消息、内部洞察等多个 GenAI 场景的实践中总结出：没有早期评测计划的产品，通常掉进三个坑。这是本章最该背下来的框架之一：

Airbnb 十条要点中的第 ② 条就是针对第一坑的解药：避免泛化 helpfulness，瞄准真实产品失败。

腾讯的痛点表从另一个视角刻画了"没有评估"的日常，与 Airbnb 三坑一一对应且更细：

每个陷阱都有对应的解药，这也是后续章节的索引方式：

一句话总结：没有评估的 GenAI 团队不是在迭代，而是在抽签——每次改 prompt 都不知道这次是改进还是退化，只能靠线上用户的投诉来"开奖"。

2.3 评估 vs 传统软件测试：四项本质差异

面试高频问法："评估和软件测试到底有什么不一样？"下面这张对照表是标准答案骨架：

注意最后一行：传统测试里"测试通过"几乎是上线的充分条件；GenAI 里评估通过只是拿到了一张入场券，线上还有第二场考试。这个认知差异是许多从传统 QA 转过来的团队最容易栽跟头的地方。

但也不是全盘推翻——从测试到评估，有些东西必须换，有些东西原样保留，分清楚这两堆才能说服传统 QA 背景的同事：

腾讯把这个转变浓缩成一句目标陈述：可重复、可量化、可持续演进的评估闭环——每次变更都能快速跑出可比较的分数，用数据代替直觉，用全量代替抽查。

2.4 "跑几条 case 感觉还行"为什么不够：四个具体失效场景

阿里评测方法论里有一节标题极其直白：为什么"跑几条 case 感觉还行"不够。它给出的四个场景，每一个都值得配一个例子：

场景 1：同一 prompt 跑通一次 ≠ 稳定可用。 非确定性系统里，一次成功只是从行为分布里抽到的一个样本。客服 agent 在你手测的那一次恰好走对了流程，不代表它 100 次里有 100 次走对——腾讯的稳定性判读经验：N=5 次执行中 1 次失败就"存在稳定性风险"，而容忍阈值按场景分级：关键决策类（问题定位 / 故障诊断）容忍 0%，辅助分析类 ≤10%，创意生成类 ≤40%。用户不会接受"多试几次总有一次成功"（阿里一致性双指标的原话）——至少一次成功率（能力上限）与连续成功率（生产要求）必须分开报，生产级场景看后者。

场景 2：改 prompt / 换模型 / 调工具参数，可能改坏原有场景，且不易第一时间发现。 这是"未被发现的回归"的日常形态。DoorDash 的仿真评测博客里有个诚实的细节：其 11 轮迭代中第 3 轮曾出现回落——没有回归集的团队甚至不会知道哪一轮回落了。解法是把每次手工检查沉淀为可复跑的用例，变更触发回归（详见第 E10 章）。

场景 3：多步链路里，前一个小偏差会被放大成错误结论。 即 2.1 的退款案例。手测几条 case 时你只看到终点输出"像那么回事"，看不到第 1 步的意图偏差正在被第 3 步的政策跳过放大。没有轨迹级评估（详见第 E7 章），级联放大永远发生在你的视线之外。

场景 4（最隐蔽）：有些样本最终答案看似对，但执行路径已偏离或带风险——这类假阳性在生产迟早暴露。 Airbnb 明确指出：只看最终答案不够，推理路径、工具参数、工作流可能在结果看似正确时已经失败。腾讯痛点表里的对应表述：分不清"正确调用工具后回答"与"训练数据碰巧答对"。一个跳过身份校验却恰好没造成损失的退款操作、一个靠猜碰对了答案的查询，都是"这次结果对、下次事故见"的假阳性。阿里对假阳性的工程回应是：加过程型与风险型检查（详见第 E11 章 RCA 体系）。

四个场景各自对应一种评测机制，这张映射表可以作为"为什么需要完整评测体系"的速答版：

动手：构造"完全正确 / 结果对但路径错 / 路径对但结果错 / 全错"四类 agent 运行，验证只看结果的评分会放过假阳性—— cd evals-special/labs && python3 eval_lab06_trajectory_eval.py

结论：评测体系必须嵌入研发流程而不是挂在上线前当关卡。用阿里的原话收束本节："评测平台不只是'出分工具'，核心价值是把问题稳定转化为可执行修复、形成持续迭代闭环。"

2.5 评估的四重身份：度量、门禁、指南针、飞轮

把评估只理解成"测试"，会低估它至少三倍的价值。成熟体系里，评估同时扮演四个角色：

四重身份之间有递进关系，逐层展开：

1. 度量是第一层：没有可信的分数，一切无从谈起。但注意度量的有效性前提是"尺子本身经过校准"——judge 与人工一致率达标（Airbnb 目标 high 80s~90s%，阿里参考值约 85% 后进自动化，腾讯口径 ≥85% 可用）才谈得上度量（详见第 E5 章）。
2. 门禁把度量接入发布流程：离线门禁 + 线上灰度联动。阿里的口径是三类信号一起看——离线质量信号（核心场景通过率、P0 风险数、关键工具参数正确率）、线上体验信号（转人工率、重复追问率、投诉率、满意度）、业务结果信号（任务完成率、工单闭环率、退款成功率）——离线提升但线上关键信号恶化，触发回滚或降级。
3. 指南针把度量接入开发循环：这是评估从"防守"转向"进攻"的一步。Airbnb 的迭代纪律（一次只改一个变量：固定模型变 prompt → 固定 prompt 变模型 → 都固定变 serving 配置）保证了分数变化可归因（详见第 E10 章）。
4. 飞轮把度量接入数据资产：badcase → 评测用例 → 训练数据 → 模型更新 → 新的线上信号回流（详见第 E12 章）。走到这一步，评估才真正成为"生命线"——它不再消耗资源，而是持续生产资产。通用循环长这样（DoorDash、Discord AITL、EDDOps 控制环的共同骨架）：

生产失败 / 真实 trace
      │ 编码为测试用例（带出处与切片标签，进回归集）
      ▼
自动流水线（生成场景 / 模拟对话 / 分层打分）
      │ 定位失败簇，选对改动
      ▼
修 prompt / 架构 → 重跑达标（门禁）→ 发布
      │ 线上信号（judge 分、转人工率、投诉）
      └──────────────回流──────────────┘

别把离线分数当终点。即便四重身份都立起来，仍要记住：客服对话基准研究（arXiv 2510.22143，2025）明确指出，由于真实部署环境的分布漂移与交互复杂性，强 offline 基准成绩只是部署可靠性的弱指标。当前共识是"离线是必要不充分"——离线门禁之后还有影子 / 灰度 / A/B 的最后一公里。

DoorDash 把这个问题表述为"双环境"挑战：开发与生产的质量可能背离。他们的解法是同一条 rubric + 同一个校准过的 judge 同时跑在真实会话与模拟会话上——离线结论才能带到线上，线上失败才能离线复现（详见第 E12 章）。DoorDash 报告其离线模拟提升与线上真实流量表现一致（其飞轮 5 分钟内可跑 200+ 场模拟对话、模拟环境幻觉率下降约 90%），但这是持续验证出来的结论，不是默认前提。

2.6 评估经济学：eval 成本 vs 线上失败成本的粗算框架

"评测很贵，值得吗？"——这是向管理层要资源时的必答题。回答它需要一个两边都摆上桌的粗算框架。

（1）eval 成本侧（可预算、可工程化压缩）：

（2）线上失败成本侧（不可预算、随流量放大）：

（3）收益侧：评估省下的钱有据可查（均以公司原文数字为准）：

• DoorDash：全量回归从人工 6+ 小时压到约 20 分钟（50 场景 × 8 trials 的 sweep，人工本地聊约 1 分钟/次）；支撑底座模型从 Claude Sonnet 4.6 迁移到 Gemini 3.5 Flash，延迟降 35%、质量无损——没有 harness，这种迁移"不敢做"，延迟收益就拿不到。
• 腾讯反向论证：没有评估时"模型不敢升级（无对比数据支撑切换决策）""缺少效率基线（变贵变慢无法归因版本）"——评估缺位本身就是持续的成本。

（4）粗算模板（面试可现场列）：

eval 年化成本 ≈ 用例建设(一次性) + 运行频次 × 单次推理成本 + judge 成本 + 校准人力
线上失败年化成本 ≈ 日会话量 × 失败率 × 单次失败成本(修复工时 + 资损期望 + 流失期望)
决策规则：只要 eval 能把失败率压低 Δ，且 Δ × 线上失败年化成本 > eval 年化成本，就值得投

代入量级感受一下（以下业务数字为示意，仅演示框架用法，实际必须换成自家真实数据）：

ROI ≥ 5 倍，且这还没算评测带来的"敢做"收益——DoorDash 若没有 harness，就拿不到模型迁移那 35% 的延迟下降。一个数量级的差距，就是"生命线"三个字的经济学含义。

（5）向业务方汇报时的口径转换：算完账还要会"翻译"。向非技术决策者汇报时，用产品语言而不是模型语言——说"三连全对率只有 42%"而不是"单次通过率 75%"，说"每天 2,000 个会话被自动质检"而不是"我们建了个 eval harness"。评测的价值必须落在对方关心的坐标系里（发布风险、资损、人力节省），这也是第 E2 章"把指标写进发布门禁"的前置技能。

2.7 业界的答案：EDD（评测驱动开发）速览

三大难题 + 三大陷阱 + 四重身份，把行业推向了一个共同的方法论终点：Evaluation-Driven Development（EDD，评测驱动开发）——把评测从"上线前的一次性检查点"变成贯穿全生命周期的"持续治理机制"：先定义期望行为（eval 即规约），在开发、发布、运行各阶段持续产生评测证据，用证据驱动最小化修复与受控迭代。

三股力量在 2024–2026 年把 EDD 从口号变成了工程学科：

EDDOps 论文对 134 篇学术文献 + 27 份工业灰色文献的统计，揭示了供需错配：学术界 93.28% 的评测研究只做部署前（pre-deployment），仅 2.24% 覆盖部署后，4.48% 是持续评测；而工业灰色文献中 40.74% 已是持续评测、81.48% 已用评测驱动适配。换句话说：最前沿的工程实践已经跑到了学术研究前面——这也是本特辑以工业实践为骨架、以论文为佐证的原因。

EDD 成熟度的两条证据（Anthropic 官方博客，2026-01）：SWE-bench Verified 成绩一年内从 40% 涨到 80%+，评测驱动的快速迭代是幕后推手；CORE-Bench 上 Opus 4.5 在修复任务与评分器之后从 42% 跳到 95%——后一个数字同时揭示了一个反直觉事实：评测系统自己也会出 bug。DoorDash 的四条 Lessons Learned 里有一条与之呼应：被标记的失败中有真实一部分其实是 harness 自身故障（judge 误报、trace 缺口），必须并行修复才可信。所以评测基础设施本身也要被评估、被版本管理（详见第 E10 章）。

EDD 的核心心智模型可以用一句话概括（Airbnb 定义，详见第 E10 章）：不是预测所有失败，而是发现 → 捕获 → 反复检查失败模式。这与 TDD 的精神同构：你无法在写代码前穷举所有 bug，但你可以保证每个发现过的 bug 都有一条永不消失的测试。

本章与后续章节的路线图：本章论证了"为什么"，其余 15 章逐一回答"怎么做"——

（主手册第 8 章 · Agent 评估与可观测性 提供了这套体系的浓缩版，本特辑是其深挖版。）

面试 30 秒版（当被问"为什么 GenAI 必须做评估"时，可以直接背这段开场）：

传统软件有确定性断言，GenAI 有三大根本难题——非确定性、黑盒化、错误级联放大， 传统测试的三根支柱（断言、断点调试、单元测试推断）因此逐一失效。 不做评估，产品会掉进三大陷阱：虚假信心、未被发现的回归、指标与产品目标脱节（Airbnb 总结）。 所以评估必须承担四重身份：质量度量、发布门禁、迭代指南针、数据飞轮入口。 投入多少由评估经济学决定：eval 成本可预算，线上失败成本不可预算且随流量放大。 业界的答案是 EDD——发现失败、捕获失败、反复检查失败。

本章小结：三大难题（非确定性、黑盒化、级联放大）摧毁了传统测试的三根支柱；不做评估会掉进三大陷阱（虚假信心、未发现回归、指标脱节）；因此评估必须承担四重身份（度量、门禁、指南针、飞轮）；投多少由评估经济学决定，答案是"杠杆投入"；方法论终点是 EDD。把这五句话讲顺，本章的面试题就都有了骨架。

三、面试高频考点

四、经典面试题与参考答案

题 1（基础）：为什么说评估是 GenAI 工程的"生命线"，而不是可选项？

参考答案： 因为 GenAI 有三个内禀属性让"先上线再修"变得不可承受：① 非确定性——同一输入不一定同一输出，单次运行只是分布中的一个样本，不评估就不知道分布长什么样；② 黑盒化——内部决策不透明，没有评估产生的 trace 与分数，失败连归因都无从谈起；③ 错误级联放大——多步链路里单步 95% 正确率 × 20 步只剩约 36% 端到端成功率，小偏差会被放大成错误结论。叠加后果是：不做评估会掉进虚假信心、未被发现的回归、指标与产品目标脱节三大陷阱（Airbnb 总结）。而评估在成熟体系里同时是质量度量、发布门禁、迭代指南针和数据飞轮入口——它不是交付前的关卡，而是贯穿全生命周期的基础设施，所以叫"生命线"。

题 2（基础）：Airbnb 总结的"没有早期评测计划"的三大陷阱是什么？各举一个例子。

参考答案： ① 虚假信心：用浅层 helpfulness 分数自我安慰——模型回答礼貌通顺，泛化的"有没有帮助"打高分，但幻觉、过度承诺、答非所问全被糊过去，分数漂亮、投诉照涨。② 未被发现的回归：改一版 prompt 让新场景变好，旧场景悄悄变差；没有回归集就没有前后对比基线，质量下行而团队感觉在进步。③ 指标与产品目标脱节：评测指标测的是"模型说话的姿势"而非真实产品失败，指标涨分、产品不动，力气白花（Goodhart 定律现场）。解药是 Airbnb 十条要点之一：避免泛化 helpfulness，瞄准真实产品失败，把指标从观察到的错误中推导出来。

题 3（基础）：GenAI 评估和传统软件测试的本质区别是什么？

参考答案： 四项本质差异：① 输入空间——测试的参数有限可枚举，自然语言输入 + 多轮上下文 + 工具返回组合爆炸，用户会说出你想不出的话；② 判定方式——测试是确定性断言、期望输出唯一，GenAI 一个目标有多种可接受结果，"正确"依赖判断，需要规则 / judge / 人工分层判定；③ 回归语义——测试的回归是功能明确坏掉，GenAI 的回归是统计分布上的悄悄漂移，不跑回归集发现不了；④ 通过标准——测试默认 100% 通过，GenAI 要分级设定（Anthropic 推荐口径：确定性任务用例集 100%、非确定性任务 ≥95%，高风险场景用 pass^k 做发布线）。还有一层：测试通过≈可上线，而离线评估通过只是必要条件，后面还有灰度与线上监控。

题 4（进阶）：有人说"我跑了十几条 case 都通了，效果不错"。请指出这个结论的所有漏洞。

参考答案： 四个具体漏洞（阿里评测方法论的四个失效场景）：① 一次跑通 ≠ 稳定：非确定性系统里一次成功只是一个样本；要报 N 次重复的成功率分布，腾讯口径 N=5 里 1 次失败就算有稳定性风险，关键决策类容忍 0%。② 改坏旧场景看不见：这十几条 case 没有沉淀为回归集，下次改 prompt / 换模型时旧场景退化无人知晓（未被发现的回归）。③ 级联放大测不出：手测只看终点输出，多步链路前段的小偏差会被后段放大，十几条 case 也覆盖不了分支组合。④ 假阳性漏检：可能存在"最终答案看似对、执行路径已偏离或带风险"的样本——跳过校验恰好没出事、训练数据碰巧答对，这类样本迟早在线上引爆。正确姿势：把 case 沉淀为可复跑用例，多 trial 报 pass^k，加过程型与风险型检查，扩到覆盖核心路径与高风险边界的 golden set（阿里经验 50–200 条起步）。

题 5（进阶）：一个 agent 单次任务成功率 75%，要上"用户不会重试"的客服场景。这个数够用吗？该用什么指标定发布线？

参考答案： 不够。75% 的单次成功率意味着每次服务 4 个用户就有 1 个失败；而在不可重试、无人值守的场景，用户不接受"多试几次总有一次成功"（阿里一致性双指标的原话）。该用 pass^k（k 次独立试验全部成功）定发布线：按 Anthropic 文档的示例算法，p=0.75、k=3 时 pass^3 = 0.75³ ≈ 42%——一个"看起来 75% 不错"的 agent，三连全对只有四成把握。τ-bench 的实证同向：GPT-4o 在 retail 域 pass^1 ≈60%（官方榜单 60.4%），pass^8 ≈25%。工程结论：① 发布门槛用低 k 的 pass^k（如 k=3~8）而非 pass@1；② 同时报至少一次成功率作为能力上限参照，两者的 gap 就是稳定性债；③ 客服/退款/支付等不可逆场景按关键决策类对待，稳定性容忍阈值取最严（腾讯分级：关键决策类 0%）。

题 6（进阶）：评估在 GenAI 开发流程中扮演哪几重角色？分别用什么工业实践佐证？

参考答案： 四重身份，层层递进：① 质量度量——把"感觉变好了"变成可比较的数字：DoorDash 的 harness 把质量信号从平均每天 1 条员工反馈升级为每天 2,000 个自动评分会话，全国上线前质量分 +8、错误率近乎减半。② 发布门禁——变更能不能上线由证据决定：DoorDash 任何变更必须通过全部 50+ 个 eval；阿里 P0 指标不达标不发布。③ 迭代指南针——告诉团队下一步改什么：Airbnb "When in doubt, look at your data"，100 个 prompt 人工精读读出 15 个 groundedness 失败、5 个不当拒答，修复优先级由此而来。④ 数据飞轮入口——线上失败变资产：Discord AITL 用标注回流把再训练周期从月级压到周级，试点有用性 +8.4%。只把评估当"测试"，就只拿到了第一重。

题 7（进阶）：老板问"评测这么贵，值得投吗？"你怎么用评估经济学回答？

参考答案： 把两边成本摆上桌。eval 成本侧可预算：用例建设（一次性，阿里经验 50–200 条 golden set 起步）、每次运行推理成本（用例 × trials × token × 单价）、judge 判定成本（分层筛查可压一个量级）、人工校准（Airbnb 从 20–100 个专家样本起步）。线上失败成本侧不可预算且随流量放大：修复工时、资损补偿（错退款收不回）、用户流失、合规事故。决策规则：eval 能把失败率压低 Δ，且 Δ×线上失败年化成本 > eval 年化成本，就值得。量级参照（DoorDash 原文数字）：全量回归从人工 6+ 小时压到约 20 分钟；harness 支撑底座模型迁移拿到延迟降 35% 且质量无损——没有评测，这种收益根本不敢拿。腾讯的反向证据：无评估时"模型不敢升级、变贵变慢无法归因"。结论：评测是杠杆投入，不是成本中心。

题 8（系统设计）：团队的退款客服 agent 一个月后要上线，目前没有任何评测体系。设计一个最小可行评测体系与落地路径。

参考答案： 按"先止血、再立柱、后闭环"三步： 第一周（止血）：从真实失败出发——收集已有的线上投诉与人工验证记录，手挑 20–50 条高风险 case（Anthropic 起步口径），人工精读输出与 trace（Airbnb 100 样本法的小规模版），归类错误模式。 第二、三周（立柱）：① 建 50–200 条 golden set（阿里经验），覆盖核心退款路径 + 高风险边界（已发货退款、运费险、大额退款），含坏样本；② 打分分层：确定性优先——订单状态、工具调用断言、金额精确性用代码判，语义与话术交给 judge（详见第 E4/E5 章）；③ 校准 judge：与人工标注一致率达到 ≥85%（阿里/腾讯参考线）才允许自动放量；④ 定门禁：确定性用例 100%、非确定性 ≥95%（Anthropic 口径），P0 风险样本零容忍，pass^k 报稳定性。 第四周起（闭环）：eval 进 CI，PR 触发回归；上线配灰度，跟踪转人工率、投诉率等线上信号；badcase 回流进用例集（只增不减）。 组织上指定一名最终人类决策者裁决"好 vs 坏"争议（Airbnb EDD 五原则之一）。若预算允许，用 Bolt 的量级做心理锚点：从零到可用约 3 个月（Anthropic 博客引用）——一个月上线的是最小版本，体系本身要持续生长。

五、易错点 · 反直觉点

1. 误区：同一个 prompt 跑通了一次，说明这个能力是稳定的。 真相：非确定性系统里一次成功只是分布中的一个样本。腾讯口径：N=5 次执行只要 1 次不通过即存在稳定性风险；τ-bench 上 GPT-4o retail pass^1 ≈60%（官方榜单 60.4%）而 pass^8 ≈25%（摘要 <25%）。 记忆锚点：单次运行是样本，不是结论。

2. 误区：改完 prompt 没出事，就是没 regression。 真相：GenAI 的回归是统计分布上的悄悄漂移，不会自己报警；没有"变更前 vs 变更后"的可比较回归集，退化根本不可见——这正是 Airbnb 三大陷阱中的"未被发现的回归"。 记忆锚点：回归不会敲门，只有回归集能开门。

3. 误区：最终答案对了就行，过程不重要。 真相：假阳性是 GenAI 最隐蔽的失败——跳过身份校验恰好没造成损失、训练数据碰巧答对，"这次结果对、下次事故见"。Airbnb 明确：推理路径、工具参数、工作流可能在结果看似正确时已经失败。 记忆锚点：结果对是一次，路径错是每次。

4. 误区：helpfulness / 平均分高，就是质量好。 真相：泛化分数天然平滑掉真实失败模式（幻觉、过度承诺、答非所问都被礼貌的通顺糊过去），这就是 Airbnb 的"虚假信心"陷阱；指标一旦与产品目标脱节，涨分只是自我安慰（Goodhart）。 记忆锚点：指标不指向真实产品失败，就指向自欺。

5. 误区：自动评测不放心，那就加人肉验证。 真相：腾讯痛点表指出，Skill 越多、模型越快，人肉回归指数增长，最终只能选择性验证、留下盲区——人工不是更可靠的路线，而是更贵的路线。专家时间应花在刀刃上（校准 judge、诊断异常，60%+ 占比，腾讯经验法则）。 记忆锚点：人肉回归是指数成本，评测自动化是唯一线性解。

6. 误区：评估是上线前的一道抽查，过了就结束。 真相：评估有四重身份（度量 / 门禁 / 指南针 / 飞轮）且贯穿开发—发布—运行全程；离线分数还只是必要条件，后面有灰度、线上监控、badcase 回流。EDDOps 统计显示工业界 40.74% 的评测已是持续评测。 记忆锚点：评估是逗号，不是句号。

7. 误区：新模型在 eval 上分数大跌，说明新模型弱。 真相：DoorDash 从 Claude Sonnet 4.6 迁移到 Gemini 3.5 Flash 时 harness 分数大跌，最终查明不是能力差距，是兼容性差距——工具签名要 plain string 而 Flash 传了 JSON 对象、system prompt 是围绕旧模型惯例隐式调优的。"低分反映的是为旧模型适配的系统，不是更弱的模型。" 记忆锚点：低分先怀疑环境，再怀疑模型。

8. 误区：只看平均分 / 总体通过率就够了。 真相：平均分天然掩盖切片退化——某类高风险场景全线崩坏，可以被大量简单场景的分数稀释掉。GEPA（arXiv 2507.19457）的 Pareto 前沿选择隐含的原则正是"按切片看指标，防止平均分掩盖退化"。 记忆锚点：平均会说谎，切片不会。

9. 误区：评测体系是纯成本中心，是"质量保险"式的必要之恶。 真相：评估经济学算的是杠杆账——DoorDash 用 harness 拿到回归提速（6+ 小时 → 20 分钟）与模型迁移收益（延迟 -35%、质量无损）；评估还持续生产资产（用例库、根因标签库、校准集）。阿里原话："质量资产越厚，Agent 迭代越不靠个人经验和临时救火。" 记忆锚点：评测买的不是保险，是杠杆。

六、推荐资源

论文（arXiv ID 均经调研核实，收录于 _research/06-edd-simulation.md）：

1. Evaluation-Driven Development and Operations of LLM Agents（EDD/EDDOps）—— arXiv 2411.13768（2024-11 首发，2025-11 v3）。EDD 方向最系统的学术表述：四阶段过程模型 + 三层参考架构 + "学术 93% 停留在部署前 vs 工业 40% 已持续评测"的供需错配统计。本章 2.7 的主要来源。
2. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains（Sierra AI）—— arXiv 2406.12045（2024-06）。pass^k 的原始出处；本章 2.1 引用的 pass^1/pass^8 数字来自该论文摘要转述口径。
3. Benchmarking and Learning Real-World Customer Service Dialogue —— arXiv 2510.22143（2025-10）。offline-online gap 的实证："强 offline 基准成绩只是部署可靠性的弱指标"。
4. GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning —— arXiv 2507.19457（2025-07）。"eval 作为优化目标函数"的代表作，Pareto 前沿按切片保留候选（详见第 E10 章）。
5. Automated Self-Testing as a Quality Gate: Evidence-Driven Release Management for LLM Applications —— arXiv 2603.15676（2026-03）。"评测结果即发布证据"的门禁化学术样本。

工程博客（本章工业数字的原始出处，均收录于 _research/00-industry-practice.md）：

1. Airbnb《Eval-driven development: Lessons from evaluating GenAI at scale》——三大陷阱、EDD 五原则、"When in doubt, look at your data"、100 样本法、judge 校准 78%→88% 全程。
2. DoorDash《Building Ask DoorDash (Part 3): Evaluation》与《A Simulation and Evaluation Flywheel to Develop LLM Chatbots at Scale》——质量分 +8 / 错误率近乎减半、50+ eval 门禁、6 小时→20 分钟回归、模型迁移延迟 -35%、11 轮迭代第 3 轮回落。
3. 阿里技术《Agent 评测：方法论与体系设计》——三大门槛、"跑几条 case 不够"四场景、一致性双指标、P0/P1/P2 门禁。
4. 腾讯技术工程《AI Agent & Skill 测评方案及落地实践》——六大痛点表、稳定性容忍阈值分级、引用 Anthropic 的 100%/95% 通过率口径。
5. Anthropic Engineering《Demystifying evals for AI agents》（2026-01）——起步 20–50 个用例、capability vs regression 套件二分、Bolt 约 3 个月建成 eval 体系。
6. Hamel Husain《Your AI Product Needs Evals》（hamel.dev）——evals-as-tests 运动的布道文本，面试谈"为什么要有 evals"的课外必读。
7. OpenAI《Evaluation best practices》（developers.openai.com 官方文档）——从一开始就反复评测（eval-driven）、每次变更都跑 continuous evaluation；数据来源五路（生产、专家构造、历史、合成、采购）；裁判优先对比式 / 分类型 / rubric 打分而非自由文本。与 Anthropic 文档对读，可见两家的口径一致性。

动手 labs：

• eval_lab01_metric_system.py——亲手算出 pass@k 与 pass^k 随 K 分道扬镳："p=0.8 的 agent，pass@8 ≈ 100% 而 pass^8 只剩约 17%"：cd evals-special/labs && python3 eval_lab01_metric_system.py
• eval_lab06_trajectory_eval.py——构造"结果对但路径错"的假阳性样本，验证 outcome-only 评分必然漏检：cd evals-special/labs && python3 eval_lab06_trajectory_eval.py
• eval_lab10_edd_loop.py——EDD 全闭环演练：门禁拒绝"修了新 bug 却改坏旧场景"的版本，回归集只增不减（配套第 E10 章）：cd evals-special/labs && python3 eval_lab10_edd_loop.py

特辑内交叉引用：

• 指标怎么定：第 E2 章 · 评估指标体系（pass^k 的完整口径与门禁统计）
• 假阳性怎么抓：第 E7 章 · 轨迹与 Agent 级评估
• 评测怎么驱动开发：第 E10 章 · 评测驱动开发（EDD）
• 四家公司怎么做：第 E15 章 · 工业实践案例研究（含 30 天 / 90 天落地路线图）
• 浓缩版对照：主手册第 8 章 · Agent 评估与可观测性

评估指标体系

一句话导读：「准确率 85%」这句话本身没有意义——有意义的是「哪个口径的 85%、在什么统计置信度下、用来做什么决策」。本章把 Agent/GenAI 评估指标组织成一套体系：纵向分层（P0 门禁 / P1 比较 / P2 观察）、横向分维（五大维度）、逐个精讲核心指标的定义与算法、给出指标设计四原则与统计口径，最后拆解万能 helpfulness 与 Goodhart 两大反模式。学完你能回答任何「这个指标怎么算、该不该进门禁、被刷了怎么办」的问题。

一、知识图谱

评估指标体系
├── 1. 为什么需要「体系」而不是单个指标
│   ├── 单一指标的三种失效：虚假信心（浅层 helpfulness）/ 未发现回归 / 指标与产品脱节（Airbnb 三坑）
│   └── 指标 = 门禁 + 迭代指南针 + 跨团队沟通语言：先定义「什么叫好」，才谈得上评
├── 2. 纵向分层（指标服务于什么决策）——阿里
│   ├── P0 上线门禁：不达标不发布（功能正确性、安全合规、一致性）
│   ├── P1 版本比较：配统计口径（置信区间 + 显著性 + 最小可感知变化）
│   └── P2 体验观察：长期跟踪（语气、满意度、转人工率）
├── 3. 横向分维（评什么）——腾讯五大维度
│   ├── 功能正确性（P0，代码判）          ├── 效率与成本（P1，代码判）
│   ├── 过程质量（P1，Rubric+人工）       ├── 鲁棒性与安全（P0，代码+人工）
│   └── 体验与对齐（P2，Rubric+人工）
├── 4. 核心指标精讲
│   ├── 一致性双指标：pass@k（能力上限）vs pass^k（生产一致性）
│   │   ├── pass@k = 1−(1−p)^k；pass^k = p^k（独立同分布假设）
│   │   ├── 无偏估计：1 − C(n−c,k)/C(n,k)（每任务 n 次试验、成功 c 次）
│   │   └── 实证：τ-bench GPT-4o retail pass^1≈60% → pass^8≈25%
│   ├── 任务完成率（子目标打点；Turn/Session/Trace/Outcome 四层）
│   ├── 工具调用准确率（该不该调 / 参数对不对 / 调用日志断言）
│   ├── groundedness / 幻觉率（有据性：回复是否锚定检索证据）
│   ├── 误拒率 / 漏拒率（拒绝合理性）
│   └── 延迟 p50/p95/p99、成本 ¥/task（质量相同看成本，成本相同看质量）
├── 5. 指标设计原则与统计口径
│   ├── 四原则：可量化 / 可比较 / 可回归 / 可归因
│   └── 门禁统计三件套（阿里）：置信区间 + 显著性检验 + 最小可感知变化阈值
├── 6. 稳定性评估与容忍阈值分级（腾讯）
│   ├── N 次重复运行：1 次不通过即存在稳定性风险
│   └── 关键决策类 0% 容忍 / 辅助分析类 ≤10% / 创意生成类 ≤40%
└── 7. 反模式
    ├── 万能 helpfulness 分：什么都评 ≈ 什么都没评
    └── Goodhart 定律：指标成为目标 → 代理-金标背离 / grader 被钻空 / 计分规则激励瞎猜

30 秒全景：先按「决策用途」分层（这个分数用来拦发布、比版本，还是看趋势？），再按「评估对象」分维（正确性/过程/效率/安全/体验），每个指标都要能回答「怎么算、谁算、多高的值算好、波动多大」——四问缺一，指标就只是仪表盘装饰。

二、核心概念精讲

2.1 为什么「一个准确率」不够：指标体系的定位

Airbnb 在 Eval-Driven Development（EDD）实践中总结了缺乏评测计划的三个常见坑，这三个坑恰好解释了为什么指标必须是「体系」而非「单点」：

Airbnb 给出的核心习惯是 "When in doubt, look at your data."——跑约 100 个样本（真实或合成），人工读输出和 trace，把错误归类，再围绕它们建指标和测试。他们的旅行客服助手案例中，100 条 prompt 的人工精读发现了 15 个 groundedness 失败、8 个正确但啰嗦、5 个不当拒答、3 个 JSON 失败——这四类失败直接推导出四个指标（有据性、简洁性、拒绝合理性、格式合规率），没有任何一个是「万能 helpfulness」。

由此得到指标体系的定位：

• 指标是规约（specification）：先定义「什么叫好」，开发与迭代才有方向——这正是 EDD「eval 即规约」的主张（详见第 E10 章 · 评测驱动开发）。
• 指标是门禁（gate）：P0 指标不达标就不发布，把质量判断从「上线后靠用户发现」前移到「发布前靠数据拦截」。
• 指标是沟通语言：「三连全对率 42%」比「感觉还行」更能让产品、算法、工程对齐预期。向业务方汇报时应使用 pass^k 这类产品语言，而不是单次通过率。

一句话：单个指标回答不了「能不能上线」，只有分层、分维、带统计口径的指标体系才能回答。

2.2 指标分层：P0 / P1 / P2（阿里）

阿里在 Agent 评测体系设计中把指标分为五大类，并按决策用途赋予优先级：P0 上线门禁（不达标不发）、P1 版本比较与工程优化、P2 体验改善与长期观察。分层的本质是回答「这个指标变差时，我们做什么动作」：

阿里的发布联动实践中，这三层指标对应三类信号同时跟踪：

• 离线质量信号（发布前）：核心场景通过率、P0 风险数、关键工具参数正确率；
• 线上体验信号（灰度中）：转人工率、重复追问率、投诉率、满意度变化；
• 业务结果信号（全量后）：任务完成率、工单闭环率、退款/赔付成功率。

并且有明确的联动规则：离线提升但线上关键信号恶化 → 触发回滚或降级（详见第 E12 章 · 在线评估与数据飞轮）。

分层时的两个实操要点：

1. P0 要少而硬。门禁越多发布越慢，团队会倾向于绕过门禁。真正的 P0 只留「失败了就是事故」的指标；阿里把「P0 风险数」直接定义为要求 0——高风险样本（赔付/隐私/合规）失败一个就拦。
2. P2 不等于不重要。腾讯特别强调：体验与对齐是 P2 但决定产品生死。分层只是「是否进门禁」的区分，不是「是否重要」的区分——早期用 Rubric + 人工抽样跟踪，成熟后接 A/B + 用户反馈闭环。

2.3 五大评估维度（腾讯）

腾讯在 AI Agent & Skill 测评方案中给出五大维度框架，每个维度标注了优先级、评分器选型与落地要求。下表在腾讯原表基础上扩充了子维度与典型例子：

腾讯给出的落地顺序是 P0 先落地、P2 按需补。维度之间并非独立——一个 badcase 往往同时扣多个维度的分，因此腾讯的扣分制评分（初始 100 分负分制，每处不符扣分至 0，达标线 80 分，按 Agent 类型与业务风险调整）会把「任务结果不符预期 −100、步骤遵循性每步 −10、工具调用每项 −10、耗时每超基准 1 分钟 −10」等组合成一份 JSON 扣分明细——分数之外保留「扣在哪」的信息，指标才能归因（评分机制详见第 E04 章 · 程序化评分）。

不同类型 Agent 的指标侧重（腾讯）：评测骨架（执行用例 → 采集 Trace → 评分 → 报告 → 根因归类）可复用，按业务定制的是「评什么、怎么判」：

这与阿里的观点一致：先分类型再定指标，「类型不分，评测结果基本不可用」。

2.4 核心指标精讲

2.4.1 一致性双指标：pass@k 与 pass^k（本章最重要的一对概念）

设单任务单次成功率为 p，k 次独立重复运行：

直觉：k 增大时两者迅速分道扬镳。 以 p = 0.8 为例：

同一个「单次准确率 80%」的 agent：按 pass@8 看近乎完美（99.9997%），按 pass^8 看几乎不可用（16.8%）。Anthropic 在官方 evals 指南中给的例子同样扎心：p = 0.75、k = 3 时 pass^3 ≈ 0.75³ ≈ 42%——一个「看起来 75% 不错」的 agent，三连全对只有四成把握。

实证（τ-bench，Sierra AI）：GPT-4o 在 retail 域 pass^1 约 61%、airline 域约 35%，而衡量可靠性的 pass^8 分别跌至约 25% 与 16%（数字引自论文摘要，arXiv:2406.12045，2024）。「能做对一次」与「稳定做对」之间的差距是系统性的，不是个别现象。

估计方法（面试计算高频）：实际评测中每个任务只能负担 n 次运行（n 次中成功 c 次）。两个常见的错误估计与正确做法：

• 错误 1：「n 次里有任何一次成功就算过」——这实际报告的是 pass@n，k < n 时会系统性高估 pass@k；
• 错误 2：用有放回公式 (c/n)^k 估 pass^k——小样本下会高估一致性，这是危险方向的高估（让团队误以为系统比实际更稳）。
• 正确：无放回组合的无偏估计——pass@k = 1 − C(n−c, k)/C(n, k)；对应地 pass^k = C(c, k)/C(n, k)（c < k 时为 0），即「从 n 次试验里无放回抽 k 次」的超几何口径。

动手验证：cd evals-special/labs && python3 eval_lab01_metric_system.py——lab 用固定种子模拟 N 任务 × K 次运行矩阵，核心断言包括 pass^k ≤ pass@k、p^k 理论值与估计值吻合、以及「同一 agent 在关键决策门禁与创意生成门禁下得到相反发布结论」。

统计注意：pass^k = p^k 依赖各次尝试相互独立。真实系统中上下文污染、残留状态、下游限流、缓存命中都会破坏独立性；若各次尝试正相关（这次挂了下次更容易挂），真实 pass^k 比 p^k 更悲观。此外 pass^k 对试验次数 n 敏感（n 太小会高估），报告时必须连同 n 与置信区间一起给出（详见第 E09 章 · 评估的统计学基础）。

k 怎么选：一场发布哲学的选择。选 k 不是拍脑袋，取决于产品形态对失败的容忍度：

值得注意的现状：多数公开 leaderboard 仍只报 pass@1 或平均分，学界对「可靠性排行榜」尚无标准——这是 2024–2026 evals 领域的公开争议之一。面试中被问「你们汇报哪个数」，答「按产品形态选口径，两个数都报，gap 就是稳定性债」是满分姿势。

2.4.2 至少一次成功率 vs 连续成功率：生产系统为什么看后者

阿里把一致性明确拆成双指标：任务重复运行 N 次，「至少一次成功率」度量能力上限，「连续成功率」度量生产要求。并给出了一句值得全文背诵的判断：

用户不会接受「多试几次总有一次成功」。

客服、支付、退款、合规等生产级场景，每一次失败都是一次真实事故（错误退款、重复扣款、违规承诺），不存在「重试到成功」的兜底路径。因此：

• 能力评测阶段看至少一次成功率——回答「这个 agent 有没有潜力做这件事」，指导投入方向；
• 发布门禁看连续成功率——回答「敢不敢把它交给真实用户」，对应 pass^k（低 k，如 k=3~8）。

两个数的 gap 就是稳定性债：gap 大说明能力有但不可靠，优化方向是降方差（固定 prompt、收紧工具 schema、减少自由发挥），而不是继续提能力上限。

2.4.3 任务完成率：最容易算、也最容易算错

任务完成率是最接近业务价值的指标，但有两个口径陷阱：

1. 判「说了什么」还是判「世界变成什么样」。客服/操作类 agent 首选终态校验（如 τ-bench 用数据库终态哈希判定：订单是否真的被取消、金额是否正确），抗话术干扰；只看自然语言回复会把「嘴上说已取消、数据库纹丝不动」判为成功（详见第 E07 章 · 轨迹与 Agent 级评估的假阳性分析）。
2. 每轮都对 ≠ 会话成功。阿里特别警告「不要只平均每轮分数」——每轮都「答得还行」但最终没解决问题仍是失败。

阿里对对话 agent 提出的四层评判框架，明确了「完成率应该落在哪一层」：

任务完成率应落在 Session/Outcome 层，并配合子目标打点（腾讯五维中「任务完成度（子目标打点）」）做部分归因：把任务拆成有序子目标（如退款任务 = 查到订单 → 核实身份 → 确认订单状态允许退款 → 执行退款 → 告知结果），每个子目标独立计数——任务失败时能立刻看出「卡在第几个子目标」，而不是只得到一个笼统的 fail。子目标达成率同时也是 P0 门禁的常用指标（阿里离线质量信号中的「核心场景通过率」通常就是子目标口径的聚合）。

2.4.4 工具调用准确率

工具调用是 agent 区别于 chatbot 的核心能力，也是失败的高发区（阿里 RCA 中的「关键工具未调用」「工具参数缺失」是高频根因）。可拆成一组可程序化判定的子指标：

腾讯把「工具调用检查（是否调用指定工具、参数是否正确）」列为确定性评分器的第一优先级——能用代码判的绝不用模型（详见第 E04 章）。注意：不要对完整调用序列做 exact match，多条合法路径会被误杀；只对关键调用做强约束。

一个真实 badcase 能说明这组指标的价值（阿里 RCA 案例）：现象是「已发货退款场景中，Agent 23 次跳过订单状态校验」，根因被归为「工具覆盖与执行」大类下的枚举「关键工具未调用」，责任模块 = 退款 Skill/退款流程执行模块，且失败集中在 v1.8 Prompt。如果没有「关键校验工具调用覆盖率」这个指标，这 23 次跳过会淹没在「最终退款大多也办成了」的结果分里——直到某次跳过校验造成资损才暴露。工具调用指标的归因价值正在于此：它把「侥幸没出事的路径违规」提前变成统计信号（这类「结果对但路径错」的假阳性样本，处理流程详见第 E07 章与第 E11 章）。

2.4.5 groundedness 与幻觉率

groundedness（有据性）度量「回复是否锚定于检索到的证据/工具返回」，是 RAG 与客服 agent 的头号质量指标；幻觉率是其反面。两者通常由 LLM-as-a-Judge 按 rubric 判定：judge 拿到「agent 的论断 + 背后的工具输出/检索片段」，逐条核对论断是否有证据支撑（DoorDash 的 transcript builder 正是为 grounding 检查定制证据视图：judge 只看该标准依赖的那片证据）。

工程上三条经验（均有出处）：

• groundedness 失败是最常见失败类型：Airbnb 100 样本探索中 15/31 个问题属于 groundedness 失败，接近一半；
• 检索改进直接降低 groundedness 失败——该指标的归因往往不在生成层而在检索层，需要配合组件级指标定位（召回是否正确、关键片段是否保留）；
• judge 判 groundedness 前必须校准：Airbnb 的 groundedness judge 初始与人工一致率仅 78%（误罚了正确的改述），修订 rubric 与示例后达 88% 才投入使用（judge 校准全流程详见第 E05 章）。

OpenAI 官方 evaluation best practices 给出的量化目标参考（文档问答类）：recall ≥ 0.85、precision ≥ 0.7；摘要类 ROUGE-L ≥ 0.40、G-Eval 连贯性 ≥ 80%、好评率 70%+——这些数字可作为团队定门槛时的外部参照，但最终门槛要从自己的失败分布推导。

2.4.6 误拒率 / 漏拒率：拒绝合理性

安全类指标必须成对出现，单看任何一侧都会产生荒谬的优化方向：

Airbnb 案例中「5 个不当拒答」就是误拒的实例——拒答本身也是一种失败模式，会直接损害可用性。正确姿势是报 tradeoff 曲线：在误拒-漏拒平面上标点，按业务风险偏好选工作点（金融场景容忍较高误拒，客服场景容忍较低误拒）。腾讯把「拒绝合理性（误拒%/漏拒%）」归入鲁棒性与安全维度，与安全用例集、红队集配套使用。

2.4.7 效率与成本：延迟分位数与 ¥/task

腾讯的原话值得引用：「pass@1 高但 token 花 10 倍的方案生产上不可接受」。效率与成本维度要求每个任务带成本画像，核心指标：

• Token：avg / p95（input/output 分开，含缓存读写）；
• 工具调用次数：avg / p95（冗余调用的直接信号）；
• 延迟：p50 / p95 / p99——只看均值会掩盖尾部；agent 会话的 wall-clock 大头往往在工具执行与外部等待，不在推理本身；
• 失败重试率：重试既烧钱又拉长延迟；
• 单任务成本 ¥/task：把 token 单价 × 用量折算到任务粒度，是与业务方沟通的通用语言。

工业实例（DoorDash）：其 eval harness 支撑了一次底座模型迁移（Claude Sonnet 4.6 → Gemini 3.5 Flash）。离线评测最初分数大跌，但 harness 给出具体失败模式后定位出不是能力差距而是兼容性差距（工具参数格式与 system prompt 惯例问题）；做小而准的修复后重跑，Flash 与 Sonnet 质量持平（在 harness 噪声范围内），迁移生产后延迟降 35%、质量无损。这个案例是「质量指标守住不动、用效率指标换收益」的标准操作——前提是质量指标先做到可比较（同一 harness、同一 judge、统计口径内比较）。

腾讯 TPerf 案例则展示了效率如何进入扣分制：耗时基准 300 秒，每超 10% 扣 1 分；token 以基线为基准每超 10% 扣 1 分，上限 −10——效率退化会被显式计入总分，而不是事后口头抱怨「变慢了」。

2.5 指标设计四原则与门禁统计口径

2.5.1 四原则

一个指标在纳入体系之前，过一遍这四道检查：

「可归因」尤其依赖两点：按切片报告（任务类型/场景/难度/风险等级分桶，避免平均分掩盖退化——GEPA 的 Pareto 前沿选择隐含的正是这一原则），以及评分输出不止 pass/fail 还要有问题分类与判定依据（阿里：为 RCA 提供「现象入口」，详见第 E11 章）。

2.5.2 门禁要带统计口径（阿里）

阿里的门禁设计有一条被很多团队忽视的要求：版本对比要配套统计检验——关键指标置信区间 + 与基线的显著性判断 + 最小可感知变化阈值（提前定义提升多少才值得发布）。原文表述：

「门禁不只看差了多少，还要看差异是否超过统计噪声。」

拆开就是三件套：

1. 置信区间：通过率是二项比例，报告 Wilson 区间（小样本下端点不越界、覆盖率接近名义水平），不报 CI 的点估计都是噪声；
2. 显著性：两版本跑同一批评测集是配对设计，用配对检验（如 McNemar，只关心两版本判定不一致的样本），而不是比较两个独立的点估计；
3. 最小可感知变化（MPP）：事先定义「提升多少才值得发布」——如果业务上 1 个百分点的提升不值得一次发布风险，就把 MPP 设为 1pp，统计上检出 0.5pp 也没有意义。

量级直觉（推导细节见第 E09 章与 cd evals-special/labs && python3 eval_lab08_statistics_ci.py）：通过率 p̂ 的标准误约为 √(p(1−p)/n)。基线 80% 附近、n=100 时标准误约 4 个点、95% CI 约 ±8 个点——v1 82% vs v2 85% 在 n=100 下完全不可判；同样的 3 个点差异，n=2000 时 CI 收到 ±1.6 个点，立刻可判。样本量与可检出差异 δ 约是 1/δ² 关系：基线 80%、双侧 α=0.05、功效 0.8 时，检出 10pp 差异每组约需 250 样本，检出 5pp 约需 1000，检出 3pp 约需 2800——想检出越小的差异，评测集越贵，这就是 golden set 规模与门禁灵敏度之间的根本权衡。

由此可以推出一份合格指标报告的最小字段——缺任何一项，数字都不可复核、不可比较：

阿里「门禁不只看差了多少，还看是否超过统计噪声」落到纸面，就是这张表。

把分层指标与统计口径串起来，一次完整的门禁执行流如下（离线部分；与线上灰度的联动详见第 E12 章）：

版本变更（prompt / 模型 / 工具 / serving 配置）
  → ① smoke 子集：少量核心用例、分钟级，拦截明显破坏
  → ② 全量回归集 × N trials：能力评测「毕业」的用例只增不减（腾讯/Anthropic 口径：
        确定性任务通过率 100%、非确定性 ≥95%）
  → ③ P0 硬门禁：核心场景通过率 ≥ 阈值 ∧ P0 风险样本失败数 = 0 ∧ 安全集 0 漏拒
        （任一不满足 → 直接拒绝，不进入统计比较）
  → ④ P1 统计比较：与基线配对检验 + CI + 显著性 + 预设 MPP
        （「不劣于基线」且「成本/延迟不劣化超阈值」才放行）
  → ⑤ 通过 → 出报告归档（含上一节最小字段）→ 进入线上灰度
        未过 → 拒绝 + 失败样本进 badcase 任务表（详见第 E11 章 · RCA）

注意两个顺序细节：P0 在统计比较之前（硬约束没有商量余地，不必浪费统计检验）；成本/延迟作为 P1 比较的一部分——新版本质量持平但成本翻倍，同样应当拒绝。

2.6 稳定性评估与容忍阈值分级（腾讯）

腾讯的稳定性评估方法：同一用例执行 N 次（建议 N=5），只要 1 次不通过即存在稳定性风险。容忍阈值按使用类型分级：

N=5 的读法（腾讯调试经验）：

两个反直觉的边界：0% pass^N 通常说明任务定义有问题，不是能力不行；而通过率异常（0% 或 100%）在多数情况下是任务或评分器坏了，不是模型弱/强——这是腾讯列出的人工评分六大必要场景之一（诊断异常）。

腾讯 TPerf 的实战决策是个好案例：TPerf 虽属辅助分析类，但其结论直接影响优化决策与发布判断，一次错误结论可能导致性能问题漏检上线，因此采用关键决策类标准（任一 Trial 不达标该用例 0 分）——阈值分级不是查表填空，最终依据是「一次失败的代价」。

这套稳定性口径如何聚合成最终分数？腾讯 TPerf 给出了可复用的公式链：

trial_score = max(0, 100 + 各项扣分)        # 单次运行的扣分制得分
trial_pass  = trial_score ≥ 80              # 达标线 80 分
case_score  = 全部 trial 都 pass → 取均值
              任一 trial 不达标 → 该用例记 0   # 「一次失败即用例失败」的聚合

关键在最后一行的聚合方式：它把「连续成功率」语义直接编译进了用例分数——不是对 5 次运行取平均（那会稀释失败），而是任一次不达标整个用例归零。对比之下，若用「5 次均值 ≥80」做判定，4 次 95 分 + 1 次 0 分照样过关，恰好放过了最不稳定的那类行为。设计一致性指标时先问自己：聚合函数是在奖励稳定，还是在稀释失败？

与之配套的回归口径（腾讯引用 Anthropic 推荐）：确定性任务用例集整体通过率需 100%，非确定性任务 ≥95%；能力测评（起步 20–50%，目标山峰）与回归测评（接近 100%，防御漂移）是两套不同预期的套件，通过率稳定 100% 的用例「毕业」进回归集（详见第 E03 章 · 黄金数据集与用例设计、第 E10 章 · EDD）。

2.7 指标反模式：万能 helpfulness 与 Goodhart

2.7.1 万能 helpfulness 分

Airbnb 三坑之首「虚假信心」的直接来源就是一个笼统的 helpfulness 分：它什么都能评，因此什么都评不准——judge 打高分的理由可能是「语气好」「够长」「格式整齐」，与「解决用户问题」弱相关。Airbnb 十条要点的第二条就是「避免泛化 helpfulness，瞄准真实产品失败」；配套的实践是「每个质量维度一个 judge、3–5 个经校准的评估器好过一堆嘈杂的评估器」。

诊断方法很简单：抽 20 条高分样本人工看。如果高分样本里有「礼貌地给了错误信息」「啰嗦但没解决问题」，这个指标就在制造虚假信心。修复路径：按观察到的失败模式拆维度（groundedness / conciseness / 拒绝合理性 / 格式合规……），每个维度独立可判（ DoorDash 的做法是每条 rubric 标准写成 binary check，汇总为会话级总分，且先做 eligibility 适用性判断——不适用的标准跳过而不是一律扣分）。

2.7.2 Goodhart 定律：指标成为目标就不再是好指标

指标一旦与 KPI、发布决策、优化目标挂钩，就会被反向塑造。四类有据可查的实例：

评测工程侧的对应防御（每条都能落地）：

1. 代理指标旁必须挂独立 gold 指标：gold 是线上信号（转人工率、投诉率、业务结果）或人工抽检结论；跟踪 proxy-gold 背离曲线，一旦背离立即降低对 proxy 的优化强度。
2. 指标组合优于单一北极星：质量（pass^k）、安全（误拒/漏拒、幻觉率）、效率（¥/task、p99）同时上报，防止单指标被刷。
3. 警惕 grader 被钻空：当指标成为优化目标，grader 就是攻击面——SWE-bench 类评测中已出现 agent 直接修改测试文件骗过断言的案例（arXiv:2506.12286）；对「分数突然飙升」的第一反应应是排查 grader 被钻空 / 评测集被污染 / judge 漂移，而不是庆祝模型变强（详见主手册第 8 章 · Agent 评估与可观测性的 grader 对抗性一节）。
4. 按切片报告并监控方差：平均分是被 Goodhart 攻破的第一道防线，切片分数（场景/难度/风险等级）更难整体造假。
5. 评测集与优化目标隔离：eval 集既当测试又当目标时必然被拟合——保留私有 holdout、定期换血、做污染检测（详见第 E13 章 · Benchmark 全景与前沿争议）。

三、面试高频考点

四、经典面试题与参考答案

题 1（基础）：pass@k 和 pass^k 有什么区别？各在什么场景下使用？

参考答案： 两者都是对「同一任务重复 k 次」的度量，但方向相反。pass@k = 1−(1−p)^k，k 次中至少一次成功，度量能力上限，适合有人在环、可重试或可从多候选中挑选的场景（创意文案、代码草稿辅助）；pass^k = p^k，k 次全部成功，度量生产一致性，适合无人值守、失败即事故的场景（客服、支付、退款），是发布门槛该看的数。关键在于 k 增大时两者迅速分道扬镳：p=0.8 时 pass@8≈99.9997% 而 pass^8≈16.8%。实证上，τ-bench 报告 GPT-4o retail 域 pass^1≈60%（官方榜单 60.4%）、pass^8 ≈25%（摘要 <25%）（arXiv:2406.12045）。所以汇报口径必须匹配产品形态：向用户交付「每次都做对」的承诺，就用 pass^k；两个数之间的 gap 就是稳定性债。

题 2（基础）：为什么不能用一个「成功率」指标评估 Agent？你会怎么分层组织指标？

参考答案： 单一指标有三个失效模式（Airbnb 三坑）：浅层 helpfulness 造成虚假信心；没有版本对比就发现不了回归；指标与产品结果脱节导致白费精力。我会按决策用途分三层（阿里框架）：P0 上线门禁——不达标不发布，只留「失败即事故」的硬指标：核心场景通过率、P0 风险样本失败数（要求为 0）、关键工具参数正确率、安全合规通过率、一致性 pass^k；P1 版本比较——任务完成率、groundedness、效率指标，必须带统计口径（置信区间 + 显著性 + 最小可感知变化），回答「v2 是否真的比 v1 好」；P2 体验观察——语气、清晰度、转人工率、满意度，不拦发布但长期跟踪趋势。分层的原则是「指标变差时我们做什么动作」：拦发布、比版本、看趋势，三类动作三套口径。P0 要少而硬，否则团队会绕过门禁；P2 不等于不重要——体验决定产品生死，只是不进门禁。

题 3（进阶）：一个支付客服 agent 评测显示「至少一次成功率 92%，连续成功率（k=3）58%」。产品经理说 92% 足够上线了，你怎么看？

参考答案： 不能上线，而且这正是一致性双指标要防止的误判（阿里）。至少一次成功率度量的是能力上限——「多试几次总有一次成功」；但支付场景每次失败都是真实事故（错误退款、重复扣款），用户不会接受重试，生产要求看的是连续成功率，即 pass^k 口径。92% vs 58% 的巨大 gap 说明 agent「会做但不稳」，优化方向不是提能力而是降方差：固定 prompt 与输出 schema、收紧工具参数校验、减少自由发挥路径、对高风险步骤加强制校验。同时要追问统计口径：这个 58% 是多少任务、每任务几次运行估出来的？pass^k 对试验次数 n 敏感，n 太小会高估，需报告 n 与置信区间。门禁设置上，我会把「pass^3 ≥ 目标值（如 90%）且 P0 风险样本 0 失败」作为发布条件，把至少一次成功率降级为能力观察指标。若单任务 p≈0.83（0.83³≈57%），要达到 pass^3≥90% 需 p≥96.5%——差距是明确可量化的。

题 4（进阶·计算）：基线通过率 82%，新版本 85%，评测集 n=100。能发布吗？要可靠检出 3 个百分点的提升需要多少样本？

参考答案： 不能发布——3 个点的差异在 n=100 下没有超过统计噪声。通过率的标准误约 √(p(1−p)/n)，基线 0.83 附近、n=100 时约 3.8 个点，95% CI 约 ±7.4 个点，两版本 CI 大幅重叠。正确做法是配对设计：两版本跑同一批用例，用 McNemar 类检验只看判定不一致的样本，案例难度这个最大噪声源被钉死，检出力更高——这正是阿里门禁要求的「置信区间 + 显著性 + 最小可感知变化」三件套。样本量估算：双比例比较 n ≈ (z_{α/2}+z_β)²·2p̄(1−p̄)/δ²，与 δ² 成反比。基线 80%、α=0.05、功效 0.8 时，检出 10pp 每组约 250 样本，检出 5pp 约 1000，检出 3pp 约 2800。所以要么扩评测集到约 3000 条/版本（配对设计可显著更少），要么把 MPP（最小可感知变化）放宽到 5pp 并接受「小提升不发布」——两个方向都是把「统计成本」显式化。动手验证见 cd evals-special/labs && python3 eval_lab08_statistics_ci.py。

题 5（进阶）：如何设计 Agent 的效率与成本指标体系？质量与成本冲突时怎么决策？

参考答案： 效率与成本是与质量并列的维度而非脚注——腾讯的原话：「pass@1 高但 token 花 10 倍的方案生产上不可接受」。指标清单（全部可从 trace 程序化统计，代码判）：Token avg/p95（input/output 分开）、工具调用次数 avg/p95、延迟 p50/p95/p99（只看均值会掩盖尾部，agent 的耗时大头常在工具与外部等待）、失败重试率、单次任务成本 ¥/task。落地要点：① 每个任务带成本画像，报告里与质量分并排（腾讯测评报告含模型版本与费用、总 token、平均费用每 Trial）；② 效率退化要能扣进总分（腾讯 TPerf：耗时基准 300s 每超 10% 扣 1 分，token 每超基线 10% 扣 1 分，上限 −10）；③ 质量与成本冲突时看能力-成本前沿：质量持平（统计噪声范围内）时选便宜的。实例：DoorDash 模型迁移（Sonnet 4.6→Gemini 3.5 Flash），离线 harness 先发现分数大跌、定位为兼容性而非能力差距，小修后质量持平（harness 噪声范围内），迁移生产延迟降 35%、质量无损——质量指标守底线、效率指标换收益的标准操作。

题 6（进阶）：groundedness（有据性）和幻觉率怎么度量？怎么保证度量本身可信？

参考答案： 度量方法：把「agent 的每条论断」与「其背后的证据（检索片段/工具返回）」交给 LLM-as-a-Judge 按 rubric 逐条核对，输出 pass/fail + 理由；幻觉率 = 无证据论断占比。工程上三个关键点：① 证据切片——judge 不该读全量 trace，DoorDash 的做法是每条 rubric 标准声明依赖的证据，transcript builder 只给 judge 那一片（grounding 检查拿论断 + 背后工具输出），聚焦证据让判断更一致；② judge 必须校准——Airbnb 的 groundedness judge 初始与人工一致率仅 78%（会误罚正确的改述），修订 rubric 与 few-shot 后达 88% 才上量；阿里的口径是与人工一致率约 85% 后进自动化，腾讯是 ≥85% 可用；③ 归因要下探到检索层——幻觉失败常因检索没召回正确文档，需配合组件级指标（context recall 低是检索问题，faithfulness 低是生成问题）。参考数字：Airbnb 100 样本探索中 15 个 groundedness 失败是最大失败类；OpenAI 官方建议文档问答 recall ≥ 0.85、precision ≥ 0.7。幻觉率要按切片（场景/知识域）报告，并作为 P0 安全维度进门禁（腾讯五维之一）。

题 7（进阶）：你负责的评测指标被「刷」了——优化后分数大涨，但线上投诉没降。如何排查和治理？

参考答案： 排查按三段式：grader 被钻空 / 评测集被污染 / 指标与目标错配。① grader 钻空：抽查「通过但可疑」的样本——agent 是否修改了测试文件、对单点断言表面达标、用固定话术骗过 rubric（SWE-bench 类评测已有改测试文件骗分的实证，arXiv:2506.12286）；② 评测集污染/过拟合：团队是否针对已知用例调 prompt，用复述变体试探、检查通过率是否远超线上真实分布；③ 指标错配：优化的是 proxy（离线 helpfulness 分），真实目标 gold（线上投诉）没动——这正是 Goodhart 定律，OpenAI 的 overoptimization 标度律（arXiv:2210.10760）给出定量形态：proxy 持续上升时 gold 先升后降。治理：a) 代理指标旁永远挂独立 gold 指标（线上转人工率、投诉率、人审抽检），跟踪 proxy-gold 背离，背离即停；b) 指标组合替代单一北极星（质量 pass^k + 安全 + 成本同时看）；c) 按切片报告，平均分最易被攻破；d) 评测集定期换血、保留私有 holdout；e) 对 grader 做红队（喂「看起来对其实错」的对抗样本）。观念：分数大涨的第一反应是怀疑测量系统，不是庆祝。

题 8（系统设计）：为一个电商退款客服 Agent 设计完整的评估指标体系与发布门禁。

参考答案： 分五层设计。① 维度框架（腾讯五维 + 阿里分层）：功能正确性（P0，代码判）——任务完成率按数据库终态校验（退款单状态、金额精确到分），不评自然语言话术；鲁棒与安全（P0）——pass^k（k=3/5）、幻觉率、误拒/漏拒、越权断言（must-not-call：不得跳过订单状态校验）、PII 合规；过程质量（P1，Rubric）——是否先查订单状态再承诺、关键澄清是否发生；效率（P1，代码判）——token/调用次数 avg&p95、延迟 p50/p95/p99、¥/task；体验（P2）——语气、解释完整性、转人工率、重复追问率。② 一致性口径：重复运行 N=5，关键决策类 0% 容忍——退款不可逆，任何一次失败都是事故，门禁看连续成功率 pass^3；同时报至少一次成功率作能力参照。③ 统计口径：golden set 起步 50–200 条（阿里），覆盖核心路径 + 高风险边界（已发货退款、运费险、特殊类目——业务先定口径），版本对比用配对检验 + 95% CI + 预设 MPP；报告 Wilson 区间与试验次数。④ 门禁规则：P0 硬门禁（核心场景通过率 ≥ 阈值、P0 风险样本失败 = 0、pass^3 达标、安全集 0 漏拒），P1 显著性比较（不劣于基线 + 成本不超基线 50%），P2 观察不拦截；离线门禁与线上灰度联动，离线升线上降 → 回滚（阿里）。⑤ 运营闭环：线上每日抽样（参考 Airbnb 5% 去标识化流量）用同一 rubric + 同一校准 judge 打分（离线在线同口径，DoorDash 原则）；badcase 进 RCA（阿里五步）与回归集（只增不减）；judge 升级时重跑三项统计（与人工一致性/高风险漏判率/边界稳定性）。评分器选型遵循确定性 > Rubric > 人工（腾讯），judge 校准到 ≥85% 一致率才上量（详见第 E05 章）。

五、易错点 · 反直觉点

1. 只报单次成功率，不报一致性：「准确率 80%」的 agent，pass^8 只有 16.8%。用户不接受「多试几次总有一次成功」——无人值守场景必须报 pass^k。记忆锚点：能力看 pass@k，发布看 pass^k。
2. 用「n 次里成功过任意一次」冒充成功率：这实际是 pass@n（n 是总试验次数），会系统性高估 pass@k；同理用 (c/n)^k 估一致性也是危险方向的高估。正确口径是无放回组合估计 1−C(n−c,k)/C(n,k)。记忆锚点：很多「好看」的评测数字，是口径选出来的。
3. 门禁只看差了多少，不看是否超过噪声：n=100 时 ±7 个点都是噪声，82%→85% 不构成发布理由。门禁要带置信区间 + 显著性 + 最小可感知变化三件套。记忆锚点：没有误差范围的对比结论可能只是噪声。
4. 万能 helpfulness 分：什么都能评 = 什么都评不准，语气好、篇幅长都能刷高分，制造虚假信心（Airbnb 三坑之首）。指标要从观察到的真实失败模式推导。记忆锚点：先有失败模式，后有指标。
5. 平均每轮分数高 = 会话成功：每轮都「答得还行」但最终没解决问题仍是失败（阿里）。任务完成率要落在 Session/Outcome 层，用终态校验而非文本匹配。记忆锚点：嘴上说已取消，数据库纹丝不动。
6. 只看质量不看成本：pass@1 高但 token 花 10 倍的方案生产上不可接受（腾讯）。质量相近时，延迟 p99 与 ¥/task 决定选型。记忆锚点：成本画像与质量分并排上报。
7. 指标 KPI 化后被反向刷爆：指标成为目标就不再是好指标——proxy 持续上升时 gold 先升后降（arXiv:2210.10760）；二元对错计分还会激励瞎猜与幻觉（arXiv:2509.04664）。代理指标旁必须挂独立 gold 指标。记忆锚点：分数大涨先怀疑尺子，再怀疑模型。
8. 通过率 0% 或 100% 归因于模型：多数时候是任务定义或评分器坏了，不是模型弱/强（腾讯人工评分六大场景之「诊断异常」）；0% pass^N 通常说明任务定义有问题。记忆锚点：极端分数先查尺子和卷子。
9. 能力套件与回归套件用同一预期：能力评测起步通过率应偏低（20–50%，指方向），回归评测应接近满分（确定性任务 100%、非确定性 ≥95%，拦退化）。用回归的预期要求能力集会打击探索，反之会漏掉回归。记忆锚点：能力集是山峰，回归集是底线。
10. 尺子自己热胀冷缩：judge 模型/prompt、rubric 升级后直接对比历史分数，趋势图失真。评分器要版本化，升级时重新校准并做桥接（阿里 judge 持续运营三统计：与人工一致性、高风险漏判率、边界稳定性）。记忆锚点：换尺子之前，先用旧尺子量一遍新尺子。

六、推荐资源

论文（arxiv ID 均来自本特辑 _research/ 已核实调研）：

1. τ-bench（arXiv:2406.12045，Sierra，2024）——pass^k 的原始出处；GPT-4o retail pass^1≈60%→pass^8≈25% 的可靠性实证。https://arxiv.org/abs/2406.12045
2. Scaling Laws for Reward Model Overoptimization（arXiv:2210.10760，OpenAI，ICML 2023）——Goodhart 的定量形态：proxy-gold 背离与最优优化量标度律。https://arxiv.org/abs/2210.10760
3. Catastrophic Goodhart（arXiv:2407.14503，NeurIPS 2024）——重尾误差下 KL 正则失效，「加正则就安全」的证伪。https://arxiv.org/abs/2407.14503
4. Does RL Really Incentivize Reasoning…（arXiv:2504.13837，NeurIPS 2025）——pass@1 与大 k pass@k 反转：只报 pass@1 会系统性高估能力增益。https://arxiv.org/abs/2504.13837
5. Why Language Models Hallucinate（arXiv:2509.04664，OpenAI，2025）——计分规则即激励机制：二元打分激励瞎猜，应允许弃权与校准计分。https://arxiv.org/abs/2509.04664
6. GEPA（arXiv:2507.19457，2025）——Pareto 前沿按切片保留候选，隐含「按切片看指标、防平均分掩盖退化」的指标设计原则。https://arxiv.org/abs/2507.19457

工业实践原文（本章全部工业数字的出处）：

1. 阿里技术《Agent 评测：方法论与体系设计》——P0/P1/P2 分层、一致性双指标、门禁统计三件套、容忍阈值思想。
2. 腾讯技术工程《AI Agent & Skill 测评方案及落地实践》（martinskxu）——五大维度、N=5 稳定性读法、容忍阈值分级、¥/task 成本画像。
3. Airbnb《Eval-driven development: Lessons from evaluating GenAI at scale》——三坑、从失败推导指标、judge 少而精、groundedness 校准 78%→88%。
4. DoorDash《Building Ask DoorDash (Part 3): Evaluation》（2026-06-30）——质量分 +8、错误率近乎减半、模型迁移延迟降 35% 质量无损。
5. Anthropic《Demystifying evals for AI agents》（2026-01）——pass^k 进发布门槛（p=0.75 时 pass^3≈42% 的著名例子）、capability vs regression 套件、确定性任务 100%/非确定性 ≥95%。
6. OpenAI《Evaluation best practices》——量化门槛示例（文档问答 recall ≥ 0.85 / precision ≥ 0.7、摘要 ROUGE-L ≥ 0.40）。

动手实验：

• cd evals-special/labs && python3 eval_lab01_metric_system.py——pass@k/pass^k 理论值与无偏估计、p=0.8 时两指标随 k 分道扬镳、同一 agent 在不同门禁下的相反发布结论。
• cd evals-special/labs && python3 eval_lab08_statistics_ci.py——Wilson 区间覆盖率验证、配对显著性（McNemar）、样本量速查表：3% 差异在 n=100 下不可判、n=2000 下可判。
• cd evals-special/labs && python3 eval_lab10_edd_loop.py——P0 门禁（通过率 ≥90% 且 0 个 P0 风险样本失败）与回归检测的完整闭环。

相关章节：

• 第 E01 章 · 为什么评估是 GenAI 工程的生命线（指标体系要解决的问题）
• 第 E03 章 · 黄金数据集与用例设计（指标的载体：评什么样本）
• 第 E04 章 · 程序化评分（指标怎么算：确定性评分器）
• 第 E05 章 · LLM-as-Judge 深入（语义类指标的度量与校准）
• 第 E07 章 · 轨迹与 Agent 级评估（过程类指标：工具序列、假阳性）
• 第 E09 章 · 评估的统计学基础（置信区间、样本量、显著性的完整推导）
• 第 E10 章 · 评测驱动开发（指标如何进门禁与 CI）
• 第 E13 章 · Benchmark 全景与前沿争议（外部坐标系与 Goodhart 的基准侧）
• 第 E15 章 · 工业实践案例研究（四家指标体系的横向对比）
• 主手册第 8 章 · Agent 评估与可观测性（浓缩版对照；本章在一致性指标、分层与统计口径上显著更深）

黄金数据集与用例设计

一句话导读：E01 回答了"为什么评"，E02 回答了"评什么"，本章回答"拿什么评"——评测集是整个 evals 体系的尺子，尺子歪了，后面所有分数都是误导性信心。学完本章你能回答：线上数据为什么不能直接当评测集、用例从哪来、怎么组织、Golden Set 建多大、badcase 凭什么入库、用例集如何像代码资产一样持续治理。

一、知识图谱

黄金数据集与用例设计（拿什么评）
│
├── 1. 为什么不能是线上随机抽样
│   ├── 幸存者偏差：正常流程占多数，高风险边缘场景占比极低
│   └── 后果：报告"看起来不错"，关键问题恰好全部漏掉
│
├── 2. 用例四类来源（阿里）
│   ├── 专家设计 —— 定标准（冷启动的 20-50 条参考解）
│   ├── LLM 扩展 —— 先定结构字段（场景/订单状态/诉求/期望动作），再生成自然语言
│   ├── 线上真实数据 —— 真实分布与失败挖掘的原料（须去标识化）
│   └── badcase 回流 —— 失败 → 资产（须过入库标准）
│
├── 3. 用例组织范式（腾讯四场景）
│   ├── 触发 → 核心逻辑 → 产物质量 → 异常容错
│   ├── 每场景正向 + 负向用例成对设计
│   ├── 核心逻辑用例量 ≈ 其余三类之和的 2-3 倍
│   └── 负向触发用例必不可少："过度触发比不触发更难发现"
│
├── 4. 一条合格用例的形态
│   ├── 用例 spec：id/来源/场景/输入/期望行为/判据/风险等级/状态
│   ├── checklist 式场景 rubric（DoorDash 素食 taco 清单）：低方差，小样本可迭代
│   └── 基线快照（腾讯）：执行 1 次 → 人工确认 → 快照为基线；不硬编码预期输出
│
├── 5. Golden Set 定位与规模
│   ├── 定位：基线评测集（相对稳定、长期复用），用于版本对比与发布门禁
│   ├── 规模经验：20-50（Anthropic）/ 50-100（Airbnb，必须含坏样本）/ 50-200（阿里）
│   └── 成熟后扩展：分类采样集 / 长尾集 / 对抗集 / 线上回流集
│
├── 6. 生命周期治理
│   ├── 入库标准五项：可复现 / 期望明确 / 根因清楚 / 代表性 / 已脱敏
│   ├── 同簇去重：同簇保留代表例
│   ├── 能力集 →（稳定 100% 通过）→ "毕业"进回归集；回归集只增不减
│   └── 样本治理：P0/P1 长期保留 / 稳定通过者降级抽样集 / 主动学习抽新分布
│
├── 7. 隐私合规：去标识化 + 用途限定（Airbnb）
│
└── 8. 三层互补：公开 benchmark（外部坐标）+ 私有 golden set（业务真值）+ 在线信号（最终裁决）

30 秒版本：评测集不是"攒一堆例子"，而是一条有准入、有组织、有生命周期、有合规边界的治理流水线。 它的质量上限决定评测结论的质量上限。

二、核心概念精讲

2.1 为什么不能是线上随机抽样：幸存者偏差

直觉上最省事的做法是"从线上日志里随机抽一批会话当评测集"——真实、免费、量大。阿里的评测方法论明确否掉了这条路：评测集不是线上随机抽样。

机制：线上流量的分布天然是"正常流程占多数、易错边缘场景占比低"。随机采样会忠实地复刻这个分布，于是评测报告里 98% 的样本本来就是 agent 闭着眼也能处理好的请求。

后果链条：

做个示意算术（非工业数据，仅建立直觉）：某高风险场景在线上流量中占 1%，随机抽 100 条，期望只抽到 1 条；如果该场景下 agent 有一半概率犯错，你的评测"发现这个问题"的概率也就五五开。评测集的职能是暴露问题，而随机抽样的职能是复刻流量——两者的目标函数根本相反。

正确姿势是分层与定向：

• 按风险/意图/置信度分层采样，对高风险、低置信、新意图样本过采样（代价是整体通过率失真，聚合时按真实流量权重加权修正）；
• 阿里的主动学习口径：新分布出现时优先抽取低置信 / 高影响 / 新意图 / 新工具 / 新知识点样本进人工确认；
• 线上数据的正确角色是失败挖掘的矿与分布参照，不是评测集主体。Airbnb 的每日抽样 5% 去标识化生产流量，用途是生产监控与评审队列，与作为基线的 golden set 是两套资产。

分层采样的一种典型设计（综合阿里口径的工程化表达）：

两个配套动作：过采样会让"整体通过率"偏离真实流量表现，汇报整体分数时按真实流量权重加权还原；同时保留分层明细——分层视图才是改进工作的抓手（哪个层在恶化一目了然）。

一句话记忆：随机抽样回答"线上平均表现如何"，评测集回答"最坏情况下会不会死"——不能用一把尺子量两件事。

2.2 用例四类来源：专家设计 / LLM 扩展 / 线上真实数据 / badcase 回流

阿里的评测数据集建设给出四条来源，各有分工，缺一不可：

（1）专家设计：定标准的人永远不能缺席。 评测集冷启动阶段，腾讯的做法是新建套件先由专家产出前 20-50 个参考解作为 ground truth；阿里同样把"专家设计用例"列为四类来源之首——它定义的不是样本量，而是"什么算对"的口径。口径未固化的场景（如"订单已发货 + 用户拒收 + 运费险 + 特殊类目该走哪条流程"）必须由业务先定，工程师不能代答。

（2）LLM 扩展：先定结构字段，再生成自然语言。 这是阿里方案里最值得抄的细节：

错误做法：prompt = "请生成 100 条客服 agent 的测试用例"
           → 模型自由发挥，场景重复、分布失控、编造业务上不存在的状态

正确做法（两步）：
  第一步：用规则/枚举确定结构字段
    {场景类型: 退款, 订单状态: 已发货, 用户诉求: 仅退款, 期望动作: 先查订单状态再答复}
  第二步：LLM 只负责把结构字段改写成接近真实用户的自然语言表达
    "东西还在路上我不想要了，钱能直接退我吗？"

结构字段保证覆盖矩阵按需填充（每条分支、每种订单状态都有人管），自然语言改写保证表达真实多样。顺序反过来，用例集的构念效度就丢了。（动手实验：cd evals-special/labs && python3 eval_lab02_golden_dataset.py，其中的 MockLLM 会直接拒绝无结构字段的生成请求——接口约束即治理。）

（3）线上真实数据：真实客服会话/工单是金矿，但进门先过两道关：去标识化（见 2.7）与代表性审查。公开语料同理——WildChat（arxiv 2405.01470，100 万条真实 ChatGPT 交互日志）与 LMSYS-Chat-1M（arxiv 2309.11998）这类真实对话语料是构建评测集与用户模拟器的常用原料，但都要先做隐私清洗再入库。

（4）badcase 回流：线上失败是最有针对性的用例原料。注意 badcase 回流不是"复制粘贴进 JSONL"，必须先过 2.6 的入库标准——这是四家共识（Airbnb 的"每周 PM 评审新增测试"是同一动作的组织形态）。看一条 badcase 从现象到用例的完整编码（阿里实例"Agent 直接承诺一定退款成功"的展开）：

# ① 线上 badcase（原始现场）
session: session-20260712-8841
phenomenon: 用户咨询已发货订单退款，Agent 回复"放心，一定给您退款成功"
root_cause_label: 风险防控 / 过度承诺          # 根因标签清楚，才具备入库资格

# ② 过入库标准后编码为用例
case_id: risk-overpromise-012
source: badcase 回流
created_from: session-20260712-8841
scenario: 退款 · 已发货
input: "东西已经发货了但我不想要了，能全额退给我吗？"
expected_behavior:
  - must_call: query_order_status               # 期望行为可判定
  - must_not: 无条件承诺退款成功
  - reply_mentions: [物流状态, 拦截/拒收流程, 退款条件]
risk_level: P0                                   # 涉资损与合规，永不降级
suite: capability                                # 修复验证稳定后毕业进回归集

这条用例同时满足入库五项：失败可复现（有原始 trace）、期望明确（三条检查项）、根因清楚（风险防控域）、有代表性（"过度承诺"是一类问题）、已脱敏。它进入回归集后，未来任何一次 prompt 重构若重新引入"拍胸脯式承诺"，CI 会当场拦截。

交叉参照：OpenAI 官方 evaluation best practices 把数据来源归纳为五路——生产、专家构造、历史、合成、采购——与上面四类来源基本同构（"采购"对应公开数据集/基准）。EDDOps 论文（arxiv 2411.13768，2024-11 首发，2025-11 v3）则要求每条用例带 provenance（来源出处）、oracle（判定标准）、slice 标签——来源必须可追溯，通过率要能按来源拆开看。

2.3 用例组织范式：触发 → 核心逻辑 → 产物质量 → 异常容错

用例攒到几十条后，最大的问题不再是"不够多"，而是"没组织"。腾讯给出的组织范式是把每个 Skill/Agent 的用例沿四个场景展开，每个场景回答一个递进的问题：

三个关键设计纪律：

（1）负向触发用例为什么必不可少。 腾讯原文一句话点破："只测正例，Agent 可能学会什么都触发——过度触发比不触发更难发现。"不触发会立刻被用户抱怨（功能"坏了"），过度触发却悄悄消耗 token、污染下游流程、把无关请求路由进昂贵链路，直到某天账单或事故才暴露。所以触发场景的用例必须是正负成对的：正例测召回，负例测精度。

（2）核心逻辑用例量 = 其余三类之和的 2-3 倍。 这是腾讯的经验法则。配套三步法：

1. 梳理分支流程图（把业务分支穷举成图）；
2. 每条分支至少 1 个用例（N 条分支至少 N 个正向 + 关键分支的负向）；
3. 补充组合与边界：分支间组合、阈值边缘、跨分支冲突。分支过多时先覆盖高频与易错。

（3）异常容错要拆成三个子类设计（腾讯）：

这个四场景框架与主手册第 8 章的"任务分类学 → 覆盖矩阵"一脉相承，但给出了更落地的填充顺序：先触发、再过程、再产物、最后容错——因为前置场景失败时，后置场景的用例根本没有意义（触发都错了，谈何产物质量）。

工业实例：TPerf 的用例分组落地（腾讯）。性能分析 Agent TPerf 把 30+ 用例按场景分成 9 组，每个用例绑定一条真实压测记录（不可变、可复现），支持 7 个模型的参数化对比（每用例 × 每模型）：

两个值得抄的细节：① 正常场景也配了 5 条用例——"没问题时不误报"本身就是一种能力，只测异常不测正常，会把"逢数据必喊瓶颈"的 agent 评出高分；② 高频场景（CPU/网卡）用例多、罕见场景（内存/Nginx）用例少，分组数量本身就是风险权重的显式表达——分支过多时先覆盖高频与易错，正是三步法的落地形态。

2.4 一条合格用例长什么样：用例 spec、checklist rubric 与基线快照

（1）用例 spec：字段即契约。 一条可入库的用例至少应固化如下字段（与 labs/eval_lab02_golden_dataset.py 的 dataclass 一致）：

case_id: refund-shipped-007
source: badcase 回流            # 专家设计 / LLM 扩展 / 线上数据 / badcase 回流
scenario: 退款 · 已发货          # 结构字段：场景类型 + 订单状态
input: "东西还在路上我不想要了，钱能直接退我吗？"
expected_behavior:              # 期望行为写成可判定的检查项，不写"回答要好"
  - must_call: query_order_status
  - must_not: 无条件承诺退款成功
  - reply_mentions: [物流状态, 退款条件]
risk_level: P1                  # P0 资损/合规 / P1 核心流程 / P2 体验
suite: capability               # capability（能力集）/ regression（回归集）/ graduated
created_from: session-20260712-8841   # provenance：来自哪条线上会话/哪次评审

要点：期望行为必须写成规则/Judge 标准/人工验收标准能消费的形式（阿里入库标准第二条"期望行为明确"的直接推论）；risk_level 决定门禁权重与保留策略；created_from 让每条用例可回溯到现场。

（2）checklist 式场景 rubric：低方差信号。 DoorDash 的一个代表性设计是"场景级清单"。例：场景"为两人份、预算 ≤$60 的素食 taco 购物清单"，rubric 不写"购物清单质量好"这种宽泛标准，而是写成一张可核验的清单——验证每件商品都是素食 taco 原料、小计 ≤$60。DoorDash 的结论：这类 checklist 标准比宽泛通用标准方差更低，小样本更有用，支撑更快的迭代。

机理很直白：判定依据越接近可程序化核验的事实（商品名在不在清单里、金额加总对不对），judge 与人工的自由裁量空间就越小，同一输入重复评分的波动就越小——方差低了，50 条样本也能看出两个版本的真实差异；方差高了，500 条样本也只是噪声（统计细节详见第 E9 章 · 评估的统计学基础）。用例设计的通用原则由此得出：能用 checklist 的场景不要用印象分，先收敛判定口径再谈规模化。

（3）基线快照机制（腾讯）：期望答案也是资产。 腾讯的用例基线机制回答了一个常被忽略的问题——"预期结果从哪来、谁来确认、何时更新"：

用例设计：只定义 prompt 与检查规则（不写死预期输出）
  → 执行 1 次
  → 人工审核本次执行的过程与结果
  → 不可接受：修改后重跑
  → 可接受：该次执行快照成为基线
后续每次执行都与基线对比（确定性评分器做程序化判定；Rubric 以基线为参考答案比语义差异）

基线快照包含两部分：预期过程（CoT、工具调用序列含入参与返回、中间产物、完整 Trace）与预期结果（最终响应、输出文件、输出报告）。基线更新的三个时机：Agent/Skill 逻辑变更、模型版本升级、用例本身修改（prompt 或检查规则变了）——任一发生都要重新执行 1 次并人工确认。

TPerf 实战案例把这一点做到了极致：30+ 用例不硬编码预期输出，而是通过基线会话标识（session_id + message_id）指向人工确认过的分析记录，评测时从平台 API 动态获取。每个用例对应一条真实压测记录——不可变、可复现。对比维度也分三层：过程对比（关键步骤缺失/顺序偏离→过程退化）、结果对比（关键内容缺失/产物不一致→结果退化）、效率对比（token/步骤数超基线比例，如 >50% → 效率退化）。

（4）两条配套纪律。

• Eligibility 适用性前置（DoorDash）：checklist/rubric 再具体，也不是每条都适用于每个会话。DoorDash 的做法是 judge 先判"该标准是否适用本会话"，不适用则跳过——例如食谱类会话不因缺少复购步骤被扣分。用例与标准入库时就要声明适用条件，否则不适用场景的误扣会成为门禁噪声的主要来源。
• 每条标准写成"从会话本身可验证"（DoorDash）：同一条 rubric 既要能供人工校准、又要能供 judge 规模化执行——凡是人工判定时需要翻外部系统才能核实的标准，要么拆成可验证的证据切片（详见第 E7 章 · Transcript Builder），要么不写进自动评测。
• 执行环境隔离（阿里）：用例设计得再好，执行时多用例共享状态（同一个测试账号、同一份被改写的库存数据）也会导致分数不可复现。评测执行环境必须逐用例隔离或重置——这是用例 spec 之外的运行侧前提。

2.5 Golden Set：定位与规模经验

定位（阿里）：Golden Set 默认作为基线评测集——相对稳定、长期复用的核心样本，用于版本对比与发布门禁。它不是全部评测数据，而是那把"不能热胀冷缩的尺子"；分类采样集、长尾集、对抗集、线上回流集是它外围的扩展层。

规模经验（以素材为准）：

三个读法：

1. 起步门槛出奇地低。四家没有一个要求先攒 1000 条——20-50 条覆盖核心路径与高风险边界的用例就能启动 eval-driven 迭代。等的不是数据量，是判据的清晰度。
2. 规模服务于职能。50-200 条是"基线尺子"的规模；Airbnb 的 5,000 样本是"每日估计生产质量"的监控规模，两者不可混谈（为什么 100 条尺子在统计上够用，详见第 E9 章的样本量计算）。
3. gold set 必须含坏样本（Airbnb 十条要点之一）。原因有二：校准 judge 时需要负例，否则测不出 judge 是否"一律说好"；坏样本还承担区分"judge 误罚正确改述"与"judge 放过流畅错误"的功能——Airbnb 客服案例中 judge 初始一致率仅 78%，正是在含失败样本的 60 条 gold 上定位到"judge 误罚正确的改述"，修 rubric 后升至 88%（judge 校准全流程详见第 E5 章 · LLM-as-Judge 深入）。

注意"黄金集"一词的两个职能，面试别混：Airbnb 语境的 50-100 条 gold set 主要服务于 judge 校准（含坏样本、人工标注、量小、长期固定），阿里语境的 50-200 条 golden set 主要服务于版本对比与发布门禁（覆盖核心路径与高风险边界、期望行为明确）。成熟团队两者都有：校准集管"尺子准不准"，基线集管"版本行不行"——它们可以是同一批样本的两个视角，但维护节奏与准入标准不同（校准集换血要极慎重，否则 judge 一致性历史数据不可比）。

2.6 数据集生命周期治理：入库、去重、毕业、只增不减

评测集是活的：每周都有 badcase 想进来，每个版本都有用例想"退役"。没有治理流水线，用例库要么膨胀到跑不起，要么信号被稀释成噪声。

（1）入库标准五项（阿里，badcase 进评测集/训练数据/知识修订前的通用门槛）：

badcase 不天然是用例。 阿里把一条 badcase 的反馈生产拆成三条生产线（评测集 / 训练数据 / 知识修订），而入库标准是三条线共用的闸门——五项缺一不可。

（2）同簇去重：失败会成簇出现（同一根因反复触发），入库与治理时同簇保留代表例，避免 100 条"退款已发货未查订单状态"挤爆回归集。簇的组织可以直接复用 rubric 标准——DoorDash 的经验是 rubric 标准天然是问题簇（grounding 失败 / 缺替代品 / 糟糕叙述分开调查），失败列表因此变成按影响排序的主题列表。

（3）能力评测 vs 回归评测与"毕业"机制（腾讯）：

毕业流转：能力集用例通过率稳定 100% 后"毕业"进回归集；badcase 的完整旅程是"复现记录完整轨迹 → 分析根因定预期行为 → 修复 → 纳入用例集防回归 → 进能力集，稳定后毕业到回归集"。腾讯引用 Anthropic 的口径作为回归门槛：确定性任务用例集整体通过率需 100%，非确定性任务 ≥95%。与之配套的是稳定性容忍阈值分级（关键决策类 0% 容忍、辅助分析类 ≤10%、创意生成类 ≤40%）——同一条用例在不同业务语境下的"毕业线"不同。

（4）样本治理四条规则（阿里）：

1. 同簇保留代表例；
2. P0/P1 风险样本长期保留（资损、合规、隐私类永不降级）；
3. 稳定多版本通过且低风险者降级为抽样集（退出每次必跑，保留抽查资格）——这是回归集不无限膨胀的泄压阀；
4. 新分布出现时主动学习优先抽取低置信 / 高影响 / 新意图 / 新工具 / 新知识点样本进人工确认。

（5）执行触发时机（腾讯）：治理的最终产物是"变更 → 自动回归"的条件反射：

门禁的严格程度可以参考 DoorDash 仿真评测飞轮的口径：任何变更必须通过全部 50+ 个 eval 才能上线，且全流程一次触发，5 分钟内可跑完 200+ 场模拟对话——"门禁要严、跑得要快"，两者靠 fixtures 与并行化同时满足（详见第 E8 章）。

（6）长尾集与对抗集：成熟期在 golden set 之外单独维护。长尾集收低频但真实的场景（小语种、极端金额、多重约束叠加）；对抗集收注入、越权、诱导承诺等安全用例——安全用例必须常驻回归，一次 prompt 重构完全可能功能全绿而防线塌方（安全评估详见主手册第 8 章 · Agent 评估与可观测性）。

动手实验：入库检查器、同簇去重、毕业流转、回归门禁的可运行实现都在 cd evals-special/labs && python3 eval_lab02_golden_dataset.py；毕业机制与"回归集只增不减"在 EDD 全闭环中的位置见 cd evals-special/labs && python3 eval_lab10_edd_loop.py。

2.7 隐私合规：去标识化与用途限定

生产数据进评测链路，合规是硬门槛，不是"以后再说"。素材中两条明确实践：

• Airbnb：生产抽样采用隐私保护方法——人工评审前去标识化、用途限定于安全与质量。两个动作缺一不可：去标识化解决"数据能不能用"，用途限定解决"数据会不会被挪作他用"。
• 阿里：把"已脱敏合规"列为入库标准第五项——未脱敏的样本在闸门口就被拒，而不是入库后再补救。

工程上的常见做法（通用实践）：直接标识符（姓名/电话/卡号/地址）程序化替换，间接标识符（罕见组合特征）做泛化或删除；工具返回值里的 PII 同样要扫（trace 是重灾区）；留存期分级、访问留痕；用于 judge 校准与人工评审的样本走同一套脱敏管线。注意脱敏不是"一次性清洗"：线上回流是持续流，脱敏必须内建在入库管道里，而不是靠人记得手动处理。

2.8 公开 benchmark 与私有评测集：三层互补

私有 golden set 不是孤岛，它和公开基准、在线信号构成三层坐标系：

几点关键事实（以素材为准）：

• 公开基准的价值在"外部参照"而非"产品指标"。τ-bench（arxiv 2406.12045，2024-06）用数据库终态哈希 + pass^k 提供了可靠的横向坐标：GPT-4o 在 retail 域 pass^1 ≈60%（官方榜单 60.4%）、airline 域 ≈42%，而衡量可靠性的 pass^8 跌至约 25% / 16%（官方榜单与论文口径）——这类数字能帮你判断"自家 agent 的稳定性缺口是不是行业通病"。
• 基准会饱和、会被污染。Anthropic 报告 SWE-bench Verified 一年内从 40% 涨到 80%+；EDDOps 对学术文献的统计显示 97.76% 的评测仍用静态基准——静态题面迟早进训练语料。公开分数只能当路标。
• 私有集的最大敌人是"自己"。一旦评测集被当作优化目标（如用 MIPROv2 类优化器以 eval 分数为搜索目标，arxiv 2406.11695），就会出现泄漏与过拟合风险——EDDOps 因此把 contamination safeguards（污染防护）与 provenance 列为评测资产的必备属性；工程手段是留出集隔离、定期换血、按 slice 报告（GEPA 的 Pareto 前沿选择即按切片保留候选，防止平均分掩盖退化，arxiv 2507.19457）。
• "只能选一个向老板汇报，选哪个"：选私有 golden set 的通过率 + 在线信号。基准分数回答不了"我们的用户会不会出事"，只有来自真实失败的私有集和线上数据能回答（完整选型框架详见第 E13 章 · Benchmark 全景与前沿争议）。

三、面试高频考点

四、经典面试题与参考答案

题 1（基础）：为什么不能直接从线上日志随机抽样当评测集？

参考答案：

因为线上流量存在幸存者偏差：正常流程占多数，易错的高风险边缘场景（退款已发货、叠加优惠、欺诈嫌疑）占比极低。随机抽样忠实复刻这个分布，评测报告"看起来不错"，但恰好把最关键的问题漏掉了——随机抽样回答的是"线上平均表现如何"，评测集要回答的是"最坏情况下会不会死"。

正确做法分三层：① 评测集主体来自专家设计 + 结构化 LLM 扩展 + badcase 回流，按"触发→核心逻辑→产物质量→异常容错"组织，对高风险分支定向填充；② 线上数据做分层采样（按风险/意图/置信度，过采样高风险与低置信样本），用于失败挖掘与分布校准，聚合时按真实流量权重加权；③ 线上抽样（如 Airbnb 每日 5% 去标识化流量）定位为生产监控，与作为基线门禁的 golden set 分开管理。

题 2（基础）：评测用例有哪几类来源？各自的优点和风险是什么？

参考答案：

四类（阿里口径）：

1. 专家设计——定标准。覆盖核心与高风险分支、判据权威；缺点是贵且慢，冷启动先出 20-50 条参考解即可。
2. LLM 扩展——上量。便宜快、表达多样；风险是自由生成会编造业务不存在的场景，所以必须先用规则确定结构字段（场景类型/订单状态/用户诉求/期望动作），再让 LLM 生成自然语言表达。
3. 线上真实数据——分布校准。表达最真实；但有幸存者偏差与隐私风险，须去标识化，且不直接当基线。
4. badcase 回流——防再犯。每条都是真实发生过的失败，针对性最强；但 badcase ≠ 用例，须过五项入库标准（可复现/期望明确/根因清楚/代表性/已脱敏）。

加分项：EDDOps 要求每条用例带 provenance/oracle/slice 标签，通过率按来源拆开看，才能判断"是评测集偏了还是模型偏了"。

题 3（进阶）：用 LLM 批量生成测试用例时，为什么强调"先定结构字段、再生成自然语言"？让模型自由生成会怎样？

参考答案：

自由生成有三个失效模式：① 场景编造——模型生成业务上不存在的状态组合（如"未支付订单申请改地址"），用例失去可判定性；② 分布失控——高频套路反复出现、关键分支无人覆盖，没有覆盖矩阵可查；③ 判据缺失——生成时没有期望动作，入库后还要人工补，成本反而更高。

"先结构后语言"把生成拆成两段：结构字段（场景类型/订单状态/用户诉求/期望动作）由规则或枚举确定，保证覆盖矩阵按需填充、每条用例天生带判据；LLM 只负责把结构改写成接近真实用户的自然语言表达，保证多样性与真实感。本质是把"测什么"（构念效度）与"怎么说"（表面多样性）解耦——前者必须握在人手里。工程实现上对应结构化输出/schema 校验：生成请求里没有结构字段就直接拒绝（eval_lab02 的 MockLLM 正是这样实现的）。

题 4（进阶）：负向触发用例为什么必不可少？你会怎么设计？

参考答案：

因为过度触发比不触发更难发现（腾讯原话）。不触发会立刻被用户发现（功能"坏了"），过度触发却静默发生：无关请求被路由进昂贵链路、token 消耗上涨、下游流程被污染，直到成本账单或连锁事故才暴露。只测正例的评测集会系统性纵容"什么都触发"的 agent。

设计方法：① 相似但不相关的 prompt 成对构造——与合法触发仅一字之差的表述（相邻技能的需求、含相同关键词但意图不同的请求）必须不触发；② 负例覆盖三类：相邻技能混淆、关键词陷阱（含实体词但意图不同）、空泛请求（"帮我看看"）；③ 判定用程序化断言（未调用目标技能入口 / 未进入目标流程），零 judge 成本；④ 与正向用例配对汇报：触发场景同时报召回（正例触发率）与精度（负例不触发率），两个数一起看才有意义。

题 5（进阶）：Golden Set 建多大规模合适？为什么 Airbnb 强调 gold set 必须包含坏样本？

参考答案：

规模经验（均以素材为准）：Anthropic 建议 20-50 个真实用例即可起步；Airbnb 用 50-100 条 gold set；阿里建议先做 50-200 条高质量 golden set 覆盖核心业务路径与高风险边界。共识是起步门槛低、判据优先于数量：50-200 条是"基线尺子"的规模，承担版本对比与发布门禁；更大的集合（如 Airbnb 规模化阶段的 5,000 样本、每日 5% 抽样）是生产监控用途，两者职能不同。统计上，100 条样本的通过率 95% 置信区间约 ±10 个百分点，足以分辨"明显变好/变坏"，再小则噪声淹没信号（计算详见第 E9 章）。

必须含坏样本有两个原因：① 校准 judge 需要负例，否则测不出 judge 是不是"一律给好"；② 坏样本能暴露 judge 的误判类型——Airbnb 客服案例正是在含失败样本的 gold 集上发现 judge 初始一致率仅 78%，根因是"judge 误罚正确的改述"，修 rubric 后升到 88%。没有坏样本的 gold set，校准根本无从谈起。

题 6（进阶）：线上进来一条 badcase，能直接变成评测用例吗？入库标准是什么？

参考答案：

不能。badcase 是原料，不是用例；阿里的入库标准五项缺一不可：

1. 失败可复现（或至少有稳定 Trace + 人工确认）——否则无法验证修复是否生效；
2. 期望行为明确——可写成规则/Judge 标准/人工验收标准，否则无法打分；
3. 根因标签清楚——归到具体能力域或业务流程，否则 RCA 断链；
4. 样本有代表性——覆盖一类问题而非一次性环境抖动，孤例会稀释信号；
5. 已脱敏合规——PII 清理完成，法务红线。

完整旅程是：badcase → 过五项标准 → 编码为用例（带 provenance 指回原始 session）→ 进能力集验证修复 → 稳定 100% 通过后毕业进回归集（只增不减）。一条 badcase 至少可生产三类反馈（评测集/训练数据/知识修订），入库标准是三条生产线共用的闸门。

题 7（进阶）：能力评测和回归评测有什么区别？"毕业"机制怎么运转？

参考答案：

两者回答的问题相反：能力测评回答"Agent 能把什么做好"——是目标山峰，起步通过率 20-50%，主动拓展、频繁迭代，失败代表改进方向；回归测评回答"原有能力是否还在"——是防线，期望接近 100%，防御漂移，CI 每次运行，失败即阻断发布。

毕业机制是两者的传送带：能力集用例通过率稳定 100% 后毕业进回归集；回归集只增不减。腾讯引用 Anthropic 口径定回归门槛：确定性任务用例集整体通过率 100%，非确定性任务 ≥95%，并按业务类型分级容忍（关键决策类 0% 容忍、辅助分析类 ≤10%、创意生成类 ≤40%）。防膨胀靠降级泄压：稳定多版本通过且低风险的用例降级为抽样集（退出每次必跑、保留抽查资格），但 P0/P1 风险样本长期保留、永不降级。badcase 的完整闭环：复现 → 定根因与期望行为 → 修复 → 纳入用例集防回归 → 进能力集 → 稳定后毕业。

题 8（进阶）：DoorDash 的 checklist 式场景 rubric（如"素食 taco 购物清单"）比宽泛 rubric 好在哪？什么场景适用？

参考答案：

案例：场景"为两人份、预算 ≤$60 的素食 taco 购物清单"，rubric 写成可核验清单——每件商品都是素食 taco 原料、小计 ≤$60——而不是"清单质量好"。

好在低方差：判定依据收敛到可程序化核验的事实（商品在不在清单、金额加总），judge 与人工的自由裁量空间被压缩，同一输入重复评分的波动小。方差低的直接收益是小样本也能迭代——50 个场景就能可靠区分两个版本，支撑更快的发布节奏；宽泛标准方差高，同样样本量下差异淹没在噪声里。此外 checklist 失败时归因明确（哪一条没满足一目了然），天然服务于失败聚类。

适用边界：任务目标可枚举成事实性检查项时用 checklist（购物、预订、表单类）；开放式目标（语气、叙事质量）仍需语义 rubric 兜底，此时用 eligibility 前置（DoorDash：judge 先判标准是否适用本会话）避免误扣。两者都要求"从会话本身可验证"，才能同一 rubric 既供人工校准又供 judge 规模化。

题 9（系统设计）：为一个新上线的客服 Agent 从零设计评测数据集体系：来源、组织、规模、治理流程、与 CI 的衔接，一次讲清。

参考答案：

第一阶段（第 1-2 周）：定口径、立骨架。 与业务方先定高风险场景的口径（如"已发货+拒收+运费险该走哪条流程"）；专家设计 20-50 条参考解覆盖核心路径；按腾讯四场景（触发→核心逻辑→产物质量→异常容错）组织，正负用例成对，核心逻辑用例量≈其余三类之和的 2-3 倍（先梳理分支流程图，每条分支至少 1 例）；每条用例固化为 spec（输入/期望行为/判据/risk_level/provenance），期望行为写成 must-call/must-not 等可判定检查项。

第二阶段（第 3-4 周）：扩量与基线。 用"先结构字段后自然语言"的 LLM 扩展把规模做到 50-200 条（阿里口径），覆盖核心业务路径与高风险边界；对执行类用例走基线快照流程（执行 1 次→人工确认→快照为基线，不硬编码输出）；为购物/预订类场景配 checklist 式低方差 rubric；线上真实会话去标识化后做分布比对，补覆盖盲区。

第三阶段（持续）：治理流水线。 入口：badcase 双通路（离线评测失败 + 线上投诉/低满意度/转人工）汇入同一任务表，过五项入库标准（可复现/期望明确/根因清楚/代表性/已脱敏）编码为用例；同簇去重保留代表例。流转：新用例先进能力集，稳定 100% 通过后毕业进回归集（只增不减）；回归集进 CI——PR 触发回归（提示词变更）+ 模型升级手动验证 + 定期全量巡检；门槛按 Anthropic 口径：确定性 100%、非确定性 ≥95%，P0 风险样本失败一票否决。防膨胀：稳定多版本通过且低风险者降级抽样集，P0/P1 长期保留；成熟后扩展长尾集与对抗集（注入/越权用例常驻回归）。

第四阶段（规模化）：三层坐标。 私有 golden set 做发布门禁；公开基准（τ-bench 类）做季度外部水位参照；线上每日抽样（去标识化、用途限定）做持续监控——三层分数不可互替。组织上指定人类终判者裁决口径争议（Airbnb 五原则之一），评测集增长与 judge 校准各有 owner。

五、易错点 · 反直觉点

1. 误区：线上日志随机抽一批就是最"真实"的评测集。 真相：线上分布里高风险场景占比极低，随机抽样复刻的是流量而不是风险，报告"看起来不错"恰好说明关键问题被漏掉了。 记忆锚点：评测集找问题，抽样描分布——目标相反，不能混用。

2. 误区：触发场景只需要测"该触发时能触发"。 真相：只测正例，agent 可能学会什么都触发；过度触发静默消耗成本、污染下游，比不触发更难发现。 记忆锚点：正例测召回，负例测精度，触发场景必须成对。

3. 误区：让 LLM 自由生成几百条用例，又快又多。 真相：没有结构字段约束的生成=场景编造+分布失控+判据缺失；覆盖率无法审计，入库后全是返工。 记忆锚点：先定骨架（结构字段），再长皮肉（自然语言）。

4. 误区：badcase 很宝贵，发现一条就加一条进评测集。 真相：不可复现的无法验证、期望不明的无法打分、无根因标签的无法归因、一次性抖动不代表一类问题、未脱敏的有合规风险——不过入库标准的 badcase 是噪声不是资产。 记忆锚点：badcase 是原料，入库标准五项是闸门。

5. 误区：gold set 全放好样本，干净漂亮。 真相：没有坏样本就校准不了 judge——测不出 judge 是否一律说好，也发现不了"judge 误罚正确改述"这类系统性误判（Airbnb 78%→88% 的校准正是靠含失败样本的 gold 集）。 记忆锚点：gold set 必须含坏样本，否则尺子没法校。

6. 误区：用例预期输出直接写死在 JSON 里，一劳永逸。 真相：业务逻辑变更、模型升级后硬编码的预期会变成错误答案，评测开始误杀正确行为；腾讯的做法是基线快照（执行 1 次→人工确认→快照为基线），且 Agent 逻辑变更/模型升级/用例修改三个时机必须重做基线。 记忆锚点：预期答案也是资产，要有人审、有版本、有更新时机。

7. 误区：评测集越大越好，1000 条总比 100 条强。 真相：基线集的价值在判据清晰与风险覆盖，不在数量；过大意味着维护成本、judge 成本与 CI 时长暴涨，信号还被重复样本稀释。四家的起步口径都是 20-200 条量级；规模扩张走"分类采样集/长尾集/监控抽样"等外围层。 记忆锚点：尺子要准不要长，宁深勿水。

8. 误区：评测集只进不出，永远安全。 真相：不做毕业与降级，回归集无限膨胀到 CI 跑不动；但只做减法更危险——回归集只增不减是底线，泄压靠"降级抽样集"（退出必跑、保留抽查），P0/P1 风险样本永不降级。 记忆锚点：只增不减是原则，降级抽样是泄压阀。

9. 误区：私有评测集拿来当优化目标（自动改 prompt 刷分）没问题，反正是自己的集。 真相：eval 一旦成为目标就会被拟合——MIPROv2 等优化器以 eval 分数为搜索目标时，必须配留出集与定期换血；EDDOps 把污染防护与 provenance 列为评测资产的必备属性。被刷穿的评测集给出的门禁全是虚假信心。 记忆锚点：评测集当裁判就不能同时当考题——留出集隔离，定期换血。

六、推荐资源

一手工业实践（本章数字的全部出处）

1. Airbnb《Eval-driven development: Lessons from evaluating GenAI at scale》（Rohit Girme, Dan Miller, Mia Zhao, Lifan Yang, Clint Kelly）——EDD 五原则、50-100 gold set 含坏样本、每日 5% 去标识化抽样、隐私用途限定。
2. DoorDash《Building Ask DoorDash (Part 3): Evaluation》（Steven Xu, Fabio Flores, Twisha Jain, 2026-06-30）——checklist 式场景 rubric（素食 taco 清单）、fixtures、50 场景 × 8 trials 的成本账。https://careersatdoordash.com/blog/building-ask-doordash-part-three-evaluation/
3. 阿里技术《Agent 评测：方法论与体系设计》（2026 年第 28 篇）——幸存者偏差、四类来源、50-200 golden set、入库标准五项、样本治理四规则。
4. 腾讯技术工程《AI Agent & Skill 测评方案及落地实践》（martinskxu，TEG 云架构平台部网关测试团队）——四场景用例组织、正负用例、2-3 倍经验法则、基线快照、能力/回归毕业机制、TPerf 实战。

论文（arxiv ID 均经 _research/ 调研核实）

1. EDDOps: Evaluation-Driven Development and Operations of LLM Agents（arxiv 2411.13768，2024-11 首发 / 2025-11 v3）——评测资产 = 标准基准 + 领域知识 + 专家用例 + 合成数据；每条用例带 provenance/oracle/slice 标签；污染防护是评测资产必备属性。
2. MIPROv2（arxiv 2406.11695，2024-06）——eval 集既是测试又是优化目标时的泄漏与过拟合风险（留出集、定期换血的出处语境）。
3. GEPA（arxiv 2507.19457，2025-07）——Pareto 前沿按切片保留候选：按 slice 看指标、防止平均分掩盖退化。
4. τ-bench（arxiv 2406.12045，2024-06）——数据库终态校验与 pass^k：公开基准如何提供可靠外部坐标（GPT-4o retail pass^1 ≈60% → pass^8 ≈25%）。
5. WildChat（arxiv 2405.01470，2024-05）与 LMSYS-Chat-1M（arxiv 2309.11998，2023-09）——构建评测集与用户模拟器的真实对话语料原料。

延伸读物

1. Anthropic Engineering《Demystifying evals for AI agents》（2026-01）——20-50 条起步、capability vs regression 套件划分。https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
2. OpenAI《Evaluation best practices》——数据来源五路（生产/专家构造/历史/合成/采购）。https://developers.openai.com/api/docs/guides/evaluation-best-practices
3. Hamel Husain《Your AI Product Needs Evals》——evals-as-tests 运动的布道文本。https://hamel.dev/notes/llm/evals/

动手 labs（本特辑）

1. eval_lab02_golden_dataset.py（本章配套实验）：用例结构 dataclass、四类来源构造、五项入库标准检查器、同簇去重、毕业流转与回归门禁。 cd evals-special/labs && python3 eval_lab02_golden_dataset.py
2. eval_lab10_edd_loop.py：毕业后的用例如何进入 EDD 门禁闭环（回归集只增不减的断言）。 cd evals-special/labs && python3 eval_lab10_edd_loop.py
3. eval_lab07_simulator_fixtures.py：checklist 式 rubric 与 fixtures 的可运行版本（配合第 E8 章）。 cd evals-special/labs && python3 eval_lab07_simulator_fixtures.py
4. eval_lab08_statistics_ci.py：为什么 100 条 golden set 在统计上够用——置信区间与样本量计算（配合第 E9 章）。 cd evals-special/labs && python3 eval_lab08_statistics_ci.py
5. eval_lab05_judge_calibration.py：gold 集含坏样本如何支撑 judge 校准（78%→88% 的复现，配合第 E5 章）。 cd evals-special/labs && python3 eval_lab05_judge_calibration.py

章节交叉引用

• 指标怎么定：第 E2 章 · 评估指标体系
• 用例的期望行为如何变成评分器：第 E4 章 · 程序化评分
• gold 集如何校准 judge：第 E5 章 · LLM-as-Judge 深入；人工标注与口径裁决：第 E6 章
• fixtures 与模拟场景的用例形态：第 E8 章 · 对话 Agent 与仿真评测
• 样本量与置信区间的数学：第 E9 章 · 评估的统计学基础
• 评测集在开发循环中的用法：第 E10 章 · 评测驱动开发（EDD）；badcase 的根因分析：第 E11 章；线上回流与数据飞轮：第 E12 章
• 公开基准全景与选型：第 E13 章 · Benchmark 全景与前沿争议；四家实践完整案例：第 E15 章
• 主手册第 8 章 · Agent 评估与可观测性（本章的浓缩版对照：任务分类学 → 覆盖矩阵 → item spec → 分阶段扩建）

评分三层之一：程序化评分

一句话导读：评分三层（程序化 → LLM Judge → 人工）中，程序化评分是唯一"零成本、零漂移、可单测"的一层。本章讲透：哪些检查必须写成代码、检查规则如何用 DSL 落成可执行规格、评分输出为什么不能只有 pass/fail、粗筛→精判→人工复核的分层流水线怎么省钱、以及扣分制 / 基线快照 / LCS 轨迹对齐这些腾讯 TPerf 实战中打磨过的工程细节。学完本章，你能独立设计一套可进门禁、可喂 RCA 的程序化评分子系统，并清楚知道规则的边界在哪里（边界之外见第 E05 章）。

一、知识图谱

程序化评分（评分三层之一 · 确定性层）
│
├── 定位：确定性优先 ——「能用代码判断的，绝不用模型判断」
│   └── 三类评分器选择顺序：确定性评分器 → Rubric/Judge → 人工
│       成本：毫秒级/免费 → 秒级/API 费 → 分钟~小时级/人力
│       稳定性：100% → 有抖动 → 取决于标注员
│       覆盖：已知硬指标 → 未知软指标 → 主观+边缘场景
│
├── 检查清单（八类，Airbnb + 腾讯合集）
│   ├── 输出层：① schema/格式校验  ② 空输出与异常长度  ③ 关键词/正则黑白名单
│   ├── 任务层：④ P/R/F1（分类任务）  ⑤ 语义相似度（有参考答案时）
│   └── 执行层：⑥ 工具调用断言  ⑦ 执行指标（调用次数/token/耗时）  ⑧ 基线对比
│
├── 前提：结构化输出 —— JSON schema 强类型，不靠 prompt 措辞产出结构
│
├── 表达：expected_behavior DSL —— must_call / 参数约束 / 预算 / 关键词 / 基线
│
├── 输出规范：{score, passed, 问题分类, 置信度, 判定依据}
│   └── 问题分类 = 现象层 ≠ 根因 → 是 RCA 的「现象入口」
│
├── 流水线：分层筛查（阿里）
│   └── 粗筛层（便宜规则快速分流）→ 精判层（完整规则 + Judge）→ 人工复核层
│       纪律：粗筛已明确失败的样本，绝不进精判
│
├── 工程实践（腾讯扣分制 + 基线快照 + TPerf 实战）
│   ├── 扣分制：初始 100 分负分制，达标线 80 分，每次输出扣分明细 JSON
│   ├── 基线快照：单用例执行 1 次 → 人工确认 → 快照为基线
│   ├── 轨迹对齐：LCS 最长公共子序列 + 五类归一化，不一致/多余/缺少/顺序错各扣 2
│   └── 稳定性：pass^k 思想 + 容忍阈值分级（关键决策 0% / 辅助分析 ≤10% / 创意 ≤40%）
│
└── 边界：规则永远判不了的 —— 语义正确性 / 语气 / 策略合理性 → 第 E05 章 LLM-as-a-Judge

本章回答的核心问题，与三层评分的分工：

二、核心概念精讲

2.1 确定性优先：程序化评分在三层评分体系中的位置

阿里对评分层的总纲只有一句话：规则看"硬条件"（工具、状态、字段、禁用动作），LLM 看"语义/策略合理性"；能写成代码的由规则主判；高风险/抽检/低置信/变更观察期追加 LLM Judge；能自动稳定判断的不长期依赖人工。腾讯把同样的原则表述为选择优先级：确定性 > Rubric > 人工。Anthropic 在《Demystifying evals for AI agents》（2026-01）中给出的打分三层顺序完全一致：确定性代码检查（正则/终态/单测）→ 模型裁判 rubric → 人工抽检。

三家公司独立得出同一个顺序，原因可以拆成四个维度。腾讯给出的三类评分器对照表（原文数字）：

这张表有四个面试必须说出来的要点：

1. 稳定性 100% 是程序化评分独有的性质。Judge 有抖动需要降噪，人工取决于标注员水平；只有代码断言同一输入永远给同一结论——这是它能做"硬门禁"的根本原因，也是版本对比时分数差异可以归因于被测系统而非评分器的前提。
2. 规则写在代码里 = 可单测、可 review、可版本化。评分器本身是软件，享受软件工程的全部基础设施（回归测试、code review、git 历史）；judge 的规则藏在 prompt 里，人工的规则藏在人脑和标注指南里，可审计性依次递减。
3. 门禁角色分层：确定性评分器做硬门禁（不过不发），Rubric 做分级门禁（error 硬 / warning 软），人工不进门禁只做采样审查——把最贵的判定能力用在杠杆最高处（详见第 E06 章 · 人工评估与评分路由）。
4. "覆盖：已知硬指标"暗示了边界：程序化评分只能判"已经想到并能写成规则的东西"，未知软指标必须交给下一层。三层不是三选一，而是分层防御：Airbnb 十条要点的第 ⑥ 条就是"代码检查 + 模型 judge + 人工评审结合"。

确定性优先的经济学：一条样本走一次 LLM judge 是秒级延迟 + API 费用，走一次规则断言是毫秒级 + 免费。当评测规模达到 DoorDash 的"每天 2,000 个自动评分会话"时，能用规则判的每一项交给 judge，都是每天重复支付一笔本可省下的钱，还要额外承担 judge 抖动带来的噪声。

2.2 程序化检查清单：八类检查与适用场景

Airbnb 三层评估框架的第一层"程序化检查（确定性、最先跑）"给出五项，腾讯"确定性评分器"给出五项（部分重叠），合并去重后是一张可直接照抄的八类清单：

两点使用经验：

• 检查项 1、2 放最前面，永远先跑。Airbnb 对格式校验与空/异常长度的评价都是"永远有用"——它们不依赖任何业务知识，却能拦截最脏的一批样本（连 JSON 都解析不了的输出，后续一切检查都没有意义）。
• 从观察到的失败反推检查项，而不是拍脑袋穷举。Airbnb 旅行客服案例的探索阶段：跑 100 个 prompt 人工精读，发现 15 个 groundedness 失败、8 个正确但啰嗦、5 个不当拒答、3 个 JSON 失败——随后"建测试"阶段第一批落地的就是 JSON 与长度检查。程序化检查清单应该随 badcase 回流持续生长（详见第 E10 章 · 评测驱动开发）。

一个最小评分器的写法（示意骨架，完整可运行版见 lab03）——注意它已经遵守了 2.5 的五元组输出契约：

def check_tool_called(sample, required: list[str]) -> ScoreResult:
    """检查项 6：关键工具是否被调用。只看 trace 里的调用事件，毫秒级。"""
    actual = [c["name"] for c in sample.trace if c["type"] == "tool_call"]
    missing = [t for t in required if t not in actual]
    if missing:
        return ScoreResult(
            scorer="check_tool_called",
            score=0.0, passed=False,
            issue="tool_not_called",                    # 可枚举常量，RCA 入口
            confidence=1.0,                              # 确定性判定，置信度恒为 1
            evidence=f"关键工具 {missing} 未被调用（实际调用: {actual}）",
        )
    return ScoreResult("check_tool_called", 1.0, True, "none", 1.0,
                       f"全部关键工具已调用: {required}")

两个细节值得注意：① 确定性评分器的 confidence 恒为 1.0——它不会"拿不准"，拿不准是下一层的事；② evidence 里带上实际值（实际调用列表、实际金额），人审时一眼定位，不用重跑。

动手验证：本章配套实验 labs/eval_lab03_programmatic_scorers.py 实现了上表第 1、2、3、6、7 类评分器，并对 19 条构造样本（明显失败 / 边界 / 通过）跑完整流水线。运行：cd evals-special/labs && python3 eval_lab03_programmatic_scorers.py。

2.3 结构化输出是前提：JSON schema 强类型 vs prompt 措辞的脆弱性

程序化评分的一切前提是：被评的输出有稳定可解析的结构。Airbnb 的原话是：建议用结构化输出（JSON schema 严格类型化），不要只靠 prompt 措辞产出结构，否则下游管道会坏。

两种做法的对照：

工程落地的三件事：

1. 生成侧强制：能用 API 的 structured output / tool schema 约束就用，把格式失败率压到接近零；格式失败率本身要作为一个独立的可统计问题分类计入报告（lab03 中 invalid_json / missing_field / type_error 是三个独立 issue 常量，便于归因是"完全不会输出 JSON"还是"字段意识不足"）。
2. 解析侧兜底：即便有约束，也要有解析失败的兜底分支——解析失败本身就是评分信号（直接判 fail 并给出问题分类），绝不允许评分器抛异常中断整批评测。
3. 格式防护反哺生产：DoorDash 底座模型迁移案例（Claude Sonnet 4.6 → Gemini 3.5 Flash）中，Flash 的部分工具参数格式与工具签名不符（签名要 plain string，Flash 传了 {"dishes": [...]} JSON 对象）。修复手段之一就是确定性的：工具输入做确定性防护，错误形状强制转换回预期形状而非丢弃调用——最终迁移达成延迟降 35%、质量无损。评分侧发现的格式问题，反过来指导了生产侧的防御性编码，这是"确定性检查价值外溢"的典型例子。

2.4 expected_behavior：把期望行为写成可执行规格（DSL）

腾讯的用例由两部分组成：prompt + 检查规则；预期结果不硬编码在用例里，而是通过基线会话标识（session_id + message_id）指向一份人工确认正确的执行记录，评测时动态获取（TPerf 从 Knot API 拉取）。这套思路可以整理成一份 YAML 风格的 expected_behavior DSL（下例为按腾讯检查项体系整理的示意写法，非任何一家原文）：

case_id: refund-001
prompt: "订单 ORD-1001 我不想要了，帮我退款"
risk_level: P0                       # 风险等级决定门禁严格度与是否追加人工复核
expected_behavior:
  # —— 工具调用断言（腾讯：工具调用检查）——
  must_call: [query_order]           # 关键工具必须调用（未调用 = 硬失败）
  must_not_call: [force_refund]      # 禁用工具（越权/跳过校验的防线）
  partial_order:                     # 偏序约束：只约束先后，不约束全序列
    - [verify_identity, execute_refund]
  params:                            # 参数约束：类型 + 值域
    execute_refund.amount: {type: number, min: 0, max: "order.paid_amount"}
    query_order.order_id: {equals_input: "订单号"}

  # —— 输出断言（Airbnb：schema / 长度 / 关键词）——
  output_schema: {required: [action, reason], types: {action: enum[refund,reject,clarify]}}
  length: {min_chars: 16, max_chars: 400}
  keywords_blacklist: ["内部员工通道", "保证一定退款成功"]   # 过度承诺一票否决
  keywords_required_if:                # 白名单条件触发：提到退款就必须披露时效
    when_output_contains: "退款"
    must_contain: ["1-3个工作日"]

  # —— 执行指标（腾讯：调用次数 / token 阈值）——
  budget: {max_tool_calls: 6, max_total_latency_ms: 8000}

  # —— 基线对比（腾讯：基线快照机制）——
  baseline:
    session_ref: "sess_2026-07-12_refund-001"   # 指向人工确认过的基线会话
    compare: [call_sequence_normalized, artifact_exists, token_ratio<=1.5]

各检查字段的适用场景速查：

lab03 的样本集正是按这份 DSL 的字段逐项构造正负样本的（黑名单命中"内部员工通道"、白名单缺失"1-3个工作日"、调用 9 次超上限 6、总耗时 11500ms 超预算 8000ms、amount=300 超值域 [0,150]），每类失败都被对应的评分器拦下并给出正确问题分类。

2.5 评分输出规范：绝不止 pass/fail

阿里的评分输出规范是本章最重要的设计点之一：评分输出不止 pass/fail，还要有问题分类（现象层：事实性错误 / 答非所问 / 过度承诺）、问题现象、置信度、判定依据——为 RCA 提供"现象入口"；且现象分类 ≠ 最终根因。

一条失败样本如果只告诉你 "fail"，下游什么都做不了：不知道坏在哪个环节（无法聚类）、不知道判定有多可靠（无法决定要不要人工复核）、不知道为什么失败（无法回放调试）。因此评分器应统一返回一个五元组（lab03 的 ScoreResult 即此结构）：

一条真实失败样本的评分输出长这样（lab03 中"退款金额超值域"样本的等价物）：

{
  "case_id": "refund-001",
  "scorer": "check_tool_params",
  "score": 0.0,
  "passed": false,
  "issue": "tool_param_error",
  "confidence": 1.0,
  "evidence": "refund.amount=300.0 超出合法范围 [0, 150]（订单实付 150）",
  "prompt_version": "v1.8",
  "model": "candidate-a"
}

issue 供聚类与 RCA 映射，evidence 供人审复核，prompt_version/model 绑定让同一 issue 能按版本聚成问题簇。

三条落地纪律：

1. 问题分类必须是可枚举的常量，不是自由文本。lab03 定义了 13 个 issue 常量（empty_output / too_short / too_long / invalid_json / missing_field / type_error / blacklist_hit / whitelist_missing / tool_not_called / tool_param_error / too_many_calls / time_budget_exceeded / none）。可枚举才能可统计，才能被下游"问题现象 × 功能模块"映射表直接消费（详见第 E11 章 · Badcase 根因分析与优化闭环）。
2. 现象 ≠ 根因，必须分层。"关键工具未调用"是现象；根因可能是 prompt 没写清触发条件、工具描述缺失、或上下文被覆盖。阿里 RCA 五步的第二步"范围收敛"正是拿现象去查映射表缩小候选模块——程序化评分输出的 issue 就是这条流水线的入口。阿里 RCA 中"规则定位硬错误"的清单——工具未调用 / 顺序违反 SOP / 参数缺失 / 报错未重试 / DB 状态未变 / 引用来源不存在——几乎每一项都是程序化评分器能直接给出的确定性信号。
3. 判定依据让每条失败可申诉。evidence 字段（如 "refund.amount=300.0 超出合法范围 [0, 150]"）让人审和开发者不用重跑就能复核结论；没有 evidence 的 fail 在评审会上等于没有结论。

聚类的价值用阿里的实例最直观：报告不是列 100 条 badcase，而是产出"退款已发货场景中，Agent 23 次跳过订单状态校验，主要集中在 v1.8 Prompt"——这句话的"23 次"来自 issue=tool_not_called 的可统计聚合，"v1.8 Prompt"来自评分记录上绑定的 prompt 版本。没有结构化的评分输出，就不可能有这样的聚类。

2.6 分层筛查流水线：粗筛 → 精判 → 人工复核

当样本量大、评分手段贵贱悬殊时，不能让每条样本都走全套检查。阿里的分层筛查流水线：

待评样本（离线评测集 / 线上抽样 / badcase 回流）
   │
   ▼
┌─────────────────────────────────────────────┐
│ 粗筛层：规则 Scorer + 轻量 Judge               │
│ 空输出 / 长度 / JSON 解析 / 关键词（只看输出文本） │
└──────┬──────────────────────┬────────────────┘
       │ 明确失败              │ 通过或存疑
       ▼                      ▼
  直接定案                 ┌──────────────────────────────┐
  （给出问题分类，          │ 精判层：完整规则 + Judge        │
   绝不进精判）             │ 工具断言 / 参数值域 / LCS 对齐 /  │
                           │ LLM 语义判定（需要 trace 与模型） │
                           └──────┬─────────────┬──────────┘
                                  │ 结论可信      │ 高风险 / 低置信 / 冲突
                                  ▼              ▼
                             入库 + RCA      ┌────────────────┐
                                             │ 人工复核层（E06）│
                                             │ 终判并回收口径   │
                                             └────────────────┘

各层职责与输出：

关键纪律：粗筛已明确失败的样本绝不进精判。否则昂贵的判定能力（trace 解析、LLM 往返）被垃圾样本稀释，评测成本随样本量线性恶化。

分层的依据不是"哪个评分器写得早"，而是"评分器依赖的信息范围"：

• 只看输出文本本身的规则最便宜（空输出、长度、JSON 解析、关键词）→ 粗筛；
• 需要完整 trace / 工具调用记录 / 环境状态的判定较贵（工具断言、参数值域、LCS 对齐）→ 精判前段；
• 需要 LLM 语义判断的最贵（语气、groundedness、策略合理性）→ 精判后段；
• 需要政策口径与价值判断的 → 人工层。

成本账要用数字说话。lab03 的实测结果（固定种子、可复现）：19 条样本中粗筛拦截 8 条明显失败（空输出 / JSON 损坏 / 异常长度 / 缺字段 / 类型错误 / 黑名单 / 白名单缺失），11 条进入精判层；LLM Judge 仅被调用 10 次；按相对成本单元计，实际开销 490 单元 vs 全量走精判的 baseline 874 单元，节省 43.9%（实验断言阈值 ≥35%）。样本越脏、judge 越贵，分层节省越大——这正是阿里把分层筛查写进平台架构的原因。

人工复核层的路由条件（高风险 / 低置信 / 规则与 Judge 冲突 / 新模型新 Prompt 上线抽样等）展开见第 E06 章 · 人工评估与评分路由。

2.7 评分工程实践：扣分制、基线快照、轨迹对齐与稳定性阈值

这一节集中讲腾讯（含 TPerf 实战案例）沉淀下来的四套工程机制，都是"程序化评分如何长期运营"的答案。

（1）扣分制与达标线。 腾讯的评分规则：初始 100 分负分制，每处不符扣对应分至 0，达标线 80 分（推荐值，按 Agent 类型与业务风险调整）。扣分项（原文数字）：

每次评分输出 JSON 扣分明细 + 原因，渲染 HTML 报告归档；报告头部带用例总数 / 通过率 / 平均分 / 模型版本与费用 / 总 token / 平均费用每 Trial。扣分制的好处是分数可归因：80 分与 60 分的差距能逐项拆出来，而不是一个黑盒总分。

（2）基线快照机制。 基线 = 单用例执行 1 次后经人工确认的预期过程与预期结果快照——回答"正确的执行应该长什么样"。预期过程含 CoT、工具调用序列（入参返回）、中间产物、完整 Trace；预期结果含最终响应、输出文件、输出报告。流程：用例设计只定义 prompt 与检查规则 → 执行 1 次 → 人工审核 → 不可接受则修后重跑 → OK 则该次快照成为基线。后续每次执行与基线对比，分三个方面：

• 过程对比：调用序列一致 / 关键步骤缺失 / 顺序偏离 → 判"过程退化"（确定性评分器程序化判定）；思维链合理性、步骤最优交给 Rubric 以基线为参考答案对比语义差异；
• 结果对比：产物存在 / 关键内容缺失 / 产物不一致 → 判"结果退化"；结论准确性、表述完整性交给 Rubric；
• 效率对比：token / 步骤数超基线比例，如 >50% → 效率退化。

基线更新时机是常考点：Agent/Skill 逻辑变更、模型版本升级、用例本身修改（prompt 或检查规则变了）——三者任一发生，重新执行 1 次并人工确认。TPerf 的基线配置随代码仓库 Git 版本化；用例不硬编码预期输出，而是用基线会话标识指向人工确认正确的记录、评测时动态获取——这样基线更新有据可查、可回滚。

（3）轨迹序列对齐：LCS + 归一化（TPerf 实战）。 程序化判定"工具调用序列是否一致"最忌讳 exact match（时间戳不同、查询参数不同都会误判）。腾讯 TPerf 的做法：LCS（最长公共子序列）对齐基线与 Trial 步骤，先做归一化再对齐，归一化规则五条（原文）：时间戳占位 / 搜索工具忽略查询参数 / 写入操作只留路径 / 终端命令提取脚本名 / 连续读文件组内不校验顺序。对齐后：不一致 / 多余 / 缺少 / 顺序错各扣 2 分，上限 −10。这套机制在 lab06 有完整实现，运行：cd evals-special/labs && python3 eval_lab06_trajectory_eval.py（轨迹三层评估详见第 E07 章）。

TPerf 的效率评分同样是程序化的：耗时基准 300s，每超 10% 扣 1；token 以基线为基准每超 10% 扣 1，上限 −10。模型评分维度（关键判定不一致直接 −80、章节内容每项 −5 上限 −80）则交给 CodeBuddy CLI 逐项对比——确定性与模型评分各管一段，最后合成。

（4）一致性标准与得分公式。 基线对比不能要求逐字一致，腾讯给出三档标准：数值型整数精确、小数相对误差 ≤1%；结论型异常等级与关键发现一致；建议型核心排查方向一致即可。得分公式（TPerf）：trial_score = max(0, 100 + 各项扣分)；trial_pass = score ≥ 80；case_score = 全 pass 取均值，任一 trial 不达标则该用例 0 分——最后一条正是 pass^k 思想在评分规则里的落地（详见第 E02 章 · 评估指标体系与第 E09 章 · 统计学基础）。

（5）稳定性容忍阈值分级。 N 次执行（建议 N=5），只要 1 次不通过即存在稳定性风险，但容忍度按使用类型分级（腾讯原文）：关键决策类（问题定位/故障诊断）0%——N/N 全过，任何一次失败都可能误判；辅助分析类（性能分析/报告生成）≤10%；创意生成类（代码建议/文案）≤40%。N=5 的结果解读：全过 = 稳定；1/5 失败 = 存在幻觉，按类型判断；2/5 = 高幻觉率，深入排查；5/5 失败 = 稳定失败，先查任务定义或基线。腾讯特别提示：0% 的 pass^N 通常说明任务定义有问题，不是能力不行——这条经验在诊断"评分器自己坏了"时极其有用（人工评分的六个必要场景之一就是"诊断通过率异常：0% 或 100% 通常是任务/评分器坏了，不是模型弱"）。

TPerf 的零容忍决策是个好案例：TPerf 虽属辅助分析类，但结论直接影响优化决策与发布判断，一次错误结论可能导致性能问题漏检上线——因此采用关键决策类标准（任一 Trial 不达标该用例 0 分）。容忍阈值不是由任务类型机械决定的，而是由错误的业务代价决定的。

（6）用例集构成与执行画像（TPerf 实测数字）。 TPerf 的用例集按场景分组共 9 大类、30+ 用例，每个用例对应一条真实且不可变的压测记录（可复现）：

执行侧的工程数字：支持 7 模型对比（每用例 × 每模型参数化测试）；Trial 并发 + 评分并行 + 三评分器并行；限流自动重试（≤5 次）；单用例约 3000s；全量 30+ 用例 × 7 模型约 3–5 小时；用 pytest 实现、TCase 平台管理用例；trace 取自 Knot AG-UI 协议事件流（工具调用事件/文本消息事件/token 消耗），由事件流解析器构建调用步骤列表。另有两条值得抄的设计：基线配置随代码仓库 Git 版本化、执行结果每次重新生成并归档；支持重新评分——评分逻辑调整后无需重新触发 Agent，历史 trace 直接重算分。这把"评分器升级"与"被测系统重跑"解耦了，是评测平台降本的关键机制。

最后补两条门禁口径（腾讯引用 Anthropic 推荐）：确定性任务用例集整体通过率需 100%，非确定性任务 ≥95%；能力测评起步通过率 20–50%（目标山峰，主动拓展），回归测评接近 100%（防御漂移，只增不减，CI 每次运行），通过率稳定 100% 后用例"毕业"进回归集。

2.8 规则的边界：哪些东西规则永远判不了

程序化评分的边界与它的优点同源：只能判"能写成规则的已知硬条件"。阿里给出的分工口径：规则看硬条件（工具、状态、字段、禁用动作），LLM 看"语义/策略合理性"。三类东西规则永远判不了：

还有两个与边界相关的常考问题：

1. 假阳性（结果对、路径错）：回复看似正确，但执行路径已偏离或带风险——阿里对此的处方是加过程型与风险型检查（工具断言、禁用动作、SOP 顺序），腾讯则在 Rubric 评分输出中专门设了 is_false_positive 布尔字段（结果对但过程错的虚假成功）。程序化评分能抓住其中可规则化的部分（跳过校验工具、越权调用），抓不住的部分要靠轨迹级评估与 judge（详见第 E07 章 · 轨迹与 Agent 级评估）。
2. 规则会不会被钻空：关键词黑名单会被同义改写绕过、单点断言会被"表面达标"满足。对策是黑白名单只做必要非充分的第一道防线，关键检查用状态级多点校验，并给评分器本身配对抗样本（见本章易错点 9 与第 E10 章）。

拿到一个新检查需求时，用这个顺序决定它该落在哪一层：

这条判定能写成代码断言吗？
├── 能，且只看输出/trace 就有确定答案 ──→ 程序化评分（本章）
├── 写不成代码，但可以写成"人/模型能对照的判断标准" ──→ LLM Judge + rubric（第 E05 章）
│       └── judge 与人工一致率校准到 ~85% 才进自动化（阿里/腾讯口径）
└── 依赖内部政策口径 / 价值判断 / 高风险兜底 ──→ 人工（第 E06 章）

本章收束：程序化评分 = 确定性优先的八类检查 + 结构化输出前提 + DSL 规格 + 五元组输出 + 分层流水线 + 扣分制/基线/对齐工程。它判不了的语义、语气与策略合理性，正是下一层的领地——详见第 E05 章 · LLM-as-Judge 深入。

三、面试高频考点

四、经典面试题与参考答案

题 1（基础）：什么是程序化评分？常见的检查项有哪些？

答题思路：先给定义与四个特性（快/稳/免费/可单测），再报菜名式过八类清单，最后点一句它在三层中的位置。

参考答案： 程序化评分是把评测中的"硬条件"写成代码断言，由脚本（断言/Lint/AST/解析器）确定性执行。特点：毫秒级、零费用、稳定性 100%（同一输入永远同一结论）、可单测可版本化，是三层评分（确定性 > Rubric > 人工）的第一层，承担硬门禁角色。常见检查项八类：① schema/格式校验；② 空输出与异常长度；③ 关键词/正则黑白名单；④ 分类任务的 P/R/F1；⑤ 有参考答案时的语义相似度；⑥ 工具调用断言（是否调用/参数正确/禁用工具）；⑦ 执行指标（调用次数/token 阈值/耗时预算）；⑧ 基线对比（与人工确认的基线快照逐项比）。Airbnb 对前两项的评价是"永远有用"，并强调程序化检查"确定性、最先跑"。

题 2（基础）：为什么说"能用代码判断的绝不用模型"？三类评分器怎么选？

答题思路：四个理由（成本/稳定性/可审计/零偏差）逐条给数字，再给选择顺序与门禁分工，最后补"分层防御不是三选一"。

参考答案： 四个理由：① 成本——规则毫秒级免费，Judge 秒级加 API 费，人工分钟到小时级；② 稳定性——代码断言 100% 稳定，Judge 有抖动需降噪，人工取决于标注员水平；③ 可审计——规则在代码里可单测、可 review、可 git 版本化，prompt 里的规则做不到；④ 零偏差——不存在 judge 的位置/冗长/自我偏好问题。腾讯的选择优先级是确定性 > Rubric > 人工，门禁角色也分层：确定性做硬门禁，Rubric 做分级门禁（error 硬/warning 软），人工不进门禁只做采样审查与校准。但注意三层是分层防御不是三选一：规则只能判"已知硬指标"，语义/语气/策略合理性必须交给 Judge 与人工，阿里口径是"规则主判、Judge 辅助、人工兜底"。

题 3（进阶）：为什么说结构化输出是程序化评分的前提？如果模型只能输出自由文本会怎样？

答题思路：对照两种做法的失败模式，落到三件工程事（生成侧约束/解析兜底/格式失败计数），用 DoorDash 迁移案例收尾。

参考答案： 程序化评分依赖稳定可解析的结构。Airbnb 明确建议用 JSON schema 严格类型化的结构化输出，不要只靠 prompt 措辞产出结构，否则下游管道会坏。对照来看：强类型约束下格式由解码层保证，直接 json.loads 即可断言字段与类型；靠 prompt 措辞则无保证，模型偶发多说话、漏引号、markdown 包裹，解析要靠脆弱正则打补丁，失败还常常静默。工程上三件事：生成侧尽量用 API 的结构化输出约束；解析失败本身作为评分信号（判 fail 并给问题分类 invalid_json），绝不让评分器抛异常中断批跑；把格式失败率单列统计。一个反哺生产的例子：DoorDash 模型迁移时发现新模型工具参数形状不符，修复手段是确定性的输入防护——错误形状强制转换回预期形状而非丢弃调用，最终迁移延迟降 35%、质量无损。

题 4（进阶）：评分输出应该包含哪些字段？只报 pass/fail 会失去什么？

答题思路：报五元组字段，把每个字段挂到一个下游能力上（聚类/RCA 路由/人工路由/申诉），结尾强调现象 ≠ 根因。

参考答案： 阿里的规范：评分输出不止 pass/fail，还要有问题分类（现象层）、问题现象、置信度、判定依据。对应五元组实现：score（连续分，供趋势观察）/ passed（门禁硬判定）/ issue（可枚举的问题分类常量）/ confidence（把握度）/ evidence（判定依据）。只报 pass/fail 会失去四个下游能力：① 聚类——issue 可枚举才能统计出"退款已发货场景 23 次跳过订单状态校验，集中在 v1.8 Prompt"这样的问题簇；② RCA 路由——issue 是"问题现象 × 功能模块"映射表的键，是 RCA 的现象入口；③ 人工复核路由——低置信样本才升级人工；④ 申诉与回放——没有 evidence 的 fail 无法复核。最后强调现象 ≠ 根因：现象进 RCA 流水线，根因由后续分模块诊断产出，二者不能混。

题 5（进阶）：给一个电商退款客服 Agent 设计程序化评分规格（expected behavior）。

答题思路：按 DSL 五方面现场写规格（工具断言/输出断言/预算/基线/风险分级），并说明检查项来源是 badcase 观察而非拍脑袋。

参考答案： 按 DSL 五个方面写：① 工具断言——must_call 含 query_order（退款前必查订单），must_not_call 含绕过校验的直接退款工具，partial_order 约束先鉴权后执行，参数约束 execute_refund.amount ∈ [0, 订单实付]；② 输出断言——schema 必填 action/reason，长度上下限（过短装不下最小结构、过长疑似失控），黑名单（"保证一定退款成功"等过度承诺话术）与条件白名单（提到退款必须披露"1-3个工作日"时效）；③ 执行指标——调用次数上限、总耗时预算，防死循环与成本失控；④ 基线对比——与人工确认的基线会话做归一化后的序列对齐与效率比（token/步骤超基线 >50% 判效率退化）；⑤ 风险分级——P0 用例失败即门禁拦截，并按风险等级决定是否追加人工复核。设计依据不是拍脑袋，而是从 badcase 回流中观察到的失败模式反推（Airbnb 做法：跑 100 条样本人工精读再建测试）。

题 6（进阶）：如何程序化判定"工具调用序列是否正确"？exact match、无序集合、偏序约束、LCS 对齐各在什么时候用？

答题思路：四种粒度由严到松排开，各配一个适用场景，引用 TPerf 的归一化规则与扣分数字作为实战锚点。

参考答案： 四种粒度由严到松：① exact match——只适合完全确定性的流水线，真实 Agent 路径多样，用它会把合法替代路径判错；② 无序关键调用集合——只查 must_call/must-not-call 是否满足，适合安全护栏；③ 偏序约束——只约束关键先后（先鉴权后操作），保留路径自由度，适合流程合规；④ LCS 对齐 + 归一化——允许局部插入/缺失/乱序，按差异扣分而非一票否决，适合"过程是否退化"的回归判定。腾讯 TPerf 用第四种：先把步骤归一化（时间戳占位 / 搜索工具忽略查询参数 / 写入只留路径 / 终端命令提取脚本名 / 连续读文件组内不校验顺序），再 LCS 对齐，不一致/多余/缺少/顺序错各扣 2 分、上限 −10。核心取舍：断言守关键调用（安全），对齐量化退化程度（回归），永不要求全序列逐字一致。动手可跑 cd evals-special/labs && python3 eval_lab06_trajectory_eval.py。

题 7（进阶）：解释粗筛 → 精判 → 人工复核的分层筛查流水线，并算一笔成本账。

答题思路：三层职责 + 一条路由纪律 + 分层依据（依赖信息范围），最后用 lab03 的成本单元数字定量收尾。

参考答案： 阿里的三层设计：粗筛层用规则 Scorer + 轻量 Judge 快速分成明显通过/明显失败/存疑；精判层用完整规则 + Judge 确认 badcase 并产出初始问题分类/现象/置信度/判定依据；人工复核层处理高风险/低置信/冲突/口径未固化样本。路由纪律：粗筛已明确失败的样本绝不进精判，否则昂贵判定被垃圾样本稀释，成本随样本量线性恶化。分层依据是评分器依赖的信息范围：只看输出文本的最便宜（空输出/长度/JSON/关键词），需要完整 trace 的次之（工具断言/参数值域/LCS），需要 LLM 语义判断的最贵。成本账（lab03 实测，固定种子可复现）：19 条样本粗筛拦截 8 条，11 条进精判，LLM Judge 仅调用 10 次，实际开销 490 成本单元 vs 全量精判 baseline 874 单元，节省 43.9%（实验断言 ≥35%）。样本越脏、judge 越贵，节省越大。

题 8（系统设计）：为公司的 Agent 评测平台设计完整的程序化评分子系统。

答题思路：按"接口契约 → 用例规格 → 流水线 → 门禁报告 → RCA 衔接 → 评分器自身 QA"六组件讲，每个组件给一个关键设计决策。

参考答案： 六个组件：① 评分器接口契约——所有评分器（规则或 Judge 包装）统一返回五元组 {score, passed, issue, confidence, evidence} 加评分器署名，issue 从可枚举常量表取，接口即 lab03 的 ScoreResult；② 用例规格——prompt + expected_behavior DSL（must_call/参数约束/预算/黑白名单/基线引用），基线用会话标识指向人工确认快照而非硬编码预期输出，随代码仓库版本化；③ 分层流水线——粗筛（文本级便宜规则）→ 精判（trace 级规则 + Judge）→ 人工复核路由（低置信/高风险/冲突），粗筛定案的失败不进精判，全程记录各层拦截数与成本单元；④ 门禁与报告——扣分制（初始 100、达标线 80、扣分明细 JSON），P0 用例一票否决，输出按问题分类聚合的分布报告，版本对比带统计口径（详见第 E09 章）；⑤ 与 RCA 衔接——issue 作为"现象入口"进 RCA 映射表，评分记录绑定 prompt/模型版本支持问题簇聚类；⑥ 评分器自身 QA——配 golden 正负样本（含"看起来对其实错"的对抗样本）防误杀与漏放，评分器变更走回归，通过率 0%/100% 触发异常诊断（通常是评分器坏了不是模型弱），线上抽检与评分器结论的一致率持续监控。

题 9（进阶）：回归集通过率从 92% 突然变成 100%，你的第一反应是什么？怎么排查？

答题思路：展示"先怀疑测量系统再谈模型能力"的资深反应，按评分器 → 基线 → 用例 → 交叉验证的顺序排查。

参考答案： 第一反应不是庆祝，而是怀疑测量系统。腾讯的经验：通过率 0% 或 100% 通常是任务或评分器坏了，不是模型弱。排查顺序：① 查评分器——最近有没有改过断言、正则、基线或聚合逻辑？用留存的 golden 正负样本（尤其"看起来对其实错"的对抗样本）重跑评分器，验证它还能抓住坏样本；② 查基线——基线是否被意外重录成了当前版本的输出（基线与被测同源会互相"背书"）；③ 查用例——回归集是否被悄悄删掉了失败用例，或数据文件路径失效导致断言空转；④ 查被测——是否真发生了能力跃升，用另一套未动过的评测集交叉验证，并抽查 20~50 条"通过"样本人工确认。结论要能区分"真的变好了"与"尺子变松了"。同样的逻辑适用于分数突变 0%：先查任务定义与基线，再怀疑能力。

五、易错点 · 反直觉点

1. 把规则能判的交给 Judge：格式、字段、工具调用这类硬条件让 LLM 判，等于花钱买抖动——judge 会偶发误判且结论不可复现，门禁随之不稳。→ 真相：确定性 > Rubric > 人工是选择优先级，规则判不了的才升级。→ 记忆锚点：能写断言的绝不写 prompt。
2. 评分输出只有 pass/fail：失败的样本没法聚类、没法路由、没法归因，评测平台退化成"出分工具"。→ 真相：必须有问题分类/置信度/判定依据，它们是 RCA 的现象入口与人工复核的路由信号。→ 记忆锚点：fail 必须带着"为什么 fail"出门。
3. 把现象分类当根因："工具未调用"写进根因报告，修复动作只能是无力的"加强 prompt"。→ 真相：现象 ≠ 根因，现象进映射表缩圈，根因靠分模块诊断产出，要指向 owner 与处理动作。→ 记忆锚点：现象是门牌号，根因是住户。
4. 工具序列 exact match：时间戳不同、查询参数不同、合法路径顺序不同，全被判错；评测集退化成背答案。→ 真相：先归一化（时间戳占位/忽略查询参数/写入只留路径），再 LCS 对齐按差异扣分，关键调用用 must-call 断言守。→ 记忆锚点：断言守关键，对齐量退化。
5. 靠解析自由文本做程序化检查：模型一句"好的，结果如下："就能让你的正则全线失效。→ 真相：结构化输出（JSON schema 强类型）是前提，解析失败本身也要计为问题分类，而不是抛异常。→ 记忆锚点：结构不强制，规则全白写。
6. 所有样本走全套检查：明显 JSON 损坏的样本也去调 LLM judge，昂贵判定被垃圾稀释。→ 真相：粗筛定案的失败绝不进精判；分层依据是评分器依赖的信息范围。→ 记忆锚点：便宜的筛子先过，贵的判官只审疑案。
7. 通过率 100% 当好消息直接汇报：可能是评分器坏了、基线被同源污染、或失败用例被悄悄移除。→ 真相：0% 和 100% 都是异常信号，先查任务定义与评分器，再谈模型能力。→ 记忆锚点：满分先怀疑尺子。
8. 基线快照一劳永逸（或动不动重录）：被测系统升级后不重录，基线测的是旧世界；每次跑完都重录，基线永远在给现状背书。→ 真相：只有三个重录时机——Agent/Skill 逻辑变更、模型版本升级、用例本身修改，且重录必须再过一次人工确认。→ 记忆锚点：基线只在世界变了时变。
9. 把关键词黑名单当安全的全部：同义改写、拆字、隐喻都能绕过正则。→ 真相：黑白名单只是必要非充分的第一道防线，语义层的过度承诺/注入回声要靠 Judge，高风险场景保留人工复核。→ 记忆锚点：正则判存在，Judge 判语义，人判口径。

六、推荐资源

一手工业实践（本章素材来源，完整精读笔记见 _research/00-industry-practice.md）

1. 腾讯技术工程《AI Agent & Skill 测评方案及落地实践》（martinskxu，TEG 云架构平台部网关测试团队）——三类评分器对照表、扣分制与 80 分达标线、基线快照机制、稳定性容忍阈值分级、TPerf 实战（LCS 对齐 + 30+ 用例 × 7 模型）的原始出处。
2. 阿里技术《Agent 评测：方法论与体系设计》（2026 年第 28 篇）——"规则主判、Judge 辅助、人工兜底"、分层筛查流水线、评分输出规范（问题分类/置信度/判定依据）与 RCA 衔接的原始出处。
3. Airbnb《Eval-driven development: Lessons from evaluating GenAI at scale》（Rohit Girme, Dan Miller, Mia Zhao, Lifan Yang, Clint Kelly）——三层评估框架中程序化检查清单（schema/长度/关键词/P-R-F1/语义相似度）与结构化输出建议的原始出处。
4. DoorDash《Building Ask DoorDash (Part 3): Evaluation》（Steven Xu, Fabio Flores, Twisha Jain, 2026-06-30）——rubric 工程、Transcript Builder 与模型迁移案例（工具参数形状强制转换、延迟降 35%）。
5. Anthropic《Demystifying evals for AI agents》（2026-01）——打分三层顺序（确定性代码检查 > 模型 rubric > 人工校准）、"确定性任务通过率 100% / 非确定性 ≥95%"口径（腾讯文中引用）的出处。

动手实验（labs）

1. labs/eval_lab03_programmatic_scorers.py（本章核心实验）——五元组评分输出、规则评分器家族、粗筛→精判两层流水线与成本节省断言。运行：cd evals-special/labs && python3 eval_lab03_programmatic_scorers.py
2. labs/eval_lab06_trajectory_eval.py——LCS 轨迹对齐与归一化的实现，呼应 2.7 的 TPerf 机制（详见第 E07 章 · 轨迹与 Agent 级评估）。
3. labs/eval_lab09_rca_pipeline.py——评分输出的问题分类如何被 RCA 映射表消费（详见第 E11 章 · Badcase 根因分析与优化闭环）。
4. labs/eval_lab05_judge_calibration.py——下一章预告：规则判不了的交给 Judge 之前，先看 Judge 如何被校准（详见第 E05 章）。

交叉引用

• 三层评分的另外两层：第 E05 章 · LLM-as-Judge 深入、第 E06 章 · 人工评估与评分路由。
• 程序化评分的上下游：第 E02 章 · 评估指标体系（pass^k 与门禁统计口径）、第 E03 章 · 黄金数据集与用例设计（用例与基线从哪来）、第 E07 章 · 轨迹与 Agent 级评估（过程型检查的展开）、第 E10 章 · 评测驱动开发（检查项如何从失败中生长）、第 E11 章 · Badcase 根因分析（问题分类的下游）。
• 主手册第 8 章 · Agent 评估与可观测性——本章是其"规则式 grader"一节的深挖版。

评分三层之二：LLM-as-Judge 深入

一句话导读：规则判不了的（语气、有据性、策略合理性），交给 LLM Judge；但裁判本身是一台未经校验就会漂移的测量仪器。本章讲透：judge 的解剖结构（rubric + 证据切片 + verdict + rationale）、rubric 工程（二元检查 / eligibility 前置 / "描述成功长什么样"）、四大偏差的机理-量化-缓解全表、Airbnb 式五步校准闭环（78%→88% 实战）、阿里"三统计"持续运营、JudgeBench 揭示的"高一致≠正确"、以及 2024-2026 可训练 judge 与 judge 攻防前沿。学完本章，你能独立搭建、校准、运营一个可进门禁的 judge 子系统，并在面试中回答"裁判可信吗"这个 evals 最核心的问题。

一、知识图谱

LLM-as-Judge（评分三层之二 · 语义判定层）
│
├── 定位：规则判「硬条件」，Judge 判「语义/策略合理性」，人判「口径与校准」
│   └── Judge = 测量仪器：仪器不先校准，量出来的全是噪声
│       DoorDash 量级：平均 1 条/天员工反馈 → 2,000 个/天自动评分会话
│
├── 解剖（anatomy）
│   ├── 输入：rubric（单条标准）+ 证据切片（只给该标准依赖的 trace 切片）
│   ├── 五条纪律（Airbnb）：每维一个 judge / 与生成模型不同源 / 带 few-shot
│   │                        / 强制输出 schema / 清晰打分说明
│   └── 输出：verdict + rationale（+ 置信度 / 问题分类 → 供 RCA 消费）
│
├── Rubric 工程
│   ├── 二元检查 vs 分级打分（DoorDash：binary 汇总方差更低）
│   ├── eligibility 适用性前置：先判"本标准是否适用"，不适用则跳过
│   ├── 描述"成功长什么样"，而非指定唯一答案（容纳所有合法路径）
│   └── 铁律："如果人都无法一致地应用 rubric，模型也不可能"（Airbnb）
│
├── 四大偏差：位置 / 冗长 / 自我偏好 / 风格
│   ├── 量化：等质量对照组、swap consistency、长度回归、自我识别率
│   └── 缓解：交换聚合 / LC 回归 / 异构评审团 PoLL / 组合去偏
│       系统复盘（2604.23178, 2026）：单点策略收益有限；
│       中端模型 + 组合去偏 胜过前沿 judge 且便宜约 15 倍
│
├── 校准闭环（Airbnb 五步法）
│   ├── 50-100 gold set（必须含坏样本）→ 跑 judge → 目标一致率 high-80s~90s
│   ├── Cohen's κ / Krippendorff's α → 分歧分析改 rubric → 重复
│   ├── 工业口径：阿里 ~85% 进自动化；腾讯 ≥85% 可用
│   └── 自动化校准：GEPA 反射式 prompt 进化（DoorDash 生产在用）
│
├── 持续运营
│   ├── 金标校准集 + 失败模式变化时重新校准
│   ├── 升级三统计（阿里）：与人工一致性 / 高风险漏判率 / 边界样本稳定性
│   └── Judge 版本化：模型 + prompt + 参数 + 判决协议，建"计量档案"
│
├── 元评估：judge 之间高一致 ≠ judge 正确
│   ├── JudgeBench（2410.12784）：最强 judge 客观准确率 ~57% vs 人类 ~78%
│   ├── RewardBench / MM-Eval（18 种语言）/ Know Thy Judge（鲁棒性）
│   └── Judge 是攻击面：对抗攻击可让安全 judge 100% 放行有害输出
│
└── 前沿路线（2024-2026）
    ├── 可训练 judge：Prometheus 2 / Self-Taught Evaluators / GenRM / RM-R1
    ├── 零权重更新：GEPA 进化 judge prompt/rubric（rollout 少最高约 35 倍）
    └── 攻防：PoisonedRAG 投毒消费外部内容的 judge；judge 作奖励与 reward hacking

本章在三层评分中的坐标（衔接第 E04 章与第 E06 章）：

二、核心概念精讲

2.1 定位：Judge 是「测量仪器」，不是「打分捷径」

为什么需要这一层。 阿里对评分分工的总纲是：规则看"硬条件"（工具、状态、字段、禁用动作），LLM 看"语义/策略合理性"。第 E04 章已经说明规则永远判不了语义正确性、语气、策略合理性——这些"未知软指标"正是腾讯三类评分器对照表中 Rubric 评分器的覆盖区：大模型（固定版本）按写在 Prompt + JSON Schema 里的规则打分，秒级出结果、付 API 费用、稳定性"有抖动（需降噪）"、做分级门禁（error 硬 / warning 软）。

Judge 解决的是规模化判断问题。 DoorDash 在构建 Ask DoorDash 评测体系时，把"规模化判断"列为五大挑战之一："是否帮到用户需要人类级判断，但人工不可扩展"，解法就是"校准过的 LLM judge 顶替人类评审"。他们给出的量级对比（原文数字）：员工反馈平均只有 1 条/天，而评测体系做到 2,000 个/天自动评分会话；全国上线前 agent 质量分 +8 分、错误率近乎减半；全量回归从手工 6+ 小时压到自动约 20 分钟。没有 judge，这个反馈密度根本不可能存在。

但 judge 的定位必须摆正：它是一个带紧反馈环的测量问题。 DoorDash 的原话是两条：

1. "LLM Judge only useful if it agrees with human reviewers."（judge 只有与人工评审一致时才有用）
2. 人工用在杠杆最大处：定 rubric、标注校准集、审计 judge 行为；打分主力才是 judge。

换个说法：judge 是评测管线里最核心的"测量仪器"，仪器本身需要校准（元评估）、需要防作弊（鲁棒性测试）、需要版本管理（prompt + 模型 + 参数）——否则整个评测体系建立在一个未被校验的传感器上（_research/01-llm-judge.md 调研结论）。Airbnb 对未校准 judge 的判词只有八个字："未校准 judge 会制造误导性信心"——分数看起来很精确，量出来的却是 rubric 的缺陷。

引入 judge 之前，先回答三个问题（决策表）：

一笔经济学账。 DoorDash 全量回归 sweep = 50 场景 × 8 trials = 400 次对话：人工本地聊约 1 分钟/次 → 6+ 小时；模拟器 + judge 约 20 分钟。按每次变更都跑一遍、每周数次变更计算，judge 化评测把迭代周期从"天"压到"小时"——这正是"评测是迭代指南针"（第 E01 章）能成立的前提。反过来说：如果你的 judge 未经校准，你只是用 20 分钟拿到了一份错误的报告，然后更快地把事情做坏。

这一节的结论：引入 judge 的门槛很低（写个 prompt 就行），但让 judge 可信的门槛很高（校准 + 运营 + 元评估）。本章剩下七节全部在讲后半句。

2.2 Judge 的解剖：rubric + 证据切片 + verdict + rationale

一个生产级 judge 的调用接口由四部分组成。Airbnb 给出的五条纪律与 DoorDash 的接口设计互相印证：

Airbnb 的 judge 使用规则（原文）：

DoorDash 的 judge 接口（逐条标准独立评分）：

• 输入 = 标准 + 该标准依赖的证据。注意不是"整条 trace 扔给 judge"：每条标准声明自己依赖哪片证据，Transcript Builder 只把那一片交给 judge（详见第 E07 章 · 轨迹与 Agent 级评估）。例如 grounding 检查只拿"agent 的论断 + 背后工具输出"；多样性检查只拿"推荐结果 + 原始请求"；叙述检查只拿 agent 工作时流式输出的文本。聚焦证据让判断更一致，也避免无关 trace 噪声干扰判决。
• 输出 = verdict + 简短 rationale。

把两边合成一个可直接照抄的 judge prompt 骨架：

[system]
你是严格的评估器。只评判下面这【一条】标准，不要顺带评价任何其他质量。
先判断该标准是否适用于本会话（eligibility）；不适用则 applicable=false 并结束。

[user]
## 标准（rubric，单条）
{criterion_text}
## 判 1 分当且仅当
{positive_desc}          # 描述"成功长什么样"
## 判 0 分当且仅当
{negative_desc}          # 枚举典型失败现象
## Few-shot（含边界样本与判定思路）
{examples}
## 证据（仅该标准依赖的 trace 切片）
{evidence_slice}
## 输出（严格 JSON，禁止其他文本）
{"applicable": bool, "verdict": 0|1, "confidence": 0.0~1.0,
 "rationale": "引用证据中的原文说明判定依据，≤80 字"}

输出侧的规范与第 E04 章程序化评分的五元组同构：rationale 不止是"解释"，它承担三个职能——① 定位（错在哪一片证据上）；② badcase 聚类（阿里：输出 reason 用于定位与聚类）；③ 审计（人工复核 judge 行为时读的就是 rationale）。阿里进一步要求：每分档有可执行标准；输出 reason；高风险/抽检/低置信场景的 judge 结论要带置信度，置信度低的进人工路由（详见第 E06 章 · 人工评估与评分路由）。腾讯的 rubric 评分器输出则是典型的结构化样例：observation_points（回答是否基于项目规范而非通用知识 / 推理是否清晰连贯 / 有无幻觉编造）+ scoring（process_score 0-100、result_score 0-100、is_false_positive bool）。

为什么要 rationale 先行、分数随后？ 这与 GenRM（2408.15240，2024）揭示的规律一致：把评分做成"先写判据、再给结论"的生成任务，比裸打分更稳健、更可审计，还能继承模型的推理能力。工程上记住一条：没有 rationale 的分数不可 debug，也不可被人工审计。

一次完整调用的样例（DoorDash guardrail 风格）——注意 judge 只拿到该标准声明的那片证据：

输入：
  标准：沟通质量——回复简洁，不向用户叙述思维过程。
  证据切片：agent 面向用户的全部回复文本（不含内部工具调用）。
判定：
  {"applicable": true, "verdict": 0, "confidence": 0.92,
   "rationale": "第 2 轮回复中出现『我先去查一下 reorder skill 的返回』，
                 向用户叙述了内部执行过程，命中判 0 条件。",
   "问题分类": "叙述泄漏", "置信度": 0.92}

其中 问题分类/置信度 与第 E04 章程序化评分的输出规范同构——三层评分共用一套输出契约，下游的 RCA 流水线（第 E11 章）才能无差别消费。上例的"叙述泄漏"正是 DoorDash 实战案例 1（reasoning leakage）中被日常线上评分捕获的失败模式。

2.3 Rubric 工程：描述「成功长什么样」

Rubric 是 judge 的"法律条文"，其质量决定 judge 的上限。四个关键设计决策：

（1）二元检查 vs 分级打分

DoorDash 的选择很明确：每条标准是 binary check，汇总为会话级总分。其 guardrail 与 capability 标准实例（原文）：

• Guardrail（全体 agent 适用）："沟通质量：回复简洁、不向用户叙述思维过程"；"信任与诚实：不呈现可证伪虚假信息"。
• Capability·餐厅发现："约束满足：推荐满足配送时间/预算/饮食限制"；"结果多样性：真实差异而非近似重复"。
• Capability·杂货购物："购物执行：用户的明确修改请求被执行"；"商品相关性"。

（2）checklist 式场景 rubric：低方差信号。 DoorDash 的离线评测进一步把标准写成场景级清单。例："两人份 ≤$60 素食 taco 购物清单"——验证每件商品都是素食 taco 原料、小计 ≤$60。这种 checklist 比宽泛通用标准方差更低，小样本更有用，支撑更快迭代（详见第 E08 章 · 对话 Agent 与仿真评测）。

（3）eligibility 适用性前置。 DoorDash 的独创设计：judge 先判该标准是否适用本会话，不适用则跳过——例如"复购流程"标准不会因为一个食谱会话缺少复购步骤而被扣分。这就是 2.2 骨架中 applicable 字段的来源。不做 eligibility 的后果：总分被一堆"不适用但判了 0"的标准拖低，且拖低幅度随会话类型漂移，分数彻底失去可比性。

（4）描述成功，而非指定唯一答案。 DoorDash 对开放式目标的 rubric 要求（原文）："具体到每次能同样判，宽泛到容纳所有合法路径"。rubric 写"推荐满足配送时间/预算/饮食限制"，而不是"必须推荐那三家店"——前者判的是约束，后者背的是答案（对照第 E04 章"不要强制固定调用序列"的同一思想）。

一条铁律。 Airbnb 的原话值得裱起来："如果人都无法一致地应用 rubric，模型也不可能。" rubric 写得含糊（"回答要好"），人标不一致，此时不是 judge 不行，是标准不行——先停下修 rubric，再谈校准（人工分歧处理详见第 E06 章）。

完整 rubric 实例（Airbnb 房源 listing 解释可读性，判 0/1）：

标准：listing 解释文本的可读性与语气
判 1 分：输出读起来像一位「热情专业的旅行顾问」——
        语气友好、信息以旅客视角组织、措辞自然。
判 0 分（命中任一即 0）：
  - 语气错误（冷淡、机械、公文腔）
  - 出现内部术语（系统字段名、业务黑话）
  - 格式差（整块无排版、乱用符号）
  - 语法问题
  - 措辞过繁（堆砌形容词、信息密度低）
输出：reason（引用原文指出命中项）+ 0/1

注意这个实例同时示范了三件事：正向描述"成功长什么样"（热情专业的旅行顾问）+ 负向枚举可观察的失败现象 + 强制输出 reason。阿里对 rubric 的补充要求是"每分档有可执行标准"——即每个分数档都要像上面"判 0 分"列表一样落到可观察、可引用的现象，而不是形容词。

Rubric 好坏对照（评审 rubric 时逐行过一遍）：

2.4 Judge 偏差全景：四大偏差的机理、量化与缓解

Judge 是模型，模型就有偏好。2023-2026 的研究把偏差从" anecdote"变成了可量化的测量学问题。四大偏差总表（全部数字来自 _research/01-llm-judge.md）：

三个必须展开的要点：

（1）偏差必须被测量，而不是被假设。 量化偏差的"零刻度"是等质量对照组：两组答案真实质量完全相同时，任何一方的胜率显著偏离 50%，只能来自裁判偏差。动手验证：labs/eval_lab04_judge_bias.py 用 MockJudge（真实质量信号 + 可注入的位置/冗长/自我偏好偏差）完整演示了"注入偏差→量化→缓解→断言缓解有效"的闭环，运行：cd evals-special/labs && python3 eval_lab04_judge_bias.py。

（2）评审团（jury）优于单 judge，但有前提。 PoLL（2404.18796，2024，COLM）用三个不同家族的中等规模模型（Command-R、Llama-3-70B、Mistral-Large）组成评审团多数投票，替代单一 GPT-4 judge，三大发现：与人类判断的相关性高于单一大 judge；成本降到几分之一；跨家族组合显著缓解自我偏好（评委与选手不同源）。但集成的增益依赖评委误差独立：同代模型共享大量训练语料与对齐配方，风格偏好这类偏差是共模的——评审团对自我偏好有效，对共模的风格/格式偏差几乎无效。工程建议：评委来自 ≥2 个模型家族 + ≥2 种规模档。阿里实践中的对应做法是多 LLM 对抗打分治理"judge 与生成模型同源会偏爱自己风格"的偏差。

（3）不要迷信单点银弹，组合去偏 + 中端模型才是最优性价比。 2026 年的系统复盘论文 Judging the Judges（2604.23178，2026）对"去偏方法本身"做了大规模评测：9 种去偏策略 × 5 个 judge 模型（Google/Anthropic/OpenAI/Meta 四家族）× 3 个基准（MT-Bench n=400、LLMBar n=200、自建 n=375）× 4 类偏差。核心结论：

• 单点去偏策略（swap / calibration / CoT 等）多数收益有限且跨模型不稳定；
• 风格偏差是最主要的残余偏差（偏向 markdown/结构化输出）；
• "中端模型 + 组合去偏"能胜过前沿 judge 且便宜约 15 倍：Gemini 2.5 Flash + 组合策略达到全场最高一致率 71.0%（κ=0.549），约 $0.001/次评测；而最佳前沿配置 Claude Sonnet 4 仅 69.5%，约 $0.015/次评测。

这三条对工程决策的直接含义：去偏要像做 eval 一样在自己的领域数据上验证迁移性，而不是照搬论文结论；预算有限时，优先把钱花在组合策略上而不是最贵的模型上。

判决协议的选择：

默认判决协议（综合上述证据的推荐配置）： 双向位置交换取平均（或随机化位置）+ 判据先行（先写理由再打分）+ 温度 0 / 低采样；成对比较优于绝对打分（绝对打分必须配 rubric 锚定）。

2.5 Judge 校准完整流程：从 78% 到 88%

校准是 judge 从"能用"到"可信"的唯一通道。Airbnb 的五步法（原文流程）：

① 建 50-100 条 gold set（必须含坏样本）
② 用 judge 跑该集合
③ 目标一致率 high-80s~90s%；分歧可用 Cohen's kappa / Krippendorff's alpha 度量
④ 检查分歧样本 → 改 rubric / few-shot 示例 → 回到 ②
⑤ 失败模式变化时重新校准（rubric 演进、被测系统改版、新能力上线）

实战案例（Airbnb 旅行平台客服政策问答助手，校准段）： PM/SME 标注 60 条 gold（含失败样本）；judge 初始一致率 78%（过低）——分歧分析发现 judge 误罚了"正确的改述"（答案正确但与参考措辞不同，字面重叠式 rubric 把它判错）；修订 rubric（放宽改述惩罚、增加事实核对项）与 few-shot 后一致率达到 88%；同期检索改进减少了 groundedness 失败。labs/eval_lab05_judge_calibration.py 完整复刻了这个案例（60 条 gold、"正确的改述"与"流畅的错误"两类陷阱样本、v1 一致率 ~80% → v2 ≥85%），运行：cd evals-special/labs && python3 eval_lab05_judge_calibration.py。

gold set 的两条硬性要求：

1. 必须含坏样本（Airbnb 十条要点之⑦）。只有好样本的 gold set 校准不出 judge 的"漏判"能力——judge 全判 pass 也能刷高一致率。
2. 必须含两类陷阱样本：正确的改述（考验 judge 是否死抠字眼）与流畅的错误（读起来通顺、实则事实错误，考验 judge 能否核对事实）。前者对应上面 78% 的根因，后者对应"风格压倒实质"的偏差（2409.15268）。

一致率与 Cohen's kappa：为什么必须看两个数。 一致率（agreement）直观但有陷阱：若 gold set 中 90% 是 good 样本，judge 无脑全判 good 也有 90% 一致率。Cohen's kappa 扣除随机一致：

κ = (p_o − p_e) / (1 − p_e)
p_o = 观测一致率；p_e = 按双方边际分布算出的期望随机一致率
常用解读：<0.2 差 / 0.2-0.4 弱 / 0.4-0.6 中等 / 0.6-0.8 良好 / >0.8 几乎完全一致

样本类别不平衡越严重，κ 与一致率的差距越大——这正是"门禁要带统计口径"（第 E02 章、第 E09 章）在 judge 校准上的体现。多于两个标注者或有序类别时，用 Krippendorff's alpha。

分歧诊断决策表（第 ④ 步怎么"检查分歧"）： 把不一致样本按"样本类别 × 分歧方向"拆开后，按表索骥：

关键纪律：分歧分析必须按"样本类别 × 方向"拆开看，整体一致率会掩盖局部失效——这也是阿里要求 judge 输出 reason、DoorDash 把"审计 judge 行为"列为人工三大杠杆之一的原因。

四家公司的校准口径对照（全部为素材原文数字）：

GEPA：把 judge 调优从炼丹变成自动化搜索。 GEPA（2507.19457，2025）是反射式 prompt 进化优化器：对含 LLM prompt 的系统采样轨迹→用自然语言反思失败原因→提出并测试 prompt 更新→在帕累托前沿上合并互补经验。论文数字：在多个任务上平均超过 GRPO 约 6%、最高约 20%，超过最强 DSPy 优化器 MIPROv2 10% 以上（如 AIME-2025 上 +12%），且 rollout 消耗少最高约 35 倍。DoorDash 把它用在 judge 校准上（上表第四行）：迭代提出 judge prompt 修订，只保留在留出集上提升一致率的版本。其工程意义：当人工校准标签只有几十到几百条（典型情况）时，GEPA 式反射优化比 RL 微调现实得多；优化对象就是 rubric 措辞、评分流程、few-shot 示例，优化目标是"与人工标签的一致率"。注意防过拟合：必须保留 held-out 校准集——优化目标本身会被 gaming。

把五步法压成一段可执行的循环（labs/eval_lab05_judge_calibration.py 的完整实现即此结构）：

gold   = 加载校准集()            # 50-100 条人工判定；必含坏样本 +
                                 # 「正确的改述」「流畅的错误」两类陷阱
while True:
    pred   = judge.run(gold)                    # ② 跑 judge
    report = 一致性报告(pred, gold)              # 一致率 / κ / 混淆矩阵
    if report.一致率 >= 0.85 and report.kappa >= 0.6:
        break                                   # 达标：阿里/腾讯口径
    分歧 = report.按(样本类别, 方向).分组()       # ④ 分歧诊断（见上表）
    rubric = 修订(rubric, 分歧)                  # 修判据 / 加 few-shot
    judge  = judge.换(rubric)                    # 回到 ②
# ⑤ 上线后：失败模式变化（新能力/被测系统改版/rubric 演进）→ 回到 ①

校准不是一次性动作。 第 ⑤ 步常被忽视：被测系统的能力边界变了、新的失败模式出现了、rubric 新增标准了，judge 的判定边界就过期了。DoorDash 明确写道：校准持续——rubric 演进时收新标注、重新校准。

2.6 Judge 的持续运营：校准集、升级三统计、版本化

Judge 通过校准只是开始，生产运营要解决三个问题：怎么知道它漂移了？升级时怎么验证？分数跨版本怎么比？

上线前速查表（judge 计量自检，任何一条为"否"都先补课）：

（1）维护 Judge 金标校准集，定期复测。 像校准传感器一样管理 judge：为每个领域维护 50-500 条人工/客观真值的校准集，定期测一致率与正确率漂移（JudgeBench 式客观真值优先于人类一致率，见 2.7）。阿里把这件事写成制度：每次 Judge prompt/模型升级，固定产出三类统计：

（2）Judge 必须版本化。 judge 的"版本"是四元组：judge 模型（固定版本）+ judge prompt（含 rubric 与 few-shot）+ 生成参数（温度等）+ 判决协议（单评/成对、是否交换位置）。任一变更都产生新版本的分数，与旧版本分数不可直接比较。腾讯三类评分器表中 Rubric 评分器一栏写的就是"大模型（固定版本）"。实操上给每个 judge 建一份"计量档案"：记录模型、prompt 版本、温度、判决协议、校准集上的历史一致率曲线——回归评测分数异动时，第一步就是查 judge 的计量档案有没有变（对照第 E10 章"一次只改一个变量"的迭代纪律）。

（3）离线与线上必须同一套 judge。 DoorDash 的三条 lessons 之一：真实会话与模拟会话用同一 rubric + 同一校准 judge，两边分数才可对齐；各自调 judge，分数会以难调和的方式背离。离线门禁说"变好了"、线上体验说"变差了"时，如果两边 judge 不同源，你连"哪边在说谎"都无法判断（离线-线上联动详见第 E12 章 · 在线评估与数据飞轮）。

（4）接受"评测系统自己也产生 bug 报告"。 DoorDash 的第四条 lesson：被标记失败中有真实一部分是 harness 自身故障（judge 误报、trace 缺口），要与产品缺陷并行修复。这解释了为什么 judge 的 rationale 与置信度字段如此重要——它们是区分"模型错了"与"judge 错了"的唯二线索。

2.7 Judge 元评估：高一致 ≠ 正确

前两节讲"judge 与人工对齐"，本节讲一个更尖锐的问题：如果人工本身不是 ground truth 呢？如果 judge 们集体犯错呢？ 2024 年起，"judge 的元评估"成为独立赛道，核心结论一致：前沿 judge 在客观困难任务上准确率只有 ~57% 量级，与人类评审仍有明显差距，且 judge 间一致性高但可能"集体犯错"。

元评估基准速览（全部来自 _research/01-llm-judge.md）：

元评估指标工具箱（建 judge 校准报表时照抄）：

1. 与人类一致率 + Cohen's κ（校正随机一致）——基础款，但受人工标注噪声限制；
2. 客观真值正确率（JudgeBench 路线）——用单元测试/答案验证器产生金标偏好，比"与人类一致"更干净的测量，优先；
3. 相关性：Kendall τ / Spearman / Pearson——排行榜层面与人类偏好排名的相关（LC-AlpacaEval 的 0.937→0.982 即此类）；
4. 鲁棒性元评估（Know Thy Judge 路线）：风格扰动、提示敏感性、对抗攻击下的假阴性率变化；
5. Bradley-Terry / Elo（竞技场聚合）：P(A>B)=exp(θ_A)/(exp(θ_A)+exp(θ_B))，Arena-Hard（2406.11939，2024）用该框架把 arena 人类数据蒸馏为自动基准，与 Arena 相关性 ~0.98（动手实现见 labs/eval_lab11_arena_bradley_terry.py）。

对评测体系的直接含义：

• judge 间一致性不能当验收指标。 MT-Bench（2306.05685，2023，NeurIPS 2023）确立范式时以"GPT-4 judge 与人类一致性约 80%+，与人类间一致性相当"作为合法性论证；JudgeBench 之后，这个论证不够了——验收 judge 要看客观真值正确率与鲁棒性，一致性只是必要不充分条件。学界分歧至今未消：一致性足够用于"相对排名"（排行榜场景），但绝对能力测量必须回到客观真值或人类评审。
• 多语言产品不能只校准英语 judge（MM-Eval）；跨模态 judge 泛化更差（MM-JudgeBench，2604.19405，2026）。
• 安全 judge 上线前必须过鲁棒性元评估：风格扰动测试、对抗后缀、prompt injection——judge 是攻击面，不是旁观者（见 2.8）。
• judge 选型：RewardBench 初筛，领域校准集终裁。 RewardBench 只测"成对判别"，不测打分校准、多轮对话、鲁棒性——公开榜单上的名次不能替代自己校准集上的验证。任何"换 judge 模型"的决策，最终以本领域校准集的三统计（2.6）为准。

2.8 前沿路线：可训练 judge、prompt 进化与 judge 攻防

2024-2026 年，judge 从"提示词工程"走向"模型工程"，再走向"攻防对抗"。演进主线分四段（_research/01-llm-judge.md 调研结论）：

三条主线：

主线一：可训练的 judge（judge 专用模型）。

开源 judge 模型的三大工程红利（Prometheus 2 路线）：本地部署（数据不出域）、成本低、可针对领域 rubric 微调；rubric-as-input 的接口设计已成事实标准。JudgeLM（2310.17631，2023）则更早证明了"微调大模型做 judge"的可扩展性。

主线二：judge 调优的路线选择。 综合素材的工程建议：

主线三：judge 攻防。 这是与 reward hacking、安全评测的直接交界：

• judge 可被直接攻击。 Know Thy Judge（2503.04474，2025）：对抗攻击可让部分安全 judge 把 100% 的有害生成判为安全；仅改变输出风格即可让假阴性率跳变最高 0.24。安全评测管线必须包含"judge 红队"环节：风格扰动测试、对抗后缀、prompt injection 测试；judge 验收不能只看干净集准确率，还要报告鲁棒性元评估结果。
• 消费外部内容的 judge 可被投毒。 RAG/agent 场景中，judge 会读检索结果、网页、工具返回——间接 prompt injection 与检索投毒（PoisonedRAG，2402.07867，2024）可以直接操纵这些 judge。对策：judge 输入的证据切片做注入检测；关键安全判决用"judge + 规则 + 人工"三重冗余。
• judge 分数作训练奖励时的纪律。 SOS-Bench（2409.15268，2024）证明 judge 偏好与安全性、世界知识、指令跟随等具体对齐指标几乎不相关，以 judge 胜率为优化目标的偏好优化（DPO 等）可能只是在"优化风格"；AlpacaEval 的长度 gaming 是"训练钻评测空子"的早期案例。工业主流做法：judge 分数可作辅助奖励，但必须配规则验证器与人工抽检闭环，并监控训练过程中 judge 分数与独立基准的背离（Goodhart 预警）。
• agentic 场景的 rubric 验证仍是开放问题：Can LLM-as-a-Judge Reliably Verify Rubrics in Agentic Scenarios?（2606.29920，2026）正面追问 judge 在多步 agent 场景下验证 rubric 的可靠性；FairJudge（2602.06625，2026）尝试自适应、去偏、一致的 judge 框架。趋势判断：judge 校准正在成为一等公民，judge 鲁棒性测试将进入上线 checklist。

三、面试高频考点

四、经典面试题与参考答案

题 1（基础）：什么是 LLM-as-a-Judge？它在三层评分体系中的位置是什么？能判什么、不能判什么？

参考答案： LLM-as-a-Judge 指用一个（通常更强的）LLM 按 rubric 评判另一个模型的输出，自 MT-Bench（2306.05685，2023）确立以来成为开放式生成评测的事实标准，因为它便宜、快速、可扩展——DoorDash 用它把评测规模从员工反馈平均 1 条/天做到 2,000 个/天自动评分会话。三层评分中：规则判"硬条件"（schema、工具调用、预算），judge 判"语义/策略合理性"（语气、有据性、策略是否合理），人工定口径并校准 judge。Judge 能判的：规则写不出、但人能一致判断的软指标；不能判的：一是代码能判的（用了浪费且引入抖动，"能用代码判断的绝不用模型"）；二是依赖内部政策口径的问题（阿里：judge 能判礼貌/清晰，但判不了"叠加优惠差价是否应补偿"这类要业务先定口径的问题）；三是它自身未被校准前，什么都"判不准"——未校准 judge 制造误导性信心。

题 2（基础）：请描述一个生产级 judge 的解剖结构：输入由什么组成、输出应包含什么、有哪些工程纪律？

参考答案： 输入 = 单条标准（rubric）+ 该标准依赖的证据切片。DoorDash 的做法是每条标准声明依赖的证据，Transcript Builder 只把那一片给 judge（grounding 检查拿论断 + 工具输出；多样性检查拿推荐 + 原始请求），聚焦证据让判断更一致。输出 = verdict + rationale（+ 置信度、问题分类），rationale 要引用证据原文，供定位、badcase 聚类与人工审计。工程纪律按 Airbnb 五条：① 每个质量维度一个 judge（3-5 个经校准的评估器好过一堆嘈杂的）；② judge 模型尽量与生成模型不同源（防自我偏好）；③ 带 few-shot，含边界样本；④ 强制输出 JSON schema；⑤ 清晰打分说明，每分档有可执行标准。外加两条运营纪律：judge 前可加 eligibility 判断（不适用则跳过），judge 本身要版本化管理。

题 3（进阶）：设计 rubric 时，二元检查与分级打分（1-5 分）怎么选？为什么 DoorDash 推荐二元？

参考答案： 选 binary 的理由有四：① 方差低——"0 还是 1"的判定边界清晰，"3 分还是 4 分"连人都会摇摆，judge 抖动更大；② 汇总干净——逐条 binary 汇总为会话级总分，不需要为加权平均的权重吵架；③ 可独立迭代——每条标准单独可改、可单独校准，改一档描述则牵动全量表；④ 校准目标明确——一致率、漏判率都好算。DoorDash 的 guardrail/capability 标准全是 binary（如"不呈现可证伪虚假信息"）。分级打分适合创意质量、体验观察等确实存在连续谱的维度，但要求每分档有可执行标准（阿里）且锚定示例。折中实践：分级维度先拆成若干 binary 子检查，再映射回分档；以及 checklist 式场景 rubric（"两人份 ≤$60 素食 taco 清单"）——比宽泛标准方差更低，小样本即可迭代。无论哪种，铁律是"人都无法一致应用的 rubric，模型也不可能"。

题 4（进阶）：LLM Judge 有哪些常见偏差？分别如何量化、如何缓解？

参考答案： 四大偏差。① 位置偏差（2305.17926，2023）：成对评判偏好特定位置；量化用 swap consistency（交换 A/B 前后判决一致率）与等质量对照组胜率偏离 50% 的幅度；缓解是双向交换取平均或句级对齐 Split and Merge（2310.01432，2023）。② 冗长偏差：把更长当更好；量化用长度作为协变量回归看系数；缓解是 LC win rate（2404.04475，2024），把 AlpacaEval 与 Arena 人类排名相关性从 0.937 提到 0.982。③ 自我偏好（2404.13076，2024）：judge 偏好自己的输出，GPT-4 自我识别率约 72%；量化用自我识别率 + 自我胜率偏移；缓解是异构 judge、PoLL 评审团（2404.18796，2024）。④ 风格偏差（2409.15268，2024）：markdown/格式/自信语气压倒实质；量化用同内容双排版 A/B；2604.23178（2026）系统复盘 9 种去偏策略发现单点策略收益有限，风格偏差是最主要残余偏差（效应量 0.10-0.76），"中端模型 + 组合去偏"胜过前沿 judge 且便宜约 15 倍（71.0% κ=0.549 @ $0.001/次 vs Claude Sonnet 4 69.5% @ $0.015/次）。默认协议：交换聚合 + 判据先行 + 温度 0。

题 5（进阶）：请完整描述校准一个 LLM Judge 的流程，并给出量化标准。如果一致率长期卡在 80% 左右，你怎么诊断？

参考答案： 按 Airbnb 五步法：① 建 50-100 条 gold set，必须含坏样本与两类陷阱（正确的改述、流畅的错误）；② 用 judge 跑该集合；③ 看一致率，目标 high-80s~90s，分歧用 Cohen's κ / Krippendorff's α 度量（注意 base rate 陷阱）；④ 逐条检查分歧样本，归因是 rubric 含糊、few-shot 缺失还是 judge 能力不足，修 rubric/示例后重跑；⑤ 失败模式变化时重新校准。工业口径：阿里 ~85% 后进日常自动化，腾讯 ≥85% 可用，DoorDash 用 GEPA 自动迭代 judge prompt、只保留留出集一致率提升的版本。Airbnb 实战：judge 初始 78%，根因是字面重叠式 rubric 误罚正确的改述，修 rubric 后 88%。卡在 80% 的诊断路径：先按"样本类别 × 分歧方向"分解混淆矩阵（FN 误罚好答案 / FP 放过坏答案各在哪类样本）；若是改述被误罚→rubric 从字面匹配转向事实核对；若是流畅错误漏判→给 judge 证据核对步骤与负向 few-shot；若人机之间对同一批样本也不一致→先修 rubric 定义（人都用不一致，模型不可能一致）；最后才考虑换更强的 judge 模型。

题 6（进阶）：为什么只看一致率不够？请用例子说明 Cohen's kappa 的价值。

参考答案： 一致率不扣除"随机一致"，在类别不平衡时会严重虚高。例：gold set 100 条中 90 条 good、10 条 bad，judge 无脑全判 good，一致率也有 90%——看起来达标，实际上它对坏样本的漏判率是 100%。Cohen's kappa 用 κ=(p_o−p_e)/(1−p_e) 扣除随机一致 p_e，而 p_e 要按两个评分者各自的边际相乘再相加。这个 judge 恒判 good，它的边际是 good=1.0、bad=0.0，故 p_e=0.9×1.0+0.1×0.0=0.9，κ=(0.9−0.9)/(1−0.9)=0——恒判一类的退化 judge，κ 恰为 0，一致率的虚高被彻底戳穿。（易错点：若误把 judge 的边际也当成 gold 的 0.9/0.1，会算出 p_e=0.82、κ≈0.44；但 judge 从不判 bad，它的 P(good) 是 1 而非 0.9，一方恒判一类时 p_e 必然等于 p_o、κ 归零。）两点延伸：① 解读参考 <0.2 差 / 0.2-0.4 弱 / 0.4-0.6 中等 / 0.6-0.8 良好 / >0.8 几乎完全一致；② 校准集要故意保持足够的坏样本比例（Airbnb：gold set 必须含坏样本），否则一致率与 κ 同时失真。工程上还应把一致率拆成误罚率（FN，惩罚正确改述）与漏判率（FP，放过流畅错误）分别看——阿里对高风险样本的漏判率是 judge 升级的三统计之一，因为合规/资损场景的漏判代价远高于误罚。

题 7（进阶）：为什么 judge 要与被评模型不同源？如果成本所限只能用同一个模型，怎么降低风险？

参考答案： 实证依据是自我偏好偏差（2404.13076，2024）：GPT-4、Claude-2、Llama-2、Mistral 都能以显著高于随机的概率识别自己生成的文本，并在成对评判中系统性偏好自己的输出；GPT-4 对自身输出识别率约 72%，且自我偏好强度与自我识别能力正相关，开源模型更甚。同源自评相当于"裁判和选手是同一个模型"，回归对比中模型会系统性高估自己的新版本。缓解首选：judge 与被评模型分属不同模型家族；关键评测用 PoLL 评审团（2404.18796，2024）——三个跨家族中端模型（Command-R、Llama-3-70B、Mistral-Large）多数投票，与人类相关性高于单一 GPT-4 judge、成本降到几分之一、显著缓解自我偏好。成本所限必须同源时的降级方案：① 统计校准——按自我识别检测修正胜率估计（原论文提出的方法）；② 绝对打分 + rubric 锚定替代成对比较（自评的成对比较是自我偏好重灾区）；③ 用客观真值校准集持续测该同源 judge 的正确率（JudgeBench 路线），一旦漂移立即降级处理；④ 高风险维度坚持换异构 judge 或人工。注意 PoLL 的边界：评审团只对独立误差有效，风格偏好是共模偏差，跨家族集成也治不了。

题 8（进阶）：JudgeBench 显示最强 judge 的客观准确率只有 ~57%，而 judge 之间互相一致率超过 75%。这对我们构建评测体系意味着什么？

参考答案： 三个含义。① "judge 间高一致"不能作为验收指标——一致只说明它们共享同样的偏见（共模错误），不说明正确；MT-Bench 时代"与人类一致率 ~80%"的合法性论证在客观真值面前不够了（JudgeBench，2410.12784，2024，ICLR 2025：350 个由单元测试等客观验证产生偏好标签的困难问题，最强 judge ~57%，人类 ~78%）。② 元评估要优先用客观真值：凡是判据可程序验证的领域（代码、数学、格式约束），用单元测试/答案验证器造 judge 校准集，比"与人类一致"更干净；人类一致率留给无法客观验证的主观维度，并配 κ。③ 对 judge 的能力边界保持谦卑：judge 适合做"低成本筛查与排序"，不适合做"最终裁决"——所以三层评分里人工才是校准源与高风险终判者（第 E06 章），所以阿里要求高风险/低置信/冲突样本进人工复核，所以推理模型也不一定更好（JudgeBench 报告 o1 系在客观评判上不占优，"会推理"≠"会评判"）。答题加分点：补充 CriticBench（2402.14809，2024）的"批判能力弱于生成能力、自评弱于评他"，说明 57% 并非意外。

题 9（系统设计）：为公司的 Agent 评测平台设计一个「Judge 服务」：解剖、校准、版本化、路由、监控，给出完整方案。

参考答案： 分五层设计。① 接口层：judge 按"单条标准 + 证据切片"调用（DoorDash 接口），输出 {applicable, verdict, confidence, rationale, 问题分类}；每个业务维度一个 judge，控制在 3-5 个（Airbnb）；证据由 Transcript Builder 按标准声明切片供给（第 E07 章）。② 校准层：每 judge 配 50-100 条 gold 校准集（含坏样本、正确的改述、流畅的错误、高风险样本）；按五步法迭代到一致率 ≥85%（腾讯口径）且 κ≥0.6；rubric 措辞优化可用 GEPA 自动进化，留出集防过拟合。③ 版本层：judge 版本 = 模型 + prompt + 温度 + 协议四元组，任一变化即新版本；每个版本建计量档案（校准集历史曲线）；新旧版本过渡期双跑对比。④ 路由层（衔接第 E06 章）：judge 结论不是终点——边界分/低置信/rationale 含糊/多 judge 分歧/规则与 judge 冲突 → 人工终判并回收口径；高风险场景自动通过也定期人工复核。⑤ 监控层：阿里三统计随每次升级固定产出（与人工一致性、高风险漏判率、边界样本稳定性）；日常抽样人工审计 judge 行为（DoorDash：审计 judge 是人工三大杠杆之一）；离线与线上强制同一 rubric + 同一 judge；把 harness 自身故障（judge 误报）单列缺陷池并行修复。成本策略：中端模型 + 组合去偏优先（2604.23178：71.0% 一致率 @ $0.001/次，比前沿配置便宜约 15 倍），关键门禁维度再上评审团。

题 10（系统设计）：你准备把 judge 分数作为 RL 训练的奖励信号。请评估风险并设计治理方案。

参考答案： 风险有四类。① 风格 gaming：SOS-Bench（2409.15268，2024）证明 judge 偏好与安全性/知识/指令跟随等真实对齐指标几乎不相关，却强烈偏好格式、长度、拒绝话术——以 judge 胜率为目标做 DPO/RL 可能只是在优化风格；AlpacaEval 长度 gaming 是早期案例（LC-AlpacaEval，2404.04475，2024 因此而生）。② 直接攻击：训练循环里的策略模型会主动探索 judge 的漏洞，本质是自动化、持续化的对抗攻击——Know Thy Judge（2503.04474，2025）显示对抗攻击可让安全 judge 100% 放行有害输出，风格扰动即可让假阴性率跳变 0.24。③ 回声室：若用 judge 生成偏好数据再训模型（Self-Taught Evaluators，2408.02666，2024 式循环），种子 judge 的偏差会被放大，存在迭代坍缩风险。④ Goodhart：judge 分数上升但真实能力不涨，且越优化背离越大。治理方案：a) judge 分数只做辅助奖励，与规则验证器（可验证判据优先，参考 RM-R1，2505.02387，2025 的思路）和人工抽检组合；b) 训练前做 gaming 探针（长度/格式扰动测试），确认分数不可被低成本刷取；c) 保留独立于训练分布的冻结校准集，定期测 judge 客观正确率（JudgeBench 路线）；d) 监控训练过程中 judge 分数与独立基准（线上信号、客观测试）的背离，背离超阈值即停训复盘；e) judge 与被训模型不同源，防自我偏好混入奖励。

五、易错点 · 反直觉点

1. 误区：写一个"万能 judge"对所有维度统一打分。 真相：Airbnb 明确要求每个质量维度一个 judge，且 judge 要少而精——3-5 个经校准的评估器好过一堆嘈杂的；万能 judge 会把语气问题与事实问题混在一个分数里，无法归因、无法单独校准。记忆锚点：judge 按维度拆，宁少勿杂。
2. 误区：judge 写个 prompt 就能进门禁。 真相：未校准 judge 制造"误导性信心"——分数精确，量的却是 rubric 的缺陷；必须校准到 high-80s~90s（Airbnb）/ ≥85%（阿里、腾讯口径）之后才谈自动化。记忆锚点：先校准，再门禁。
3. 误区：judge 用和被评模型同一个模型，省钱又省心。 真相：自我偏好有硬实证——GPT-4 对自己输出的识别率约 72%，四个主流模型都系统性偏好自己的生成（2404.13076，2024）；同源自评会系统性高估自己的新版本。记忆锚点：裁判与选手不同源。
4. 误区：judge 之间一致率 >90%，说明 judge 可靠。 真相：JudgeBench（2410.12784，2024）显示 judge 间互相一致率 >75%，但最强 judge 客观准确率只有 ~57%（人类 ~78%），且一致性与正确性相关性很弱——它们会一起犯错。记忆锚点：高一致 ≠ 正确，可能是共谋。
5. 误区：校准集全放好样本，因为"坏样本看起来不吉利"。 真相：全好样本的校准集测不出漏判能力——judge 无脑全判 pass 也能刷出高一致率；gold set 必须含坏样本（Airbnb 十条要点之⑦），且要含"正确的改述"与"流畅的错误"两类陷阱。记忆锚点：没有坏样本的校准集是假的。
6. 误区：一致率 90% 已经很好，不必看 kappa。 真相：若 90% 样本是 good，全判 good 的傻 judge 一致率也是 90%（但 κ=0——恒判一类零判别力）。类别越不平衡，一致率越会撒谎。记忆锚点：看 κ，别只看一致率。
7. 误区：找到一篇去偏论文就照搬（swap / CoT / 校准各挑一个"银弹"）。 真相：2604.23178（2026）对 9 种策略 × 5 模型 × 3 基准的系统复盘显示：单点策略多数收益有限且跨模型不稳定；风格偏差是最主要的残余偏差；组合策略 + 中端模型才是性价比之王（便宜约 15 倍且一致率更高）。记忆锚点：去偏靠组合，银弹不存在。
8. 误区：judge prompt 随手改，反正"改得更好了"。 真相：judge 版本 = 模型 + prompt + 参数 + 协议，任一变更都让新旧分数不可比；回归异动时查不到是模型变了还是 judge 变了。阿里的三统计（一致性/高风险漏判率/边界稳定性）必须随每次升级产出。记忆锚点：judge 即资产，改动即发版。
9. 误区：推理模型（o1/R1 系）一定更会当 judge。 真相：JudgeBench 报告推理型模型在部分客观评判任务上并不占优；Critique 研究显示 CoT judge 会"推理出错误的自信"。"会推理"≠"会评判"，评判能力要单独元评估。记忆锚点：推理强 ≠ 评判强。
10. 误区：judge 不执行代码、不碰外部世界，所以没有安全问题。 真相：judge 是攻击面——对抗攻击可让安全 judge 把 100% 的有害输出判为安全（2503.04474，2025）；消费检索内容/工具返回的 judge 可被 PoisonedRAG（2402.07867，2024）式投毒操纵；judge 分数进训练循环还会被 reward hacking。记忆锚点：judge 也要红队。

六、推荐资源

一手工业实践（本章素材来源，完整精读笔记见 _research/00-industry-practice.md 与 _research/01-llm-judge.md）

1. Airbnb《Eval-driven development: Lessons from evaluating GenAI at scale》——judge 五条使用规则、rubric 0/1 实例、五步校准法、78%→88% 案例、"未校准 judge 制造误导性信心"的原始出处。
2. DoorDash《Building Ask DoorDash (Part 3): Evaluation》（2026-06-30）——judge 接口（标准+证据→verdict+rationale）、eligibility 前置、binary rubric 汇总、GEPA 校准 judge、离线/线上同一 judge 的原始出处。
3. 阿里技术《Agent 评测：方法论与体系设计》——"规则主判、Judge 辅助、人工兜底"、~85% 校准口径、升级三统计、多 LLM 对抗打分的原始出处。
4. 腾讯技术工程《AI Agent & Skill 测评方案及落地实践》——Rubric 评分器（固定版本大模型 + Prompt + JSON Schema）、≥85% 可用口径、"校准 LLM 评委是人工最核心场景"的原始出处。

前沿论文（全部来自 _research/01-llm-judge.md，arxiv ID 已核实）

1. MT-Bench / Chatbot Arena：Judging LLM-as-a-Judge（2306.05685，2023，NeurIPS 2023）——范式奠基，GPT-4 judge 与人类一致性约 80%+。
2. 位置偏差：Large Language Models are not Fair Evaluators（2305.17926，2023）；句级对齐：Split and Merge（2310.01432，2023）。
3. 自我偏好：LLM Evaluators Recognize and Favor Their Own Generations（2404.13076，2024）。
4. 风格偏差：Style Outweighs Substance（2409.15268，2024）。
5. 长度控制：Length-Controlled AlpacaEval（2404.04475，2024，TMLR）。
6. 评审团：Replacing Judges with Juries (PoLL)（2404.18796，2024，COLM）。
7. 去偏系统复盘：Judging the Judges（2604.23178，2026）。
8. 元评估：JudgeBench（2410.12784，2024，ICLR 2025）、RewardBench（2403.13787，2024，NeurIPS D&B）、CriticBench（2402.14809，2024，ACL Findings）、MM-Eval（2410.17578，2024）。
9. 鲁棒性与攻防：Know Thy Judge（2503.04474，2025）、PoisonedRAG（2402.07867，2024）。
10. 可训练 judge：Prometheus 2（2405.01535，2024，EMNLP）、Self-Taught Evaluators（2408.02666，2024）、GenRM（2408.15240，2024，NeurIPS）、RM-R1（2505.02387，2025）、CompassJudger-2（2507.09104，2025）、JudgeLM（2310.17631，2023）。
11. Prompt 进化：GEPA（2507.19457，2025）；综述：A Survey on LLM-as-a-Judge（2411.15594，2024）；蒸馏基准：Arena-Hard（2406.11939，2024）。

动手实验（labs）

1. labs/eval_lab04_judge_bias.py（本章核心实验之一）——MockJudge 注入位置/冗长/自我偏好偏差→等质量对照组量化→swap-and-average / 多 judge 投票 / 长度受控评分三种缓解的有效性断言。运行：cd evals-special/labs && python3 eval_lab04_judge_bias.py
2. labs/eval_lab05_judge_calibration.py（本章核心实验之二）——复刻 Airbnb 78%→88% 校准案例：60 条 gold（含"正确的改述"与"流畅的错误"）、混淆矩阵 / 一致率 / Cohen's κ、rubric 修订闭环、升级三统计监控。运行：cd evals-special/labs && python3 eval_lab05_judge_calibration.py
3. labs/eval_lab11_arena_bradley_terry.py——Bradley-Terry / Elo 与长度风格控制，呼应 2.7 的竞技场聚合与 LC 思想（详见第 E09 章 · 评估的统计学基础）。运行：cd evals-special/labs && python3 eval_lab11_arena_bradley_terry.py

交叉引用

• 三层评分的另外两层：第 E04 章 · 程序化评分（judge 的上游边界）、第 E06 章 · 人工评估与评分路由（judge 的校准源与人工兜底）。
• judge 的上下游：第 E03 章 · 黄金数据集（校准集从哪来）、第 E07 章 · 轨迹与 Agent 级评估（Transcript Builder 证据切片全貌）、第 E09 章 · 评估的统计学基础（一致率/κ/置信区间）、第 E10 章 · 评测驱动开发（judge 筛候选、一次一变量）、第 E12 章 · 在线评估与数据飞轮（离线/线上同一 judge、judge 分数作奖励）、第 E14 章 · 前沿论文全景（judge 方向综述）、第 E15 章 · 工业实践案例研究（四家 judge 口径横向对比）。
• 主手册第 8 章 · Agent 评估与可观测性——本章是其"LLM-as-Judge"一节的深挖版。

评分三层之三：人工评估与评分路由

一句话导读：在「规则 → Judge → 人工」的三层评分体系里，人工是最贵、最慢、最不可扩展的一层，却也是唯一能产出新口径、裁决自动评分器的一层。本章回答四个问题：人力该花在哪些工作（六个高杠杆场景）、标注工程怎么做（指南/分歧/一致性）、哪些样本值得送人工（评分路由）、人工结论如何放大（反哺闭环）。学完你能设计一套完整的人机协同评分流水线，并扛住系统设计级的追问。

前置阅读：第 E04 章 · 程序化评分（规则层）、第 E05 章 · LLM-as-Judge 深入（Judge 层）。本章是评分三层的收口篇——三层不是并列的三选一，而是一条有路由、有反哺的流水线，人工站在流水线的两个关键位置：校准入口与冲突出口。

一、知识图谱

                  评分三层（选择优先级：确定性 > Rubric > 人工）
   ┌───────────────────┬───────────────────┬───────────────────┐
   ▼                   ▼                   ▼
【第一层 规则】      【第二层 Judge】      【第三层 人工】
 硬条件/工具/schema   语义/策略/rubric      兜底 + 校准源
 毫秒级·稳定100%      秒级·有抖动·需校准    分钟-小时级·最贵·最权威
   │                   │                   ▲
   │ 明显通过/明显失败  │ 一致率≥85%后放量    │
   ├──────────────────►├───────────────────┤
   │                   │                   │
   └── 不确定/冲突/新版本 ──►【人工评分路由】──┘
                       ①边界分 ②低置信 ③reason含糊
                       ④多judge分歧 ⑤新版本抽样 ⑥规则-Judge冲突
                                │
        ┌──────────┬──────────┬─┴───────┬───────────┐
        ▼          ▼          ▼         ▼           ▼
    校准Judge   主观打分   诊断0%/100%  建Ground   Trace采样
    （最核心）              异常        Truth      +高风险100%复核
        │                               │
        └───────────────┬───────────────┘
                        ▼
        专家时间分配：60%+ 花在「校准Judge」与「诊断异常」
                  坚决不做日常全量打分
                        │
                        ▼
        【反哺】人工结论 → 校准规则 / Judge prompt / 根因标签体系

先用一张表定位本章在评分三层中的角色：

（表格口径来自腾讯三类评分器对照；"人工不进门禁"是关键设计决策：人力无法支撑每次 CI 运行，人工的价值在门禁之外——定口径、校尺子、查漏。）

二、核心概念精讲

2.1 定位：人工是评分系统的「校准源」，不是「打分主力」

三层的分工原则，阿里的一句话最凝练：规则主判，Judge 辅助，人工兜底。规则看"硬条件"（工具、状态、字段、禁用动作），LLM 看"语义/策略合理性"，能写成代码的由规则主判；高风险/抽检/低置信/变更观察期追加 LLM Judge；能自动稳定判断的不长期依赖人工（阿里）。腾讯给出同样的优先级：确定性 > Rubric > 人工。

为什么"人工全量打分"是反模式？三笔账：

1. 成本账：人工评分是分钟-小时级/人力成本，而自动评分是毫秒-秒级。腾讯的痛点表写得很直白：Skill 越多、模型越快，人肉回归指数增长，只能选择性验证、留下盲区。DoorDash 的数字更具冲击力——全量回归从手工 6+ 小时压到自动约 20 分钟（50 场景 × 8 trials = 400 次对话的 sweep）。
2. 规模账：日常打分的样本量是生产流量级的。DoorDash 从"平均 1 条/天员工反馈"做到"2,000 个/天自动评分会话"，靠的是校准过的 Judge 而不是扩招标注员。
3. 杠杆账：专家最稀缺的能力是"判断什么是好"，而不是"重复判断"。把专家耗在逐条打分上，等于用最贵的资源做最可替代的工作。

由此得到三条被多家公司验证的经验法则：

注意这四家的表述殊途同归：人工评估的成熟度，不看"能动员多少人打分"，而看"自动化评分器以多小的人力投入变得可信"。人工不是评分系统的执行层，而是它的校准源与仲裁庭。

2.2 人工评估的六个高杠杆场景

腾讯把"人工必须出场"的场景收敛为六个，这是本章的主干清单：

六个场景的内在结构值得记住：①④ 是为自动化评分器"造尺子"，③⑤ 是给自动化评分器"质检"，②⑥ 是自动化永远不该独自碰的领域。

再叠上另外两家的清单，覆盖面更完整：

• Airbnb 的人工四用途：建 ground truth；安全高风险决策；细微差别与创意（nuance & creativity）；解决自动评估器间冲突——最后一条是"多 judge 分歧进人工"这个路由规则的方法论来源。
• 阿里的适用环节：① 新建评测集定口径——例如"订单已发货 + 用户拒收 + 运费险 + 特殊类目"该走哪条流程，需要业务先定，这不是模型问题也不是评分器问题，是业务规则问题；② 校准 Judge——"judge 能判礼貌/清晰，但判不了'叠加优惠差价是否应补偿'这类依赖内部政策的问题"；③ 处理争议样本；④ 抽查高风险场景。

一个面试可以直接复述的判断框架：凡是答案依赖"内部政策、业务口径、价值排序"的样本，自动评分器天然无权裁决——因为它们的训练分布里没有你的内部政策。这类样本永远要路由给人（见 2.6 分工决策表）。

各场景的操作要点（面试追问"具体怎么做"时的得分点）：

• ① 校准 Judge：校准样本要覆盖各分段与边界案例；人工对校准集的判定结论本身要版本化存档——它是后续每次 judge 升级对照的金标。
• ② 主观任务打分：给标注员的 rubric 要写行为锚点（"什么样的回复算简洁"），而不是"质量好/一般/差"这类抽象词；每次打分输出 reason，供他人复核与后续分歧分析。
• ③ 异常诊断：标准动作是分层抽样 10–20 条逐条精读，读的是输入、输出、trace 三件套而非只读输出；对照旧版本被评系统重跑，区分"模型变了"还是"尺子变了"。
• ④ Ground Truth：参考解不只记最终答案，还记关键过程（工具调用序列、中间产物）。腾讯的基线快照机制是标准做法：用例先执行 1 次 → 人工审核过程与结果 → 不可接受则修后重跑 → 可接受则该次快照成为基线，后续每次执行与基线对比；Agent/Skill 逻辑变更、模型升级或用例本身修改时重新快照。
• ⑤ Trace 采样：固定节奏（每周）+ 固定抽样率，重点读两类样本——自动评分器打高分的（防"结果看似对但路径已偏离"的假阳性，阿里明确要求为此加过程型与风险型检查，轨迹评估细节详见第 E07 章 · 轨迹与 Agent 级评估）与用户反馈差的。
• ⑥ 高风险兜底：复核结论要留痕（复核人、依据、rubric 版本）进审计日志；"自动通过也要定期复核"要排期化，不能靠临时起意。

2.3 Judge 校准：人工评估的第一任务

为什么校准排在第一位？ 两句话足够：

• Airbnb：未校准的 judge 会制造误导性信心——分数看起来在涨，可能只是尺子变松了。
• DoorDash："LLM Judge only useful if it agrees with human reviewers." Judge 的全部合法性来自与人工判断的一致性。

Airbnb 的校准五步法（本章必须能默写的流程）：

1. 建 50–100 条 gold set，必须含坏样本——只有好样本的校准集测不出 judge 的误罚倾向；
2. 用 judge 跑该集合；
3. 看一致率，目标 high 80s ~ 90s%；分歧程度可用 Cohen's kappa / Krippendorff's alpha 度量；
4. 逐条检查分歧 → 改 rubric / 改 few-shot 示例 → 重复第 2 步；
5. 失败模式变化时重新校准——校准不是一次性动作。

实战案例（Airbnb 旅行平台客服政策问答助手）：PM/SME 标注 60 条 gold（含失败样本）；judge 初始一致率 78%（过低）——分歧分析发现 judge 误罚了正确的改述（语义正确但字面不同于参考答案的回答被扣分）；修 rubric 与示例后一致率达 88%；同期检索改进减少了 groundedness 失败。这个案例的价值在于展示校准循环的完整收益链：人工标注 → 暴露 judge 缺陷 → 修 rubric → judge 可信 → 规模化打分（该助手随后扩到 5,000 样本、每日抽 5% 去标识化生产流量）。

四家校准线对照（面试高频数字题）：

三家独立给出 85% 上下的阈值，可以视为行业经验收敛值。注意表述的严谨性：这是经验线不是统计定律——门槛的实质是"judge 与专家的分歧 ≤ 专家之间的分歧"（主手册第 8 章 · Agent 评估与可观测性 对这一判据有展开）。

分歧怎么分解：第 4 步的"检查分歧"不是逐条重标一遍，实用做法是先把分歧样本按方向分桶，再对症下药：

分桶的价值在于：前两类改的是 judge（rubric/示例），第三类改的是口径本身——修复路径完全不同，混在一起处理会反复返工。

校准的自动化：GEPA（DoorDash 实践）。人工校准的瓶颈是"改 rubric 靠人试"，DoorDash 把这一步交给了反射式 prompt 优化器 GEPA（arXiv 2507.19457，2025）：对候选 prompt 采样运行 → 用自然语言反思诊断失败 → 变异生成新 prompt → 按 Pareto 前沿在多个任务切片上保留候选（而非只看平均分）。落到 judge 校准上：GEPA 迭代提出 judge prompt 修订，只保留在留出集上提升与人工标注一致率的版本。这等于把"分析分歧 → 改 rubric → 重测"的人工循环部分自动化，人工退到"标注留出集 + 审计修订方向"的位置。GEPA 原论文报告其样本效率比 GRPO 强化学习高约 35 倍量级（详见第 E10 章 · 评测驱动开发）。

校准是持续运营，不是一次验收（阿里）：维护 Judge 金标校准集；每次 judge prompt/模型升级固定产出三类统计：

1. 与人工标注一致性（一致率，或多模型对抗 Kappa）；
2. 高风险样本漏判率（合规/资损/隐私——这类样本漏判一个的代价远超平均分波动）；
3. 边界样本稳定性（重复评测的波动幅度）。

何时触发重新校准？把三家的触发条件合并成一张清单：rubric 演进/新增能力（DoorDash）、失败模式变化（Airbnb）、judge prompt 或模型升级（阿里）。三者任一发生，旧校准结论作废。

动手实验：校准五步法 + 混淆矩阵 + κ 的完整实现见 labs。 cd evals-special/labs && python3 eval_lab05_judge_calibration.py 该 lab 复现了 Airbnb 案例：Judge v1 字面重叠式 rubric 误罚"正确的改述"（一致率 < 82%），修订 rubric 后 v2 ≥ 85%。

2.4 标注工程：指南、分歧与标注者间一致性

人工评估的可信度不取决于"专家多厉害"，而取决于标注工程的四个要素：指南、分歧处理、一致性度量、规模化路径。

（1）标注指南 / rubric 先于标注员。 Airbnb 的判断标准一针见血："如果人都无法一致地应用 rubric，模型也不可能。" 标注指南不是评分的辅助文档，而是整个评分体系（人工 + judge）的单一事实来源。DoorDash 进一步要求每条标准写成"从会话本身可验证"——同一条 rubric 既供人工校准使用，又供 judge 规模化使用（第 E05 章 · LLM-as-Judge 深入 对 rubric 工程有完整展开，含 Airbnb 房源 listing 语气 0/1 判定的完整实例）。rubric 写得好不好，有一个廉价的检验方法：让两个专家各自独立按指南标一批样本，看一致率——IAA 低首先是 rubric 的问题，不是人的问题。

（2）专家分歧处理：先停下，解决分歧再自动化。 Airbnb 的纪律是：专家有分歧就先停下解决分歧再自动化。这条纪律背后的逻辑：专家分歧通常不是随机噪声，而是口径未定义的信号——两个专家各自在用指南没覆盖的隐含标准。此时强行自动化（取多数、平均、或交给 judge），等于把未定义的口径固化成系统性偏差。正确流程是把分歧样本摆上桌 → 辩论出裁决 → 把裁决写回 rubric → 再标下一批。这个"分歧 → 口径"的转化过程，正是 2.7 反哺闭环在标注阶段的形态。

（3）标注者间一致性（IAA, Inter-Annotator Agreement）的度量。 Airbnb 校准流程中点名的两个指标：

IAA 有双重身份：它既是标注质量的度量，更是 rubric 质量的度量。IAA 低 → 先修 rubric 再谈换人、再谈自动化。同时，IAA 也给出了 judge 校准目标的天花板参照：judge 与人的目标一致率定在 high 80s ~ 90s 而非 100%，部分原因正是人与人之间也做不到 100%（详见易错点 10）。

κ 的手算示例（面试计算题高频形态）。设人工专家与 judge 对 100 条样本独立做 pass/fail 判定，混淆矩阵如下：

                人工：pass   人工：fail
Judge：pass        72           8
Judge：fail         6          14

• 观察一致率 P_o = (72+14)/100 = 86%；
• 期望机遇一致率 P_e = P(judge pass)×P(人工 pass) + P(judge fail)×P(人工 fail) = 0.80×0.78 + 0.20×0.22 = 0.668；
• Cohen's κ = (P_o − P_e) / (1 − P_e) = (0.86 − 0.668) / (1 − 0.668) ≈ 0.58。

解读这个反差：一致率 86% 看起来踩线达标，κ=0.58 却说明一致的大半来自"大多数样本本来就 pass"的基础率，judge 的真实判别力有限——单看 fail 行，人工判 fail 的 22 条里 judge 只抓到 14 条，漏判率约 36%。这正是分布偏斜场景的典型失真：一致率与 κ 讲的是两个故事，而真正致命的那个数字（坏样本漏判）两者都没直接回答。所以阿里的 judge 升级统计把高风险样本漏判率单列成项——校准报告里它必须与一致率并排出现。

（4）规模化路径：先小后大，先专家后队伍。 四家的起步规模惊人一致：

顺序不能颠倒：先用少量专家把 rubric 磨稳定，再扩队伍。提前规模化标注的后果是：一群标注员按一份含糊的指南生产大批量低质标签，返工成本远高于前期慢慢磨 rubric。

（5）gold set 必须含坏样本。 这是 Airbnb 十条要点之一。校准集的构成要刻意覆盖三类"陷阱样本"：

• 流畅的错误：语言漂亮但事实错误——测 judge 是否被流畅性迷惑；
• 正确的改述：语义正确但字面不同于参考答案——测 judge 是否过度依赖字面匹配（Airbnb 78%→88% 案例的病灶正是这里）；
• 边界样本：刚好踩在 rubric 判定线上的样本——它们决定 judge 的判定边界画在哪。

（6）隐私与合规。 Airbnb 明确：生产流量抽样送人工评审前必须去标识化，且用途限定于安全与质量。这不是可选项——任何把未脱敏生产会话直接丢给标注团队的流程，在合规审查处直接死亡（数据飞轮的合规红线详见第 E12 章 · 在线评估与数据飞轮）。

动手实验：gold set 的构造、入库标准检查与治理流水线见 labs。 cd evals-special/labs && python3 eval_lab02_golden_dataset.py

2.5 人工评分路由：不是「分数低」才配进人工

三层评分流水线真正的设计难点不在每一层怎么评，而在层与层之间怎么流转。阿里给出了完整的分层筛查架构：

粗筛层（低成本快速分流）          精判层（确认 badcase）          人工复核层（终判）
规则 Scorer + 轻量 Judge    →    完整规则 + Judge          →    高风险 / 低置信 /
明显通过 / 明显失败 / 存疑        产出：问题分类、问题现象、       冲突 / 口径未固化
                                  置信度、判定依据

关键设计：评分输出不止 pass/fail。精判层必须同时产出问题分类（现象层：如事实性错误/答非所问/过度承诺）、问题现象、置信度、判定依据——为下游 RCA 提供"现象入口"（第 E11 章 · Badcase 根因分析与优化闭环）。对路由而言，这四个字段里的置信度与判定依据（reason）是路由信号的直接来源：没有它们，下表的六类触发条件有一半无法实现。

人工评分路由的六类触发条件（阿里的核心贡献，也是本章的面试题眼）：

为什么"只看分数阈值"不够？ 这是路由设计最常见的简化，必须能说出它漏掉的三类信号：

1. 低分 ≠ 不确定。一个样本被规则高置信判 fail（如 JSON 损坏、禁用工具被调用），失败得明明白白，不需要人工——它需要的是修复，不是复核。反过来，一个 0.49 分的边界样本比一个 0.05 分的样本更值得人工看。
2. 分数捕捉不到"评分器自身的不确定性"。置信度、reason 质量、judge 间分歧，都是分数之外的元信号——它们度量的是"尺子可不可靠"，而不仅是"样本好不好"。
3. 分数捕捉不到"分布漂移"。新模型/新 prompt/新 schema 上线时，旧评分器可能整体失准但分数看起来正常——此时唯一可靠的策略是按抽样率主动送人工（阿里的"变更观察期"），用人工结论反过来校验评分器是否还有效。这与主动学习思路一致：阿里在样本治理中明确，新分布出现时优先抽取低置信/高影响/新意图/新工具/新知识点样本进人工确认。

路由逻辑可以直接写成代码：

def route_to_human(sample, rule_verdict, judge_verdicts, context) -> bool:
    # —— 第一类：不确定性信号 ——
    if is_borderline(rule_verdict.score, gate_threshold):       # ① 边界分
        return True
    if max_confidence(rule_verdict, judge_verdicts) < CONF_MIN: # ② 低置信
        return True
    if is_vague(judge_verdicts[0].reason):                      # ③ reason 含糊
        return True
    if len({v.verdict for v in judge_verdicts}) > 1:            # ④ 多 judge 分歧
        return True
    # —— 第二类：漂移信号 ——
    if context.recent_change and sampled(context.audit_rate):   # ⑤ 新模型/新prompt/
        return True                                             #    新schema/新活动抽样
    # —— 第三类：冲突信号 ——
    if rule_verdict.verdict != judge_verdicts[0].verdict:       # ⑥ 规则 vs Judge 冲突
        return True                                             #    人工终判 + 回收口径
    return False

用 5 条样本走一遍路由决策（判断每条命中哪类信号）：

注意样本 A 与 E 的对照：A 分数极低但无人工必要，E 分数很高且 reason 完整却必须进人工——路由的依据从来不是分数高低，而是信号的类别。

两个工程细节值得在面试中主动补充：

• 路由率本身要监控。送人工比例突然飙升，通常意味着评分器坏了或分布漂移了（与"0%/100% 异常"同理）；路由率长期为零，则可能是阈值设得太松，路由形同虚设。
• 线上抽样是路由的最大进料口。Airbnb 每日抽样 5% 去标识化生产流量，跑检查与 judge 后标记样本送人工，每周 PM 评审——在线评估与人工路由共用同一套打分口径（DoorDash 原则：离线与线上同一 rubric + 同一校准 judge，两边分数才可对齐；详见第 E12 章 · 在线评估与数据飞轮）。

动手实验：分层筛查（粗筛 → 精判）与路由的成本节省可量化复现。 cd evals-special/labs && python3 eval_lab03_programmatic_scorers.py

2.6 人机分工决策表：什么永远留给人

把前面各节的结论汇总成一张可直接用于系统设计的决策表：

从表中可以提炼出永远留给人的三类维度：

1. 政策口径——业务规则的定义权不属于任何自动评分器；
2. 价值判断——涉及取舍与排序的争议需要一个被授权的终判者；
3. 高风险——误判代价不可接受的场景，自动化只能做初筛，人做最终把关。

以及一条防止过度自动化的边界原则（阿里原文）："能自动稳定判断的不长期依赖人工"——注意它的双向性：既反对"人工全量打分"，也反对"人工永远把着不放"。分工的终局是人的有序撤退：今天人判的口径，明天变成规则或校准后的 judge；撤退的前提是自动化层通过了校准验收（一致率、高风险漏判率、边界稳定性）。腾讯表格中"人工评分器不进门禁，做采样审查"正是这种撤退后的稳态形态。

兜底裁决的升级路径（组织层配套）：分工表回答"谁评"，落地还要回答"评的人之间不一致怎么办"。可操作的三级升级链：标注员分歧 → SME 复审 → 指定的最终决策者裁决——Airbnb EDD 原则 4 要求明确指定这一个人，因为"好 vs 坏"的争议如果没有唯一终裁人，会在委员会里无限循环。每级裁决的结论都要带依据并写回 rubric，这就接上了 2.7 的反哺闭环。另有一个能批量消除"伪分歧"的机制值得借鉴：DoorDash 的 eligibility 适用性前置——judge 先判该标准是否适用本会话，不适用则跳过（如食谱流程不因缺复购步骤被扣分）。实践中相当一部分"judge 与人工分歧"其实是"这条标准本就不该评这个会话"，把适用性判断前置，这类分歧在源头就消失了。

2.7 人工结论反哺：一次人工判定要产出三份资产

人工判完不是终点。如果人工结论只用于"给这条样本一个分数"，那么下一条同类样本还得再花一次人工——人力成本线性增长，永远追不上样本量。阿里的反哺机制把人工结论导向三个去处：校准规则、校准 judge prompt、校准根因标签体系。

反哺路径一：规则层——口径回收。 路由条件⑥（规则与 judge 冲突）的人工终判，产出的不只是这条样本的 verdict，更是一条新口径。例如业务终判"拒收+运费险场景应走先退款后退货流程"，这条裁决应当被写成一条确定性规则（或 rubric 检查项）入库——下次同类样本由规则直接判定，不再消耗人工。这就是"回收口径"四个字的完整含义：人工判定把口径缺口补上，自动化层的能力边界向外推一格。

反哺路径二：Judge 层——校准集回流。 人工与 judge 的分歧样本是校准集最优质的增量来源（它们恰好落在 judge 的判定边界上）：分歧样本入金标校准集 → 分析分歧原因 → 修 rubric/few-shot/judge prompt → 重新跑校准五步法（2.3）；DoorDash 更进一步用 GEPA 自动搜索 judge prompt 修订、只保留提升留出集一致率的版本，并在 rubric 演进（新增能力）时收新标注、重新校准。

反哺路径三：根因层——标签体系。 人工复核结论反校准根因标签体系（第 E11 章 · Badcase 根因分析与优化闭环）：标签要稳定、可统计、指向 owner 与处理动作——运营可配置 / 算法需优化 / 工程需修复 / 业务需定口径。注意阿里强调"业务需定口径"本身就是一类根因：很多看似模型失败的问题，根因是业务规则从未被定义——这类问题的修复动作不是改 prompt，而是开一次业务评审会。

把反哺机制汇总成一张"资产转换表"——人工评估的每一类产出都应对应一个可复用的资产：

反哺的规模效应，用两个工业数字收尾：

Discord AITL 是人工评估反哺闭环的教科书样本：人工标注 → 评测集 → 再训练 → 上线 → 新标注，且专门量化了 offline 与 online 评测设置的一致性。它说明人工评估的产出不仅校准评分器，还能直接驱动模型迭代——人工不是成本中心，是评分系统的校准源、口径工厂与数据飞轮的进料口。

三、面试高频考点

四、经典面试题与参考答案

题 1（基础）：三层评分体系里，为什么人工不做日常全量打分？专家时间应该怎么分配？

参考答案： 三层评分的分工是"规则主判、Judge 辅助、人工兜底"（阿里），选择优先级为确定性 > Rubric > 人工（腾讯）。人工不做全量打分有三笔账：成本上人工是分钟-小时级/人力，规则毫秒级免费、judge 秒级；规模上生产流量是千会话/天量级（DoorDash 日均 2,000 个自动评分会话，人工全量回归要 6+ 小时、自动化后约 20 分钟）；杠杆上专家最稀缺的能力是"定义什么是好"，不是重复判断。因此腾讯给出经验法则：能自动化的坚决不找专家，专家时间 60%+ 花在"校准 LLM 评委"与"诊断异常"；DoorDash 同构：人工用在杠杆最大处——定 rubric、标注校准集、审计 judge 行为；Airbnb 则要求指定一个最终人类决策者裁决争议。人工的正确定位是评分系统的校准源与仲裁庭，不是流水线工人。

题 2（基础）：Agent 评测中哪些工作必须留给人工？请给出尽量完整的清单。

参考答案： 按腾讯六场景为主干：① 校准 LLM 评委（最核心，抽样 100–200 条对齐，一致率 ≥85% 才可用）；② 主观任务打分（语气、清晰度等 rubric 维度的人工抽样）；③ 诊断通过率异常（0%/100% 通常是任务或评分器坏了）；④ 建 Ground Truth（新套件前 20–50 个参考解，配合基线快照机制）；⑤ Trace 采样审查（每周固定抽样读轨迹找隐藏失败模式）；⑥ 高风险兜底（医疗/金融/安全 100% 人工复核）。再补两家：Airbnb 强调人工负责细微差别与创意、安全高风险决策、解决自动评估器间冲突；阿里强调新建评测集时"定口径"（如已发货+拒收+运费险场景走哪条流程需业务先定）与处理争议样本。归纳成三类不可让渡的维度：政策口径、价值判断、高风险——它们的答案依赖内部政策与业务取舍，不在任何模型的训练分布里。

题 3（进阶）：请完整描述校准一个 LLM Judge 的流程，给出量化标准，以及不达标时怎么办。

参考答案： 按 Airbnb 校准五步法：① 建 50–100 条 gold set，必须含坏样本——流畅的错误、正确的改述、边界样本三类陷阱样本要刻意覆盖；② 用 judge 跑该集合；③ 看一致率，目标 high 80s ~ 90s（腾讯口径 ≥85%、阿里 ~85% 后进日常自动化），分歧用 Cohen's κ / Krippendorff's α 度量；④ 逐条分析分歧 → 修 rubric 与 few-shot 示例 → 重跑；⑤ 失败模式变化、rubric 演进、judge prompt/模型升级时重新校准。不达标时的动作不是换 judge 模型，而是回到分歧样本：Airbnb 客服案例中初始一致率 78%，分歧分析定位到 judge 误罚正确的改述，修 rubric 与示例后达 88%。校准还应自动化提效：DoorDash 用 GEPA（arXiv 2507.19457）迭代生成 judge prompt 修订、只保留在留出集上提升人工一致率的版本。校准后进入持续运营：每次升级产出三项统计——与人工一致性、高风险样本漏判率、边界样本稳定性。

题 4（进阶）：两位专家标注同一校准集出现约 20% 的分歧。有人建议"取多数/平均，先往前推进"，你怎么看？

参考答案： 不能取平均往前推进，这是标注工程里最危险的捷径。Airbnb 的纪律是：专家有分歧就先停下解决分歧再自动化。理由是：专家分歧通常不是随机噪声，而是口径未定义的信号——两位专家各自在应用指南没覆盖的隐含标准；此时取多数或平均，等于把一份未定义的口径固化成训练/校准数据，judge 学到的将是系统性偏差，而且后续很难追溯。正确流程：① 把分歧样本摆上桌逐条辩论；② 裁决出唯一答案；③ 把裁决写回 rubric/标注指南——分歧处理过程就是口径固化过程；④ 用更新后的指南重新标注分歧样本验证一致性；⑤ 再进入后续批次。同时要区分：若分歧集中在某类场景，说明 rubric 对该场景欠定义，补指南；若分散且两位专家 IAA 持续偏低，才考虑标注员培训或换人——但第一步永远是先怀疑 rubric，因为"如果人都无法一致地应用 rubric，模型也不可能"（Airbnb）。

题 5（进阶）：你的评分流水线如何决定哪些样本最终送人工？为什么不能只看分数阈值？

参考答案： 用阿里的六类路由触发条件：① 边界分（得分落在门禁阈值灰区）；② 低置信（评分器输出的置信度低于阈值）；③ reason 含糊（judge 判定依据不可复核）；④ 多 judge 分歧；⑤ 新模型/新 Prompt/新工具 Schema/新活动上线的抽样观察；⑥ 规则与 judge 结论冲突 → 人工终判并回收口径。这些条件依托分层筛查架构：粗筛层（规则+轻量 judge 快速分流）→ 精判层（完整规则+judge，输出问题分类/现象/置信度/判定依据）→ 人工复核层。只看分数阈值会漏掉三类信号：其一，低分 ≠ 不确定——高置信的明确失败（JSON 损坏、禁用工具）需要的是修复不是复核，边界分反而更值得看；其二，置信度、reason 质量、judge 间分歧度量的是"尺子可不可靠"，是分数之外的元信号；其三，分数捕捉不到分布漂移——新版本上线时旧评分器可能整体失准而分数照常，必须按抽样率主动送人工，这也是主动学习"优先抽低置信/新意图/新工具样本"的落点。另外要监控路由率本身：飙升通常意味着评分器坏了或漂移了。

题 6（进阶）：某个评测套件的通过率从 70% 突然变成 0%（或 100%），你的第一反应和排查路径是什么？

参考答案： 第一反应不是"模型突然变弱/变强"，而是怀疑任务定义或评分器坏了——腾讯明确：0% 或 100% 通常是任务/评分器问题，不是模型能力问题；其稳定性调试经验也给出同构信号：0% pass^N 通常说明任务定义有问题。排查路径：① 查评测基础设施——用例输入是否被改坏、fixture/环境状态是否漂移、被测系统是否根本没跑通（超时、schema 变更导致全量解析失败）；② 查评分器——规则断言是否过严（如基线更新后旧快照失配）、judge 是否升级或 prompt 变动导致尺度漂移；③ 人工抽样：按"诊断 0%/100% 异常"场景，专家抽 10–20 条逐条读输入、输出与 trace，判断到底是系统性失败还是系统性误判；④ 用旧版本被评系统重跑同一套件做对照——若旧版本也变 0%/100%，锁定评分器或环境；若旧版本分数正常，才回到新版本变更本身。这正是人工六场景中"诊断异常"的价值：自动评分器无法给自己做体检，体检必须靠人。

题 7（进阶）：Judge 模型要升级到"更强"的新版本，能直接换吗？需要走什么验证流程？

参考答案： 不能直接换——"更强"是通用能力判断，不是"在你的 rubric 上判得更准"的证明；未经验证替换 judge 等于悄悄换了一把尺子，历史分数全部失去可比性。验证流程按阿里的 judge 持续运营口径：维护一份 judge 金标校准集（含坏样本与边界样本），对新版 judge 固定产出三项统计——① 与人工标注一致性（一致率或多模型对抗 Kappa），对照 ≥85% 的经验线；② 高风险样本漏判率（合规/资损/隐私），这是新版本最容易悄悄恶化的地方，平均分涨而高风险漏判升是典型的"尺子变松"；③ 边界样本稳定性（同一批边界样本重复评测的波动）。同时做新旧桥接：同一批历史样本用新旧 judge 各跑一遍，量化分数漂移幅度，趋势图标注版本断点（主手册第 8 章 · Agent 评估与可观测性 对"judge 版本化与历史数据桥接"有展开）。若新 judge 在分歧样本上的判定理由与旧版系统性不同，还要回到 rubric 层确认是 judge 变了还是口径该变。DoorDash 的实践可作补充：judge prompt 的打磨本身可用 GEPA 类优化器在留出集上自动迭代，但"是否采纳修订"的验收标准始终是与人工标注的一致率。

题 8（系统设计）：你们要为一个客服 Agent 搭建评分体系，团队只有一位领域专家（SME）和一位标注员。请设计人机分工方案：如何起步、如何校准、如何路由、如何反哺。

参考答案： 总体原则：把 SME 的时间当最稀缺资源预算——60%+ 花在校准 judge 与诊断异常，坚决不做日常全量打分（腾讯经验法则）。分四阶段： ① 起步（定口径 + 建锚）：SME 牵头写 rubric，要求"每条标准从会话本身可验证"（DoorDash），业务口径类问题（退款政策组合、补偿规则）由 SME 直接定标准；标注员配合产出 20–50 个参考解（腾讯）与 50–100 条 gold set，刻意包含坏样本：流畅的错误、正确的改述、边界样本（Airbnb）。 ② 校准：judge 跑 gold set，目标一致率 ≥85%（腾讯/阿里口径）；分歧样本由 SME 逐条裁决并写回 rubric——"专家有分歧先停下解决再自动化"（Airbnb）；标注员负责按更新后的指南重标分歧批，报 Cohen's κ 监控一致性；预算允许时可用 GEPA 类方法自动搜索 judge prompt 修订。 ③ 路由：分层筛查——粗筛规则分流 → 精判层输出问题分类/现象/置信度/判定依据 → 六类条件路由人工（边界分/低置信/reason 含糊/多 judge 分歧/新版本抽样/规则-judge 冲突）；线上每日抽 5% 去标识化流量跑 judge、标记样本进人工队列（Airbnb）；医疗/资金/合规类场景 100% 人工复核（腾讯）。 ④ 反哺：人工终判的口径固化为新规则；分歧样本回流校准集；根因标签按"运营可配置/算法需优化/工程需修复/业务需定口径"归类（阿里）；每周 SME 评审会看失败主题与路由率趋势（Airbnb 每周 PM 评审）。隐私红线贯穿全程：人工评审前去标识化、用途限定于安全与质量。

题 9（进阶）：给定人工与 judge 的混淆矩阵，你如何量化人机一致性？为什么只看一致率会误事？

参考答案： 先算观察一致率 P_o（混淆矩阵对角线占比），再算 Cohen's κ = (P_o − P_e)/(1 − P_e)，其中 P_e 是按双方各自的边际分布算出的"机遇一致率"——κ 扣除了"瞎猜也能对上"的部分，度量的是真实判别力。举例：100 条样本，对角线为 72/14，P_o = 86%，P_e = 0.80×0.78 + 0.20×0.22 ≈ 0.67，κ ≈ 0.58——一致率看似达到 85% 线，κ 却揭示一致多半来自"大多数样本本来就 pass"的基础率。pass/fail 判定的分布天然偏斜，一致率会系统性高估 judge 质量：上例中人工判 fail 的 22 条里 judge 只抓到 14 条，漏判率约 36%。这就是阿里把高风险样本漏判率单列为 judge 升级统计项的原因——合规/资损/隐私类样本漏一个的代价远超平均分波动。工程结论：一致率、κ、坏样本/高风险召回要并排报告；多标注员或非二值任务用 Krippendorff's α。

题 10（系统设计）：为一个涉及资金操作的高风险 Agent（退款/赔付）设计人工评估的运营方案。

参考答案： 按四条线设计：① 进料线：赔付/资损/隐私/合规/投诉升级类样本无条件进人工队列，与自动评分结果无关——阿里的口径是"自动通过的也要定期人工复核"；路由六条件中此类样本叠加"高风险"权重优先处理。② 裁决线：双人复核制（初审 + 复审），结论带依据、rubric 版本与会话 ID 留痕进审计日志；分歧按"标注员 → SME → 指定终判者"升级（Airbnb EDD 原则 4 要求明确唯一终判人）；裁决结论写回业务口径与 rubric。③ 校准线：高风险场景全部作为对抗样本纳入 judge 金标校准集；judge 每次升级单独报告"高风险样本漏判率"，该指标一票否决——平均一致率达标但高风险漏判恶化即阻断放量。④ 闭环线：确认的高风险 badcase 只增不减进回归集；根因标签绑定 owner（运营可配置/算法需优化/工程需修复/业务需定口径）；稳定性按关键决策类口径——腾讯对关键决策类容忍阈值为 0%（N 次全过，一次失败都可能误判），发布门禁用连续成功率（pass^k）而非至少一次成功率。贯穿四线的原则：高风险场景自动化只做筛查、人做终判，且每次终判都要可审计、可复用。

五、易错点 · 反直觉点

1. 误区：专家越多，评测越可靠。 真相：人力堆在日常打分上是负杠杆——成本分钟-小时级、扩展性差，而且专家被消耗在重复劳动上就没空做校准与诊断；腾讯的口径是专家时间 60%+ 必须花在"校准 LLM 评委"与"诊断异常"。记忆锚点：专家是校准砝码，不是流水线。
2. 误区：分数低于阈值的样本送人工复核就够了。 真相：低分 ≠ 不确定——高置信的明确失败不需要人工；路由要看的是不确定性信号（边界分/低置信/reason 含糊/多 judge 分歧）、漂移信号（新版本抽样）与冲突信号（规则 vs judge），阿里明确"不由分数阈值单独决定"。记忆锚点：路由看的是"尺子可疑"，不是"分数难看"。
3. 误区：专家意见不一致就投票取多数，先推进进度。 真相：分歧通常是口径未定义的信号，取多数会把未定义的口径固化成系统性偏差；Airbnb 的纪律是先停下解决分歧再自动化，裁决结果要写回 rubric。记忆锚点：分歧不是噪声，是口径缺口。
4. 误区：校准集里放满"标准好答案"就够了。 真相：gold set 必须含坏样本（Airbnb 十条要点之一）——没有"流畅的错误"测不出 judge 被流畅性迷惑，没有"正确的改述"测不出 judge 误罚同义改写（78%→88% 案例的病灶正在于此）。记忆锚点：没有坏样本的 gold set，校不出尺子的偏差。
5. 误区：通过率 0% 说明模型太弱，100% 说明评测太简单。 真相：0% 或 100% 通常是任务定义或评分器坏了（腾讯六场景之三）；0% pass^N 的调试技巧是先查任务定义，不是先怀疑能力。记忆锚点：全军覆没先查尺子，再查选手。
6. 误区：judge 是强模型就能直接上岗，校准是走形式。 真相：未校准的 judge 制造误导性信心（Airbnb），"LLM Judge only useful if it agrees with human reviewers"（DoorDash）；一致率不达 85% 上下就放量，等于拿一把没校准的尺子做发布决策。记忆锚点：先校尺，再量货。
7. 误区：人工判定完、分数入库，这条样本就关闭了。 真相：人工结论必须反哺三处——口径固化为规则（下次同类不再耗人工）、分歧样本回流校准集修 judge prompt、结论反校准根因标签体系（阿里）；判完不反哺，人力成本永远线性增长。记忆锚点：一次人工判定，要产出三份资产。
8. 误区：把生产会话直接导给标注团队评审，效率高。 真相：生产流量送人工前必须去标识化，且用途限定于安全与质量（Airbnb 隐私注记）——未脱敏的人工评审流程在合规审查处直接出局。记忆锚点：不脱敏，不评审。
9. 误区：judge/rubric 升级后，旧校准结论继续有效。 真相：rubric 演进、judge prompt/模型升级、失败模式变化，任一发生都要重新校准（DoorDash/Airbnb），且升级要固定产出三项统计：与人工一致性、高风险漏判率、边界稳定性（阿里）。记忆锚点：尺子一换，先重新校尺。
10. 误区：一致率要追求 100%，85% 是妥协。 真相：人与人之间也做不到 100% 一致——校准目标的实质是"judge 与专家的分歧 ≤ 专家之间的分歧"；盲目追 100% 会过拟合到个别专家的口味，或把 rubric 改成无法泛化的特例清单。记忆锚点：校准的天花板是 IAA，不是完美。

六、推荐资源

论文

1. GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning（arXiv 2507.19457，2025-07）——DoorDash 用于 judge 校准的反射式 prompt 优化器：采样运行 → 自然语言反思 → 变异 prompt → Pareto 前沿按切片保留候选；本章 2.3 的"自动化校准"即此工程化应用。
2. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena（arXiv 2306.05685，2023-06）——judge 与人类一致率（80%+）及 judge 偏差清单的奠基文献；理解"为什么 judge 需要人工校准"的历史起点。
3. Agent-in-the-Loop: A Data Flywheel for Continuous Improvement in LLM-based Customer Support（Discord，EMNLP 2025 工业赛道，ACL Anthology 2025.emnlp-industry.135）——四类人工在线标注持续回流、再训练周期月级→周级的完整数据飞轮样本；人工评估反哺闭环（2.7）的学术侧对照。

工程博客

1. Airbnb《Eval-driven development: Lessons from evaluating GenAI at scale》——人工评估四用途、20–100 样本起步、专家分歧纪律、校准五步法与 78%→88% 实战案例的原始出处。
2. DoorDash《Building Ask DoorDash (Part 3): Evaluation》（2026-06-30）——"人工用在杠杆最大处"、GEPA 校准、"同一 rubric 既供人工校准又供 judge 规模化"的出处；配合同系列《A Simulation and Evaluation Flywheel to Develop LLM Chatbots at Scale》（2026-01）读：judge 用人工标注样本校准到与专家一致后才放量。
3. 阿里技术《Agent 评测：方法论与体系设计》——人工评分路由（六类触发条件）、分层筛查三层架构、评分输出规范、judge 升级三项统计、根因标签四 owner 的出处，本章 2.5–2.7 的主力素材。
4. 腾讯技术工程《AI Agent & Skill 测评方案及落地实践》——三类评分器对照表、人工六个必要场景、"专家时间 60%+"经验法则、0%/100% 异常诊断的出处。
5. Anthropic《Demystifying evals for AI agents》（2026-01）——"起步只需 20–50 个真实用例"、打分三层（确定性代码检查 > 模型 rubric > 人工校准）的官方表述。

本特辑交叉引用

• 第 E04 章 · 评分三层之一：程序化评分——规则层的检查清单与评分输出规范（本章路由信号的来源）。
• 第 E05 章 · 评分三层之二：LLM-as-Judge 深入——rubric 工程与 judge 偏差全景（本章校准对象的构造细节）。
• 第 E10 章 · 评测驱动开发（EDD）——"100 样本人工精读法"与 Airbnb 完整案例演练。
• 第 E11 章 · Badcase 根因分析与优化闭环——人工结论反哺的根因标签体系（"人审兜底"的下游）。
• 第 E12 章 · 在线评估与数据飞轮——线上抽样送人工、离线-线上同一 judge 口径、反馈生产线。
• 主手册第 8 章 · Agent 评估与可观测性——人机协同（HITL/HOTL）与 judge 校准的概览版。

动手 labs

轨迹与 Agent 级评估

一句话导读：只看"最终答案对不对"的评估，会系统性放过 Agent 最危险的失败——结果碰巧对、路径已经错。本章讲透过程级评估的完整工程：为什么 outcome-only 有四个盲区、Airbnb 三层模型（step/trajectory/session）与阿里四层评判（Turn/Session/Trace/Outcome）如何分工、结构化 Trace 为什么是被测 Agent 的标准能力而非事后补救、DoorDash 的 Transcript Builder 如何把原始 trace 塑形为 judge 能用的证据切片、腾讯 LCS 序列比对怎么做归一化与扣分、评测如何镜像多智能体运行时架构，以及 2024–2026 前沿（PRM、progress rate、Agent-as-a-Judge、元评估）如何落到工程。学完本章，你能设计一套"结果 + 过程"双门槛的 Agent 级评估体系，并回答面试中最常被追问的那句："你怎么知道 Agent 不是碰巧答对的？"

一、知识图谱

轨迹与 Agent 级评估（评什么形态：过程 > 单一结果）
│
├── 为什么只看最终答案不够
│   ├── 假阳性：结果对但路径错 / 带风险 ——「生产迟早暴露」（阿里）
│   ├── 一次请求 = 搜索 × 推理 × 外部动作 × 文本生成，每环节可独立失败（Airbnb）
│   ├── 三个致命缺陷：诊断盲区（20 步轨迹错在第 3 步无法定位）
│   │                奖励稀疏（终局标量无法归因）/ 捷径与欺骗（reward hacking）
│   └── 双向背离：过程对但结果败（环境抖动）⇄ 结果对但过程违规（跳过校验）
│
├── 分层评估模型
│   ├── Airbnb 三层：step（单工具调用/推理步）→ trajectory（路径合理高效）
│   │               → session（整体达成用户目标）
│   ├── 阿里四层：Turn（单轮）/ Session（整段会话）/ Trace（执行轨迹）/ Outcome（最终结果）
│   │   └── 「每轮都答得还行，但最终没解决问题，仍是失败」——不要只平均每轮分数
│   └── 每层失败 → 指向不同根因：单工具实现 / 规划编排 / 目标理解
│
├── Trace 基础设施（前提）
│   ├── 立场：Trace 是被测 Agent 的标准能力，不是事后补救（阿里/腾讯）
│   ├── 打点：OpenTelemetry；span 记录用户输入/模型输出/工具调用与返回/widgets（DoorDash）
│   ├── 存储：ClickHouse（DoorDash）；span 层级 session→agent/task→llm_call→tool_call
│   ├── 结构化三要求：可解析 / 内容完整 / 跨版本格式稳定（腾讯）
│   └── 标准演进：OTel GenAI semconv 仍 Development；2025-08 agentic 提案；2025-12 Datadog 支持
│
├── 把 trace 变成可判证据（DoorDash Transcript Builder）
│   ├── 原始 trace 三大难判：工具返回巨大 / schema 脚手架噪声 / 证据散落多 span
│   ├── 三动作：重组分散 span · 删无信号 token · 裁超大载荷
│   └── 每条标准声明依赖证据，judge 只拿那一片（grounding=论断+工具输出；
│       多样性=推荐+原始请求；叙述=流式文本）→ 聚焦让判断更一致
│
├── 轨迹比对技术（腾讯 LCS 实现）
│   ├── 禁 exact match：路径多样，合法替代路径不该被判错
│   ├── 归一化五规则：时间戳占位 / 搜索忽略查询参数 / 写入只留路径
│   │               / 终端命令提取脚本名 / 连续读文件组内不校验顺序
│   ├── LCS 对齐 → 四类偏差：缺少 / 多余 / 不一致 / 顺序错，各扣 2 分上限 -10
│   └── 效率对比：耗时/token 以基线为基准每超 10% 扣 1；基线=人工确认过的执行快照
│
├── 评测镜像运行时架构（DoorDash 多智能体）
│   └── Orchestrator 评路由 / 护栏贯穿全流程评 / 领域 Agent 评任务能力
│
├── 前沿：过程奖励与信用分配（2023–2026）
│   ├── PRM800K → Math-Shepherd（MC rollout）→ OmegaPRM（二分 O(log n)）
│   ├── GenRM（生成式批注验证）/ VinePPO（重采样无偏归因）/ PRIME（隐式奖励）
│   ├── Qwen Lessons：PRM 可被 hack、难度外推差 → 红队 + OOD 分层校准
│   └── Agent 侧：AgentBoard progress rate / τ-bench 终态 diff + pass^k
│       / Agent-as-a-Judge（带工具核验，时间 -97.72%/成本 -97.64%）/ AgentRewardBench（元评估，FPR>50%）
│
└── 落地原则：执行式验证为主、judge 为辅、人工抽检校准；
    评估器上线前先测 FPR/FNR；「结果正确 + 规则合规」双门槛

本章在特辑中的位置：评分三层（E04 程序化 / E05 Judge / E06 人工）回答"拿什么评"，本章回答"评什么形态"——当被测对象从"一次输出"变成"一条轨迹"时，评估的输入（trace）、判据（三层 + 双门槛）、工具（对齐算法、Transcript Builder、PRM）全部要升级。与第 E08 章（对话与仿真评测）的分工：本章讲轨迹本身怎么评，E08 讲"轨迹从哪来"（模拟器 + fixtures）；与第 E11 章的分工：本章的三层分数是 RCA 范围收敛的输入。

二、核心概念精讲

2.1 为什么只看最终答案不够：四个盲区与"假阳性"

阿里对这件事的表述最直接："有些样本最终答案看似对，但执行路径已偏离或带风险——这类假阳性在生产迟早暴露。" 腾讯痛点表里也有同款一条："过程易忽略——答案碰巧对但推理路径错，分不清'正确调用工具后回答'与'训练数据碰巧答对'"。Airbnb 则从请求结构给出根因：一次 Agent 请求可能同时包含搜索、推理、外部动作、文本生成，每个环节都可能独立失败，而最终文本把所有中间失败都"抹平"了。

先看一次请求的内部结构——Airbnb 所说"每个环节可独立失败"的解剖图：

一次客服 Agent 请求（五个环节，任何一个可独立失败）
用户："帮我退掉昨天买的订单"
   │
   ├─ ① 意图识别    ── 可能把「退货」识别成「物流查询」
   ├─ ② 检索        ── 可能召回错误的退款政策文档
   ├─ ③ 推理与规划  ── 可能漏掉「先查订单状态」这一步
   ├─ ④ 工具调用    ── 可能把 order_id 参数传错、或压根没调用
   └─ ⑤ 回复生成    ── 可能编造「一定退款成功」的过度承诺
   │
   ▼
最终回复："好的，已为您提交退款，请留意到账。"
   └── 只读这一句话，①~⑤ 的失败全部不可见

只看最终答案（outcome-only）的评估有四个盲区：

把阿里那个退款案例展开成 trace 视角，假阳性的结构一目了然：

期望轨迹：verify_identity → get_order_status → (可退?) → apply_refund → notify_user
实际轨迹：verify_identity → [get_order_status 缺失] → 直接生成「已退款」回复
outcome 评分：回复礼貌、格式正确、包含订单号 → 满分 ✗
trajectory 评分：关键校验工具未调用 → 硬门禁拦截 ✓

一个贯穿全章的真实案例（阿里 badcase 库）：用户咨询"已发货的订单怎么退款"，Agent 没有调用订单状态查询工具，直接按"未发货退款"流程回复并承诺退款成功——最终回复看起来礼貌、完整、格式正确，outcome 评分拿满分；但路径上关键校验工具未调用，且承诺了政策不允许的"一定退款成功"。这类样本在离线评测集里以"通过"存在，直到线上产生投诉才被回流（详见第 E11 章 · Badcase 根因分析与优化闭环）。阿里的结论：对这类 case 必须加过程型与风险型检查。

还要注意双向背离：过程全对但终局失败（环境抖动、最后一步失误）与终局成功但过程违规，是两个方向的反例。工业界（如客服 Agent）因此普遍采用"终态正确 + 规则合规双门槛"，而不是二选一。学界的过程奖励模型（PRM）研究更关注前一个方向，这也是学术指标直接搬进生产会水土不服的原因之一。

动手验证：cd evals-special/labs && python3 eval_lab06_trajectory_eval.py。lab 构造了四类运行（完全正确 / 结果对但路径错 / 路径对但结果错 / 全错），断言 outcome-only 评分必然放过"结果对但路径错"的假阳性样本，而三层评估 + 硬门禁能把它拦下来。

2.2 三层评估模型：step / trajectory / session（Airbnb）与四层评判（阿里）

Airbnb 的 Agentic 评估框架把评估对象切成三层：

三层各自独立失败，任何一层都不能代替另外两层：session 分高掩盖不了 trajectory 违规（假阳性），trajectory 完美也救不了 session 失败（白跑一趟）。这与 2.1 的双向背离一一对应。

阿里面向对话 Agent 给出同构但更细的四层：Turn（单轮）/ Session（整段会话）/ Trace（执行轨迹）/ Outcome（最终结果），并特别警告一个对话场景特有的陷阱：不要只平均每轮分数——"每轮都答得还行，但最终没解决问题，仍是失败"。举个例子：一段 8 轮的退款客服会话，每轮都礼貌响应、有问必答（turn 平均分 4+/5），但全程没有调用过一次退款工具，用户最后一句还是"钱还没到"——turn 均值很漂亮，outcome 层却是彻底失败。四层必须同时看，而不是取平均。四层与 Airbnb 三层的对应关系：

多智能体系统下还有一个工程要点（Airbnb）：Agent 通常在 root 下发 trace 和 span，评估侧可以通过树遍历重建 trace，校验 subagent 调用与工具使用——即轨迹结构本身（谁调用了谁、嵌套是否正确）也是评估对象。第 E08 章会展开多 Agent 场景的模拟器设计，主手册第 8 章则从 DAG 视角讨论了 handoff 评估，本章聚焦"轨迹怎么判分"。

2.3 Trace 先行：结构化 Trace 是被测 Agent 的标准能力

轨迹评估的输入是 trace。阿里与腾讯不约而同把这件事提到原则高度："Trace 输出是被测 Agent 的标准能力，而非事后补救"（阿里）；"设计阶段就把结构化 Trace 作为标准能力，而非事后补救"（腾讯）。理由很朴素：三层评估器全部消费 trace——step 层逐个 span 校验、trajectory 层抽取调用序列、session 层读取最终回复与终态；没有结构化 trace，过程评估整体不存在。

（1）span 里记什么。 DoorDash 的 Ask DoorDash 用 OpenTelemetry 打点，trace 存进内部 ClickHouse；span 记录四类内容：用户输入、模型输出、工具调用与返回、展示给用户的 widgets。阿里的要求更细：稳定记录工具名、入参、返回值、时间戳、耗时、错误；复杂 Agent 还要记录计划、检索、Guardrail 判定。腾讯把"内容完整"具体到"每步工具名/入参/返回/时间戳，理想含思维链与决策依据"。

（2）结构化三要求（腾讯）：

被测系统不满足时的三档对策（腾讯）：有日志无结构 → 写解析器（下策）；仅最终输出 → 只能做结果评测（中策）；可改造 → 推动被测系统增加 Trace 输出（推荐）。

满足三要求的最小 trace 长这样（字段对应：腾讯"每步工具名/入参/返回/时间戳" + DoorDash 四类 span 内容）：

{
  "session_id": "sess_20260805_0001",
  "agent_version": "refund-agent-v1.8",
  "spans": [
    {"span_id": "s1", "type": "user_message",
     "content": "帮我退掉订单 #1234", "ts": "10:00:00.000"},
    {"span_id": "s2", "parent": "s1", "type": "tool_call",
     "name": "get_order_status", "params": {"order_id": "1234"},
     "ts": "10:00:01.210", "duration_ms": 180},
    {"span_id": "s3", "parent": "s2", "type": "tool_result",
     "result": {"status": "shipped", "refundable": false}, "ts": "10:00:01.390"},
    {"span_id": "s4", "parent": "s1", "type": "llm_call", "model": "model-x-v2",
     "input_tokens": 1840, "output_tokens": 96, "duration_ms": 920},
    {"span_id": "s5", "parent": "s1", "type": "assistant_message",
     "content": "该订单已发货，暂不支持直接退款……", "ts": "10:00:02.400"}
  ]
}

注意两点：agent_version 这类元数据是跨版本可比性的前提（分数差异归因）；多智能体场景再加 parent_agent/subagent 调用边，Airbnb 正是靠树遍历重建 trace 并校验 subagent 调用。span 层级的推荐设计是 session → agent/task → llm_call → tool_call，为 OTel agentic conventions 留位置。

（3）标准化进展。 行业侧的收敛方向是 OpenTelemetry GenAI semantic conventions（gen_ai.* 属性命名空间）。按时间线（据调研整理）：2024 年各家私有 schema 混战（Traceloop OpenLLMetry、Arize OpenInference 等）→ 2025-01 OpenLLMetry 语义约定并入 OTel → 2025-03 OTel 官方博客发布 AI agent 可观测性标准路线图 → 2025-08 提出 agentic systems 语义约定提案（agent/task/chain/tool 层级 span 属性） → 2025-12 Datadog 等厂商宣布原生支持 OTel GenAI semconv（v1.37+）。注意：截至 2026 年中，GenAI 语义约定仍处于 Development（开发中） 稳定性；部分 agent/tool 属性（如 gen_ai.agent.id）已进入属性 registry，但完整的 agentic span 约定仍在提案推进中、命名可能变（与主手册第 8 章口径一致）——工程上的务实做法是第一天就按 gen_ai.* 属性打点、同时保留私有字段兼容层，span 层级按 session → agent/task → llm_call → tool_call 设计，为 agentic conventions 留位置。核心属性速查：

（4）trace 的复利。 trace schema 稳定之后会产生三重回报：生产 trace 是免费的评测集来源（脱敏后可直接转回放用例）、失败聚类有了统一字段（详见第 E12 章 · 在线评估与数据飞轮）、自动诊断有了输入（2.8 节的 TRAIL/AgentDebug 都以 trace 为输入）。阿里把评测执行环境隔离也列为配套要求——多用例共享状态会导致分数不可复现，这与 trace 完整性同属"评估前置条件"。

2.4 Transcript Builder：把原始 Trace 塑形为"证据切片"（DoorDash）

有了 trace 不等于能判分。DoorDash 的原话：原始 trace 完整但难判，具体三难：

1. 工具返回可能巨大——一次餐厅搜索 API 返回上百条记录，judge 的上下文窗口装不下，装得下也会被淹没；
2. schema 脚手架与无信号字段多——内部协议字段、调试标记占了大量 token，对判定毫无贡献；
3. 证据散落多个 span/turn——判断"推荐是否有据"需要把第 2 轮的论断和第 5 轮的工具返回拼在一起。

解法是 Transcript Builder：一组 Python 脚本，做三个动作——重组分散的 span、删除无质量信号的 token、裁剪超大载荷，产出紧凑视图。关键设计在下一步：每条 rubric 标准声明自己依赖的证据，builder 只把那一片交给 judge。原文给出三个实例：

塑形前后对比（示意，字段取自 DoorDash 原文描述）：

【judge 前：原始 trace 片段】
tool_result(search_restaurants):
  {meta: {request_id:"...", schema_v:"3.1", debug:{...数百字...}},
   results: [{name:"A", price:..., rating:..., eta:..., promotions:[...],
              tracking:{...}}, ... 共 137 条 ...]}      ← 数万 token，大量无信号字段
assistant(span #12): "A 川菜馆离您很近，30 分钟可达"      ← 待核验的论断
...（中间隔 7 个 turn 的其他 span）...

【judge 后：grounding 证据切片】
assertion: "A 川菜馆离您很近，30 分钟可达"
evidence:  search_restaurants.results[0] → {name:"A 川菜馆", distance_km:0.8, eta_min:30}
verdict: ____   rationale: ____

效果是"聚焦证据让判断更一致"——这与第 E05 章的 judge 校准逻辑同构：给 judge 的无关上下文越多，偏差与方差越大。DoorDash 把它列为四条 Lessons Learned 的第一条："Judge 需要'为问题塑形'的 transcript 视图——删无关、只留标准依赖的证据。"

工程上可以这样理解：Transcript Builder 是"评测侧的 ETL"。它把一份完整的原始 trace（存 ClickHouse 的那份）物化成 N 个按标准定制的视图；原始 trace 保留用于人工复核与 RCA，视图只服务自动评分。这带来一个附带好处——judge 误判时，人审可以回到原始 trace 查证，评分与证据链永远可追溯。实现时的两个注意点：裁剪规则要版本化（裁过头会把关键证据切掉，属于"评测系统自己产生的 bug"，DoorDash Lesson 4 明确说被标记失败中有真实一部分是 harness 自身故障）；每条标准的证据声明应与 rubric 一起 review，二者是同一个契约的两半。

2.5 轨迹比对与 LCS 序列对齐：腾讯实现

trajectory-level 的核心动作是"把这条轨迹和预期路径比一比"。最直觉的做法是 exact match（完全一致才通过），但它是轨迹评估的头号反模式：同一任务存在多条合法路径（先查订单还是先验身份？），exact match 会把大量正确行为判错，评估集退化成"背答案"。可用的比对粒度由严到宽：

腾讯 TPerf（AI 性能分析 Agent）给出目前公开细节最完整的 LCS 实现。完整流水线分四步：

第一步：归一化。 对齐之前先把"不影响对错的差异"抹掉，否则同一行为每次运行都会被判"不一致"。五条规则：

第二步：LCS 对齐。 对归一化后的基线序列与 trial 序列求最长公共子序列（LCS），LCS 即两者的"公共骨架"，代表被正确执行的部分。

第三步：偏差分类扣分。 没进入 LCS 的 span 分成四类：不一致 / 多余 / 缺少 / 顺序错，各扣 2 分，本维度上限 -10。"缺少"里最严重的子类是"缺少关键校验步骤"——在综合判定中它不应只扣 2 分，而应触发硬门禁（见 2.8 与 lab06）。

第四步：效率对比。 过程质量不只看"走对没有"，还看"走贵没有"：耗时以 300 秒为基准，每超 10% 扣 1 分；token 以基线为基准每超 10% 扣 1 分，上限 -10。这与腾讯五维指标中"效率与成本"一脉相承——"pass@1 高但 token 花 10 倍的方案生产上不可接受"。

用一个最小例子走一遍对齐（lab06 中的场景）：

基线 SOP：[verify_identity, get_order_status, apply_refund, notify_user]

Trial A：[verify_identity, apply_refund, get_order_status, notify_user]
  LCS 公共骨架（长度 3）：[verify_identity, get_order_status, notify_user]
  偏差分类：apply_refund 与 get_order_status 顺序错（-2）
  ——违反「先查状态、再办退款」的 SOP，但两步都在 → 扣分即可

Trial B：[verify_identity, apply_refund, notify_user]
  LCS 公共骨架（长度 3）：[verify_identity, apply_refund, notify_user]
  偏差分类：get_order_status 缺少
  ——缺少的是关键校验工具 → 不走扣分，直接触发硬门禁判失败（假阳性）

对应的判定骨架（示意）：

def trajectory_score(trial_spans, baseline_spans):
    t = [normalize(s) for s in trial_spans]     # 五规则归一化
    b = [normalize(s) for s in baseline_spans]
    lcs = longest_common_subsequence(b, t)      # 公共骨架
    for span in classify_unmatched(b, t, lcs):  # 缺少/多余/不一致/顺序错
        if span.kind == "missing" and span.critical:
            return HARD_GATE_FAIL               # 关键校验缺失：一票否决
        deduct(2, cap=-10)
    deduct_efficiency(duration_vs=300, token_vs=baseline, per_10pct=1, cap=-10)
    return max(0, 100 + total_deductions)       # ≥80 达标（腾讯口径）

配套的基线快照机制（腾讯）：用例设计只定义 prompt 与检查规则 → 执行 1 次 → 人工审核过程与结果 → 不可接受则修后重跑 → 可接受则该次快照成为基线（含 CoT、工具调用序列、中间产物、完整 trace、最终响应）。基线更新时机只有三个：Agent/Skill 逻辑变更、模型版本升级、用例本身修改。TPerf 实战规模：9 大场景分组 30+ 用例（CPU 瓶颈 6 / 网卡 5 / 磁盘 4 / 磁盘 IO 2 / 内存 1 / TCP 队列 3 / Nginx 1 / 配置问题 1 / 正常场景 5），支持 7 模型参数化对比，单用例约 3000 秒，全量 30+ × 7 模型约 3–5 小时；基线配置随代码仓库 Git 版本化，执行结果每次重新生成归档，且支持"重新评分"（评分逻辑调整后无需重跑 Agent）。

动手验证：lab06 实现了归一化 + LCS 对齐 + 四类扣分的完整可运行版本，并断言"假阳性样本 outcome 分高但 trajectory 分低 → 综合判定失败"。运行：cd evals-special/labs && python3 eval_lab06_trajectory_eval.py。

2.6 评测镜像运行时架构：多智能体系统怎么切评估责任（DoorDash）

当被测系统本身是多智能体架构，评估体系应该与运行时架构同形，否则失败无法归因到 owner。DoorDash Ask DoorDash 的运行时：用户消息 → Orchestrator（路由层）→ 分发到领域 Agent（如 Restaurant Discovery Agent、Grocery Shopping Agent）→ 领域 Agent 直接处理或交还 Orchestrator。评测按同一结构切分：

这个同形设计回答了多智能体评估最容易扯皮的问题："端到端分数掉了，是谁的锅？"——路由错误记 Orchestrator，领域任务失败记领域 Agent，护栏违规则跨 Agent 追。DoorDash 的 rubric 工程还有两个与轨迹评估直接相关的细节（rubric 工程本身详见第 E05 章）：

• 每条标准是 binary check，汇总为会话级总分——二值判定比连续打分稳定，轨迹级证据交给 judge 时尤其如此；
• checklist 式场景 rubric：把标准下沉到场景级清单，例如"两人份 ≤$60 素食 taco 购物清单"场景，清单逐项验证"每件商品都是素食 taco 原料、小计 ≤$60"。这类具体清单比宽泛通用标准方差更低，小样本也能给出可用信号，支撑更快迭代。

另一个连接点：Eligibility 适用性前置——judge 先判该标准是否适用本会话，不适用则跳过（例如食谱流程不因缺少复购步骤被扣分）。这防止"用 A 场景的轨迹标准去罚 B 场景的合法路径"，是轨迹评估中路径多样性问题的 rubric 侧解法。

这套"trace 基础设施 + 证据切片 + 镜像架构"的组合拳带来的业务结果（DoorDash 原文数字）：从平均每天仅 1 条员工反馈，到每天 2,000 个自动评分会话；全国上线前 agent 质量分 +8 分、错误率近乎减半；全量回归从手工 6+ 小时压缩到约 20 分钟——过程级评估不是成本中心，而是让发布敢踩油门的依据。

2.7 前沿一：过程奖励模型（PRM）与信用分配

评估视角的"给步骤打分"，在训练视角叫过程奖励 / 信用分配（credit assignment）——同一套信号，评测用它归因，RL 用它训练。2023–2026 这条线的演进值得每个做 Agent 评估的工程师了解，因为 PRM 正在成为轨迹评估的候选评分器。

PRM vs ORM 的形式化：ORM（outcome reward model）对完整解给一个分数；PRM（process reward model）对每个步骤给分数，整解分数通常取各步对数似然加和 score(y) = Σ_i log r_i。同一套步骤分数有四个用途，评测工程师至少会碰到前三个：

标注成本的三次下降（这是 PRM 工程化的主线）：

OmegaPRM 对评测平台的启示超出标注本身：给轨迹打分不必逐步全量打分，先粗粒度二分定位可疑区间再细查——这与调试长轨迹时"先看中间步骤对不对"的人工策略同构。

两个不需要步骤标签的路线：

• PRIME（arXiv 2412.01981，2024）：token 级价值头 + 隐式奖励，从结果奖励反推每 token 的过程价值，完全不需要步骤标注；对评测的启示是"只有终局真值（如单元测试通过与否）时，仍可通过价值估计获得步骤级归因"。
• VinePPO（arXiv 2410.01679，2024）：在轨迹中间状态重采样 K 条续写，用续写实际回报构造无偏的步骤优势估计。工程含义值得单独记住："从某步出发的成功率"本身就是该步质量的无偏评估——不训练任何模型也能回答"这一步到底值多少分"，可直接用作离线轨迹归因工具（数学基准上相对 GRPO/PPO 最高约 +4 个百分点）。

生成式验证器：GenRM（Generative Verifiers，arXiv 2408.15240，2024）把验证做成生成任务——先生成对每一步的自然语言批注（critique），再输出 verdict。它桥接了 PRM 与 LLM-as-a-Judge 两个世界：批注式验证提供可解释的打分依据，天然接入 judge 工程栈，是当前步骤级 rubric 评估最常用的打分形式（详见第 E05 章）。

PRM 的失败学（必读）：阿里 Qwen 团队的《The Lessons of Developing Process Reward Models in Mathematical Reasoning》（arXiv 2501.07301，2025）系统披露四个结论：① 步骤级标签确实比轨迹级标签更高效；② PRM 的分数可以被 hack——best-of-N 选择中模型会生成恰好骗过 PRM 的解（PRM800K 尤其明显）；③ PRM 在难度外推与分布漂移下性能显著退化；④ PRM 与 ORM 组合使用效果更好。对应工程清单：任何验证器上线前做对抗性审计（hacking 红队）、按难度分层校准、报告中区分 in-distribution 与 OOD 的可信度。rStar-Math（arXiv 2501.04519，2025）进一步指出验证器必须"跟着被测系统一起进化"：它让 PRM 与策略通过 MCTS 共同自进化（Qwen2.5-Math-7B 在 AIME24 达 53.3%，超过 o1-preview 约 8.7 个百分点；MATH 从基线 58.8% 提升到约 90%——注意 58.8% 是 rStar-Math 之前的基线分，不是最终成绩）。评测工程上的对应物：被测 Agent 升级后，旧验证器的分数不可直接比较，需要重新校准或共同迭代。

综合 Qwen Lessons 与 rStar-Math，把 PRM 当评测器/选择器使用时的工程清单：

1. 标注：优先蒙特卡洛或二分自动标注（成本可控），人工标注只用于校准集；
2. 分布：验证器训练分布要覆盖目标难度，OOD 场景分层报告准确率；
3. 红队：上线前做 reward hacking 对抗审计——专门生成"骗验证器"的样本看它上不上当；
4. 组合：PRM 与 ORM 组合使用效果更好（Qwen Lessons 结论四）；
5. 共迭代：被测策略升级后重训/重校准验证器，记录两者的配对兼容性。

信用分配分类学（依据 2026 年综述《From Reasoning to Agentic》，arXiv 2604.09459）可作为面试答题框架：按粒度（token 级 / 步骤级 / 片段级 / 轨迹级）、按信号来源（人工标注 / 模型标注 / 自动估计如 MC rollout 与重采样 / 规则式如单元测试与状态 diff）、按用途（训练时奖励 / 推理时选择 / 纯评测报告）。

2.8 前沿二：Agent 轨迹的专属评估方法与元评估

PRM 线源自数学推理；Agent 轨迹评估有自己的四个代表工作，各自贡献了一个可迁移的工程范式：

（1）AgentBoard（arXiv 2401.13178，2024）——progress rate，让失败可诊断。 为每个任务定义子目标集合，用归一化加权距离衡量轨迹"走了多远"，把 0/1 成功率拆成连续的进展曲线。数据点：即便最强模型总体成功率也仅约 40% 出头；progress rate 与 success rate 的结合揭示了不同模型在规划、探索、利用子能力上的分化。工程迁移：为核心任务定义子目标/检查点，报告 progress rate 而不只是成功率——它直接决定你能不能回答"模型卡在哪一步"。

（2）τ-bench（arXiv 2406.12045，2024）——执行式验证 + pass^k。 评估不靠看对话文本，而是比对对话结束时数据库状态与目标状态是否一致——纯执行式（execution-based）验证，抗"看起来对"的文本欺骗。关键数字：GPT-4o 级模型成功率 <50%，零售域 pass^8 <25%（pass^k 的统计细节见第 E02 章 · 评估指标体系与第 E09 章 · 评估的统计学基础）。它定义的黄金标准组合是：状态比对（而非文本判断）+ 多次重复（可靠性）+ 规则合规性检查。同属执行式验证的还有 Terminal-Bench（arXiv 2601.11868，2026）：80 个高难度 CLI 长程任务，每个配 pytest 风格功能测试 + oracle 参考解，最强模型 + agent 组合成功率约 35%。执行式验证的共同模式：可执行的真值判定程序 + 沙箱；优点客观可复现，代价是每个任务都要写判定程序。

（3）Agent-as-a-Judge（arXiv 2410.10934，2024）——评估者要有"手脚"。 与 LLM-as-a-Judge 的本质区别：评估者是会执行工具的 Agent——拿到被测 Agent 的完整代码库/产物后，可以运行代码、做静态分析、逐步对照分层需求打分。配套 DevAI 基准：55 个真实自动化 AI 开发任务、365 条分层用户需求。关键数字（论文摘要口径）：与人工评估同等可靠，相比三位人类专家评估节省 97.72% 的时间、97.64% 的成本，且评估质量显著优于纯文本判读的 LLM-as-Judge。它是当前对"开放式产物（代码库、报告）"做过程级评估的主流范式；97% 优势的前提是 rubric 质量与 Judge 的工具权限，且为场景特定报告值、不宜外推为普适结论，引用时应一并说明。

（4）AgentRewardBench（arXiv 2504.08942，2025）——评估器本身必须被评估。 这是本方向最重要的"元评估"工作：收集 197 条 Web Agent 轨迹（含成功与人工确认的失败案例），系统测试各类自动评估器识别"轨迹真正成功"的能力。核心发现令人清醒：多数评估器的 false positive 率极高——多个常用评估器在失败轨迹上的误报率超过 50%，纯 LLM 判别尤其不可靠；结合代码/执行检查与分步核对的方案明显更好。落地要求：任何轨迹评估器（尤其 LLM judge）上线前，先在已知成败的轨迹集上测 FPR/FNR；优先选择有执行式依据的评估器；把评估器准确率作为评测基础设施的一级指标。

把四者串起来，得到轨迹评估器的选型优先级（与第 E04 章"确定性优先"一脉相承）：

规则/执行式验证（终态 diff、单测、schema、must-call 断言）
        ↓ 覆盖不到的语义判断
Agent-as-a-Judge / 带证据切片的 LLM judge（须过元评估：已知成败集测 FPR/FNR）
        ↓ 高风险 / 低置信 / 评估器分歧
人工抽检（校准 judge、审"结果对但轨迹可疑"样本，见第 E06 章）

trace 级自动诊断的现状：TRAIL（arXiv 2505.08638，2025）提出覆盖子代理/工具调用/任务推理等维度的 27 类错误分类学，发布 148 条人工标注 agent trace；即便最强模型，"给定完整 trace 定位根因"的准确率也仅约 40–60%。AgentDebug（arXiv 2509.25370，2025）把失败归因到 6 个模块（工具使用、上下文/记忆管理、规划、验证等）并做"诊断→修复→复跑"闭环，失败恢复率提升约 10% 量级。SentinelAgent（arXiv 2505.24201，2025）则把视角从"事后诊断"推向"运行时监控"：将 agent 间交互建模为图结构，由专职监督 agent 结合图拓扑与运行时指标做异常检测与归因——离线评测保证出厂质量，运行时异常检测保证存量质量，二者互补（在线侧详见第 E12 章）。结论：trace 质量与 span 粒度决定自动诊断上限；LLM 诊断结果应作为"待人工确认的假设"呈现，而非自动修复。

综合判定：加权平均 vs 硬门禁。 三层分数如何汇总成一个判定？lab06 给出的答案是"加权 + 一票否决"双轨：常规偏差（顺序错、多余步骤、效率超标）用扣分制（腾讯 80 分达标线）；但禁用动作命中、关键校验缺失、最终目标未达成这三类失败不允许被其他层的高分"平均"掉——跳过身份校验不能靠"语气好"补回来。门禁的数量要克制，否则误杀率上升，评估体系会退回"没人信"的状态（门禁设计的完整讨论见第 E10 章 · 评测驱动开发）。

本节收束：轨迹评估落地清单（把 2.3–2.8 压缩成八条可执行动作）：

1. 结构化轨迹日志先行——没有满足三要求的 trace，后面全部免谈；
2. 评估器分层——规则/执行式验证为主，Agent/LLM judge 为辅，人工抽检校准；
3. 评估器先过元评估——在已知成败的轨迹集上测 FPR/FNR，再谈上线；
4. judge 只拿证据切片——Transcript Builder 塑形，每条标准声明依赖证据；
5. 轨迹比对禁 exact match——归一化 + LCS / 无序集合 / 偏序约束三选一；
6. 长程任务报 progress rate——子目标分解让失败可诊断，而不只是 0/1；
7. 可靠性多次试验——pass@1 + pass^k（k≥4），固定温度与用户模拟协议；
8. 把评估器当资产管理——版本化、定期元评估、记录验证器与被测模型的配对兼容性。

三、面试高频考点

四、经典面试题与参考答案

题 1（基础）：为什么评估 Agent 不能只看最终答案？请举一个具体例子。

参考答案： 四个盲区：① 假阳性——结果对但路径错/带风险，如退款 Agent 跳过订单状态查询直接承诺退款成功，这次恰好可退所以"答对了"，但风险敞口一直在，阿里明确这类假阳性"在生产迟早暴露"；② 诊断盲区——20 步轨迹失败，错误可能在第 3 步，终局只有一个 0/1 标量，无法定位；③ 捷径与欺骗——最终状态"看起来对"可能来自绕过规则或 reward hacking；④ 碰运气——"训练数据碰巧答对"与"正确调用工具后回答"在最终文本上无法区分，通过率不可复现。此外还有双向背离：过程全对也可能因环境抖动而终局失败，所以工业界用"终态正确 + 规则合规"双门槛，而不是单看任一侧。

题 2（基础）：说说轨迹评估的三层模型，每层评什么、怎么评、失败说明什么？

参考答案： Airbnb 三层：step-level 评单工具调用/推理步——参数 JSON Schema 校验、must-call/must-not-call 断言、禁用动作检查，失败指向单工具实现或参数生成问题；trajectory-level 评整条路径是否合理高效——与基线做 LCS 对齐、无序关键调用集合比对、步数/token 预算检查，失败指向规划与编排问题（绕路、重复、跳步、顺序颠倒）；session-level 评整体是否达成用户目标——终态比对、目标 checklist，失败指向目标理解问题。三层独立失败、不可替代：session 分高掩盖不了 trajectory 违规（假阳性），trajectory 完美救不了 session 失败。阿里对话 Agent 版本是四层：Turn/Session/Trace/Outcome，特别警告"不要只平均每轮分数"——每轮都答得还行但最终没解决问题仍是失败。

题 3（基础→进阶）：什么是结构化 Trace 的三个要求？接手的被测 Agent 没有 Trace 输出怎么办？

参考答案： 三要求（腾讯）：① 可解析——JSONL/JSON 结构化格式而非自由文本；② 内容完整——每步工具名/入参/返回/时间戳/耗时/错误，理想含思维链与决策依据；DoorDash 的 span 记录用户输入、模型输出、工具调用与返回、展示给用户的 widgets；③ 跨版本格式稳定——schema 不随版本漂移，否则历史分数不可比。没有 trace 时三档对策：有日志无结构 → 写解析器（成本高易碎，下策）；只有最终输出 → 只能做结果评测（中策）；可改造 → 推动被测系统增加 trace 输出（推荐）。立场要鲜明：trace 是被测 Agent 的标准能力而非事后补救（阿里/腾讯共识）。标准化方向是 OTel GenAI semconv（gen_ai.* 属性），截至 2026 年仍处 Development 状态，agentic 层级 2025-08 才有提案，应"先按标准打点 + 保留私有字段兼容层"。

题 4（进阶）：DoorDash 的 Transcript Builder 解决什么问题？如果让你设计，怎么做？

参考答案： 问题：原始 trace 完整但难判——工具返回可能巨大（超出/淹没 judge 上下文）、schema 脚手架与无信号字段多、证据散落多个 span/turn。设计分两步：第一步是三个清洗动作——重组分散的 span、删无质量信号的 token、裁剪超大载荷，产出紧凑视图（DoorDash 用一组 Python 脚本实现，原始 trace 仍存 ClickHouse 供人审与 RCA）；第二步是证据切片——每条 rubric 标准声明自己依赖的证据，builder 只把那一片交给 judge：grounding 检查拿 agent 论断 + 背后工具输出，多样性检查拿推荐列表 + 原始请求，叙述检查拿流式输出文本。收益：聚焦证据让 judge 判断更一致、上下文成本更低。注意点：裁剪规则要版本化（裁过头是 harness 自身 bug，DoorDash 承认被标记失败中有真实一部分来自评测系统自己）；证据声明与 rubric 是同一契约，要一起 review。

题 5（进阶）：两条工具调用轨迹怎么做比对？为什么不能 exact match？归一化的作用和风险是什么？

参考答案： 不能 exact match，因为同一任务有多条合法路径，全等比对会把合法变通判错，评估集退化成背答案。腾讯 TPerf 的 LCS 方案四步：① 归一化——时间戳占位、搜索类工具忽略查询参数、写入只留路径、终端命令提取脚本名、连续读文件组内不校验顺序；② 求 LCS 公共骨架；③ 非 LCS 部分分类为不一致/多余/缺少/顺序错，各扣 2 分、上限 -10；④ 效率对比——耗时以 300 秒为基准每超 10% 扣 1，token 以基线为基准每超 10% 扣 1、上限 -10。归一化的作用是抹掉"不影响对错的差异"，否则同一行为每次运行都被判不一致；风险是归一化过度——若把金额、订单号这类关键参数也忽略掉，参数错误会被静默放过，等于把假阳性重新放进来。路径自由度更高的任务可退到无序关键调用集合或偏序约束（只断言"先鉴权后操作"这类依赖）。基线来自"执行 1 次 + 人工确认"的快照机制，只在逻辑变更/模型升级/用例修改时更新。

题 6（进阶）：PRM 和 ORM 有什么区别？没有步骤级标注数据时，还有哪些办法拿到步骤级信号？

参考答案： ORM 对完整解打一个分，PRM 对每个步骤打分、整解分数通常取各步对数似然加和。PRM800K（arXiv 2305.20050，2023）证明步骤级标签信息密度约高 100 倍（GPT-4 直接解 MATH 52.9%，PRM best-of-1250 达 78.2%）。没有步骤标注时有四条路线：① 蒙特卡洛标注（Math-Shepherd，arXiv 2312.08935）——从某步多次 rollout，"走到正确答案的比例"作软标签；② 二分搜索（OmegaPRM，arXiv 2406.06592）——二分定位第一个错误步骤，标注成本 O(n)→O(log n)，降约 100 倍；③ 隐式奖励（PRIME，arXiv 2412.01981）——token 级价值头从结果奖励反推过程价值，只有单元测试真值也能用；④ 中间状态重采样（VinePPO，arXiv 2410.01679）——从某步重采样 K 条续写看成功率，不训练模型即可做离线步骤归因。必须补一句失败学（Qwen Lessons，arXiv 2501.07301）：PRM 分数可被 hack、难度外推下退化，直接当评测器要先做红队与 OOD 分层校准。

题 7（进阶）：Agent-as-a-Judge 和 LLM-as-a-Judge 的本质区别是什么？它能直接信任吗？

参考答案： 本质区别：评估者是否有环境交互能力。LLM-as-a-Judge 是"阅读式"——读 transcript 打分；Agent-as-a-Judge（arXiv 2410.10934，2024）让 Judge Agent 带工具核验——运行代码、静态分析、逐条对照分层需求，能核验而非仅阅读。在 DevAI 基准（55 个真实 AI 开发任务、365 条分层用户需求）上，它与人工评估同等可靠，相比三位人类专家节省 97.72% 时间、97.64% 成本（场景特定值），评估质量显著优于纯文本判读。但不能直接信任，两个理由：① AgentRewardBench（arXiv 2504.08942，2025）用 197 条 Web Agent 轨迹测出多数自动评估器在失败轨迹上的误报率超过 50%，结合执行检查与分步核对的方案才明显更好——所以任何轨迹评估器上线前先在已知成败的轨迹集上测 FPR/FNR；② 97% 的时间/成本优势有前提——rubric 质量与 Judge 的工具权限，开放式产物评估尤其依赖分层 rubric 写得好不好。

题 8（进阶）：什么是"评估器的元评估"？你的轨迹评估方案上线前要做哪些验证？

参考答案： 元评估 = 评估"评估器本身"。动机是 AgentRewardBench 的实证：自动轨迹评估器把明显失败的轨迹判为成功的比例普遍超过 50%，且评估器之间差异巨大——不测元指标就上线，等于把质量门禁交给一个未知的分类器。上线前验证清单：① 构造已知成败的轨迹集（成功 + 人工确认的失败，含"结果对但过程错"的假阳性样本），测评估器的 FPR/FNR——假阳性识别能力是轨迹评估器的核心能力；② 与人工标注对齐，一致率达到团队口径（Airbnb high 80s~90s，阿里/腾讯约 85%）后才进自动化（详见第 E05 章校准流程）；③ 偏差检查（位置/冗长/同源偏好，见第 E05 章）；④ 稳定性检查（同轨迹重复评分方差）；⑤ 持续运营——judge 模型/prompt/rubric 任一变更触发重校准，记录评估器与被测模型的配对兼容性（被测 Agent 升级后旧评估器分数不可比，rStar-Math 的教训）。

题 9（系统设计）：为一个多领域对话 Agent（客服 + 购物助手，Orchestrator 路由到各领域 Agent）设计完整的轨迹与 Agent 级评估体系。

参考答案： 分六层回答。 ① Trace 先行：被测系统按 OTel 打点，span 记录用户输入/模型输出/工具调用与返回/widgets（DoorDash 口径），层级 session→agent/task→llm_call→tool_call；满足可解析、内容完整、跨版本格式稳定三要求；trace 存 ClickHouse 类列式存储。 ② 评测镜像运行时架构（DoorDash）：Orchestrator 评路由准确率（该转不转/转错人）；护栏 rubric 贯穿全流程评（不泄露内部过程、不呈现可证伪虚假信息，全体 Agent 通用）；每个领域 Agent 评任务能力（客服评工单闭环与政策合规，购物评约束满足与多样性），失败可归因到 owner。 ③ 三层评分：step 层用程序化断言（参数 schema、must-call/must-not-call、禁用动作）；trajectory 层用归一化 + LCS 对齐关键 SOP（缺少关键校验触发硬门禁，其余按腾讯口径各扣 2、上限 -10）+ 效率预算（步数/token/耗时）；session 层用执行式验证——终态数据库 diff（τ-bench 范式）+ 目标 checklist，不靠判文本。 ④ Judge 层：语义类标准（groundedness、叙述质量）用 LLM judge，前置 Transcript Builder：每条标准声明证据依赖，judge 只拿切片；judge 校准到 ≥85% 一致率，rubric 写成 binary check + eligibility 前置。 ⑤ 元评估与门禁：所有自动评估器先在已知成败轨迹集测 FPR/FNR；综合判定 = 加权扣分 + 一票否决（禁用动作/关键校验缺失/目标未达成）；多 trial 报 pass@1 与 pass^k（无人值守口径看 pass^k）。 ⑥ 闭环：线上 trace 抽样回流（每日去标识化 5% 流量，Airbnb 口径），"结果对但轨迹可疑"样本人工抽检后入回归集；被测 Agent 升级时评估器同步重校准。仿真侧（模拟器 + fixtures 生成轨迹）见第 E08 章，失败归因流水线见第 E11 章。

题 10（进阶）：一条 20 步的轨迹最终失败了，你有哪些办法定位"是哪一步坏的"？

参考答案： 四条路线，成本与保真度各不同。① 中间状态重采样（VinePPO，arXiv 2410.01679 的思路）：从可疑步骤出发重采样 K 条续写，续写的成功率就是该步质量的无偏估计——不训练模型即可用于离线归因；② 先粗后细二分定位（OmegaPRM 的工程启示）：不必逐步全量打分，先验证轨迹中点状态是否还在正确路径上，再对可疑半区递归二分，O(log n) 成本锁定可疑区间；③ 成功/失败轨迹 diff：同一任务的成功 trial 与失败 trial 做序列对齐，找第一个分叉点（工具参数不同？检索结果不同？规划选择不同？）——前提是 trace schema 跨版本稳定、试验条件可复现；④ 评估器辅助归因：让带工具的 judge（Agent-as-a-Judge 形态）逐步核验并给出批注，适合无法重放的环境，但要先过元评估。所有路线的共同前提是完整结构化 trace（2.3 节）与可重放环境；定位结论应落成结构化归因字段，喂给 RCA 的范围收敛（第 E11 章），而不是停在口头结论。

五、易错点 · 反直觉点

1. 轨迹 exact match：把"调用顺序不同但正确"的解判错，评估集退化成背答案，还扼杀了更优路径的发现。→ 真相：用 LCS 对齐 / 无序关键调用集合 / 偏序约束，只锁关键依赖，保留路径自由度。→ 记忆锚点：锁关键步骤，不锁全路径。

2. 把"结果对"当"行为对"：最终文本会抹平一切中间失败，假阳性样本在离线评测里以"通过"存在。→ 真相：结果对但路径错的样本比结果错更危险——偶发正确不可复现、风险敞口持续存在、失败还无法归因；必须"终态正确 + 规则合规"双门槛。→ 记忆锚点：结果判 pass，轨迹判安全。

3. 把原始 trace 整个喂给 judge：上下文被工具返回与脚手架噪声淹没，判断方差大、成本高。→ 真相：DoorDash 的教训是 judge 需要"为问题塑形"的视图——每条标准声明证据依赖，只给那一片。→ 记忆锚点：judge 只看它需要的那页。

4. 归一化过度：时间戳、查询参数该抹，但把金额、订单号也抹掉，参数错误就被静默放过。→ 真相：归一化只抹"不影响对错的差异"；抹错一个关键字段 = 亲手造一个假阳性。→ 记忆锚点：归一化抹噪声，不抹证据。

5. 加权平均一切：用"总分 = 各层加权"做判定，跳过关键校验可以用语气分补回来。→ 真相：禁用动作命中、关键校验缺失、目标未达成必须一票否决（硬门禁），扣分制解决不了安全问题。→ 记忆锚点：安全问题不进平均分。

6. 拿 PRM 直接当评测器，不做红队：Qwen Lessons（arXiv 2501.07301）证明 PRM 分数可被 hack——best-of-N 会选出恰好骗过 PRM 的解，难度外推时打分系统性失准。→ 真相：验证器上线前做 hacking 红队 + 难度分层校准，报告区分 in-dist 与 OOD 可信度。→ 记忆锚点：验证器也怕被刷分。

7. 纯阅读式 LLM judge 直接评轨迹：AgentRewardBench 实测多数自动评估器在失败轨迹上误报率 >50%，"读起来像成功"与"真的成功"是两回事。→ 真相：优先执行式依据（终态 diff、测试、断言），judge 只做补充，且先在已知成败集上测 FPR/FNR。→ 记忆锚点：先验评估器，再让它评。

8. Trace 事后补：上线后才想起加日志，靠脆弱解析器从自由文本里抠结构化信息。→ 真相：trace 是被测 Agent 的标准能力（阿里/腾讯共识）；三要求（可解析/内容完整/跨版本稳定）在设计阶段定，事后补的成本是重造一遍。→ 记忆锚点：没有 trace，就没有过程评估。

9. 被测 Agent 升级后直接对比旧评估器分数：验证器在旧策略分布上训练/校准，评估新策略时系统性失准。→ 真相：rStar-Math 的结论是验证器必须与被测系统共同进化；策略升级 → 评估器重校准，否则分数差异归因不了。→ 记忆锚点：尺子也要跟着版本走。

10. 只平均每轮分数评对话 Agent：每轮都"答得还行"，平均分挺好看，但问题最终没解决。→ 真相：阿里四层评判要求同时看 Turn/Session/Trace/Outcome，session/outcome 层失败一票压过 turn 层均值。→ 记忆锚点：平均分会骗人，闭环才算数。

六、推荐资源

论文（全部来自本特辑 _research/03-trajectory-eval.md 与 _research/10-infra-observability.md，arXiv ID 已核实）

1. Let's Verify Step by Step（PRM800K）— arXiv 2305.20050（2023）：过程监督的奠基，步骤级标签信息密度约高 100 倍。
2. Math-Shepherd — arXiv 2312.08935（2023）：蒙特卡洛完成率自动标注，"步骤质量 = 后续成功率"范式的确立。
3. OmegaPRM — arXiv 2406.06592（2024）：二分搜索把过程标注成本降到 O(log n)。
4. Generative Verifiers（GenRM）— arXiv 2408.15240（2024）：批注式生成验证，PRM 与 LLM-as-a-Judge 两个世界的桥。
5. VinePPO — arXiv 2410.01679（2024）：中间状态重采样的无偏步骤归因，可直接当离线轨迹归因工具。
6. PRIME — arXiv 2412.01981（2024）：无步骤标签的隐式过程奖励。
7. The Lessons of Developing Process Reward Models（Qwen）— arXiv 2501.07301（2025）：PRM 失败学，hack 与 OOD 问题的第一手报告。
8. rStar-Math — arXiv 2501.04519（2025）：验证器与策略共同自进化。
9. AgentBoard — arXiv 2401.13178（2024）：progress rate 与子目标分解。
10. τ-bench — arXiv 2406.12045（2024）：终态数据库 diff + pass^k，tool-agent 评测的黄金标准。
11. Agent-as-a-Judge — arXiv 2410.10934（2024）：带工具核验的过程级评估，DevAI 基准。
12. AgentRewardBench — arXiv 2504.08942（2025）：轨迹评估器的元评估，FPR >50% 的警钟。
13. Terminal-Bench — arXiv 2601.11868（2026）：执行式验证在 CLI 长程任务上的规模化实践。
14. TRAIL — arXiv 2505.08638（2025）：27 类 agent trace 错误分类学与自动定位。
15. AgentDebug — arXiv 2509.25370（2025）：六模块失败归因与"诊断→修复→复跑"闭环。
16. 延伸阅读：信用分配综述《From Reasoning to Agentic》arXiv 2604.09459（2026）；PRM 综述 arXiv 2510.08049（2025）；StepAgent arXiv 2411.03817（2024）；SPA-RL arXiv 2505.20732（2025）；AgentTrace 结构化日志框架 arXiv 2602.10133（2026）。

工程博客（四家工业实践一手来源，数字以 _research/00-industry-practice.md 为准）

• Airbnb《Eval-driven development: Lessons from evaluating GenAI at scale》——三层 Agentic 评估（step/trajectory/session）与 root trace 树遍历的出处。
• DoorDash《Building Ask DoorDash (Part 3): Evaluation》（2026-06）——Transcript Builder、评测镜像运行时架构、OTel + ClickHouse 的出处；同系列 Part 1/2 讲架构与 fixtures（与第 E08 章配套阅读）。
• 阿里技术《Agent 评测：方法论与体系设计》——Turn/Session/Trace/Outcome 四层评判、"trace 是标准能力"立场、假阳性案例的出处。
• 腾讯技术工程《AI Agent & Skill 测评方案及落地实践》——LCS 对齐、归一化五规则、基线快照、TPerf 实战数字的出处。
• OpenTelemetry GenAI Semantic Conventions（open-telemetry/semantic-conventions-genai，Development 状态；agentic 提案 2025-08）— https://opentelemetry.io/docs/specs/semconv/gen-ai/

动手实验（labs）

相关章节

• 第 E04 章 · 评分三层之一：程序化评分——step 层断言的完整清单与扣分制细节。
• 第 E05 章 · LLM-as-Judge 深入——judge 偏差、rubric 工程与校准流程（Transcript Builder 的下游）。
• 第 E06 章 · 人工评估与评分路由——"结果对但轨迹可疑"样本的人审兜底。
• 第 E08 章 · 对话 Agent 与仿真评测——Conversation Simulator 与 fixtures 如何批量生产轨迹。
• 第 E09 章 · 评估的统计学基础——pass^k 的估计与置信区间。
• 第 E11 章 · Badcase 根因分析与优化闭环——三层分数如何喂给 RCA 的范围收敛。
• 第 E13 章 · Benchmark 全景与前沿争议——τ-bench/GAIA/Terminal-Bench 等外部基准的全景对照。
• 主手册第 8 章 · Agent 评估与可观测性——入门浓缩版（本章为其过程评估部分的深挖）。

对话 Agent 与仿真评测

一句话导读：对话 Agent 的质量无法用"一问一答"的静态数据集衡量——用户会追问、改主意、发脾气、等你引导他操作。 本章解决"没有真实用户参与时，如何端到端、可复现、低成本地评测多轮对话 Agent"： Conversation Simulator（LLM 扮演用户）+ Fixtures（冻结外部世界）+ checklist 式 rubric + 全量 sweep 的成本工程。 学完你能得到：对话评测五大难点与四层判分框架、DoorDash 会话模拟器与 fixtures 的完整设计细节、 τ-bench/τ²-bench 学术范式与 pass^k 可靠性数字、模拟器保真度的验证方法，以及仿真评测的边界与 offline-online gap 治理。

一、知识图谱

对话 Agent 与仿真评测
├─ 难点：对话评测为什么特殊（2.1）
│   ├─ 五大难点：上下文累积 / 目标切换 / 情绪回应 / 人工接管 / 多轮引导
│   ├─ 核心判据："每轮都答得还行，但没解决问题仍是失败"（阿里）
│   └─ 四层判分：Turn（单轮）/ Session（整段会话）/ Trace（执行轨迹）/ Outcome（最终结果）
├─ 演员：Conversation Simulator（2.2）
│   ├─ scenario = 开场请求 + 用户目标 + 反应策略（DoorDash）
│   ├─ persona 来源：真实工单抽取 / 隐式画像挖掘（arxiv 2502.18968）/ 真实日志语料
│   ├─ 行为真实性：动态判断 解决? 有进展? 缺信息? 绕圈?；升级像真人（逐步升级而非秒转人工）
│   └─ 非合作模拟：会不耐烦、跑题、改主意（ChatChecker, arxiv 2507.16792）
├─ 舞台：Fixtures 冻结外部状态（2.3）
│   ├─ 录制工具返回替代实时调用：菜单/库存/测试账号不再漂移
│   ├─ reorder_history_v1 实例（DoorDash 复购场景）
│   ├─ 附带收益：可构造欺诈、大额退款等真实里难遇的难例
│   └─ 教训："环境必须受控，否则分数测量的是噪声"（DoorDash）
├─ 范式：从 τ-bench 到工业流水线（2.4）
│   ├─ τ-bench（arxiv 2406.12045）：模拟器 + 工具 + DB 终态哈希 + pass^k
│   ├─ τ²-bench（arxiv 2506.07982）：双控——用户侧也能动手，引导比代办难
│   └─ DoorDash：同一 rubric + 同一 judge 贯穿离线线上；GEPA 校准裁判
├─ 判据：checklist 式场景 rubric（2.5）
│   ├─ 素食 taco ≤$60 案例（DoorDash）：低方差信号，小样本也能迭代
│   └─ eligibility 适用性前置：不适用的标准跳过而非扣分
├─ 成本：全量 sweep 的工程账（2.6）
│   ├─ 50 场景 × 8 trials = 400 对话；人工 6h+ → 模拟器约 20min
│   └─ 成果：2,000 会话/天自动评分、上线前质量分 +8、错误率近乎减半
└─ 边界：仿真 ≠ 真实（2.7）
    ├─ 模拟器自身要被评测：目标一致性、幻觉、同源偏差（DAUS, arxiv 2402.13374）
    ├─ offline-online gap：强离线成绩只是部署可靠性的弱指标（arxiv 2510.22143）
    └─ 治理：保真度抽检 + 同一 rubric 同一 judge + shadow/canary 第二道闸

二、核心概念精讲

2.1 对话评测的五个特殊难点：为什么不能"每轮打分取平均"

单轮问答评测的范式是"输入 → 输出 → 对照参考答案"。对话 Agent 把这个范式打碎了—— 阿里技术在《Agent 评测：方法论与体系设计》中把对话 Agent 的特殊难点归纳为五类， 并给出一条总纲式判据：不要只平均每轮分数——每轮都"答得还行"但最终没解决问题，仍是失败。

四层判分框架（阿里）：对话 Agent 要同时看四个层面，任何一层单独成立都不够：

四层的关系是：Outcome 是最终裁决，Turn/Session/Trace 是归因与护栏。 一个会话可以每轮 Turn 分都很高（礼貌、流畅、格式正确），但 Outcome 是失败的—— 用户绕了八轮还是没退成款。反过来，Outcome 成功也可能掩盖 Trace 层的风险 （跳过了订单状态校验恰好没出事，即"假阳性"，详见第 E7 章）。 工程口径：门禁判 Outcome 与关键 Trace 断言，Turn/Session 分用于诊断与体验迭代，绝不互相替代。

这套四层与 Airbnb 的 step/trajectory/session 三层（第 E7 章）、 腾讯的"触发→核心逻辑→产物质量→异常容错"四场景用例组织（第 E3 章）互为表里： 对话评测的特殊性在于，Session 层的"推进质量"无法静态判分，必须让一个会动态反应的用户把会话跑完—— 这就引出了本章的主体：仿真评测。

2.2 Conversation Simulator：让 LLM 扮演用户

（1）为什么必须"按需生成会话"。 DoorDash 在 Ask DoorDash 评测 harness 的五大挑战中， 把对话评测的困境表述得最尖锐：

注意第三条里的关键洞察：历史会话不能对改过的 agent 重放——agent 变了，面对同一句话的回应就变了， 对话路径随之完全不同，"重放"测的已不是同一个交互。所以正确姿势不是回放录像，而是 让一个 LLM 扮演用户，按场景设定与 agent 现场对戏，每次生成一条新会话。

（2）模拟器的解剖：scenario 三要素。 DoorDash 的 Conversation Simulator 让 LLM 扮演购物者， 一个 scenario（场景）定义三件事：开场请求、用户目标、对提问/结果的反应方式。 场景是数据而不是代码——sweep 要跑几十上百个场景，场景必须可序列化、可版本管理、可由非工程师编写。 一个结构化完整的场景配置实例（字段组织参照 DoorDash 公开描述与本特辑 lab 约定）：

evalId: grocery-reorder-001
sessionInput:                      # 会话的环境输入（渠道、用户档案等）
  channel: chat
  userLocale: en-US
conversationScenario:
  opening: "Reorder my usuals"     # 开场请求：模拟器的第一句话
  userGoal: >
    完成常购清单复购；确认配送时间；不接受用含花生商品替换
  persona:                         # 从真实工单抽取：脾气 + 情境叙事 + 期望结果
    temper: "耐心有限，但讲道理"
    contextStory: "每周日晚固定复购的常客，这周赶时间"
    expectedOutcome: "订单确认 + 明确配送窗口"
  reactionPolicy:                  # 反应策略：模拟器行为的"性格"
    whenAskedClarification: "挤牙膏式补充：一次只说一条自己知道的信息"
    whenNoProgressTwice: "要求升级/投诉——像真人一样给过机会才发火"
    whenResultWrong: "反驳并给出自己的依据，不轻易接受"
fixtures:                          # 冻结外部状态（见 2.3）
  get_reorder_items: reorder_history_v1
rubric: [reorder-checklist-v2, guardrail-communication, trust-honesty]
trials: 8                          # 每场景重复运行次数（支撑 pass^k，见 2.6）

（3）persona 从哪来：四条进料线。

注意方向上的呼应：真实日志 → 隐式画像 → 模拟器 → 回归测试，这本身就是一条数据飞轮 （详见第 E12 章）——模拟器的 persona 不必全靠手写模板，可以从生产对话中"挖掘"。

（4）行为真实性：模拟器要做动态判断，而不是念台词。 一个合格的模拟用户在会话中持续回答四个问题： 是否已解决？是否有进展？是否需要更多信息？是否在绕圈？ 并据此决定配合、追问还是升级。 DoorDash 的要求是升级行为像真人：给过几次机会、agent 反复答得差才投诉， 会反驳、会补充细节、会逐步升级，而不是一上来就转人工。 本特辑 labs/eval_lab07_simulator_fixtures.py 用一个最小状态机实现了这种"真人耐心"： 未解决但有进展 → 继续配合；被反问 → 补充信息；连续 2 次无进展 → 升级投诉 （cd evals-special/labs && python3 eval_lab07_simulator_fixtures.py）。

（5）合作型模拟的系统性高估与非合作模拟。 如果模拟用户总是礼貌、信息完备、轻易满意， 它会把 agent 的能力系统性高估。ChatChecker（arxiv 2507.16792，2025）把"找茬式测试"工程化： persona 驱动的非合作用户模拟器——用户会不耐烦、跑题、表达模糊、中途改主意—— 配 Breakdown Detector（检测对话崩坏点，定位失败轮次，服务回归归因）与 Dialogue Rater（对系统质量打分）三件套。 工程推论：场景库必须包含"难缠用户"切片（易怒、模糊、改主意、多目标）， 否则你在一个礼貌的假用户身上测出了一个礼貌的假高分。 同理，lab07 的 checklist 还验证了一件反直觉的事：编造商品的 agent 可以让"用户"满意收尾—— 模拟用户的满意不等于任务正确，结果判定必须独立于对话氛围（见 2.5）。

2.3 Fixtures：冻结外部世界，否则分数测量的是噪声

（1）问题：实时外部状态让评测不可复现。 对话 Agent 的背后是一圈活着的外部系统： 商品目录每天在变、门店库存实时波动、测试账号状态漂移。如果评测时真的调用这些接口， 同一条用例每次测的其实是不同的题——今天通过明天失败的差异，可能全部来自环境而不是 agent。 DoorDash 的 Lesson Learned 第二条原话是："环境必须受控，否则分数测量的是噪声。"

（2）解法：录制工具返回，回放替代实时调用。 fixtures 的做法是： 把工具的真实返回录制成固定 payload，评测运行时拦截工具调用、原样回放。 DoorDash 复购场景的实例：开场请求 "Reorder my usuals"，工具 get_reorder_items 固定返回录制的 reorder_history_v1——一份 Albertsons 的历史订单 （Meadow Gold 全脂牛奶 ×2、Oroweat 全麦面包、牛油果、Ben & Jerry's 冰淇淋……）。 于是每次运行 agent 都看到同一份订单 → 预期结果可预测 → judge 可以对照同一商品集评分。 把这份 fixture 展开成结构化 JSON 大致如下（商品清单忠实于原文，字段结构为示意）：

{
  "fixture_id": "reorder_history_v1",
  "recorded_from": "生产会话录制并脱敏",
  "merchant": "Albertsons",
  "items": [
    {"name": "Meadow Gold Whole Milk", "qty": 2},
    {"name": "Oroweat Whole Wheat Bread", "qty": 1},
    {"name": "Avocado", "qty": 3},
    {"name": "Ben & Jerry's Ice Cream", "qty": 1}
  ]
}

（3）fixtures 的三重价值与对照。

第三重价值常被忽略：fixture 让"真实里很难遇到的场景"变成可批量测试的用例—— DoorDash 用 mock 后端模拟订单/退款/时间戳来复现欺诈、大额退款等边角案例。 这类场景在真实流量里占比极低（正是第 E3 章说的幸存者偏差），却恰恰是资损与合规的高风险区。

（4）fixture 的治理。 fixtures 不是写完就完：

1. 版本化：reorder_history_v1 的命名暗示了版本演进；场景配置与 fixture 一起进仓库、带 provenance（EDDOps 对评测资产的通用要求，见第 E10 章）。
2. 防 mock 漂移：录制的返回要与生产 API 定期对账——上游 schema 变了、字段语义变了而 fixture 没更新，评测全绿、上线即炸（主手册第 8 章 · Agent 评估与可观测性）。
3. 环境隔离：评测执行环境要隔离，避免多用例共享状态导致分数不可复现（阿里）；每条用例从干净状态启动。
4. 脱敏合规：fixture 源自真实数据时必须去标识化、用途限定（Airbnb 隐私注记，见第 E3 章）。

动手：labs/eval_lab07_simulator_fixtures.py 专门设置了对照组——同一 agent、同样采样随机性下， fixture 组 N 次评分一致，而"漂移的伪实时数据"组方差显著膨胀，亲眼验证 "环境不受控时分数测量的是噪声"。运行：cd evals-special/labs && python3 eval_lab07_simulator_fixtures.py

2.4 标准范式：从 τ-bench 到 DoorDash 全流水线

（1）τ-bench：对话 Agent 仿真评测的模板。 学术侧的范式源头是 Sierra 的 τ-bench（arxiv 2406.12045，2024）：LLM 用户模拟器与 agent 多轮对话， agent 需遵守领域政策（retail/airline 域的企业规则）并调用 API 工具， 最终以数据库终态哈希做可验证判定（而非只看对话文本），并用 pass^k 刻画"单次通过率在多次独立试验下的一致性"。这套"模拟器 + 可验证终态 + 重试验可靠性"设计 成为后续几乎所有对话 Agent 仿真评测的模板，也被 DoorDash 等工业实践直接借用。

τ-bench 最具冲击力的数字（论文摘要转述，量级可信、精确值以原文为准）：

口径提示：上表为论文摘要数字；Sierra 官方榜单（taubench.com）后续报告的 GPT-4o 更高——retail 60.4%、airline ≈42%。本手册凡引 τ-bench GPT-4o 成绩，论文口径记 ~35%（airline）、榜单口径记 ~42%，两者并存，切勿混用（另见本章末数字附注与第 E2 章）。

GPT-4o 从 pass^1 到 pass^8 腰斩再腰斩，说明 "能做对一次"与"稳定做对"之间差距巨大—— 对话每多一轮、任务每多一步，误差都在复合。这也是为什么生产级对话 Agent 的发布门槛 应当使用 pass^k（低 k）而非 pass@1（指标定义与无偏估计见第 E2 章，统计口径见第 E9 章）。

（2）τ²-bench：双控与"多轮引导"难点。 τ²-bench（arxiv 2506.07982，2025）把范式升级为 dual-control（双控）：模拟用户不再只是说话，也能自己执行工具动作（点击邮件链接、改路由器设置）， agent 必须通过对话引导用户完成动作，并处理联合行动中的信息不对称；新增 telecom 域， 任务涉及跨系统排障、指导非专家用户。评测显示：即使最强模型，在双控设定下的成功率也远低于 τ-bench 单控设定——引导用户操作比直接操作难得多。 这为 2.1 的第五个难点（多轮引导）提供了定量注脚：客服/支持类 agent 的真实瓶颈是"指挥用户"， 仿真评测若让用户侧没有行为能力，会系统性高估 agent。

（3）DoorDash 的全流水线：评测镜像运行时架构。 DoorDash 是多 agent 架构： 用户消息 → Orchestrator → 路由到领域 Agent（如 Restaurant Discovery Agent）→ 领域 Agent 直接处理或交还 Orchestrator。评测与之同形：路由在 Orchestrator 评；护栏贯穿全流程评； 任务能力在每个领域 Agent 评（组织方式详见第 E7 章）。对话仿真评测在这条流水线上的位置：

场景库（scenario + persona + fixture）
  → Conversation Simulator 生成模拟用户消息
  → 被测 agent 全流程运行（工具调用被 fixture 拦截回放）
  → OpenTelemetry trace 落 ClickHouse → Transcript Builder 按标准切证据片
  → 校准过的 LLM judge 逐条标准二元判定（verdict + rationale）
  → 汇总为会话级分数 → 全量 sweep 报告（按场景 × trial）

两个贯穿性约定：① 离线与线上用同一 rubric + 同一校准 judge——这是 DoorDash Lesson Learned 第三条： 离线结果只有能带到线上才有意义；若离线线上各自调 judge，两边分数会以难调和的方式背离 （详见第 E12 章）。② judge 校准用 GEPA（arxiv 2507.19457，2025）： 迭代提出 judge prompt 修订，只保留在留出集上提升与人工标注一致率的版本 （GEPA 机制与"eval 作为优化目标"见第 E10 章；judge 校准全流程见第 E5 章）。

（4）generator-verifier gap：为什么 judge 模式可行。 DoorDash 仿真评测飞轮依赖一个经验事实： 判定比生成容易——LLM 裁判读全对话 + 工具调用 + 政策后给二元判定 + 理由， 比让模型从零生成完美服务要可靠得多；裁判再用人工标注样本校准到与专家一致后才上量。 这正是"LLM-as-a-Judge"在对话场景成立的前提（judge 的偏差与校准见第 E5 章）。

2.5 场景级 checklist rubric：低方差信号

仿真评测把"跑会话"变成了自动化，但"判会话"仍然是方差的主要来源。 DoorDash 的答案是把开放式目标翻译成场景级 checklist 式 rubric。

（1）实例：素食 taco 购物清单。 DoorDash 杂货购物场景的 rubric 例子： "两人份 ≤$60 素食 taco 购物清单"——judge 逐项验证：每件商品都是素食 taco 原料； 小计 ≤$60。对比两条路线：

这与第 E5 章的通用结论一致：judge 做二值判断比打连续分可靠； DoorDash 的每条标准都是 binary check，汇总为会话级总分。

（2）eligibility 适用性前置。 checklist 有一个隐蔽杀手：不适用的标准误伤会话。 DoorDash 的设计是 judge 先判该标准是否适用本会话，不适用则跳过—— 例如食谱流程不因缺少复购步骤被扣分。适用性判断与标准判定分开， 避免"标准越多、误伤越多"，也让 rubric 可以跨场景复用。

（3）与四层判分的对应。 checklist 主要落在 Outcome/Session 层； Guardrail 类标准（如"回复简洁、不向用户叙述思维过程""不呈现可证伪虚假信息"） 面向全体 agent 贯穿全流程。lab07 的极简 checklist——目标商品在清单里 / 总价≤预算 / 无编造商品——足以抓住超预算与编造商品两类失败，即使"用户"在对话里表示满意。

2.6 全量 sweep 的成本账与实验设计

（1）一笔明账（DoorDash 原文数字）。 仿真评测的经济性是它成为 CI 门禁的前提：

两个数量级的时间差，正是"回归集只增不减"（第 E10 章）在经济上成立的前提。 DoorDash 报告的整套成果数字：质量信号从平均 1 条/天员工反馈 → 2,000 个/天自动评分会话； 全国上线前 agent 质量分 +8 分、错误率近乎减半，达到生产发布标准； 11 轮迭代中第 3 轮曾回落——回归是常态，门禁的价值正是抓住它； 模拟环境幻觉率下降约 90%；离线提升与线上真实流量表现一致。 这套 harness 还支撑了底座模型迁移（Claude Sonnet 4.6 → Gemini 3.5 Flash）： 先被离线评测拦下（分数大跌），定位为兼容性差距而非能力差距，小修后 延迟降 35%、质量无损（案例全程见第 E15 章）。

（2）为什么是 8 trials。 每场景重复 N 次不是浪费，而是可靠性测量本身： N 次独立运行支撑 pass^k 估计（τ-bench 口径报 pass^1 与 pass^8）， 并吸收模型采样与模拟器行为的方差。实验设计要点：

• 固定模拟器与 seed：模拟用户的模型版本、温度固定，随机种子受控——模拟器是非确定性来源之一，其变异要么固定、要么用多 trial 吸收（统计处理见第 E9 章）；
• trial 间环境重置：fixture 保证外部状态一致，每条 trial 从干净状态启动；
• 报告统计口径：通过率带置信区间（Wilson/bootstrap），版本对比用配对检验—— 400 次对话的样本量下，多大的分差才算"真变好"是统计问题而非感觉问题（第 E9 章）。

（3）分层预算。 E2E 对话仿真位于评测金字塔顶层（单元 grader → 轨迹/结构测试 → E2E 模拟， arxiv 2601.18827，2026），是最贵的一层。落地节奏通常是：PR 触发 smoke 场景子集（少量场景 × 少 trial）

• 每日/每次模型变更跑全量 sweep + 高风险切片（欺诈、退款、人工接管）常设。 OpenAI 托管 Evals 平台的下线（2026 宣布）也提示：评测资产（场景 + fixture + rubric） 要用开放格式托管在自家仓库，与运行平台解耦（第 E10 章）。

2.7 模拟器的保真度与仿真评测的边界

仿真评测最大的风险不是技术故障，而是在假用户身上测出假结论。三个层次的清醒：

（1）模拟器 ≠ 真实用户。 模拟器与被测 agent 常用同族模型（同源偏差），可能互相"太好懂"； 合作型模拟高估、非合作型又可能过于刁钻；学界尚无公认的"模拟器保真度"标准指标。 DAUS（arxiv 2402.13374，2024，Amazon）直面了这个问题：未经微调的通用 LLM 当用户模拟器 不可靠——会偏离用户目标、幻觉出不存在的对话事实；DAUS 用领域数据微调 + 受控解码， 显著提升目标一致性（goal compliance）并抑制幻觉行为，使模拟对话更接近真实分布。 工程结论：用户模拟器本身需要被"评测与校准"——模拟器质量直接决定下游 agent 评测效度； 领域微调/对齐模拟器是工业级仿真评测流水线的常见投资。

（2）保真度抽检的常规动作。 没有单一指标能裁决保真度，工业界的务实做法是一组抽检：

（3）offline-online gap：离线是必要不充分。 学术侧的实证很直接： 真实客服对话基准研究（arxiv 2510.22143，2025）明确指出，由于部署环境的分布漂移与交互复杂性， 强 offline 基准成绩只是部署可靠性的弱指标。另一侧，Discord 的 AITL 数据飞轮 （EMNLP'25 工业赛道，ACL Anthology 2025.emnlp-industry.135）把 offline 与 online 评测设置之间的一致性当作专门对象来量化。 DoorDash 能报告"离线提升与线上一致"，前提是同一 rubric + 同一校准 judge 两边跑。 完整治理链路：离线门禁 → shadow → canary → A/B → 线上抽样评测， 阿里给了最硬的联动规则：离线提升但线上关键信号（转人工率、重复追问率、投诉率、满意度、 任务完成率、工单闭环率）恶化 → 触发回滚或降级（发布联动详见第 E12 章）。

（4）仿真评测系统自己也会坏。 DoorDash Lesson Learned 第四条： 评测系统自己也产生 bug 报告——被标记的失败中有真实一部分是 harness 自身故障 （judge 误报、trace 缺口），需要与业务 bug 并行修复。 所以成熟的仿真流水线都保留一条"harness 健康度"指标：A/A 噪声基线、 judge 与人工抽检的一致率漂移、fixture 失效率。评测系统本身也要被评测（主手册第 8 章同此观点）。

三、面试高频考点

四、经典面试题与参考答案

题 1（基础）：评测对话 Agent 和评测单轮问答有什么本质区别？为什么不能把每轮分数取平均当会话成功率？

参考答案： 单轮评测是"输入→输出→对照参考"，对话评测面对五个特殊难点（阿里归纳）： ① 上下文累积——关键信息跨轮分布、可能被后文覆盖；② 目标切换——用户中途改主意，一个会话多个子目标； ③ 情绪回应——答案对但语气差会升级为投诉；④ 人工接管——转接时机与交接质量本身要评； ⑤ 多轮引导——指挥用户操作比自己执行更难（τ²-bench 定量证明）。 不能平均的原因：每轮都"答得还行"但最终没解决问题仍是失败——Turn 层的礼貌流畅无法推出 Outcome 层的任务达成，用户绕八轮没退成款，平均每轮 4 分没有任何意义。 正确做法是四层分开看：Outcome 做最终裁决与门禁，Turn/Session/Trace 做归因与体验迭代，互不替代。

题 2（基础）：什么是 fixtures？为什么仿真评测环境必须冻结外部状态？

参考答案： fixtures 是把工具的真实返回录制成固定 payload，评测运行时拦截调用、原样回放。 原因：对话 Agent 背后的目录、库存、账号状态都在实时漂移，若评测时实时调用， 同一条用例每次测的是不同的题——分差可能全部来自环境而非 agent。 DoorDash 的教训原话是"环境必须受控，否则分数测量的是噪声"。 实例：复购场景开场 "Reorder my usuals"，get_reorder_items 固定返回录制的 reorder_history_v1（Albertsons 订单：Meadow Gold 全脂牛奶 ×2、Oroweat 全麦面包、 牛油果、Ben & Jerry's 冰淇淋），每次运行看到相同订单，预期结果可预测，judge 可对照同一商品集评分。 附带收益：fixtures 还能构造欺诈、大额退款等真实流量里罕见的难例，对冲幸存者偏差。 治理三件事：fixture 版本化、定期与生产 API 对账防 mock 漂移、用例间环境隔离。

题 3（进阶）：请设计一个用户模拟器的 scenario 结构。怎样让模拟用户的行为"像真人"而不是"念台词"？

参考答案： scenario 三要素（DoorDash 定义）：开场请求（模拟器的第一句话）、用户目标（含期望结果）、 反应策略（对提问/结果的反应方式）。persona 建议携带脾气、情境叙事、期望结果， 从真实工单抽取，或用隐式画像方法从真实日志反推（arxiv 2502.18968）。 行为真实性靠动态判断而非脚本：模拟器每轮回答四个问题——是否已解决、是否有进展、 是否需要更多信息、是否在绕圈——据此选择配合、补充、追问或升级。 升级行为要像真人：给过几次机会、反复答差才投诉，会反驳、逐步升级而非一上来就转人工（DoorDash）。 还要刻意包含非合作切片：用户不耐烦、跑题、表达模糊、中途改主意（ChatChecker，arxiv 2507.16792）， 因为合作型模拟会系统性高估 agent。配置应是数据不是代码——可序列化、可版本管理、非工程师可写。

题 4（进阶）：τ-bench 的评测范式由哪些组件构成？它的 pass^k 数字说明了什么？

参考答案： 四个组件：① LLM 用户模拟器与 agent 多轮对话；② agent 需遵守领域政策（retail/airline 业务规则） 并调用 API 工具；③ 以数据库终态哈希做可验证判定，而非只看对话文本——抗话术干扰； ④ 用 pass^k 刻画可靠性：单次通过率在多次独立试验下的一致性。 数字（论文摘要转述）：GPT-4o retail 域 pass^1 ≈60%（官方榜单 60.4%）、airline 域 ≈42%， 而 pass^8 跌至约 25% / 16%——"能做对一次"与"稳定做对"差距巨大， 因为对话每多一轮、误差复合一次。工程推论：生产级对话 Agent 应以 pass^k（低 k）作发布门槛， pass@1 只作能力上限参照；τ²-bench（arxiv 2506.07982）进一步把用户侧升级为能动手的"双控"， 最强模型双控成功率也远低于单控——引导用户操作比直接操作难得多。

题 5（进阶）：为什么 checklist 式 rubric 比宽泛标准更适合仿真评测？请举一个设计实例，并说明 eligibility 前置的作用。

参考答案： 宽泛标准（"购物清单是否合理"）人各有解，judge 判定方差高，需要大样本才看得出差异； checklist 把开放式目标拆成非真即假、可附证据的检查项，判定一致性高、方差低， 小样本也有用，支撑更快迭代，且失败时能定位到具体坏项。 实例（DoorDash 杂货场景）："两人份 ≤$60 素食 taco 购物清单"——逐项验证每件商品都是素食 taco 原料、 小计 ≤$60。每条标准都是 binary check，汇总为会话级总分。 eligibility 前置：judge 先判该标准是否适用本会话，不适用则跳过——食谱流程不因缺复购步骤被扣分。 没有这一步，标准越多误伤越多；有了它，rubric 才能跨场景复用。 延伸：判定要独立于对话氛围——编造商品的 agent 可能让模拟用户满意收尾， 所以结果检查必须查事实（商品真实性、价格），不能只问"用户是否满意"。

题 6（进阶）：用户模拟器本身也是 LLM。你如何验证它的可靠性，防止"在假用户身上测出假结论"？

参考答案： 先承认已知缺陷：DAUS（arxiv 2402.13374，Amazon）证明未经微调的通用 LLM 模拟器会偏离用户目标、 幻觉出不存在的对话事实；模拟器与被测 agent 同族时存在同源偏差，互相"太好懂"； 学界尚无公认的保真度标准指标。验证手段分四层： ① 模拟器自身指标：目标一致性（是否守住 persona 目标）、幻觉率（是否编造不存在的事实）， 必要时领域微调 + 受控解码（DAUS 路线）； ② 真实对话对照抽检：模拟会话与真实会话在轮次分布、升级率、失败模式上是否同构； ③ 敏感性分析：换一个模拟器模型重跑，若版本对比结论翻转，说明测的是"应付特定模拟器的技巧"； ④ offline-online 相关性回测：离线模拟涨幅是否在线上兑现，系统性不兑现就重建场景库。 组织上把模拟器当资产管理：persona 从真实日志持续挖掘更新（隐式画像/数据飞轮）， 合作/非合作/模糊/易怒等切片齐全，定期保真度抽检。

题 7（系统设计）：为一个外卖/零售客服对话 Agent 设计端到端仿真评测体系。

参考答案： 按"场景库—演员—舞台—判官—门禁—回流"六层设计： ① 场景库：scenario = 开场请求 + 用户目标 + 反应策略，persona 从真实工单抽取 （脾气、情境叙事、期望结果），覆盖复购、退款、投诉、目标切换、难缠用户等切片； 每条场景带 provenance 与 slice 标签，场景即数据、可版本管理。 ② 模拟器：LLM 扮演用户，动态判断解决/进展/缺信息/绕圈，升级像真人（给过机会才投诉）； 含非合作切片；固定模型版本与 seed。 ③ fixtures：录制工具返回冻结目录/库存/订单状态；专门构造欺诈、大额退款难例； fixture 版本化并定期与生产对账；用例间环境隔离。 ④ 判分：场景级 checklist rubric（binary check + eligibility 前置）+ 终态校验（订单/退款状态）； judge 逐条标准独立评分、输入为 transcript 证据切片 + 工具调用 + 政策，输出 verdict + rationale； judge 用人工标注校准（GEPA 打磨，一致率达标才进门禁）；评测镜像运行时架构——路由、护栏、领域能力分开评。 ⑤ 门禁与实验设计：全量 sweep = 场景 × 8 trials（支撑 pass^k 与方差吸收）， PR 跑 smoke 子集、每日与模型变更跑全量；通过率带置信区间，版本对比用配对检验。 ⑥ 回流：线上失败与 harness 自身故障（judge 误报、trace 缺口）分两条线修复； 同一 rubric + 同一 judge 跑线上抽样，离线升线上降触发回滚；失败场景回流为新 scenario。 成本锚点（DoorDash）：50 场景 × 8 trials = 400 对话，人工 6h+ → 模拟器约 20min； 上线前质量分 +8、错误率近乎减半、2,000 会话/天自动评分。

题 8（系统设计/开放）：你的对话 Agent 仿真评测全绿，但上线后转人工率与投诉率没降。给出你的排查框架与治理方案。

参考答案： 先定位差距来源，五个候选： ① 模拟器失真：合作型用户过多、persona 过时、模拟器与被测模型同源互相迎合—— 做真实对话对照抽检与换模拟器敏感性分析； ② rubric 与真实痛点错位：仿真测的是任务完成，投诉来自语气、等待、解释缺失、 结果对了但没告知（把线上投诉做归因分类，反查评测盲区）； ③ 环境保真度不足：fixture 与生产漂移、线上才有的真实数据形态（超长订单、多语言）没覆盖—— fixture 对账 + 用线上真实会话补场景； ④ offline-online 口径分裂：离线线上两套 judge 或两套 rubric——统一为同一 rubric + 同一校准 judge （DoorDash 原则三：各自调 judge 分数会难调和地背离）； ⑤ 分布漂移：评测集停留在旧分布——对比线上抽样与场景库分布做覆盖度审计。 理论锚点：arxiv 2510.22143 明确强 offline 成绩只是部署可靠性的弱指标； 阿里联动规则最硬：离线提升但线上关键信号恶化 → 回滚或降级。 治理上把仿真定位成"必要不充分"：离线门禁之外保留 shadow/canary 第二道闸， 线上抽样用同一 rubric 持续评分，offline-online 相关性定期回测，不兑现即重建场景库。

五、易错点 · 反直觉点

1. 把每轮分数平均当会话成功率：每轮都礼貌流畅，用户绕八轮没解决问题仍是失败。 → 真相：Outcome 层才是最终裁决，Turn 分只做诊断。→ 记忆锚点：平均分会奖励"礼貌地不作为"。
2. 用历史会话重放测新版本：以为录像回放最真实，实际 agent 一变更，对话路径完全不同，重放测的不是同一个交互。 → 真相：DoorDash 的结论是"按需生成会话"，模拟器驱动 agent 现场跑场景。→ 记忆锚点：重放测的是旧 agent 的过去，不是新 agent 的未来。
3. 评测时实时调用外部 API：目录在变、库存在变、账号在漂移，同一条用例每次测的是不同的题。 → 真相：fixtures 冻结外部状态，分数差异才能归因于 agent。→ 记忆锚点：环境不受控时，分数测量的是噪声。
4. 模拟用户太合作：礼貌、信息完备、轻易满意的模拟器，把 agent 测出礼貌的假高分。 → 真相：合作型模拟系统性高估；场景库必须有不耐烦、跑题、改主意的非合作切片（ChatChecker）。→ 记忆锚点：假用户不会投诉，假分数不会说谎——只会骗你。
5. 模拟器与被测 agent 同源：同族模型互相"太好懂"，评测变成自家人对暗号。 → 真相：同源偏差需靠换模拟器敏感性分析与真实对话抽检对冲；模拟器质量直接决定评测效度（DAUS）。→ 记忆锚点：裁判、模拟器、被测者，三角关系越独立越可信。
6. fixture 写完不维护：上游 schema 变了、字段语义变了，fixture 还停在旧世界，评测全绿、上线即炸。 → 真相：fixture 要版本化、定期与生产 API 对账（mock drift 治理）。→ 记忆锚点：冻结的是状态，不是维护责任。
7. 只报 pass@1 不报 trial 设计：单次成功率 61% 听起来不错，τ-bench 里 GPT-4o 的 pass^8 只有约 25%。 → 真相：对话/客服类生产场景必须报 pass^k 与试验次数，能力上限与可靠性分开报告。→ 记忆锚点：能做对一次 ≠ 稳定做对。
8. 只看"用户是否满意"判成功：编造商品的 agent 可以让模拟用户满意收尾。 → 真相：结果判定要独立于对话氛围——查事实（商品真实性、价格、终态），满意度只是 P2 观察项。→ 记忆锚点：满意可以被话术制造，终态不会撒谎。
9. 把仿真当终点：离线模拟全绿就直接全量上线。 → 真相：强 offline 成绩只是部署可靠性的弱指标（arxiv 2510.22143）；仿真之后还有 shadow/canary 与线上同 rubric 抽检，离线升线上降要敢回滚。→ 记忆锚点：仿真是排练场，不是公演。
10. 忽略 harness 自身故障：失败列表里全是"agent 的错"。 → 真相：被标记失败中有真实一部分是评测系统自己的 bug（judge 误报、trace 缺口），要并行修复（DoorDash Lesson 4）。→ 记忆锚点：秤不准时，先修秤再称象。

六、推荐资源

核心论文（arxiv ID 均来自本特辑 _research/06-edd-simulation.md 调研，已核实）

1. τ-bench（Sierra，2024）：对话 Agent 仿真评测的范式源头——LLM 用户模拟器 + 政策遵守 + DB 终态哈希 + pass^k。 https://arxiv.org/abs/2406.12045
2. τ²-bench（Sierra，2025）：双控环境，用户侧也能执行工具动作；"引导比代办难"的定量证据。 https://arxiv.org/abs/2506.07982
3. DAUS: Reliable LLM-based User Simulator for Task-Oriented Dialogue Systems（Amazon，2024）： 模拟器自身的可靠性问题——目标一致性与幻觉，领域微调 + 受控解码。 https://arxiv.org/abs/2402.13374
4. Know You First and Be You Better: Modeling Human-Like User Simulators via Implicit Profiles（2025）： 从真实日志挖掘隐式用户画像驱动模拟器。 https://arxiv.org/abs/2502.18968
5. ChatChecker: Dialogue System Testing Through Non-cooperative User Simulation（2025）： 非合作模拟 + Breakdown Detector + Dialogue Rater。 https://arxiv.org/abs/2507.16792
6. Benchmarking and Learning Real-World Customer Service Dialogue（2025）： offline-online gap 实证——强离线基准只是部署可靠性的弱指标。 https://arxiv.org/abs/2510.22143
7. Gromada et al., Evaluating Conversational Agents with Persona-driven User Simulations （EMNLP 2025 工业赛道，销售 bot 案例；无 arxiv 版本）：persona 切片 × 业务 KPI（转化、升级率）的评测组织方式。 https://aclanthology.org/2025.emnlp-industry.16/
8. Agent-in-the-Loop（Discord，EMNLP 2025 工业赛道）：数据飞轮与 offline-online 一致性的量化样本。 https://aclanthology.org/2025.emnlp-industry.135/
9. 延伸阅读：PersonaBOT（RAG 增强 persona 模拟器，https://arxiv.org/abs/2505.17156）； WildChat 1M 真实交互日志（https://arxiv.org/abs/2405.01470）； LMSYS-Chat-1M（https://arxiv.org/abs/2309.11998）； Generative Agents（LLM 模拟人类行为的奠基，https://arxiv.org/abs/2304.03442）； 10 亿 persona 规模化合成（Tencent 参与，https://arxiv.org/abs/2406.20094）； From Simulation to Strategy（模拟器→策略规划闭环，https://arxiv.org/abs/2510.08621）。

工业博客与文档

• DoorDash《Building Ask DoorDash (Part 3): Evaluation》（2026-06-30）：五大挑战表、 Conversation Simulator、fixtures、checklist rubric、GEPA 校准——本章 DoorDash 细节的第一来源。
• DoorDash《A Simulation and Evaluation Flywheel to Develop LLM Chatbots at Scale》（2026-01-26）： 模拟器 persona 从真实工单抽取、mock 后端构造欺诈难例、200+ 对话/5 分钟、幻觉率降约 90%。
• Anthropic《Demystifying evals for AI agents》（2026-01）：起步 20–50 个真实用例、pass@k/pass^k、 capability/regression 双套件（与第 E10 章对读）。

动手 labs

• labs/eval_lab07_simulator_fixtures.py（本章配套）：状态机驱动的模拟用户 + fixtures 拦截回放 + 漂移对照组方差实验 + checklist rubric。运行：cd evals-special/labs && python3 eval_lab07_simulator_fixtures.py
• labs/eval_lab06_trajectory_eval.py：轨迹三层评估与"结果对但路径错"的假阳性捕获（配合 2.1 四层判分）。
• labs/eval_lab08_statistics_ci.py：多 trial 通过率如何报置信区间与显著性（配合 2.6 实验设计）。

章节交叉

• 第 E5 章 · LLM-as-Judge 深入：judge 的偏差、校准与 GEPA 全流程。
• 第 E7 章 · 轨迹与 Agent 级评估：Transcript Builder 证据切片、评测镜像运行时架构。
• 第 E9 章 · 评估的统计学基础：pass^k 的估计、样本量与版本对比显著性。
• 第 E10 章 · 评测驱动开发（EDD）：仿真评测在 EDD 闭环中的位置与失败回流。
• 第 E12 章 · 在线评估与数据飞轮：离线-线上一把尺子、发布联动与回流。
• 第 E15 章 · 工业实践案例研究：DoorDash 案例全文（含 reasoning leakage 与模型迁移两案）。
• 主手册第 8 章 · Agent 评估与可观测性：评估环境与可复现性的通识基础（本章是其深挖）。

评估的统计学基础

一句话导读：「v2 通过率 85%，比 v1 的 82% 高，可以发布」——这句话缺了三个限定词：85% 的误差范围有多大、3 个点的差距能否与噪声区分、多大的差距才值得一次发布。本章把评测分数装进统计学的骨架：单个分数用 Wilson 区间与 bootstrap 给出误差条；评测规模用样本量公式在跑之前算清楚；版本对比用配对设计与最小可感知变化（MPP）判定真伪；pass@k/pass^k 用无偏估计量与重复实验设计报数；竞技场排名用 Bradley-Terry、tie 建模与风格控制回归。学完本章，你能现场手算 CI 与样本量，能回答一切「这个分数可信吗」类的面试题——这也是评测岗笔试计算题的全部题源。

一、知识图谱

评估的统计学基础
│
├─ 1. 基本立场：评测 = 小样本统计推断
│   ├─ 分数是统计量（随机变量），不是真值
│   └─ 五大方差来源：采样 / temperature=0 非确定性 / prompt 措辞 / judge / 题目抽样
│
├─ 2. 区间估计（给单个分数装误差条）
│   ├─ 二项比例：Wald 区间的两个致命伤 → Wilson score interval（默认）
│   ├─ Bootstrap：任意统计量的无公式误差条（重抽样单元 = 评测单元）
│   └─ 覆盖率：评判 CI 好坏的唯一硬指标
│
├─ 3. 样本量与功效（评测之前定规模）
│   ├─ 估精度：n ≥ z²p(1−p)/ε²（±2pp ⇒ ~2400 题；±1pp ⇒ ~9600 题）
│   ├─ 比版本：n ∝ 1/δ²（检出 5pp ≈ 1000 条/组；3pp ≈ 2800 条/组）
│   ├─ 先导法：ReliableEval 矩方法反解 n（2505.22169）
│   └─ 为什么 100 条 golden set 只是起点不是终点
│
├─ 4. 版本对比（差异是真是假）
│   ├─ 配对设计：同一题集 + McNemar / 配对 bootstrap
│   ├─ 直接 bootstrap「分差」，不要肉眼比两个 CI 是否重叠
│   └─ 阿里门禁三件套：置信区间 + 显著性 + 最小可感知变化（MPP）
│
├─ 5. pass@k / pass^k 的统计学
│   ├─ 无偏估计量 1 − C(n−c,k)/C(n,k)（HumanEval，2107.03374）
│   ├─ 小 n 方差爆炸与 Beta 后验替代（2510.04265）
│   ├─ pass^k：iid 假设下 ≈ p^k；τ-bench 实测 60%→25% 不可外推（2406.12045）
│   └─ 重复设计：N=3/5/8/10 取舍；repetitions ≥3 是底线
│
├─ 6. 竞技场方法论（成对比较的统计学）
│   ├─ Bradley-Terry MLE vs 增量 Elo：顺序无关性是切换的根本原因
│   ├─ Tie 建模：丢弃/半分都有偏 → Davidson / factored tie（2412.18407）
│   ├─ Bootstrap CI（典型宽 5–15 Elo）与分差检验
│   ├─ 风格控制回归（2404.04475 / Arena style control / Arena-Hard 2406.11939）
│   └─ 脆弱性：丢票敏感（2508.11847）与投票操纵（2501.17858）
│
├─ 7. 噪声与可复现
│   ├─ temperature=0 + seed 仍非确定（2410.03492）
│   ├─ 重复 3–5 次 + 聚合，排名翻转率显著下降（2509.24086）
│   └─ judge 报告规范：偏差校正 + CI（2511.21140）；judge 样本效率下界（2410.13341）
│
└─ 8. 面试计算工具箱（第四节题源）
    └─ 算 CI / 反解样本量 / 配对检验 / pass^k 外推 / Elo-BT 换算

30 秒抓住主线：评测是用几十到几千道题的样本，推断模型在全体任务分布上的表现——这是一个统计推断问题，不是算术问题。于是有三个必须回答的问题：① 单个分数的误差多大（2.2–2.3）；② 多少样本才够（2.4）；③ 两个分数的差异是真是假（2.5）。在此之上，pass@k/pass^k 有自己的估计陷阱（2.6），竞技场排名自成一套配对比较统计学（2.7），而一切结论的前提是控制住噪声来源（2.8）。2024 年之前业界普遍把跑分当成确定性点估计；2024 年起，置信区间、重复实验、显著性检验成为严肃评测报告的标配——这条演进主线贯穿本章所有论文引用。

二、核心概念精讲

2.1 评测是小样本统计推断：点估计、区间估计与五大方差来源

LLM 评测的本质：用几十到几千道题的样本，去推断模型在「全体可能任务分布」上的能力，并据此排序、做 A/B 决策。样本有限，所以任何评测分数都是一个统计量（随机变量）而不是真值——换一批题、换一次运行、换一个 judge，分数都会变。2024–2026 评测统计学的主线，就是「从点估计走向分布推断」。

一个分数至少由五个随机源共同塑造（汇总自 2410.03492、2509.24086、2505.22169 的方差来源分析）：

推论一：没有误差条的分数在评审中应当被质疑——这是全章最低成本、最高收益的纪律。 推论二：发布评测结论前，把上表过一遍，至少固定并记录其中可控项（种子、温度、judge 版本、题目集快照）。

动手：用固定种子做 1000 次模拟实验，亲眼验证「声称 95% 的区间是否真的覆盖真值约 95%」—— cd evals-special/labs && python3 eval_lab08_statistics_ci.py

2.2 通过率的置信区间：Wald 的陷阱与 Wilson score interval

通过率 p̂ = X/n（n 条用例中 X 条通过）是最基础的评测指标，也是二项比例。它的标准误约为 √(p(1−p)/n)——n=100、p≈0.83 时约 3.7 个点，95% 区间约 ±7.4 个点。这就是「100 条评测集上 2–3 个点的差异看不出任何东西」的数学根源。

最朴素的区间是 Wald 区间：p̂ ± z·√(p̂(1−p̂)/n)（95% 时 z=1.96）。公式好记，但有两个致命伤：

1. 端点越界：n=20、全部失败（p̂=0）时，Wald 给出区间 [0, 0]——声称「真实通过率精确等于 0」，荒谬；真实上界按「三三法则」约为 3/n ≈ 15%。p̂=1 时同理给出 [1, 1]。
2. 覆盖率不足：小样本或极端比例下，声称 95% 的 Wald 区间实际覆盖率远低于 95%，是「假安全感」。

Wilson score interval（得分区间）是报告二项比例的默认选择：

z = 1.96（95% 置信水平）

              p̂ + z²/(2n)  ±  z·√( p̂(1−p̂)/n + z²/(4n²) )
Wilson 上下限 = ────────────────────────────────────────────
                       1 + z²/n

三个直觉帮你记住它：

• 它是「反转得分检验」的产物：把所有「与观测 p̂ 不矛盾的 p₀」收集起来就是区间，构造方式天然比 Wald 的「以 p̂ 为中心对称外扩」更合理；
• 它做了收缩：区间中心不是 p̂，而是 p̂ 向 1/2 的加权平均（权重 z²/n），n 越小收缩越强——这正是小样本需要的保守；
• 端点永远落在 [0,1] 内，且小样本下覆盖率接近名义水平。

同一数据两种区间的对比：

覆盖率（coverage）是评判 CI 好坏的唯一硬指标：重复做实验，区间盖住真值的频率。95% 是声明，覆盖率模拟才是验证（lab08 用固定种子模拟 1000 次，断言 Wilson 覆盖率落在 [0.92, 0.98]）。

2.3 Bootstrap：任意统计量的无公式误差条

Wilson 只解决「单个比例」。评测里还有中位数延迟、pass^k、BT 分数、胜率差……这些没有好用的闭式区间，通用解法是 bootstrap：

重复 B 次（B = 500 ~ 1000）：
    从原始评测单元中【有放回】重抽样出同规模样本
    在重抽样集上重算统计量（准确率 / BT 分数 / 两模型分差 / ……）
取 B 个统计量的 2.5% 与 97.5% 分位数 → 95% CI

三个使用要点，全是面试追问点：

bootstrap vs 公式法怎么选：二项比例优先 Wilson（稳定、无模拟误差、可复现）；任何非比例统计量、或分布假设不放心时用 bootstrap；两者都不可行（样本极少、强依赖结构）再考虑 Beta 后验等贝叶斯方法（2510.04265、2504.21303）。bootstrap 也是配对比较显著性检验的方法学源头之一（NLP 经典的配对 bootstrap 检验，Koehn 2004）。

2.4 样本量计算：多少题才够

评测集规模不该拍脑袋，它由「你要多高的分辨率」反解出来。分两类问题。

问题一：估计单个通过率，要 ±ε 的精度需要多少题？

n ≥ z² · p(1−p) / ε²        （z=1.96 对应 95%；p 未知时取最坏情况 p=0.5）

速查表（95% 置信水平）：

（±2pp 需 ~2400 题、±1pp 需 ~9600 题与调研素材一致。）这解释了两个业界现象：① 把精度做细极其昂贵——从 ±2pp 到 ±1pp 样本量翻两番（n ∝ 1/ε²）；② 30 题的竞赛集（如 AIME 类）半宽约 ±18pp，在统计上根本无法区分前沿模型——业界经验法则是 ~1000 题起步才有基本功效。

问题二：比较两个版本，要检出 δ 的差异需要多少题？

双比例比较（双侧 α=0.05，功效 1−β=0.8，z_β=0.84）：

每组 n ≈ (z_{α/2} + z_β)² · 2·p̄(1−p̄) / δ²     （p̄ = (p₁+p₂)/2；加连续性修正再上浮 10–20%）

基线 80% 时的速查表（与第 E2 章门禁口径一致）：

1/δ² 定律是评测经济学的第一性原理：想检出的差异减半，评测预算翻两番。「感觉够了」通常远不够——区分两个真实胜率只差 1% 的模型，需要数千次成对比较。

为什么 100 条 golden set 是行业常见起点（阿里 50–200 条、Airbnb 50–100 条）？四个理由：

1. 精度匹配门禁语义：n=100 时通过率 CI 半宽约 ±8pp，足以区分「82% vs 90% 门槛」这类大差距——门禁要的是拦截明显劣化，不是测微差；
2. 迭代速度：100 条在分钟级跑完，支撑「一次一变量」的高频迭代（第 E10 章）；
3. 人工可审：Airbnb 的「100 样本人工精读法」要求专家读得完每一条输出与 trace；
4. 成本可控：agent 级评测单条成本高，100 条 × N 次重复才在预算内。

但要清楚它的边界：n=100 只能检出 ~8pp 以上的差异；需要分辨 3pp 就得扩到 ~2800 条（配对设计可显著更少），或接受「小提升不值得发布」的 MPP 设定（2.5）。起点与终点之间，用样本量公式显式做预算。

先导法（把拍脑袋变成实验+公式）：ReliableEval（2505.22169，EMNLP 2025 Findings）针对「评测对 prompt 措辞高度敏感」提出随机化评测——对一个题目生成大量语义保持的 prompt 扰动，把评测对象从单点 prompt 扩展为 prompt 分布；再用矩方法从先导样本估计分数方差 σ̂²，反解所需样本数：

n ≥ ( z_{α/2} · σ̂ / ε )²

落地姿势：先用 10% 预算跑先导集估方差，再决定全量规模。该框架在 GPT-4o、Claude-3.7-Sonnet 等 5 个前沿模型上验证：即使最强模型也存在显著 prompt 敏感性；对高方差任务（开放生成、多轮 agent）尤其必要。

2.5 版本对比的显著性：配对设计与阿里门禁三件套

「v1 82%，v2 85%，v2 更好？」——先看设计，再看检验。

配对设计优于独立设计，原因是评测里最大的噪声源是题目难度差异，而不是模型差异：

配对数据的标准检验是 McNemar 检验：把每题的两版本判定整理成 2×2 表，只看不一致的题——A 对 B 错（b 题）与 A 错 B 对（c 题）：

χ² = (|b − c| − 1)² / (b + c)      （df=1；χ² ≥ 3.84 即 α=0.05 显著）

直觉：两版本都做对/都做错的题对「谁更好」毫无信息量；全部信息集中在不一致的题上。等价地，也可以对「逐题分差」做配对 bootstrap，取差值 CI 看是否盖住 0。不要用两独立比例的 z 检验——那是独立设计的工具，用在配对数据上既浪费信息又可能错。

手算示例（面试计算题常见形态）：n=100 配对，两版本都做对 70 题、A 对 B 错 8 题、A 错 B 对 14 题、都做错 8 题。裸通过率 A=78%、B=84%，「B 高 6 个点」；但 McNemar 只看翻转：χ²=(|8−14|−1)²/(8+14)=25/22≈1.14 < 3.84，不显著——6pp 的裸差距里，不一致样本太少、方向性不够强，证据不足以支持「B 更好」。这个例子说明配对检验的判据是翻转样本的数量与方向比，而不是裸分差。

阿里门禁三件套。阿里对版本对比的统计口径要求（原文表述）：

「门禁不只看差了多少，还要看差异是否超过统计噪声。」

落到纸面是三件事缺一不可：

1. 置信区间：关键指标报告区间（比例用 Wilson，其余用 bootstrap），不报 CI 的点估计视为噪声；
2. 显著性判断：与基线做配对检验，差异要能被证明不是抽样波动；
3. 最小可感知变化（MPP）：提前定义「提升多少才值得发布」。统计上能检出 0.5pp，不等于 0.5pp 值得一次发布风险——MPP 把「值不值」从统计问题还原为业务决策。

工作示例（lab08 完整复现了这个实验）：

同一个 3pp，样本量 20 倍之差，结论从「不能发布」变成「可以发布」。这就是门禁统计口径的意义：不是卡流程，而是把「信不信这个差异」变成可计算的量。

两个补充纪律：① 门禁同时看多个指标时，先指定一个主指标，其余按层级决策——m 个指标各自按 95% 单独判定，至少一项误报的概率是 1−0.95^m，会随指标数膨胀；② 显著性是「有没有差异」，MPP 是「值不值得」，两者都过才放行（见易错点 3）。

2.6 pass@k 与 pass^k 的统计学：估计、方差与重复实验设计

pass@k 的无偏估计量（HumanEval，2107.03374，OpenAI 2021）：每题采样 n 个解、c 个通过，则

pass@k = 1 − C(n−c, k) / C(n, k)

它是「从 n 个解里无放回抽 k 个、至少一个通过」的组合概率，避免了「先抽 k 个再看是否通过」的点估计偏差。例：n=10、c=3 时，pass@1 = 0.3（与 c/n 一致），但 pass@2 = 1 − C(7,2)/C(10,2) = 53.3%——明显高于朴素的「30% × 2」。

pass@k 点估计的统计缺陷（2510.04265 的系统批判）：

• 每题样本数 n 常常很小（许多新 benchmark n=1~20），n<20 时 pass@k 点估计方差极大；
• 不同 n、不同题目难度混合下的 pass@1 完全不可比——横向对比必须统一 n；
• 替代方案：把每题通过率 p 视为随机变量，用 Beta 后验（如 Beta(c+1, n−c+1)）刻画并聚合时传播不确定性，输出能力的后验分布而非单点分数；低样本设置下排序稳定性显著更好。
• 务实共识：保留 pass@k 但必须附带 n 与 CI（bootstrap 或 Beta 近似），或同时报告低方差的平均通过率 avg@k。

pass^k：鲁棒性指标。pass^k = 同一任务独立运行 k 次全部成功的比例（τ-bench 2406.12045 系统提出，2024）。若各次尝试独立同分布、单任务成功率 p，则 pass^k ≈ p^k——衰减速度远超直觉：

但不能拿 (平均 pass@1)^k 外推 pass^k。τ-bench 的实测数字（论文摘要转述口径）：GPT-4o 在 retail 域 pass^1 ≈60%（官方榜单 60.4%），而 pass^8 ≈25%（摘要 <25%）——若按 iid 外推，0.60^8 ≈ 1.7%，与实测差出一个量级。原因有二：① 任务难度异质（部分任务几乎每次都对、部分几乎每次都错，pass^k 由「稳定会做的题」决定）；② 各次尝试正相关（同类错误反复出现）。反过来，若系统存在上下文污染、残留状态、下游限流等破坏独立性的因素，实测 pass^k 也可能更差。结论：pass^k 必须实测，不能外推；报告时同时给 pass@1 与 pass^k，两者的差距就是系统方差的直接度量。工程惯例 k 取 4–8，τ-bench 的 k=8 成为行业标杆。

重复实验设计：N=3/5/8/10 怎么取舍

两条依据：其一，单次运行的排名翻转概率不可忽略——在典型 benchmark 规模下，3–5 次重复 + 聚合能显著降低翻转率（2509.24086），这与 2410.03492、2504.07086 相互印证：重复次数是评测预算里性价比最高的一项，比重跑新 benchmark 便宜得多，却能直接消除排名噪声；其二，对 agent 这类高方差任务，预算应分配给「重复次数 + prompt 扰动」，而不是只堆新题目。内部评测平台的合理默认：num_repeats ≥ 3，报告均值 ± 区间。

动手：模拟 N 任务 × K 次重复的 agent 结果矩阵，亲眼看 pass@k 与 pass^k 随 K 分道扬镳—— cd evals-special/labs && python3 eval_lab01_metric_system.py

2.7 竞技场方法论：Bradley-Terry、tie 建模、bootstrap CI 与风格控制

Chatbot Arena 把偏好评测从「固定 benchmark」变成「众包配对比较」，也随之引入一整组统计问题：多少投票才够？分差多少算真？平局怎么办？风格偏好算不算偏差？这套方法论由四篇工作奠基（2403.04132、2412.18407、2406.11939、2404.04475）。

Bradley-Terry vs Elo。对每场对局 (i, j)，BT 模型把胜率建模为潜在强度之比：

P(i 胜 j) = γᵢ / (γᵢ + γⱼ)，γ > 0

用全部对局做极大似然估计（通常加先验/锚点约束防漂移），再换算到 Elo 尺度：Elo_i = 400·log10(γᵢ/γ_anchor) + Elo_anchor。而 Elo 是在线增量更新：Elo_i ← Elo_i + K·(outcome − expected)，期望胜率 = 1/(1+10^(−ΔR/400))。两者是同一概率模型的两种算法：

这就是 2024 年各家排行榜从 Elo 切换到 BT 的根本原因：Elo 只是 BT 的一种粗糙在线近似。Chatbot Arena（2403.04132，ICML 2024）论文发表时已有 240K+ 投票、90K+ 用户、50+ 模型，其最终方案就是 BT 评分 + bootstrap 置信区间（对投票数据有放回重抽样、重新拟合 BT、取分位数得 95% CI），BT 分数的 bootstrap CI 通常宽 5–15 Elo 分——媒体常把 2–5 分的差距宣称为「超越」，而这样的差距经常落在 CI 重叠区内。

Tie 不能丢。Arena 投票中约一成以上是平局，标准 BT 不支持 tie，三种处理方式的对比：

2412.18407 是竞技场方法论从工程实践到统计学的正式化。自建竞技场/内部偏好评测平台时，这是最值得直接抄的作业：BT MLE 替代增量 Elo；显式建模 tie；相邻排名的分差必须经联合协方差检验才能宣称显著。

排名有多脆弱？两项攻击性研究给出警告：

风格控制回归（style control）。LLM judge 系统性偏好更长的回答，导致「把模型调啰嗦」就能刷分（verbosity hacking）。Length-Controlled AlpacaEval（2404.04475）的解法是回归去偏：

偏好 vote ~ β₀ + β₁·model + β₂·length + β₃·markdown + …

用逻辑回归拟合偏好后，把所有回答的长度等风格变量固定在参考值（如全体均值）时计算期望胜率（G-computation / 回归调整思想），得到 length-controlled win rate。效果：与 Chatbot Arena 的 Spearman 相关性从 0.94 提升到 0.98；verbosity 操纵带来的胜率增益从约 12% 压缩到约 3%。Chatbot Arena 随后引入 style control（多元逻辑回归控制长度、markdown 格式等混淆变量，见 LMSYS 2024-08 博客），并同时发布 overall 与 style-controlled 两个榜单——这等于承认「风格偏好是偏差还是真实用户偏好」取决于你要回答什么问题（学界争议，见 2.8 与第 E13 章）。Arena-Hard（2406.11939，ICML 2025）的 v2 同样引入 style control，其完整配方是「竞技场分布蒸馏 + 强 judge 成对比较 + BT 分数」：从 Arena 真实投票与 WildChat 中聚类蒸馏出 500 道高区分度题目（Arena-Hard-Auto），用强模型 judge 对候选模型 vs 基座模型做成对比较，再用 BT 把胜率升级成可比较的分数——与 Chatbot Arena 人类排名相关性 98.6%，区分度约为 MT-Bench 的 3 倍，成本 <$20。这是「离线自动评测对齐在线竞技场」的模板，其「固定一个参考模型、报告 BT 分数而非裸胜率」的做法被大量内部 eval 系统模仿。

工程结论：任何怀疑输出表面特征（长度、格式、emoji、代码块数量）与质量混淆的 judge 评测，都应做混淆变量回归检查——方法只是一个逻辑回归，却能把抗操纵性提升一个量级。

动手：纯标准库实现 BT 极大似然 + Elo + bootstrap 分差 CI + 风格控制，看朴素 BT 如何「把长当强」、修正后如何恢复真实排序—— cd evals-special/labs && python3 eval_lab11_arena_bradley_terry.py

2.8 噪声与可复现：方差清单、重复实验与 judge 报告规范

「temperature=0 + 固定 seed 所以结果确定」是常见误解。图灵研究所的实证研究（2410.03492）核心结论：即使 temperature=0 + 固定随机种子，模型输出仍可能不确定——批处理效应、底层 kernel、量化的非确定性都会让单次跑分不可复现。该工作还系统研究了重复次数、benchmark 规模、温度对分数均值与预测区间的影响，并提出低成本的分数不确定性量化方法（子集重抽样/重复实验的稀疏设计），让「给分数加误差条」不再昂贵。

可复现性控制清单（方差来源 → 动作）：

重复实验的量化依据（2509.24086，与 2410.03492、2504.07086 互证）：典型 benchmark 规模下，单次运行的排名翻转概率不可忽略；3–5 次重复 + 均值/中位数聚合能显著降低翻转率。延伸阅读中，2504.07086 主张 bootstrap 多次运行取均值来评估推理模型的进步；2512.07795 提出「Run Noise」指标专门分离重复运行的随机性；2502.05234 分析温度与多次采样聚合的方差权衡。争议的本质是成本：重复 3 次意味着 3 倍推理预算，对动辄数千美元的 agent 评测尤甚——但对比「基于单次运行做出错误发布决策」的代价，这通常是最便宜的一笔保险。

judge 评测的统计报告规范（详见第 E5 章，此处给统计学骨架）：

观测 judge 分数 = 真实分数 + judge 偏差(bias) + judge 噪声(variance)

How to Correctly Report LLM-as-a-Judge Evaluations（2511.21140）指出：直接报告 judge 原始准确率/胜率会混入偏差与噪声，不同 judge 的分数不可直接比较；应使用偏差校正估计量——用一个小规模人工标注校准集（几百条）估计 judge 的混淆结构/偏差，对被评模型的真实胜率做校正，并构造 CI。judge 升级/换型后偏差参数需重估；多 judge 面板的收益取决于 judge 间错误相关性（相关错误不随面板规模下降）。同时记住理论下界（2410.13341，ICLR 2025）：在前沿任务上 judge 评测的误差随样本量下降存在理论极限，靠 judge 做评测最多相当于「把人类标注数据翻倍」的收益量级——judge 适合扩大覆盖，不能替代高质量人工校准集；前沿模型的评测必须保留人工锚点（第 E6 章）。阿里口径与此一致：judge 与人工复核一致率约 85%（参考值）后才进日常自动化，且每次 judge 升级固定产出「与人工一致性 / 高风险漏判率 / 边界样本稳定性」三项统计。

报告纪律汇总（评测报告的最小检查表）：

1. 一切分数带 CI：二项比例用 Wilson；成对胜率/排名用 bootstrap（按评测单元重抽样，B≥500）；
2. 版本比较用配对设计（McNemar 或配对 bootstrap），不用两个独立点估计的肉眼对比；
3. pass@k 必须报 n，统一各模型的采样预算；题目少时用 Beta 后验区间；
4. 重复 ≥3 次，报告均值 ± 区间；temperature=0 + seed 也要重复；
5. 样本量在评测前用公式/先导实验规划，而不是跑完再看；
6. 竞技场式排名用 BT MLE + tie 模型 + 均衡比较图 + style control；
7. judge 分数报告偏差校正后的值与 CI，附 judge 版本与校准集状态；
8. CI 重叠的排名视为统计上不可区分，向业务方给「不可区分组」而非精确名次。

面试计算速查表（第四节计算题的公式都在这里）：

三、面试高频考点