方法与工具 / RESEARCH REPORT
企业 AI 应用的三层评估:单元评测、轨迹评估与业务验收
从 Anthropic、LangChain、OpenAI 的一手评估实践提炼:单元层评单轮输出、轨迹层评环境终态、业务验收层用 pass^k 衡量每次可靠,并给出四周落地顺序。
摘要
企业 AI 评估分三层:单元层用确定性 grader,轨迹层评 outcome 不评步骤,业务验收层用 pass^k 并把生产事故转成回归用例。
- 体裁
- 研究报告
- 适用对象
- AI 工程负责人、算法工程师、企业 AI 落地实践者
- 参考来源
- 3 项 · 详见文末
企业 AI 应用的三层评估：单元评测、轨迹评估与业务验收
答案是：企业 AI 应用的评估要分三层做——单元层用确定性 grader 评单轮输出，轨迹层看环境终态（outcome）而不是步骤对拍，业务验收层用 pass^k 衡量"每次都可靠"的概率，并把每一次生产事故都转成回归测试用例。
一、先对齐语言：评估的基本词汇
Anthropic 2026 年 1 月的官方工程博客《Demystifying evals for AI agents》把评估的词汇表讲得很清楚，一次 evaluation 的构成是：
- task：单个测试用例
- trial：一次运行——因为模型输出不确定，每个 task 要跑多次
- grader：打分逻辑
- transcript / trajectory：完整记录（输出、工具调用、推理过程、中间结果）
- outcome：环境终态
- harness：端到端跑评估的基建
- suite：任务集合
其中最关键的一组区分是 transcript vs outcome。博客举的例子：订票 Agent 说"你的机票已订好"，这只是 transcript；SQL 数据库里是不是真多了一条预订记录，才是 outcome。很多团队的评估只看了 transcript——Agent 说得头头是道，事其实没办成。
二、第一层：单元评测——评单轮输出
这一层评的是"一次调用答得好不好"，对应分类、抽取、单轮问答这类任务。做法：
- 确定性 grader 能用就用：字符串精确匹配、正则、Python 脚本断言——便宜、稳定、可复现。
- LLM-as-judge 是必要时的补充，不是默认选项。用的时候遵守四条纪律（Anthropic）：
- 必须与人类专家打分校准，没校准过的 judge 分数不可信； - 每个维度写结构化 rubric，并且每个维度用独立的 judge打分，不要一个 judge 管全部； - 给裁判 LLM 一个"出路"：证据不足时允许返回 "Unknown"，防止它为了给分而幻觉； - judge 用的模型和被测模型最好不是同一个，避免"自己给自己打高分"。
三、第二层：轨迹评估——评 outcome，不评步骤
Agent 是多步的，这一层评的是"事办没办成"。这里有一个业内真实的分歧，值得负责人知道：
LangChain 的官方文档提供了 trajectory match 评估器，有 strict / unordered / subset / superset 四种模式——本质上是检查 Agent"是不是按预期的顺序调了预期的工具"，即步骤对拍。
Anthropic 则明确警告这种做法过于僵硬、测试过脆：Agent 常常能找到评估设计者没预料到的合法路径，步骤对拍会"不必要地惩罚创造力"。他们的建议是：评"产出了什么"（outcome），而不是"走了哪条路"。
负责人做决策时记住这个优先级：outcome > 关键中间产物 > 步骤顺序。步骤对拍可以作为调试手段，但不适合当验收标准。
| Grader 类型 | 适用层 | 优点 | 注意事项 |
|---|---|---|---|
| 代码型（确定性） | 单元层、轨迹层的 outcome 断言 | 便宜、稳定、可复现 | 覆盖不了开放式质量 |
| 模型型（LLM-as-judge） | 单元层的开放回答、轨迹层的部分中间产物 | 灵活、能评"质量" | 必须与人类校准；防幻觉；分维度独立打分 |
| 人工 | 抽检、校准 judge、验收争议 | 最可信 | 贵、慢，只用于关键样本 |
还有一条反直觉的经验：0% pass@100（跑 100 次全败）最常说明 task 或评分器写坏了，而不是模型不行。Anthropic 披露过一个实例：Opus 4.5 在 CORE-Bench 上最初只拿到 42%，排查发现是评分过严、任务描述歧义、任务不可复现——修复评估本身后，分数跳到 95%。评估挂零时，先查评估，再怪模型。
四、第三层：业务验收——pass^k 与回归套件
前两层是研发视角，这一层是业务视角：上线后，每一次调用都可靠吗？
Anthropic 引入了两个可靠性指标，负责人应该直接拿去当 SLA 口径：
- pass@k：k 次尝试中至少成功一次的概率
- pass^k：k 次全部成功的概率
算一笔账就知道为什么重要：单次成功率 75% 的 Agent 看起来不错，但跑 3 次全成的概率只有 0.75³ ≈ 42%。博客原话："面向客户的 Agent，用户期望每次都可靠，pass^k 尤其重要。"demo 看 pass@k，上线看 pass^k——这是验收时最容易被演示误导的地方。
评估集的建设也有讲究。Anthropic 的起点建议是 "20–50 个简单任务，从真实失败里取"，而不是一上来就堆几百个 synthetic 用例。评估集是活资产：每一次生产事故、每一条用户投诉，都应该转成新的测试用例，进回归套件。OpenAI 的《Working with evals》文档把这套流程比作 BDD（行为驱动开发）：描述任务 → 用测试输入跑 eval → 分析结果再迭代；一个 eval 必须有两样东西：data_source_config（测试数据 schema，含人工标注的 ground truth）和 testing_criteria（grader）。
时效提醒：OpenAI 正在下线 Evals 平台——2026 年 10 月 31 日起对存量用户只读，2026 年 11 月 30 日彻底关闭，官方建议迁移到 Datasets。如果你的团队还在用 OpenAI Evals 做评估基建，现在就该排迁移计划了。
五、落地顺序：四周起步法
- 第 1 周：从生产日志和客服记录里捞 20–50 个真实失败案例，建成第一个评估集。
- 第 2 周：给能确定性判定的部分写代码型 grader，先让 outcome 断言跑起来。
- 第 3 周：引入 LLM-as-judge 评开放式质量，并与人类专家打分做一次校准。
- 第 4 周：把评估集接进 CI，每个版本发布前跑回归；建立"事故→新用例"的固定流程。
四周后，你拥有的不只是一套分数，而是一套能跟着业务一起长大的评估资产——这才是"评测"和"验收"的区别。
---
参考来源
常见问题
transcript 和 outcome 有什么区别?
transcript 是 Agent 的完整过程记录(说了什么、调了什么工具),outcome 是环境终态(比如数据库里是否真多了一条订单)。评估要盯 outcome,只看 transcript 会被'说得头头是道但事没办成'误导。
为什么不建议用步骤对拍做验收?
Anthropic 明确警告:检查 Agent 是否按特定顺序调特定工具的做法过于僵硬、测试过脆,Agent 常找到合法的新路径。应评'产出了什么'而非'走了哪条路'。
pass@k 和 pass^k 哪个更适合做 SLA?
pass^k(k 次全部成功的概率)。单次成功率 75% 的 Agent,3 次全成的概率只有约 42%。面向客户的场景,用户期望每次都可靠,pass^k 更合适。
评估集从多少用例起步合适?
Anthropic 建议 20–50 个简单任务、从真实失败里取,而不是一上来堆几百个 synthetic 用例;生产事故和用户投诉要持续转成新的测试用例。