RAG 型 Agent 投诉最集中的两件事——幻觉和答非所问——这篇拆成可测的 RAGAS 2+2 指标，附「哪个低修哪段」的诊断表、faithfulness≠真相的致命细节、多跳检索链评测。藏书中 RAG 评测的最完整操作指南。
先修：了解 RAG 基本结构即可。所有 RAG / 知识库问答 / 「查了再答」型 Agent 团队。先算四个指标定位病灶，再决定修检索还是修生成。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
Context Recall（该找的找全没）和 Context Precision（找回的相关吗）测检索；Faithfulness（每条结论有证据吗）和 Answer Relevancy（答到点子上吗）测生成。
faithfulness 只查「忠不忠于检索到的证据」，不查证据本身对不对——忠实复述一份错误文档照样高分。要四指标一起看，有 ground truth 时加事实正确性兜底。
修检索：模型忠实地基于残缺证据作答，根子是检索没找全——这时调生成的 prompt 一点用都没有。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
这一讲攻一个面向大量 RAG 型 Agent 的高频刚需——检索与事实性。为什么单列一讲？因为相当比例的 Agent 是"先检索、再回答"的：查知识库、翻文档、搜网页，拿到资料再组织答案。而生产里对这类 Agent 投诉最集中的两件事，恰恰是：它一本正经地胡说（幻觉）、以及答非所问。这一讲教你把"幻觉""答不对"从模糊的抱怨，拆成可测的指标，并精确定位——到底是检索的锅，还是生成的锅。
（提醒：即便你的主 Agent 不是问答型，只要它某一步要"查点什么再据此行动"——比如退款 Agent 里"查退款政策再判断"那一步——这一讲的方法就用得上。）
要评它，先看清它的结构。一个 RAG 型 Agent 干活分两段：检索（retrieve）——根据用户问题，去知识库/文档里找相关资料，在 Agent 里这往往是一次工具调用；生成（generate）——基于检索到的资料，组织出回答。
两段各有各的病，而且会互相甩锅：检索错了（没找到该找的、或找回一堆无关的）→ 生成得再好也是巧妇难为无米之炊；检索对了，但生成瞎编（不忠于找到的证据，自己脑补）→ 这就是幻觉。
所以，评这类 Agent 的第一原则是：分两段评。把"这个 RAG 不准"这句笼统的话，拆成"检索准不准"和"生成忠不忠实"两个独立问题。
业界有一套广泛使用的指标框架叫 RAGAS（它其实提供了十几个指标，这里说的是最经典的四个核心指标），正好两两对应上面两段。记住这个"2+2"结构，你就抓住了检索评测的骨架。
测检索的两个：
测生成的两个：
| 指标 | 测哪一段 | 回答什么问题 |
|---|---|---|
| 上下文召回 Context Recall | 检索 | 该找的找全了吗（漏没漏）？ |
| 上下文精确 Context Precision | 检索 | 找回的相关吗、排序对吗（噪声多不多）？ |
| 忠实度 Faithfulness / groundedness | 生成 | 每条结论有证据支撑吗（有没有幻觉）？ |
| 答案相关性 Answer Relevancy | 生成 | 答到点子上了吗（对不对题）？ |
举个知识库问答的例子：用户问"你们的会员年费多少、怎么退"。检索段要找回"年费价格"和"退费政策"两份资料（召回）、且别混进无关的"积分规则"（精确）；生成段要只依据找到的资料作答（忠实，不能脑补一个价格）、且把年费和退费都答了（相关，别只答一半）。
忠实度（faithfulness）只检查"回答忠不忠于检索到的证据"，不检查"证据本身对不对"。
这意味着一个危险的情形：如果检索器返回了一份错误的文档，而模型忠实地复述了它——faithfulness 会很高，但答案是错的。模型没"撒谎"（它老老实实用了给它的资料），可它被喂了错料。
所以，高 faithfulness ≠ 回答正确。光盯 faithfulness，你会漏掉"检索错了但忠实复述"这一整类错误。这恰恰是为什么四个指标要一起看：
如果你的任务有 ground truth（标准答案），最好再加一个最终事实正确性（回答和标准答案比对），作为"证据对不对"的兜底——因为 RAGAS 那四个指标里，没有一个直接保证"回答在真实世界里是对的"。
这是这一讲最实用的产出。有了"2+2"，你就能把"RAG 不准"精确定位到具体环节，对症下药：
| 症状 | 说明是谁的问题 | 怎么修 |
|---|---|---|
| Context Recall 低 | 检索器漏了该找的 | 修检索：索引覆盖、召回策略、query 改写、多跳检索 |
| Context Precision 低 | 检索器噪声多/排序差 | 修检索：重排序、过滤、chunk 切分 |
| Faithfulness 低 | 生成器瞎编、忽略证据 | 修生成：prompt 约束"只用给定证据"、换更强模型 |
| Answer Relevancy 低 | 生成器答非所问 | 修生成：改 prompt、澄清意图 |
有了这张表，你团队里就不会再有"RAG 感觉不太准，调调 prompt 试试"这种拍脑袋了——先算四个指标，看是哪个低，再决定去修检索还是修生成。很多团队一遇到幻觉就猛调生成的 prompt，其实根因是 context recall 太低（压根没检索到）——那怎么调 prompt 都没用。
四个数要连起来读。举例：某次问答，Context Recall 0.9、Context Precision 0.5、Faithfulness 0.95、Answer Relevancy 0.9。怎么解？该找的基本找全了、生成也忠实也对题——唯一短板是 Precision 0.5：检索回来一半是噪声。这次虽答对了，但一堆噪声塞进上下文，既费 token、又随时可能在别的问题上把模型带偏，所以结论明确：去修检索的排序/过滤，别动生成。反过来，若是 Recall 0.4、Faithfulness 0.95——那是"忠实地基于残缺证据作答"，根子在检索没找全，你调生成的 prompt 一点用都没有。单看一个指标会误诊，四个一起读才知道往哪使劲。
这些指标大多是用 LLM-as-a-Judge 算的。以 faithfulness 为例，典型做法是：把回答拆成若干条独立断言，再逐条问裁判"这一条能从检索到的上下文里推出来吗？"——能推出的算"忠实"，推不出的就是幻觉。
举个具体的。用户问会员政策，Agent 答："年费 199 元，30 天内可无理由退款，退款 3 个工作日到账。" 拆成三条断言：① 年费 199 元；② 30 天内可无理由退款；③ 退款 3 个工作日到账。逐条比对检索到的政策文档：①② 文档里都有 → 忠实；③ 文档里根本没提到账时间 → 这条是模型脑补的。于是 faithfulness = 2/3 ≈ 0.67，而且你精确定位到了那条编造的结论。这种"拆断言、逐条验"的做法，比笼统问"这回答有没有幻觉"可靠得多。
所以——LLM 裁判的一切（偏差、Rubric、校准）在这里全部适用：这些指标不是绝对真理，用之前要拿人工校准（人机一致率），否则你只是把"幻觉"换成了"裁判觉得像幻觉"。
工程上：
建检索评测集，比普通问答评测集多标一样东西。除了"问题 + 标准答案"，你还得标出"为回答这个问题，应该检索到哪几条关键资料"（业界叫 golden context）。有了它，你才算得出 context recall 和 precision。这份标注是检索评测的主要成本，但也是你能把"检索"和"生成"分开评的前提——没有它，你就只能评最终答案对不对，又退回黑箱了。
别只报平均 faithfulness。一个"平均忠实度 0.95"可能掩盖着"5% 的回答里塞着离谱的幻觉"——而在事实性上，偶发的严重幻觉，往往比普遍的轻微不准更伤用户信任。所以对幻觉，除了看均值，更要盯尾部：有多少条 faithfulness 特别低、都错在哪类问题上。高风险场景里，甚至该用"可靠性视角"（有没有偶发的严重编造）来卡，而不是满足于一个好看的平均分。
上面的框架源自"一问一答"的 RAG，但 Agent 场景更复杂，有三点特殊：