前言

很多团队把 RAG 或 RAG Agent 跑通之后，都会很快遇到几个非常现实的问题：

  • 明明回答错了，到底是检索没找对，还是模型没用好证据？
  • 同一个版本今天看起来还行，明天换一批问题就掉分，到底该怎么稳定评估？
  • Agent 已经会调工具了，但你还是不知道它到底是调对了工具，还是只是碰巧把答案说对了？

如果你也在被这些问题反复折磨，这篇文章就是写给你的。

这篇文章我想把 RAG 智能体评测这件事讲清楚，核心目标只有一个：把“感觉效果还行”变成“可以复现、可以对比、可以定位问题”的工程流程。

本文主要参考了 OpenAI Evals / Graders、Ragas、TruLens、LangSmith、阿里云 AI Search、Amazon Bedrock 和 BEIR 的官方资料，并结合工程实践给出一套更容易落地的评测框架。

读完这篇文章，你至少会搞清楚四件事：

  • 检索层到底该看哪些指标
  • 归因层怎么判断模型是不是“有证据地回答”
  • 回答层如何区分“答对了”和“答得好”
  • 如果已经进化成 Agent，还要额外补哪些评测项

一、先说结论：RAG 评测一定要分层，不要只看最终答案

如果你只看“最后回答得对不对”，通常会遇到两个问题：

  • 回答错了，但你不知道是没检索到，还是检索到了却没用上。
  • 回答看起来对，但你不知道它到底是基于证据回答，还是模型自己猜对了。

所以，RAG 智能体最稳妥的评测方式，是把问题拆成至少四层：

  1. 检索层：召回的内容是否相关、是否覆盖了关键事实？
  2. 归因层：最终答案是否真正建立在检索上下文之上？
  3. 回答层：答案是否准确、完整、相关、对用户有帮助？
  4. Agent 层：如果已经是带工具调用的 RAG Agent，还要看工具调用是否正确、任务是否完成。

TruLens 的 RAG Triad 很适合作为入门心智模型，它把 RAG 评测拆成三件事：context relevance、groundedness、answer relevance。这个拆法非常实用，因为它刚好对应“检索是否相关”“回答是否有依据”“最终有没有答到点子上”这三个核心问题。

二、先搭评测集，再谈指标

很多人一上来就问“Faithfulness 用哪个模型评”“Context Recall 怎么算”，但其实更关键的是：你有没有一套像样的测试集。

OpenAI 在 Evals 文档里把评测拆成了两个核心对象：

  • data_source_config：测试数据长什么样；
  • testing_criteria：你用什么规则来判断输出是否达标。

它的示例很清晰：数据集里的每一条样本都要符合一个 JSON schema，并且可以包含 ground truth；testing criteria 则用 grader 去比对模型输出与参考答案。

LangSmith 给出的 RAG 评测流程也非常直接：

  1. 创建包含问题和参考答案的数据集。
  2. 运行你的 RAG 应用。
  3. 用 evaluators 评估结果，例如 answer relevance、answer accuracy、groundedness、retrieval relevance。

换句话说，数据集是地基，指标只是尺子。地基没打好，后面所有分数都不可靠。

我建议 RAG 智能体测试集至少包含这几列

{
  "question": "用户问题",
  "reference_answer": "标准答案或高质量参考答案",
  "golden_facts": ["必须覆盖的关键事实1", "关键事实2"],
  "golden_context_ids": ["理想命中的文档或片段ID"],
  "bad_cases": ["不该出现的幻觉点", "常见误答"],
  "metadata": {
    "difficulty": "easy|medium|hard",
    "scenario": "faq|multi-hop|comparison|tool-augmented"
  }
}

如果你的系统已经是 Agent 形态，我建议再加两列：

  • expected_tools：理想情况下应该调用哪些工具；
  • success_criteria：只要满足什么条件，就算任务完成。

这里补一句，这个 Agent 层字段设计是我基于 Ragas 已经提供 Tool Call Accuracy / Tool Call F1 / Agent Goal Accuracy 这类指标做的工程化延伸，不是对单一文档的直接转述。

三、RAG 智能体常用指标，到底分别在衡量什么？

下面这张表，基本可以覆盖大多数 RAG 场景。

评测层 典型指标 它回答的问题
检索层 Context Relevance / Context Precision / Context Recall / Coverage / nDCG / Recall / MRR 取回来的内容是不是相关、够不够全、排序好不好
归因层 Faithfulness / Groundedness / Citation Precision / Citation Coverage 最终回答是不是基于检索证据，而不是模型胡编
回答层 Answer Relevancy / Answer Accuracy / Correctness / Completeness / Helpfulness / Satisfaction 回答是否答题、是否准确、是否完整、是否对用户有帮助
Agent 层 Tool Call Accuracy / Tool Call F1 / Agent Goal Accuracy 工具是否调对、流程是否走对、任务是否完成

下面分开说。

四、检索层：先别急着评答案，先看“拿回来的东西是不是对的”

1. Context Relevance：检索结果和问题是否相关

Amazon Bedrock 在检索型评测里把 Context relevance 定义得很直白：看召回的文本块是否与问题在语义上相关。Ragas 的 Context Relevance 也是这个意思，它会判断 retrieved contexts 和 user input 是否匹配。

这个指标适合回答一个最基础的问题：

你的检索器到底有没有把“方向”找对？

如果这个分数很低，后面的 Faithfulness、Accuracy 再高也没有太大意义，因为系统可能只是“围绕错误材料认真作答”。

2. Context Precision：召回内容里“有用内容”的占比高不高

Ragas 的 Context Precision 关注的是：返回的上下文里，有多少是真正有助于回答问题的。你可以把它理解成“检索结果的纯度”。

这个指标高，通常意味着：

  • 检索器没带回来太多无关噪声；
  • rerank 或 chunk 策略比较合理；
  • 上下文窗口没有被大量无关内容占满。

阿里云 AI Search 的评测任务里也提供了 Context Precision，当你有 reference answer 时，它会把它看成“参考答案与检索结果之间的准确性”。

3. Context Recall / Coverage：关键证据有没有被找全

Ragas 的 Context Recall，以及 Amazon Bedrock 的 Context coverage，本质上都在回答同一个问题：

支撑正确答案所需的关键信息，检索阶段到底找回来了多少？

这个指标特别适合排查“回答不完整”问题。很多时候模型并不是不会答，而是证据没找全。

阿里云 AI Search 也提供了 Context Recall，把它解释为“检索结果相对参考答案的完整性”。

4. nDCG / Recall / MRR：更传统的检索排序指标

如果你想更系统地评估 Retriever，本质上还是要回到 IR 指标。BEIR 作为一个异构零样本检索基准，被广泛拿来衡量检索系统在多数据集、多领域下的泛化能力；其官方实现里常见的评估指标包括：

  • nDCG@k
  • Recall@k
  • MRR
  • 以及 MAP、Precision 等

这类指标对调 Retriever、reranker、embedding 模型尤其有价值。它们不直接评价最终答案，但对“为什么答案会变差”有很强的解释力。

五、归因层：回答是不是“有证据地回答”

1. Faithfulness：回答里的陈述能否从上下文推出

Ragas 对 Faithfulness 的定义很经典：看生成答案中的 claim，是否可以从 retrieved context 中推导出来。

这个指标几乎是 RAG 评测的必选项，因为它直接对应“幻觉”问题。一个回答即使表面上很顺、很像样，只要里面有关键结论无法从上下文得到支撑，就不应该算高质量回答。

阿里云 AI Search 也提供了 Faithfulness，把它描述为“检索文档与模型答案之间的幻觉率”；Amazon Bedrock 在 response generation 类型的评测里同样把 Faithfulness 作为核心指标。

2. Groundedness：回答是否真正扎根于检索证据

TruLens 的 Groundedness 和 Ragas 的 Response Groundedness 都在做相似的事：判断最终回答是否被上下文支撑。

Ragas 在 Nvidia Metrics 中把 Response Groundedness 定义得更细：它会看 response 的每个 claim 是否能在 provided contexts 中被完全或部分找到。

Faithfulness 和 Groundedness 很像，但工程上我一般这样理解：

  • Faithfulness 更偏“事实一致性”；
  • Groundedness 更偏“答案是否真正建立在证据上”。

如果只能先选一个，我建议先上 Faithfulness；如果系统已经开始做复杂多跳问答、长答案生成或 citation 展示，再把 Groundedness 也补上。

3. Citation Precision / Citation Coverage：做引用型产品时一定要加

Amazon Bedrock 在 response generation 评测里还提供了：

  • Citation precision
  • Citation coverage

这个组合非常值得借鉴。前者更接近“引用得准不准”，后者更接近“该引用的地方有没有引用到位”。如果你的产品面向企业知识库、金融、医疗、法律或内部知识助手，这两个指标的重要性会明显上升。

六、回答层：不是“有依据”就够了，还要“真的回答了用户问题”

1. Answer Relevancy：有没有答到用户想问的点

Ragas 的 Answer Relevancy 非常适合用来抓“答非所问”。它关注的是：

这段回答是不是直接、恰当地回应了原问题？

它不会判断事实真伪，而是判断答案是否围绕问题展开，是否跑题、是否冗长、是否缺关键点。

TruLens 的 Answer Relevance 也属于这一层。很多系统表面看起来“输出很多”，但一旦这个分数低，说明它可能只是写得像答案，并没有真正解决用户问题。

2. Answer Accuracy / Correctness：答案和标准答案到底一致不一致

当你有 reference answer 时，Answer Accuracy 就非常重要。

Ragas 的 Nvidia Metrics 中，Answer Accuracy 衡量的是模型回答与参考答案的一致程度；LangSmith 也把 Correctness: Response vs reference answer 放在 RAG 评测流程里。

这个指标特别适合这些场景：

  • FAQ 问答
  • 企业知识问答
  • 有明确标准答案的客服场景
  • 数据问答、政策问答、产品说明问答

如果没有 ground truth，就不要强上 Accuracy；这种情况下更适合用 Relevancy + Faithfulness + Human Review 组合。

3. Completeness / Helpfulness / Satisfaction：用户视角的最终体验

Amazon Bedrock 在 response generation 类型评测中，还提供了：

  • Completeness
  • Helpfulness
  • Logical coherence

阿里云 AI Search 提供了 Satisfaction，它本质上也是从“用户是否会满意”这个角度来综合看答案。

这些指标的价值在于：它们不是只盯着“对不对”，而是盯着“好不好用”。

例如一个答案可能：

  • 事实是对的；
  • 也有证据支撑；
  • 但只回答了一半，或者表达极差。

这时候 Accuracy 和 Faithfulness 可能都还不错，但 Completeness / Helpfulness / Satisfaction 会把问题暴露出来。

七、如果你的 RAG 已经进化成 Agent，还要多看一层

很多团队现在做的已经不是“纯检索+回答”，而是：

  • 先检索知识库；
  • 再查数据库或 API；
  • 再根据结果规划下一步；
  • 最后汇总输出。

这时候只评 RAG 三件套还不够。

Ragas 在指标总览中已经把 Agent 场景单独列了出来，包括：

  • Tool Call Accuracy
  • Tool Call F1
  • Agent Goal Accuracy

这意味着你至少还要多问三个问题：

  1. 工具调对了吗？
  2. 该调的时候有没有调？
  3. 最终任务到底有没有完成？

这里再强调一次：这部分是我基于 Ragas 的 Agent 指标体系做的工程化展开。对于 RAG Agent，我通常会把最终评测拆成：

  • 检索质量
  • 证据归因
  • 回答质量
  • 工具调用质量
  • 任务完成率

如果再往生产环境走，我还会额外记录 延迟、成本、失败率、人工接管率。这部分属于工程运营指标，不是上面文档里的语义质量指标。

八、一套更实用的落地流程

如果让我给团队落一套“能跑起来”的 RAG 智能体评测流程，我会这么做。

第一步：分场景建数据集

至少分成下面几类：

  • 单跳事实问答
  • 多跳推理问答
  • 比较/汇总类问题
  • 长答案生成
  • 无答案场景
  • 工具增强场景

无答案场景尤其重要，因为它能测出系统会不会“明明没检索到也硬答”。

第二步：把指标按层绑定

我建议最小可用组合如下：

没有参考答案时

  • Context Relevance
  • Faithfulness / Groundedness
  • Answer Relevancy

有参考答案时

  • Context Precision
  • Context Recall / Coverage
  • Faithfulness
  • Answer Accuracy / Correctness
  • Completeness 或 Satisfaction

RAG Agent 场景

  • 上面全部基础指标
  • Tool Call Accuracy
  • Agent Goal Accuracy

第三步：用 grader 把规则写死

OpenAI Graders 的意义就在这里。对于不同类型的问题，你可以选择不同的 grader：

  • string_check：适合非常确定的答案；
  • text_similarity：适合开放式文本答案；
  • score_model：适合让 LLM 作为 judge 做语义评分；
  • multi grader：把多个子评分组合成总分。

例如你完全可以把一个企业知识助手的总分拆成：

总分 = 0.35 * context_recall
     + 0.25 * faithfulness
     + 0.25 * answer_accuracy
     + 0.15 * answer_relevancy

这个权重组合不是官方固定标准，而是工程上的配置思路。关键不是“权重绝对正确”，而是你终于能稳定比较版本 A 和版本 B。

第四步：看分数，也看失败样本

只看平均分非常容易误判。真正有价值的是：

  • 哪类问题掉分最严重；
  • 是检索掉分，还是生成掉分；
  • 是“没找到”，还是“找到了没用上”；
  • 是“答偏了”，还是“答得不完整”。

LangSmith 把数据集、运行结果、评估过程串起来的价值，其实也在这里：让你可以回放失败样本，定位具体链路问题。

九、我更推荐的一套指标组合

如果你现在要开始做 RAG 智能体评测，但又不想一上来就把体系搞得过重，我建议按下面这个优先级来。

第一阶段：先把最核心的三项跑起来

  • Context Relevance
  • Faithfulness
  • Answer Relevancy

这三项能先回答：

  • 检索对不对；
  • 回答有没有依据；
  • 最终有没有答到点子上。

第二阶段：有 reference 之后补齐“准确”和“覆盖”

  • Context Precision
  • Context Recall / Coverage
  • Answer Accuracy / Correctness

这一步会让你真正知道：

  • 证据是否找全；
  • 证据是否干净；
  • 最终答案是不是和标准答案一致。

第三阶段：产品化后补“用户体验”和“Agent 行为”

  • Completeness / Helpfulness / Satisfaction
  • Citation Precision / Coverage
  • Tool Call Accuracy / Agent Goal Accuracy

做到这一步，评测就不再只是模型评测，而是开始接近产品质量评测了。

十、几个常见误区

误区 1：只看最终准确率

这会把检索问题、生成问题、Agent 规划问题全部混在一起，几乎无法定位。

误区 2：没有 ground truth 却强行做 accuracy

如果没有参考答案，就不要迷信 Accuracy 分数。优先做 Relevancy、Faithfulness、Human Review。

误区 3：只做离线评测，不看线上失败样本

离线评测能发现普遍问题，但线上日志才能发现真实用户问题。两者必须结合。

误区 4：把“评测指标”当成“唯一目标”

指标是为了帮助你定位和优化系统，不是为了追求某一个漂亮数字。尤其在真实业务里，低成本、低延迟、可解释、稳定性往往和纯质量分数同样重要。

十一、常见 Q&A

1. 没有标准答案，还能不能做 RAG 评测？

  • 可以。
  • 如果你暂时没有 reference answer，就先别强上 Answer Accuracy。
  • 第一版最小闭环，优先做 Context Relevance、Faithfulness、Answer Relevancy。

2. Faithfulness 和 Answer Accuracy 到底有什么区别？

  • Faithfulness 看的是：这段回答能不能从检索证据里推出。
  • Answer Accuracy 看的是：这段回答和标准答案是否一致。
  • 一个回答可能“有依据但不完整”，也可能“碰巧答对但没依据”，这两个指标刚好能把它们区分开。

3. 做了 RAG Agent，是不是只看 Tool Call Accuracy 就够了？

  • 不够。
  • 工具调对了，不等于任务就完成了。
  • 除了 Tool Call Accuracy，最好再补 Agent Goal Accuracy，看它最终有没有真的完成用户目标。

4. 第一版评测体系最少应该先上哪几个指标？

  • 如果你现在刚开始搭评测体系，我建议先上这三个：
  • Context Relevance
  • Faithfulness
  • Answer Relevancy

这三个指标已经足够帮你判断：

  • 检索方向对不对
  • 回答有没有依据
  • 最终有没有答到用户真正关心的问题

5. 离线评测分数不错，线上就一定没问题吗？

  • 不一定。
  • 离线评测适合发现“普遍问题”，线上日志适合发现“真实用户问题”。
  • 最稳妥的做法，永远是离线指标 + 线上失败样本 + 人工抽检三者结合。

十二、结束语

RAG 智能体评测这件事，说复杂也复杂，说简单其实也简单。最核心的一点是：

不要把 RAG 当成一个黑盒回答器去评，而要把它拆成“检索、证据归因、答案生成、Agent 行为”几个层次分别评。

只要你把这件事做好，评测就不再只是“验收环节”，而会变成你持续优化 RAG 系统的导航仪。

如果你刚开始搭体系，我建议先从这一组开始：

  • Context Relevance
  • Faithfulness
  • Answer Relevancy

等你有了 reference answer，再补：

  • Context Precision
  • Context Recall / Coverage
  • Answer Accuracy

如果你已经在做 RAG Agent，再往上叠：

  • Tool Call Accuracy
  • Agent Goal Accuracy
  • Completion / Satisfaction

这样搭出来的评测框架，才是真的能指导迭代的框架。

看到这里，恭喜你。

  • 现在你应该已经知道，RAG 评测不能只看“最后答得对不对”。
  • 你也应该知道，检索层、归因层、回答层、Agent 层，分别该看什么。
  • 更重要的是，你已经有了一套可以真正落地的评测思路，而不是继续凭感觉调参。

参考资料

如果这篇文章帮你把 RAG 智能体评测这件事理顺了，欢迎多多点赞、关注、收藏，也欢迎转发给正在做知识库、RAG、Agent 的朋友。

  • 点赞：你的一个赞，就是我继续整理这类实战长文的动力。
  • 收藏：后面真要搭评测体系的时候，回来翻这篇会更方便。
  • 关注：后续我还会继续写 RAG、Agent、知识图谱、评测和工程化落地相关内容。
  • 评论：评论区聊聊，你现在做 RAG 评测时最头疼的是哪一步？是测试集难构造、指标不会选，还是线上线下评不一致？
  • 转发：如果你身边也有人在做知识库问答、企业助手或者智能体项目，也可以把这篇文章转给他。

——全文完——

感谢阅读，期待你的点赞 + 关注 + 评论 + 收藏，我们下期见！

# RAG
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

C 语言入门第 1 讲：C 语言常见概念（超详细）

avatar AtomGit开源社区
cover

HITL：让人类随时叫停 AI，并且能优雅地继续

avatar AtomGit开源社区

深入底层：从SAR ADC原理到模拟前端设计，解析高精度数据采集卡的硬件架构

从SAR ADC的微伏级建立精度，到三重隔离的电磁兼容设计，打造一块高精度工业数据采集卡，是对硬件工程师综合实力的极限考验。ZLinear开源电子通过开源的胸怀和硬核的技术，将原本高高在上的工业级方案拉下神坛。如果您正在寻找靠谱的数据采集方案，或者希望深入学习工业DAQ的底层设计，欢迎访问ZLinear官网获取全套资料，让我们共同推动工业测控技术的普及与进步！

avatar AtomGit开源社区