rag检索质量有问题排查链路是什么

问答答非所问时，很多人的第一反应是换模型或调提示词，改完还是不准，因为问题多半出在检索这一段。这篇给一条从上往下走的排查链路：先确认知识到底在不在库里，再逐段看切分、向量化、召回数量、重排、拼装提示词哪一段把正确内容弄丢了。每段都给可执行的验证动作和什么情况下这条路不适用。

问答答非所问，很多人的第一反应是换模型、改提示词，改完还是不准。问题大多不在生成那一侧，而在检索这一段：正确的知识根本没被找出来，或者被找出来又被挤掉了。所以排查要从上往下走，先确认知识到底在不在库里，再逐段看切分、向量化、召回数量、重排、拼装提示词哪一段把正确内容弄丢了。

下面这条链路的核心是「先定位再改」：每一步都做一次能证伪的验证，确认这段没问题再往下走。不要一上来就调参数，那样很容易几个人同时改，最后说不清是哪一步起的作用。这套排查主要针对单轮问答型 RAG；多轮追问、带工具调用的场景要另外看问题改写和检索轮次是否合理，后面会单独说明。

第一步：先确认内容在库里，再看切得对不对

排查的第一刀不要切在检索模型上，先确认「知识进没进库」。做法是造一组带原文关键词的问题，绕过向量检索，直接去向量库按关键字查原文。查不到就是进料或切分出了问题，后面的召回、重排全都别看了，先回头修数据管道。

1. 按关键字直查向量库挑 10 条左右有明确答案的问题，用答案里的专有名词、编号、原句片段去查。命中为 0 说明这条内容压根没入库，或者入库时被清洗掉了。
2. 抽片段读上下文把命中的片段连前后各一段原文一起读。答案和主语被劈成两半，或者缺了时间、限定条件这种关键前提，就是切太碎，需要调大分块粒度或按标题层级切。
3. 查结构内容清洗表格、扫描件、代码块先单独检查。表格被压成一行乱序文本、扫描件根本没 OCR 出字，这类脏数据进库以后怎么调检索都救不回来。

第二步：向量化与召回数量，判断是找不着还是排太后

确认内容在库、切得也还算完整，就进入「找不找得到」这一层。最容易犯的错是把「没找着」和「找着了但排太后」混成一件事，其实这是两个完全不同的问题，修法也不一样。

• 同一问题分别用关键词检索和向量检索各跑一次，对照哪条路捞到了正确片段
• 把 topK 临时调大，看正确片段能不能进候选集，能进就是排序问题，进不去才回头查向量模型和分块粒度
• 文档量级大、之前加过来源或时间过滤的，先把过滤条件关掉重跑，确认不是过滤把正确片段筛掉了
• 人工记一版「正确片段应该排第几」的期望值，后面每改一次都拿同一批问题回归

这层要注意一个不适用的场景：如果业务本身强依赖时效，比如只查最近几天更新的内容，那么关掉时间过滤跑出来的好结果并不能说明线上没问题。这时候要做的是带过滤条件重跑一次，比的是同一条件下正确片段有没有进候选。

第三步：重排与拼装，看正确答案是不是被挤出去了

正确片段已经进了候选，最终答案还是错，多半是在重排和拼装这两步被挤掉了。重排阶段正确片段被压到后面、超出截断位置，或者拼进上下文的片段互相矛盾、新旧版本混在一起，都会让模型拿到一锅乱炖的上下文。

• 对比重排前后的候选顺序，正确片段重排后掉出前几名，就调整送进重排的条数和截断位置
• 逐字看最终提示词里实际塞进去的片段，很多时候答案就在库里但根本没被拼进上下文
• 片段之间互相矛盾时，先统一来源优先级，再谈要不要换模型
• 拼装环节要留出片段的来源标识，出问题时能一眼看出是哪一条在捣乱

这一步的判断很直接：拿人工挑出的正确片段，按线上同样的方式拼进提示词问一次，模型答对，说明检索链路就是瓶颈；答错，才轮到看提示词和模型本身。如果拼进去的片段里本来就带着互相矛盾的旧内容，那也不是模型的问题是数据的问题。

第四步：确认不是生成环节背锅

前面三步都过了，答案还是不对，才把注意力挪到生成。最省事的验证是把人工挑好的正确片段直接塞进提示词问一次，答对说明检索是瓶颈，回前面几段继续找；答错才去看提示词结构、指令是否清楚、模型能力是否够用。

引用来源

每段输出都标注来自哪条片段，答错时能回溯到具体条目而不是靠猜

回归问题集

固定一批带标准答案的问题，每次改完检索链路都重跑，防止改好一个坏一个

链路留痕

记下每一步的召回条数、重排前后顺序，出问题时能倒推是哪一步变了

找问题的顺序记牢：库里有不有、切得整不整、找得到找不到、排得前不前排、拼没拼进去、最后才轮到模型。跳着改基本等于蒙，改完也说不清是哪一步起了作用。想对照各家向量模型和中转站在检索类任务上的表现，可以先去站内页面看当时的资料，不必凭印象选。