Paper 13: RAG Evaluation, RAGAS, and Retrieval Metrics

本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。

Source Anchors

核心导读

RAG 的原理是把模型的参数记忆与外部检索记忆结合：先检索相关资料，再让生成模型基于上下文回答。RAGAS 的启发，是把这个过程拆成可评估对象：context 是否相关、是否覆盖答案所需信息，answer 是否回应问题，关键断言是否忠实于提供的 context。

它的价值在于把“回答看起来不错”拆成可定位的系统证据。一个流畅答案可能来自错误检索、过期文档、无权限资料、噪声上下文或不支持的引用；分层评估能帮助团队判断问题发生在 query rewrite、metadata filter、retriever、reranker、context packing、generation、citation mapping 还是需求定义。

金融零售 RAG 还必须超出通用 RAGAS 指标。Faithfulness 只说明答案忠实于给定 context，不说明 context 是否权威、当前、授权或足够完整。生产级 EvalOps 应加入 permission gate、current-version gate、source authority、safe refusal、audit replay、failure taxonomy 和 release regression，让 RAG 从 demo 能力变成可上线、可复盘、可回滚的系统资产。

---

1. 核心问题：RAG 最危险的失败是“看起来正确”

RAG 的产品承诺通常是：模型基于外部知识回答，而不是只靠参数记忆。 这听起来降低了幻觉风险。 但如果检索链路错了，RAG 会产生一种更难发现的问题：答案语言流畅、引用形式完整，但证据其实不对。 常见失败包括：

• 正确文档没有被检索出来。
• 检索到了相似但过期的政策。
• top-k 中混入大量无关上下文。
• 模型把上下文之外的常识写进答案。
• 引用存在，但引用不支持对应断言。
• 用户看到了无权访问的资料。
• 知识库无答案时，模型仍然给出看似合理回答。 在金融零售中，这些失败会影响客户权益、监管沟通、内部操作和审计证据。 例如，KYC 助手引用旧版开户材料清单，可能导致客户反复补件。 信用政策助手把培训材料当成正式政策，可能导致不一致解释。 AML copilot 漏检关键交易证据，可能导致调查 narrative 不完整。 所以 RAG evaluation 的核心不是给答案打一个总分。 它要回答：系统在每一步是否拿到了正确资料，是否按权限和版本过滤，是否忠实使用证据，是否在不知道时拒答或升级。

---

2. 技术贡献：RAGAS 把系统拆成可评估维度

2.1 RAG 的基本结构

RAG 论文把生成模型的参数记忆和外部检索记忆结合起来。 简化链路是：

question -> retriever -> retrieved documents -> generator -> answer

对企业系统来说，真实链路更复杂：

question
  -> query rewrite / intent routing
  -> permission and metadata filter
  -> vector / keyword / hybrid retrieval
  -> reranking
  -> context packing
  -> generation
  -> citation mapping
  -> validation
  -> logging and feedback

评估必须覆盖这些环节，否则无法定位失败原因。

2.2 RAGAS 的关键启发

RAGAS 的贡献是把 RAG 质量拆成多类指标，而不是只看最终答案。 它关注的问题包括：

• 检索到的 context 是否和问题相关。
• context 是否覆盖回答所需信息。
• 答案是否忠实于 context。
• 答案是否回答了用户问题。 其中 faithfulness 尤其关键。 它问的不是“答案在世界上是否真实”，而是“答案中的断言是否被提供的 context 支持”。 这符合 RAG 的系统承诺：回答应基于可检索证据。

2.3 Reference-free evaluation 的价值和边界

RAGAS 强调许多指标可以不依赖人工 gold answer，而由 LLM judge 根据 question、context 和 answer 评估。 这对快速迭代很有价值。 企业可以在 chunking、embedding、reranker、prompt、model 和 index 变更后快速比较版本。 但金融零售不能完全 reference-free。 高风险场景必须有 gold source、业务 owner、专家复核、权限测试和版本断言。 LLM judge 可以帮助扩大评估覆盖，但不能成为唯一验收主体。

2.4 LLM-as-Judge 的适用位置

LLM judge 适合评估开放式输出的结构、相关性、覆盖度和部分忠实性。 它不适合作为以下事项的唯一判断：

• 监管合规结论。
• 用户是否有权限。
• 政策版本是否当前有效。
• 引用是否来自权威源。
• 某个业务动作是否允许执行。 这些需要确定性检查、元数据校验、专家抽检和审计回放。

---

3. 机制原理：RAG eval 的对象模型

3.1 一个 eval case 不只是一个问题

高质量 RAG eval case 至少包含：

3.2 Query set 要覆盖真实工作

只从 FAQ 抽题会低估 RAG 风险。 金融零售 query set 应覆盖：

• 高频直问。
• 术语变体。
• 多条件问题。
• 跨文档问题。
• 冲突政策。
• 无答案问题。
• 无权限请求。
• 合规诱导。
• 地区、产品、渠道、客户类型差异。
• 需要人工升级的问题。 例如 KYC 场景不能只问“企业开户需要哪些文件”。 还要问高风险行业、外资股东、地区差异、旧政策冲突、缺件例外、客户无权查看内部 SOP 等问题。

3.3 Retrieval trace 是评估证据

每次 eval 应保存：

• 原始 query。
• query rewrite。
• metadata filters。
• candidate documents。
• retrieval scores。
• rerank scores。
• packed context。
• dropped context。
• final answer。
• citation mapping。
• model and prompt version。 这不是为了日志完美主义。 当答案错了，trace 决定团队能否定位是检索、排序、过滤、上下文打包、prompt、模型还是需求本身的问题。

---

4. Retrieval metrics：先证明资料找对了

4.1 Hit Rate

Hit Rate 看 top-k 中是否至少包含一个 gold source。 它回答：

系统是否大概率把正确资料找出来？

它简单直观，适合早期检索链路调优。 局限是只要命中一个就算成功，不能说明排序、完整性或噪声水平。

4.2 Recall@K

Recall@K 看 top-k 中召回了多少应召回资料。 它适合多文档、多条款、多证据问题。 例如 AML narrative 可能同时需要交易证据、KYC 信息、历史 alert 和 typology guidance。 如果 recall 低，生成模型可能写出流畅但不完整的答案。

4.3 Precision@K / Context Precision

Precision 看检索结果中有多少是真相关。 高 recall 低 precision 会造成：

• context window 被无关资料占用。
• 模型被相似产品或旧政策干扰。
• 引用错配概率上升。
• 成本和延迟上升。 金融场景中，precision 不是追求越高越好。 关键是确保上下文足够聚焦，不混入危险相似项。

4.4 MRR

Mean Reciprocal Rank 关注第一个正确结果排在多前。 当 UI 展示来源列表，或 context packing 偏向前几个结果时，MRR 很重要。 正确资料排在第 9 位，和排在第 1 位的风险完全不同。

4.5 nDCG

nDCG 支持多级相关性。 金融资料常常不是二元相关：

• 当前正式政策高度相关。
• 同产品旧政策相似但危险。
• 同类产品政策部分相关。
• 培训材料可作背景但不能作为依据。
• 草稿文档不能用于客户回答。 nDCG 能把这种分层放进排序评估。

4.6 检索指标异常的诊断

---

5. Answer metrics：再证明答案忠实、完整、可用

5.1 Faithfulness

Faithfulness 问的是：

答案中的断言是否被检索上下文支持？

它不是全局正确性。 如果答案说“客户必须提交最近 6 个月流水”，context 只支持“可能需要流水”，那就是 unsupported claim。 在高风险场景中，应从 answer-level faithfulness 进一步做到 claim-level citation。 每个关键断言都要能指向具体来源。

5.2 Answer relevancy

Answer relevancy 问的是答案是否真正回应用户问题。 低 relevancy 的常见原因：

• 用户问条件适用，系统回答概念解释。
• 用户问本地区政策，系统回答全国通用政策。
• 用户问下一步流程，系统只解释背景。
• 模型因为不确定而泛泛拒答，没有澄清。

5.3 Completeness

Completeness 看答案是否覆盖必要条件、例外、限制和下一步。 金融零售中，完整性经常比文采重要。 KYC 文件清单必须覆盖客户类型、地区、实体类型、风险等级、有效期和例外流程。 投诉处理建议必须覆盖 SLA、升级条件、记录要求和客户沟通口径。

5.4 Citation support

Citation support 不能只检查“有没有引用”。 它要检查：

• 引用是否支持对应断言。
• 引用是否当前有效。
• 引用是否来自权威来源。
• 引用是否在用户权限范围内。
• 多个引用是否互相冲突。 引用是 RAG 的信任接口。 错误引用比没有引用更危险，因为它制造了虚假的可审计感。

5.5 Safe refusal

RAG 必须知道什么时候不回答。 应拒答或升级的情况包括：

• 知识库没有答案。
• 用户无权限。
• 资料冲突且无法判断。
• 问题要求越权承诺。
• 问题要求泄露内部策略。
• 请求会影响客户权益或监管记录。 拒答也要评估。 拒答不足会带来风险，过度拒答会损害采用率。

---

6. Governance metrics：金融级 RAG 的上线底线

RAG 生产评估必须加入治理指标。

---

7. 为什么这套评估有效

7.1 它把失败定位到具体环节

一个坏答案可能来自多个地方。

Bad answer
  -> gold source retrieved?
      no: retrieval / query / metadata / index issue
      yes:
        -> context current and relevant?
            no: version / rerank / packing issue
            yes:
              -> answer faithful to context?
                  no: prompt / model / verifier issue
                  yes:
                    -> expected behavior wrong?
                        yes: requirement / gold set issue

这种 triage 能避免团队把所有错误都归咎于“模型不够强”。 很多 RAG 失败其实是文档治理、chunking、metadata、权限、版本或需求定义问题。

7.2 它让 release gate 可执行

RAG 系统每次改动都可能影响结果：

• 换 embedding model。
• 改 chunk size。
• 加 metadata filter。
• 调 reranker。
• 改 prompt。
• 换生成模型。
• 更新索引。
• 改权限规则。 没有 eval suite，每次发布都靠人工感觉。 有了回归集和 gate，团队可以比较版本、识别退化、决定灰度或回滚。

7.3 它让业务、风险和技术对齐

业务关心回答是否有用。 风险关心是否越权、误导、过期、不可追溯。 技术关心检索、排序、上下文和模型。 RAG eval 把三者连接到同一张表：case、gold source、metric、threshold、owner、evidence。

---

8. 局限和误用

8.1 只用 LLM judge

LLM judge 有价值，但它会受 prompt、模型版本、评价标准和上下文影响。 高风险问题不能只靠 judge 分数上线。 需要专家抽检、确定性校验和审计证据。

8.2 把 faithfulness 当成 correctness

Faithfulness 只说明答案忠实于给定 context。 如果 context 本身错了、过期了或无权使用，faithful answer 仍然不合格。 所以必须同时评估 retrieval、version、authority 和 permission。

8.3 Gold set 和平均分误用

业务政策、产品和用户问题都会变化，eval dataset 也要有生命周期：新政策上线后更新，线上失败样本进入回归集，旧样本标记 retired，高风险样本定期专家复核。 平均分高不代表安全。一条 critical unsupported claim、一次权限泄露、一次错误 adverse action 解释，都可能足以阻止上线。高风险 gate 应使用 hard fail 规则，而不是只看均值。

---

9. 架构和产品价值

9.1 RAG EvalOps reference flow

RAG EvalOps 的主链路是：versioned eval cases 和 indexed corpus 进入 eval runner，产出 retrieval / generation trace，再计算 retrieval、answer、governance metrics。release gate 通过后进入 canary / pilot / production；失败时按 query、chunk、metadata、rerank、prompt、model、policy 做 triage；线上监控再把失败样本回灌 eval set。这个闭环把 RAG 质量从一次性测试变成持续运营。

9.2 Requirements-to-eval matrix

需求要落成 eval matrix：当前有效政策用 current-version rate，关键事实用 citation support，无权资料用 permission pass rate，知识库无答案用 refusal accuracy，高风险建议用 escalation accuracy。每个指标都要绑定 eval case、threshold、evidence 和 owner，这比“AI 回答要准确”更能指导开发和验收。

9.3 产品决策用 eval，而不是感觉

Pilot 是否扩大，不应只看用户满意度，还要看 answer usefulness、citation support、refusal accuracy、human override rate、expert review cost、incident rate、latency 和 cost per answer。adoption 高但 citation support 低，应暂停扩大；faithfulness 高但 adoption 低，优先检查 UX、工作流和问题覆盖。

---

10. 金融零售系统案例

10.1 KYC policy assistant

任务是回答开户材料、客户类型、地区差异和例外流程。 必须评估：

• 地区、实体类型、风险等级 metadata 是否过滤正确。

• 当前有效文件清单是否召回。

• 旧政策是否被排除或标注。

• 内部 SOP 是否只对授权员工可见。

• 缺件和例外流程是否完整。 关键 hard fail：

• 无权用户看到内部政策原文。

• 引用旧版 KYC 文件要求。

• 对缺失材料给出错误承诺。

10.2 AML investigation copilot

任务是帮助调查员整理证据和生成 narrative 草稿。 评估重点：

• 关键交易、对手方、KYC、历史 alert 是否召回。
• narrative 中每个事实是否有证据。
• 是否覆盖 typology checklist。
• 是否避免自动 SAR/STR filing 建议。
• 是否保留人工调查员结论和 override。 这里的 recall 比普通 FAQ 更重要，因为漏掉关键证据可能比回答不流畅更危险。

10.3 Credit policy assistant

任务是解释授信政策、审批条件和 adverse action 相关流程。 评估重点：

• 正式政策优先于培训材料。
• reason code 解释必须来自 source-of-truth。
• 模型不能编造拒绝原因。
• 回答不能替代审批决策。
• 公平信贷敏感因素不能被错误引用。

---

11. 学习验证

用自己的话回答：

• RAGAS 为什么不只评最终答案。
• Faithfulness 和 correctness 有什么区别。
• Hit Rate、Recall@K、Precision@K、MRR、nDCG 分别回答什么问题。
• 金融 RAG 为什么必须加入 permission 和 current-version gate。 做一个 RAG eval package：为 KYC policy assistant 设计 40 条 eval case，覆盖高频开户、地区差异、高风险行业、旧政策冲突、无答案、无权限、缺件例外和人工升级。每条 case 写出 gold_sources、expected_behavior、risk_tier、failure_tags。 输出一张 retrieval report，至少包含 Hit Rate@5、Recall@10、Context Precision、MRR、nDCG、wrong-version count、permission leak count。对每个低于阈值的指标写出可能原因和下一步实验。 选择 10 个错误答案做 failure triage，至少区分 no_gold_retrieved、wrong_version、permission_leak、noisy_context、unsupported_claim、citation_mismatch、missing_exception、over_refusal 和 unsafe_answer。

---

12. 读完后应形成的判断

RAG 评估的核心不是证明模型聪明，而是证明系统基于正确、授权、当前、可引用的证据回答。 RAGAS 提供了重要拆解方法，尤其是 context 和 answer 的分层评估。 但金融零售生产环境还需要权限、版本、权威来源、拒答、审计和回归发布。 高质量 RAG 系统一定有三类资产：

• versioned eval dataset。
• retriever and generator trace。
• release gate and failure triage loop。 有了这些资产，RAG 才能变成可管理的企业 AI 能力。

---

SOTA 检查 (2026-07-01)

• Ragas 库仍在活跃维护，且已远超本篇讨论的原始四指标：PyPI 上 Ragas v0.4.3 于 2026-01 发布（v0.4.1/0.4.2 为 2025-12），当前指标清单已扩展到 Context Precision/Recall、Faithfulness、Multimodal Faithfulness/Relevance、Answer Accuracy、Response Groundedness 等。本篇以 2023-09 的 RAGAS 论文为锚点，读框架思想没问题，但落地选指标应以官方文档 docs.ragas.io 当前版本为准。
• 2026 年的 RAG 评估已从"单一框架"变成"分层生态"：Ragas 定位是纯指标框架（缺生产可观测/实验追踪）；工程侧主流补位方案是 DeepEval（pytest 原生集成、50+ 指标含 G-Eval 与确定性指标，适合本篇 §7.2 的 CI release gate）、LangSmith、Arize Phoenix 等评估+可观测平台（2026 年多方对比文章共识）。本篇 §6 的治理指标（permission/version/audit replay）这些平台仍不原生覆盖，需要自建——该结论依然成立。
• 评估对象本身在迁移：naive retrieve-then-generate → agentic RAG / context engineering：2025-2026 主线是 agent 自主决定"何时检索、检索什么、证据是否充分"（Agentic RAG Survey, arXiv 2501.09136, 2025-01；RAGFlow 2025 年终综述"From RAG to Context"，2025-12）。对应的评估新方法是能力分解式 benchmark，如 RAGCap-Bench（arXiv 2510.13910, 2025-10），把 agentic RAG 拆成中间能力单独测，比端到端评估快约 50 倍——这与本篇 §2.1"评估必须覆盖每个环节"的分层思想同构，但把"环节"从固定 pipeline 扩展为动态检索循环。库内 docs/AGENTIC_RAG_2026.md（2026-05-29）和 docs/aipa/day41-agentic-retrieval.md 已按此路线落到本仓库 Agent Lab 代码。
• 本篇不随版本过时的框架性结论：(1) faithfulness ≠ correctness，忠实于错误/过期/越权 context 仍不合格；(2) retrieval / answer / governance 三层指标分离 + failure triage 决策树（§7.1）；(3) 金融场景 hard fail 规则优先于平均分（§8.3）；(4) eval case 的对象模型（gold_sources / expected_behavior / risk_tier / owner）。这些在 agentic RAG 时代反而更重要，因为检索链路变成动态循环后，trace 和归因成本更高。
• 库内配套实操：检索评估落地手册见 docs/AI_RETRIEVAL_EVAL_GRAPH_RAG_PLAYBOOK.md（本篇的 eval stack / release gate 展开版），JIT 检索与 context rot 量化见 docs/aipa/day40-jit-retrieval.md。