文档解析与摄取质量

深入解析 · 检索与 RAG

文档解析与摄取质量：上游瓶颈，绝大多数团队都低估它。

几乎每一次"RAG 不工作"的排查都会落到同一结论：检索器吐出的切块技术上没错，语义上却是坏的——一张表被压成逗号分隔的数字墙、一个标题与其正文脱节、一个页脚渗进每一个切块、一份分栏 PDF 把第二栏读成了第一栏的延续。重排序、改写或换模型都无法修复在建索引之前就被毁掉的文本。本条目把摄取当作一等工程问题：解析究竟要做什么、在哪里崩溃，以及"干脆跳过文本抽取"这条现代捷径。

STEP 1

为什么摄取质量通常是瓶颈。

什么是 RAG 中"分两半调试 RAG"的检索-生成切分是对的，但不完整。在检索之前还有上游的第三半，它决定正确答案是否曾可被索引：

source documents
       |
       v
[0 PARSE & EXTRACT]   PDFs, HTML, Word, slides, images
                      -->  clean text + structure
       |
       v
[1 CHUNK]             split along semantic boundaries
       |
       v
[2 EMBED & INDEX]     dense + sparse vectors
       |
       v
[3 RETRIEVE]   [4 GENERATE]   (the rest of the pipeline)

大多数团队仔细地为第 3、4 阶段加埋点，却把第 0 阶段当作"我们用了个 PDF 库"。然后花数月时间怪嵌入模型。能揭穿这一点的诊断：取十个失败用例，找出包含答案的源文档，在索引里看那段对应的切块。如果切块不可读——表格被压平、标题塞进正文、栏顺序错乱——下游任何阶段都救不回来。摄取就是失败所在。

这项检查耗时十分钟，却会改变大多数团队的路线图。打开你语料中失败率最高的那份文档，把它的切块倒进一个文本文件并通读。如果你都分不清表格在哪结束、正文在哪开始，模型也分不清。

STEP 2

PDF 不是文本。它是一种靠猜测抽取的视觉格式。

PDF 存的是被定位的字形——"在 (x=72, y=540) 处用 Helvetica-Bold 11pt 画字符 ‘A’"——没有任何关于段落、表格、列的语义概念。每个 PDF 文本抽取器都通过按位置聚类字形、猜测行/段/表的起止来重建阅读顺序。这些猜测会以可预测的方式失败：

多栏布局。朴素的自上而下抽取器会跨栏阅读而非顺栏阅读，把"第一栏第 1 行、第二栏第 1 行、第一栏第 2 行、…"拼成胡言乱语。
表格。单元格变成无行/列结构的数值流。一张 10 行 4 列的费率表变成一行 40 个数字。任何关于"B 计划第 3 年的费率"的问题现在都从切块里答不出来，因为让它可答的结构没了。
页眉、页脚、页码、水印。每页重复，因此会以套话噪声出现在每个切块里，在嵌入时压住信号，并撑大索引。同一个段落在同一个免责声明页脚下出现 200 次也会污染 BM25 统计。
脚注与边栏。因位置上相邻而被拼进句子中间。
图与公式。要么被整体丢弃，要么以字形位置的混乱 OCR 形式出现。

存在两层解析器。纯文本抽取器（pdfminer、pypdf、PyMuPDF）快速、对结构良好的原生数字文本够用。布局感知解析器（Unstructured、LlamaParse、Reducto、Azure Document Intelligence、Marker、Docling）先跑一个布局模型——把栏、表、页眉、列表识别为结构元素——再在每个区域内抽取。它们更慢（常以 LLM 为后端）、不免费，但对任何非平凡语料都是唯一正确答案。

STEP 3

表格与其它结构化内容需要专门处理。

一张丢了结构的表格比没有表格更糟，因为模型会自信地误读它。按能力与成本递增的三种可行策略：

序列化为 Markdown 或 HTML 表格。布局感知解析器重建网格并发出保留行、列与表头的表格。把这段 Markdown 文本嵌入，能给生成阶段足够结构来跨行阅读。便宜，且通常够用。
以行为切块、附带列名上下文。把每一行作为单独切块索引，前缀其列名与表标题。这能为"在 Y 列查找 X"类查询提升召回，否则它们会与周围正文争夺嵌入相似度。
用 LLM 把表格转成文字。在摄取时让 LLM 把每张表抄写成一段叙述（"A 计划第 1 年月费 20 美元、第 2 年 25 美元 …"），并同时索引原表与文字摘要。摄取昂贵，但查询时检索变得轻而易举。当表格本身就是答案承载内容时（财报、费率表、检验单），值。

同样的逻辑适用于其它结构化内容：公式应保留为 LaTeX 或规范化文本而非字形糊汤，代码块应保留为代码（不要被当作散文重排），列表应保留项目符号而不应被压平为流水文。每一项都是检索器与生成器都能用到的结构信号。

STEP 4

OCR 是独立流水线，而现代 OCR 多半就是一个视觉 LLM。

扫描文档、拍摄的合同、截图、纯图像 PDF 在上述任何处理之前需要 OCR。2026 年 OCR 的诚实小结：

经典 OCR（Tesseract、AWS Textract、Google Document AI）快、确定性强，对干净的印刷文本够用。它产出的是带包围框的单词流；之上的布局重建仍是独立问题。
端到端 OCR Transformer（Donut、Pix2Struct，以及面向科学文档的较新 Nougat）跳过包围框阶段，直接从页面图像产出结构化文本。在复杂布局与表格上更好；更慢；对分布外文档类型脆弱。
视觉 LLM 整页理解——把页面图像送入多模态模型（Claude、GPT-4o、Gemini）并请求结构化 Markdown。到 2025–2026 年，在杂乱文档上其质量已与专用解析器相当，且更易运维（无需另外微调一套模型）。代价是每页推理成本与生成式输出的常规非确定性。

选择由体量与文档多样性决定。一天百万张扫描发票 → 经典 OCR 加布局模型。一周一百份格式不一的合同 → 计入边界情况节省的工程时间后，视觉 LLM 大概率更好也更便宜。

STEP 5

分块是解析决策，不是分词器决策。

默认的"每 500 令牌切一刀、50 令牌重叠"是分词器驱动的启发式，无视结构。它会乐意把一个 600 令牌的小节切成两半、把表与其标题分开、把一个标题与其下方不相关段落合并。分块质量在解析质量的下游，修复办法是沿解析器已识别出的结构边界切分：

标题感知分块。把每个 H1/H2/H3 小节视为一个单元；仅在超出令牌预算时进一步切分。给每个切块前缀其父标题面包屑（手册 > 计费 > 退款政策），让切块自带上下文。
元素感知分块。绝不跨切块切表。绝不切代码块。让图说与其图保持在一起。这些都是廉价规则，能阻止最糟糕的失败。
语义分块——用连续句子之间的嵌入相似度检测话题切换——很流行，但在真实语料上实际不如标题感知分块。作者写下的标题通常比嵌入余弦更好用，且是免费的。
重叠存在的目的是回收跨越切块边界的答案。10% 到 15% 是惯例；更多会浪费索引体积，且对边界良好的切块召回无提升。

检索侧视角见分块与向量搜索。这里要点反过来讲：分块决策会级联到检索质量，而你能做的切块由解析器交给你的东西决定上限。解析层的修复比分块参数调优具备更大的下游效应。

STEP 6

完全跳过文本：视觉 RAG（ColPali 一脉）。

最新的做法——视觉 RAG，由 ColPali（Faysse 等，2024）推广——是放弃文本抽取，把文档当图像索引。每页渲染为截图，经一个视觉语言模型产出每页的多向量（ColBERT 式）嵌入并入索引。查询时，查询文本被嵌入到同一空间；命中的页面以图像返回，并直接送给具备视觉能力的生成器。

它绕开了本条目里每一种解析失败模式：表格、图、公式、手写批注、复杂布局——模型以人类看页面的方式看页面。代价是真的：

索引体积大致大一个量级（每个页面区域一条向量，而非每个切块一条）。
生成需要一个具备足够图像上下文预算的多模态模型；每次回答的成本明显高于文本 RAG。
引用变难——"这条主张来自第 7 页的这一区域"现在是一个包围框，不是可引用的文本片段。

对视觉密集的语料（财报、科学论文、技术手册、幻灯片），视觉 RAG 在更少工程投入下能跑赢一条精心打磨的文本流水线。对以文本为主的语料（Markdown 维基、客服记录、代码），它过度设计，文本路径既更便宜又更易调试。把它当作一类特定文档的工具，不要当作默认值。

贯穿全篇的统一教训：摄取是不被仪表盘照亮的那半 RAG，也是决定答案是否曾可被回收的那半 RAG。在调检索器或提示词之前，读你的切块。然后修解析器。