01｜RAG 效果不好，为什么可能从文档解析就已经注定？

很多团队第一次优化 RAG，会从模型开始。

召回不准，就换 Embedding；答案不稳，就加 Reranker；仍然不行，再换一个更大的生成模型。

这些调整当然可能有效。但还有一种更早发生、也更容易被忽略的错误：知识在进入向量数据库之前，就已经变形了。

原文里清清楚楚的标题层级，解析后变成连续正文；一张价格表被读成十几行互不相干的数字；每页重复的页眉混进内容；脚注跑到另一段后面；图片里的流程完全消失。

此时检索系统面对的，并不是那份原始文档，而是一份残缺的“转述”。

文件能打开，不等于知识已经进入系统

一份文件进入 RAG，至少要经过三层变化。

第一层是读取文件。系统能识别 PDF、Word 或网页，没有损坏，也没有密码阻挡。

第二层是抽取内容。页面上的文字、图片和表格被取出来，变成程序可以处理的数据。

第三层才是恢复文档。系统知道哪一行是标题，哪几段属于同一节，表格中哪个数字对应哪个产品，脚注解释的是哪句话，以及这些内容位于原文哪里。

很多“解析成功”的日志，只证明了前两层。它能告诉你抽出了三万字，却没有告诉你这三万字之间的关系还剩多少。

就像搬家时把所有家具都运到了新房，但拆掉了柜门、抽屉和标签。东西没有少，却已经很难使用。

一次解析错误，会怎样走完整条链路？

假设原文中有这样一节：

退款规则<br>企业版：合同生效后 30 天内可申请。<br>个人版：购买后 7 天内可申请。

如果解析器丢掉了标题，又把两行产品名称与期限错开，切分器拿到的可能只剩：

合同生效后 30 天内可申请。购买后 7 天内可申请。

接下来会发生四件事。

切分阶段不知道这段属于“退款规则”；向量化阶段只能编码残缺语义；检索阶段即使找到了它，也无法判断两个期限分别属于谁；生成阶段为了回答得通顺，很可能自行补上对应关系。

最后用户看到的是一个“模型答错了”的案例。但错误真正发生的时间，是文档刚进系统的时候。

解析质量决定了检索的上限

RAG 可以理解成一场开卷考试。

生成模型是答题的人，检索系统负责翻书，解析系统则负责在考试前印教材。

如果教材的目录、表格和页码都印乱了，翻书的人很难找到完整证据；即使偶然翻到了，答题的人也无法确认上下文。

这就是解析对 RAG 的特殊影响：它不一定直接制造一个显眼报错，却会同时降低三个上限。

• 可发现性：正确内容能否被问题召回。

• 可理解性：召回后，内容之间的关系是否仍然清楚。

• 可追溯性：答案能否回到原文的章节、页码或区域。

一个只保留正文字符串的系统，也许能完成演示；一个要处理制度、合同、研报和技术手册的系统，迟早会撞上这三个上限。

先别急着换模型，做一次“逆向检查”

当 RAG 答错一个有明确答案的问题，可以从答案沿链路往回查。

第一步，看最终提供给模型的上下文里有没有正确证据。

如果没有，再看检索候选中有没有；如果候选中也没有，再查向量库里的 chunk；如果 chunk 已经残缺，就回到解析产物与原文件逐项比较。

这套检查能把“效果不好”拆成更具体的问题：

原文中根本没有答案；

解析时答案丢了或关系错了；

切分时答案与必要上下文分开了；

检索没有找到正确块；

模型拿到证据后仍然理解错了。

只有第 4 类主要由检索策略负责，第 5 类才主要落在生成模型身上。

文档解析真正要交付什么？

好的解析结果，不只是一个很长的 text 字段。

它至少要回答：这段内容是什么类型？属于哪一章？前后是谁？来自哪一页、哪个区域？是否由 OCR 得到？有没有解析警告？能否回到原始文件核对？

这并不意味着所有项目一开始都要搭建最复杂的系统。它只意味着团队要明确：自己保留了什么，又主动放弃了什么。

如果知识库只有格式规整的 Markdown，简单解析可能已经足够；如果文档以扫描合同、双栏论文和复杂报表为主，仍然把“抽到文字”当作完成，风险就会被推迟到用户提问时爆发。

RAG 的第一公里，不是选择向量数据库，而是先让机器看到一份接近人所看到的文档。

下一篇，我们从最常见也最容易误解的文件开始：PDF 看起来像一张页面，为什么程序却未必知道哪句话应该先读？

系列说明：本文讨论的是解析如何限制 RAG 上限，并不意味着所有回答错误都来自解析。正式排查仍应分别检查知识、解析、切分、检索和生成五个环节。