RAG答非所问？先排查向量检索链路，别急着换模型

1. 答非所问不等于模型差：先讲一次真实故障的完整复盘

做 RAG 项目最怕遇到的场景，莫过于用户问了一个明明知识库里存在答案的问题，系统却给出一个风马牛不相及的回复，或者在正确答案旁边绕来绕去。更气人的是，如果你把同一个问题直接甩给底层大模型，它反而能说个八九不离十。这时候绝大多数人的第一反应都是"模型不行""换个大模型试试"。我见过不少团队把时间耗在替换模型、调 prompt、改温度参数上，折腾一两个礼拜毫无收获。

我在实际维护 RAG 服务时遇到过一次典型故障，现象是这样的：知识库里有三十多篇产品操作手册，用户问"如何设置定时备份"，系统却回答"备份策略只有管理员可以修改"，而且把权限说明部分的内容完整吐了出来。初步看似乎是模型理解能力不足，但当我打开检索链路日志，把向量召回的结果直接打印出来看了一眼，问题立刻浮出水面——召回的 Top5 文本片段里，有四条来自"系统权限管理"章节，没有一条真正命中"定时备份"的内容。

问题根本不在模型侧。RAG 是一个完整的链路，向量召回只是其中一环，但这一环决定了模型"能看到什么"。模型再聪明，看到的材料本身就是跑偏的，它就只能跑偏。所以我一直坚持一个排查原则：RAG 答非所问，先查向量，再怪模型。

这个原则背后是概率博弈。一套成熟 RAG 系统出问题，检索环节出错的概率远大于生成环节。模型幻觉、prompt 写得稀烂当然存在，但更常见的是分块不合理、嵌入模型与领域文本不匹配、查询改写做得太粗暴、相似度阈值设得太高或太低、召回 TopK 太小导致关键内容根本没进模型视野。这些问题全部发生在"向量进模型之前"，而它们的临床症状，清一色是"答非所问"。

所以这篇文章想聊聊，当 RAG 出现答非所问时，我是怎么定位问题、怎么判断问题出在向量侧还是模型侧的。顺便会把整个链路里最容易埋雷的几个环节捋一遍，附上我自己实际在用的调试方法和补救措施。核心就一句话：不要急着换模型，先把向量检索这一路查明白。

2. 向量检索链路上的四个"黑手"：为什么问题多半出在检索侧

先说结论：RAG 的检索质量是由一条流水线决定的，任何一环不到位，召回的内容就是歪的。这条流水线通常包括四段——文档预处理与分块、嵌入模型选型、向量索引构建、查询时的检索策略。每一段都可能成为"答非所问"的元凶，而且它们的错误是滚雪球式的，越往后越难救。

2.1 分块策略：召回不准的第一大来源

很多人觉得分块就是"把文档切成一段一段"，没什么技术含量。实际上，分块粒度直接决定了语义边界的完整性。我见过最典型的反例是用固定长度切块，比如每 300 个 token 一刀切下去，结果把一个完整操作步骤从中间截断，前半段在上一块，后半段在下一块。用户问"设置定时备份"，恰好那个操作说明被切散在两块里，每块各自只有一半信息，嵌入模型对这两块内容的向量化表示都变得模糊，召回质量自然崩。

更隐蔽的问题是块与块之间完全没有重叠。即便那一刀切得刚好在段尾，但如果某段内容跨越了文档的自然语义边界，比如一段里既有"如何创建定时备份"又有"备份失败时的常见原因"，嵌入向量会把两个主题混合编码，检索时无论用户问哪个方向，召回结果都带杂质。

我实际采用的策略是分块大小与嵌入模型的输入窗口配套，通常在 500 到 800 个 token 之间，同时设置 50 到 100 个 token 的 overlap。遇到表格、代码块、标题层级分明的文档，会先做结构化清洗，把 Markdown 标题、表格列名、列表前缀这些"语义锚点"保留下来再切块。这样切出来的一块，基本是一个语义自洽的单元，检索命中效率高很多。

2.2 嵌入模型：没选对，检索质量直接输在起跑线

嵌入模型的作用是把一段文本映射成向量，让相似语义的文本在向量空间里离得近。但这个"相似"是和数据分布强相关的。通用领域文本用通用嵌入模型效果尚可，一旦知识库是专业垂直领域，比如医疗、法律、机械故障诊断、老旧的内部系统文档，通用嵌入模型往往力不从心。

举个真实例子：我的一个知识库里有大量"变频器故障代码对照表"，用户问"F0021 报错是什么意思"，通用嵌入模型把"F0021"当成一个无意义的 token 处理，向量表征更侧重于"报错"这个通用词，检索出来一堆别的故障代码解释，真正的 F0021 条目排到了几十名开外。这其实就是查向量时特别容易踩的坑：领域专有名词、型号、编号、缩写，在通用向量模型里几乎没有辨识度。

如果你发现自己的知识库里充满了这类实体型文本，建议不要硬撑。要么换成在相近领域语料上微调过的中文嵌入模型，要么在检索前加一层查询改写，把"F0021 报错"改写成"变频器故障代码 F0021 的含义"，再喂给向量检索。还有一种更省事的方案是混合检索，把关键词精确匹配的结果和向量召回的结果做融合，对编号类查询特别管用。

2.3 向量索引构建：数据对了，但查不出来等于白搭

就算分块和嵌入模型都没问题，向量索引本身也可能出岔子。开源的向量数据库很多，比如 Milvus、Qdrant、Chroma，各有各的索引参数。大多数人对这些参数无感，直接用默认值。默认值通常偏保守，追求速度但不那么精准。

最典型的参数是 HNSW 图索引里的 efSearch 和 M。efSearch 越大，搜索时探索的候选节点越多，精度越高，但响应变慢；M 越大，图的连通度越高，召回越全，但构建索引的时间和内存消耗都会涨。用默认配置跑小规模数据集没问题，文库一上十万级向量，精度滑坡是分分钟的事。

我自己遇到过的情况是：十万条向量，默认 efSearch=40，某个查询在测试集里只能说够用；但知识库扩到五十万条后，同样的查询召回的相似度分数整体下滑，命中条目掉到 Top10 之外。把 efSearch 提到 200 之后，召回明显改善。如果你要做高召回率的任务，检索性能这块一定得亲手调，别拿默认参数硬扛。

索引的另一大坑是增量更新。很多 RAG 项目在导入新文档后，只是把新向量追加到集合里，但 HNSW 等图索引结构不会自动调整之前构建好的图。旧数据和新数据之间的连接关系会变稀疏，导致新入库的、与查询语义最接近的内容反而召不回。处理好这一块的唯一办法是定期重建索引，或者使用支持在线建索引的向量库并把构建参数调到一个合理的平衡点。

2.4 检索策略：TopK、阈值、混合查找，这三件事决定模型"吃什么"

召回环节最后一步是决定哪些内容能进模型的上下文。这里的变量有三个：TopK 数量、相似度阈值、是否使用混合检索。

TopK 太小的后果很直观——真命天子排在第 6 名，结果你只取前 5 条，信息到不了模型那儿。TopK 太大同样有问题，无关内容会混进来稀释注意力，模型反而被噪声带偏。阈值的逻辑也不难：阈值定太高，什么都召不回，模型无中生有；阈值定太低，召回的垃圾内容全往上下文里塞，模型被五花八门的信息干扰。

混合检索是个更高级的话题。纯向量检索对语义相似有效，但对精确匹配的编号、命令、产品名不敏感；纯关键词检索（BM25）反之。把两种检索结果做加权融合是工程上非常值得做的事。我在多个项目里把向量召回与 BM25 召回的融合权重调为 0.7 比 0.3，再按融合分数重排，编号型查询的命中率直接翻倍。

3. 排错要按链路走：从问题现象到根因的完整定位流程

说了这么多可能出问题的环节，怎么定位到具体某一环才是实操者最关心的。我总结了一套自己的排查链路，核心思路是从模型端往上回溯。模型回答不对，先看它吃了什么；吃的东西不对，再往上看检索的每一步。

3.1 第一步：把"模型吃进去的东西"原样打印出来

这一步是免费且见效最快的。不管用的是 LangChain、LlamaIndex 还是自己手写的 RAG 流程，在把检索结果拼进 prompt 之前，拦一道，把最终拼接好的上下文内容完整写到日志里。

看日志的时候重点观察三件事：第一，召回片段跟用户问题的主题贴合度；第二，召回的排序是否合理，正确答案是否排在靠前位置；第三，上下文里有没有明显无关的段落混入。如果这几条里有一条不对劲，问题大概率在检索侧。如果召回的每一段内容都准确、完整、紧扣问题，模型却还是答错，那才能往模型侧的方向怀疑。

这个步骤听起来简单，但很多项目根本没做。生产环境里 RAG 服务是个黑盒，用户只看到问题和答案，中间的上下文对谁都不透明。没有这一层可观测性，后面的排查全部抓瞎。

3.2 第二步：测试集回归，区分"偶发幻觉"和"系统性偏差"

单次故障不能说明问题，要判断是偶发还是系统性的，得有一组覆盖各类型的测试问题。我维护一个大约 40 条问题的回归集，包含事实型问题、操作步骤型问题、编号型问题、描述型问题，每个问题都标注了期望召回片段和标准答案。

每次故障处理完，先跑一遍这个回归集，看整体召回率和答复准确率的变化。如果只是个别问题答错，可以按个例排查；如果一大片问题都答非所问，那多半是某个全局环节崩了，比如嵌入模型换了、分块参数被改过、向量库集合被清掉重建了、索引参数被重置了。

3.3 第三步：手动向量检索，把真实召回结果和期望结果做对比

定位到检索环节之后，不要看日志里的相似度分数就完事，直接用同一个查询向量、同一个向量数据库去手动跑一次查询。这一步有几个技巧：

• 查看每条召回文本的原始内容和所在文档标题，确认语义是否贴合；
• 观察相似度分数的梯度。如果 Top1 到 Top5 的分数差距很小、内容又互相矛盾，说明分块或嵌入模型对文本的区分度不够；如果分数普遍极低，说明用户查询和知识库中的内容在向量空间里距离太远，通常是查询表述和库内表述差异过大，或者嵌入模型对这类文本认识不足；
• 用同一个查询换几个近似措辞再查，比如"定时备份"和"设置备份计划"，看召回结果的稳定程度。稳定性差说明文本语义边界不清晰或查询改写缺失。

手动向量检索调试可以借助向量数据库自带的调试工具，也可以直接写几行 Python 脚本。别嫌麻烦，这一步做完，问题出在哪个环节基本就确定了。

4. 修复的真实案例与优化手段：从分块到检索策略的一次完整调整

理论说了两章，还是落到实战里更扎实。拿我最常遇到的两类问题展开讲讲：一类是纯文本类知识库的召回漂移，一类是混合型文档的召回混乱。这两类基本覆盖了大部分 RAG 答非所问的场景。

4.1 案例一：纯文本文档的分块策略翻车与重建

先看这个案例。知识库内容是 30 篇包含操作说明的 Markdown 文档，原始实现是固定 400 token 切块，无重叠，嵌入模型使用通用中文模型，向量数据库是 Chroma，默认配置，TopK 取 4。用户问"如何导出操作日志"，答案一直不理想，召回到的全是权限说明和系统配置类内容。

排查过程按上面那套链路走：把模型吃到的上下文打印出来，发现四条召回记录里三条来自"角色权限"章节，只有一条沾了点"日志"的字眼。手动向量检索同样的问题，Top10 里关于"导出操作日志"的内容都在 10 名开外。再一看文档结构，答案其实分布在两个相邻章节里：一章是"日志管理的概念"，一章是"导出日志的详细操作"，跨了两章的内容。400 token 固定切块把两段各自切得支离破碎，语义被稀释。

修复分两步：第一步，改用 600 token、overlap 为 100 token 的切块策略，同时对文档做结构化切分，在遇到二级标题时强制作为新块起点；第二步，对"导出操作日志"这类动宾结构的查询，在查询改写阶段加上同义扩展，比如"导出"扩展到"备份、下载、保存"。改完以后，手动检索 Top5 里出现了完整操作步骤，模型回答明显贴合。

这类问题的根因是分块和嵌入模型的联合失效，本质在于分块切毁了语义边界。遇到类似症状，先把文档类型摆出来，看看是不是操作类文本，是的话优先考虑结构化切分。

4.2 案例二：混合型文档的召回混乱与混合检索改造

第二个案例更难一点。知识库里有产品说明书、公告通知、内部 wiki，还有一份几百页的 Excel 表格转成的 CSV 格式数据。用户问"最近一次价格调整是什么时候，调整幅度多大"，RAG 召回了产品说明书里关于价格体系的介绍、通知里的活动促销内容，唯独没召回真正包含调价日期的公告和 CSV 里的价格变更记录。

原因不复杂：CSV 数据被转成一段一段纯文本之后，语义非常松散，通用嵌入模型对它几乎无感；而价格调整这种动态事实，存在于公告和 CSV 里，被固定格式的说明书文本淹没。纯向量检索对这类结构化数据的召回率天然就差。

我的处理方式是给这个知识库加混合检索通道：保留向量召回的同时，用 BM25 对原始文本做关键词召回，再把两路结果合并重排。同时对 CSV 这种表格数据，在转文本阶段保留表头和列名，比如把"日期, 商品, 原价, 调整后价格"这一行保留成"2024-03-15，商品 A，原价 100，调整后价格 120"，再用正文模型做向量化。改完之后，用户问调价相关信息，BM25 通道能通过"调价""2024-03-15"这类精确词命中日期的记录，向量通道能通过"价格调整幅度"的语义命中期含义，两侧互补，召回质量提升非常明显。

这个案例的核心启发是：RAG 系统面对的数据往往是异构的，单一检索策略很难覆盖所有情况。先说结论：RAG 的检索质量是由一条流水线决定的，任何一环不到位，召回的内容就是歪的，所以先查向量再怪模型不是偏袒某一边，而是链路概率决定的系统性排查优先级。

4.3 修复中的参数细节：TopK、融合权重和重排策略的取舍

上面两个案例都涉及参数调整。我把我实际使用的参数范围列出来，供参考：

这几个参数是联动的，只调一个不调另一个有时反而坏事。最典型的例子是：你把 TopK 从 5 提到 10，但相似度阈值没动，召回的尾部开始混入弱相关的片段，模型反而被噪声干扰；如果你同时把阈值从 0.75 提到 0.8，弱相关的片段被过滤掉，效果又会回升。

重排模型是另一个值得投入的方向，特别是知识库检索量大到一定程度、不用重排就难以保证 TopK 准确性的场景。它的机制是在向量和 BM25 召回的前几十条候选里，用 cross-encoder 逐条计算与用户问题的相关度分数，再按这个分数重排。因为 cross-encoder 做了查询和文档的细粒度交互，精度明显高于双塔式的嵌入模型相似度判断。代价是慢，所以只用来处理候选集，而不是全库扫描。

5. 长期维护视角：给 RAG 系统建立"检索健康度"监控机制

排错能力再强，也不如让问题少发生。做了一段时间 RAG 之后，我给自己带的每个项目都补上了数据可观测性建设。这一步没多高大上，就是把排错时看的东西变成长期监控的指标，提前发现漂移。

5.1 监控什么：三类关键指标

第一类是召回相关指标。对带标准答案的测试集，定期跑一次，记录平均召回率、Top1 准确率、Top5 准确率。这个曲线一旦出现连续下滑，说明知识库或检索配置出问题了。别等用户来投诉答非所问，指标先报警才叫健康。

第二类是相似度分数分布。日常操作中保存所有查询的相似度分数，定期观察分数分布形态。正常情况是大多数查询的 Top1 分数落在 0.75 到 0.9 之间，分布相对集中。如果分数整体下移，说明新入库内容和旧内容之间的向量空间分布开始割裂，可能要重建索引或调整嵌入模型了。

第三类是端到端回答质量。这个稍微主观，但可以用简单的规则做粗筛：回答长度异常短、直接输出"我不知道"、回答与召回片段关键实体不一致，这些都能用脚本批量检测。指标不一定精确，但能快速锁定风险区域。

5.2 发布变更时的回归检查

大部分 RAG 系统的质量问题都是在变更时引入的。换嵌入模型、调整分块参数、升级向量数据库、改 prompt 模板，任何一个动作都可能悄无声息地改变检索行为。我自己的习惯是，任何检索侧变更都要跑一遍回归测试集，并且把变更前后的检索结果快照存在一起对比。对比时不能只看答案是否正确，还要看召回的片段是否发生大面积漂移。

还有一个容易忽略的细节：用了外部嵌入模型的在线接口时，模型供应商偶尔会升级模型版本，向量维度或语义分布会变，旧索引里的向量和新查询向量之间的一致性就会出现裂缝。处理办法是固定模型版本，或者每次升级后强制重建索引。我自己就踩过一次这个坑，嵌入模型悄悄升级后，整个知识库的检索精度肉眼可见地下滑，排查了半天才发现是版本变了。

5.3 定期重建索引，不等于删除重建

向量索引维护中常见的困境是：旧数据不能动，新数据持续进来，图结构越滚越复杂，检索性能逐渐劣化。我的建议不是随便删重建，而是采用分区式策略。比如按时间或按文档来源建多个集合，写入时只进增量集合，检索时跨集合查询；对增量集合定期合并，把过期数据淘汰掉。这样做既能保证新数据能被及时召回，又避免了大全量重建带来的短期不可用。

实际执行时要注意跨集合查询会带来额外的延迟，如果集合数量超过五六个，建议合并成更大的分片，或者在业务低峰期做周期性的全量重建。这个要根据你的向量数据库能力和业务容忍度来做权衡。

6. 排错手记里的个人经验：一些常规文档不会写的教训

最后聊几个在真实项目中反复踩过的点。这些经验不保证百分之百套用到你的场景，但大概率能帮你少走弯路。

第一个教训是别把"答非所问"想得太简单。它可能是分块问题，可能是嵌入模型问题，可能是索引问题，可能是混合检索缺失，也可能是模型自身的指令遵循问题。不建立排查链路，只靠"猜"和"试"，运气好能修好一次，但下次换个症状又得重新猜。把链路日志、测试集、手动检索这三板斧用起来，排错效率会提升一个量级。

第二个教训是向量相似度分数不是万能的。很多 RAG 项目把相似度阈值当成一道硬性过滤标准，分数高于阈值就认为相关，低就丢弃。这是最坑人的误解。分数高低受嵌入模型影响巨大，不同模型之间的分数分布天差地别，同一个模型在不同的向量数据库里也可能因为归一化方式不同而数值不同。所以阈值的设定必须基于你自己知识库的真实数据分布来校准，而不是拿网上的默认值抄一遍。

第三个教训是查询改写真的值得做。用户问的是一句口语化描述，知识库里存的是一段正式文档语言，两者在向量空间里的距离可能很远。如果每次手动检索的分数都偏低，先不要调整数据库参数，先想想该不该加一个查询改写层。用语言模型把口语问题转写成更贴近文档风格的表述，或者提取关键实体扩展同义词，往往比盲目调参收益大得多。

第四个教训有关测试集的构建方式。构建回归集时不能只挑自己记得清楚的、效果好的问题，要故意把容易混淆、格式特殊、跨章节的内容也放进去。否则测试集本身有偏，跑出来的指标再好看也没有说服力。我自己构建测试集时会把"错误答案概率高的查询"和"正确答案概率高的查询"混合在一起，并标注每个查询期望召回的文档 ID 或章节 ID，这样定位问题会非常快。

我处理过的 RAG 项目里，绝大多说答非所问的根因都不在模型侧。不是说模型永远没问题，而是模型问题往往更容易暴露——你给它一个明确的、上下文完整的提问，它答错了，才是模型的事。而在 RAG 场景下，模型看到的上文本身是检索环节决定的，检索歪了，模型就跟着歪。所以你的知识库模型最近开始答非所问，别急着换模型，也别急着骂模型，先打开日志看一眼它"看"到了什么，再走一遍上面的排查链路。你会发现，大多数时候，问题都埋在向量那条路上，找到它、修掉它，模型自然就正常了。