RAG 知识库为什么答不准：切片到召回的五个断点

很多企业上知识库的第一版都长这样：把共享盘里的制度文件、产品手册、会议纪要批量导入，接一个大模型，前面加个对话框。演示给领导看时挺像回事，真交给业务用，问题立刻冒出来——问报销标准，答的是三年前的旧版；问某类合同该找谁签，答得头头是道，翻原文根本没有这句。

这类失败很少是模型不够聪明。从文档进系统到答案出屏幕，中间有五处会持续漏信息：切片、语义、召回、重排、上下文。任何一处没处理好，答案都会歪，而且歪得很自然，让人看不出错。下面按链路顺序讲这五个断点：症状、怎么判断、怎么改。

问题不在模型，在文档到答案的那条链路

RAG 拆开只有四步：切片、向量化入库、按问题召回、把片段拼进上下文交给模型。前三步都在做筛选，模型只在最后一步说话。前面筛掉的、筛歪的，模型补不回来，它只会基于手里那几段材料把话说圆。

一个真实场景：八十页的制度 PDF 按固定五百字切，第三十七片正好把「审批额度」和「适用岗位」切断。用户问「部门经理能批多少」，召回到的是后半片，只有金额没有岗位，模型于是给出一个听起来合理、实际越权的数字。日志里这一轮完全正常。

所以排障的第一条规矩是：先看喂进去的原文，再看模型的回答。把那一轮的召回片段原样打印出来，人工读一遍，多数问题当场就露馅。跳过这一步直接换模型或者加提示词，通常只是把同一个错误换个说法。

下面这张表是项目里实际在用的排查清单，从左到右就是排查顺序。前三个断点占了问题的大头，先查它们，通常能解决七八成。

表里「判断方法」这一列都设计成不用改代码、一小时内能跑完的动作。抽二十个真实问题，把召回原文打印出来对着表看，定位往往比读一周代码更快。

有两个断点值得多说。切片最隐蔽，切坏了不影响运行，只影响答案完整性；重排最容易被误判，片段都召回到了，模型却挑了错的那条，看着像理解能力不行，实际是排序没做。有一次排查，召回从五条放宽到十五条后，正确片段排在第十一位——加一层重排就解决了。

五个断点不要一起改。改动叠加时，你无法判断是哪一项起了作用。建议按「切片、重排、上下文」的顺序推进，每一步都留一份固定的评测题，改完立刻回测。

把「每五百字一刀」改成按标题层级切：一级标题下的完整小节为一个片段，单片控制在 300 到 600 字，条款类文档一条一片，绝不跨条。表格和流程图单独成片，并在片段开头补一行「所属文档、章节、生效日期」。

这行前缀很关键：它让片段脱离原文后仍能自证身份，问到「新版还是旧版」时模型才有依据。改造量主要在清洗脚本，两百页的文档集一个人两三天能跑完第一版。

调大召回条数最省事也最容易出事：条数一多，噪声跟着进上下文，模型反而更容易被带偏。正确顺序是先把召回放宽到 10 到 20 条做候选，再用一层重排按相关性打分，只把前 4 到 6 条送进上下文。

重排带来的延迟通常在几百毫秒量级，内部问答完全可以接受。判断重排有没有用，看同一个问题在开关两种情况下的答案差异，不要只看离线指标。

窗口再大也不要塞满。给检索片段留固定预算，按相关性从高到低填，超出就截断而不是硬塞；单片段过长时先做摘要再拼进上下文。

同时要求每个答案标注来源片段编号，前端能点开看原文。这不只是体验问题——带引用的答案业务才敢用，用错一次就没人再信。

常见误区是把预算全押在换更强的模型上。从项目经验看，链路改造带来的提升远大于换模型：切片和重排做好，一个中等规模的模型就能答得相当稳；链路不修，换什么模型都答不准，只是错得更流畅。

真正的成本在三块：文档清洗与切片改造的人力、评测题整理、上线后的内容维护。第三块最容易漏算——制度一改版，旧片段还在库里，模型就会拿旧答案回答新问题。

风险方面，三件事必须在上线前定好：谁能看哪些文档，权限要落到片段级而不是只做菜单级；文档过期由谁负责下架；答不出来时怎么兜底。明确说「资料里没有」，比编一个答案强得多。

验收不要用「感觉答得挺准」这种描述。固定一份五十到一百题的评测集，覆盖高频问题、跨文档问题、无答案问题三类，每次改动回测同一份，看四个数：

谁负责：业务方出题并判定答案对错，技术方负责链路与指标看板，内容负责人管文档时效。交付物至少包含评测集、指标看板、切片规范文档，以及一份「已知不支持的问题清单」。

RAG 答不准，绝大多数时候不是模型的问题，是链路的问题。五个断点里切片和重排的性价比最高，先动这两处，通常两周内就能看到明显变化。

如果手上正好有一套答不准的知识库，可以把文档类型、大致页数、现在用的切片方式整理一下，打 400-873-2750，或通过联系我们发过来，我们先帮你判断卡在哪一段。方案范围见企业知识库，权限与执行边界可参考AI 智能体，要求数据不出内网的话看私有化部署；更多实操文章收在知识库栏目。