RAG回答不准排查指南：从数据到检索全流程
于是追问了一个关键问题：「你搭建的 RAG 系统偶尔回答不准，用户反馈答非所问。你会从哪个环节开始排查？」
他愣住了，回答：「可能是模型的问题吧……换个更强的模型试试。」
继续追问：「你确定是模型的问题，还是你设计的问题？」
他：「……」
这个回答我已经听过不下二十次。大多数开发者在 RAG 系统出问题时，第一反应就是替换模型。GPT 不行换 Claude，Claude 不行换 Gemini。换了一圈，问题依旧。
因为 RAG 回答不准，90% 的情况根源不在模型——而在检索链路。
今天就把这 90% 的故障场景拆解透彻。下次面试官抛出这个问题，你能从第一层排查到第四层，而不是只蹦出「换模型」三个字。
第一层：你的 Chunk 切分策略对吗
这是 RAG 系统里最容易被低估的环节。
大部分人在切分文档时方式过于粗暴。固定 500 个字符一刀切，不关心句子是否断在中间，不管段落边界在哪里。切完直接扔进向量库，以为万事大吉。
然后用户问「公司去年的营收是多少」，系统检索回来的片段却是「……同比增长 23%。其中 Q3 表现尤为突出，但需要注意的是，以下数据基于……」——前面缺失了具体数字，后面丢失了上下文关联。
这种问题我们称作语义截肢。
有一个极其典型的案例。某份合同文档中，条款第 3 条和第 4 条逻辑上紧密关联，结果 chunk 恰好切在第 3 条最后一句和第 4 条第一句之间。检索回来的片段刚好漏掉了关键限制条件。AI 基于这个不完整的片段回答，直接给出了在法律上完全相反的结论。
排查方法很简单。取出用户的问题以及检索回来的 top-3 片段，人肉读一遍。如果你读完也感觉无法准确回答，那么问题一定出在切分策略上，跟模型毫无关系。
如何修正。三个方向入手。
第一，按语义边界切分，而非固定长度。段落、章节、条款——这些天然结构才是切分锚点。长度只作为兜底约束，不是主要策略。
第二，启用重叠窗口。相邻 chunk 之间保留 10% 到 20% 的重叠区域，防止关键信息恰好落在切分缝隙里。
第三，携带元数据。记录每个 chunk 来自哪个文档、第几页、第几段。出问题时能快速溯源，而不是在向量库里大海捞针。
给学员的总结就一句话：「Chunk 策略是 RAG 的地基。地基歪了，上层架构再优化也无济于事。」
第二层：检索回来的内容，真的与问题相关吗
好，假设 chunk 切分没有问题。接下来要排查检索质量。
这里存在一个特别普遍的误区。很多人认为向量检索就等于语义检索，语义检索就等于准确检索。并非如此。
向量检索本质上是相似度匹配。将问题和文档都转为向量，然后计算余弦相似度。相似度高的结果排在前面。
但问题在于：相似不等于相关。
举个例子。用户询问「Python 的 GIL 是什么」，知识库里有一篇文档叫「Python 多线程性能优化指南」，文中大量出现 GIL、线程、锁等术语。向量相似度极高，排在检索结果第一位。
但这篇文章讲的是如何绕过 GIL，而不是解释 GIL 的作用。用户看到的是一堆优化技巧，而非基础概念。
这就是典型的高相似度、低相关性。
排查方法依旧很简单。把 top-3 检索结果拿出来读。如果你觉得返回的片段与用户问题之间存在信息鸿沟，那么问题就在检索环节。
如何修正。
第一，设定相似度阈值。低于某个分数直接丢弃。宁可返回「我不知道」，也别返回一堆看似相关实则无关的内容。
第二，采用混合检索。纯向量检索对关键词不敏感。用户搜索「2024 年财报」，向量检索可能返回一堆语义相关的财报分析，却不一定是 2024 年的。搭配 BM25 关键词检索做混合，能大幅提升准确率。
第三，加入 Rerank 重排序。初检索返回 top-20，再用专门的重排序模型精筛出 top-3。从 20 到 3 的这一步，其重要性远高于从 1000 到 20 的过程。
坦诚地说，大部分 RAG 系统的检索质量，加一个 Rerank 模型就能提升 30% 以上。但很多人根本不知道还有这个优化层级。
第三层：上下文拼接正确了，但 AI 依然胡编乱造
到达这一层，说明 chunk 切分和检索质量都没有大问题。但 AI 的输出仍然不对。
排查方向需要转变：不是检索的问题，而是 AI 对上下文的阅读理解出了问题。
常见场景有三种。
第一种，上下文过长。为了保险，你把 top-10 的检索结果全部塞进 prompt。结果上下文长度过大，AI 读到后面忘记前面，或者关键信息被淹没在海量无关文本中。
第二种，上下文相互矛盾。检索回来的两段内容，一段说「公司 2024 年营收 50 亿」，另一段说「公司 2024 年营收目标 80 亿」。AI 不知道应该信哪个，于是开始编造答案。
第三种，prompt 指令不够清晰。你没有明确告诉 AI「如果检索结果不足以回答问题，就回复不知道」。于是 AI 基于不完整的信息，强行拼凑了一个答案。
这三种情况的排查方法相同。把拼接好的完整 prompt 打印出来看。你喂给 AI 的上下文，自己读完能否回答用户的问题。如果连你自己都觉得信息不全或信息矛盾，AI 必然翻车。
如何修正。
上下文过长 → 减少 top-k 数量，或者先对检索结果做一轮摘要压缩。上下文矛盾 → 在 prompt 中追加指令，要求 AI 标注信息来源，遇到冲突时优先采信最新或最权威的源。指令不明确 → 加一句「如果上下文信息不足以准确回答，请明确告知用户，不要自行编造」。
第四层：用户的问题本身就有问题
这一层很多人想不到。
RAG 回答不准，有时候不是系统的问题，而是用户问得太模糊。
比如用户只输入「这个怎么样」四个字，没有任何上下文。你怎么让 RAG 检索？检索什么？
或者用户说「帮我总结一下」。总结什么？最近三天的文档？上个月的会议纪要？还是整个知识库？
这类问题下，RAG 检索回来的内容大概率是随机的，因为 query 本身就没有明确的语义指向。
排查方法。查看用户的原始 query。如果 query 本身模糊、短小、缺乏关键词，那么 RAG 回答不准是正常现象。
如何修正。
第一，增加 query 改写环节。在检索之前，用 LLM 把用户的模糊问题改写成清晰的检索 query。例如「这个怎么样」→「用户希望了解当前讨论的产品或方案的评价与反馈」。
第二，引入追问机制。如果 query 太模糊，不要强行检索。反问用户「您需要了解哪方面的信息？」，让用户补充上下文。
第三，利用历史上下文。把用户前几轮对话的内容拼接到 query 中一起检索。很多时候用户口中的「这个」，指的就是上一轮讨论的对象。
一张排查清单
好，四层都讲完了。下面总结成一张排查清单。下次 RAG 系统回答不准，按这个顺序逐一排查。
第一层：Chunk 策略
- 切分方式是按语义边界还是固定长度
- 是否启用了重叠窗口
- 关键信息是否被切分在两段之间
第二层：检索质量
- top-3 结果与用户问题是否真正相关
- 是否设置了相似度阈值
- 是否使用了混合检索
- 是否加入了 Rerank 重排序
第三层：上下文组装
- 上下文是否过长
- 不同片段之间是否存在矛盾
- prompt 是否明确「不知道就回复不知道」
第四层：用户 Query
- 用户问题本身是否过于模糊
- 是否做了 query 改写
- 是否利用了历史对话上下文
面试时，如果能按这个顺序一层一层展开，面试官大概率不会再继续追问。
因为这四层，已经覆盖了 RAG 系统 90% 的故障场景。
剩下的 10%，才是模型本身的问题。
文章写到这里，希望对正在搭建或优化 RAG 系统的你有所启发。