RAG 文档处理管线：别只调检索，先把文档喂对

很多 RAG 项目刚启动时，团队最容易把注意力放在向量数据库、Embedding 模型、重排模型和提示词上。

这些当然重要，但线上效果经常卡在更上游：文档还没进入索引，就已经被解析错、切碎错、清洗错了。

典型问题包括：

- PDF 双栏被按错误顺序读取，左栏结论接到了右栏论据后面。
- 表格被摊平成普通文本，列名和值的关系消失。
- Chunk 边界刚好切断条件和结论，模型只看到半句话。
- 页眉、页脚、目录、版权信息被当成正文入库。
- Metadata 没保存页码、章节路径、权限和版本，后续无法过滤、追溯和引用。

所以，RAG 的核心经验可以先记一句话：

检索决定下限，文档处理决定上限。

这篇文章从工程角度把文档处理管线拆开：解析、清洗、Chunking、Metadata、质量校验，以及图片、表格、图表这类多模态内容该怎么处理。

一、文档从上传到入库，要过哪些关

一份文档从上传到进入知识库，至少要经过这几步：

1. 文件上传与基础校验。
2. 格式识别与解析器选择。
3. Layout 解析，恢复标题、段落、表格、图片和阅读顺序。
4. 清洗去噪，移除乱码、重复页眉页脚、目录残留。
5. Chunking，把内容切成适合检索和生成的块。
6. Metadata 补全，记录来源、页码、章节路径、权限、版本。
7. 入库，把文本向量、结构化数据、原始文件引用写入存储。
8. 抽样质检，提前发现解析和切分问题。

每一层都有自己的坑：

很多项目一开始只做“解析后直接切块入库”，看起来链路很短，后续排查会非常痛苦。因为答案错的时候，你很难判断到底是解析错了、切分错了、检索错了，还是生成错了。

生产级 RAG 管线要做的第一件事，是把这些环节拆开，并让每一层都有可观测指标。

二、Chunking 没有万能参数，只有场景适配

Chunking 的目标不是“切得均匀”，而是在召回精度和上下文完整之间找平衡。

块太小，向量匹配会更精确，但模型拿到的上下文不完整；块太大，上下文更完整，但向量语义会变得模糊，召回噪声也会增加。

固定长度切分：适合做基线

固定长度切分最简单：每 512 或 1000 Token 切一块，相邻块之间保留一定重叠。

优点是实现简单、行为稳定、吞吐高。短 FAQ、简单帮助文档、内部知识条目，用它做第一版完全可以。

问题也明显：它不理解标题、段落、表格、代码块和业务条件。

比如一段退货规则：

除以下情况外，均可申请七天无理由退货：定制商品、鲜活易腐商品、在线下载的数字化商品除外。

如果边界切在“除以下情况外”后面，检索出来的 Chunk 可能只剩半句，模型就可能给出完全相反的答案。

固定长度适合作为 baseline，不适合作为所有场景的终点。

递归字符切分：技术文档的常用默认值

递归切分会按层级逐步尝试：先按标题，再按段落，再按句子，最后才按字符或 Token。

这更接近人读文档的方式，也更适合技术博客、产品手册、API 文档、研究报告。

常见做法是：

- Markdown 按 H1/H2/H3 切。
- HTML 按 h1-h6、p、div 等标签切。
- 普通长文本先按段落，再按句子。
- 代码按函数、类、模块边界切。

对于通用文本，可以从 400-800 Token 的目标块大小开始调；代码类文档不要硬套通用 Token 数，按函数和类边界更稳。

语义切分：效果依赖参数，不要盲目崇拜

语义切分会用 Embedding 计算句子之间的相似度，把语义相近的句子聚成一块。

它听起来很优雅，但工程上有两个问题：

- 需要额外 Embedding 调用，成本和耗时都会上升。
- 阈值和最小块大小很敏感，参数不合适时容易产生大量超小 Chunk。

实践里，语义切分最好加上 min_chunk_size 和 max_chunk_size 约束。否则一个 40 Token 的“语义完整片段”虽然看起来合理，但对 RAG 生成来说上下文远远不够。

按结构切分：不要拆散天然语义单元

有些文档本身就有强结构：法律条款、财务报告、论文章节、合同条款、产品手册页面。

这类文档不要急着按固定 Token 数硬切。页面、章节、条款、表格、代码块，往往就是作者已经设计好的语义边界。

推荐方式可以这样记：

Parent-Child Chunk：召回小块，生成大块

Parent-Child Chunk 是一个非常实用的折中方案。

做法是：小 Chunk 用于检索，大 Chunk 用于生成。

例如，把文档先切成 300 Token 的子块用于向量召回，同时把这些子块挂到 1200 Token 的父段落上。检索命中子块后，不只把子块塞给模型，而是把它对应的父段落一起带上。

这种方式尤其适合长教程、政策解读、操作手册、故障排查文档。

它的代价是索引和检索链路更复杂：每个子块要记录父块 ID，检索后还要多一次关联读取。但换来的收益很明确：召回保持精确，生成拥有上下文。

三、语义丢失：RAG 答非所问的隐形原因

语义丢失不是“文本少了一点”这么简单，而是原始文档里的依赖关系被处理管线拆散了。

常见有四种：

第一种是结构截断。一个完整业务规则被切到两个 Chunk 里，条件在上一块，结论在下一块，模型只看到一半。

第二种是上下文蒸发。Chunk 只保留正文，没有章节路径。模型看到“过去三年中”，却不知道它是在讲供应商风险、客户交易，还是设备故障率。

第三种是表格结构破坏。表头和值被摊平成一串文本，主键、从属字段、单位和备注都混在一起。

第四种是专有名词截断。比如“SSO 单点登录”被切成“SSO 单点...”和“登录配置...”，向量表示会变差，检索也更难命中。

应对语义丢失，可以从四个方向补：

- 保留层级 Metadata：章节路径、页码、父标题、段落编号都要写入 Chunk。
- 给 Chunk 生成摘要和问题变体：让“钱怎么退”和“退款申请路径”都能命中同一段。
- 控制边界：尽量在段落、条款、表格、代码块边界处切分。
- 对关键文档使用 Late Chunking 或 Contextual Chunking：先理解全文结构，再决定切分方式。

这里有一个低成本高收益的实践：每个 Chunk 至少保存 source_id、page、section_path、heading、chunk_index、permission_scope、version。这些字段不会让 Embedding 变强，但会让检索过滤、引用溯源和生成补上下文变得可控。

四、结构丢失：PDF、Word、Excel、扫描件各有各的坑

结构丢失是语义丢失的具体表现。不同格式的风险完全不同，不能用同一套“纯文本解析”解决。

PDF：重点是阅读顺序和版面区域

PDF 最麻烦的地方是“看起来有结构，底层未必有结构”。

双栏、多栏、页眉页脚、脚注、侧边栏、跨页表格，都可能让文本流顺序错乱。

处理 PDF 时，优先考虑 Layout-Aware Parser。它会结合文本坐标、字号、段落间距和版面区域，推断真实阅读顺序。

对于高价值文档，可以用两种解析器交叉解析，再比较输出差异。差异很大的页面不要直接入库，应该进入人工审核或备用解析流程。

Word：不要只读文字，要读样式

Word 的章节结构通常藏在样式里，比如 Heading 1、Heading 2、正文。

如果只把 Word 导成纯文本，标题层级会丢失。更稳的做法是用 python-docx 读取段落样式，重建文档树，再按标题层级切分。

但也要注意一个现实问题：很多 Word 文档的样式并不规范。有人用加粗大字号冒充标题，也有人整篇都套 Heading 1。工程上要允许“样式识别 + 规则修正 + 异常告警”一起工作。

Excel：表格不是文本，是结构化数据

Excel 不能简单按行拼接成文本。

数据表要按行抽成 JSON，配置表要保留字段和值的映射，混合文档要把说明文字和表格区域分开处理。

例如销售表，比起一句“手机 A 10000 12000 20%”，更好的表示是：

{
  "table_name": "季度销售数据",
  "headers": [
    "产品",
    "Q1销量",
    "Q2销量",
    "环比增长"
  ],
  "rows": [
    {
      "产品": "手机A",
      "Q1销量": 10000,
      "Q2销量": 12000,
      "环比增长": "20%"
    }
  ]
}

结构化表示更适合过滤、计算、聚合，也更容易生成准确答案。

扫描件：OCR 后必须校验

扫描件最怕三类错误：字符识别错、行列错位、段落合并。

数字 0 和字母 O、中文繁简体、产品编号、身份证号、金额小数点，都是高风险点。

关键扫描件不要只跑一次 OCR 就入库。可以使用双 OCR 引擎交叉校验，数值密集文档再加列求和、总计一致性等规则校验。

五、分层校验：没有质检的管线，不适合上生产

RAG 文档处理需要三层质量门禁。

第一层是格式校验，在上传后立即完成：

- 扩展名是否合法。
- MIME 类型是否匹配。
- 文件大小是否超限。
- 文件是否损坏或为空。
- 编码是否可识别。

第二层是解析校验，在解析后完成：

- 是否提取到正文。
- 正文长度是否异常。
- 乱码率是否过高。
- 标题、表格、图片数量是否合理。
- PDF 页数和解析页数是否一致。

第三层是 Chunking 校验，在切分后完成：

- Chunk 数量是否异常。
- 平均长度、最小长度、最大长度是否合理。
- 标准差是否过大。
- 是否存在明显半句话、半个表格、半段代码。
- 抽样 Chunk 是否能独立回答一个局部问题。

失败后不要只有“报错退出”一种动作。更实用的降级策略是：

降级不是降低质量要求，而是把风险显式化。最糟糕的情况不是解析失败，而是解析失败后系统假装成功。

六、多模态内容：图片、表格、图表不能直接跳过

真实企业文档很少只有纯文本。产品手册有截图，财报有表格，研究报告有图表，流程制度有泳道图。

如果这些内容不进入知识库，RAG 回答天然缺一块。

图片：先判断它是不是信息载体

图片可以分两类：

- 信息载体：截图、流程图、架构图、现场照片、仪表盘。
- 装饰内容：Logo、页眉、背景图、水印、二维码广告。

装饰内容应该清理掉；信息载体要抽取语义。

常见做法有三种：

1. CLIP 向量化图片，命中后回传原图。
2. 用多模态模型生成图片描述，把描述文本入索引。
3. 多向量检索：摘要入向量库，原图存在 docstore，检索命中后再取原图参与生成。

企业文档里大量图片其实是截图、流程图和仪表盘，CLIP 对这类内容不一定稳。更常用的方案是“多模态模型生成结构化描述 + 原图保留”。

表格：Markdown 化只是起点

表格至少要保留行列关系。Markdown 表格比纯文本强，但对数值计算和过滤还不够。

数值型表格更适合抽成 JSON 或写入结构化存储；查询时先做结构化计算，再把结果和表格上下文交给模型解释。

另外，表格描述最好带上上下文。不要只写“这是一个销售表”，而要写“华东区 2024 年 Q1/Q2 各产品销量及环比增长表，用于分析区域市场表现”。

图表：Caption 和上下一起存

图表要保留标题、坐标轴、图例、单位、数据来源和结论。

一个有用的 Caption 应该是这样的：

折线图展示 2020-2024 年季度营收趋势，Q4 2024 达到峰值 12.5 亿元，图表用于支撑“第四季度增长明显加速”的结论。

图表通常是为上下文论点服务的。只存图表本身不够，还要存它所在章节、前后段落和作者对图表的解释。

七、从零搭建时，按四步推进

如果要从零搭一套企业级 RAG 文档处理管线，不建议一上来就覆盖所有格式。

第一步，先把文本类文档跑通。Markdown、HTML、TXT 是最容易稳定的格式，用它们验证标题层级、Chunk 分布、Metadata 和入库流程。

第二步，再攻坚 PDF。选 10-20 份真实样本文档，覆盖多栏、表格、扫描件、图文混排，验证 Layout 解析和表格抽取质量。

第三步，引入多模态处理。优先处理信息密度高的图片、表格、图表，而不是把所有图片一股脑向量化。

第四步，做质量闭环。拿真实用户 Query 定期回放，观察召回结果是否来自正确页面、正确章节、正确表格。解析器、切分策略、Metadata 和重排规则都要跟着这个闭环迭代。

结尾：先把知识库的原料处理好

RAG 不是把文件丢进向量库就结束了。它更像一条数据生产线，每个环节都在决定后续答案质量。

真正稳定的 RAG 系统，通常会同时做好五件事：

- 解析层理解版面结构，而不是只抽纯文本。
- 清洗层去掉噪声，但不误删业务信息。
- Chunking 层按场景选择策略，保留语义边界。
- Metadata 层保存来源、页码、权限、版本和章节路径。
- 多模态层让图片、表格、图表以可检索的方式进入系统。

不要指望换一个更贵的 Embedding 模型，就能修好被切碎、读错、污染的数据。

把文档处理做好，RAG 才真的有资格谈检索和生成。