「RAG」怎么量化你的 RAG 效果？

0 前言

本文内容整理自公众号「小林面试笔记」的文章 18. 怎么量化你的 RAG 效果？，用于记录与总结 RAG 相关的核心面试知识点。

「怎么量化你的 RAG 效果？」，可以这样作答：

评估要分两层来看：检索层回答"该召回的有没有召回到"，看 Hit@K（Top-K 里有没有正确答案，回答"找到没"）和 MRR（正确内容排得多靠前，回答"多快找到"）；生成层回答"答案质量好不好"，用 RAGAs 框架的四个指标：Faithfulness（答案有没有忠实于检索内容，衡量幻觉）、Answer Relevancy（答没答到点子上）、Context Recall（需要的知识被召回多少）、Context Precision（召回的相关内容排得靠不靠前）。

有两句话必须说在前面：一是一定要在自己的业务数据上跑评测，不能只看别人的离线排行榜，排行榜分数再高也不代表你的知识库好用；二是离线指标只是手段，线上指标才是最终衡量标准——用户点踩率、追问率、转人工率这些真实反馈，比任何离线评分都更能说明系统好不好用。离线指标帮我们发现病，线上指标才是最终疗效。

1 什么是 RAG 评估？

一句话定义：用一套可量化的指标体系，持续测量 RAG 系统"回答得好不好"，并且能把"好不好"拆解到具体环节——是检索没找到，还是生成没答好，都能通过数字看出来。

注意"持续"这个词。RAG 系统不是搭好就跑一辈子的：

  • 知识库更新了——明天就可能有新文档进来；
  • 用户提问方式变了——上个月大家问"怎么退",这个月变成"我想取消订单"；
  • Embedding 模型换了、Chunking 策略调了——任何一环的改动都会连锁影响最终答案。

每次改造都是系统的一次"变脸"，不重新评估就等于蒙眼开车。所以 RAG 评估不是上线前做一次的体检报告，而是伴随系统一生的仪表盘。

2 为什么需要 RAG 评估？

很多早期团队靠人工抽查来验收，随机挑几条问答让同学看一眼"还行不行"。这种做法有三个致命的毛病：

第一，靠感觉调优没有方向。 抽样样本太少，几条问答代表不了整体质量，结论天然不可靠。你可能有这种感觉——“感觉最近回答变差了”，但差在哪、差了多少，说不出来。

第二，出问题不知道该查哪里。 用户说答得不对，是检索没召回到相关内容，还是 LLM 自己发挥跑题了?没有数据支撑，排查全靠猜，和大夫不拍片直接开药一个道理。

第三，优化完无法验证有没有用。 换个 Embedding 模型、调了个 Rerank 权重，效果到底是变好还是变坏？没有人能给出一个"可对比"的结论，技术决策全凭嘴仗。

评估的本质，就是把"这套系统好不好用"的主观感受，转化成可以追踪、可以对比、可以指导决策的客观数字。有了数字，调优才谈得上方向，验收才谈得上标准。

3 为什么 RAG 评估很难？

评估难，难在三个地方：

难点一：答案没有唯一标准。 这是和传统搜索引擎评估最不一样的地方——搜索是"这个文档该不该排前面"，有标准答案；RAG 回答的是自然语言，同一个问题可以有很多种正确说法，你没法拿 Excel 对答案。

难点二：问题可能出在两个环节。 答案不好，可能是检索层没找到好资料，也可能是生成层把好资料答坏了。把"结果不好"的锅同时给两个环节，等于没定位问题，下一步优化无从谈起。

难点三：人工标注成本高、难持续。 真要人工判断每条回答好不好，人力和时间都撑不住，尤其系统需要定期重新评估的时候。

既然切成一个大问题没法下手，解决办法就是把评估拆成两层分开衡量：先看检索层，再看生成层，各算各的账，问题自然精准定位：

为什么 RAG 评估很难：自然语言没有标准答案，需要按检索层、生成层分开评估

4 第一层：检索层评估

评估检索层，需要先准备一份测评数据：一批"问题 + 对应的正确 chunk ID"。这批数据怎么来？要么从历史问答里人工标注，要么找领域专家整理——总之必须提前准备好"标准答案"，后面两个指标都要拿它当参照系。

4.1 Hit@K——找到没？

Hit@K 回答的问题是"正确的内容在不在召回结果里"。 把 Top-K 个检索结果摆到你面前，你要找的那个 chunk 在不在里面？在就命中，不在就没命中，对所有测试问题求个比例就是 Hit@K。

怎么用？可以参考以下经验值：

  • Hit@5 低于 0.7，说明检索层本身有问题——该找的经常没找回来，得先解决召回；
  • Hit@5 高于 0.8，说明检索层大概率是好的，问题多半出在生成层，别再死磕检索了。

4.2 MRR——多快找到？

MRR（Mean Reciprocal Rank，平均倒数排名）回答的问题是"正确的内容排得有多靠前"。 对每个问题，取正确 chunk 在召回结果里的排名，算它的倒数，再对所有问题求平均：

MRR=1N∑i=1N1rankiMRR = \frac{1}{N}\sum_{i=1}^{N}\frac{1}{rank_i}

排第一得 1 分，第二 0.5，第三约 0.33，第五 0.2——排得越靠前分越高。MRR 低于 0.5，通常说明 Rerank 的效果不够好，相关内容被淹在后面了。

4.3 两个指标怎么配合？

一句话区分：Hit@K 是"找到没"，MRR 是"多快找到"。

举一个很典型的例子：假设 Hit@5 = 0.9 但 MRR = 0.3——说明 90% 的问题正确答案都在 Top-5 里，但普遍排在很靠后的位置。内容找回来了，但排序完全没谱，这和"答案排在第一名"的用户体验是天壤之别。单纯看 Hit@K 会高估检索质量，两个指标配合起来，才能精确定位检索层的问题出在哪一步（召回没召回全 vs 排序没排好）：

检索层评估：Hit@K 回答"找到没"，MRR 回答"多快找到"

5 第二层：生成层评估（RAGAs 框架）

5.1 LLM-as-a-Judge：让 LLM 当裁判

生成层评估的核心难点是"没有标准答案"，那怎么打分？**RAGAs（Retrieval Augmented Generation Assessment）**是业界用得最多的 RAG 端到端评估框架，它的核心思路是 LLM-as-a-Judge——用 LLM 当裁判自己打分，而不是靠人工一条条标注。

为什么行得通？因为判断"这句话有没有依据""这个回答跑没跑题"这类事，LLM 干得比人快得多、便宜得多。把人工标注的成本降到几乎为零，评估才能大规模、持续地跑起来。

5.2 四个核心指标

① Faithfulness（忠实度）：答案说得是不是真的？

把答案逐句拆开，看每一句话在检索到的 chunk 里能不能找到出处——能找到的就是忠实的，纯靠 LLM 自己编的就是不忠实的。这个指标直接衡量幻觉程度，目标值 > 0.8。

② Answer Relevancy（答案相关性）：答的是不是用户想要的？

衡量答案有没有回答用户的问题本身。注意和 Faithfulness 区分开：Faithfulness 问"说的是不是真的"，Answer Relevancy 问"说的是不是用户要的"。举个最经典的例子：用户问"北京的天气怎么样"，你答了三页"北京的历史"，每句话都千真万确、出处齐全——Faithfulness 满分，但 Answer Relevancy 直接不及格，因为答非所问。目标值 > 0.8。

③ Context Recall（上下文召回率）：该找的知识找到全了吗？

回答一个问题需要的信息，有多大比例被检索结果覆盖到了？这个指标需要 ground_truth（标准答案） 做参照：把标准答案里提到的事实，和检索回来的 chunk 比对，看覆盖了多少。覆盖得多说明检索"找全了"，漏得多就是召回不足。目标值 > 0.7。

④ Context Precision（上下文精确率）：有用的内容排得靠前吗？

检索结果里，真正有用的内容是不是都排在前面？同样需要 ground_truth 来判定哪些 chunk 是有用的。这个指标和 Context Recall 是天生一对：Context Recall 关注"该找的有没有找全"，Context Precision 关注"找到的里面，相关的是不是排在前面"——一个管广度，一个管排序。

RAGAs 框架的四个核心指标：Faithfulness、Answer Relevancy（生成层），Context Recall、Context Precision（检索层）

5.3 评估太贵怎么办？降本两个办法

四个指标每跑一轮都要调 LLM，成本确实不低，工程上有两招：

  1. 抽样评估：不需要全量测，挑最有代表性的 200~500 条测试样本跑就行，够说明问题；
  2. 换便宜点的裁判：评判模型从 GPT-4o 降级到 GPT-4o-mini，成本直接降 10 倍，精度损失在可接受范围内——评估要的是"趋势准确"，不需要裁判比选手还贵。

6 通过指标定位问题

分层评估最大的价值，是用指标的组合直接告诉你"该修哪一环"。把四个生成层指标和常见问题对应起来，就是一张排查表：

指标异常 说明的问题 优化方向
Context Recall 低 检索层没召回到正确内容 换更强的 Embedding 模型、调整 Chunking 策略、加多路召回
Context Precision 低 召回的噪音太多，稀释了 LLM 的注意力 加强 Rerank 模型、调低最终送入 LLM 的 chunk 数量
Faithfulness 低 LLM 编造、幻觉多 加强 Prompt 约束、引入引用核查、做检索质量门控
Answer Relevancy 低 答案跑题，答非所问 Prompt 指令不够明确，明确告诉 LLM"请严格回答问题本身，不要展开无关内容"

这么一看就通了：Context Recall 不好，多半是检索该干的活没干好；Faithfulness 不好，多半是生成在乱发挥。指标不是拿来晒的，是拿来指导下一步动作的：

通过评估指标定位问题：Retrieval 低走检索优化，Faithfulness 低走生成约束

7 线上指标：最终衡量标准

离线指标千好万好，用户真实使用才是最终考试。RAG 上线后要盯这几个线上指标：

  • 踩率（thumbs_down_rate）：用户主动点踩的比例，最真实的负反馈，别指望用户天天夸，但用户一定会懒得骂；
  • 追问率（followup_rate）：用户追问同一个问题的比例——答非所问才会追问，说明上次的回答基本没用，用户在反复要同一个答案；
  • 转人工率（escalation_rate）：RAG 放弃回答、转给人工的比例。过高通常说明知识库覆盖不足。注意：因为质量门控（第 17 篇讲过）而上升的转人工率不一定是坏事——宁可转人工，也不要给用户一个错误答案硬撑着；
  • 空回答率（answer_empty_rate）：系统主动说"我不知道"的比例，过高说明知识库急需扩充；
  • 会话解决率（session_resolution_rate）：一次对话能不能把用户的问题解决掉，最综合的"结果指标"。

线上指标和离线指标的关系，是一个持续改进的闭环：

离线测评 → 上线 → 线上观测 → 发现问题 → 离线复现 → 修复 → 再上线

还有一个必须说清的认知：离线指标好，不代表线上一定好。测试集是你自己准备的，和真实用户提问总会有偏差。如果发现"离线评分不错、线上用户却一直点踩"，往往不是系统坏了，而是测试集需要更新，或者指标权重需要调整——该跟着业务跑的，是评测体系本身：

完整评测闭环：离线测评、上线观测、复现修复、再上线的持续改进循环，线上指标是最终衡量标准

8 面试总结

这道题最核心的加分点，是**"分层"的思维方式**——别把 RAG 当黑盒整体评，拆成检索层、生成层两层各算各账。

完整答题框架走四步：先拆两层（检索层用 Hit@K/MRR，生成层用 RAGAs 四指标）→ 补一句"在自己的业务数据上跑"（离线排行榜只能参考）→ 拿出指标定位的能力（Context Recall 低修检索、Faithfulness 低修生成）→ 落到线上闭环（点踩率、追问率、转人工率才是最终标准，离线评测持续为线上服务）。

如果被追问"这些指标的阈值为什么不能通用"，标准回答：阈值是经验参考值，不同业务的数据分布完全不同，必须用自家测试集跑一遍来校准，参考值只是起步点；如果被追问"RAGAs 是怎么算分的"，答案是LLM-as-a-Judge——让 LLM 当裁判按规则打分，四个指标两两配对（Recall/Precision 管检索，Faithfulness/Relevancy 管生成），抽样 200~500 条 + 用 mini 模型做裁判来降成本。

最后记住一句话：RAG 评估不是一次性体检，而是伴随系统一生的仪表盘；离线指标帮我们发现病，线上指标才是最终疗效。

参考

本文图片均来源于公众号「小林面试笔记」，版权归原作者所有。

追逐繁星 > RAG
#AI #大模型 #LLM #RAG
「RAG」怎么量化你的 RAG 效果？
https://marisamagic.github.io/2026/08/17/20260817_RAG评估/
作者
MarisaMagic
发布于
2026年8月17日
许可协议