RAG 评估（RAGAS 与指标体系）

「RAG 系统怎么评估好坏」是工程落地绕不开的问题，也是高频面试题。RAG 是检索 + 生成的串联，必须拆开两段分别评，否则定位不了问题。本文讲清 RAG 评估的指标体系、RAGAS 框架、无参考评估，以及怎么搭建评估闭环。通用评估方法见模型评估。

一、为什么 RAG 评估要拆两段？

RAG 答错可能来自两个完全不同的环节：

问题 ──检索──► 上下文 ──生成──► 答案
        ↑                ↑
     检索错了？        生成错了？
   （没召回对的）   （召回对了但没用好/编造）

只看「最终答案对不对」无法定位问题：答案错了，是检索没找到，还是找到了但模型没用好？
所以 RAG 评估必须分别度量检索质量和生成质量，再看端到端。

二、检索质量指标

指标	含义	关注
Context Recall（上下文召回率）	回答所需的信息有没有被检索到	漏不漏
Context Precision（上下文精确率）	检索到的内容有多少是真正相关的	准不准、排序好不好
Hit Rate / Recall@k	前 k 个结果里有没有命中相关文档	召回
MRR / NDCG	相关文档排得够不够靠前	排序质量

召回 vs 精确的权衡：召回不够 → 答案缺信息（漏答）；精确不够 → 上下文里塞了噪声，可能引发幻觉、稀释关键信息（lost in the middle）。两者都要看。

三、生成质量指标

指标	含义	抓什么问题
Faithfulness（忠实度）	答案是否忠于检索到的上下文（没编造）	幻觉
Answer Relevancy（答案相关性）	答案是否切题（答到点上）	跑题/答非所问
Correctness	答案与标准答案是否一致	事实正确（需参考答案）

Faithfulness 是 RAG 最核心的生成指标：RAG 的承诺就是「基于材料作答、可溯源」，答案脱离上下文自由发挥就违背了 RAG 的初衷。它衡量「答案的每个论断能否在检索内容里找到依据」。

四、RAGAS：自动化评估框架

RAGAS 是最流行的 RAG 评估框架，核心是用 LLM 当裁判自动算上面的指标，无需大量人工标注参考答案。

四个经典指标的计算思路：

Faithfulness：把答案拆成若干「论断」，逐个判断能否被上下文支持 → 支持比例。
Answer Relevancy：让 LLM 根据答案反推「它在回答什么问题」，与原问题比相似度。
Context Precision：检索到的每个 chunk 与问题是否相关，看相关的是否排在前面。
Context Recall：（需参考答案）标准答案的每个点能否在检索上下文里找到。

            检索质量              生成质量
          ┌──────────┐        ┌──────────┐
question →│ Precision│        │Faithful- │← answer
          │ Recall   │        │ ness     │
          └────┬─────┘        │Relevancy │
          contexts ───────────►└──────────┘

关键价值：大部分指标无需人工写标准答案（除 Context Recall），靠 LLM-judge 自动算，能规模化跑回归。但 judge 本身有偏差，需校准（见模型评估的 judge 偏差一节）。

五、端到端与业务指标

端到端正确性：最终答案对不对（有金标准答案时）。
引用准确性：答案标注的出处是否真的支持该论断（带 citation 的 RAG 必评）。
业务指标：用户采纳率、点踩率、转人工率——最终裁判（见 LLMOps）。
延迟与成本：检索 + rerank + 生成的总延迟、单次问答的 token 成本。

六、怎么搭 RAG 评估闭环

1. 建评估集：从真实问题挑 50~200 条，标注（问题, 理想答案, 相关文档）
2. 分段评估：检索指标 + 生成指标分别算，定位瓶颈在哪一段
3. 针对性优化：
   - 检索差 → 调切分/混合检索/rerank（见 切分与检索策略）
   - 生成差 → 调 prompt/约束「只用材料」/换模型
4. 回归：每次改动重跑评估集，防止改好一处坏另一处
5. 线上 bad case 回流，持续扩充评估集

诊断口诀：先看检索指标，检索不行先修检索——检索没召回对的内容，再怎么调 prompt 也没用。

高频追问

Q：RAG 评估为什么要分检索和生成两段？ 因为答错的根因不同：检索没召回对的内容（漏），还是召回对了但模型没用好/编造（幻觉）。只看最终答案无法区分，也就无法对症优化。分段后能定位瓶颈：先修检索，再修生成。

Q：Faithfulness 和 Answer Relevancy 区别？ Faithfulness 看「答案是否忠于检索材料」（防幻觉，答案的每个论断要有上下文依据）；Answer Relevancy 看「答案是否切题」（防跑题）。一个管「有没有编」，一个管「答没答到点上」，可能一个高一个低。

Q：RAGAS 怎么做到不要标准答案就能评估？ 用 LLM-as-a-judge：Faithfulness 靠「答案论断能否被上下文支持」、Answer Relevancy 靠「从答案反推问题再比相似度」、Context Precision 靠「判断每个 chunk 与问题相关性」——这些都不需要人工标准答案。只有 Context Recall 需要参考答案。代价是依赖裁判模型，需校准其可靠性。

Q：检索指标里 Recall 和 Precision 哪个更重要？ 取决于场景，但通常先保 Recall：相关内容没召回（漏），答案直接缺信息，无可挽回；Precision 低（混入噪声）还能靠 rerank 和「只用相关材料」的 prompt 部分补救。当然噪声过多会引发幻觉和 lost-in-the-middle，两者要平衡。

Q：怎么判断该优化检索还是优化生成？ 跑分段评估：检索指标（Recall/Precision）低 → 优化切分、混合检索、rerank；检索指标高但 Faithfulness/Relevancy 低 → 优化 prompt（强调只用材料）、换更强的生成模型、加约束。先看检索，检索是地基。

Q：上线后怎么持续评估 RAG？ 线上抽样跑 LLM-judge（Faithfulness/Relevancy）+ 收集用户点踩/转人工作为业务信号 + bad case 回流扩充离线评估集，每次系统改动先跑离线回归再灰度。把评估当 CI，而非一次性验收。

RAG 评估（RAGAS 与指标体系） ​

一、为什么 RAG 评估要拆两段？ ​

二、检索质量指标 ​

三、生成质量指标 ​

四、RAGAS：自动化评估框架 ​

五、端到端与业务指标 ​

六、怎么搭 RAG 评估闭环 ​

高频追问 ​