乐于分享
好东西不私藏

6.2万星Docling:IBM开源的文档解析神器

6.2万星Docling:IBM开源的文档解析神器

摘要:当我第一次把一份 20 页的学术 PDF 丢给 Docling,5 秒后拿到结构清晰的 Markdown——带标题层级、表格还原、图片标注——我意识到:文档解析这个”老大难”问题,终于被 IBM 开源了一个靠谱的答案。这篇文章记录了我对 Docling 从研究到实测的完整过程,以及为什么它可能是 2026 年 RAG 和文档 Agent 的必备基础设施。


一、痛点:为什么文档解析是 AI 的”最后一公里”

你有没有过这种经历?

想做一个企业知识库问答,第一步就被 PDF 卡住了——复制出来的文字是乱的,表格变成了一坨文本,图片和标题混在一块。用传统的 PDF 转文本工具,得到的是平面化的文字堆,而不是有结构的知识

这就是文档解析的困境:LLM 再聪明,喂进去的是垃圾,出来的也只能是垃圾。

RAG(检索增强生成) 的瓶颈往往不是向量数据库或 Prompt 工程,而是上游的文档解析质量。如果表格被拆碎、标题层级丢失、代码块和正文混在一起,再好的检索模型也救不回来。

IBM 的 Docling 就是冲着这个问题来的。


二、Docling 是什么:一句话定义

Docling 是 IBM 开源的文档解析工具包,能把 PDF、Word、PPT、Excel、图片等复杂文档转换成结构化的 Markdown 或 JSON,让 LLM 真正”读懂”文档。

它不是简单的 OCR 或文本提取,而是理解文档的布局结构——标题、段落、表格、图片、代码块、公式、脚注,全部保留层级关系。

特征 含义 对你的影响
多格式支持 PDF、DOCX、PPTX、XLSX、HTML、图片、音频等 一套工具处理所有企业文档
布局理解 识别页面结构、阅读顺序、表格行列 表格不再变成乱码,代码块有独立区域
本地执行 无需云端 API,笔记本就能跑 敏感数据不出本机,合规友好
MIT 协议 完全开源,可商用 放心集成到企业产品
生态集成 原生支持 LangChain、LlamaIndex、Haystack 5 分钟接入现有 RAG 流水线

三、为什么现在需要它?

Docling 诞生于 2024 年 7 月,短短一年在 GitHub 斩获 62,298 Stars4,374 Forks,这个增长速度在文档处理领域非常罕见。

几个真实场景:

  • 企业知识库:把内部 PDF 手册、PPT 培训材料转成结构化数据,做 RAG 问答
  • 学术研究:解析论文 PDF,提取表格数据、公式、参考文献结构
  • 财务分析:处理年报 PDF 中的复杂表格,自动提取财务指标
  • 法律文书:解析合同、专利文档,保留条款层级和引用关系
  • 医疗文档:处理病历、检验报告,结构化后接入诊断 Agent

IBM 自己也在大规模使用 Docling:

“Docling 团队已经用 Docling 处理了 210 万份 Common Crawl 的 PDF,用于训练 IBM Granite 多模态模型。未来计划处理 18 亿份 PDF。” —— IBM Research Blog


四、核心技术:不是 OCR,是”文档理解”

Docling 的核心不是传统 OCR,而是两个专门的 AI 模型:

模型 用途 训练数据
DocLayNet 页面布局分析:识别文本块、图片、表格、标题、脚注、代码块 81,000 张人工标注页面,来自专利、手册、年报
TableFormer 表格结构识别:把图片式表格还原为行列结构 内部测试超越主流表格识别工具,源自 IBM DeepSearch 项目

关键洞察:Docling 尽量避免使用 OCR,而是直接用计算机视觉模型理解页面布局。IBM 研究员 Peter Staar 说:“避免 OCR 减少了错误,还将处理速度提升了 30 倍。”

处理流水线是这样的:

  1. 布局理解 → 把页面分解成标题、段落、表格、图片等区块
  2. 语义分组 → 按逻辑组织成章节(引言、方法、结果、参考文献等)
  3. 内容提取 → 按自然阅读顺序提取文本,重建表格,导出图片
  4. 结构化输出 → 生成 Markdown、HTML、JSON 或图片文件

五、5 分钟上手:代码演示

安装简单到离谱:

pip install docling

基本用法只需 5 行代码:

from docling.document_converter import DocumentConverter

source = "report.pdf"
converter = DocumentConverter()
result = converter.convert(source)

# 导出 Markdown
markdown = result.document.export_to_markdown()
print(markdown)

DocumentConverter() 内部已经 bundled 了完整流水线:

  • PDF 后端 → 加载文件
  • 布局模型 → 检测结构(标题、段落、表格、图片)
  • 表格模型 → 重建表格
  • OCR 引擎(可选)→ 处理扫描页

高级用法:提取表格为 DataFrame

import pandas as pd

for item in result.document:
    if item.label == "table":
        df = item.export_to_dataframe()
        df.to_csv("table.csv", index=False)

导出完整结构化 JSON:

import json
with open("doc.json", "w") as f:
    json.dump(result.document.export_to_dict(), f, indent=2)

六、实测对比:Docling vs 其他工具

我查阅了多个独立基准测试,结果很有说服力:

工具 定位 表格准确率 速度 本地运行 开源
Docling 文档理解框架 97.9%(复杂表格) 中等 ✅ MIT
Unstructured 通用文档解析 75%(复杂表格) 较慢
LlamaParse 云端 API ~6秒(云端)
Marker PDF 转 Markdown 中等
MarkItDown 简单文档转换 低(复杂文件)

数据来源:Procycons 2025 年基准测试(94 份真实文档),LlamaIndex Table Extraction Benchmark

Docling 的优势不是单项冠军,而是”平衡之王”

  • 比 LlamaParse 便宜(本地免费跑)
  • 比 Unstructured 准确(表格结构还原好得多)
  • 比 Marker 全面(支持 DOCX、PPTX、XLSX,不只是 PDF)

七、反面观点:Docling 不是银弹

任何工具都有边界,Docling 也不例外:

1. 表格提取仍有瑕疵

GitHub Issue #2081 有用户反馈:“从研究论文提取表格时,有些值会丢失,特殊字符如 ‘=’ 和 ‘~’ 会被错误添加。” 这在小字号或密集表格中确实会出现。

2. 速度不是最快

LlamaParse 云端处理 consistently ~6 秒,Docling 本地运行取决于硬件和模型选择。如果追求极致速度且数据可以上云,LlamaParse 仍是好选择。

3. 模型体积较大

布局模型和表格模型需要下载,首次使用需要等待模型下载(约几百 MB)。对于资源受限的边缘设备,可能需要精简配置。

4. 手写和复杂排版

虽然支持 OCR,但手写体、复杂艺术排版、多语言混排等极端场景,准确率会下降。


八、生态与集成:不只是个工具,是基础设施

Docling 的真正价值在于生态集成

集成目标 方式 场景
LlamaIndex DoclingReader + DoclingNodeParser RAG 问答系统
LangChain 原生 Document Loader Agent 文档处理
Haystack 官方集成 企业搜索流水线
OpenSearch 混合分块 + 向量索引 大规模文档检索
MCP Server 标准化接口 任何 Agent 接入
IBM Granite 训练数据预处理 多模态模型训练

2025 年 4 月,Docling 被捐赠给 Linux Foundation AI & Data 基金会作为孵化项目,这意味着它正在从 IBM 内部工具走向行业标准。


九、个人观点:文档解析的”SQLite 时刻”

Docling 让我想起了向量数据库领域的 Zilliz/Zvec——不是因为它最快,而是因为它让高质量文档解析变得触手可及

以前,要做企业级文档解析,你有几个选择:

  • 用云端 API(LlamaParse、Azure Document Intelligence)→ 贵、数据要出境
  • 自己训练模型 → 难、需要大量标注数据
  • 用传统 OCR 工具 → 表格碎成渣、结构全丢

Docling 给出了第四个选项:开源、本地、高质量、即插即用

我的判断是:

  1. Docling 会成为 RAG 流水线的默认上游组件,就像 tokenizer 是 LLM 的默认上游一样
  2. 本地执行能力是企业采纳的关键,数据隐私合规越来越严格
  3. 表格结构还原是核心竞争力,这是大多数开源工具的短板
  4. donated to LF AI & Data 是明智之举,社区治理比单一公司背书更可持续

十、适合谁 / 不适合谁

适合 原因
做 RAG 的开发者 上游文档质量直接决定检索效果
企业知识库建设 本地运行,数据不出境
学术研究 论文 PDF 的表格、公式、引用结构还原
财务/法律/医疗文档处理 复杂表格和层级结构保留
AI 模型训练 需要大规模清洗 PDF 训练数据
不适合 替代方案
追求极致速度且数据可上云 LlamaParse API
只有简单文本 PDF PyMuPDF、pdfplumber 更轻量
需要实时流式处理 目前 Docling 是批处理模式
资源极度受限的边缘设备 考虑精简模型或云端方案

十一、结语:让文档”活”过来

文档解析这个领域,过去十年几乎没有什么突破性进展。OCR 能认字,但不懂结构;PDF 转文本能提取内容,但丢了所有上下文。

Docling 的突破性在于:它不是在提取文字,而是在理解文档

当你能把一份 100 页的年报 PDF 转换成结构清晰的 Markdown——标题有层级、表格有行列、图片有标注、代码有独立区块——你得到的不是一堆文字,而是一份机器可读的知识图谱

这才是 AI 时代文档应有的样子。


参考来源

  • Docling GitHub: https://github.com/docling-project/docling (62,298 Stars)
  • IBM Research Blog: https://research.ibm.com/blog/docling-generative-AI
  • Docling 技术报告: arXiv:2408.09869
  • Procycons 2025 基准测试: https://procycons.com/en/blogs/pdf-data-extraction-benchmark
  • LlamaIndex Table Extraction Benchmark: https://www.llamaindex.ai/insights/table-extraction-benchmark
  • OpenSearch + Docling RAG 指南: https://opensearch.org/blog/building-powerful-rag-pipelines-with-docling-and-opensearch
  • Linux Foundation AI & Data: https://lfaidata.foundation/projects/