Featured image of post RAG 模型效果评估
LLM实践 RAG评估

RAG 模型效果评估

RAG 评估方法总结：从为什么到怎么做

一、为什么要做 RAG 评估？

最近在搭建劳动法 RAG 系统时，我发现一个很现实的问题：辛辛苦苦搭好的系统，到底好不好用？靠几次手动测试显然不靠谱 —— 可能刚好问了简单的问题，也可能漏掉了潜在的漏洞。就像训练深度学习模型时需要 loss 来量化优化方向，RAG 系统也需要一套清晰的评估方法来衡量性能。

于是我翻了些资料，并重点参考了以下两个来源：

这篇文章将结合我实际使用的经验，对常见的 RAG 评估方法、框架与指标做一个总结，希望能为你搭建自己的评估流程提供一些参考。

二、RAG 评估的核心要素

2.1 数据集构建

想评估系统，首先得有 一份结构化的数据集。一个完整的 RAG 评估数据集，通常包含 4 个部分：

  • ① 用户的问题；
  • ② 系统针对问题检索到的内容；
  • ③ 系统生成的最终回答；
  • ④ 参考正确答案（可以是人工标注的标准答案，也可以是公认的权威解释）。

这里有个小细节：大模型的回答往往没有 “唯一正确答案”，只要能准确解答问题，不同表述都可能是合理的。所以评估时更多用 “相似度” 来衡量生成答案和参考答案的距离，而不是非对即错。

那这样的数据集怎么获取？常见的有三种方式：

  • 人工制作：最 “笨” 但最准的方式。比如让标注人员根据知识库设计问题、写参考答案，但成本高、耗时长，适合小范围精准测试。
  • 日志收集：从系统实际运行的日志里提取真实问答对（用户问了什么，系统返回了什么，检索了哪些内容）。这种数据最贴近真实场景，但可能需要清洗（比如过滤无效问题）。
  • 大模型生成：目前最常用的方式。用大模型基于知识库自动生成问题和参考答案，效率极高，能快速扩量。

具体选哪种，主要看评估需求和计算资源（时间、人力、数据量需求）。

2.2 评估方式

有了数据集，接下来要考虑 “怎么评估”。目前主流的评估方式有三种，各有优劣：

RAG评估指标箱线图（本地图片）

三种评估方式

  • 人工评估：靠人来打分。比如让几个标注员对照参考答案，给系统生成的回答打分（比如相关性、准确性）。优点是能处理复杂场景（比如回答的逻辑性、语气是否友好），缺点是主观、耗时，且一致性难保证（不同人标准可能不一样）。

  • 基于规则的评估：用固定规则量化分数。例如 BLEU、ROUGE、F1 等传统指标，或者是“检索到的内容是否包含参考答案中的关键词”“生成回答的长度是否在合理范围”等具体规则。优点是客观、高效，缺点是灵活性差 —— 现实中的问题往往复杂，规则很难覆盖所有情况。

  • 大模型评估：这是目前最主流也是最“智能”的方法。通过提示大模型执行评估任务，让模型根据设定的评分规则给出分数。尽管大模型本身也可能存在不稳定性，但使用大型、高质量模型（如 GPT-4o、DeepSeek-r1等）时，评估结果在多数情况下是稳定可靠的。

2.3 RAG常用的评估指标

RAG 的评估指标五花八门 ——LangChain 里有 14 种，RAGAS 里有 8 种，乍一看有点懵，这么多指标都是在衡量什么性能呢，又该选用哪些。但其实换个角度想就简单了：所有指标本质上都是在衡量 “数据集四要素” （问题， 检索内容，生成回答，参考答案）之间的关系。 比如：

  • 正确性（Answer Correctness）：看 “生成答案” 和 “参考答案” 有多像（内容是否准确，是否覆盖关键信息）；
  • 答案相关性（Answer Relevance）：看 “生成答案” 和 “用户问题” 的匹配度（有没有答非所问，是不是围绕问题展开）；
  • 检索召回率（Retrieval Recall）：看 “检索内容” 是否包含 “参考答案” 的关键信息（有没有漏掉重要内容）。

在 RAGAS 中，这些指标被合理划分为两大类： “检索部分” 和 “生成部分”。毕竟 RAG 的核心就是 “先检索、再生成”，分开评估能更精准地定位问题 —— 比如如果检索指标差，就去优化检索策略（如向量数据库、检索算法）；如果生成指标低，就去调 prompt 或换生成模型。 指标
具体每个指标的计算逻辑，大家可以看看上面的参考的资料（开头提到的视频和博客），里面讲得很细。

2.4 评估框架的作用与如何选择

有了数据集、评估方式、指标，这些框架（比如 LangSmith、RAGAS、Llamaindex）到底起什么作用？

评估框架的作用是整合流程、自动执行、可视化展示，大幅提升工作效率。帮你把零散的步骤串起来。比如你用 RAGAS 时，只需要按格式准备好数据集，指定要评估的指标（比如正确性、相关性），它会自动调用大模型（比如你配置的 OpenAI API），按规则打分，最后返回RAG模型的各项指标分数。

我这次使用了 RAGAS，主要是因为它教程全、代码简单（几行代码就能跑通基础评估），对新手很友好。LangSmith 也值得一提 —— 它更像是一个 “全链路监控平台”，功能丰富，不仅用于评估，还支持链路追踪、模型监控等高级特性，功能更全，但操作稍复杂些，适合需要长期维护 RAG 服务的场景。

三、RAG 评估实践

3.1 数据准备与评估指标选择

由于前一个博客中有一个已经搭建好的劳动法 RAG 模型，我就用这个模式试试评估效果。毕竟之前没有做评估的工作，得自己跑一遍才知道这模型到底效果如何。

看了 Ragas 的文档（Ragas 文档），发现评估流程居然比我想象的简单多了 —— 基本上就是在原来的代码后面多贴几行，就能跑起来。因为 Ragas 用的是 大模型评估 的方式，所以你得先准备一个 API Key 给它调用。它支持市面上主流的大模型服务，我自己有之前申请过的 DeepSeek API，就直接拿来用了。

如果想申请Deepseek api可以在这个网址DeepSeek 开放平台申请，如果只是做demo尝试的话，充值10块20块就可以用很久。

接下来就是数据集的准备，这步也很简单。Ragas 文档 Ragas 文档里给了数据集的示例格式，直接照着它的格式来就行。

数据集格式

我的做法是先把参考的劳动法文献上传给大模型，然后让它帮我生成一批问题和对应的参考答案。比如让它围绕 “试用期工资标准”“解除劳动合同的补偿金” 这类常见问题来出题，这样生成的问题更贴近实际使用场景，最后一共生成了三十组问答对。

然后拿着这些生成的问题，去跑 RAG 模型。模型会返回两部分内容：一是它检索到的相关法律条文片段（也就是 context），二是最终生成的回答。把 “问题 + 检索片段 + 生成答案 + 参考答案” 这四样凑齐，就是一组完整的数据了。

指标方面，我先挑了三个用于尝试：faithfulness、context_recall 和 context_precision。选这三个是因为它们各有侧重：

  • faithfulness（忠实度）：生成答案有没有老老实实基于检索内容；

  • context_recall（上下文召回率）：检索结果里有没有覆盖回答问题所需的全部信息；

  • context_precision（上下文精确率）：检索结果里有多少是真正有用的。

这三个指标一结合，差不多能摸清楚 RAG 在 “检索准不准” 和 “生成靠不靠谱” 这两块的基本表现。

要是想更细致，加指标也特简单。去 Ragas 文档里找它支持的指标列表，比如想加个 answer_relevance（答案相关性），直接把名字加到参数里就能扩展，非常灵活。

3.2 评估结果分析

跑完 30 个问答对的评估后，ragas库会返回一个结果表格，其中每一行是一个数据，每行的具体形式如下

用户输入 查询内容 模型输出 参考答案 指标1 指标2….

那么为了让结果更加直观，以便分析模型效果。我根据这些数据绘制了图表。

箱线图： 把 faithfulness、context_recall、context_precision 三个指标放一张图里，横轴是指标名称，纵轴是分数（0-1 分）。箱线图能直接看出每个指标的中位数、四分位范围，以及有没有极端值。

具体箱线图如下：

箱线图

从该图表中能得到以下结论： ① Faithfulness（忠实度）

  • 中位数大约在 0.75 左右，说明大部分回答都是基于检索内容生成的，虚构或偏离原文的情况相对较少。
  • 上四分位数接近 0.9，下四分位数约在 0.55，说明虽然整体表现不错，但在部分样本上仍有较大波动。
  • 有少数低分样本（最低约 0.25），可能是模型在这类问题上没有很好利用检索信息，出现了“幻觉”或生成了不相关的内容。

② Context Recall（上下文召回率）

  • 除了两个极端低值（接近 0），几乎所有样本的得分都接近 1，说明在大多数情况下，检索器能找到覆盖答案所需信息的文档。
  • 那两个低分异常值可能是检索阶段完全没命中相关内容，导致生成阶段无法给出完整回答，需要重点排查具体问题和文档分块策略。

③ Context Precision（上下文精确率）

  • 得分整体非常集中且偏高，大部分样本在 0.85~1.0 之间，说明检索到的文档大部分是有用的、相关性高的。

3.3 基于评估结果的优化方向

从评估结果来看，这个 RAG 系统整体表现已经不错：检索的 召回率和精确率 都在较高水平，说明多数时候系统能找到对回答有用的文档；而 忠实度 虽然大体良好，但在个别样本上波动较大，偶尔会出现生成“幻觉”或与检索内容不完全一致的情况。

因此，接下来的优化方向可以归纳为三点：

  1. 提升生成阶段的稳定性：通过优化提示词或增加事实校验，减少模型随意发挥的情况；

  2. 降低极端检索失败：在数据切分和向量检索上做改进，确保所有问题都有覆盖到的候选文档；

  3. 进一步提高检索相关性：在召回结果上加入 rerank 或过滤步骤，减少噪音干扰。

整体而言，模型的基础能力是够用的，接下来更多是精雕细琢，让结果在少数极端情况下也能保持稳定可靠。

📓 项目小结

说实话，一开始我对 RAG 的评估是有点发怵的。刚看到那么多指标、框架、教程的时候，感觉信息量特别大，不知道从哪里下手，甚至有点怀疑自己能不能搞定。后来就抱着“先随便试试”的心态，跟着文档慢慢跑，过程中踩了一些小坑，但做着做着就顺了。到最后能跑通一整套评估流程，看到结果出来，其实挺有成就感的。

这次的经历让我意识到，评估真的是 RAG 开发里非常必要的一环。光靠自己问几个问题去试，根本看不出系统的整体水平，也没法知道瓶颈在哪。而有了量化指标，就能直观地看到优点和缺点，后续优化才有方向。

还有一个很深的体会是：其实很多技术点不用自己“造轮子”。像 Ragas 这种库，功能已经很完善了，花点时间看文档就能用起来，能省下不少重复劳动。以后再遇到类似需求，我也会先去找找现成的工具，而不是一开始就想着自己全写。

写这篇笔记也是希望能给和我一样之前没进行过 RAG 评估的朋友一点参考 —— 先动手试试，很多问题在实践里自然就解决了。

( ๑╹ ꇴ╹) ｸﾞｯ!

💻项目源码

💻 项目源码可以访问我的Github：rag_eval

© 2024 - 2025 霜降-Shuang.Jiang
使用 Hugo 构建
主题 Stack 由 Jimmy 设计