RAG 系统怎么评测？检索命中率、忠实性、支撑度和答案相关性
你的 RAG 系统上线了。
问题抛进去，答案吐出来，看起来挺美。但你有没有想过：这个答案到底是"真懂"还是"瞎编"的？它引用的那些知识，是真的从你给的知识库里找出来的，还是大模型自己"脑补"的？
上篇我们聊完大模型本身的评测——MMLU、HumanEval、MT-Bench 这些 benchmark——现在换个角度。如果你的应用不只是调模型，而是搭了一套 RAG 系统，这时候怎么知道它到底好不好用？
废话不多说，直接开始。
RAG 评测为什么非做不可？
先说个扎心的事实：大模型会"一本正经地胡说八道"。
这个问题业界叫"幻觉"。模型可能用很自信的语气告诉你一个完全错误的答案。RAG（检索增强生成）的核心思路就是：用真实文档给模型套上"紧箍咒"，让它基于事实说话。
但 RAG 不是简单地把文档塞给模型就完事了。它有两个关键环节：
检索阶段：从海量文档里找出最相关的那几块。
生成阶段：让大模型根据检索到的内容组织答案。
每个环节都可能翻车。检索可能找错文档，生成可能偏离原文，甚至可能自己杜撰一个"看起来合理"的答案。
不评测，你就不知道问题出在哪。是检索器不行？还是生成器不听话？或者是两边的"配合"出了问题？
打个比方，就像厨房出品不稳定，你不质检原材料、不看烹饪过程，光端上来尝一口，很难定位问题根源。
所以 RAG 评测的本质是：把"质量检查"拆成几个维度，看看每个环节到底表现如何。
检索命中率：找到正确答案了吗？
先看检索阶段。
检索命中率衡量的，就是你的检索器"找东西"的能力。本质上是在问：用户的问题相关的文档，有没有被成功找出来？
这个能力有个更准确的名字——召回。
你可能会想：召回嘛，找得越多越好？错。
关键是要找得准、找得全、而且排名靠前。
举个例子。用户问"怎么用 Python 读取 JSON 文件"，系统检索出 100 份文档。但排第一的是讲 XML 的，第 50 份才是 JSON 相关的。这种结果，用户体验就很差。
衡量检索质量，常用这几个指标：
MRR（平均倒数排名）：只看最好的那个结果排在第几位。如果第一名就是正确答案，MRR 就是 1；如果排到第 5 名，MRR 就是 0.2。说白了，它关心的是"最好的结果有多靠前"。
MAP（平均精度）：不仅看最好的结果，还考虑所有正确答案的排名情况。如果有 3 个相关文档，分别排第 1、3、10 位，MAP 会比分别排 1、9、10 位更高。
nDCG（归一化折损累计增益）：这个更精细。它不仅看相关性，还考虑排名位置的影响——排在前面的正确答案比排在后面的更有价值。
选哪个指标取决于你的场景。如果是搜索引擎类应用，MRR 最直观；如果是需要全面覆盖的研究场景，MAP 或 nDCG 更合适。
高检索命中率意味着：用户问什么，系统能找到真正相关的文档。前提是，文档本身就在你的知识库里。
但找到文档就够了吗？未必。
忠实性：生成的内容有没有瞎编？
检索做得好，不代表生成也靠谱。
忠实性评估的是：生成的答案和检索到的文档内容一不一致。
说白了，模型有没有"夹带私货"——引用原文 A，却答成了意思完全不同的 B。或者干脆自己编一个"看起来像那么回事"的答案。
怎么判断忠实性？
方法很直接：逐句对比。
把生成答案里的每句话，都在源文档里找对应。如果一句话在原文里找不到任何依据，就标记为"不可靠"。
这就像学生考试。题目问的是课本上的知识点，标准答案是"照抄原文"。学生自己发挥，哪怕说得天花乱坠，对不起，分数要扣。
这里有个微妙的地方：忠实性不要求答案正确。
原文可能是错的，模型照抄了错误内容，这依然算"忠实"。忠实性只管"有没有按原文来"，不管"原文本身对不对"。
那"原文错了怎么办"？
这是另一个问题——知识库质量。忠实性解决的是"模型有没有听检索结果的话"，不是"检索结果本身靠不靠谱"。
忠实性低的典型表现：检索到的上下文明明在说 A，生成答案却在讲 B。原因可能是上下文太杂乱，模型理解偏了；也可能是模型"太有主见"，选择性地忽略了一些内容。
这时候你得检查：是检索噪声太大，还是模型 Prompt 没调好？
支撑度：检索到的上下文真的有用吗？
忠实性说的是"生成内容有没有原文依据"。
支撑度说的是另一个问题：检索到的上下文，对生成答案的贡献有多大？
这里有个容易混淆的点。
检索阶段通常会返回 Top-K 个文档块。但这些块里，有多少真正被生成器用上了？可能检索回来 10 个块，生成答案只用了 3 个，另外 7 个完全没派上用场。
这就是支撑度要回答的问题。
支撑度拆成两个维度：
Contextual Precision（上下文精度）：你检索回来的东西，有多少是真正相关的？
比如问"感冒了能吃海鲜吗"，检索结果里混进了 5 篇旅游攻略、3 篇海鲜做法，只有一篇提到感冒忌口。这种"噪音太多"的情况，上下文精度就低。
Contextual Recall（上下文召回）：生成答案里提到的内容，有多少能在检索结果里找到？
模型回答了一大堆，但很多信息是"自己想的"，检索回来的上下文根本撑不住。这也是问题。
高支撑度 = 检索到的东西，生成器都用上了，而且用得准确。
低支撑度通常有两个原因：一是检索阶段就出了问题，找回来一堆不相关的东西；二是切片策略不当，把完整的信息拆得支离破碎，相关内容散落在不同块里，模型拼不起来。
做个类比。你让实习生做调研，他抱回来 20 本书，但论文里真正引用的只有 3 本。其他 17 本，要么不相关，要么内容重复。这种效率，你说头疼不头疼？
答案相关性：最终回答用户买账吗？
前面的指标都关注"过程"。
检索准不准、引用对不对、上下文有没有用上——这些固然重要，但最终还是要看：用户拿到答案满不满意。
答案相关性，测的就是这个。
注意"相关性"这三个字。它不是说答案必须完全正确，而是说答案在语义层面上和问题是否对得上。
举几个例子：
高相关性：问"怎么预约周三上午的专家门诊"，答"您可以通过医院公众号选择科室和医生，预约具体时间段"。直接解决了问题。
部分相关：问"怎么预约专家门诊"，答"专家门诊通常在周一到周五，建议提前网上预约"。答了一些相关内容，但不完整，没有具体说怎么操作。
误导性回答：问"怎么预约专家门诊"，答"普通门诊可以直接现场挂号，专家门诊需要提前三天预约"。看起来有信息，但把"普通门诊"和"专家门诊"搞混了，可能把人带坑里。
还有一种情况：答案看着正确，但故意回避了核心问题。问"XX 药的副作用有哪些"，答"XX 药疗效显著，深受患者好评"。没撒谎，但用户想知道的关键信息一个字没提。
评估答案相关性，要警惕两种干扰：
误导性信息：看起来相关，实际错误。
不完整回答：答非所问，或者只答了一部分。
模型可能"很会说话"，把错误信息包装得看起来很专业。相关性评估就是要识破这种包装，看答案和问题之间的匹配程度。
怎么系统地评测你的 RAG？
理论讲完了，怎么落地？
实际做 RAG 评测，有几个关键步骤：
第一步：建评测数据集
这是最费功夫的，但也是最重要的。
你需要准备一批"问题-答案-上下文"三元组。问题要覆盖真实场景，答案要标注正确内容，上下文要包含支撑答案的原始文档。
关键是覆盖不同的场景和难度：简单的事实问答、复杂的多跳推理、需要排除干扰信息的场景……
数据集质量直接决定评测结果的可信度，garbage in, garbage out。
第二步：选评测维度组合
不是所有场景都要把四个指标全拉满。根据你的应用特性来决定：
客服机器人——答案相关性和忠实性更重要。答非所问或瞎编，后果很严重。
研究助手——支撑度要关注。检索到的东西得真正被用上，不然效率太低。
医疗、法律等专业场景——忠实性压倒一切。一句错误信息可能造成严重后果。
第三步：持续迭代
评测不是一锤子买卖。
每次改动检索策略、调整 Prompt、换了模型版本，都要跑一遍"质检流程"。这和持续集成测试的思路一样，每次合并代码都自动跑用例。
业界有些开源工具支持这个流程，比如 RAGFlow，提供可视化的评测面板，能看到每个环节的具体表现。
第四步：结合真实反馈
指标再完善，也没法完全替代真实用户。
系统评测过了，上线发现用户还是抱怨"答得不对"——这时候别急着否定指标，而是去收集用户实际遇到的问题，可能是评测集没覆盖到的场景。
指标和用户反馈结合，才能形成完整的质量画像。
最后
RAG 评测四大金刚——检索命中率、忠实性、支撑度、答案相关性——各自盯住系统的不同环节。把它们串起来，你就能看清楚系统哪里强、哪里弱。
不过再怎么说，冷冰冰的数字可能很好看，用户却觉得"还是不好用"。这里面的 gap，往往在于评测集和真实场景的分布差异。
你的 RAG 系统准备好了吗？
下次我们把视角从 RAG 这种特定技术方案，扩展到整个 AI 应用的评测问题。离线评测、人工评估、线上反馈——这些手段怎么结合，才能得到一个客观可信的结论？到时候再细聊。