Evals 到底在评什么？一文拆解 AI 评估的三种方法

高可用架构导读：在 LLM 和 Agent 系统里，evals 就是把好不好变成可重复判断的工程机制。

传统软件主要测试确定性的代码路径，但 AI 输出具有概率性：同一个功能可能因为 prompt、模型、检索数据、工具调用、上下文组织或用户场景变化而表现不同。

evals 的作用，是把业务质量、安全边界、任务完成度、格式约束、推理过程和用户反馈转成可运行的检查：有些用代码判断，有些由人工标注，有些交给 LLM 裁判扩展规模。

成熟团队不会把 evals 当成上线前的一次性考试，而是把它放进完整循环里：从生产 traces 中发现失败模式，沉淀数据集和黄金样例，用 evals 比较 prompt、模型和系统设计改动，再通过 CI 门禁、灰度发布、线上监控和漂移检测持续回流。

对 Agent 尤其如此，因为 Agent 不只是生成一段文本，还会多轮规划、调用工具、读写状态、执行动作；因此 evals 不只是测最终答案，更要观察中间轨迹、工具错误、策略偏移、成本和延迟以及高风险行为。

换句话说，evals 是 AI 工程里的规格、回归测试和质量仪表盘，让团队能从感觉模型变好了走向我们知道它在哪些场景变好了，在哪些场景还不可靠。

今天的文章介绍 AI 评估的三种方法。

作者 Lotte Verheyden 是 Langfuse 的 Product Marketing Engineer & Developer Relations 负责人。她拥有比利时鲁汶大学计算机科学工程硕士学位，2025年加入 Langfuse（YC W23）并移居旧金山。 她专注于 AI 工程实践分享，创作 Langfuse Academy 系列内容，擅长将复杂的技术概念转化为实用指南，帮助开发者构建生产级 LLM 应用。 

AI Engineering Loop 简短回顾

团队通过 AI Engineering Loop 持续改进 AI 系统。它把生产环境中发生的事情（追踪、监控）和开发阶段的结构化迭代（数据集、实验、评估）串联起来。每一次发布的改进都会产生新数据，团队会不断重复这个过程。

你可以在这里^[1]阅读更多内容。

评估如何嵌入这个循环

离线评估位于运行实验和发布变更之间。你有一个数据集，也已经让应用在数据集上跑了一遍，现在需要判断输出是否足够好。

评估通常如何演进

大多数时候，你会先人工审阅输出，建立对应用里什么算好、什么算差的直觉。然后，你会识别值得检查的具体失败模式。一旦这些失败模式可以被精确定义，就可以用专门的评估器自动化检查。

本文接下来会详细介绍不同类型的评估。实践中，你很可能最终会把它们组合起来使用。但一个运行良好的自动化评估体系，几乎总是从人工审阅开始。

人工评估不是一劳永逸的事。好的生产体系会持续让专家审阅输出，用来发现新的失败模式，并保持自动评估器的校准。

评估方法

评估主要有三种方式：人工评估、基于代码的评估，以及使用 LLM 的评估。每一种都适合不同类型的质量检查。

人工评估

人工评估指的是手动查看输出，给输出打分，或者写下你的看法。

这是一个重要过程。阅读输出，你才能真正理解应用实际做了什么、在哪些地方表现不佳，以及针对你的具体用例，什么才算好。有了这种理解，你才知道之后应该构建哪些自动评估器，以及如何定义它们的评判标准。跳过这一步、直接进入自动化评估的团队，最后衡量的往往是一些无关紧要的东西。

人工评估还会产生人工标注，这些标注之后可以作为验证自动评估器的基准真值。

基于代码的评估

基于代码的评估器检查那些可以用确定性逻辑验证的属性。它们速度快、成本低，并且每次都会产生相同结果。

一些天然适合基于代码评估器的检查示例：

• 输出是有效 JSON，或者符合要求的 schema
• 输出包含（或不包含）特定关键词或模式
• 输出保持在长度限制内
• 生成的 SQL 可以无错误执行

它们的局限在于无法评估含义。基于代码的评估器可以检查输出是否包含 “refund” 这个词，但无法判断输出是否正确解释了退款政策。

LLM-as-a-judge

LLM-as-a-judge 评估器使用语言模型为输出打分。AI 应用和 Agent 的质量取决于文本输出质量的评判，而这类评估器正是为了解决这个核心问题。

如果某些质量判断需要理解语言，这就是合适的方法：回答是否与问题相关，语气是否匹配目标受众，摘要是否抓住了源材料的关键点，等等。

LLM 裁判并不完美，用不好很容易翻车。这意味着：

• 模型不会自动像人类专家一样打分，因为它没有专家所拥有的上下文
• 它们需要用人类偏好来校准，以验证它们衡量的确实是你以为它们在衡量的东西
• 它们可能与你的应用 LLM 共享盲点，尤其是在两者使用同一模型家族时

这些限制并不是避免使用 LLM 裁判的理由。一个经过人工标注校准、并由基于代码的检查兜底的 LLM 裁判，可以成为可靠的评估器。

基于参考答案与无参考答案的评估器

基于代码的评估器和 LLM-as-a-judge 评估器，都可以是基于参考答案的，也可以是无参考答案的。基于参考答案的评估器会把输出和预定义的期望输出进行比较，例如正确答案或黄金回答。无参考答案的评估器则只评估输出本身，不需要拿它和基准真值比较。

无参考答案评估器的优势在于，它们可以应用到未见过的生产数据上，而基于参考答案的评估器始终需要一个预先定义好的参考回答。

实践中

什么时候设置评估器

如前所述，你总是从人工审阅开始。完成这一步后，问题就变成：是否应该为你发现的问题设置自动评估器？

问问自己，这个问题是修一次就解决了，还是会反复出现。如果一个简单的 prompt 修改就能解决它，那就直接修改，不需要评估器。但如果你能清楚识别出一个失败模式，并且希望在不同输入上反复测试它，那就适合设置评估器。

应该评估什么？

像有帮助或质量这样的通用属性很诱人，容易被当作起点，但它们很少产生有用信号。检查模糊标准的评估器，只会给出模糊结果。你越能精确定义在你的应用里什么算好、什么算差，评估器就越有用。

一个实用建议：设计评估器时，优先使用二元分数（通过/失败），而不是分级量表（1-5）。二元分数会迫使你清楚定义可接受和不可接受之间的分界。分级量表会引入歧义，比如 3 分和 4 分到底差在哪里，这会让分数更难解释，也会降低不同评估器之间以及跨时间的一致性。

组合评估方法

你关心的每一种质量，都应该有自己的评估器。

多数成熟的评估体系会使用全部三种评估方法^[2]。 它们合在一起，可以让你看到应用整体质量。

从哪里开始

从人工审阅开始，然后只自动化那些需要反复运行的检查。

1. 人工审阅输出^[3]，建立对应用中好坏输出的直觉。
2. 写下你想捕捉的具体失败模式，并尽可能清楚地定义它们。
3. 只有当你需要在大量输入上或跨时间反复测试某个失败模式时，才设置自动评估器。

接下来是什么

如果结果足够好，就可以发布这次变更。一旦上线，循环会再次开始：更新后的系统会产生新的追踪^[4]、新的监控^[5]信号，以及新的改进机会。

一些评估器也应该用到离线实验之外的场景。无参考答案评估器、用户反馈信号，以及其他适合生产环境的安全检查，都可以应用到实时流量上，用来确认生产环境中的质量是否与部署前看到的一致。

如果生产行为符合预期，你就可以更有信心地继续扩展。如果不符合，就把这些案例捕捉到 traces 中，将它们转成数据集^[6]条目，然后运行下一轮实验^[7]。这就是闭环的方式。

原文：[8]

参考阅读

• 做 AI Agent 之前，先装好这 5 样东西
• 我把 Karpathy 的 AutoResearch 搬到了软件开发领域，效果炸了
• 用 Claude 实现多智能体系统：一个人如何跑起 4 个 AI 专家团队
• 别再死磕提示词了，真正拉开差距的是上下文工程