目录
当你构建完一个 AI 智能体 之后，总会撞上同一堵墙："好了，但它真的能用吗？" 你改了提示词、换了模型、加了工具——而用来凭数据而非凭感觉来判断这些改动是让效果变好还是变差的机制，就是 Evals（评估）。
LLM 对同一个输入每次都可能产出不同的结果（它是概率性的）。所以只凭"看起来能用"就上线，会在生产环境中埋下悄无声息的回退和边缘用例的失败。本文将讲清楚 Evals 是什么、衡量质量的五种方法、面向智能体的专属评估，以及如何从小做起——写给实践者。
30 秒看懂核心结论
如果你只想读一句
1. 为什么你需要 Evals
普通软件是确定性的：相同输入，相同输出。正因如此，检查"输出是否与预期值一致"的单元测试才管用。但 LLM 是概率性的——哪怕是同一个问题，每次回来的措辞或框架都会略有不同。用AI 智能体 vs RPA 里的说法，它不是确定性的"手"，而是概率性的"脑"，所以直接照搬精确匹配的测试是行不通的。
这里往往会冒出三种失效模式。
你手动试了几个例子，就断定"感觉更好了"。你根本没注意到另一个用例已经坏了。
你改了提示词或模型，只有某一类输入变差了。你是从生产环境的投诉里才发现的。
"它偶尔会返回一些奇怪的东西。"因为它是概率性的，试一次未必能复现，所以你无从追查原因。
Evals 能一次性防住这三种。准备一个评估数据集，每次改动都对整个集合打分，再比较分数——仅此一点就能把"凭感觉"变成"看数据"，让回退无所遁形。你把越多的判断交给智能体，Evals 就越会和护栏一样，成为质量的基石。
2. Evals 是什么
Evals（评估）＝ 衡量 AI 的输出或智能体的行为是否如预期般正确、稳定地运作。用人类的说法，就是打分。它的构成要素很简单，可以拆成三部分。
你用来评估的输入集合。收集真实的使用样例、过往日志，以及预期中的边缘用例。
把输出转化成分数的方式：精确匹配、规则检查，或让另一个 AI 来打分。
对整个集合打分，比较改动前后，判断是变好还是变差。
Evals 不是"建一次就完事"——它的精髓在于把它当作每次改动提示词、模型或工具时都要跑的回归测试。和测试代码一样，它是一份你需要不断培育的资产。
3. 衡量质量的五种方法
有五种有代表性的打分思路。经验法则是按任务的性质来选，并组合使用多种。
为每个输入准备好预期输出（gold label 金标签），按匹配率打分。最适合答案固定的任务：分类、抽取、是/否判断。
机械地检查正则、精确匹配、JSON 是否合法、必需字段是否齐全。验证"必须始终返回这种格式"很拿手——又快又便宜。
让另一个 LLM 依照评分标准（rubric）打分。适用于答案不唯一的任务：摘要质量、语气、相关性。
在同一数据集上比较改动前后的分数（提示词/模型变更）。能抓住"整体上升、局部下降"这类隐蔽的回退。
对线上日志持续打分并观察。盯住失败率、成本、延迟和输入漂移，尽早发现劣化。
| 方法 | 适用场景 | 成本 | 客观性 |
|---|---|---|---|
| ① 标准答案 | 分类、抽取、判定 | 低 | ◎ 高 |
| ② 基于规则 | 格式 / 结构检查 | 低 | ◎ 高 |
| ③ LLM-as-judge | 摘要、生成、对话质量 | 中 | ○ 取决于评分标准 |
| ④ 回归 | 检测改动带来的回退 | 中 | ◎ 相对 |
| ⑤ 生产环境监控 | 检测线上劣化 | 中–高 | ○ 持续进行 |
关键在于分层："能机械衡量的就机械衡量（① ②），衡量不了的质量用 LLM-as-judge（③），再通过回归和生产环境持续跑起来（④ ⑤）。" LLM-as-judge（③）很好用，但充当裁判的 LLM 本身也会浮动，所以要把评分标准写清楚，并尽可能对照人工打分来校准。
4. 面向智能体的专属评估
对于单次回应（一个输入 → 一个输出），上面五种就够了。但AI 智能体会走多个步骤、自己调用工具，并在途中做决策。所以你必须评估的不只是最终输出，还有整个过程。
它最终是否达成了目标（例如订到了正确的预约）？智能体的首要指标。
它是否用正确的参数、按正确的顺序调用了正确的工具？揪出错误或多余的调用。
步骤与决策的路径是否合理？评估绕路、死循环和无谓的重试。
在同样成功的前提下，token、步数更少、延迟更低更好。这在生产环境里很关键。
要观察这些，需要记录每一步（输入、思考、工具调用、结果）的追踪（tracing）。许多框架以及下文的工具都把追踪和评估打包在一起提供。对于多智能体配置，要保留分层的追踪，好让你能精确定位是哪个智能体出了问题。
5. 如何起步——从小做起
你不必从第一天起就拥有一套完美的评估平台。从一个 20 条的数据集起步是很现实的。
- 收集失败样例：先攒 10–20 个"出过错的输入"。真实日志和投诉是一座金矿——这是评估集的核心。
- 写下预期行为：给每个输入附上"正确答案"或"需满足的条件"。并非所有都需要严格答案（用 ③ 来衡量质量）。
- 选一个打分器：格式检查 → ② 基于规则；答案固定 → ① 标准答案；质量 → ③ LLM-as-judge。起步时用一两个就够。
- 先跑一次建立基线：记录当前的分数。那就是你的参照点。
- 每次改动都跑一遍：改完提示词/模型后，重跑并用 ④ 回归来比较。如果分数下降，就别上线。
- 在生产环境加上观察：一旦上线，就用 ⑤ 监控持续盯住失败率和成本，并把线上真实的坏样例回流进评估集。
💡 小贴士：给你的评估集更多地偏向"你不希望发生的失败"，而非"常见的成功"。把边缘用例、对抗性输入和含糊的请求纳入进来，能让你在改动时主动防住那些容易出问题的地方。一份好的评分标准，就像好的提示词设计一样，越具体就越可复现。
6. 常见陷阱
- 数据集太小 / 太偏：只收集成功案例，会漏掉真实世界的失败。要刻意掺入失败和边缘用例。
- 盲目信任 LLM-as-judge：充当裁判的 LLM 同样会浮动、带有偏见。要把评分标准写清楚，并定期对照人工打分来校准。当心"自卖自夸"（同一个模型既写又夸自己的输出）。
- 只看最终输出：对智能体而言，过程就是一切。若不看工具调用、执行轨迹和成本，你会为一个"碰巧蒙对"的结果点赞。
- 凭一次运行下结论：因为它是概率性的，对重要的评估要多跑几次，观察其方差。
- 不更新评估：规格和使用方式都会变。要持续把新的生产失败案例加进评估集。
7. 主要工具
你可以从自己写脚本开始，但如今有一批专用工具在不断涌现，它们把追踪和评估打包在一起。以下是代表性的例子（均为官方站点）。
| 工具 | 它能做什么 |
|---|---|
| Anthropic Console / Evals | 在 UI 里为 Claude 测试和评估提示词。也可用于比较模型选型。 |
| OpenAI Evals | 一个用于定义和运行 evals 的开源框架。数据集 + 打分器的基本形态。 |
| LangSmith | 追踪 + 评估。记录智能体的每一步，贯穿回归与生产环境监控。 |
| Langfuse | 开源的 LLM 可观测性。把追踪、评估和成本监控整合在一起。 |
| Ragas | 专为 RAG（检索增强生成）打造的评估：相关性、忠实度等等。 |
不管你用哪一个，本质都一样：一个数据集 + 一个打分器 + 坚持比较的纪律。工具只是让这件事更省力。最好的起点，就是一个小小的评估集，哪怕它只是你机器上的一段脚本。
总结
- Evals 是什么："打分"，用数字来衡量 AI 的输出和行为——凭数据而非凭感觉判断好坏。
- 为什么需要它：LLM 是概率性的、结果会浮动，所以单元测试不契合，回退和边缘用例会溜过去。
- 五种方法：① 标准答案 ② 基于规则 ③ LLM-as-judge ④ 回归 ⑤ 生产环境监控。能机械衡量的就机械衡量，衡量不了的质量交给 LLM，并持续跑起来。
- 智能体也需要过程评估：任务成功率、工具调用、执行轨迹、成本。追踪是前提。
- 如何起步：20 个失败样例。建立基线，然后每次改动都跑一遍。
在"我做出来了"和"它能用了"之间，隔着一座名为 Evals 的桥。如果说护栏是阻止失控行为的防守，那么 Evals 就是衡量质量、并持续把它往上推的进攻。一个小小的评估集，就能让智能体开发从"凭感觉"变成工程。
FAQ
Q. Evals 和普通的单元测试有什么不同？
单元测试检查"输出是否与预期值精确一致"。但 LLM 是概率性的，每次产出的结果都不同，所以直接照搬精确匹配是行不通的。Evals 的不同之处在于，它在标准答案匹配之上，组合了适配概率性输出的衡量方式——基于规则的检查、由 LLM 打分，以及跨多次运行观察方差。
Q. LLM-as-judge（让 AI 打分）可信吗？
它很好用，但不是万能药。充当裁判的 LLM 可能浮动、带有偏见。关键在于写出一份具体的评分标准、定期对照人工打分来校准，并把生成和打分的角色/模型分开，以避免"自卖自夸"。相对比较（A 和 B 哪个更好）往往比绝对分数更稳定。
Q. 我需要多少条评估项？
从 10–20 条起步就很不错了。哪怕只有几条，也能帮你做"改动后分数是升还是降"的相对比较。现实的做法是，通过不断加入生产环境中发现的失败来把它养大。比数量更重要的是把失败、异常和边缘用例都恰当地纳入进来。
Q. 真的需要评估智能体的"执行轨迹"吗？
如果你要把它放到生产环境跑，那就需要。即便最终输出正确，绕路、无谓的工具调用和死循环也会损害成本和可靠性。加上记录每一步的追踪，把过程和任务成功率放在一起看。用例越是涉及权限和副作用——比如业务自动化用例或自动化云运维——过程评估的回报就越高。
