简介：RAG知识库上线后，常见问题并非“模型不够强”，而是检索链路与生成策略不匹配。本文对比“知识存在但检索不到”与“知识不存在却强行回答”两类典型故障，从架构、召回、上下文构造和生成控制四个维度拆解原因，并给出可落地的优化路径与选型建议。适合正在搭建或排查企业知识库的开发者、技术负责人阅读。
很多团队在搭建 RAG 知识库时，会把主要精力放在两件事上：一是把公司文档写入向量数据库，二是让大模型基于检索结果回答问题。只要这两步跑通，就认为知识库已经可以上线。实际上，这类系统真正进入业务使用后，最常见的问题往往不是模型能力不足，而是检索链路与生成策略之间的错配。
本文围绕两类高频故障展开对比：一类是“知识库里明确存在的信息，模型却找不到”；另一类是“知识库里不存在的信息，模型却给出了看似合理的回答”。这两类问题在表面上都表现为“回答错误”，但产生机制、排查路径和优化方向差异很大。理解这种差异，是后续改进 RAG 系统的基础。
在企业知识库场景中，用户通常带着明确业务问题发起查询，例如“报销流程是什么”“某个接口的限流规则是什么”“某类订单需要哪些审批”。如果系统返回错误信息，业务影响会直接传导到实际工作流中。
但“错误”并不等于“同一种错误”。知识存在却检索不到，本质是召回失败；知识不存在却强行回答，本质是生成失控。前者可以通过优化索引、分词、召回策略和重排模型来改善；后者需要从上下文构造、提示词约束、置信度评估和兜底策略入手。如果把两类问题混在一起处理，常见结果就是反复调整模型参数、更换模型版本，但问题依旧存在。
因此，排查 RAG 知识库问题时，第一步不是改模型，而是先判断当前错误属于召回失败还是生成幻觉。这个判断直接决定后续的优化路径和资源投入方向。
这类问题的典型表现是：用户明确知道某份文档里有答案，甚至能指出文档名称或大致章节，但系统返回的结果却说“未找到相关资料”或给出了其他内容。
从技术链路来看，RAG 的检索阶段通常包含以下环节：文本切分、向量化、相似度召回、可能的重排。任何一个环节处理不当，都可能导致正确答案无法进入最终上下文。
文档进入向量数据库之前，需要先进行切分。切分粒度直接影响召回质量。如果切分过大，一个片段里混入多个主题，向量表示会被稀释，导致与用户问题的相似度降低；如果切分过小，单个片段可能缺少完整上下文，即使被召回，模型也无法从中提取出准确答案。
常见的问题包括：按固定字数切分而忽略段落边界；将表格、代码块或层级标题强行截断；没有保留章节路径或文档元数据。对于结构复杂的业务文档，单纯按字数切分基本都会引入信息损耗。
即使是通用向量模型，在面对企业内部术语、缩写、产品代号、特定业务命名时，也可能出现相似度判断偏差。例如用户问“A 产品的开通条件”，而知识库中相关段落写的是“该产品线的准入规则”，“开通条件”和“准入规则”在业务上等价，但在向量空间中不一定足够接近。
此外，中文场景下还存在专有名词切分错误、数字与单位粘连、同义词未归一化等问题。这些都会导致相关文档的向量相似度排名靠后，从而在 Top-K 截断时被排除。
纯向量检索适合处理语义相似但用词不同的场景，但对精确匹配类查询不够稳定。比如用户查询具体编号、接口名称、配置项、状态码时，关键词匹配往往比语义匹配更可靠。如果 RAG 系统只支持向量检索，或者虽然支持关键词检索但没有合理的融合排序机制，就很容易在精确查询场景下召回失败。
一个更稳健的设计是同时执行向量检索与关键词检索，再通过加权融合或重排模型统一排序。融合策略需要根据业务语料特点调整，而不是简单固定比例。
企业知识库通常有权限边界。不同部门、不同角色能访问的文档范围不同。如果过滤条件没有在检索阶段正确生效，可能出现两种情况：一是无权访问的文档被召回，带来越权风险；二是有权访问的文档因过滤条件配置错误而被排除，表现为“明明存在却找不到”。
这类问题往往和数据权限模型与知识库索引的绑定方式有关。需要确保知识条目在写入索引时就携带清晰的权限标签，并在检索时以强制过滤条件生效，而不是仅依赖事后过滤。
这类问题的表现是：用户问了一个知识库中根本没有覆盖的问题，模型却给出了一个看起来合理但实际不存在的答案。例如用户询问某项尚未发布的政策，模型根据通用知识或语言习惯拼凑出一个“看似正确”的流程。
RAG 本质上并没有让模型学会企业内部资料。它只是在模型回答问题之前，临时检索相关片段并放入当前上下文。模型仍然基于自身预训练能力组织语言。如果检索阶段没有找到相关材料，而提示词又没有明确约束模型在材料不足时拒答，模型就可能依靠自身知识储备“补全”答案。
很多 RAG 框架在检索结果为空或相似度低于阈值时，仍然会把一个空上下文或几条低相关文档交给模型。此时如果没有额外指令，模型会倾向于“尽力回答”，因为默认的生成目标就是满足用户请求。这种倾向在通用对话场景中是优点，但在企业知识库场景中则是风险。
一种常见的改进方式，是在提示词中明确要求模型先判断给定材料是否足以回答问题，如果不足以回答，则直接告知用户“当前知识库中未找到相关材料”，而不是生成推测性内容。这个判断环节需要明确的指令设计，否则模型仍然可能将低相关信息视作有效依据。
在多轮问答中，模型会根据当前提示词中的历史消息理解上下文。如果历史消息中包含过时的、已撤回的或与当前问题无关的信息，模型可能将其误用为回答依据。这类问题在长会话中更容易出现，尤其当用户切换话题或引用之前无关内容时。
| 对比维度 | 知识存在但检索不到 | 知识不存在却生成答案 |
|---|---|---|
| 故障位置 | 主要在检索链路 | 主要在生成控制与提示策略 |
| 主要表现 | 返回无关内容或表示未找到 | 给出看似合理但无依据的答案 |
| 召回结果特征 | 正确答案未进入 Top-K 或排名靠后 | 检索结果为空或低于相关性阈值 |
| 模型行为 | 基于错误材料或不足材料回答 | 基于自身预训练知识补全 |
| 优化方向 | 切分策略、向量对齐、混合检索、重排、权限过滤 | 提示词约束、材料充分性判断、兜底应答、多轮上下文管理 |
| 排查起点 | 检查召回日志、相似度分布、切分结果 | 检查上下文内容、相似度阈值、提示词指令 |
| 对模型升级的依赖 | 较低，普通模型改动影响有限 | 中等，指令遵循能力强的模型有助于改善，但仍需配合提示与阈值设计 |
从上表可以看出，两类问题在技术链路上有清晰边界。实际生产环境中，二者还可能同时出现在同一次查询中，例如召回质量本身较差，同时模型又没有有效的兜底机制，导致错误被进一步放大。
首先需要检查文本切分方式。对于结构化文档，应保留标题层级、表格结构和文档元数据。对于非结构化文档，可以尝试基于段落边界和语义完整性切分，并在切分后增加必要的上下文补充。
其次，评估向量模型在自有语料上的表现。可以构建一个小规模标注集，人工确认若干查询对应的正确文档片段，然后对比召回命中率。如果基础召回率明显偏低，需要重点优化索引与向量化策略。
再次，引入混合检索。关键词检索可使用通用全文检索能力，向量检索负责语义补全，再通过融合排序整合两路结果。对于精确匹配类查询，可适当提高关键词检索的权重。
最后，检查权限过滤是否符合预期。确保过滤条件在召回阶段即为强制条件，而非召回后再处理。
首先，在提示词中加入材料充分性判断环节，明确要求模型先检查给定片段是否包含回答所需信息。如果材料不足，应直接返回“未找到相关内容”或“该问题需要人工确认”，而不是生成推断性答案。
其次，根据业务场景设置合理的相似度阈值。低于阈值时，可选择直接返回未命中，或将低相关片段标记为“参考性材料”，要求模型在回答中明确区分“知识库明确信息”与“一般性背景补充”。
再次，在多轮对话中，需要在每一次请求时对历史消息做必要裁剪或摘要，避免无关旧信息干扰当前问题。对于涉及规则类、政策类查询，可在回答后附加“依据文档”列表，便于用户核对。
无论是检索失败还是生成幻觉，都需要通过日志和用户反馈定位问题。建议至少记录以下信息：用户原始问题、召回文档编号及相似度、最终构造的上下文、生成的回答。通过对这些信息进行抽样分析，可以判断故障集中在检索还是生成环节。
同时，可以设置“回答是否可信”或“答案是否解决问题”的用户反馈入口。持续积累的反馈数据可用于后续重排模型训练、阈值调整和提示词优化。
在实际系统中，检索与生成是相互衔接的两个阶段，任何一端的缺陷都可能被另一端放大。因此，建议在设计 RAG 系统时，将检索质量评估与生成控制策略解耦管理。
具体来说，可以增加一个中间判断层，在生成回答之前分析召回结果的质量。判断维度可以包括：最大相似度是否超过阈值、结果内部一致性如何、是否包含明确可引用的答案片段。根据质量评估结果，选择不同的执行分支：正常回答、补充提示后回答、明确通知用户知识库未覆盖该问题、转入人工处理流程。
这样的设计可以避免将所有问题都推给大模型处理，也可以让检索链路的问题更容易暴露出来。
RAG 知识库的问题不能简单归结为“模型不懂业务”。很多情况下，知识存在但检索不到是在召回链路引入的信息损耗，需要用切分策略、混合检索、权限过滤和可观测性来优化；知识不存在却生成答案则更多受提示词设计与生成控制策略影响，需要通过材料充分性判断、相似度阈值和兜底应答来约束。
排查时应先做问题归类，再针对性地分析日志与召回结果。对知识检索链路与模型生成行为分别建立评估指标，可以帮助团队更准确地定位问题，而不是在错误的环节上反复调优。对于企业知识库这种对准确性要求较高的场景，为“不确定”和“未命中”设计明确的下游路径，往往比单纯追求“模型回答得更流畅”更有价值。