12. 如何设计 RAG 的评测指标？

简单回答

RAG 的评测需要分别评估检索质量和生成质量。检索端常用 Recall@K、MRR、NDCG 等经典 IR 指标；生成端需要评估回答的准确性（Faithfulness，是否忠实于检索到的上下文）、相关性（Answer Relevancy，回答是否切题）、以及完整性。近年来 RAGAS 框架提出了一套比较完整的评测方案，结合 LLM-as-Judge 做自动化评测已经是行业主流做法。

详细解释

为什么 RAG 评测比较复杂

RAG 系统是一个多环节串联的系统，效果差可能是检索问题也可能是生成问题，单一指标无法定位根因。必须分环节评测，才能知道该优化哪个环节。

另一个难点是"标准答案"的获取。检索端评测需要 query-document 的相关性标注（哪些文档是正确答案），生成端评测需要参考答案或人工判断。标注成本高是 RAG 评测的最大实际障碍。

检索端评测指标

Recall@K 是最核心的指标。在 Top-K 个检索结果中，正确文档至少出现一个的比例。比如 Recall@5 = 0.85 表示 85% 的查询在前 5 个结果中包含了正确文档。这个指标直接反映了检索有没有"找到"正确答案。

MRR（Mean Reciprocal Rank） 关注正确文档的排名位置。

其中 ${\text{rank}}_i$ 是第 i 个 query 对应的正确文档在结果中的排名。MRR 越高说明正确文档排得越靠前。

NDCG（Normalized Discounted Cumulative Gain） 是更细粒度的排序指标，考虑了多个文档的相关性等级（不只是"相关/不相关"的二元判断），以及位置越靠前贡献越大的折扣效应。适合有多档相关性标注的场景。

Hit Rate 是最简单的指标——检索结果中是否包含正确文档，只看有没有不看排名。适合快速粗评。

实际项目中，Recall@K 和 MRR 用得最多，因为直观且好解释。K 的取值取决于你实际会送给模型多少个 Chunk——如果最终只取 Top-5 送给模型，那 Recall@5 就是最关键的指标。

生成端评测指标

生成端的评测比检索端更难，因为自然语言的回答很难用简单的数值指标衡量。

Faithfulness（忠实度） 评估模型的回答是否忠实于检索到的上下文。理想情况下，回答中的每一个事实性声明都应该能在检索到的 Chunk 中找到依据。如果模型自己编造了不在上下文中的信息，Faithfulness 就低。这是 RAG 中最关键的生成端指标——它直接衡量了 RAG 有没有真正起到"减少幻觉"的作用。

Answer Relevancy（回答相关性） 评估模型的回答是否切题。即使回答完全忠实于上下文，如果答非所问，也不是好回答。

Correctness（正确性） 评估回答和参考答案是否一致。这需要有标准参考答案，在有 ground truth 的场景下适用。

Completeness（完整性） 评估回答是否覆盖了问题的所有方面。用户问了三个点，模型只回答了两个，完整性就不够。

LLM-as-Judge

传统的自动评测方法（如 BLEU、ROUGE）基于 n-gram 匹配，对自然语言生成的评估非常粗糙。近年来 LLM-as-Judge 成为主流做法——用一个强大的 LLM（如 GPT-4）来充当"裁判"，根据预设的评分标准对回答打分。

比如评 Faithfulness 时，可以让 GPT-4 判断"以下回答中的每个事实性声明，是否在参考资料中有依据"。评 Relevancy 时，让 GPT-4 判断"回答是否充分回应了用户的问题"。

LLM-as-Judge 的优势是不需要人工逐条标注，可以大规模自动化评测。劣势是存在评判偏差（不同 LLM 的判断可能不一致），以及成本（大量 LLM 调用）。实践中通常会在一个小样本上同时做人工评测和 LLM 评测，计算两者的一致性（如 Cohen's Kappa），如果一致性够高就可以用 LLM 评测替代大规模人工评测。

RAGAS 框架

RAGAS（Retrieval Augmented Generation Assessment）是一个比较完整的 RAG 评测框架，定义了四个核心指标：Faithfulness、Answer Relevancy、Context Precision（检索到的上下文中相关内容的占比）、Context Recall（正确答案的信息在检索到的上下文中被覆盖的比例）。这四个指标分别从不同维度评估了 RAG 系统的质量，而且都可以用 LLM-as-Judge 自动化计算。

评测集的构建

评测集是评测的基础，也是最耗时的部分。常见的构建方式：从业务日志中抽取真实用户 query，人工标注正确答案和对应的正确文档；用 LLM 基于知识库文档自动生成 query-answer 对（相当于"逆向"出题），人工审核后作为评测集；把 bad case 积累起来作为回归测试集。

一个好的评测集应该覆盖不同类型的问题（简单事实、跨文档推理、否定性问题、边界情况），以及不同的 query 表述方式（正式/口语、长/短、单语义/多意图）。规模上几百条通常就够做定量分析了，不需要上万条。

面试时可以这样答

RAG 评测要分检索和生成两个维度。检索端看 Recall@K 和 MRR，评估"正确文档有没有被找到、排名靠不靠前"。生成端看 Faithfulness、Answer Relevancy 和 Correctness，评估"回答是否忠实于上下文、是否切题、是否正确"。

自动化评测主流做法是 LLM-as-Judge——用 GPT-4 之类的模型当裁判打分。RAGAS 框架定义了一套比较完整的指标体系，实际项目中可以直接复用。但 LLM 评判会有偏差，所以要在小样本上和人工评测做一致性校验。

评测集的构建是最耗时的环节。实际中我一般从线上 bad case 积累，加上用 LLM 基于文档自动生成 QA 对、人工审核的方式来构建，几百条就够做定量分析了。重要的是覆盖不同类型的问题和不同的 query 表述方式。

常见追问

1. LLM-as-Judge 的评分和人工评分一致性有多高？怎么提高？
2. 你在项目中用了什么评测工具？RAGAS 的具体使用体验如何？
3. 评测集需要多大规模才够？怎么平衡标注成本和覆盖度？