RAG 取不到数据怎么排查？三个回答层次见水平

《面试题目》

1. RAG 取不到数据，你怎么排查？

---

《参考解析》

为什么「换个 embedding、调调 topK、把阈值调低」只能算及格

这类回答描述的是动作，不是排查过程：它默认问题出在模型或参数上，而 RAG 取不到数据的原因通常在上游。面试官抛出这题，想听的是你能不能把「检索失败」拆成可验证的环节、按顺序排除，而不是列出几个可以调的旋钮。答不出来不代表你不知道 RAG 是什么，而是说明没有真在生产环境里被这种问题折腾过。

做过项目的人会分四层排查

第一层，数据真的进去了吗。先拿一个已知答案的问题去向量库里直接搜一遍，确认这条内容在不在；同时看导入链路的日志与失败重试——解析失败、增量更新漏批、文档被过滤掉，都会表现为「库里没有，但以为有」。很多线上事故到这一步就结束了，根本不需要动参数。

第二层，chunk 切对了吗。一段里混了好几个主题，向量就被平均成一团模糊的语义；切得太碎，半句话被拦腰截断，关键上下文落到相邻块里。这两种情况都表现为「库里明明有，召回的全是无关段落」。常见对策是按文档结构切（标题层级、段落边界），设置适当的块大小与重叠窗口，并给每块补上标题路径这类上下文。

第三层，query 匹配对吗。用户的问题太长、太口语、或者带了上文指代，直接去检索和文档的表达对不上。这时要做的是 query 改写或扩展：抽取核心实体与意图、补全指代、生成多个检索式。另外纯向量检索对专有名词、型号、数字不敏感，配一路 BM25 或关键词召回做混合检索，往往比换 embedding 模型更立竿见影。

第四层，rerank 对吗。召回回来十条，正确答案排在第 9 位，传给模型依然没用。判断方法很直接：把候选集和 query 的相似度打分打出来看——正确答案根本不在候选集里就是召回问题，在候选集里但被排下去了就是排序问题，两者的修法完全不同。

真踩过坑的人会补上两类细节

一类是非文本内容被切坏。企业知识库里大量内容是表格，如果切分时直接按纯文本处理，行列对应关系全部丢失，向量编码出来的语义是乱的，和用户问题怎么都匹配不上。把表格单独抽出来、转成结构化文本（例如 Markdown 表格）再切，块内语义才立得住。图片同理：先做 OCR 或图注描述，再进库。

另一类是口语化 query。用户问「那个东西怎么弄」，这种表达和文档的书面语之间几乎没有字面与语义重叠，任何检索模型都救不回来。稳妥做法是在检索前加一步改写：让模型先把口语问题转成书面问句并抽取出实体与诉求，再去检索；对多轮对话还要把指代补全成完整问题，否则第二轮之后的检索质量会断崖式下跌。

再往上还能答什么

把「修好了」变成「能量化地知道有没有修好」：建一个小规模的召回评测集（典型问题 + 应该命中的文档），盯 recall@k 与 MRR，任何切分策略、检索方式、rerank 的改动都先在这套集子上过一遍再上线；线上把 query、召回结果、最终喂给模型的证据链留档，badcase 定期回流成评测样本。排查手段上，相似度分布、命中块的原文、以及「有没有被上下文长度截掉」这三样东西应该一键可查——很多时候问题不在检索，而在检索到的内容没进 prompt 或被截断了。

至于换 embedding 模型或做领域微调，那是这条链路都验证完之后的最后一步，不是第一步；答题时把它放在最后，恰好说明你知道排查的优先级。