RAG 上生产前的三道验收关卡：召回、忠实、可溯源

大部分 RAG 项目死在”演示很惊艳、上线很尴尬”这个阶段。原因往往不是模型不行，而是验收标准缺失：团队只看最终答案”像不像”，没人去看检索有没有找对、答案有没有编、引用能不能点开对上原文。这三件事必须拆开验，因为它们的失败原因和修复手段完全不同。

第一关：召回验——答案错，有一半是压根没找到

召回验要回答的问题只有一个：该被找到的段落，到底有没有进上下文。

准备方式：从真实业务问题里抽 100～200 条，为每条人工标注”至少应该命中哪几个 chunk”。不要用模型自动生成标注，否则验的是模型自己的偏好。

两个指标必须同时看：

• 命中率（Hit Rate@k）：标准段落是否出现在 top-k 里。k 取你实际喂给模型的数量，不是取 10 糊弄自己。
• 覆盖率（Recall@k）：标准段落有几成被捞上来。答案需要多处拼合的场景，命中率会骗你。

一个典型现象是 Hit Rate@5 有 92%，但 Recall@5 只有 55%——说明”找到了一个相关片段”很容易，“找全”很难。多跳问题、跨文档对比问题几乎都栽在这里。

排查顺序固定三步，别跳：先看切块（chunk）有没有把答案切断，再看查询改写（query rewriting）有没有把原意改跑，最后才怀疑 embedding 模型。实践中第一项占问题总量的六成以上。

第二关：忠实验——答案里的每句话都要能在上下文里站着

忠实度（faithfulness）验的是：输出里的每个断言，是否被检索到的上下文支持。 这是防幻觉的核心关卡。

不要用”整体评分 1-5 分”这种主观打分，方差大到无法决策。用抽取式比对：把答案拆成原子断言（一句一个事实），逐条判定支持 / 不支持 / 矛盾。

断言："该产品支持 SSO 单点登录，且免费版包含该功能"
→ 断言1：支持 SSO —— 上下文支持 ✅
→ 断言2：免费版包含 SSO —— 上下文未提及 ❌（属于越界补充）

判定”未提及”比判定”矛盾”更重要。大量幻觉不是瞎编，而是把合理常识补进答案：用户问退货政策，资料里写了 7 天，模型顺手补一句”法定 15 天”，看起来专业，实际是风险。

阈值建议：断言支持率低于 95% 不放行；任何一条”矛盾”级错误必须定位到 prompt 或数据源头，不能靠调温度掩盖。

第三关：可溯源验——引用必须点得开、对得上

只要产品里出现”根据文档 X”这类话术，就必须验引用。方法是机器化校验，不是人工抽查：

1. 抽取答案中的每个引用标记，解析到具体文档与段落。
2. 用字符级相似度或关键实体（数字、人名、型号、日期）比对引用段落与断言内容。
3. 统计”引用段落存在但无关”的比例——这是最隐蔽的错误，用户点开看到相关文档却找不到那句话，信任瞬间归零。

数字类断言要单独加一道规则：答案里出现的每个数字，必须在引用段落里逐字出现。金额、比例、期限这些一旦被模型”折算”或”单位换算”，错误率极高。

把三关串进回归流程

单次验收只证明当天能用。真正起作用的是把它做成回归：

• 每次改切块策略、换 embedding、调 prompt，全量跑三关。
• 每个失败样例沉淀成一条固定用例，标注”预期命中段落”和”预期断言”。
• 上线时抽样 5% 线上真实问题回灌进测试集，防止分布漂移。

一张最简单的看板就够：三条指标曲线加一个失败用例数。三条曲线任意一条下降超过 2 个点，本次变更不许合入。

RAG 的工程质量，最终体现为你有没有勇气说清”什么情况下它一定会答错”。有了这三关，这句话才说得出来。