模块 12 — 评估与可观测性 (Evaluation & Observability)

📚 重要英语词汇：模块 12 词汇表

定位：模块 10 讲了怎么把 Claude 应用「部署上线」，模块 11 讲了怎么让它「不被攻破」。本模块回答最后两个生产级问题：你怎么知道它好不好（评估 Evaluation）？你怎么知道它现在好不好（可观测性 Observability）？ 没有评估的团队会陷入官方描述的反应式循环 (reactive loop)：等问题爆到用户面前，修一个坏一个，分不清真回归还是噪声；有了评估 (Evals) + 金标数据集 (Golden Dataset) + 回归测试 (Regression Testing) + 线上监控，质量才从「感觉」变成「数字」。这是 Claude 架构师把 demo 变成生产系统的最后一公里。

0. 学习目标

🎯 学习重点：考试主线是“成功标准→评估任务→评分器→CI 门禁→线上监控→失败回流”闭环。

读完本模块你应能：

1. 说清一次评估 (Evaluation) 的解剖结构：input / output / 金标答案 (Golden Answer) / score，以及 agent 语境下的 task / trial / grader / transcript / outcome / harness。
2. 按任务选择三类评分器：代码评分 (Code-based Grading)、LLM 评审 (LLM-as-Judge / Model-based Grading)、人工评分 (Human Grading)，并知道官方推荐顺序与校准方法。
3. 从零构建金标数据集 (Golden Dataset)：题目从哪来、怎么写无歧义任务、怎么配参考解 (Reference Solution)、怎么防类不平衡 (Class Imbalance) 与评测集饱和 (Eval Saturation)。
4. 建立分层指标体系：任务成功率 (Task Success Rate)、工具正确性 (Tool Correctness)、答案正确性 (Answer Correctness)、接地性 (Groundedness)、幻觉评估 (Hallucination Evaluation)，以及检索层的 recall@k / precision@k / MRR / nDCG（呼应模块 07）。
5. 区分 capability evals 与 regression evals，用 pass@k / pass^k 处理非确定性。
6. 设计延迟与成本监控：TTFT、每任务成本、token 预算，并接入官方 Usage & Cost API 与可观测性平台。
7. 设计线上监控与告警闭环：drift 检测、采样人审、逃逸指标（用户改写率、人工接管率），并与离线评估形成互补。

1. 为什么评估是生产化的地基

🎯 学习重点：没有基线就无法区分真实回归与随机噪声，也无法安全比较模型、prompt 或工具改动。

官方工程博客《Demystifying evals for AI agents》描述了没有评估的团队的标准轨迹：原型期靠手动测试、dogfooding 和直觉「出人意料地走得远」，可一旦上了生产、开始规模化，「用户报告 agent 变差了，团队只能瞎猜盲查」——debug 变成反应式：等投诉 → 手工复现 → 修 bug → 祈祷没修坏别的。没有评估，你分不清真回归和噪声，也无法在上线前对成百上千场景自动测试（来源: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents，访问于 2026-08-30）。

评估的价值随生命周期复利：

• 基线 (baseline) 与回归测试免费获得：一旦金标集存在，延迟、token 用量、每任务成本、错误率都可以在固定任务组上持续追踪（来源同上）。
• 模型升级从「数周」变「数天」：新模型发布时，没有评估的团队要手工回归数周；有评估的团队跑一遍套件就知道强弱、几天完成升级（来源同上）。
• 评估驱动的开发 (eval-driven development)：官方实践是「先写 eval 定义预期行为，再让 agent 达标」——评估任务本身是检验产品需求是否足够具体的手段（来源同上）。
• 官方提示词工程文档把这一定位写得更直接：构建成功 LLM 应用的起点是定义成功标准 (success criteria)，然后设计评估来度量它——「这个循环是 prompt engineering 的核心」（来源: https://platform.claude.com/docs/en/test-and-evaluate/develop-tests，访问于 2026-08-30）。

架构师视角：评估是产品的可执行规格说明书。两份需求文档可以有三种解读，一套金标集只有一种。

成功标准怎么写才合格

官方给的四条标准（来源: develop-tests，访问于 2026-08-30）：

官方的多维标准示例值得背下来——同一个系统，任务、安全、错误严重度、延迟四类指标并列：held-out 集上 F1 ≥ 0.85；99.5% 输出无毒；90% 的错误只造成「不便」而非「严重后果」；95% 请求响应时间 < 200ms（来源同上）。这就是「分层指标」的最小样板。

2. 评估的解剖：从单轮到 Agent

🎯 学习重点：必考区分 transcript 与 outcome；agent 是否成功以环境终态为核心证据。

2.1 基础四件套（单轮评估）

官方 cookbook 给出评估的标准结构（来源: https://platform.claude.com/cookbook/misc-building-evals，访问于 2026-08-30）：

1. 输入 (Input)：喂给模型的 prompt（模板 + 变量）。
2. 输出 (Output)：模型真实产生的回答。
3. 金标答案 (Golden Answer)：比对基准——可以是必须精确匹配的答案，也可以是给评分器的「完美答案示例」或评分指引。
4. 分数 (Score)：用某种评分方法产出的结果。

2.2 Agent 语境下的扩展定义

Agent 会跨多轮调用工具、修改环境状态，错误会传播和复利，所以评估对象从「一次回答」扩展为「一段完整交互」。官方定义（来源: demystifying-evals，访问于 2026-08-30）：

transcript vs outcome 是本模块最重要的辨析之一：官方例子——机票 agent 最后说「您的航班已预订」，transcript 完美收尾；outcome 是预订系统的 SQL 数据库里到底有没有那条预订记录。任务成功要看 outcome，不只看说了什么（来源同上）。

2.3 评估流水线全景图

注意最后一个回环：线上失败案例回流成金标集新题目——这是官方路线图第一步（「把用户报告的失败转成测试用例，保证套件反映真实使用」）与长期维护的合流（来源: demystifying-evals，访问于 2026-08-30）。

3. 三类评分器：代码 vs LLM-as-Judge vs 人工

🎯 学习重点：优先 deterministic grader，必要时才用 LLM judge，并用人工样本持续校准。

官方对三种评分方法的定位（来源: develop-tests，访问于 2026-08-30；方法清单扩展自 demystifying-evals）：

官方排序原话：「deterministic graders where possible, LLM graders where necessary or for additional flexibility, and using human graders judiciously」（来源: demystifying-evals，访问于 2026-08-30）。

3.1 成本视角：出题是一次性成本，评分是永久成本

cookbook 的提醒值得写进预算表：写题目和金标答案贵，但通常是一次性固定成本；评分则每次重跑评估都要付费，永续发生——所以「能被快速、便宜地评分」应该成为 eval 设计的中心考量；把开放式问题改写成选择题等结构化形式是常用技巧（来源: misc-building-evals，访问于 2026-08-30）。

3.2 LLM-as-Judge 的四条官方技巧（来源: develop-tests，访问于 2026-08-30）

1. 详细清晰的 rubric：「答案第一句必须提到 'Acme Inc.'，否则自动判 incorrect」——而不是「答案应该好」。
2. 输出要经验化/结构化：让 judge 只输出 correct/incorrect，或 1–5 分——纯定性判断无法快速规模化。
3. 先推理再打分，然后丢弃推理：让 judge 在标签里先思考再给结论，能显著提升复杂判断的评分质量（cookbook 的 grader prompt 模板就是 <thinking> 推理 + <correctness> 结论双标签结构，来源: misc-building-evals，访问于 2026-08-30）。
4. 给「不知道」的出口：judge 信息不足时允许返回 "Unknown"，避免 judge 自己幻觉出一个结论（来源: demystifying-evals，访问于 2026-08-30）。

再加两条来自 agent 评估实践（来源同上）：

1. 按维度隔离 judge：每个评分维度一个独立 LLM judge，比一个 judge 包打所有维度更稳。
2. 与人工校准后才能信任：LLM judge 必须先与人类专家对比打分，确认分歧足够小；系统稳健后人工只需偶尔复核。校准不是一次性动作——rubric 变了就要重校准。

4. Offline vs Online、Capability vs Regression、pass@k vs pass^k

🎯 学习重点：三组概念最易混淆：离线与线上互补、能力集与回归集目标相反、pass@k 与 pass^k 叙事相反。

4.1 离线评估 vs 线上监控（以及中间地带）

• 离线评估 (offline evals)：开发/CI 阶段对固定任务组的自动化测试，无真实用户，可复现，可每次提交都跑。官方把它定位为「上线前与 CI/CD 中的第一道防线」（来源: demystifying-evals，访问于 2026-08-30）。
• 线上监控 (production monitoring)：生产系统的指标与错误追踪，揭示真实用户行为、捕捉合成评估漏掉的问题，但没有评分所需的 ground truth、信号噪声大。官方定位：「上线后检测分布漂移 (distribution drift) 与未预见的真实失败」（来源同上）。
• 中间地带：A/B 测试（真实流量、测真实结果，但出显著性要数天到数周）、用户反馈（稀缺、自选择、偏严重问题）、人工转录审读 (manual transcript review)（建立失败直觉，官方建议每周抽样阅读）、系统性人因研究（校准 judge 的金标准来源）。

架构师判断：离线评估回答「这个版本比上个版本好吗」，线上监控回答「用户现在遭遇什么」。只用其一都会有盲区——离线集漂移于真实分布时产生「虚假信心 (false confidence)」，纯靠线上则一切事故用户先踩到。

4.2 Capability evals vs Regression evals

官方二分法（来源: demystifying-evals，访问于 2026-08-30）：

「毕业」机制解决了一个根本矛盾：能力题只有在不饱和时才有信息量。官方提醒，评估饱和 (eval saturation) 时（agent 通过了所有可解任务），分数不再提供改进信号，且大改进只表现为小数点——SWE-bench Verified 一年内从约 30% 涨到 >80% 就是饱和进程的实例（来源同上）。

4.3 非确定性：pass@k 与 pass^k

同一任务每次跑结果不同，所以每个 task 要跑多 trial。两种汇总口径（来源: demystifying-evals，访问于 2026-08-30）：

• pass@k：k 次尝试中至少一次成功的概率。k 越大越高（「射门次数多，总有一个进」）。适合「成功一次就够」的工具型场景；编程常用 pass@1（第一次就做对）。
• pass^k：k 次全部成功的概率。k 越大越低。per-trial 成功率 75% 时，pass^3 = 0.75³ ≈ 42%。适合「每次都必须对」的面向用户系统。
• k=1 时两者相等；k=10 时一个趋近 100%、一个趋近 0%——讲的是相反的故事，选哪个取决于产品要求。

5. 金标数据集与回归测试

🎯 学习重点：金标题必须无歧义、可由参考解通过，并保持 held-out 与生产分布对齐。

5.1 怎么建：官方 0→1 路线图（压缩自 demystifying-evals §Going from zero to one，访问于 2026-08-30）

1. 尽早开始：评估在项目第一天就有用（强制团队写清楚「成功是什么」），不必等完美套件。
2. 从已有测试起步：发布前手动检查的行为、用户常用任务；已在生产则翻 bug tracker 和 support queue——用户报告的失败是最真实的题目来源，按用户影响排优先级。
3. 写无歧义任务 + 参考解：好任务的标准是两个领域专家独立得出同一 pass/fail 结论，且专家自己能通过该任务；题目里的规格要完整（官方反例：Terminal-Bench 审计发现「让 agent 写脚本」却没说文件路径，而测试按特定路径找脚本——agent 无辜挂科）。前沿模型 0% pass@100 通常说明题目坏了，不是模型不行。每个任务配参考解 (reference solution)：一份已知能通过所有 grader 的输出，证明题目可解、grader 配置正确。
4. 平衡问题集：测「应该发生」也测「不应该发生」——单侧评估制造单侧优化（只测「该搜索时要搜索」，会训出什么都搜的 agent）。官方 web search 评估的真实教训：必须同时覆盖「该搜」（查天气）与「不该搜」（谁创立了 Apple）双向题目，在 undertriggering 与 overtriggering 之间找平衡。
5. 健壮的 harness 与稳定环境：每次 trial 从干净环境开始，隔离共享状态——官方内部发现 Claude 曾靠翻看前序 trial 留下的 git 历史获得不公平优势；基础设施抖动造成的失败会被误记为 agent 失败。
6. 认真设计 grader：评产出不评路径（agent 会走设计者没预料到的合法路径，严格校验工具调用顺序往往过脆）；多组件任务给部分分 (partial credit)（正确识别问题+验证身份但没退款，好于立刻失败）；grader 要抗绕过（防「钻评测空子」式通过）。
7. 读 transcript：分数不涨时，transcript 告诉你是 agent 真错了还是 grader 冤枉了它。官方规则：「评估分数不被人细读 transcript 前，我们不把它当真」。失败应该「看起来公平」——agent 错在哪一目了然。
8. 长期维护：套件是活资产，要有 owner；让最接近用户的人（PM、客服、销售）也能贡献题目。

5.2 防过拟合到评测集：五个机制

「过拟合到评测集 (overfitting to the eval set)」指系统在金标集上分数漂亮、真实分布上拉胯。防线：

1. 分布对齐：题目分布 ≈ 真实使用分布（难度、类型、长度都像）（来源: misc-building-evals，访问于 2026-08-30）。
2. held-out 意识：develop-tests 官方例子里 F1 目标明确写「on a held-out test set of 10,000 diverse Twitter posts」——不要拿你反复调参看过的题目报告成绩；金标集一分为二（调参集 / 汇报集）是标准做法（来源: develop-tests，访问于 2026-08-30）。
3. 持续换血：线上失败不断回流成新题（来源: demystifying-evals）；题目长期不换 → 系统学会「应试」。
4. 双向平衡（见 5.1 第 4 条）：单侧题目会让优化方向本身跑偏。
5. 抗绕过 grader：题目和评分器要设计成「通过 = 真解出问题」，而不是利用漏洞（来源同上）。

另一个方向的「过拟合」是评分器 bug 冒充模型缺陷：官方两个真实案例——Opus 4.5 在 CORE-Bench 上最初只有 42%，研究者排查后发现是僵化评分（期望 "96.124991…" 却惩罚 "96.12"）、任务规格歧义、随机任务不可精确复现；修好后跳到 95%。METR 也发现自家基准有「按题面阈值优化却被要求超过阈值」的错配任务——按说明行事的模型反而得分更低（来源同上）。教训：分数异常时先怀疑 eval，再怀疑模型。

5.3 回归测试 = CI 门禁

回归套件的操作定义（来源: demystifying-evals，访问于 2026-08-30）：

• 触发时机：每次 prompt 修改、模型升级、工具/检索参数变更、依赖更新。
• 通过标准：回归套件保持近 100% 通过率；分数下降即信号「有东西坏了」，阻断发布。
• 官方云厂商同步提醒：模型供应商可能静默更新模型行为，回归集也是检测外部漂移的探针（本句为业界通用实践，落地时按模块 10 的「模型升级策略」执行）。

6. 指标分层体系：从检索到答案

🎯 学习重点：按检索、工具、终态、答案、接地性分层，才能把“分数下降”定位到具体组件。

只看一个平均分是本模块的头号反模式。 指标必须按管线的因果层拆开——哪层坏了修哪层，RAG 应用先看检索层（检索层崩了，调生成侧 prompt 无用，见模块 07）。

6.1 任务成功率 (Task Success Rate)

定义：以 outcome（环境终态）为准的任务完成比例，用代码 grader（state_check）验证。官方会话 agent 例子的成功判据三合一：工单状态 = resolved（state check）+ ≤10 轮完成（transcript 约束）+ 语气恰当（LLM rubric）——多维成功 + 各维各配 grader（来源: demystifying-evals，访问于 2026-08-30）。多 trial 时报告 per-task 成功率与 pass^k。

6.2 工具正确性 (Tool Correctness)

三个检查面（全部可代码化，来源: demystifying-evals 访问于 2026-08-30）：

• 该调的调了：required 工具是否被调用——官方退款例子里 verify_identity、process_refund、send_confirmation 三件套。
• 参数合规：不仅调了，参数要对——process_refund 的 amount <= 100 是官方 YAML 里真实出现的参数级断言。
• 不该调的没调 / 顺序合理：例如必须先 verify_identity 再 process_refund。但注意官方对「严格校验调用顺序」的警告：agent 可能走你没预料的合法路径，评产出不评路径——顺序断言只在顺序本身是业务规则（如先鉴权后退款）时才该是硬性的。

6.3 答案正确性 (Answer Correctness)

• 封闭式任务（分类、抽取、单值问答）：exact match / string match，代码评分即可（develop-tests 的情感分析例子）。
• 开放式任务：与 golden answer 对照的 LLM-as-Judge（reference-based evaluation），或成对比较。金标答案此时不是「唯一正确文本」而是「完美答案示例 / 评分指引」（来源: misc-building-evals，访问于 2026-08-30）。
• 注意：answer correctness 是对最终答案内容的判断，与 task success（状态达成）、groundedness（有据）是三个独立维度——可以全对但无据（模型自己猜对），也可以有据但错（引用了过时文档，模块 07 已辨析 groundedness ≠ accuracy）。

6.4 接地性 (Groundedness) 与幻觉评估 (Hallucination Evaluation)

Groundedness：回答中的每个主张 (claim) 是否被检索到的证据支撑。官方研究 agent 评估的三件套：groundedness checks（主张被检索来源支撑）+ coverage checks（关键事实无遗漏）+ source quality checks（来源权威，而不是检索序第一）（来源: demystifying-evals，访问于 2026-08-30）。

工程化路径：

1. 平台层：Citations。给文档块开 citations: {"enabled": true}，API 返回的引用是支撑每个主张的确切原文段落，让「验证答案」和「向用户展示来源」都程序化可查（来源: https://platform.claude.com/docs/en/build-with-claude/citations，访问于 2026-08-30）。引用是 groundedness 的基础设施：没有引用，逐主张溯源只能靠后处理对齐。
2. 提示层：官方减幻觉技术——这些护栏的效果本身要靠幻觉指标度量（来源: https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations，访问于 2026-08-30）：

• 允许说「我不知道」：明确授权弃答，大幅减少编造；
• 先摘原文引语再作答（>20k token 长文档尤其有效）：把生成锚定在原文上；
• 主张级引证：答完后逐主张找支撑引语，找不到就撤回该主张；
• 进阶：best-of-N 一致性检查（同一 prompt 跑多次，输出互相矛盾 → 幻觉嫌疑）、限定外部知识（只用给定文档，不用参数记忆）。
• 官方底线：这些技术显著降低但不消除幻觉，高风险决策仍需人工验证。

1. 指标层：幻觉率的可操作定义 = 无支撑且未弃答的主张数 / 总主张数（抽样人审或 LLM judge 判定支撑关系，judge 需校准）。「弃答率」单独报告——用拒答刷低幻觉率是新的作弊方向。

6.5 检索指标（呼应模块 07）

RAG 管线的检索层用四件套度量（定义与公式详见模块 07 §检索评估；官方 RAG cookbook 正是「检索层指标 + 端到端 Claude grading」两层结构，来源: https://platform.claude.com/cookbook/capabilities-retrieval-augmented-generation-guide，访问于 2026-08-30）：

指标作弊警告（模块 07 的教训在此同样成立）：recall@k 靠加大 k 就能涨（全库塞入 = recall 100%），必须与 precision@k / nDCG 同看。

6.6 组合与门禁

官方给 task 级评分的三种组合：weighted（各 grader 加权合成须过阈值）、binary（全部 grader 必须过）、hybrid（关键 grader 一票否决 + 其余加权）（来源: demystifying-evals，访问于 2026-08-30）。生产建议：安全类 grader（未越权调用工具、未泄露数据）走一票否决；质量类走加权。

7. 延迟与成本监控

🎯 学习重点：按任务而非按请求统计成本与延迟，并将质量、延迟、成本放在同一版本对比中。

7.1 延迟指标

官方定义（来源: https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-latency，访问于 2026-08-30）：

• Baseline latency（基线延迟）：模型处理 prompt 并生成响应的时间，不含吞吐率视角。
• TTFT (Time to First Token)：从发送 prompt 到模型吐出第一个 token 的时间——streaming 场景下决定用户感知的「响应速度」。

agent 评估把延迟做成了 tracked metrics：官方 YAML 示例里跟踪 time_to_first_token、output_tokens_per_sec、time_to_last_token，以及 transcript 侧的 n_turns / n_toolcalls / n_total_tokens（来源: demystifying-evals，访问于 2026-08-30）。延迟指标应该进回归套件：一次「无害」的 prompt 重写可能让 TTFT 翻倍（缓存失效、输出变长）。

降延迟的手段（模型选择如 Haiku、压缩 prompt/输出、streaming）是模块 10/02 的内容；本模块强调官方次序警告：先做出无约束下表现好的 prompt，再降延迟——过早优化延迟会让你永远不知道「满血性能」长什么样（来源: reduce-latency，访问于 2026-08-30）。

7.2 每任务成本与 token 预算

• 每任务成本 (cost per task)不是每请求成本：agent 完成一个任务可能 N 轮调用 × 每轮 input(含缓存) + output，再乘以 pass^k 概率下的重试放大。官方 YAML 的 n_total_tokens 就是任务级 token 账单的采集点（来源: demystifying-evals，访问于 2026-08-30）。
• token 预算：给任务设总 token 预算（transcript 约束的一种），超预算 = 任务失败——这比 max_tokens 这种单请求限制更贴近业务约束。
• 架构师提醒（来源: https://www.anthropic.com/engineering/building-effective-agents，访问于 2026-08-30）：agentic 系统经常用延迟和成本换任务表现——所以质量、延迟、成本三个指标必须并排出现在同一张报表，任何「质量涨了」的报告都要附带成本延迟变化。评估让这三者「免费」获得基线。

7.3 官方成本观测工具（截至 2026-08-30）

• Usage & Cost Admin API：程序化获取组织的 API 用量与成本数据（粒度可到日/时段），官方列出的用途包括产品性能监控、变更是否有改善的度量、设置告警、速率限制优化与成本对账。需要 Admin API key 等管理员凭据（来源: https://platform.claude.com/docs/en/manage-claude/usage-cost-api，访问于 2026-08-30）。
• 官方合作伙伴集成：同页列出 Datadog（LLM Observability，自动 tracing 与监控）、Grafana Cloud（开箱仪表盘与告警）、Honeycomb（OpenTelemetry）、CloudZero / Harness / Vantage（FinOps 成本管理）等现成集成（来源同上）。LangSmith / Langfuse / Arize Phoenix 则是官方 evals 文章点名的评估+可观测平台（Langfuse 可自托管、满足数据驻留）（来源: demystifying-evals，访问于 2026-08-30）。

架构师视角：trace 是离线评估与线上监控的公共货币。transcript 格式统一后，同一个 grader 既能跑离线金标集，也能对线上抽样流量打分——「在线评估」就是把离线 grader 挂到生产采样管道上。

8. 线上监控与告警

🎯 学习重点：线上没有现成 ground truth，要组合 drift、逃逸指标、分层抽样与 transcript 下钻。

8.1 六种理解 agent 表现的方法（官方对照表压缩，来源: demystifying-evals，访问于 2026-08-30）

官方结论：「最有效的团队组合使用这些方法：自动化评估做快速迭代，生产监控做 ground truth，定期人审做校准」（来源同上）。

8.2 Drift（漂移）检测

• 输入分布漂移：用户问题类型/长度/语言随时间变化（营销活动带来新客群）。症状：线上指标稳但某子群体崩溃。
• 模型行为漂移：供应商侧模型更新改变行为（模块 10 的模型升级策略）。
• 语料漂移：RAG 知识库更新后，金标块失效或新内容未入索引。
• 检测手段：官方口径是 production monitoring 负责发现 distribution drift（来源同上）；工程上 = 对输入特征分布与输出质量代理指标做时间序列对比 + 分位数告警；离线侧定期用回归套件对生产采样题目重打分。

8.3 采样人审 (sampled human review)

官方把「每周抽读 transcript」列为常设实践（来源同上）。工程化：按风险分层采样（高金额工具调用 100% 抽、低风险随机 1–5% 抽）、人审结果回流两个方向——校准 LLM judge（一致性对比）与沉淀新 eval 任务。标注者间一致性 (inter-annotator agreement) 是人审自身质量的度量。

8.4 逃逸指标（Escape / deflection proxy metrics）

以下为业界通用代理指标（非 Anthropic 官方术语，落地按自家产品定义），共同点：不评「答案质量」，评「用户是否放弃了 agent」——用户的行为是最诚实的评分器：

• 用户改写率：用户对 agent 回答重新措辞再问一遍的比例——「没听懂」的信号。
• 人工接管率 / 升级率 (escalation rate)：会话转人工的比例（客服场景）；「接管」是任务失败的高置信代理。
• 负面反馈率（thumbs-down）与放弃率（会话中途离开）。
• 用法：设基线 → 版本对比 + 告警阈值；异常升高时，从对应时段采样 transcript 定位是哪一层（检索/工具/生成）劣化。

8.5 告警设计要点

• 按层路由：检索层指标告警找 RAG 管线负责人；工具错误率告警找集成 owner；groundedness 抽检下滑找 prompt owner。一个「总平均分」告警没人能行动。
• 阈值要有基线：先跑离线金标集得到稳定基线，再设线上阈值（p95 而非均值；见 bad vs better）。
• 告警要能自愈和升级：短时尖峰（限流、抖动）降噪；持续偏移升级到人审队列。

9. Bad vs Better：评估体系架构对比

🎯 学习重点：反模式是单一平均分；正解是关键指标一票否决、分层指标和离线/线上双闭环。

❌ Bad：一个平均分走天下

构建流程:
  prompt v1 → 内部试 20 个问题 → "感觉不错" → 上线
  改动后 → 重跑 20 题 → 平均分 86 → 发布

线上:
  一个「Quality Score」仪表盘（所有维度混成一个 0-100 分）
  无告警（或只有 API 错误率告警）

问题（逐条对应本模块的官方依据）：

1. 平均分掩盖分层劣化：改版后平均分 86 不变，实际是检索层 -10、生成层 +10（或安全合规 +20、任务成功 -15）——你不知道修好 A 的是不是弄坏 B 的同一个改动。
2. 无金标集规格：20 题「感觉不错」不满足 Measurable/Achievable/Relevant，两轮「感觉」不可比。
3. 无回归语义：没有「哪些题过去对、现在也必须对」的锁定，回归靠用户报告（reactive loop 本尊）。
4. transcript 当 outcome：按「agent 说做完了」计成功。
5. LLM judge 未校准：一个未对比人工的 judge 决定发布与否，judge 自己幻觉无人知晓。
6. 线上只有总量指标：TTFT/成本/逃逸指标缺失 → 质量下滑三周后由客服工单数量「告警」。

✅ Better：分层指标 + 回归集 + 双闭环

离线（CI 门禁）:
  capability 套件（低通过率，爬坡目标）+ regression 套件（≈100% 红线）
  每 task 多 trial → pass^k（用户面）+ pass@1（工具面）
  分层报表: 任务成功率 / 工具正确性 / 答案正确性 / groundedness
           + 检索层 recall@k·precision@k·MRR·nDCG
           + 系统层 TTFT·每任务成本·token 预算达成率
  grader: 代码优先，LLM judge 带详细 rubric + Unknown 出口，
          每季度与人工抽检对表校准；安全 grader 一票否决
  金标集: 题目≈生产分布，双向平衡，线上失败每月回流，饱和即毕业

线上（监控闭环）:
  trace 采样管道: 高风险调用全审、常规流量分层随机抽
  逃逸指标: 改写率/接管率/thumbs-down 设基线与告警
  drift: 输入分布时序对比 + 回归套件定期对生产采样重打分
  成本: Usage & Cost API 对账 + 每任务成本日报（质量报表并排）

10. Tradeoffs（架构师决策清单）

🎯 学习重点：每项评估设计都要回答信号质量、运行成本、反馈速度和可解释性的取舍。

1. 评分器三选：代码评分便宜可靠但脆（合法变体挂科）；LLM judge 灵活但非确定、需校准；人工金标准但贵慢。→ 官方次序：能代码则代码，必要时 LLM，人工点到为止。
2. 一次性成本 vs 永续成本：出题贵一次，评分贵永远。宁可前期多花在设计「可便宜评分的题目结构」（如改选择题），不要造一个每次跑都烧钱的评分流程。
3. 题量 vs 题质：官方明确「量优先于质」——更多题目 + 略低信号的自動评分，好于少量精细人工题（develop-tests 设计原则 + cookbook 智慧）。前提是评分自动化。
4. 评产出 vs 评路径：评产出（state/结果）健壮、不惩罚创造性解法；评路径（调用序列）精确、可控但脆。业务规则型顺序（先鉴权后打款）才值得硬校验。
5. 离线可复现 vs 线上真实性：离线集可控但会漂离真实分布（虚假信心风险）；线上真实但无 ground truth、被动。→ 两者都要 + 失败回流管道。
6. pass@k vs pass^k：报喜口径 vs 报忧口径；面向用户系统必须看 pass^k，哪怕数字难看。
7. 多 trial 成本 vs 统计稳定：trial 越多指标越稳、账单越贵。低方差任务 1–3 trial，高风险任务才上 5+。
8. 延迟/成本 vs 质量：agentic 系统的本质交换（BEA）。指标并排呈现，让「质量提升」的提案附带成本延迟账单，由业务方拍板，而不是工程方默认吞下。
9. 告警灵敏度 vs 噪声：阈值太紧 → 告警疲劳全员无视；太松 → 回归漏网。基于离线基线的 p95/分位数阈值 + 持续偏移才升级。
10. 评测集共享 vs 保密：套件入库便于全员贡献（官方鼓励 PM/客服提题），但公开的固定题目=可应试。→ 汇报用 held-out 子集，贡献用开发子集。

11. Common Mistakes（常见错误）

🎯 学习重点：分数异常先审题目、环境与 grader，再归因模型；不要把评估基础设施当绝对真值。

1. 只看平均分：所有维度糊成一个数，回归发生时无法定位层。→ 分层指标（§6/§9）。
2. 把 transcript 当 outcome：agent 说「订好了」就计成功。→ state_check 查数据库终态。
3. 0% 通过率先怪模型：前沿模型 0% pass@100 多半是题目/评分器坏了。→ 每题配参考解；先审 eval 再审模型。
4. 单侧问题集：只测「该做 X 时做了 X」，训出过度触发的系统。→ 双向平衡（该搜/不该搜）。
5. 严格校验工具调用顺序：惩罚了设计者没预料的合法路径（CORE-Bench 42%→95% 的教训）。→ 评产出不评路径；只有业务规则顺序才硬校验。
6. LLM judge 拿来就用：无 rubric、无 Unknown 出口、从不与人工对表。→ 四条官方技巧 + 定期校准。
7. 评估集一劳永逸：饱和不毕业、题目不换血、线上失败不回流。→ graduation + 每月回流 + held-out 汇报集。
8. 环境共享状态：trial 之间残留文件/缓存/git 历史，造成相关失败或虚假高分。→ 每 trial 干净隔离环境。
9. recall 单看：加大 k 就能刷高。→ 与 precision@k / nDCG 同看。
10. 离线评估替代线上监控（或反之）：离线漂移无感知 / 线上问题全靠用户报告。→ 双闭环。
11. groundedness 当 accuracy：有据≠正确（证据可能过时/错误），正确≠有据（碰巧对）。两个维度分开报（模块 07 已辨析）。
12. 过早优化延迟：性能还没达标就砍 token 换速度，永远见不到满血基线。→ 先功能后延迟（官方次序警告）。
13. 拿弃答刷幻觉率：把「我不知道」的比例藏起来只报幻觉率下降。→ 弃答率单独上报，与任务成功率联动看。

11A. 架构师犀利细节：数字、边界与门禁

🎯 学习重点：会计算概率、识别指标作弊，并把安全、质量和成本设置成不同门禁。

• 成功率 75% 不等于可靠：单次成功率为 0.75 时，连续 3 次全成功的 pass^3 = 0.75³ ≈ 42%；若用户每次都要求正确，应报告 pass^k，而不是用 pass@k 粉饰可靠性。
• 0% pass@100 是诊断信号：前沿模型百次均失败时，先检查题目歧义、环境污染和 grader；反模式是立刻换更贵模型，正解是先用 reference solution 证明任务可解。
• CORE-Bench 42%→95%：僵化精度比较和规格歧义能制造 53 个百分点的“假模型缺陷”。评分器变更必须像生产代码一样版本化、回归和审计。
• recall@k 可被轻易刷高：增大 k 直到全库进入上下文可得 100% recall，却会压低 precision、增加 token 成本与生成延迟；必须与 precision@k/nDCG、答案接地性和每任务成本同看。
• 95% 请求 <200ms 是分位数目标，不等于平均延迟 200ms；平均值会掩盖长尾。agent 还要同时记录 TTFT、TTLT、工具轮数和总 token，避免“首字快、任务慢”。
• 门禁配比原则：越权、泄露等安全 grader 走 binary 一票否决；质量维度可 weighted；关键项否决、其余加权属于 hybrid。不要让高语气分抵消一次真实越权。
• 采样边界：高风险调用 100% 审计、低风险流量 1–5% 抽样是本模块现有工程示例，不是跨业务通用常数；实际比例必须由事件率、检测把握度、审核容量与风险预算反推。

12. 重要英文术语（考试保持英文）

🎯 学习重点：能准确解释 ground truth、grader、drift、pass@k、pass^k 及其适用场景。

• Evaluation (Eval) — 评估；Golden Dataset / Golden Answer — 金标数据集 / 金标答案
• Regression Testing / Regression Evals — 回归测试 / 回归评估；Capability Evals — 能力评估
• Task / Trial / Grader / Assertion — 任务 / 试验 / 评分器 / 断言
• Transcript (Trace / Trajectory) — 转录（完整交互记录）；Outcome — 环境终态结果
• Evaluation Harness / Agent Harness — 评估脚手架 / 智能体脚手架
• Code-based Grading / Model-based Grading (LLM-as-Judge) / Human Grading — 代码评分 / 模型评审 / 人工评分
• Rubric / Reference Solution / Partial Credit — 评分细则 / 参考解 / 部分分
• pass@k / pass^k — k 次至少一次成功 / k 次全部成功
• Task Success Rate / Tool Correctness / Answer Correctness / Groundedness / Hallucination Rate — 任务成功率 / 工具正确性 / 答案正确性 / 接地性 / 幻觉率
• recall@k / precision@k / MRR (Mean Reciprocal Rank) / nDCG (normalized Discounted Cumulative Gain) — 检索四件套
• TTFT (Time to First Token) / Baseline Latency — 首 token 延迟 / 基线延迟
• Cost per Task / Token Budget — 每任务成本 / token 预算
• Production Monitoring / Distribution Drift / A/B Testing / User Feedback — 生产监控 / 分布漂移 / A/B 测试 / 用户反馈
• Sampled Human Review / Spot-check / Inter-annotator Agreement — 采样人审 / 抽检 / 标注者间一致性
• Eval Saturation / Overfitting to the Eval Set / Held-out Test Set — 评测饱和 / 过拟合评测集 / 留出测试集
• Escalation Rate（业界通称） — 人工接管/升级率

13. 认证相关性

🎯 学习重点：架构题不仅问“怎么评”，还问如何证明上线前可接受、上线后可发现劣化。

• Claude Certified Architect – Foundations (CCAR-F) 面向「构建生产级 Claude 应用的 solution architects」（来源: https://www.anthropic.com/news/claude-partner-network，访问于 2026-08-30，经 00-certification-current-status 核验）；评估与可观测性正是「生产级」三字的核心支撑——架构师要能回答「这个系统怎么证明它是对的、以及它坏了怎么第一时间知道」。
• 官方考试域权重尚未公开（本仓库 00-certification-current-status 记录为 PENDING）；本模块内容对齐官方文档与工程博客的一手表述，不引用第三方权重数字。
• 高频考法预判（基于官方材料的可考性）：

1. 给一个任务（分类/开放式问答/agent 退款流程），选 grader 类型（code vs LLM judge vs human）并说明理由；
2. transcript vs outcome 辨析（「agent 说完成了」算不算 task success）；
3. pass@k 与 pass^k 随 k 的变化方向与产品适配；
4. groundedness vs answer correctness 的区分；
5. 检索症状 → 指标路由（该召回没召回 → recall@k；召回在但排不前 → MRR/nDCG）；
6. capability vs regression 套件的期望通过率与生命周期（毕业机制）；
7. LLM judge 校准实践（rubric、Unknown 出口、人工对表）。

• 与其他模块的考试联动：模块 07（检索指标与两层评估）、模块 10（可观测性/审计/成本延迟权衡）、模块 11（安全 grader 一票否决）、模块 04（工具回路与 tool correctness）、模块 08（evaluator-optimizer 工作流——「清晰评估标准 + 可度量改进」正是本模块的运行时化身，来源: https://www.anthropic.com/engineering/building-effective-agents，访问于 2026-08-30）。

14. 小结

🎯 学习重点：用一张图复述离线 CI 与线上观测相互供数的双闭环。

• 评估是可执行的规格：成功标准要 Specific / Measurable / Achievable / Relevant。
• Agent 评估评的是 harness + 模型，看 outcome 不只看 transcript；多 trial 用 pass@k / pass^k 汇总。
• 三类评分器按「代码优先、LLM 必要、人工点睛」组合；LLM judge 必须有 rubric、Unknown 出口和人工校准。
• capability 套件爬坡，regression 套件守门；题目双向平衡、参考解护体、线上失败回流、饱和即毕业。
• 指标分层：任务成功 / 工具正确 / 答案正确 / 接地性 + 检索四件套 + TTFT 与每任务成本——质量、延迟、成本并排呈现。
• 线上是第二闭环：drift 检测、每周采样人审、逃逸指标告警；离线与线上互相喂养。
• 下一站：模块 13 Capstone——把本模块的评估体系纳入完整参考架构与决策工作簿。

延伸阅读：模块 07 §检索评估（recall/precision/MRR/nDCG 公式与手算）、模块 10 §可观测性（trace/日志/审计）、examples/ 三个无 key 可跑的评分器、labs/lab.md、以及官方原文（sources/sources-12-evals.csv E01–E09）。