大家都在做 RAG，那么如何评价 RAG 的质量呢？
大家都在做 RAG，那么如何评价 RAG 的质量呢？
RAG 评估这个事情，说难也难说简单也简单。难在大部分人搞混了"该评什么"，简单在只要搞清楚 RAG 管线里哪些环节各自负责什么，评估指标就自然出来了。
我做过几个 RAG 项目，踩过的最大一个坑就是——一开始只盯着最终回答的质量打分，发现分数低了就到处乱调，完全不知道问题出在检索环节还是生成环节。后来把评估拆开了，效率立刻上来了。
先把一个关键问题理清楚：你到底在评什么
RAG 系统不是一个黑盒，它至少有两个独立的环节：检索和生成。检索负责从知识库里找到相关的内容，生成负责基于找到的内容回答用户的问题。
这两个环节各自都可能出问题，而且出问题的表现完全不同：
检索没找到正确内容，后面生成得再好也没用，模型只能瞎编或者说"我不知道"。检索找到了正确内容，但生成的时候模型没好好用这些内容，答案还是不对。检索找到了，生成也用了，但模型自己又加了一些没有依据的内容进去。
如果你不分开评，只看最终回答"对不对"，你根本定位不了问题在哪。回答错了到底是因为没检索到，还是检索到了但模型没用好？不知道这个，你怎么决定是去优化分块策略还是去调 Prompt？
检索环节该看什么
检索环节的核心问题就一个：用户问了一个问题，知识库里有答案，你检索出来的结果里到底有没有包含这个答案。
这里有几个指标用起来比较实在。
召回率（Recall）是最重要的一个。对于每个测试问题，你事先标注好正确答案出自哪个文档块，然后看检索返回的 top-k 结果里有没有包含这个块。100 个问题里有 80 个能在 top-5 里找到正确块，召回率就是 80%。
这个指标反映的是：你的检索管线有没有"漏掉"正确答案。如果召回率低，说明正确答案根本没进入候选集，后面生成环节再厉害也没用。遇到这种情况应该去优化分块策略、换 embedding 模型、做 query 改写，而不是去调 Prompt。
精确率（Precision）看的是另一面：检索返回的 top-k 结果里有多少是真正相关的。你返回了 5 个块，其中 3 个跟问题有关，精确率就是 60%。如果精确率低，说明你检索出来的结果里混了很多不相关的内容。这些不相关的内容塞进 LLM 的上下文会干扰模型的判断，有时候甚至比不给上下文效果还差。
还有一个 MRR（Mean Reciprocal Rank），看的是正确答案在检索结果里排第几位。排第一就是 1，排第二就是 1/2，排第五就是 1/5，取所有问题的平均值。这个指标在你用 rerank 的时候特别有用——rerank 不改变召回率（候选集不变），但会改变排名，MRR 能直观反映 rerank 有没有把正确答案往前排。
我自己实际用下来，最常盯的是 Recall@5 和 MRR。这两个指标基本能覆盖检索环节的大部分问题。
生成环节该看什么
生成环节的评估比检索要复杂一些，因为自然语言的"对不对""好不好"不像检索那样可以精确计算。
最核心的一个指标是忠实度（Faithfulness），或者叫"有没有瞎编"。模型的回答是不是完全基于检索到的文档内容，有没有自己添加文档里没有的信息。RAG 的全部意义就在于让模型"基于事实回答"，如果模型拿到了文档还自己编，那 RAG 等于白做。
评估忠实度最简单的方式是用另一个 LLM 做裁判：把检索到的文档和模型的回答一起丢给裁判模型，让它判断回答里的每一个事实陈述是否都能在文档中找到依据。这个方法不完美，但在实际项目里够用。RAGAS 框架就是用这个思路做的。
第二个是回答相关性（Answer Relevancy）：模型的回答有没有真正回答用户的问题。有时候模型会"答非所问"——检索到了相关文档，也忠实地引用了文档内容，但引用的不是用户想知道的那部分。比如用户问退款流程，模型回答了退款政策的适用范围，内容没错但没回答到点上。
第三个是完整性：用户的问题需要的信息是不是都涵盖到了。比如用户问"标准版和专业版的区别"，正确答案应该从功能、价格、服务支持三个维度对比，模型只说了功能差异，那就不完整。
这三个指标——忠实度、相关性、完整性——我觉得是评估 RAG 生成质量最核心的三个维度。市面上很多评估框架搞出了十几个指标，名字花里胡哨的，但拆开看基本都是在这三个维度上做变体。
这些指标能不能反映实际表现
说实话，能反映一部分，但不能完全反映。
自动评估指标（不管是算 F1、BLEU 这种传统 NLP 指标，还是用 LLM-as-Judge 做评分）都有一个根本性的局限：它们衡量的是"技术意义上的正确"，但用户感受到的"好不好用"比"正确"复杂得多。
举个例子。一个 RAG 系统在我的评估集上忠实度 95%、相关性 90%，数字很好看。但上线之后用户反馈说"回答太长了看不到重点"、"回答的语气太像客服脚本"、"我问的问题它说不知道让我联系人工"。这些问题在自动评估里完全看不出来。
所以我自己的做法是两条腿走路：
自动评估用来做快速迭代。每次改了分块策略、换了 embedding 模型、调了 Prompt，跑一遍自动评估看数字有没有提升。这个过程需要快，不能每次都靠人工看。自动评估的价值不在于它的绝对数字有多准确，而在于它能告诉你"这次改动是变好了还是变差了"。只要指标的变化方向是可靠的，具体数值差个几个百分点不重要。
人工评估用来做阶段性检查。每隔一两周，或者每次做了大的改动之后，让几个人实际用一下，记录哪些问题回答得好、哪些不好、不好的原因是什么。这个过程慢但信息量大，很多自动评估发现不了的问题都是人工试出来的。
评估集怎么建
不管你用什么指标，前提是你得有一个评估集。没有评估集，所有指标都是空谈。
建评估集不需要搞得很复杂。最简单的做法是这样的：从实际的用户提问里挑 100-200 个有代表性的问题，然后人工标注每个问题的正确答案和答案出自哪个文档。格式就是三元组：问题、正确答案、答案来源。
几个容易忽略的点：
问题要有代表性。不要只挑简单的事实性问题（"退款周期是几天"这种），也要包含需要综合多个文档的问题、需要推理的问题、文档里没有答案的问题。最后一种很重要——你的 RAG 系统对"超出知识范围"的问题应该回答"不知道"而不是瞎编，这也是需要评估的。
评估集需要定期更新。知识库的文档会变，用户的提问方式也会变。三个月前建的评估集可能已经不能反映当前的实际使用情况了。
别追求评估集的规模，先追求覆盖面。100 条覆盖各种类型问题的评估集，比 1000 条全是简单事实查询的评估集有用得多。
工具层面
如果你不想从零搭评估管线，有几个现成的框架可以用。RAGAS 是目前用得最多的，它把检索和生成的评估都包进去了，支持用 LLM 做自动评分，Python 接口也比较友好。TruLens 也是类似的思路，侧重于用 LLM 做 feedback function 来评估忠实度和相关性。
但不管用什么工具，核心逻辑都是一样的：把评估拆成检索和生成两个环节，各自用对应的指标来衡量，然后根据哪个环节的指标差来决定优化方向。工具只是让这个过程更自动化一些，思路才是关键。
最后说一点，很多人一上来就问"RAG 的效果怎么评估"，其实更应该先问的是"我的 RAG 系统到底在哪个环节出了问题"。评估不是目的，评估是为了定位问题然后解决它。如果你连评估集都没有就在那调参数，那不管用什么指标都没意义。