Agent 与 RAG 评测指南

1. 这篇文档讲什么

这篇文档专门讲两个问题：

• 怎么对 Agent 做评测
• 怎么对 RAG 做评测

很多人一开始做评测时，容易只盯着一个问题：

“模型回答得像不像人？”

但在工程里，这远远不够。

因为真正要评测的，不只是“说得好不好”，而是：

• 任务有没有完成
• 工具有没有用对
• 检索有没有找准
• 回答有没有依据
• 系统是否稳定可复现
• 成本、时延能不能接受

所以这篇文档的核心目标是：

帮你建立一套更工程化的 Agent 和 RAG 评测方法，而不是只做主观打分。

---

2. 先讲一个总原则

不管评测 Agent 还是 RAG，都建议按 4 层来拆：

1. 组件层

   • 单独评估某个模块
   • 比如检索器、重排器、工具调用器

2. 链路层

   • 看整个流程是否跑通
   • 比如“检索 -> 生成 -> 引用”是否闭环

3. 任务层

   • 看最终业务目标是否完成
   • 比如“是否成功解答问题”“是否成功完成工单处理”

4. 运营层

   • 看线上成本、稳定性、时延、失败率

一句话理解：

不要只测答案，要测整个系统。

---

3. Agent 评测：到底在评什么

Agent 和普通问答模型最大的区别，不是它更会聊天，而是它会：

• 拆任务
• 做规划
• 调用工具
• 根据观察结果继续执行
• 在多步流程里完成目标

所以 Agent 评测的重点通常不是“文采”，而是下面几类能力：

1. 任务完成度
2. 规划与决策质量
3. 工具调用质量
4. 多轮执行稳定性
5. 效率指标
6. 安全与约束遵守

---

4. Agent 评测维度

4.1 任务完成度

这是最核心的一层。

你要先定义：

• 这个任务的成功标准是什么
• 什么叫部分成功
• 什么叫失败

例如：

• 客服 Agent：是否正确解决用户问题
• 测试 Agent：是否正确生成可执行测试脚本
• 工单 Agent：是否成功查询、总结并输出处理建议

常见指标

• Task Success Rate

  • 任务成功率

• Goal Completion Rate

  • 目标完成率

• Pass@1

  • 一次执行直接成功的比例

• Human Acceptance Rate

  • 人工是否接受最终结果

评测关键点

• 成功标准必须可操作
• 尽量避免只写“回答合理即可”
• 最好能写成 checklist 或结构化断言

---

4.2 规划与决策质量

很多 Agent 失败，不是模型不会说，而是：

• 第一步就走错
• 顺序错了
• 漏掉关键步骤
• 提前结束
• 在不该调用工具时乱调用

所以可以评估它的“过程质量”。

可以看什么

• 是否识别出任务需要几个步骤
• 是否先做信息收集再做结论
• 是否在缺信息时知道补查
• 是否会在错误结果后重试或回退

常见指标

• Plan Quality Score

  • 计划质量分

• Step Accuracy

  • 关键步骤命中率

• Recovery Rate

  • 出错后恢复率

• Premature Stop Rate

  • 过早终止率

实战建议

规划质量不一定非要完全自动打分。

更常见的做法是：

• 抽样人工评审执行轨迹
• 给每步定义期望动作
• 用规则检查是否漏关键步骤

---

4.3 工具调用质量

如果 Agent 会调工具，这块一定要单独测。

因为很多系统看起来“答案错了”，本质上其实是：

• 工具选错了
• 参数传错了
• 调用时机不对
• 结果拿到了但没用好

常见指标

• Tool Selection Accuracy

  • 工具选择正确率

• Argument Accuracy

  • 参数正确率

• Tool Call Success Rate

  • 工具调用成功率

• Observation Utilization Rate

  • 是否正确利用工具返回结果

• Unnecessary Tool Call Rate

  • 无效调用率

典型检查项

• 应该调工具时有没有调
• 不该调时有没有乱调
• 参数字段是否完整
• 返回异常时是否处理得当

---

4.4 多轮执行稳定性

Agent 往往是长链路系统，所以要评估稳定性。

同一个任务跑 10 次，结果可能不一样。

这时候就不能只看单次结果，而要看：

• 成功率是否波动大
• 是否容易卡在某一步
• 是否出现循环调用
• 是否会因为上下文变长而性能恶化

常见指标

• Run-to-Run Variance

  • 多次执行波动

• Loop Rate

  • 死循环比例

• Timeout Rate

  • 超时率

• Average Steps Per Task

  • 每个任务平均步数

一个很实用的思路

对同一批任务固定版本、固定配置，多跑几轮：

• 看成功率均值
• 看成功率标准差
• 看失败类型分布

如果平均值还行但波动很大，这个系统在线上通常也不稳。

---

4.5 效率指标

Agent 不是只看能不能做，还要看值不值得这么做。

常见指标

• Latency

  • 总时延

• Token Cost

  • token 成本

• Tool Cost

  • 工具调用成本

• Average Turns

  • 平均轮次

• Average Tool Calls

  • 平均工具调用次数

为什么这块重要

两个 Agent 都能完成任务时，通常要继续比较：

• 谁更快
• 谁更省钱
• 谁更稳定

在真实业务里，这几个指标往往比“文风更自然”更重要。

---

4.6 安全与约束遵守

如果 Agent 能调用外部能力，这块必须纳入评测。

重点关注

• 是否越权访问
• 是否调用了禁止工具
• 是否泄露敏感信息
• 是否遵守业务流程约束
• 是否输出不允许执行的操作建议

常见指标

• Policy Violation Rate

  • 规则违规率

• Sensitive Leakage Rate

  • 敏感信息泄露率

• Unsafe Action Rate

  • 危险动作比例

• Permission Compliance Rate

  • 权限遵守率

---

5. Agent 评测怎么落地

5.1 先构造任务集

评测最怕只拿几个“演示题”。

更合理的是构造一个覆盖真实场景的任务集，至少包含：

• 简单任务
• 中等复杂任务
• 多步骤任务
• 工具依赖任务
• 异常分支任务
• 容易误判的边界任务

一个好任务集应该覆盖什么

• 高价值高频场景
• 历史真实失败案例
• 长尾复杂任务
• 安全红线任务

数据来源

• 线上真实用户问题脱敏后整理
• 历史工单
• 历史失败日志
• 专家手工构造的 challenge case

---

5.2 给每个任务写标准答案，不如写标准判定规则

Agent 任务很多时候不是只有一个标准文本答案。

比如：

• 是否成功调对工具
• 是否最终生成了正确 JSON
• 是否补齐了缺失字段

所以比起写唯一答案，更适合写：

• 成功条件
• 必须出现的动作
• 不能出现的错误
• 输出结构约束

示例

对于“查询订单并总结异常原因”的任务，可以定义：

• 必须调用订单查询工具
• 必须输出订单号、状态、异常原因
• 不允许编造不存在的状态字段
• 若工具返回空，必须明确说明未查到

这就比只比对一段固定文案更稳。

---

5.3 看最终结果，也看执行轨迹

评测 Agent，不能只看 final answer。

因为两个答案都错，背后的原因可能完全不同：

• 一个是没调工具
• 一个是工具调对了，但总结错了
• 一个是中间拿到正确信息，却最终被覆盖掉了

所以建议同时记录：

• 输入
• 每一步 thought 或 action 摘要
• 工具调用日志
• 工具返回结果
• 最终输出
• 判分结果

这样你后面才能定位：

• 是规划问题
• 是工具问题
• 是提示词问题
• 还是模型能力问题

---

5.4 Agent 常见评测方式

方式一：规则评测

适合：

• 输出结构固定
• 任务成功条件明确
• 工具链路清晰

例如：

• 是否调了正确 API
• JSON 字段是否齐全
• 返回码是否正确

优点：

• 便宜
• 稳定
• 可批量运行

缺点：

• 很难覆盖开放式质量

方式二：模型裁判

适合：

• 开放式任务
• 文本质量难以完全规则化

例如：

• 总结是否完整
• 回复是否准确且有依据

注意：

• 裁判模型本身也会有偏差
• 最好给清晰 rubric
• 关键任务最好加人工复核

方式三：人工评审

适合：

• 高价值任务
• 安全敏感任务
• 规则和模型都难稳定判分的任务

优点：

• 质量最可靠

缺点：

• 贵
• 慢
• 不易大规模持续跑

实战上最常见的组合

规则评测做主干，模型裁判补开放项，人工抽检做兜底。

---

6. RAG 评测：到底在评什么

RAG 不是单纯“让模型回答问题”，它至少包含两段：

1. Retrieve

   • 能不能把相关资料找出来

2. Generate

   • 能不能基于资料正确回答

所以 RAG 评测至少要拆成两部分：

• 检索评测
• 生成评测

如果只看最终回答，很容易误判：

• 回答错，可能是没检索到
• 回答错，也可能是检索到了但没用好
• 回答对，还有可能只是模型靠常识蒙对了

---

7. RAG 的评测维度

7.1 检索质量

这是 RAG 的基础。

如果检索阶段没把关键文档找出来，后面生成阶段通常救不回来。

常见指标

• Recall@K

  • 前 K 条结果里，是否召回了相关文档

• Precision@K

  • 前 K 条结果里，相关文档占比

• MRR

  • 第一个正确结果排得靠不靠前

• nDCG

  • 综合考虑排序质量

• Hit Rate

  • 是否至少命中一个相关文档

最常见、最实用的两个指标

• Recall@K
• Hit Rate@K

因为很多业务里，第一目标不是“前几条都完美”，而是：

关键证据能不能先找出来。

---

7.2 上下文质量

RAG 不是“召回文档”就结束了，还要看送给模型的上下文是否真的可用。

这里经常出问题的地方有：

• chunk 切得太碎，信息断裂
• chunk 太大，噪音很多
• 重排不准，关键段落排太后
• 上下文里混入互相冲突的信息

可以关注的指标

• Context Precision

  • 喂给模型的上下文里有多少是有用的

• Context Recall

  • 关键证据是否被纳入上下文

• Noise Rate

  • 噪音片段比例

• Chunk Support Coverage

  • 关键事实是否被上下文覆盖

实战里怎么做

很多团队不会把这层做得非常数学化，而是会人工抽样看：

• 检索到的 chunk 是否真的支持答案
• 关键依据是否完整
• 有没有无关内容挤占上下文窗口

---

7.3 生成质量

即使检索到了正确文档，模型生成时仍然可能出错。

常见检查项

• 是否回答了用户问题
• 是否基于检索内容回答
• 是否遗漏关键条件
• 是否引入文档中不存在的信息
• 是否引用了错误证据

常见指标

• Answer Correctness

  • 回答正确性

• Faithfulness

  • 是否忠于上下文

• Groundedness

  • 是否有依据

• Completeness

  • 是否回答完整

• Citation Accuracy

  • 引用是否准确

---

7.4 幻觉与依据一致性

这是 RAG 最关键的一块之一。

因为做 RAG 的目的，往往就是为了减少幻觉。

重点关注

• 回答中的结论能否在检索上下文里找到依据
• 是否把上下文中的一句话解释歪了
• 是否把多个片段错误拼接
• 是否在没有依据时强行下结论

常见指标

• Hallucination Rate

  • 幻觉率

• Unsupported Claim Rate

  • 无依据断言比例

• Evidence Alignment Score

  • 证据对齐程度

一个实战标准

如果回答中的关键结论无法映射到证据片段，就算生成文字再流畅，也不应判高分。

---

7.5 端到端业务效果

最终还是要回到业务目标。

例如：

• 知识库问答：是否解决了用户问题
• 企业检索助手：是否减少人工查资料时间
• 客服助手：是否提升首问解决率

常见指标

• Exact Match / F1

  • 适合事实问答

• Resolution Rate

  • 问题解决率

• Deflection Rate

  • 是否减少人工转接

• Human Acceptance Rate

  • 人工是否采纳

---

8. RAG 评测怎么落地

8.1 先准备评测问答集

一个基础 RAG 评测集通常包含：

• 用户问题
• 标准答案或参考答案
• 相关文档 id
• 关键证据片段
• 任务类型标签

问题最好做分类

• 事实型问题
• 流程型问题
• 对比型问题
• 多跳问题
• 易混淆问题
• 无答案问题

其中“无答案问题”非常重要。

因为很多 RAG 系统最大的问题不是答不出来，而是：

明明知识库里没有，模型却编了一个答案。

---

8.2 单独评检索，不要只看最终答案

建议先离线评检索器。

也就是对每个 query，先只看：

• 相关文档是否召回
• 排序是否靠前
• chunk 是否覆盖证据

这样你才能定位问题到底出在：

• embedding
• chunk 策略
• topK 设置
• 重排模型
• 召回源配置

---

8.3 再评生成阶段

在检索结果固定的前提下，评估生成器是否：

• 正确使用上下文
• 不编造
• 引用充分
• 回答完整

这一步能帮助你区分：

• 是“找不到”
• 还是“找到了但不会答”

---

8.4 最后做端到端评测

端到端评测要看整个链路：

• query 改写
• 检索
• 重排
• 上下文拼装
• 生成
• 引用

这一步最接近真实线上表现。

但它不适合用来替代组件评测，因为一旦结果差，你很难知道是哪一环出了问题。

所以更好的方法是：

组件评测定位问题，端到端评测验证整体效果。

---

9. Agent 和 RAG 评测的区别

很多人会把这两个混在一起。

其实它们重点不同。

维度	Agent 评测重点	RAG 评测重点
核心对象	多步任务执行系统	检索增强问答系统
关键问题	能不能完成任务	能不能找对资料并基于资料回答
关注过程	规划、工具、状态流转	检索、重排、证据使用
常见失败	步骤错、工具错、流程中断	没召回、证据不足、基于错误上下文生成
主要指标	任务成功率、工具正确率、步数、稳定性	Recall@K、Faithfulness、答案正确率

一句话区分：

• Agent 更偏“会不会做事”
• RAG 更偏“会不会先找到资料，再基于资料说话”

---

10. 一套实用的评测流程

如果你是第一次搭评测体系，可以直接用下面这套顺序。

10.1 Agent 评测流程

1. 明确任务清单和成功标准
2. 构造覆盖不同难度的任务集
3. 记录执行轨迹、工具日志和最终结果
4. 用规则评一批基础指标
5. 用模型裁判补充开放式质量指标
6. 对高风险任务做人工抽检
7. 按失败类型做归因分析
8. 回归对比不同 prompt、工具、模型和策略版本

10.2 RAG 评测流程

1. 准备问答集、相关文档和证据标注
2. 先离线评检索召回与排序
3. 再固定检索结果评生成质量
4. 最后做端到端评测
5. 单独统计无答案问题的拒答能力
6. 同时观察时延、成本和引用质量
7. 建立版本对比基线

---

11. 常见误区

11.1 只看主观体验，不看任务成功

一句“感觉挺聪明”没有工程价值。

真正重要的是：

• 任务是否完成
• 是否可复现
• 是否稳定

---

11.2 只看最终答案，不看过程

尤其是 Agent，如果不看执行轨迹，很多问题根本定位不出来。

---

11.3 RAG 只看生成，不看检索

这会导致你一直调 prompt，却忽略真正的问题可能是召回没做好。

---

11.4 没有无答案样本

没有这类样本，你很难评估系统的“克制能力”。

而在企业知识库场景里，这往往非常重要。

---

11.5 只做一次性评测，不做回归基线

评测不是做一次 PPT，而应该变成持续回归机制。

每次改：

• 模型
• prompt
• 工具
• 检索策略
• chunk 策略

都应该有前后对比。

---

12. 面试里可以怎么讲

如果面试官问你“怎么评测 Agent”或者“怎么评测 RAG”，你可以按这个结构回答。

回答 Agent 的简版

我会把 Agent 评测拆成四层：

• 任务层：看任务成功率和人工采纳率
• 过程层：看规划是否合理、工具是否调对、是否能从异常中恢复
• 系统层：看稳定性、时延、成本、超时率
• 安全层：看是否违规调用、越权访问、泄露敏感信息

落地时我会准备真实任务集，给每类任务定义成功标准，同时记录执行轨迹。评测方法通常是规则评测为主，模型裁判和人工抽检为辅。

回答 RAG 的简版

我会把 RAG 评测拆成检索、生成、端到端三层：

• 检索层看 Recall@K、Hit Rate、排序质量
• 生成层看回答正确性、Faithfulness、是否有依据、是否幻觉
• 端到端层看真实业务问题解决率和人工采纳率

落地上我会准备问答集、相关文档和证据标注，先单独评检索，再评生成，最后做端到端回归，同时加入无答案样本来检查系统是否会乱编。

---

13. 最后总结

你可以记住两句话：

Agent 评测

重点不是“像不像人”，而是“能不能稳定完成任务”。

所以要重点看：

• 任务完成
• 工具调用
• 执行轨迹
• 稳定性
• 成本与安全

RAG 评测

重点不是“答得顺不顺”，而是“有没有先找对证据，再基于证据回答”。

所以要重点看：

• 检索召回
• 上下文质量
• 回答正确性
• 依据一致性
• 无答案时是否克制

如果把这两套思路分清楚，你在做项目、做汇报、做面试表达时都会更清楚。