第三章：文档解析与预处理

3.1 为什么这是 RAG 最被低估的一环

大多数人讲 RAG 时会从切分讲起，但真实项目里，最先卡住的往往是更前面一步：把原始文档变成干净的文本。

原因很简单：企业的知识不是以 Markdown 存在的。它是扫描版的合同 PDF、带合并单元格的 Excel、有页眉页脚和分栏的 Word、嵌了流程图的 PPT、以及内网 Wiki 里格式混乱的 HTML。

这一层出错，后面所有环节都是在垃圾数据上做优化。 切分策略再精妙、Embedding 模型再强、Rerank 再准，也救不回一张被解析成乱码的表格。

这是「RAG 落地三大难」中公认最脏最累的一难。

3.2 解析阶段的四类典型问题

flowchart TB
    DOC[原始文档] --> P1[版面问题]
    DOC --> P2[表格问题]
    DOC --> P3[非文本内容]
    DOC --> P4[噪音与结构丢失]

    P1 --> A1[分栏被按行读串
阅读顺序错乱]
    P2 --> A2[合并单元格塌陷
行列关系丢失]
    P3 --> A3[扫描件 图表 公式
无法直接取文本]
    P4 --> A4[页眉页脚重复
标题层级丢失]

3.2.1 版面与阅读顺序

PDF 本质上是绘图指令的集合，它记录的是「某个字符画在页面的哪个坐标」，而不是「这段文字属于哪个段落」。

所以双栏排版的论文，用简单的文本抽取工具处理时，很容易把左右两栏按视觉行拼接起来，产出彻底错乱的句子。

3.2.2 表格

表格是解析里最难的一类，因为它的信息同时编码在内容和位置关系里。

一个被拉平成纯文本的表格，会丢掉「这个数字属于哪一行哪一列」这个最关键的信息。合并单元格、跨页表格、无边框表格会让情况进一步恶化。

3.2.3 扫描件与图片

纯图片 PDF 里没有任何文本层，必须走 OCR。而 OCR 会引入一类特殊的错误：它产出的文本看起来是正常文字，但字符是错的（比如把 0 认成 O）。这类错误比「解析失败」更危险，因为它不会报错，会静默污染知识库。

3.2.4 噪音与结构丢失

每页重复的页眉页脚、水印、页码，会在切分后混进每一个片段里稀释语义。而标题层级一旦丢失，就无法做后续的结构化切分——这是最可惜的一类损失，因为原文档里本来是有这个信息的。

3.3 解析路线的三种选择

实践建议是分层处理，而不是全用最贵的那条路：

flowchart LR
    IN[文档] --> T1[规则解析]
    T1 --> CK{质量检查}
    CK -->|通过| OK[入库]
    CK -->|失败| T2[版面模型]
    T2 --> CK2{质量检查}
    CK2 -->|通过| OK
    CK2 -->|失败| T3[多模态模型]
    T3 --> OK

这样绝大多数简单文档走最便宜的路径，只有难啃的部分才升级到昂贵方案。

3.3.1 用大模型解析的额外风险

用 VLM 解析文档是 2025 年之后快速普及的做法，但它有一个规则方法没有的风险：它可能生成并不存在的内容。

规则解析失败时会报错或返回空，而 VLM 解析失败时会输出一段看起来很合理的内容。表格数字识别不清时，它可能补出一个「合理」的数字。

所以用 VLM 解析必须配套：

• 让它只做转录不做总结，在提示里明确禁止推断和补全；
• 对数值密集的表格做抽样人工校验；
• 保留原始页面图像的引用，便于事后追溯核对。

3.4 表格的特殊处理

表格不应该被当作普通文本对待。常见的三种处理方式：

第三种在大表格上尤其重要：一张几百行的表切碎后，任何单个片段都无法回答关于它的问题，而整张表又可能太大。用摘要做检索入口、命中后再取全表，是更稳的做法。

跨大量表格做聚合统计的问题（「所有合同的平均金额」），RAG 本身并不适合，应该走结构化抽取 + 数据库查询的路线（见第一章 1.7 节的能力边界）。

3.5 一条绕开解析的新路线：视觉文档检索

近年出现的一类方法是直接把文档页面当作图像来做嵌入和检索，完全跳过 OCR 和版面分析。检索时把 Query 和页面图像在同一空间里比对，命中后把页面图像直接交给多模态模型阅读。

它的价值在于：版面复杂、图表密集的文档上，传统「OCR + 文本嵌入」管线丢失的信息（图表、排版关系、视觉强调），在图像里天然保留了。 公开评测显示这类方法在视觉丰富的文档上优于传统管线。

它目前的局限包括：

• 页面级图像嵌入的存储开销远大于文本向量；
• 检索和生成都依赖多模态模型，GPU 成本高；
• 与现有文本检索链路的混合方案尚未定型；
• 是否进入主链路取决于语料的视觉信息密度、成本、延迟、可引用性和业务评测；不能脱离这些条件判断它是否应取代 OCR 管线。

完整的视觉、表格、音视频联合索引、跨模态检索、引用和安全链路见 多模态 RAG。

3.6 清洗阶段该做什么

解析出文本后，还需要一轮清洗：

• 去重复元素：页眉、页脚、水印、页码、导航栏——判断方法是「在多页中重复出现且位置固定」；
• 保留结构信号：把标题层级转成 Markdown 的 # 层级，这是后续结构化切分的依据；
• 规范化空白与编码：全角半角、连续空行、断行连字符；
• 保留元数据：文件名、章节路径、页码、更新时间、权限标签。

3.6.1 元数据是最容易被跳过、后期最难补的

元数据在建库时几乎不花成本，但它决定了三件后期很难补救的事：

权限标签尤其要在建库时就写进去。等系统上线后再补，意味着全量重建索引——而这在很多组织里就等于「做不了」。

3.7 入库前质量校验

预处理完成后，需要在入库前建立几条自动检查：

• 空白率：解析出的文本长度与文件大小的比值异常低，说明可能解析失败；
• 乱码率：非常见字符占比过高，说明编码或 OCR 有问题；
• 表格完整性：识别出的表格行列数是否与原文一致（抽样）；
• 重复率：同一段文本在库中出现次数异常高，说明页眉页脚没清干净；
• 人工抽样：每类文档抽几份逐页对照——这一步无法被自动化完全替代。

一条实用经验：与其花两周调 Rerank，不如花两天看看你的知识库里到底存了什么。 很多「检索效果差」的问题，根源在解析阶段。

3.8 常见错误

3.8.1 直接用最简单的工具处理所有格式

不同格式、不同版面复杂度应该走不同路径。一刀切必然在某一类文档上大面积失败。

3.8.2 不做质量校验就入库

解析失败往往是静默的。没有校验，你会在几周后从「检索效果差」这个模糊症状反推回来。

3.8.3 把表格当普通文本拉平

丢掉行列关系后，表格数据基本失去检索价值。

3.8.4 不保留元数据

后期补元数据意味着全量重建。尤其是权限标签。

3.8.5 认为用了大模型解析就万无一失

VLM 会静默编造内容，风险模式与规则解析完全不同，需要额外的校验手段。

3.8.6 把预处理当一次性工作

文档会更新、会新增格式。预处理链路需要能持续运行和监控，而不是跑一次就完事（详见第十九章）。

3.9 本章总结

1. 预处理是 RAG 最脏最累也最容易被低估的一环，这一层的错误无法被后续任何优化弥补；
2. 四类典型问题：版面阅读顺序、表格结构、扫描件与图片、噪音与结构丢失；
3. 三条解析路线（规则 / 版面模型 / 多模态模型）应该分层组合，按质量检查逐级升级，而不是全用最贵的；
4. 用 VLM 解析要防它编：限定只转录不推断，对数值做抽样校验；
5. 表格要特殊处理：保留结构、行级展开或摘要挂载；跨表聚合应走结构化路线；
6. 视觉文档检索是绕开解析的新路线，在视觉复杂文档上有效，但存储和算力成本高，尚未成为主流生产方案；
7. 元数据必须在建库时写入，尤其是权限标签，事后补等于全量重建；
8. 必须做入库前质量校验，包括自动指标和人工抽样。

参考资料

• ColPali: Efficient Document Retrieval with Vision Language Models
• Advanced ingestion process powered by LLM parsing for RAG system
• Searching for Best Practices in Retrieval-Augmented Generation
• Retrieval-Augmented Generation for Large Language Models: A Survey