# 第 21 章 评估驱动的一切

## 本章目标

- **O1** 能够追踪“成功标准”“评估用例”“版本决定”之间的前向与反馈路径（产物：评估闭环记录）
  - 证据: 评估闭环记录画出“成功标准”“评估用例”“版本决定”的前向路径和返回路径
- **O2** 能够构造评估闭环记录，注明每轮输入、判断和回写证据（产物：评估闭环记录）
  - 证据: 评估闭环记录为每一环写明输入、判断、输出和负责人
- **O3** 能够把成功标准转成可重复用例并据结果决定版本（产物：评估闭环记录）
  - 证据: 产物包含成功标准、代表用例、逐例结果和版本决定

## 学习路径

- **初学者**: 本章迁移任务是：能够把成功标准转成可重复用例并据结果决定版本。先按图中的“反馈闭环”关系完成评估闭环记录的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够把成功标准转成可重复用例并据结果决定版本。提交评估闭环记录后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 评估闭环记录
- **图解类型**: evaluation-loop
- **关系语义**: 三环先沿前向路径产生结果，再由返回路径把观察写回；没有回写就不构成闭环。
- **核心概念**: 成功标准 · 评估用例 · 版本决定

![第 21 章评估闭环记录教学图](/learning/diagrams/zh/chapter-21.svg)

沿前向与返回两条路径检查评估闭环记录，确认结果确实改变下一轮输入。

图先从“成功标准”前向经过“评估用例”到“版本决定”，再以虚线返回起点。前向箭头产生结果，返回箭头承载观察和修正；若结果没有回写到下一轮输入，流程只是单程而不是闭环。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

### 21.1 一个典型场景：改了一行提示词，然后呢？

你给客户做的工单分类助手上线三周，运行平稳。周一早上，业务方提出一个口径调整：把"紧急"的判定从"影响生产"放宽到"影响生产或影响交付承诺"。你打开提示词，改了一句话，前后五分钟。代码没动，测试全绿。

现在回答一个问题：你怎么知道这次修改没有把三百条历史工单中原本分对的两百条改坏？

在传统软件里这不是难题——改动就是一次发布，跑一遍测试套件，断言全部通过即可放心。但这次你改的是提示词：模型的行为随之整体漂移，没有任何单元测试能断言"三百条历史工单的分类结果仍然合理"。没有评估集的时候，唯一的办法是抽样看几十条，也就是——祈祷。

而祈祷在客户现场是奢侈品。客户的技术负责人会问你："改了之后系统还行吗？"你不能回答"感觉还行"，你得拿出数字。这个数字从哪来？从 evals（评估集）来——一组固定输入、一份期望要点、一套通过标准，任何时候重跑，得到可比的结果。

这个能力不是本书的发明，而是部分 FDE 岗位的显式要求。Anthropic 的 Forward Deployed Engineer 招聘描述里逐字写着：

> "Production experience with LLMs including advanced prompt engineering, agent development, evaluation frameworks, and deployment at scale."

注意这几项的并列关系：高级提示工程、agent 开发、评估框架、规模化部署。这里能支持的结论是：在该岗位描述中，评估能力被放在生产部署经验内，而不是独立的可选加分项；它不能单独证明整个行业采用同一标准。

OpenAI 一侧的实践印证了同一判断。据 The Pragmatic Engineer 2025 年 8 月对 OpenAI FDE 负责人的采访，其客户项目的典型节奏分三个阶段：早期 scoping 现场数日；验证期构建 evals，并在 evals 上爬坡；交付期每周驻场。最值得注意的是中间那句话——迭代不是在感觉上爬坡，是在 evals 上爬坡：提示词改了，跑一遍；模型换了，跑一遍；方案调了，跑一遍。评估集就是爬坡的坡道，没有坡道的迭代是自由落体。

所以本章标题是"评估驱动的一切"。在 AI 系统里，几乎所有关键决策都应当被 eval 驱动：提示词迭代由 eval 结果驱动，模型升级由 eval 对比驱动，方案取舍由 eval 数据驱动。反过来说，没有 eval 的迭代有个难听但准确的名字——凭感觉驱动（vibes-driven）。客户为你买单的不是感觉。

### 21.2 eval 不是软件测试：确定性断言 vs 概率性输出

很多工程团队的第一反应是："我们有测试，加几条不就行了？"不行。eval 与软件测试表面相似（都是"给定输入，检查输出"），底层假设完全不同。

典型确定性单元测试可精确约束行为。在固定输入与受控依赖下，断言检查约定输出或性质；第 7 章验收与第 25 章测试电网大量使用这类工具。但软件测试也覆盖并发、随机算法和不稳定外部依赖，不能说所有软件都有唯一输出，或一次通过就证明系统正确。

模型评估活在概率世界。同一个输入，模型两次运行可以给出措辞不同但都正确的回答；"正确"不是唯一解，而是一个分布；判定一个输出不是"对答案"，而更像"评卷"——看它覆盖了哪些要点、犯了什么错、错得多重。

把差异摊开到表格上：

| 维度 | 典型确定性单元测试 | 模型评估（eval） |
|------|----------|------------------|
| 输入输出关系 | 受控条件下：同输入有约定输出或性质 | 概率性：同输入可有多个合理输出 |
| 判定方式 | 断言（assert 相等 / 抛错） | 评分（对期望要点的覆盖程度、禁止项检查） |
| 通过语义 | 二值：通过或失败 | 连续：通过率 / 得分，如"92% 用例达标" |
| 失败语义 | 实现、断言或测试环境不符合约定，需排查 | 可能是采样波动，也可能是真退化，需区分 |
| 结果稳定性 | 一次通过只证明本次已测条件，覆盖仍有边界 | 记录真实配置，重复运行观察波动，不保证确定性 |
| 触发重跑的变更 | 代码变更 | 提示词、模型、温度、上下文——任何一项变更全部重评 |

概率性输出也可以用确定性 scorer 评分，例如分类标签精确匹配、JSON schema 或禁止字段检查。区别在被评行为及结论的适用范围，不在是否使用 assert；两类工具可以组合。

最后一行值得强调：在 AI 系统里，"变更"的范围远大于传统软件。你没改一行代码，只把模型从上一代切到新一代，或把上下文窗口里塞的文档换了一批，输出质量就可能整体漂移。eval 的触发条件必须覆盖所有影响输出的变量，而不只是代码。

还要防止另一个极端——把 eval 与测试对立起来，以为有了 eval 就不需要测试。二者是分层关系，不是替代关系：测试电网守住代码行为不退化（函数、接口、业务逻辑），eval 守住模型输出质量不退化（正确性、幻觉、格式）。两道防线各管一半，缺一半系统都裸奔。第 23 章会把六步工作法的"验收"扩展为"代码验收 + 模型输出验收"双轨——那是本部分的收口，本章先把 eval 这条轨立起来。

五个质量维度：一次 eval 该度量什么

"输出对不对"只是质量的一个维度。一次完整的 eval 至少要分别度量五个维度，因为它们会互相打架：

| 维度 | 问的问题 | 典型度量 | 常见坑 |
|------|----------|----------|--------|
| 正确性 | 结果对不对 | 要点通过率、评分 | 只看平均分，掩盖长尾失败 |
| 幻觉率 | 有没有编造 | 含捏造内容的用例占比 | 幻觉高发于客户私有域——恰恰是通用模型最缺训练数据的地方 |
| 格式遵循 | 输出能否被下游消费 | JSON schema 校验通过率 | 一个格式错误足以打挂整条下游流水线 |
| 成本 | 这次调用花多少钱 | 单用例平均 token 数 / 费用 | 长 prompt × 高频调用，账单按乘法增长 |
| 延迟 | 用户等多久 | P50 / P95 时延 | 平均延迟无感，P95 才决定体验 |

五个维度合起来构成一个"质量向量"。真实的工程决策几乎总是向量里的权衡：换更强的模型，正确性上升、成本和延迟也上升；收紧格式约束，格式遵循上升、表达质量可能下降。eval 的作用不是消灭权衡，而是把权衡变成显式的数字——让"要不要"从各自的直觉之争，变成一张可以摆在客户和团队面前的对比表。

可以先用这张表做个现状自查：你的项目现在能立刻回答其中几个维度？多数团队的答案是：正确性"大概"，幻觉率"没量过"，格式"跑挂了才知道"，成本"月底看账单"，延迟"用户没投诉"。能回答的维度越多，你的系统离"工程"越近；一个都回答不了的，不管上线没有，都还停留在演示阶段。

### 21.3 最小可行 eval：从 10 个手工用例开始

知道该度量什么之后，下一个陷阱是起步姿势：评估平台、自动标注、judge 流水线——工具先行，三个月搭不出来，eval 还是一条没有。正确的起步恰好相反：一张表 + 一段脚本，10 个手工用例，今天就能落出来。

第一步：凑齐 10 个真实输入

用例的来源决定 eval 的成色。按 6 + 2 + 2 配比收集：

- 6 个常规用例：来自客户现场的真实输入——工单原文、用户原话、真实文档片段。不要自己编"理想输入"：你编的输入像你的思路，客户的输入像客户的思路，模型犯的错在后者。
- 2 个边界用例：输入残缺、表述歧义、多问题混杂的情形。模型在边界上的表现才是区分度所在。
- 2 个历史失败用例：上线前测试或上线后暴露过的真实失败。曾经错过的地方，回归时最容易再错。

第二步：为每个用例写期望要点与通过标准

期望要点不是唯一标准答案——那是把概率系统当确定性系统测。它是"一个合格回答必须覆盖的要点 + 必须不出现的内容"。落到一张用例表上，模板如下（沿用第 1 章的教学对账场景；行内情境和金额为教学假设，实际使用须填入获准数据及可追溯来源）：

| # | 用例名 | 输入（使用时填真实案例及来源） | 期望要点（必须覆盖） | 禁止项 | 通过标准 |
|---|--------|------------------|----------------------|--------|----------|
| 01 | 常规差异定位 | 三月对账差 12,400 元的凭证流（教学假设；填入实际数据来源） | ①指出差异金额与科目 ②定位到凭证编号 ③结论不越界（不推断原因） | 编造凭证号 | 要点 3/3 |
| 02 | 数据缺失 | 上游系统缺两天流水的月份 | ①识别数据缺失 ②明确输出"无法完成判断" ③指明缺失范围 | 在缺数据时猜测差异原因 | 禁止项一票否决 |
| 03 | 歧义表述 | "这笔钱对不上"（未指明期间与科目） | ①请求澄清或列出候选解释 ②不擅自锁定单一解释 | 无依据断言 | 要点 2/2 |
| 04 | 历史失败 | 上线首周误报过的跨币种凭证 | ①正确处理币种换算 ②差异金额与基准一致 | 沿用旧错（直接相加） | 要点 2/2 |
| … | … | … | … | … | … |

两个设计细节：禁止项比要点更优先——编造一个凭证号比漏掉一个要点严重得多，所以用一票否决；通过标准逐用例声明——不同用例容忍度不同，边界用例可以宽松，核心用例必须全对。

第三步：让它可重跑

用例表落成数据文件，配一段最朴素的脚本：循环调用、按要点判分（初期人工判分完全可以）、输出结果表。技术上没有任何难度，唯一的纪律是可重跑：任何人、任何时候、执行同一条命令，得到口径可比的数字。第一次全量运行的结果就是基线——从此每次改提示词、换模型、调方案，都与基线对比，而不是与记忆对比。

10 个用例当然不构成统计意义上的置信度，但它完成了一个从 0 到 1 的关键转变：从"每次改完凭感觉"，变成"每次改完有数字"。随项目推进，用例会自然增长——新失败回流成新用例，等手工判分撑不住时，第 22 章的 golden set 分层与 LLM-as-judge 正好接上；变更频繁需要锁定基线、防手滑回退时，第 23 章的版本化与回归流程正好接上。

最后是四个最常见的起步误区，每一个都值得写在用例表的页眉上：

1. 只放简单用例：十个用例模型全对，eval 永远绿灯——绿灯不是目标，区分度才是。
2. 期望要点写成唯一答案：要求模型逐字复述你的参考答案，把评卷变成了对答案。
3. eval 集一次写完不再更新：现场每暴露一个新失败，就该多一条用例；不回流的 eval 会慢慢腐化成"永远通过的摆设"。
4. 只量正确性：幻觉率、格式、成本、延迟四个维度一个不看，直到其中某一个在生产环境爆炸。

【自检清单】最小可行 eval 自查

- [ ] 我能一句话说清"这套 eval 在度量什么、给谁看"吗？
- [ ] 用例输入来自客户现场的真实数据，而不是我编写的理想输入吗？
- [ ] 10 个用例里含边界用例和历史失败用例吗？
- [ ] 每个用例的期望要点是"要点覆盖"而不是"唯一标准答案"吗？
- [ ] 含捏造类禁止项的用例，是否设了一票否决？
- [ ] 有没有一个基线结果，让下次变更可以与它对比？
- [ ] 除了正确性，五个质量维度里我还量了哪几个？没量的那几个，出事时第一时间会发现吗？

### 【练习】给你的项目写出第一张 eval 用例表

题目：选一个你正在做（或最近做过）的 AI 功能——摘要、分类、抽取、问答皆可——按 21.3 节的 6 + 2 + 2 配比凑齐 10 个真实输入，为每个用例写期望要点、禁止项与通过标准，跑出第一份基线结果表。

引导：重点体验两个落差。①"真实输入"的落差：把客户或用户的原话放进输入栏时，你会发现它们比想象的更残缺、更歧义——恭喜，这正是 eval 的价值所在。②"期望要点"的落差：写到第三四个用例时，你会开始纠结"这条算必须覆盖还是最好覆盖"——这种纠结就是质量标准的显式化过程，值得花时间。

参考方向（供讲师参考）：评阅练习主要看三点。用例来源是否真实（编造的理想输入一眼可辨）；禁止项是否抓住了该场景最致命的失败模式（摘要场景通常是"不编造原文没有的内容"，抽取场景通常是"不确定时硬给值"）；通过标准是否分层（核心用例严格、边界用例宽容）。常见的反例是十张表长得一模一样——那说明写表的人没有针对自己的场景思考失败模式，只是填了模板。

---

> 本章业界事实的来源说明：Anthropic Forward Deployed Engineer 招聘描述中 "Production experience with LLMs including advanced prompt engineering, agent development, evaluation frameworks, and deployment at scale" 为逐字引用；OpenAI 客户项目"三阶段流程、验证期构建 evals 并在其上爬坡"出自 The Pragmatic Engineer 2025 年 8 月对 OpenAI FDE 负责人的采访记录。本章关于 eval 与软件测试的区分、五个质量维度、最小可行 eval 与用例表模板，属于本书的方法论展开，不归属特定公司的内部实践。本章未另引行业统计；未标明来源的案例、金额、比例、用例数量和频率均为教学假设，不是客户实测或行业基准。

---

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-21.md`，写上版本、决定、证据和缺项。

给工单模型设计常规、边界、历史错误、对抗各两个样本，写期望、禁止项、判定方式和版本。区分规则测试与真实模型评估。

<!-- chapter-artifact-requirement -->
### 本章必交产物：评估闭环记录

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: 评估闭环记录画出“成功标准”“评估用例”“版本决定”的前向路径和返回路径
- O2: 评估闭环记录为每一环写明输入、判断、输出和负责人
- O3: 产物包含成功标准、代表用例、逐例结果和版本决定

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

常规类别可精确匹配，解释质量需要点清单，秘密暴露是独立红线。记录来源许可、提示、模型、参数、数据与逐条输出。规则练习证明检查管线可运行，不证明模型能力；样本数量是练习设计，不代表生产充分性。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；评估闭环记录、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [建立成功标准与评估](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests) — Anthropic, 2026-09-17. 评估应从可观察成功标准、用例和版本化证据开始。
- [NIST AI 风险管理框架](https://www.nist.gov/itl/ai-risk-management-framework) — National Institute of Standards and Technology, 2026-09-17. AI 风险治理需要跨设计、开发、部署和使用阶段持续识别、测量、管理与记录。
- [FDE 的起源、角色区分与 OpenAI 工作阶段访谈](https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers) — The Pragmatic Engineer, 2026-09-17. 该访谈报道 FDE 起源脉络、OpenAI 的 SA/FDE 区分、客户项目三阶段及团队知识分享节奏；属于二手访谈材料，不代表行业通用标准。
- [Anthropic Forward Deployed Engineer 职位说明](https://job-boards.greenhouse.io/anthropic/jobs/5302966008) — Anthropic, 2026-09-28. 该 Anthropic 岗位要求把生产级 LLM 经验与提示工程、agent 开发、评估框架和规模化部署并列；不代表所有 FDE 岗位要求。