RAG 文档处理与切分策略：从解析、清洗、Chunking 到多模态内容处理

文档处理是 RAG 链路里投入产出比最高的一段：解析丢掉的结构、切分切断的语义，后续换再好的 Embedding 模型和向量库也救不回来。本文按入库前的完整顺序讲清解析、版面分析、切分、多模态处理与清洗质检的做法和取舍。

为什么解析是第一道坎

RAG 的效果上限在文档进索引之前就已定下来：Embedding 只能编码你喂给它的文本，喂进去的是错序、残缺、带噪声的内容，向量检索找回来的也只能是垃圾。以企业知识库里占比最高的 PDF 为例，至少有四类坑：

表格解析：普通文本提取会把表格拍平成一行行文字，行列对应关系、合并单元格归属全部丢失，模型看到的”数字”根本不知道属于哪一列。
双栏/多栏排版：PDF 底层按文本对象的写入顺序存储，不等于视觉阅读顺序，直接顺序提取会把左栏结尾拼到右栏开头。
扫描件 OCR：数字 0 和字母 O、繁简体混淆这类误识别，对编号、身份证号等关键字段是致命的；表格线识别偏移还会导致行列错位。
页眉页脚与目录残留：每页重复的公司名、页码会被当成正文切块，稀释向量质量。

Word 和 Excel 也并非坦途：标题样式经常被滥用（加大字体的普通段落冒充标题），Excel 的字段关系可能靠合并单元格和颜色表达，只信样式名或只读单元格都会拿到残缺结构。

版面分析：还原阅读顺序

对付复杂版式需要版面分析（Layout Analysis）：解析器结合文本块的坐标、字号、间距，先识别哪些是标题、正文、表格、图片，再推断阅读顺序，LlamaParse、Docling、Marker 都是这个思路。工程上两个动作值得做：高价值文档用两个解析器各跑一遍，差异大的页面进人工审核（两者一致也不等于正确，仍要抽查）；扫描件链路默认 OCR 会出错，对金额、编号等关键字段做校验或双引擎交叉验证，低置信度内容打标签而不是默默入库。

切分策略：四种主流做法怎么选

固定长度 + 滑动窗口

按字符或 Token 数硬切，相邻块保留 10%–20% 的重叠（Overlap）。实现最简单、行为可预测，适合作评测基线。硬伤是完全不懂语义边界：一段”除以下情况外均可七天无理由退货：（一）……（二）……”恰好在边界处断开时，前后两块各自都不完整，模型很容易断章取义。重叠能缓解边界截断，但过大会浪费向量空间并引入重复噪声。

递归字符与按结构切分

递归切分按优先级分隔符逐层尝试：先保段落，仍超长再按句子切，最后才退到更细的边界——在控制块大小的同时尽量保住语义单元，是通用文本的稳妥起点。对结构明确的文档（Markdown、HTML、代码），更好的做法是直接按标题层级、标签层级、函数/类边界切，并把章节路径写进元数据。

语义切分

先算相邻句子或段落的 Embedding 相似度，在语义突变处下刀，同一块内主题连贯。代价是每句话都要过一次嵌入模型，成本高；没有最小块约束时，话题转折处可能切出一两个句子的小块，命中后撑不起回答。通用文本可从 200–400 Token 区间起步调参。

父子块（Parent-Child）

检索要小块（匹配精度高），生成要大块（上下文完整），父子块把两个目标拆开：约 300 Token 的子块进向量索引负责被命中，命中后取回所属的约 1200 Token 父段落喂给模型。长文档、政策解读、故障手册场景收益明显，代价是索引多存一份父子关联、检索多一次回表。

表格与图片：多模态内容怎么办

表格：结构化抽取是核心

表格不能当纯文本处理。可行路径有两条：

转 Markdown 表格：用 Docling、TableFormer 这类专用工具提取结构，Markdown 至少保留行列关系，LLM 能读懂”哪列对哪行”。
转结构化 JSON：财务报表等数值型表格转成带 headers 和 rows 的 JSON，便于数值检索和计算类查询。

无论哪条路径，都要为表格补一段描述文本，写清所在章节、主题、单位和时间范围——否则检索端分不清两张同名”销量汇总表”分别属于哪个业务域。图表同理，要保留 Caption、坐标轴、单位和数据来源，缺了这些限定条件，同一组数值会被解释错。

图片：区分信息载体与装饰

页眉 logo、水印这类装饰性图片应直接丢弃；流程图、架构图、截图这类信息载体有两条处理路径：

CLIP 向量化：用图文对齐模型把图片编码进向量空间，命中后回传原图给多模态 LLM。对自然图片效果好，对密集文字的截图需单独评测。
MLLM 生成描述：把图片内容写成文字描述进文本索引，原图存对象存储；命中描述后按 doc_id 取回原图参与生成。这是”摘要用于检索，原文用于生成”的多向量检索思路，对截图和流程图通常比 CLIP 保留更多细节，但描述可能漏字段或读错数值，需抽样评测。

清洗与去重：质检流水线

生产级管线必须有分层校验，而不是解析完直接入库：

格式校验（大小/MIME/编码）
  → 解析校验（空内容、乱码率、长度异常）
    → 切分校验（块大小分布、边界截断抽检）
      → 入库（向量 + 原文 + 元数据）

格式校验拦截成本最低：扩展名与实际 MIME 不符、超大文件、编码混乱，直接拒绝或转人工。
解析校验看内容质量：结果为空、乱码率超阈值（比如 5%）、长度异常，都说明解析出了问题；乱码率高的可尝试 OCR 或换解析器，仍失败就降级为纯文本并打标签。
切分校验抽查块大小分布：标准差过大说明切分不均，大量小块可能是切分异常，超大块可能撑爆模型上下文。

校验失败的处理原则是”保留可确认正确的内容，而不是悄悄吞掉失败页”：100 页文档有 10 页解析失败，业务允许时可只索引其余 90 页，但必须记录缺页范围、阻断对缺失部分作完整性承诺；合同、法规这类要求完整性的材料应暂缓发布。

去重基于内容哈希：入库前算正文或 Chunk 的 SHA-256 与已有记录比对，未变化则跳过 Embedding；SimHash 适合”大致相同”的近似去重（如转载文章），但不能精确定位差异点。元数据至少带 source_id、page、section_path、acl、updated_at，否则无法过滤与引用溯源。

切分策略对比

策略	优点	缺点	适用场景
固定长度 + 重叠	实现简单、行为可预测	无视语义边界，易截断	基线评测、短文档、FAQ
递归字符	保段落/句子边界，通用性强	仍需调块大小参数	通用文本起步方案
按结构切	边界天然清晰，层级可入元数据	依赖解析质量	Markdown/HTML/代码/论文
语义切分	块内主题最连贯	计算贵，可能切出过小块	高精度要求且预算充足
父子块	检索精度与生成上下文兼得	存储与关联查询开销	长文档、教程、政策解读

块大小没有通用最优值：事实型查询偏小块（256–512 Token），分析型查询偏大块（1024+）。所有参数都应在自有业务评测集上调出来，别人知识库上的结论不能直接搬。

面试视角

文档处理为什么是 RAG 最值得投入的环节？ 它是链路上限的制定者：解析错序、切分截断、元数据缺失在入库后不可逆，检索与生成端的优化只能逼近这个上限。同样的 Embedding 与模型，换套切分策略往往就是最大幅度的召回提升，成本远低于换模型。

PDF 双栏文档解析出来是乱的，怎么办？ 根因是文本对象存储顺序不等于阅读顺序。换 Layout-Aware Parser 用坐标和版面特征推断阅读顺序；高价值文档双解析器对比加人工审核，扫描件走 OCR 并设关键字段校验。

切分策略怎么选？ 先用固定长度建立基线，再按文档类型对比递归、按结构切分的召回收益；长文档考虑父子块，高精度场景评估语义切分。依据是同一评测集上的 Recall@k 与答案忠实度，而非经验参数。

表格进 RAG 怎么处理？ 专用工具抽取结构后转 Markdown 或 JSON，补带章节、单位、时间范围的描述文本；合并单元格、跨页表格是重点坑位，需专项验证。

小结

解析是 RAG 的第一道坎：表格、双栏、OCR 错误一旦入库就无法被下游补救；版面分析用坐标与样式还原阅读顺序。
切分没有银弹：固定长度做基线，递归与按结构切是通用起点，父子块兼顾检索与生成，语义切分换精度要付成本。
表格走结构化抽取，图片区分装饰与信息载体，多模态推荐”描述进索引、原文进存储”的多向量方案。
格式、解析、切分三层校验加内容哈希去重，是防止脏数据污染索引的底线工程。