生产 RAG 检索故障怎么查？沿着正确证据逐站定位

答案引用了正确文件，数字却错了。检查后发现：退款表格来自扫描 PDF，解析时两列文字被拼到一起。团队调了两天提示词，真正丢失的信息却发生在模型调用之前。

生产 RAG 的检索故障，应沿着正确证据逐站定位。本文把原文的诊断顺序改写成与供应商无关的排障方法，去掉产品接入推广，并补充多租户和评测口径的限制。

找出人工确认能够回答问题的片段，记为 gold passage。它不是答案文本，而是后面每一步要追踪的证据。

记录原始查询、改写查询、过滤条件、召回 ID 与分数、重排结果、最终提示词片段和引用。先查看查询改写有没有丢失关键条件，例如"企业合同"被改成了泛化的"合同"。

如果原始查询能找回证据，而改写查询不能，优先排查改写。之后的每一站都问同一个问题：这段证据还在吗？

按文档 ID 或原文中的精确短语查索引。查不到时，先检查连接器、目录范围、文件类型、同步任务和解析结果。

对扫描文档和表格，应把源页面与存储文本人工对照。列顺序、单位、合并单元格、标题及脚注都可能被破坏。如果解析后的文本已经无法让人读懂，换一个 Embedding 模型通常无济于事。

此阶段的验收是"证据以可理解形式进入索引"，不是仅统计成功上传了多少文件。

检查证据是否跨块，表格行有没有列标题，例外条件是否与主规则分离。可以尝试按章节或表格分块，并给子块携带标题和必要元数据。

改变分块后，受影响文档通常需要重新生成向量。先在失败查询上验证，再扩大重建范围，避免大规模重索引之后仍无法解释改善来自哪里。

如果证据完整存在，检查它在原始候选集中的名次。明确候选评测口径：每题若有多个相关片段，Recall@k 是找回数量占全部相关片段的比例；若仅追踪一个 gold chunk，记录的是这条证据是否进入前 k，可称命中率。

包含精确产品代码的问题可以比较稀疏或关键词检索；跨语言和领域术语问题可以比较适用的 Embedding 模型。每种方案都需要在固定数据集上验证。

还有两类容易误判为模型问题的情况。第一，近似向量搜索没有返回精确搜索能找到的结果；应比较当前数据库支持的精确检索或更高搜索精度配置。第二，查询和文档向量来自不同模型版本、维度或归一化策略。维度相同也不保证向量处在可比较空间。

日期、生效状态、文档类型和租户字段都会影响结果。证据初始排名不错，却在过滤后消失时，要核对文档元数据与实际条件。

原文建议移除过滤来做对照。多租户生产系统不能为了调试关闭授权过滤。应使用合成数据、受控离线副本或同租户的授权诊断环境，只调整允许实验的业务过滤条件。权限边界必须持续生效。

对比重排前后名次。如果正确片段从前排掉到截断线外，检查长文本截断、模型适用性和问题分布。

如果重排后仍在列表中，再看上下文组装：去重、Token 预算、模板拼接是否删掉它。最终发送的提示词才是模型实际能利用的输入，候选列表不等于最终上下文。

只有确认完整证据进入提示词，仍被回答忽略或曲解时，才把模型生成和指令作为重点实验对象。

第一行优先修分块；第二行查元数据与允许范围内的过滤逻辑；第三行如果仍答错，再查上下文解释与生成。这些数字仅说明诊断方法，没有测量任何客户系统。

固定问题和 gold evidence，重跑摄取或检索相关阶段，保存新的 Trace。分别记录候选召回、最终上下文覆盖、答案与引用质量，再比较延迟和成本。

日志可以优先保存 chunk ID，但必须能够按文档版本解析回当时的内容。若索引更新后同一个 ID 指向了不同文本，旧 Trace 就难以复核。

排障的目的，是找到证据最早丢失或变形的位置，并通过一次有边界的实验验证修复。更强的模型可以改善部分生成问题，但不能替系统读取一段从未送达的证据。