RAG 知识库问答效果不稳，多数情况下不是大模型能力不够，而是知识库上游的资料处理链路出了问题。文档没有在读取、切分、Embedding 三个环节被处理好，后续向量检索自然漏检、错配，模型只能基于错误片段回答。IT 主管应先把排查重心放在资料入库前的处理质量，而不是急着换模型或调 Prompt。
RAG 检索效果差的根因，为什么在资料处理链路
企业知识库问答出现“答案飘”“漏检”“引用错文档”，团队的第一反应往往是换更强的模型或加长上下文窗口。但一个基本事实是：检索增强生成的效果取决于“检索到了什么”，而不是“模型有多强”。如果检索环节返回的片段本来就不对，生成环节没有任何补救空间。
资料处理链路可以拆成三个连续环节：
- 读取：PDF、Word、Excel、扫描件、HTML 等格式能否被完整、准确地解析成可用文本
- 切分：长文档被切成多大的片段、按什么边界切、是否保留标题和章节结构
- Embedding：文本片段转成向量时，使用的模型是否适配企业文档的语言和领域特征
这三个环节任何一处出问题，错误都会向下游累积。上游丢掉的表格结构、被截断的条款、混在一起的章节标题，到了向量库里就是不可辨别的噪声。
什么情况下应该先查资料处理链路
如果你的项目同时出现以下两种以上现象，基本可以判断问题不在模型：
- 同一个问题，模型换了几版，答案仍然不准
- 明明文档里有标准答案，但系统说找不到
- 回答里夹杂大量无关上下文，真正有用的句子被冲掉
- 对表格、合同条款、操作手册类内容的回答尤其差
- 短文档问答尚可，长文档几乎不可用
这些现象的共同点，是检索环节拿不到高质量片段。模型只能基于被送进去的内容作答，检索质量不提升，模型能力再强也无从发挥。
IT 主管应优先排查的三个环节
文档读取阶段：先确认“读进来的是什么”
企业知识库的原始资料形态通常比想象中复杂。PDF 可能是扫描件、Word 里混着表格和图片、Markdown 里嵌着代码块、旧系统导出的文件带着大量乱码和页眉页脚。
读取环节最容易出问题的地方在于：文件表面能打开，不代表内容被正确提取。扫描版 PDF 如果没有 OCR，提取出来的就是空文本；带复杂表格的文档，读进来后列和行可能完全错位；复制粘贴过来的内容，可能混入大量不可见字符。
排查做法是先从知识库里抽取几篇典型文档，人工对比原文与读取结果，确认文本完整、表格结构无错乱、没有大段乱码。这一关不过，后面所有优化都没有意义。
切分阶段：别再用默认参数一刀切
切分是 RAG 项目中最容易被低估的环节。很多项目直接使用框架默认的固定长度切分，比如每 500 字切一段。这种方式对叙述性文档勉强可用，但对制度文件、合同条款、FAQ、操作手册等结构化内容，几乎必然出问题。
常见的切分误区包括：
- 把一个问题和一个答案切开，导致检索只能命中半截
- 把表格按行切断，列对应关系完全丢失
- 把带层级编号的条款切散，不知道这段属于哪一章哪一条
- 切分粒度过小，检索到的片段缺少上下文
- 切分粒度过大，导致无关内容一起被塞进 Prompt
合理的做法是按文档类型设计切分策略。FAQ 类文档可以按问答对切分；制度类文档优先保留章节层级；合同类文档需要以条款为基本单位；表格密集的文档则需要考虑将表格转换为结构化文本后再处理。
Embedding 阶段：通用模型不是万能模型
Embedding 模型的选择直接影响检索命中率。通用模型对日常语言有不错的覆盖，但企业知识库往往包含大量行业术语、产品型号、内部缩写、制度表述。
如果业务语料中频繁出现“PO 单”“客诉等级 B2”“风控规则 R-07”这类表达，通用 Embedding 模型很可能无法理解其语义。结果就是，用户用业务语言提问时，系统找不到对应的知识片段，即使这些片段在知识库里清清楚楚地存在。
这个环节的排查方式是做一个简单的检索测试集：选取 20 到 30 个真实业务问题，人工标注知识库中的正确答案所在片段，然后检查系统能否在检索结果中命中。如果命中率低，优先考虑更换或微调 Embedding 模型，而不是去调整大模型。
给 IT 主管的链路检查清单
当知识库问答效果不达预期时，建议按以下顺序排查：
- 从知识库中抽取 10 篇覆盖主要类型的文档，核对读取结果是否完整准确
- 检查切分后的片段，确认没有语义单元被切断、表格结构完整、层级信息保留
- 用 20 个已知答案的业务问题做检索测试，统计答案片段的命中情况
- 对比命中失败和成功的案例，定位是切分策略问题还是 Embedding 匹配问题
- 针对问题文档类型，单独调整读取或切分方案后重新入库，再做对比测试
这个链路跑完，大部分效果不稳定的问题都能被定位到具体环节。剩下的小部分，才轮到考虑 Prompt 优化或模型调整。
这类排查适合由谁来做
这个工作不是单纯的算法任务，也不是业务部门能独立完成的。它需要有人同时理解文档结构、检索机制和业务场景。实际操作中，通常是由信息化负责人牵头，协调业务部门确认知识片段的“正确切法”，再由技术团队执行调整和测试。
如果企业内部没有同时对 RAG 链路和业务文档都熟悉的角色，这个过程容易反复试错。智未来 AI 在企业知识库项目中的做法，是从业务文档结构出发，先建立分类型的处理规则，再用测试集验证效果，而不是拿着默认 Pipeline 直接上线。智未来（上海）智能科技有限公司在交付知识库项目时，会把读取策略、切分规则和检索测试方法一并交付给客户团队，确保后续文档更新时，IT 部门能自己维持链路质量。
关于企业知识库与 RAG 系统的完整建设逻辑，可以进一步了解企业知识库与 RAG 系统的交付范围。如果项目还涉及让外部 AI 搜索更准确理解企业内容，则与 GEO 与 AI 搜索优化有衔接关系。
常见问题
问：RAG 知识库问答效果不好，第一步到底应该查什么？
先查文档读取质量。从知识库里抽取几篇典型文档，人工对比原文和系统读取结果，确认没有乱码、表格错位和内容缺失。如果读取环节就出问题，后面的切分、Embedding 和模型再调都没用。
问：切分用默认参数不行吗？为什么总是要单独调？
不行。默认固定长度切分只适合叙述性文本。企业知识库里的制度、合同、FAQ、操作手册都有各自的结构，一刀切会把语义单元切断。按文档类型分别设计切分规则，是提升检索命中率成本最低的一步。
问：怎么判断是 Embedding 模型不合适，而不是大模型不行？
做一个检索命中测试。用 20 个已经知道答案的业务问题，检查系统检索出来的片段里有没有包含正确答案。如果大量问题检索阶段就漏了，说明是 Embedding 或切分的问题，和后面的大模型生成能力无关。
问：企业没有专门的 AI 工程师，这类排查能自己完成吗？
部分可以。文档读取核对和切分规则设计，业务人员和信息化负责人配合就能完成初步判断。但 Embedding 测试和调整需要一定的技术能力。如果内部资源不足，选择有知识库交付经验的团队配合做一次链路诊断，比直接换模型更实际。
问：优化完资料处理链路后，效果能提升多少？
这取决于原有链路的基线水平。如果原来使用默认切分和通用 Embedding，优化到分类型切分加业务适配的 Embedding 后，检索命中率的提升通常可以直接在测试集上量化观察到。但具体数值需要在项目内用测试集验证，不能事先承诺。
问：现在很多厂商说换个大模型就能解决 RAG 效果问题，是真的吗？
大模型能力只影响生成环节。如果检索出来的片段本身就不包含正确答案，换更强的模型只会让它在错误的上下文里更自信地给出看似合理的答案。先确认检索链路没问题，再考虑模型层面的调整，才是成本最低的顺序。