Amadeus的知识库 | RAG 系统优化升级的前提 —— 你真的搞明白了它的评估体系吗？

一、引文

当我们做出来了自己的 RAG 系统，智能客服也好，企业内部知识库助手也罢，把它们上线给用户使用后，难免后面会根据实际落地效果和用户反馈进行系统的优化升级。但是你真的搞懂了怎么去评价一个 RAG 系统的好坏呢？它有哪些评价标准呢？这些标准又受到 RAG 哪些环节的影响呢？如果不知道这些的话，就连最单纯的头痛医头、脚痛医脚都做不到，又何谈用全面的观点看问题，做系统性优化呢？因此在这篇文章中，我将着重讲解 RAG 的评估体系，让大家了解它的各项评估指标，以便对自己的 RAG 系统做监测做优化。

二、系统化评估指标

在介绍 RAG 的系统化评估指标前，我们需要对 RAG 进行分层，主要划分为检索阶段、生成阶段、端到端阶段。每个阶段有各自的评估指标，由此我们可以根据某个指标的数据来确定是 RAG 的哪个阶段出了问题。

1.检索阶段

检索阶段其实就是我们熟悉的拿着查询向量去向量数据库中检索或者根据 BM25 关键词检索召回相关的文档 chunk。

（1）命中率

当多条问答作为测试样本时，召回的 chunk 里面有正确答案就记为命中，反之就是未命中。命中率 = 命中次数 / 总问题数。

命中率存在一个明显的缺点，就是他不关心包含正确答案的 chunk 排在召回的那批 chunk 的第几位，只要那批 chunk 里面有命中正确答案的 chunk，那么那个正确答案 chunk 排在召回chunk 的第一位还是最后一位效果都是一样的，但事实上它们背后反映的检索性能是相差很大的。

（2）MRR

MRR 又叫平均倒数排名，它是在关注命中率的基础上，也关心正确答案 chunk 排在召回的那批 chunk 中的第几位，越靠前分数越高，类似于第一位得 1 分，第二位得 1/2 分，第三位得 1/3 分，最后 MRR = 测试样本总得分 / 总问题数。它比命中率更能反映检索的质量。

MRR 的直觉理解：MRR = 0.7 意味着平均来看，正确答案大约排在第 1.4 位（1 / 0.7 ≈ 1.43）。MRR 越接近 1，说明正确答案越稳定地排在第 1 位。

（3）召回率

命中率和 MRR 都是假设正确答案只存在于一个文档块里面，但是现实中可能正确答案分布在多个文档块，需要将它们全部召回才能拼凑起足以回答问题的上下文。召回率便是基于后一种假设的评估指标，它关注的是检索阶段有没有找全。如果说包含正确答案的文档块一共有 N 个，但是检索阶段只找回了 M 个，那我们就说此次检索的召回率 = M / N。

（4）精确率

精确率跟召回率一样都是基于后一种假设，它关注的是检索阶段找的准不准的。如果说检索阶段召回的文档块一共有 N 个，但是真正有用的只有 M 个，那我们就说此次检索的精确率 = M / N。

2.生成阶段

检索阶段我们重点是在它有没有召回正确的 chunk，在生成阶段我们主要是看大模型有没有好好利用这些 chunk 来回答。

（1）忠实度

忠实度主要是看大模型有没有严格遵照返回的 chunk 进行回答，还是说编造了 chunk 中没有的信息进行回答。忠实度不等于正确率，有可能文档内容就是错的，但是大模型忠实度高，严格遵照 chunk 回答，那么答案也就是错的。

（2）答案相关性

答案相关性是指大模型的回答是不是跟用户问题的答案是相关的，它关注的是答案是否正确的问题。

3.端到端的评估指标

所谓的端到端其实就是看大模型最终的回答有没有解决用户问题

（1）答案正确率

以答案正确率作为标准首先必须有一个标准答案，将大模型回答按照语义相关性跟标准答案进行匹配，计算相关性得分。

（2）兜底率

所谓的兜底就是说大模型无法召回与用户问题相关的 chunk，也可以理解为当前 RAG 的知识库中的知识不具备回答该问题的能力，这个时候又不能让大模型不输出或瞎编，所以通常会在它的 Prompt 中加入兜底策略，即召回的 chunk 中没有相关的就说返回友好语句说自己不知道。那兜底率其实就是大模型兜底行为发送的概率。

（3）用户满意度

在真实的线上场景中，最大的业务指标其实是用户的满意度，即用户根据使用反馈可以选择点赞或拉踩，我们就可以记录这些行为数据对 RAG 进行调优。

三、LLM-as-Judge

在上一小节中我们已经了解了 RAG 的一些系统化评估指标，从检索阶段到端到端的评估指标，那么应该如何计算你 RAG 系统的这些指标呢。一种常见的策略是 LLM-as-Judge + 人工定期审查。所谓的 LLM-as-Judge 其实就是用另一个不同于检索、生成阶段的大模型（避免自我偏好），对另一个大模型的检索阶段和生成阶段还有端到端的评估指标，按照上一小节提到的那些评估指标进行打分。其好处在于评估模型也具备理解语义的功能，因此只要把会话记录扔给他，他就能轻松计算出生成阶段的忠实度、答案相关性这些指标，如果人去一个个看无疑是非常浪费时间的。

简而言之：用一个大模型来充当评委，对另一个大模型的回答打分。这就是 LLM-as-Judge。

给评委模型一个评分 Prompt，明确告诉它评分维度、评分标准，让它输出结构化的评分结果。设计三个评分 Prompt，分别评估忠实度、相关性和正确率。

人工定期审查是作为一种保险，随机抽查评估模型的打分样本，与人力打分进行对比，然后看评估模型打分的准确率，再考虑是否对评估模型进行优化。

四、总结

我们今天主要围绕 RAG 系统评估展开，指出上线后优化需先明确评估标准，将 RAG 分为检索、生成、端到端三阶段，分别介绍各阶段核心评估指标（如检索阶段的命中率、MRR 等，生成阶段的忠实度等，端到端的正确率等）。同时提出采用 LLM-as-Judge（用独立大模型按设定标准打分）结合人工定期审查的方式，高效计算各项指标，助力 RAG 系统监测与优化。