前阵子团队看线上客诉，用户问「我的订单为什么还没发货」，机器人回了一段完全无关的退换货政策。他们那周一直在调 prompt、换生成模型，越调越乱。我让他们把检索结果打出来一看，根子根本不在生成：用户的问题命中的那条物流说明，被排到了第 8 位，生成模型压根没看到，只能拿不相干的文档硬编。
白调了一周生成，检索那段的坑一天没动。这事让我认定一条：RAG 评测不能混着测，得先把它劈成两段。
一、RAG 由检索与生成两段串联，失效形态不同
说白了，RAG 就是把「找资料」和「写答案」两件事串起来，链路其实就几步：用户问题先被向量化，检索器从知识库捞回一批相关 chunk，重排模型把最相关的顶到前排，前 K 个拼成上下文，最后喂给生成模型作答。
问题就出在这条链上有两个独立的失败注入点。检索段负责把相关 chunk 捞出来并排好，生成段负责看着这些 chunk 组织语言。两段的活儿不同，出的毛病也完全不同。
检索段翻车，通常是捞不回来（召回率塌）、或者捞回来了但排太靠后（排序烂）、或者捞回来一堆不相关的（噪声灌进上下文）。生成段翻车，通常是明明有资料却编了没的（幻觉）、或者 citation 对不上、或者长上下文里抓错了那一段。
混在一起评测，你看到「答案错」这一个结果，分不清是哪段作的妖。治标式调参就来了：检索有问题却去调生成，越调越偏。我见过最典型的，是花三天重训生成、加了两轮 few-shot，上线一量错误率纹丝不动，回头查检索才发现召回率只有 0.4，根子压根没碰着。
二、检索与生成两段分测，度量标尺各异
多数人一上来就跑端到端，拿个「任务成功率」交差，其实是最容易糊弄自己的法子，答案错了你根本不知道病在检索还是生成。
把三把尺子摆出来一起看：
| | | |
|---|
| | | |
| | | |
| | Faithfulness、Citation 命中、答案对拍 | |
| | | |
| | | |
| | | |
检索段量「资料对不对」，生成段量「话对不对」，端到端量「事办没办成」，三把尺子最忌只留一把。只测端到端，能看到答案错却归因不了：是检索没捞着还是生成编了，分不清。只测检索，召回再准也保证不了生成拿到资料后不胡说。只测生成更坑：固定 context 跑出 0.95 的 Faithfulness，一接真实检索的噪声立刻垮。这三段得叠着测，少一把就留一处黑盒。
出问题时怎么用？把三段指标挂同一块看板，按 query 维度下钻。一个团队实际在用的就这几列：检索 top3 命中占比、检索平均排名、Faithfulness 自动校验通过率、端到端任务成功率、人工抽检抽样错误率。哪列塌了直接定位到段，不用靠猜。
三、成熟度自查：从哪档补起
聊完定义，对照下面这张表做一遍成熟度自查。
| | | |
|---|
| | | |
| | | |
| | 加生成段评测，查 Faithfulness 与 Citation | |
| | | |
别跳着走。常见错误是一上来就冲阶段四想全进 CI，结果检索段连基线都没有，指标挂上去也是空的。阶段二能拦掉一半「白调生成」的冤枉工时，值得先花两天把检索指标立起来。
四、RAG 评测体系搭建：三段框架与归因主线
RAG 评测共 01-06 六篇，框架上是三段骨架加一条把三段连起来的归因线。
骨架第一段是检索评测（02），管召回率、准确率、排序的坑，捞不回和排不准分别怎么量。第二段是生成评测（03），管幻觉归因，查清是检索漏了还是生成编了，这根归因线也贯穿全文。第三段是端到端评测（05），把前两段放回真实链路一起量、造三元组评测集。04 是检索段的前置地基（切分污染），06 是上线后的漂移守护，这两块不进分段计数但全程相关。
五、落地实践：分步落地，兼容现有体系
不用推翻现有体系，先给检索段建指标（02），再补生成段 Faithfulness（03），查 chunk 切分污染（04），造端到端评测集（05），进 CI 后加知识库版本回归闸（06）。
与既有的四件套（评测集、评分卡、裁判、难负）亦可衔接。RAG 评测把评测集换成「问题-标准答案-应检索文档」三元组，评分卡加一列 Faithfulness，裁判换成检索命中加生成一致性双校验，难负换成近义干扰与无关文档注入。字段映射关系汇总如下表。
| | |
|---|
| | |
| 加 Faithfulness 与 Citation 命中两列 | |
| | |
| | |
本文建议
- S（具体）：两周内对 1 个核心 RAG 链路建检索段指标（Recall@5、MRR）与生成段 Faithfulness 校验，覆盖主场景。
- M（可衡量）：每个核心 query 集至少 20 条；检索 Recall@5 大于等于 0.8、MRR 大于等于 0.5；Faithfulness 自动校验通过率进报告。
- A（可达成）：复用现有向量库与日志，只加指标脚本与标注样本，不改业务链路。
- R（相关）：RAG 是 agent 与 skill 里最高频的一类链路，本篇把它的评测从通用评测里单拎出来，承接前序四件套。
- T（有时限）：首个核心链路改动合并前跑通检索加生成双指标；之后每次知识库变更自动跑。
一句话收尾
你那条 RAG，现在是检索和生成分开盯着的零件，还是每次出问题靠调 prompt 蒙？
英文术语释义
- RAG（检索增强生成）：先检索知识库相关文档，再让模型基于文档作答的架构。
- Recall@K：前 K 个结果里命中相关项的比例，衡量捞得回不回得全。
- Faithfulness（忠实度）：生成答案是否句句有检索文档支撑，衡量幻觉程度。
- Chunk（文本块）：知识库被切分后存入向量库的最小检索单元。
