RAG 答错时如何分层定位？怎样区分入库、召回、重排和生成问题？

简化版

沿正确证据的路径逐层检查：原文是否存在、解析与切块是否保留答案、过滤后是否可检索、召回后是否被重排或上下文裁剪丢失，最后才检查模型是否正确使用证据。用固定请求回放和单层替换实验定位问题，不能看到最终答错就直接换模型或增大 Top-k。

详细版

固定原始问题、用户可见范围、文档与模型版本，明确参考答案及支撑证据。
从来源到解析文本、切块、索引逐层核查，区别知识缺失、解析损坏和索引滞后。
在同一授权候选范围内比较精确搜索与近似搜索，区分向量表示问题与索引搜索问题。
保存召回、过滤、融合、重排和最终上下文的文档 ID 与排名，找到证据首次丢失的位置。
把可靠证据直接交给生成器做对照，再检查裁剪、Prompt、引用和生成行为。
按失败类型建立回归集，每次只改变一个关键因素，同时验收质量、权限、延迟与成本。

完整版教学

一、先定义“这道题需要哪些证据”

没有参考证据时，看到“结果里有一篇相关文档”很容易误以为检索成功。但用户可能问一个有条件的结论，仅有主题相关的介绍无法支持答案。诊断前应标出可回答该问题的片段，以及是否需要多个片段联合支持。如果当前授权知识库里本来就没有答案，这首先是知识覆盖或拒答行为问题。

例如问题问“版本 3 在关闭重试时，请求多久超时”，需要版本号、重试条件与超时值。只检索到版本 2 的超时值不算成功证据，也不能算作正确的召回命中。回放还要固定用户权限与时间，因为另一个用户可见的正确资料不一定对当前请求可用。测试日志应保留必要的版本与 ID，敏感原文按实际权限受控访问。

诊断样本：
  query：原始问题和必要对话条件
  access_scope：当前用户授权范围
  corpus_revision：知识库版本
  required_evidence：E1 的版本条件 + E2 的配置定义
  expected_behavior：证据完整则作答，否则说明缺口

二、从来源检查到可检索切块

先确认原始来源真的包含答案，再检查解析后的文本是否还包含相同信息。 PDF 表格可能丢列，OCR 可能把数字识别错，标题与正文也可能在切块时分离。这些错误发生在 Embedding 之前，调整向量搜索参数无法恢复被删除的信息。随后核对切块是否写入正确索引、是否被标为删除，以及文档版本是否同步。

检查位置	典型现象	下一步动作
原始来源	没有目标配置	补知识或明确无法回答
解析文本	表头与数值错位	修复解析并重新入库
切块内容	条件在一块，数值在另一块	保留标题、调整边界或扩展邻块
索引记录	新切块不存在或版本旧	排查写入、失败队列与刷新流程
可见候选	被错误元数据条件排除	核查过滤规则与字段值

应按文档 ID 回查切块，而不是再次调用同一个失败的语义检索来证明文档不存在。 “能在数据库查到记录”和“能被当前搜索请求访问”也不同，需要检查实际查询使用的索引别名与过滤条件。合法的权限拒绝不能当成故障移除；只有错误的授权元数据才需要修正。这一步能把内容管道故障与检索排序故障分开。

三、区分向量模型没有排好与近似索引漏找

精确向量搜索在给定向量、距离函数和候选集合上计算最近邻，可作为检查近似搜索的对照。如果正确证据在精确搜索里排名第 3，在近似搜索里却没有进入前 20，应重点检查近似搜索参数与实现。如果精确搜索里它也排在第 500，扩大近似搜索范围不一定能解决向量表示本身的不足。这时应核查查询改写、编码前缀、模型版本、归一化和业务词汇表达，再考虑混合检索或微调。

实验 A：相同查询向量 + 相同候选范围 + 精确距离排序
实验 B：相同查询向量 + 相同候选范围 + 近似索引排序

A 命中，B 漏掉 -> 优先检查近似搜索损失
A、B 都排得低 -> 优先检查表示、度量和查询内容
候选范围不同 -> 对照条件不成立，不能直接归因

过滤的位置也会影响候选数量，例如先召回再过滤可能只剩很少结果。不同引擎对预过滤、后过滤和近似搜索的实现不同，应核查实际使用路径，不能只看参数名字。具体机制可参考 Elastic 的 kNN 查询说明。排障可以在获授权的受控测试中比较规则，但不能通过在线关闭权限过滤来提高召回。

四、记录证据在哪个阶段消失

召回成功不代表模型最终看到了证据。融合可能受重复文档影响，重排可能只读取被截断的片段，上下文组装还可能因为 token 预算把关键内容裁掉。因此需要为同一请求保存各阶段的候选 ID、版本、分数、排名与保留原因。跨阶段比较应使用稳定 ID，而不是比较模型生成的片段摘要。

假设 100 道题各需要一份已标注证据，初始召回有 90 道命中，重排后只剩 72 道保留证据，最终上下文只有 63 道包含完整证据。召回到重排的条件保留率是 72/90，即 80%；重排到上下文是 63/72，即 87.5%。乘积 0.9×0.8×0.875 为 0.63，与端到端上下文覆盖率一致。这组构造数据说明，只提升最初的召回不一定能修复后续 27 道题的证据流失。

100 道题 -> 初始召回命中 90 -> 重排后保留 72 -> 上下文保留 63
丢失数量：       10                 18                9

上面的乘积依赖阶段结果逐步筛选、同一题集且单证据的假设，不需要假定各层独立。若系统会在后续阶段补检索，或一道题需要多份证据，就应记录集合变化与完整覆盖情况，不能机械套用这个漏斗。重排后损失最大只是优先排查线索，也要检查标注是否遗漏其他等效证据。定位第一处异常有助于分工，但不代表一条请求只可能有一个故障。

五、用单层替换实验检查生成与上下文

把人工确认的最小完整证据直接送入同一生成器，是隔离上游检索问题的一种诊断实验。若这样能答对，而原上下文答错，说明证据缺失、噪声或组装方式值得优先检查。若直接给正确证据仍答错，则应继续检查 Prompt、输出约束、模型能力和参考答案本身。这个实验改变了输入条件，只能提供定位线索，不能保证所有真实请求都能达到相同表现。

为了细分原因，可以逐项恢复真实条件：加入干扰块、恢复原顺序、恢复原 token 预算。如果恢复裁剪后才答错，检查是否丢失限定条件；如果加入旧版文档后才答错，检查冲突证据处理。每次保留相同模型配置并对随机生成做必要重复，避免把偶然采样差异误判成因果关系。绝不能把参考答案直接写进 Prompt 后宣称检索方案修好了。

原流程：真实检索上下文 -> 同一生成器 -> 原错误
对照 1：最小完整证据   -> 同一生成器 -> 是否改善？
对照 2：证据 + 干扰块  -> 同一生成器 -> 噪声是否触发错误？
对照 3：恢复原裁剪规则 -> 同一生成器 -> 必要条件是否被删？

指标也要区分：答案能被上下文支持，不代表上下文本身正确或版本有效。 Ragas 将上下文召回、精度和忠实度等分别列为评估维度，可参考其指标目录。自动评审适合批量筛查，关键故障还要回到原文、目标条件和实际轨迹确认。修复后在受影响分组与全局回归集上检查，避免某类查询改善却损害其他类别。

六、常见误区与追问

误区：RAG 答错先换更大的生成模型。 如果原文未入库或正确证据被过滤，大模型也没有可靠材料，应先沿证据路径检查。
追问：精确搜索也找不到就证明知识库没答案吗？ 不能，相关文档可能存在但向量排名低，应按已知文档 ID 核查来源与切块。
误区：扩大 Top-k 总能改善结果。 它可能增加噪声和裁剪压力，也无法修复解析丢失、错误权限或模型版本不匹配。
追问：召回命中为什么上下文覆盖仍低？ 证据可能在融合、重排或 token 裁剪时消失，应比较各阶段稳定 ID 与实际文本。
误区：去掉权限过滤再上线就能解决召回不足。 正确授权是必须保持的约束，只能修复错误配置，不能用泄漏换取指标。
追问：直接给标准证据能答对，是否就证明生成层没问题？ 只说明该条件下可答对；真实上下文的噪声、顺序与冲突仍可能暴露生成层弱点。

七、加强记忆

把排障想成追踪一件包裹：源头有没有、装箱有没有损坏、进没进仓库、出库时有没有被拦、转运时有没有丢、收件人有没有读对。每一步都用相同请求、稳定证据 ID 和版本核对，再用单层替换验证猜测。找到证据首次异常的位置后修复并回归，才能避免靠换模型和调参数碰运气。

记忆钩子：先追证据，再调参数；找不到、没送到、送到了没读对，是三类不同的问题。

简化版

详细版