跳到主要内容

Evaluation / Evals

学到 Prompt Engineering、Context Engineering、RAG、Tool Use 和 Agent Engineering 之后，下一步非常关键的一件事，就是学会 Evaluation，也就是评估。

因为从这个阶段开始，一个很现实的问题会出现：

  • 你做了很多优化
  • 改了 prompt
  • 改了检索策略
  • 加了工具调用
  • 加了 Agent 流程

但你怎么知道系统到底是真的变好了，还是只是“看起来还行”？

这就是 Evaluation / Evals 要解决的问题。

一句话说：

Evals 的本质，是用更系统、更可重复的方式判断一个 AI 系统是否真的有效。

1. 为什么一定要学 Evals​

很多 AI 项目一开始都靠“感觉”在优化：

  • 试几个 prompt
  • 随便问几个问题
  • 觉得结果还不错
  • 就以为系统好了

这在初期探索没问题，但一旦系统变复杂，就会立刻遇到几个问题：

  • 你不知道哪次修改真的有效
  • 不知道系统在哪些场景会失败
  • 不知道优化是不是带来了副作用
  • 不知道模型升级后有没有退化
  • 团队里不同人对“效果好不好”理解不一致

所以 Evals 的价值就在于：

  • 让优化有依据
  • 让迭代可比较
  • 让问题可定位
  • 让质量可追踪

2. Evaluation 是什么​

Evaluation 可以理解为：用一套明确的方法，去判断模型或 AI 系统在某类任务上的表现。

它可以评估：

  • 单次回答质量
  • Prompt 是否更稳
  • RAG 是否检索得更准
  • Tool Use 是否调用正确
  • Agent 是否真的完成任务
  • 系统整体是否更可靠

所以 Evals 不是只评估“模型聪不聪明”，而是评估整个系统在真实任务里是不是好用。

3. Evals 在评估什么​

不同系统会评不同内容，但常见会关注下面几类。

3.1 正确性​

答案对不对。

这是最基础的指标。

3.2 相关性​

回答是否真的针对用户问题，而不是看起来很流畅、实际答偏了。

3.3 完整性​

回答有没有漏掉关键点。

3.4 稳定性​

同类问题下，输出是否一致、是否容易波动。

3.5 可依据性​

回答是不是基于给定材料或工具结果，而不是模型自己编。

3.6 工具执行质量​

如果系统会调工具，就要看：

  • 选没选对工具
  • 参数对不对
  • 有没有正确使用结果

3.7 任务完成度​

对 Agent 或工作流来说，更重要的是：

  • 最终任务有没有完成
  • 中间过程是否合理
  • 有没有多余步骤

4. 为什么“看几个例子觉得不错”不够​

因为 AI 系统有很强的偶然性和样本偏差问题。

比如：

  • 你刚好测到了几个简单问题
  • 你只测了自己熟悉的场景
  • 你没有覆盖边界情况
  • 模型在少数例子上表现很好，但整体并不稳

这就会导致一种很常见的错觉：

局部看起来进步了，但整体并没有真的提升。

所以评估一定要尽量系统化，而不是只靠主观印象。

5. Evals 的基本构成​

一个比较完整的评估体系，通常包括下面几部分。

5.1 评估目标​

先明确你到底在评什么。

例如：

  • 提高问答准确率
  • 降低 RAG 幻觉
  • 提高工具调用成功率
  • 提高 Agent 的任务完成率

5.2 测试集​

也就是一批代表性的测试样本。

这通常是 Evals 里最重要的部分之一。

5.3 评分标准​

你必须明确什么叫“好”，什么叫“差”。

比如：

  • 完全正确
  • 部分正确
  • 明显错误

或者：

  • 调对工具
  • 参数正确
  • 结果使用正确

5.4 执行方式​

可以是：

  • 人工评测
  • 自动规则评测
  • 模型评测
  • 混合评测

5.5 结果分析​

评估不是打完分就结束，还要看：

  • 错误集中在哪类问题
  • 哪种修改带来了提升
  • 哪种优化引入了新问题

6. 最常见的评估方法​

6.1 人工评测​

由人直接看输出并打分。

优点：

  • 最接近真实体验
  • 能看出细微质量差异

缺点：

  • 成本高
  • 慢
  • 主观性强

适合：

  • 早期探索
  • 高价值场景
  • 复杂输出质量判断

6.2 规则评测​

用程序规则去判断结果。

例如：

  • JSON 格式是否正确
  • 是否包含必填字段
  • 工具参数是否符合 schema
  • 是否命中了某个标准答案

优点：

  • 快
  • 可重复
  • 便于自动化

缺点：

  • 对开放式任务覆盖有限

6.3 Model-as-a-Judge​

也就是“用模型评模型”。

比如让一个评审模型判断：

  • 回答是否相关
  • 是否忠于资料
  • 是否完整
  • 两个版本谁更好

优点：

  • 规模化方便
  • 比纯规则灵活

缺点：

  • 评审模型本身也可能有偏差
  • 标准不一致时会不稳定

6.4 混合评测​

这是最常见也最实用的方式：

  • 规则评测负责格式和硬指标
  • 模型评测负责语义质量
  • 人工抽样复核关键样本

7. 测试集怎么设计​

很多人一提到 Evals，只想到“打分”，但真正决定评估质量的，是测试集本身。

7.1 测试集要覆盖真实任务​

不要只挑最顺手的问题，要尽量包含：

  • 高频场景
  • 核心场景
  • 边界场景
  • 容易出错的场景

7.2 测试集要分层​

一个好的测试集通常会分层，比如：

  • 简单问题
  • 中等复杂问题
  • 复杂多步问题
  • 极端边界问题

7.3 测试集要有代表性​

样本数量不一定要很大，但要有代表性。

如果全是一个类型的问题，评估结果很容易失真。

7.4 要保留失败样本​

失败案例非常有价值，千万不要因为它不好看就删掉。

很多高质量 eval 集，都是从真实线上失败案例慢慢积累出来的。

8. Prompt 应该怎么评​

如果你在调 prompt，常见会关注这些维度：

  • 是否更准确
  • 是否更稳定
  • 是否更少跑题
  • 是否更符合输出格式
  • 是否更少幻觉

这时候常见方法是：

  • 固定一批问题
  • 对比多个 prompt 版本
  • 看哪个版本整体更优

9. RAG 应该怎么评​

RAG 至少可以分成两层来评。

9.1 检索层评估​

重点看：

  • 正确文档有没有被召回
  • Top-K 结果里有多少有效片段
  • 检索结果排序是否合理

这层主要关注 retrieval。

9.2 生成层评估​

重点看：

  • 回答是否基于检索材料
  • 是否正确回答了用户问题
  • 是否出现幻觉
  • 是否引用了正确依据

也就是说：

  • 检索对不对是一层
  • 基于检索结果回答得好不好是另一层

10. Tool Use 应该怎么评​

Tool Use 的评估重点通常不是“文案写得美不美”，而是流程是否正确。

可以重点看：

  • 是否选择了正确工具
  • 是否在该调用时调用了工具
  • 参数是否正确
  • 是否正确理解工具结果
  • 最终答案是否忠于工具结果

举个例子：

用户问订单状态，如果模型：

  • 选错工具
  • 订单号提错
  • 查到了结果但最终回答没用上

都应该判定为失败。

11. Agent 应该怎么评​

Agent 的评估更复杂，因为它是多步系统。

常见关注点包括：

  • 最终任务是否完成
  • 中间步骤是否合理
  • 有没有重复或无效动作
  • 是否能在有限步数内收敛
  • 是否正确调用了工具
  • 是否保持了状态一致性

所以 Agent eval 通常既看：

  • Outcome
  • 也看 Process

12. 常见指标有哪些​

不同任务的指标不同，但你可以先熟悉这几类。

12.1 Accuracy​

正确率。

12.2 Pass Rate​

通过率。

常用于：

  • 工具调用是否成功
  • 输出格式是否符合要求
  • 任务是否完成

12.3 Hallucination Rate​

幻觉率。

12.4 Retrieval Hit Rate​

检索命中率。

12.5 Task Completion Rate​

任务完成率。

12.6 Latency​

延迟。

有时候一个系统更准了，但慢得不可用，也不能算真正变好。

12.7 Cost​

成本。

在真实系统里，效果、速度、成本通常都要一起看。

13. 一个简单评估例子​

假设你做了一个知识库问答助手。

你可以设计一组 eval：

  • 50 个常见问题
  • 20 个边界问题
  • 10 个文档中无答案的问题

然后评这几件事：

  1. 是否检索到了正确文档
  2. 回答是否正确
  3. 没答案时是否老实说“未提及”
  4. 是否引用了正确依据

这样你就能比较清楚地判断：

  • 问题出在检索
  • 还是出在生成

14. 为什么 Evals 对团队尤其重要​

一旦进入团队协作，Evals 的价值会更明显。

因为它能帮助团队：

  • 对齐质量标准
  • 比较不同方案
  • 追踪版本变化
  • 防止优化引入回归
  • 让讨论从“我觉得”变成“数据表明”

这会极大提高团队做 AI 产品时的协作效率。

15. 最常见的误区​

15.1 只靠主观感觉​

这是最常见的问题。没有 eval 的优化，很容易陷入“看起来更好”的错觉。

15.2 只评简单样本​

这样得到的结果通常会过于乐观。

15.3 只看最终回答，不看中间过程​

对 RAG、Tool Use、Agent 来说，这很容易误判问题来源。

15.4 指标太单一​

只看准确率，不看延迟、成本、稳定性，可能会做出片面的优化。

15.5 没有持续更新测试集​

如果测试集长期不更新，评估很快就会和真实用户问题脱节。

16. 学 Evals 最值得先掌握的 8 个点​

建议优先掌握这 8 个：

  1. 先明确评估目标
  2. 学会设计有代表性的测试集
  3. 学会区分人工评测、规则评测和模型评测
  4. 学会分层评估 Prompt、RAG、Tool、Agent
  5. 学会看准确率之外的指标
  6. 学会对比不同版本
  7. 学会分析失败样本
  8. 学会把评估做成持续流程

17. 一个实用的学习顺序​

如果你要系统入门，可以按这个顺序：

  1. 先理解为什么需要 Evals
  2. 学测试集设计
  3. 学人工评测和规则评测
  4. 学 RAG / Tool / Agent 的分层评估
  5. 学模型评测
  6. 学版本对比和回归检测
  7. 最后再学自动化评估流水线

18. 一句话总结​

Evaluation / Evals 的本质，不是给模型“打个分”这么简单，而是建立一套能持续判断系统质量、定位问题来源、验证优化效果的工程方法。

如果说前面的学习是在教你“怎么搭系统”，那 Evals 学的就是“怎么判断你搭出来的系统是不是真的靠谱”。