RAG 评估（RAGAS 与指标体系）
「RAG 系统怎么评估好坏」是工程落地绕不开的问题，也是高频面试题。RAG 是检索 + 生成的串联，必须拆开两段分别评，否则定位不了问题。本文讲清 RAG 评估的指标体系、RAGAS 框架、无参考评估，以及怎么搭建评估闭环。通用评估方法见 模型评估。
2026 面试先背这几句话
- RAG 评估一定要拆成检索评估、生成评估、端到端业务评估、成本延迟评估，只看最终答案无法定位问题。
- 检索侧看 Recall/Precision/MRR/NDCG，生成侧看 Faithfulness、Answer Relevancy、Correctness，生产还要看引用准确性和拒答质量。
- RAGAS 的价值是用 LLM-as-Judge 自动化评估，但它不是银弹：judge 偏差、中文领域术语、引用粒度都需要人工校准。
- 评估集要来自真实问题，覆盖高频、长尾、权限、过期知识、冲突知识、无答案问题和噪声问题。
- 上线后要把 bad case 回流成回归集，把评估接进 CI/灰度，而不是上线前一次性验收。
一、为什么 RAG 评估要拆两段？
RAG 答错可能来自两个完全不同的环节：
问题 ──检索──► 上下文 ──生成──► 答案
↑ ↑
检索错了？ 生成错了？
（没召回对的） （召回对了但没用好/编造）- 只看「最终答案对不对」无法定位问题：答案错了，是检索没找到，还是找到了但模型没用好？
- 所以 RAG 评估必须分别度量检索质量和生成质量，再看端到端。
一个实用诊断矩阵：
| 检索 | 生成 | 现象 | 优先优化 |
|---|---|---|---|
| 差 | 差 | 答案错且无依据 | 切分、召回、索引、权限过滤 |
| 差 | 好 | 模型忠于材料，但材料不对 | 检索链路 |
| 好 | 差 | 找到了资料但乱答/编造 | prompt、模型、上下文组装 |
| 好 | 好 | 离线指标好 | 看业务反馈、成本、延迟 |
面试口诀：先看检索，再看生成；检索没召回，prompt 救不了。
检索评估和生成评估怎么拆
面试里可以用“同一个问题，两份输入”来解释：
| 评估对象 | 输入 | 输出 | 代表指标 | 能定位什么 |
|---|---|---|---|---|
| 检索评估 | question + relevant_chunks 标注 | 检索 Top-K | Recall@K、MRR、NDCG、Context Precision | 切分、召回、过滤、排序问题 |
| 生成评估 | question + retrieved_context + answer | 答案质量判断 | Faithfulness、Answer Relevancy、Correctness、Citation Accuracy | 幻觉、跑题、引用错误、拒答问题 |
| 端到端评估 | question -> final answer | 用户侧结果 | 任务成功率、采纳率、转人工率 | 业务价值 |
如果没有标注相关 chunk，也要至少保存每次 query 的 Top-K、rerank 分数、最终上下文和答案。否则线上 bad case 没法判断是检索错还是生成错。
二、检索质量指标
| 指标 | 含义 | 关注 |
|---|---|---|
| Context Recall（上下文召回率） | 回答所需的信息有没有被检索到 | 漏不漏 |
| Context Precision（上下文精确率） | 检索到的内容有多少是真正相关的 | 准不准、排序好不好 |
| Hit Rate / Recall@k | 前 k 个结果里有没有命中相关文档 | 召回 |
| MRR / NDCG | 相关文档排得够不够靠前 | 排序质量 |
召回 vs 精确的权衡：召回不够 → 答案缺信息（漏答）；精确不够 → 上下文里塞了噪声，可能引发幻觉、稀释关键信息（lost in the middle）。两者都要看。
检索评估怎么标注
离线评估通常需要为每个问题标注相关文档或相关 chunk：
question: "上海员工差旅住宿标准是多少？"
relevant_docs: ["travel_policy_2026.pdf#page=12"]
relevant_chunks: ["chunk_123", "chunk_124"]
expected_answer_points:
- 上海属于一线城市
- 住宿标准为 X 元/晚
- 超标需审批如果只标最终答案，不标相关文档，就很难评估检索。生产团队常见做法是：先人工标 50~200 条高质量黄金集，再用线上点踩和搜索日志持续扩充。
常见检索问题与指标信号
| 问题 | 指标表现 | 典型原因 |
|---|---|---|
| 漏召回 | Recall@k 低、Hit Rate 低 | 切分不当、query 改写差、纯向量不适合编号 |
| 排名差 | MRR/NDCG 低 | rerank 缺失或效果差 |
| 噪声多 | Context Precision 低 | Top-K 太大、metadata 过滤缺失 |
| 越权召回 | 离线指标可能正常，线上事故严重 | tenant/role filter 缺失 |
| 过期召回 | 答案引用旧制度 | updated_at/version 未参与排序 |
三、生成质量指标
| 指标 | 含义 | 抓什么问题 |
|---|---|---|
| Faithfulness（忠实度） | 答案是否忠于检索到的上下文（没编造） | 幻觉 |
| Answer Relevancy（答案相关性） | 答案是否切题（答到点上） | 跑题/答非所问 |
| Correctness | 答案与标准答案是否一致 | 事实正确（需参考答案） |
Faithfulness 是 RAG 最核心的生成指标：RAG 的承诺就是「基于材料作答、可溯源」，答案脱离上下文自由发挥就违背了 RAG 的初衷。它衡量「答案的每个论断能否在检索内容里找到依据」。
引用准确性（Citation Accuracy）
带引用的 RAG 还要单独评引用：
- 引用存在：答案中的关键论断是否都带引用。
- 引用支持：引用的 chunk 是否真的支持该论断。
- 引用粒度：引用是否精确到页码/段落，而不是笼统指向整篇文档。
- 引用不越权：用户是否有权限访问被引用来源。
很多系统看起来「有引用」，但引用只是装饰，实际 chunk 并不支持答案。面试里提到这一点，会显得很懂落地。
拒答质量
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 偏差一节）。
RAGAS 的使用边界
RAGAS 很适合做自动化回归，但要注意：
- Judge 会偏：不同裁判模型、不同语言、不同领域术语会影响分数。
- 分数不是绝对真理：更适合比较 A/B 版本趋势，而不是迷信单次分数。
- 长上下文会稀释判断：上下文太长时，judge 也可能漏看证据。
- 引用粒度要自定义：有些业务要求页码级、条款级支持，默认 faithfulness 不一定够。
- 安全/权限要另评：RAGAS 不会天然知道企业 ACL 是否正确。
实践上会用「RAGAS 自动跑全量 + 人工抽检一部分 + 关键指标阈值门禁」组合。
五、端到端与业务指标
- 端到端正确性：最终答案对不对（有金标准答案时）。
- 引用准确性：答案标注的出处是否真的支持该论断（带 citation 的 RAG 必评）。
- 业务指标：用户采纳率、点踩率、转人工率——最终裁判（见 LLMOps）。
- 延迟与成本：检索 + rerank + 生成的总延迟、单次问答的 token 成本。
成本与稳定性指标
| 指标 | 为什么重要 |
|---|---|
| P50/P95/P99 延迟 | 平均值好看不代表用户体验稳定 |
| 单问 token 成本 | 上下文过长会直接烧钱 |
| Rerank 超时率 | 影响质量和延迟 |
| 缓存命中率 | 决定成本和吞吐 |
| 空召回率 | 高说明知识库覆盖或检索有问题 |
| 拒答率 | 过低幻觉，过高不可用 |
| 线上点踩率/转人工率 | 真实用户质量信号 |
生产评估要同时有「质量分」和「工程分」。一个 faithfulness 很高但 P95 20 秒、每问几块钱的系统，也不能算上线成功。
六、怎么搭 RAG 评估闭环
1. 建评估集：从真实问题挑 50~200 条，标注（问题, 理想答案, 相关文档）
2. 分段评估：检索指标 + 生成指标分别算，定位瓶颈在哪一段
3. 针对性优化：
- 检索差 → 调切分/混合检索/rerank（见 切分与检索策略）
- 生成差 → 调 prompt/约束「只用材料」/换模型
4. 回归：每次改动重跑评估集，防止改好一处坏另一处
5. 线上 bad case 回流，持续扩充评估集诊断口诀：先看检索指标，检索不行先修检索——检索没召回对的内容，再怎么调 prompt 也没用。
评估集应该覆盖什么
| 类别 | 目的 |
|---|---|
| 高频问题 | 保证主路径体验 |
| 长尾问题 | 看泛化和召回鲁棒性 |
| 精确匹配 | 编号、型号、人名、条款号，验证 BM25/Hybrid |
| 多跳问题 | 需要综合多个文档，验证上下文组装 |
| 冲突问题 | 新旧制度冲突，验证时效和权威排序 |
| 无答案问题 | 验证拒答 |
| 权限问题 | 验证 tenant/role 过滤 |
| 噪声问题 | 验证抗干扰和注入风险 |
版本对比怎么做
每次改切分、embedding、Top-K、reranker、prompt、模型，都要和上一版本 A/B：
baseline: chunk=512, top_k=20, rerank_top_n=5, model=A
candidate: chunk=800, top_k=50, rerank_top_n=6, model=A
比较：
- Context Recall 是否提升
- Context Precision 是否下降
- Faithfulness 是否变化
- P95 延迟和单问成本是否可接受不要只看一个指标上涨。比如 Top-K 从 10 提到 80，Recall 可能涨，但 Precision、延迟、成本和 faithfulness 都可能变差。
七、线上评估与可观测
离线评估只能覆盖已知问题，上线后还要持续监控：
- 采样评估：线上抽样跑 faithfulness/relevancy judge，控制成本。
- 用户反馈：点踩、追问、复制、采纳、转人工都是信号。
- Trace 复盘：记录 query rewrite、召回 chunk、rerank 分、最终上下文、答案、引用和成本。
- Bad case 分类：标成检索漏召回、噪声召回、生成幻觉、引用错误、权限错误、过期知识等。
- 回流回归集：高频或严重 bad case 必须进入离线评估集。
LangSmith、Langfuse、Arize Phoenix 等可观测平台的价值就在这里：把单次问答拆成可回放链路，并把线上样本沉淀成 dataset/evaluation。
八、面试专项：RAG 上线评估门禁
RAG 评估不要停在“跑了 RAGAS 分数”。上线门禁要同时覆盖质量、权限、安全、成本和回归。
| 门禁 | 评什么 | 不通过时 |
|---|---|---|
| Golden Set | 高频问题的 Recall@K、Faithfulness、引用准确性 | 不允许发布，先定位检索或生成瓶颈 |
| Bad Case Set | 历史线上失败是否复发 | 失败 case 必须修复或说明接受风险 |
| 权限测试集 | 不同 tenant/role 是否只能召回授权文档 | 越权返回为硬失败 |
| 无答案集 | 无依据时是否拒答、是否转人工 | 幻觉硬答为失败 |
| 冲突/过期集 | 新旧制度、不同权威来源如何处理 | 缺时效和权威排序则回退 |
| 引用校验 | 每个关键论断是否被引用 chunk 支持 | “假引用”不能过门禁 |
| 成本延迟 | P95 延迟、rerank 超时率、单问 token 成本 | 超预算要降级、缓存或调参数 |
| Judge 校准 | LLM-as-Judge 与人工抽检一致率 | 一致率低时不能信自动分 |
CI/CD 怎么接
每次改这些配置都要跑回归：
- chunk size、overlap、parent-child 策略。
- embedding 模型、向量索引、BM25 参数。
- query rewrite、Top-K、rerank_top_n。
- prompt、模型、引用模板、拒答阈值。
- ACL 过滤逻辑、索引版本、缓存策略。
门禁输出最好是结构化报告：
retrieval: Recall@5 / MRR / Context Precision
generation: Faithfulness / Answer Relevancy / Citation Support
safety: ACL pass rate / injection pass rate / refusal quality
ops: P95 latency / cost per query / cache hit rate
regression: failed_cases / newly_failed_cases / fixed_cases面试可复述：
我会把 RAG 评估接进发布流程。不是只看最终答案，而是检索、生成、引用、权限、无答案拒答、成本延迟都设门禁。LLM-as-Judge 负责规模化，人工抽检负责校准。线上 bad case 回流后进入回归集，防止同类问题复发。
高频追问
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，而非一次性验收。
Q：RAGAS 分数高就一定好吗？ 不一定。RAGAS 依赖 judge，可能受模型偏差、语言、领域术语和上下文长度影响；它更适合做版本趋势比较。生产还要结合人工抽检、引用准确性、权限、安全、延迟和成本。
Q：怎么评估引用是否靠谱？ 把答案拆成论断，检查每个论断是否有引用、引用 chunk 是否支持该论断、引用是否足够精确、用户是否有权限访问来源。引用不是贴个链接就完，必须验证「引用支持答案」。
Q：Top-K 越大越好吗？ 不是。Top-K 大会提高召回上限，但也会带来噪声、延迟、rerank 成本和上下文污染。要用评估集找 Recall、Precision、Faithfulness、成本之间的拐点。
Q：无答案问题怎么评？ 评拒答率和拒答质量：知识库没有依据时应明确拒答并说明原因；如果强行编答案，faithfulness 和安全性都应判失败。无答案样本必须进入评估集。