一句话总结

IBM Research的AI4K小组推出了Docling，这是一个采用MIT许可的开源软件包，用于PDF文档转换，利用专门的AI模型（DocLayNet用于版面分析，TableFormer用于表格结构识别）在普通硬件上提供高效、自包含的处理，并提供可扩展的接口以集成新功能。

核心贡献

• Docling是一个采用MIT许可的自包含Python库，能够在普通硬件上完全本地转换PDF文档，资源占用小。
• 它集成了DocLayNet用于版面分析，TableFormer用于表格结构识别，以恢复页面布局、阅读顺序和表格结构。
• 该工具支持转换为JSON或Markdown格式，元数据提取，可选的OCR，可配置的批处理和交互式处理模式，以及可扩展的架构，便于添加新模型和功能。

引言

将PDF转换为机器可处理格式的挑战源于文档的极端多样性、弱标准化以及为打印优化的布局中固有的结构丢失。这对于需要解锁丰富PDF内容的现代应用（如检索增强生成RAG）越来越重要。虽然存在强大的商业和云端文档理解解决方案，但只有少数开源工具可用，与专有产品相比，功能和质量的差距很大。作者通过Docling解决了这一问题，这是一个开源、自包含的Python库，提供了专门的、可本地执行的AI模型用于版面分析和表格结构识别，从而在普通硬件上实现快速、可扩展且许可宽松的PDF转换。

数据集

作者描述了Docling生成丰富结构化文档输出的能力，这些输出可以转化为用于下游机器学习和知识提取任务的数据集。本文并未发布单一的静态数据集，而是概述了如何将这些输出组合成文档衍生语料库，以及Docling如何与开源的IBM数据准备工具包集成，以构建大规模多模态训练数据集。

• 数据集构成与来源： 数据源自Docling处理的文档，从中提取表格、图形、章节标题和参考文献等结构。实际文档来自用户提供的企业文档集合（论文未指定固定的语料库）。
• 各子集的关键细节： 未给出明确的子集、大小、过滤规则或来源分布。重点在于转换工具的输出质量，而非具体的数据集划分。
• 论文如何使用数据： Docling的结构化输出支持检索增强生成（通过开源助手quackling）、段落检索、分类和知识库构建。对于训练数据创建，Docling集成到IBM数据准备工具包中，该工具包对原始文档应用可扩展的变换，使输出准备好用于大规模多模态模型训练。
• 处理细节： Docling执行表格结构识别、章节分割和参考文献提取。IBM数据准备工具包提供了必要的流水线，将这些结构化输出转换为训练就绪的格式；除了表格和结构识别外，未详细说明裁剪策略或元数据构建的具体细节。

方法

作者将Docling设计为一个线性处理流水线，对每个给定文档顺序执行。如下图所示，工作流程从解析PDF页面开始，然后通过可定制的模型流水线提取各种特征，最后汇总结果并序列化输出。

流水线从一个PDF后端开始，负责检索每页上的所有文本内容及其几何坐标，并渲染每页的视觉表示。为了解决现有开源库的局限性，作者提供了多种后端选择，包括基于qpdf库的自定义解析器，以及依赖pypdfium的替代方案。

在初始解析之后，标准模型流水线在每一页上独立应用一系列AI模型。第一个组件是可选的OCR模块，利用EasyOCR处理扫描PDF或嵌入的位图图像。流水线的核心是一个版面分析模型，该模型是基于RT-DETR的目标检测器，并在DocLayNet数据集上训练。该模型预测各种页面元素的边界框和类别。预测的提议经过后处理以去除重叠，并与提取的文本token相交，将它们分组为有意义的单元，如段落、标题和表格。对于表格结构识别，作者集成了TableFormer，这是一个视觉Transformer模型，预测逻辑行和列结构，并识别表头和表体单元格。结构预测会匹配回原始PDF单元格，以避免昂贵的文本重新转录。

在最后的组装阶段，系统将所有预测结果聚合到一个明确定义的文档数据类型中。然后，后处理模型通过检测文档语言、纠正阅读顺序、匹配图形与标题以及标注元数据来增强特征。最终输出可以序列化为JSON或转换为Markdown表示。此外，作者设计的模型流水线具有高度可扩展性，允许用户通过从抽象基类派生子类来完全自定义模型链。

实验

基准测试实验在225页文档集上评估了Docling的处理速度和资源使用情况，使用两种硬件系统和两种PDF后端，并固定线程数，发现默认后端提供更高的质量，而轻量级pypdfium后端提供更快、内存效率更高的处理，但牺牲了表格恢复的保真度。GPU加速支持仍在开发中。

在两种测试系统上，Docling的pypdfium后端处理文档的速度更快，内存使用量显著低于原生后端，而Apple M3 Max的性能远超Intel Xeon。将线程数从4扩展到16，在Xeon服务器上的运行时间减少比在MacBook上更明显。pypdfium带来的性能提升以输出质量为代价，尤其是在表格恢复方面。在两种系统上，pypdfium后端将处理时间减少了约40%，内存使用量不到原生后端的一半。原生后端的峰值内存保持在约6.2 GB，无论线程数如何，而pypdfium仅需约2.5 GB。在Intel Xeon上，将线程数从4增加到16，两种后端的求解时间缩短超过30%；在Apple M3 Max上，改进不到10%。在所有后端和线程配置下，Apple M3 Max的吞吐量大约是Intel Xeon E5-2690的两倍。

评估比较了Docling的pypdfium和原生后端在Apple M3 Max和Intel Xeon系统上的表现，线程数从4到16变化，以评估运行时间、内存使用和输出质量。pypdfium后端始终提供约40%更快的处理速度和不到一半的内存占用，但牺牲了表格恢复的准确性。Apple M3 Max的吞吐量大约是Xeon的两倍，而线程扩展在Intel服务器上带来的运行时间减少远大于在MacBook上。