为什么读取PDF这么难

原链接：https://www.llamaindex.ai/blog/why-reading-pdfs-is-hard"

每一个 AI 智能体最终都会撞上同一堵墙：它需要读取 PDF。RAG 管线、深度研究智能体、接触企业数据的编码智能体——它们都需要摄入文档，而这些文档绝大多数都是 PDF。问题在于，PDF 从未被设计为机器可读的格式。

这种格式直接脱胎于 PostScript——Adobe 于 1982 年创建的页面描述语言。PostScript 告诉打印机画什么、画在哪里。PDF（1993 年）保留了相同的成像模型，但去掉了编程构造：一个页面就是一系列在特定坐标处渲染图形的操作符。HTML 有 <h1>、<table>、<p>——这些声明文档结构的语义标签；而 PDF 只会说"用这个字体程序在坐标 (72, 740) 处渲染这些字形轮廓。"它不存储字母或字符串。它存储的是矢量曲线的绘制指令——这些曲线渲染后恰好看起来像文本——而且根据 PDF 的来源不同，字体可能被错误标记，字形可能与你预期的字符不对应，你在屏幕上看到的内容可能根本无法还原为文本。

PDF 描述的是页面的外观，而非其含义。 仅此一点，就是一切 PDF 解析问题的根源所在。

你看到的 vs. PDF 中存储的

PDF 中的文本是字形，而非字符

你所看到的流畅文本，实际上是内容流中的一系列绘制命令，夹在 BT（Begin Text）和 ET（End Text）操作符之间，每个片段都定位在绝对的 x、y 坐标上。

上图展示了短语 "The quick brown fox jumps over the lazy dog." 在 PDF 中可能被存储的方式。

单词之间的空格并不作为实际的空格字符存储——间距隐含在 x 坐标的跳跃中，解析器需要通过字体度量来推断单词边界。TJ 操作符使这一问题更加复杂：它包含以千分之一文本空间单位为单位的逐字形字距调整（[(A) 120 (W) 120 (A) 95 (Y)] TJ），解析器必须判断每个数值间距代表的是字距调整还是单词边界。没有标准答案；这取决于字体、PDF 生成器，有时甚至只是运气。

此外，Tj 字符串中的字节并不是 Unicode。它们是通过 CMap（字符映射表）经字体特定编码映射的字符代码。如果字体包含正确的 /ToUnicode CMap，解析器可以将代码映射回可读字符。但如果不是——这在字体子集化中经常发生，PDF 只嵌入其使用的字形并为它们分配任意 ID——没有 OCR 就无法恢复文本。

这就意味着，有时你从 PDF 中复制文本并粘贴后，得到的可能是 (cid:38)(cid:76)(cid:81)(cid:68)(cid:81) 或一串错误的字符，而不是你在屏幕上清晰看到的文字。PDF 渲染得很完美，因为渲染器直接绘制字形轮廓——它不需要 Unicode 就能绘制形状。但任何尝试提取实际文本的解析器都无能为力。

大多数真实世界的 PDF 中根本没有"表格"的概念

PDF 规范（ISO 32000）在技术上定义了一种通过"Tagged PDF"（下文详述）实现结构化布局原语（包括表格）的方式。但绝大多数真实世界的 PDF 中完全不包含这些结构。你所看到的表格，实际上是两组完全独立的绘制操作：用路径操作符（m 表示 moveto、l 表示 lineto、re 表示矩形、S 表示描边）绘制的网格线，以及用 BT/ET + Tj 放置在 x、y 坐标处的单元格文本。线条与文本之间没有任何语义关联：

解析器必须检测线段，找到交叉点来推断单元格边界，然后通过空间包含关系将文本关联到单元格。一位测试了 12 款"同类最佳"PDF 表格提取工具的从业者将结果描述为["令人触目惊心。"](https://medium.com/@kramermark/i-tested-12-best-in-class-pdf-table-extraction-tools-and-the-results-were-appalling-f8a9991d972e ""令人触目惊心。"")而且许多表格甚至没有网格线——它们是纯靠空白对齐的文本，没有任何线条，这使得表格检测变成了纯粹视觉模式识别问题。

你看到的表格 vs. PDF 中存储的

图表面临完全相同的问题。柱状图是用 re + f（填充）绘制的彩色矩形，折线图是路径段（m + l），坐标轴标签只是附近的文本坐标。没有"图表"对象，没有数据序列的元数据。解析器看到的只是彩色形状，必须推断它们代表什么。

阅读顺序是一种猜测

内容流中操作符的顺序与视觉阅读顺序之间没有任何保证关系。

双栏布局可能先存储第二栏再存储第一栏，可能交错混合两栏的字符，也可能最后才绘制页眉。PDF 生成器按照适合其管线的任意顺序写入内容：模板层最后写入，文本按字体分组以最小化字体切换开销，背景元素先于前景元素。重建阅读顺序需要提取所有文本及其位置，将字符聚类为单词、单词聚类为行、行聚类为栏，然后确定正确的顺序。每一步都基于启发式方法。

Tagged PDF（在 PDF 1.4 中引入）本应解决这个问题。它在顶层添加了语义结构标签，如 <Table>、<P>、<H1>，并定义了逻辑阅读顺序——这也是上文提到的表格原语的来源。但标签完全是可选的，大多数真实世界的 PDF 都不包含它。它的存在主要是为了满足无障碍合规要求（ADA、Section 508），即使是 Acrobat 等工具自动生成的标签，在面对复杂布局时也经常出错。这个特性存在于规范中，但对于解析你在实际场景中遇到的大多数文档来说，实际上毫无用处。

阅读顺序 vs. 内容流顺序

七十年的文档读取探索

自 20 世纪 50 年代以来，人们一直在构建文档读取机器。David Shepard 于 1951 年在自家阁楼中建造了"Gismo"，这台机器能够以约 90% 的准确率识别打字机字母。美国邮政局在 20 世纪 60 年代部署了 OCR 用于自动邮件分拣。Raymond Kurzweil 于 1976 年发布了第一款全字体 OCR——Kurzweil 阅读机^[1]，这是一款面向视障读者的印刷品转语音设备。Stevie Wonder 是首批购买者之一。

文档解析的整体发展脉络可分为两个时代：基于管线的方法——将专门化的阶段串联起来，以及基于模型的方法——尝试整体理解页面。

管线时代

最早的基于管线的方法建立在启发式算法之上：对图像进行二值化、查找连通分量、分割字符、逐一识别、应用字典纠错。Tesseract^[2] 于 20 世纪 80 年代在 HP 实验室开发，2006 年由 Google 开源，成为大多数开源 OCR 的基石。

机器学习和深度学习的出现意味着从 2015 年左右开始，可以用专用模型替换管线中的各个组件。基于 CNN 的文本检测模型（EAST^[3]、CRAFT^[4]）取代了手工调优的启发式方法来定位文本区域。CRNN 架构^[5]带来了序列级识别能力，可以识别整行文本而无需逐个分割字符。Tesseract 4 引入了 LSTM 网络。在清洁文档上，文本识别准确率确实达到了令人满意的水平。Amazon Textract（2019 年）、Google Document AI、Azure Form Recognizer 等 Cloud API 将这一方法产品化。一个围绕 ABBYY、Kofax（现为 Tungsten Automation）等公司形成的数十亿美元的 IDP（智能文档处理）产业由此崛起。

这些系统在清洁、结构化的文档上表现良好，但由于它们主要基于刚性管线和高度专化的 ML 模型，在处理复杂布局的文档或任何超出训练数据分布的文档时就会失败。企业界的应对方案是针对每种文档类型训练模板，但这种方法需要持续训练，无法轻松扩展到数千甚至数百万种不同的文档类型。

模型时代

端到端模型的发展带来了通过同时推理文本、布局和视觉信息——而非分阶段处理——来一次性解析文档的可能性。微软的 LayoutLM^[6] 系列（2020-2022）是这方面的早期工作，在文本、视觉特征和二维空间位置上进行了联合预训练。近年来，前沿实验室的专有 VLM 在多样化的数据分布上展现了强大的文档理解能力。GPT-4V 于 2023 年底发布，随后是 Gemini 1.0、Claude 3 等视觉能力不断增强的模型。这引发了人们的认识：通过"直接截图发给 VLM"就能完成文档解析。

管线方法 vs. 模型方法在文档解析中的对比

"直接截图"无法规模化

如今，Gemini 3 Pro、Opus 4.6、GPT-5.2 等前沿 VLM 已经可以通过截图读取 PDF。虽然它们的单次文档理解准确率相当高，但在大量生产任务中，其性能仍不够理想。

我们在《LLM API 不是完整的文档解析器》^[7]一文中对此进行了详细讨论。概括来说：每一页都要消耗视觉 token（包括那些根本不需要视觉处理的纯文本页面），视觉模型在信息密集的内容上仍然会产生幻觉（数字颠倒、凭空捏造否定词、跳过表格行），你无法获得元数据（没有用于审计追踪的边界框、置信度分数或来源引用），而速率限制使其在企业规模下不切实际。

文本提取 + 视觉 = 正确的架构

正确的方法是将两者结合，让各自发挥所长。这看起来与之前的基于管线的方法类似，只是底层组件的泛化准确率要高得多。

从 PDF 二进制文件中提取文本可以获得原始字符、字体信息和近似位置——快速、廉价，对于大多数标准文本内容来说是可靠的。这些信息可以输入 LLM 来重建逻辑阅读顺序。

与此同时，VLM 处理视觉上复杂的区域：复杂错位或非标准表格、需要解读坐标轴标签的无标注图表、手写批注。布局检测模型将每个页面分割为这些元素，并在解析后的元数据中包含精细的边界框，使智能体构建者能够将任何 LLM 生成的答案追溯到源文档中的视觉引用。

这就是我们正在用 LlamaParse^[8] 构建的东西。这种组合方法在准确率和成本上都超越了纯截图方法，因为对于大部分内容，你获得了文本提取的低成本可靠性；而在真正需要的地方，你又拥有视觉模型的空间推理能力。

PDF 包含了互联网上一些最高质量的书面内容，而且它们不会消失——仅 Common Crawl 就包含大约 13 亿个 PDF 文件。AI 智能体需要可靠地大规模读取这些文件，而要做好这一点，就意味着要理解为什么这种格式从一开始就如此困难。