文档解析是 RAG 系统的隐形天花板

一个合规承包商构建了一个 RAG 系统，旨在回答有关 400 页政策文档的问题。系统通过了内部 QA，针对单主题查询的检索表现正确。然而系统上线后，在处理涉及例外条款的任何问题时，它开始返回语气自信、结构严谨但错误百出的答案。

调试过程似曾相识：更换嵌入模型、调整相似度阈值、试验分块大小、添加重排序器。几周过去了，改进微乎其微。真正的症结在于，一个关键的例外条款在段落边界处被分割到了两个分块（chunks）中 —— 这并非由于分块策略，而是因为 PDF 提取器在误读排版时，悄无声息地将该段落一分为二。孤立来看，这两个分块都无法检索或解析。系统无法通过幻觉得到正确答案，因为正确的信息从未完整地进入索引。

这就是“提取天花板”：即当下游优化再多也无法弥补受损或缺失的输入数据时，系统所面临的瓶颈。

PDF 的本质

PDF 是一种显示格式，而非数据格式。文件存储的是字符放置指令 —— 页面上的坐标 —— 而非语义结构。一篇双栏学术论文并不是两段有序的文本流，而是一组恰好在渲染时通过视觉形成分栏的字符位置集合。PDF 格式在语义上没有“这段文字在另一段文字之前”的概念。

这与 RAG 流水线所需的东西产生了根本性的错位：逻辑有序、保留结构的纯文本。提取工具必须从空间坐标中重建语义顺序，而它们往往以可预测的模式失败。

栏目合并。 标准的解析器在向下移动一行之前，会先读取整个页面的宽度。在双栏论文中，这会导致左栏和右栏的文本按行交错。输出看起来像英文句子，但顺序完全错误。PyMuPDF 在默认模式下按照“字符存储顺序而非阅读顺序”进行解析，在复杂布局中会产生混乱的结果。

表格扁平化。 将表格转换为顺序文本会破坏行、列关系。包含合并单元格、多级表头和子组行的财务报表，会变成一串没有任何位置上下文的数字。在评估复杂表格提取的基准测试中，LlamaParse 错误放置了一份包含 48 个单元格的可持续发展报告表格中的列值 —— 尽管捕获了正确的数据，但将其归属于错误的维度，导致表格无法解析。Unstructured 在处理同一文档时遭遇了列偏移错误，导致整个区域明细表不可用。

章节层级崩溃。 如果没有标题检测，一份 50 页的文档会被扁平化为毫无区别的正文内容。标题样式 —— 更大的字体、加粗、特定的位置 —— 是 PDF 作为原始字符属性存储的视觉提示。不进行布局分析的工具无法区分 H2 标题和恰好以大号单词开头的普通段落。

扫描版 PDF 损坏。 可搜索的 PDF 将 OCR 文本层叠加在扫描图像之上。光照条件、旋转、倾斜和手写注释都会在提取开始前降低 OCR 质量。文本记录可能会在任意位置断裂。存储为曲线而非文本字形的字符往往会被完全遗漏。

这四种失败模式的危险之处在于：它们都不会抛出异常。提取流水线正常返回文本，计算嵌入，相似度搜索检索分块，然后系统自信地给出错误的答案。

为什么你总是归咎于嵌入模型

当 RAG 系统表现不佳时，典型的调试路径会跳到检索层：嵌入模型、相似度阈值、分块重叠比例、重排序器。这些都处于提取流程的下游。如果相关信息从未被清晰地捕获，再怎么优化检索也无法让它浮现。

相关的实证证据非常惊人。在一项针对 800 多份文档的基准测试中，解析器实现了 74% 的文本准确率，但结构保留率仅为 35% —— 这两项指标的相关性仅为 0.174。极高的字符级准确率几乎无法说明结构是否得以保留。提取输出在 BLEU 和编辑相似度上可能得分很高，但同时却破坏了每个表格、合并了所有栏目并删除了所有标题上下文。

这种差距解释了一种常见的挫败感：更换嵌入模型带来的收益微乎其微。问题不在于表示形式，而在于被表示的内容。在针对 302 个问题的受控研究中，改进的 PDF 解析（基于深度学习而非基于规则）在 47% 的 RAG 问题上优于基准方案，在 38% 的问题上持平，仅在 15% 的问题上落败。该研究中近一半的问答改进完全归功于更好的提取，而没有对检索或生成部分做任何更改。

第二个复合效应是嵌入漂移（embedding drift）。当你更改解析器或分块逻辑时 —— 哪怕只是细微的改动 —— 文档会被重新处理，但来自原始分块的嵌入可能仍保留在向量库中。同一份文档在不同的提取运行下会产生结构迥异的分块，但旧的向量依然存在于索引中。开发者观察到检索召回率随时间下降，将其归因于模型漂移，并尝试新的嵌入模型。真正的原因是提取内容与当前索引内容之间的版本不匹配。

诊断框架：将提取与检索分离

正确的评估方法是孤立地测试每一层。在确定每一层独立贡献了什么之前，不要运行端到端评估。

第一层：提取审计。 在接触嵌入（embeddings）之前，先构建一个黄金提取集。抽样 50–100 页代表你所面临的棘手案例：表格、多栏布局、扫描页、脚注、嵌套列表。手动标注正确的文本和结构。针对这些页面运行你的解析器，并测量字符级 F1、n-gram 重叠（BLEU-4）和结构元素恢复率——具体来说，是否找到了所有表格，标题是否保留了下来？

几乎在每个 RAG 项目中，这一步都会被跳过。工程师们直接进入索引阶段，并因为没有抛出异常而假设提取工作正常。黄金集能捕捉到那些无声的失败。

第二层：检索评估。 在拥有已知良好的上下文集后，创建一个黄金问答集，其中你明确知道每个问题应该检索到哪些特定的块（chunks）。测量上下文召回率（相关块是否在 top-k 中？）和上下文精确度（不相关的块是否挤占了它们？）。这可以将检索算法的失败与提取失败区分开来。

诊断信号：如果上下文召回率低，先审计你的黄金提取集。只有在提取看起来干净时，才应该调查嵌入模型选择、分块大小或检索参数。

第三层：生成评估。 给定检索到的上下文，测量忠实度（回答是否植根于上下文中？）和正确性。在这一层，在正确的提取和检索下仍然存在的幻觉是 LLM 的问题。在大多数生产系统中，它们只占失败案例的少数。

RAGAS、Braintrust、Langfuse 和 Deepset 的 Haystack 等工具都支持组件级的 RAG 评估，可以将失败追踪回负责的层。对层隔离的投资会在更短的调试周期中得到回报。

为你的文档语料库选择正确的解析器

解析器的选择不如语料库分析重要。在 800 份文档的基准测试中，领域差异对性能的影响超过了解析器的选择：法律合同在不同工具中的准确率都在 93–95% 之间，而学术论文的准确率则从 8% 到 60% 不等——这 52 个百分点的差距表明，文档类型对工具差异的影响超过了 55 个百分点。

在选择工具之前先对语料库进行分类。

对于财务报告、政府备案文件和结构化商业文档： PyMuPDF 速度很快（在财务文档上的 F1=0.9825），并且能可靠地处理原生 PDF。它在处理复杂或无边框表格时提取能力较弱；对于格栅表格（有边框的网格），可以使用 Camelot 进行补充，它在政府招标文档上达到了 F1=0.8279。

对于学术和科学论文： 基于规则的工具基本都会失败。Nougat（Meta 基于 Transformer 的解析器）是唯一能在包含数学公式、多栏布局和复杂图表说明交错的论文中保持性能的选择。

对于带有表格的复杂企业文档： Docling（IBM，MIT 许可）使用专门的布局分析模型，在包含 48 个单元格的可持续发展报告表格上达到了 97.9% 的准确率，而其他工具在此表格上均告失败。它在本地处理（约 1.3 页/秒），这对于数据敏感的环境非常重要。

对于需要务实权衡的通用生产流水线： LlamaParse（0.003 美元/页）在独立基准测试中达到了 78% 的编辑相似度和 81% 的鲁棒性得分，无论文档长度如何，处理速度约为每份文档 17 秒，并且在无需运行本地模型的情况下处理感知布局的提取。

对于带有手写内容的扫描文档： Amazon Textract 在手写识别方面得分为 82%，并与 AWS 流水线集成。Azure Document Intelligence 在印刷体文本 OCR 方面领先（2025 年基准测试中准确率为 96%），但在表格结构提取方面表现欠佳。

生产中最常见的错误是为异构语料库选择单一的解析器。混合路由策略——在摄取时对文档类型进行分类，然后路由到相应的专用解析器——在多样化的文档集合上始终优于任何单一解析器的方法。

防止提取失败的生产模式

一些具体的实践可以防止最常见的失败模式。

将表格提取为一等实体。 绝不要允许表格在行中间被切分。将表格与正文分开提取，将其转换为统一格式（Markdown 或结构化 JSON），并将其存储为原子单元，其元数据指向其源章节上下文。这可以在整个流水线中保留行列关系。

保留章节层级作为元数据。 使用能识别标题层级的解析器，并将章节路径存储为块元数据——“第三章 > 风险因素 > 市场风险”。当一个块缺乏足够的局部上下文而无法通过语义相似度检索时，章节路径可以实现在模糊查询下的上下文检索。

在索引前实施质量门禁。 通过程序检查：可疑的短块（截断）、高特殊字符密度（OCR 损坏伪影）以及列数不一致的表格（结构性失败）。这些信号能在问题文档损坏你的向量索引之前，捕捉到那 20% 消耗了 80% 流水线调试时间的文档。

为你的提取流水线进行版本化。 当解析器配置或分块逻辑发生变化时，跟踪哪些嵌入是在哪个提取版本下产生的。重新索引受影响的文档。如果没有提取版本化，随着陈旧向量的积累，流水线的变化会无声地降低检索质量。

在生产中监控提取健康状况。 跟踪令牌添加率（解析器引入的但不在源文件中的文本）、元素检测率（是否找到了表格和标题？）以及随时间变化的块长度分布。块长度分布的突然转变通常表示输入文档的格式发生了变化，而你的解析器处理方式有所不同。

NVIDIA 对 OCR 流水线的研究发现，专用提取工具在检索任务上的表现优于视觉语言模型 7.2%，同时速度快 32 倍（8.47 对 0.26 页/秒）。视觉语言模型（VLMs）是生成层处理视觉内容（图表、图解）的正确工具，而不是在吞吐量至关重要且目标是文本忠实度的提取层。

正确的投入顺序

对于大多数 RAG 团队来说，正确的投入顺序是：提取质量 → 分块策略 → 检索 → 生成。这与团队实际投入时间的顺序大致相反。

究其原因，在于可见性。提取失败是无声无息的。检索失败会体现在用户投诉中。而生成失败则是显而易见的——幻觉很容易被发现并归咎。因此，工程时间流向了流程中可见的末端，导致上游的根源问题未能得到解决。

为你特定的文档库构建一套黄金提取集（Golden extraction set）——在索引之前、在选择 embedding 模型之前、在调优检索之前——是杠杆率最高的诊断性投入。这需要一周的人工标注。它通常比数月的下游调优能更早地暴露实际的故障点。

Embedding 模型无法修复糟糕的分块。重排序器（Reranker）无法找回从未被检索到的块。LLM 无法根据从未被清晰捕获的上下文进行回答。提取是上限。先提高它。