Docling：将PDF转换为AI可读格式 locale

#决定其余所有环节的关键步骤

当文档助手回答得不好时，人们会归咎于模型。原因却几乎总是出在处理流程的上游。从企业模板导出的报告，经过一个简单的文本提取器处理后，会变成这样的文本流：页眉打断段落，双栏内容被横向逐行读取，结果表格变成一连串失去上下文的数字。这些片段随后被编码、检索，并作为事实呈现给模型：模型读到荒谬的内容，又自信地将其复述出来。无论是嵌入模型、重排序器还是提示词，都无法挽救流程上游失败的转换——大多数本地 RAG 教程专注于语言模型的选择，却对这一点只字不提。

Docling 直接针对这一常被忽视的步骤。该项目由 IBM Research 于 2024 年 7 月以 MIT 许可证开源发布，允许无版税且无 Copyleft 限制的商业使用。它迅速在 GitHub 上获得超过 10,000 颗星，并在 2025 年初位列全球最受关注的仓库之一；截至 2026 年 9 月底，官方仓库拥有超过 68,000 颗星，其最新稳定版 v2.130.0 发布于 2026 年 9 月 22 日。

#Docling 的功能

布局分析

识别页面中的各个区域及其类型，避免图注被合并到段落中，或页脚出现在句子中间。

阅读顺序

还原人类会遵循的阅读顺序，让分栏排版的文档终于可以有效利用。

表格结构

恢复行、列及合并单元格，并以真正的表格形式导出，而非文本行。

必要时启用光学字符识别

没有文本层的扫描页面会先经过 OCR 处理，避免导入时没有任何文本内容。

图表理解

饼图、直方图和曲线图可以转换为数据表格或文字描述，而不是被完全忽略。

统一的文档模型

统一的内部表示，多种导出格式（Markdown、HTML、DocTags、无损 JSON）：后续处理流程无需知道输入原本是 PDF 还是办公文档。

除了 PDF，Docling 还支持 DOCX、PPTX、XLSX、HTML、EPUB、图片（PNG、TIFF、JPEG 等）、电子邮件（EML、MSG），甚至能通过转录流水线处理音频（WAV、MP3）——这一点很重要，因为实际的语料库从来不会只包含同一种类型的内容。在集成方面，只需几行代码即可将该库接入 LangChain、LlamaIndex、Crew AI 和 Haystack，从而免去在智能体流水线中自行编写转换代码的工作。

#表格：值得费这番功夫的真正原因

在专业文档中，数字几乎总是出现在表格里，而简单粗糙的提取方法在这里最容易严重失效。一行内容被提取成“Paris 12 480 3,2”后，便丢失了赋予它意义的列标题。随后，检索返回一个看似正确的片段，模型却编造了数值之间的关系，导致回答出错，而且这种错误很难察觉。

Docling 将这项任务交给一个专用模型 TableFormer，该模型使用一种名为 OTSL（Optimized Table Structure Language，优化表格结构语言）的专用词汇表来编码表格结构，并能正确处理合并单元格和多级表头。根据提出该格式的研究论文，OTSL 将等效 HTML 表示所需的 28 个以上 token 缩减至寥寥数个，从而将待预测序列的平均长度缩短约一半，并将推理时间减半（相较于生成 HTML 的模型）——这是一个对最终用户不可见的架构细节，但解释了为何 Docling 的表格识别功能即使没有专门用于这一用途的 GPU，也能处理大量数据。管道选项中提供两种模式：FAST 模式速度更快，但在处理复杂表格时精度较低；只要表格包含合并单元格或多级表头，就推荐使用 ACCURATE 模式。即使以 Markdown 格式保留结构，也能维持每个数值与其对应名称之间的关联。在预期答案为数字的语料库中，仅凭这一点，就足以说明采用比简单文本提取器更耗资源的转换器是合理的。

#可用的 OCR 引擎

Docling 并非只搭载一种 OCR 引擎：它根据文档类型统筹调用多个可互换的引擎。EasyOCR 和 Tesseract（通过 tesserocr 或命令行）覆盖大多数情况；RapidOCR 支持自定义模型；OcrMac 在 macOS 原生文字识别功能可用时会调用该功能。引擎选择在处理流程的选项中完成，而非在应用代码中，因此可以切换引擎而无需修改文档导入逻辑。

在实际应用中，生产环境的数据摄取流程几乎总是先用一份样本测试 Tesseract：如果它能输出干净的文本，就没有理由承担使用 EasyOCR 的成本。改用 EasyOCR 主要适用于质量下降的扫描件、部分内容为手写的表单，或 Tesseract 表现不佳的语言。RapidOCR 和 OcrMac 仍是小众选择，分别仅适用于已有训练完成的自研 OCR 模型，以及无需安装外部依赖的独立 Mac 工作站。

#按文档结构分块

大多数本地 RAG 指南没有解释的一个要点是：Docling 不仅进行格式转换，还提供适合其刚刚重建的文档结构的切分方式。其 HybridChunker 从文档的层级结构（标题、章节）出发，再根据所选嵌入模型实际使用的分词器调整每个片段的大小：过长的块会在文档元素的边界处切分，而不是在句子中间切断；共享同一标题的过短块则会被合并。提供的分词器必须与下游所用嵌入模型的分词器保持一致，否则片段的实际大小（以 token 计）就会与向量索引的预期不符。这是一种基于结构的切分方式，可以与忽略句子边界、按字符块切分的方式进行比较：参见我们的文本切分策略指南，了解两种方法之间的权衡。

#计算成本

实际意义是：按批次转换一次，然后保留结果。只有源数据发生变化时，重新索引才有意义。如果同一台机器还运行着语言模型，两者会通过处理流水线的加速选项争用同一个 GPU：在用户提问的同时摄取语料库，会让两者都变慢。

#在流程中的位置

1. 01
   转换

   Docling 将您的文件转换为 Markdown 或结构化 JSON，并完整保留表格。
2. 02
   分块

   使用 HybridChunker，按照识别出的文档结构和嵌入模型的分词器进行分块，而不是每隔一千个字符切分一次。转换器在这里再次发挥了价值。
3. 03
   编码与存储

   本地嵌入模型将文本片段转换为向量，并存储在类似 Qdrant 的向量数据库中。
4. 04
   回答

   本地模型通过 Ollama 或本地推理服务器，基于检索到的段落进行文本生成。

• 将向量存储在Qdrant中
• 比较分块策略
• 一款开箱即用、可与自己的文档对话的应用
• 特殊情况：从发票中提取数据
• 单独使用 Tesseract：适合清晰文本的更简单 OCR 方案
• QuelLLM 本地 RAG 工具包：所有组件汇集于同一页面
• 来源：Docling 在 GitHub 上的官方仓库
• 来源：Docling管道选项（OCR、TableFormer）
• 来源：HybridChunker 文档

#仍然存在的问题

低质量扫描件

对于歪斜的复印件，OCR 的识别精度受限于物理条件，而非软件。

图形元素较多的页面布局

杂志、文字环绕图片的排版、表单：所有转换工具都难以处理。

手写体

超出此类工具范畴

复杂图表

图表理解功能涵盖常见类型（饼图、柱状图、折线图）；对于特别特殊的图表——地图、技术图、架构图——仍可能只能还原其图注，而无法还原其中的数值。

入门成本

首次启动时，安装版面布局、表格和 OCR 模型需要下载数 GB 的数据；对于无法访问网络的隔离机器，必须提前获取这些模型。

#FAQ