文档解析是 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 中？）和上下文精确度（不相关的块是否挤占了它们？）。这可以将检索算法的失败与提取失败区分开来。

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

加载中…