面试官说：你搭的 RAG 为什么回答不准，从哪开始排查

有个学员找我做模拟面试，简历上写着「独立搭建了基于 RAG 的企业知识库问答系统」。我一看，挺好，这年头能自己搭 RAG 的人不多。

然后我问了他一个问题。

「你搭的 RAG 有时候回答不准，用户反馈说答非所问。你从哪开始排查。」

他愣了一下，说：「可能是模型的问题吧……换个更强的模型试试。」

我说：「你确定是模型的问题，不是你的问题。」

他：「……」

说实话，这个回答我听过不下二十次了。大多数人搭 RAG 遇到问题，第一反应就是换模型。GPT 不行换 Claude，Claude 不行换 Gemini。 换了一圈，问题还在。

因为 RAG 回答不准，90% 的情况不是模型的问题。是检索的问题。

今天我就把这 90% 的情况拆开来讲。下次面试官问你这个问题，你能从第一层排查到第四层，而不是只会说「换模型」。

第一层：你的 Chunk 切对了吗

这是 RAG 系统里最被低估的一个环节。

大部分人搭 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%，才是模型的问题。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

最近我把大家公认最容易翻车的 Agent 开发面试考点 整理成了一份 PDF，从 Prompt 设计到评测体系、从容错链路到系统编排，不只是考题，每道题都附了面试官的考察意图和避坑思路。

我自己面了不少人，也被面了不少次，这些东西说实话，外面那些面经基本看不到。