📑 本页目录（点开跳转）
14 · 评测 Evals
⏱ 38 分钟 ｜ ⭐⭐ 决定你敢不敢上生产的一节
🎯 一句话
没有评测的 Agent 优化 = 玄学。 评测不是"上线前跑一下"，而是你和模型之间唯一可靠的沟通渠道。
😰 一、没有评测会发生什么
有评测：发布前自动测数百个场景，每次改动都有数字。
🔑 一条容易被忽视的时间账： 「评测越晚建越难建。」 早期产品需求能自然转化为测试用例； 等系统复杂了再补，你已经不知道"正确行为"该长什么样了。
🧪 二、三类评分器
| 类型 | 方法 | 优点 | 缺点 |
|---|---|---|---|
| 代码评分器 | 字符串匹配、fail-to-pass 测试、静态分析、状态校验 | 快、便宜、客观、可复现 | 对合理变体脆弱、缺乏细腻度 |
| 模型评分器 | rubric 打分、自然语言断言、两两比较、多评委共识 | 灵活、可扩展、能处理开放式输出 | 非确定性、更贵、需对照人类专家校准 ⭐ |
| 人工评分器 | 专家审查、抽检、A/B | 金标准，用来校准模型评分器 | 贵、慢 |
💡 实践中最常见的组合：单元测试管正确性 + LLM rubric 管质量，按需再加人工抽检。
🪜 三、从零到可信评测：八步
第 0 步：尽早开始
❌ 「等产品稳定了再建评测」
✅ 从真实失败中取 【20–50 个】简单任务就能开始
💡 早期效应量大（30% → 80%），小样本就有统计意义
不必等攒够几百个
第 1 步：把手动测试自动化
从你每次发布前人工核对的行为入手。bug 单和客服队列是现成的任务来源。
第 2 步：写无歧义的任务 + 参考解
质量标准：两位独立专家应得出相同的通过/失败判定，且两人自己都能做出来。
⚠️ 一条重要的诊断经验： 「多次试验 0% 通过率（0% pass@100）往往说明任务坏了，而不是 Agent 不行。」
参考解的两个作用：证明任务可解、验证评分器配置正确。
第 3 步：平衡的问题集 ⭐
① 方向平衡：正反两面都要测
· 该做的（有信息就该检索）
· 【不该做的】（没必要时不该乱检索）
→ 单向评测导致单向优化！
② 类别平衡：各类任务的比例要合理
💡 真实案例：某搜索评测在「该搜没搜」与「不该搜乱搜」之间反复调了多轮才平衡。 只测前者的话，模型会学成"什么都搜"。
第 4 步：稳健的 harness 与干净环境
⭐ 每次试验从【干净状态】开始
共享状态的危害：残留文件、缓存、资源耗尽
→ 造成与 Agent 表现【无关】的相关性失败
→ 你会以为是模型的问题，其实是上一个测试没清理干净
还要防作弊：别让 Agent 翻 git 历史找答案
第 5 步：设计好评分器 ⭐
最重要的一条：评产出，不评路径。
「不要检查 Agent 是否按特定顺序调用了一串工具…… 评它产出了什么，不评它走了哪条路。」
为什么：Agent 可能发现了一条你没想到但更好的路径。检查路径 = 惩罚创造性。
其他要点：
| 要点 | 说明 |
|---|---|
| 支持部分得分 | 「识别对问题但退款失败」应该显著高于「完全失败」 |
| LLM 评委用结构化 rubric | 分维度打分，不要笼统给一个数 |
| 定期人工校验 | 抽 10 个案例人工核对评委判得对不对 |
第 6 步：读转录 ⭐⭐
「不读大量试验的转录和评分，你不会知道你的评分器是否真的在工作。」
读转录时该问的五个问题：
① 评分器判对了吗？（有没有误判）
② Agent 失败在哪一步？是理解错还是执行错？
③ 它有没有"蒙对"？（结果对但过程荒谬）
④ 有没有它绕了远路但仍然做对的？（说明评分器该更宽容）
⑤ 同一类错误反复出现吗？（那是系统性问题，值得优先修）
第 7 步：监控饱和
能力评测饱和后失去改进信号
（某基准一年内从 30% → 80%+）
→ 饱和的评测应该「毕业」转入回归套件（只保证不退化）
→ 同时建更难的新评测
⚠️ 注意「进步的错觉」： 只剩难题时，大的能力提升只表现为小的分数增长。 有团队一度以为新模型没进步，直到建了能捕捉长任务收益的评测才看出差距。
第 8 步：长期维护
专职团队管基础设施，领域专家和产品团队贡献任务。 可以实践「评测驱动开发」——先建低通过率的能力评测，再驱动改进。
📊 四、两个一致性指标
| 指标 | 含义 | 随 k 变化 | 该用在哪 |
|---|---|---|---|
| pass@k | k 次尝试至少一次成功 | 上升 | 「一次成功就够」的工具（如代码补全，人会挑） |
| pass^k | k 次全部成功 | 下降 | 要求稳定一致的面向客户 Agent ⭐ |
具体感受一下：
单次成功率 75%：
pass@3 = 1 − 0.25³ = 98.4% （看起来很棒）
pass^3 = 0.75³ = 42.2% （其实很糟）
⭐ 同一个系统，两个指标讲的是完全相反的故事
🔑 选错指标 = 优化错方向。面向客户的 Agent 必须看 pass^k。
🌀 五、评测本身会失真（很多团队忽视的一层）
① 基础设施噪声
📌 仅资源配置差异就能在某编码基准上造成 6 个百分点的分差—— 常常大于排行榜上模型之间的差距。
原因：不同模型有不同的默认策略（有的一上来装全套依赖）， 资源配置决定了哪种策略碰巧能成功。此外还有时段效应（API 延迟随流量波动）、集群健康、并发水平。
🔑 实用结论：对未说明配置的、3 个百分点以内的排行榜差距保持怀疑。
「几个点的领先可能是真实的能力差距——也可能只是一台更大的虚拟机。」
② 评测会被模型追上
某性能工程招聘测试被模型连续击穿三个版本，最终不得不从 「模拟真实工作」转向「模拟新颖工作」（分布外的问题空间）。
教训：AI 在有大量训练资料的问题上表现最好；不限时条件下人类专家仍占优。
③ 自动评估发现不了的问题
📌 真实案例：多 Agent 研究系统的自动评估全绿， 但人观察到 Agent 持续偏好 SEO 内容农场而非权威学术来源—— 加入来源质量启发式后才解决。
⭐ 有些问题只有人看转录才能发现。
📋 六、公开基准都在测什么（以及测不到什么）
这一章从头到尾在说「建你自己的评测集」。但你还是绕不开公开基准—— 选模型时你手上只有这些数字，面试时也一定会被问到。 ⭐ 要论证「公开基准替代不了自建评测」，你得先知道它们各自到底在测什么。
| 基准 | 形态 | 测的是什么 | ⚠️ 测不到什么 |
|---|---|---|---|
| SWE-bench | 真实 GitHub issue + 仓库快照，改完跑 fail-to-pass 测试 | 在真实代码库里定位并修复问题 | 只有 Python 开源仓库；测试通过 ≠ 改法合理。⭐ 一个分数值不值得信（数据污染 / 饱和 / 报告条件不对等，以及「100 题只能分辨 8 个百分点」那个能自己算的置信区间）在《大模型全景导论》11 章 |
| SWE-bench Verified | 上面的人工核验子集（500 题） | 同上，但去掉了描述不清、测试本身有问题的脏题 | 同上。⭐ 看到「SWE-bench」三个字先问是哪一版——不同版本的分数不可直接比 |
| τ-bench | 客服场景（零售 / 航司），用户由另一个模型扮演，Agent 带一套业务工具 | 多轮对话中守规则、用对工具、把数据库改成正确的最终状态 | 模拟用户比真人礼貌太多；规则集是人工写的、比真实业务简单。⭐ 它的最大贡献是把 pass^k 摆上了台面（见第四节） |
| GAIA | 现实世界的助理问题，分三级难度，答案是唯一的短字符串 | 多工具协作：浏览 + 读文件 + 多模态 + 多步推理 | 答案唯一才好判，所以天然排除了开放式任务；且网页会变，跑分随时间漂 |
| WebArena | 一组自建可复现的网站（论坛 / 购物 / 代码托管等）里的浏览器任务 | 端到端操作网页，用程序检查最终状态（订单建没建、帖子发没发） | 站点是仿真的，没有真实网站的反爬、弹窗、A/B 改版 |
| OSWorld | 真实操作系统里的桌面任务，跨多个应用 | 跨应用操作，用校验脚本检查最终状态 | 环境重，跑一遍很贵；任务分布是研究者挑的，不是你用户的 |
| BFCL | 一批函数定义 + 一句话请求 | 单次工具调用的格式和参数对不对 | 只测「说得对不对」，不测「做成没做成」——它测的是第 8 章说的那一层 |
这些基准的四个共同盲区
① 任务分布是【别人的】
没有一个基准里有你的业务规则、你的话术、你的边界情况
② 环境都做了简化
仿真站点没有反爬和改版，模拟用户不会骂人也不会说反话
③ 训练数据污染
公开越久污染越可能，这也是【饱和】的一部分（第 8 步）
④ 只给一个总分
不告诉你【哪一类用户】会踩坑 —— 而这恰恰是你上线后最想知道的
⭐ 那读基准的正确姿势是什么
只有两个用途：
| 用途 | 怎么用 |
|---|---|
| 粗筛模型代际 | 判断「这一代能不能干这类活」够用了。⚠️ 但记住第五节那条：3 个百分点以内、又没说明配置的差距，一律当噪声 |
| ⭐ 抄它的评测形态 | 这才是最有价值的一条 —— 基准的分数会过期，它的判分手法不会 |
三个可以直接搬进自建评测的手法：
- τ-bench 的
pass^k—— 面向客户的 Agent 必须看它（第四节） - WebArena / OSWorld 的状态校验 —— 不看 Agent 说了什么，只看世界被改成了什么样。 这正是第 5 步「评产出，不评路径」最干净的实现方式
- GAIA 的唯一短答案 —— 把开放问题改造成能被精确匹配的形式，代码评分器就能接管
🔑 一句话收口：公开基准告诉你「这一代模型大概能做什么」， 只有你自己的 20–50 个真实任务能告诉你「它能不能做你这件事」。 前者选模型，后者决定上不上线——两件事，不能互相替代。
🔨 七、动手：建你的第一个评测套件
| 步骤 | 做什么 | 时间 |
|---|---|---|
| 1 | 翻 bug 单/用户反馈，挑 20 个真实失败场景 | 60 min |
| 2 | 每个写成无歧义任务 + 参考解（过"两人同判"质量关） | 90 min |
| 3 | 先只用代码评分器（能自动判的部分） | 60 min |
| 4 | 跑 5 次试验，读完所有转录 ⭐ | 60 min |
| 5 | 找出评分器判错的案例——这些才是你真正要修的 | 45 min |
💡 第 4 步是最容易被跳过、也最有价值的一步。 不读转录，你建的是一个"看起来在工作"的评测。
🕳️ 八、八个常见坑
| 坑 | 症状 | 修 |
|---|---|---|
| 等稳定了再建评测 | 越晚越难建 | 20 个任务就能开始 |
| 评分器检查工具调用顺序 ⭐ | 惩罚 Agent 发现的更优路径 | 只评产出 |
| 只测正例 | 模型学成"什么都做" | 正反两面都要有 |
| 不读转录 | 评分器有 bug 而不自知 | 每轮读一批 |
| 环境不干净 | 出现与模型无关的失败 | 每次试验重置状态 |
| 看错一致性指标 | 面向客户却只看 pass@k | 稳定性要求高就看 pass^k |
| 信 3 个点以内的差距 | 被基础设施噪声骗 | 多次运行看方差 |
| 拿公开基准当验收标准 ⭐ | 榜上分很高，你的用户还是天天投诉 | 基准只用来粗筛模型代际和抄判分手法；能不能上线由你自己那 20–50 个真实任务决定 |
📚 延伸阅读
🔗 这一章连到哪里
| 去哪 | 为什么 |
|---|---|
| 数据这一关 13 · 评测集也是数据 | 这四处讲的是各自场景怎么评测；评测集本身怎么造、多大够、有没有被污染、评分器准不准、结果该怎么报 在那一章 ⭐ |
👉 这一节对应的框架：Ragas / promptfoo / DeepEval 封装的就是你在这一节手搭的那套。见 16b · 框架这层皮；⚠️ 而「审核器本身也需要被评」在 16c · 接进真实产品。
✅ 检查点
- 没有评测的团队会陷入什么循环？为什么评测越晚建越难？
- 三类评分器各是什么？最常见的组合是什么？
- 0% 通过率通常说明什么？
- 为什么「评产出不评路径」？检查路径会导致什么后果？
- 读转录时该问哪五个问题？
- pass@k 和 pass^k 的区别？75% 单次成功率下 pass^3 是多少？
- 基础设施噪声能造成多大差距？实用结论是什么？
- 什么样的问题只有人读转录才能发现？
- τ-bench、GAIA、WebArena / OSWorld 各测什么？它们共同测不到的是什么？
- 公开基准的两个正当用途是什么？有哪三个判分手法值得搬进自建评测？
👀 答案
- 反应式循环：投诉→复现→改→「感觉好了」→别处退化。越晚越难是因为早期产品需求能自然转成测试用例，系统复杂后你已经说不清"正确行为"该是什么。
- 代码评分器（快便宜客观但脆弱）、模型评分器（灵活但需校准）、人工（金标准，用来校准模型评分器）。最常见组合：单元测试管正确性 + LLM rubric 管质量。
- 任务写坏了，而不是 Agent 不行。
- Agent 可能发现你没想到但更好的路径。检查路径等于惩罚创造性，还会让评测在模型升级后失效。
- ①评分器判对了吗 ②失败在哪步、是理解错还是执行错 ③有没有蒙对 ④有没有绕远路但做对（说明评分器该更宽容）⑤同类错误是否反复（系统性问题优先修）。
- pass@k 是至少成功一次（随 k 上升），pass^k 是全部成功（随 k 下降）。75% 时 pass^3 = 0.75³ ≈ 42.2%。
- 约 6 个百分点，常大于模型之间的真实差距。结论：对未说明配置的、3 个点以内的差距保持怀疑。
- 自动评估全绿但行为有系统性偏好问题——如持续偏好 SEO 内容农场而非权威来源。这类"结果对但来源差"的问题只有人看转录才发现。
- τ-bench：客服场景多轮对话，用户由另一个模型扮演，看 Agent 守不守规则、有没有把数据库改成正确的最终状态（
pass^k就是它推起来的）。GAIA：现实助理问题，分三级难度，要浏览+读文件+多步推理，答案是唯一短字符串。WebArena / OSWorld：前者在自建可复现网站里做浏览器任务，后者在真实操作系统里跨应用操作，都用程序校验最终状态。共同测不到的：你的业务规则和你的用户——任务分布是别人的、环境做过简化、公开越久越可能被污染，而且只给一个总分，不告诉你哪类用户会踩坑。 - 两个用途：粗筛模型代际（且 3 个点以内又没说明配置的差距一律当噪声）和 ⭐ 抄它的判分手法（分数会过期，手法不会）。三个可以搬的手法：τ-bench 的
pass^k、WebArena/OSWorld 的状态校验（只看世界被改成什么样，是「评产出不评路径」最干净的实现）、GAIA 的唯一短答案（把开放问题改造成可精确匹配的形式，代码评分器就能接管）。
🛑 可以停在这里
⚡ 走神救援
没有评测的Agent优化=玄学。没有它就陷进反应式循环：投诉→复现→改提示词→「感觉好了」→上线→别处退化了没人知道。⚠️评测越晚建越难建——早期需求能自然转成用例，系统复杂后你已说不清"正确行为"是什么。三评分器：代码（快便宜但对合理变体脆弱）、模型（灵活但需对照人类专家校准）、人工（金标准，用来校准模型评分器）；常用组合＝单测管正确性＋LLM rubric管质量。八步：①20–50个真实失败任务就够（早期效应量大，小样本就有统计意义）；②bug单和客服队列是现成的任务来源；③无歧义任务＋参考解，标准是两位独立专家判定一致、且自己都做得出来，⚠️0% pass@100往往说明任务坏了，不是Agent不行；④⭐正反平衡，只测正例模型会学成"什么都搜"；⑤每次试验从干净状态开始，还要防它翻git历史找答案；⑥⭐评产出不评路径——查工具调用顺序=惩罚创造性，并要支持部分得分；⑦⭐⭐读转录五问：判对了吗、失败在哪一步、有没有蒙对、有没有绕远路但做对（评分器该更宽容）、同类错误是否反复；⑧监控饱和，⚠️「进步的错觉」：只剩难题时大的能力提升只表现为小的分数增长。pass@k vs pass^k：单次75%时pass@3=98.4%，pass^3只有42.2%——面向客户必须看pass^k，选错指标=优化错方向。⚠️评测本身还失真三层：仅资源配置差异就能造成6个百分点分差，常大于模型之间的真实差距（3个点以内的差距别信）；评测会被追上（某测试被连破三个版本，只好转向「模拟新颖工作」）；💀有些问题只有人读转录才能发现——自动评估全绿，人却看到Agent持续偏好SEO内容农场而非权威来源。公开基准速查：SWE-bench＝真实GitHub issue改完跑fail-to-pass测试（Verified是人工核验过的 500 题子集，⭐看到「SWE-bench」先问是哪一版）、τ-bench＝客服场景、用户由另一个模型扮演、校验数据库最终状态（
pass^k就是它推起来的）、GAIA＝三级难度的现实助理问题、答案是唯一短字符串、WebArena＝自建可复现网站里的浏览器任务、OSWorld＝真实操作系统跨应用任务（后两者都用程序校验最终状态）、BFCL＝只测单次工具调用的格式对不对。四个共同盲区：任务分布是别人的、环境做过简化、公开越久越可能被污染、只给一个总分不告诉你哪类用户会踩坑。⭐所以公开基准只有两个正当用途：粗筛模型代际（3个点以内的差距当噪声），以及抄它的判分手法——分数会过期，手法不会：τ-bench 的pass^k、WebArena/OSWorld 的状态校验（「评产出不评路径」最干净的实现）、GAIA 的唯一短答案（把开放问题改造成能被代码评分器精确匹配的形式）。⭐公开基准告诉你「这一代模型大概能做什么」，只有你自己的 20–50 个真实任务能告诉你「它能不能做你这件事」。
下一节 👉 15-安全-沙箱与提示注入.md