一个包治百病的文档解析器：Docling 如何把 PDF/DOCX/EPUB/视频都变成 LLM 的早餐
你要给 LLM 喂一份 PDF。看起来简单——用 PyPDF2 提文本就行。然后你发现：PDF 里的表格被拆成乱序的文本片段，双栏论文的阅读顺序是错的，公式变成了一堆乱码，扫描版 PDF 完全是图片。你换 pdfplumber，表格好一点但公式还是不行。你换 unstructured，功能多但速度慢得像蜗牛。最后你发…
一个包治百病的文档解析器：Docling 如何把 PDF/DOCX/EPUB/视频都变成 LLM 的早餐
你要给 LLM 喂一份 PDF。看起来简单——用 PyPDF2 提文本就行。然后你发现：PDF 里的表格被拆成乱序的文本片段，双栏论文的阅读顺序是错的，公式变成了一堆乱码，扫描版 PDF 完全是图片。你换 pdfplumber，表格好一点但公式还是不行。你换 unstructured，功能多但速度慢得像蜗牛。最后你发现自己在写一个"文档解析器选型"的调研报告，而不是在做你原本要做的事情。
这是 2024 年之前每个做 RAG 的人的日常。IBM Research 的团队显然也被这个问题折磨过——他们做了 Docling，一个 MIT 许可的文档处理工具包，专门解决"把乱七八糟的文档格式变成 LLM 能消化的结构化数据"这件事。94 stars/天，GitHub 上 30k+ 总星，LF AI & Data 基金会项目，arXiv 论文 2408.09869。
核心抽象：DocTags 作为通用中间表示
Docling 的核心设计是DocTags——一种统一的文档中间表示格式。无论输入是 PDF、DOCX、PPTX、HTML、EPUB 还是 Apple Pages，都会先被解析成 DocTags，然后再导出为 Markdown、JSON 或其他格式。
这个设计的关键在于：格式多样性是输入端的问题，不是输出端的问题。LLM 不关心你给它的是 PDF 还是 DOCX，它只关心文本的结构和质量。DocTags 把"解析各种格式"和"生成 LLM 输入"解耦——解析器只需要把每种格式转成 DocTags，下游应用只需要处理 DocTags。
这和编译器的 IR（中间表示）是同一个思路：LLVM IR 让前端（C/C++/Rust）和后端（x86/ARM/RISC-V）解耦，DocTags 让前端（PDF/DOCX/HTML）和后端（Markdown/JSON/向量数据库）解耦。这种"窄腰"设计在系统里反复出现，因为它的组合性优势太大了——加一个新格式只需要写一个新解析器，加一个新输出只需要写一个新导出器。
PDF 理解：不只是提文本
Docling 的 PDF 处理不是简单的文本提取。它做的是结构化理解：
- 页面布局分析：识别标题、正文、页眉页脚、页码
- 阅读顺序检测：双栏论文的正确阅读顺序，多栏网页的列识别
- 表格结构识别：把表格转成 HTML 或 Markdown 表格，保留行列关系
- 公式识别：把图片公式转成 LaTeX
- 图片分类：区分图表、示意图、照片
- 元数据提取：标题、作者、摘要、参考文献
258M 参数是个有意思的数字。当前 VLM 主流是 7B+ 参数（Qwen-VL、LLaVA），Docling 用 258M 的小模型做文档理解——这是"任务特化小模型 > 通用大模型"的又一例证。文档理解不需要通用世界知识，需要的是布局感知和结构识别，这种窄任务用小模型足够了，而且推理成本低一个数量级。
格式覆盖：从 PDF 到视频
Docling 的格式支持列表长得像自助餐菜单：
文档类：PDF、DOCX、PPTX、XLSX、HTML、Markdown、AsciiDoc、RTF、ODT/ODS/ODP（OpenDocument）
特殊格式：EPUB（电子书）、XBRL（财务报告）、Apple Pages（.pages，两种 container generation 都支持）、Email（.eml/.msg）
多媒体：图片（OCR + VLM）、音频（ASR 转录）、视频（MP4/AVI/MOV/MKV/WebM，提取关键帧 + ASR 转录）
纯文本：.txt、.qmd、.Rmd
这个覆盖范围已经远超原始论文（论文只讲 PDF）。特别是视频和音频支持——Docling 现在能把一个 MP4 视频转成"关键帧图片 + 语音转录文本"的结构化输出，这对视频 RAG 是直接可用的。
XBRL 支持值得单独提一下。XBRL 是财务报告的标准格式，SEC 上市公司年报都用它。传统做法是用 Arelle 或其他专用 XBRL 工具，Docling 把它纳入统一文档处理流程，意味着金融 RAG 应用可以用同一套管线处理年报、新闻稿、分析师报告——不管原始格式是什么。
MCP Server：文档作为 agent 工具
Docling 提供了一个 MCP（Model Context Protocol）server。这意味着 LLM agent 可以把 Docling 当成一个工具调用——agent 遇到 PDF 时，不需要自己解析，而是通过 MCP 调用 Docling 的 API，拿到结构化文本。
这个设计的影响比看起来大。当前 agent 框架（LangChain、LlamaIndex）处理文档的方式是"预处理时解析好，存进向量数据库"。但如果文档是动态的——agent 在执行任务时才发现需要读某个 PDF——就需要运行时解析。MCP server 让 Docling 成为 agent 的"文档感知器官"，agent 可以在任务执行中按需解析任意文档。
这和 Anthropic 的 MCP 生态方向一致——把专用工具暴露给 agent，而不是让 agent 自己实现所有功能。Docling 的 MCP server 让"文档解析"成为 agent 可组合的能力之一。
集成生态：四个主流框架
Docling 的集成列表：LangChain、LlamaIndex、Crew AI、Haystack。这四个覆盖了当前 agent/RAG 框架的主流——LangChain 是最流行的通用框架，LlamaIndex 专注 RAG，Crew AI 做多 agent 协作，Haystack 是企业级搜索。
这种"不做框架，做框架的插件"策略是聪明的。Docling 不想成为"又一个 RAG 框架"，而是想成为所有 RAG 框架的文档处理层。用户不需要为了用 Docling 而切换框架，只需要在现有框架里加一个 Docling loader。
对比 unstructured.io 的策略——unstructured 也做文档解析，但它的定位更偏向"数据 ETL"，而 Docling 更偏向"LLM 输入预处理"。两者的技术路线相似（都是布局分析 + OCR + 结构化），但生态定位不同。
IBM 的开源策略
Docling 是 IBM Research 的项目，但已经捐给 LF AI & Data 基金会。这意味着：
1. 商标归基金会：IBM 不独占品牌 2. 贡献者协议：第三方可以贡献而不需要签 IBM 的 CLA 3. 治理透明：项目方向不由单一公司决定
IBM 近年在开源 AI 领域的策略很一致——Granite 模型系列、Docling、Merlin（RAG 评测）都是 MIT/Apache 许可 + 基金会治理。这和 Meta 的 Llama 策略（自定义许可证，限制商业使用门槛）形成对比。IBM 的策略对企业用户更友好——没有许可证风险，可以放心用在商业产品里。
Docling 的 arXiv 论文（2408.09869）发表于 2024 年 8 月，到 2026 年 9 月已经两年多。项目从纯 PDF 解析扩展到视频、音频、财务报告、电子书——这种"从单点突破到平台化"的演进路径，和 PyTorch 从深度学习框架到通用 AI 编译器的路径类似。
还没解决的问题
Docling 的文档很坦诚，列出了"Coming soon"和"Limitations"：
Coming soon：元数据提取增强、更多布局模型、表格理解改进
Limitations（从 GitHub issues 推断）：
- 扫描版 PDF 的 OCR 质量依赖底层 Tesseract/EasyOCR
- 复杂公式（多行、矩阵）识别率不如专用工具
- 视频处理是帧级采样，不是真正的视频理解
- 大文件处理内存占用高
结语：文档处理的"窄腰"时刻
Docling 的核心贡献不是某个解析算法——布局分析、表格识别、OCR 都是成熟技术。它的贡献是把文档处理变成一个有标准接口的层：输入任意格式，输出 DocTags，下游应用统一处理。
这和 TCP/IP 之于网络、LLVM IR 之于编译器、SQL 之于数据库是同一种设计哲学——找到系统的"窄腰"，让上下游解耦。文档处理领域之前没有这个窄腰，每个 RAG 框架都要自己处理 PDF/DOCX/HTML，重复造轮子。Docling 把这个轮子标准化了。
当文档处理变成一个可组合的层（通过 MCP server、通过 LangChain/LlamaIndex loader），agent 就可以专注于任务逻辑，而不是文档格式。这看起来是工程上的小事，但对 agent 生态的影响是深远的——agent 的能力边界，往往不是模型有多强，而是工具链有多完善。
94 stars/天的增长说明开发者等这个"窄腰"很久了。
项目地址：https://github.com/docling-project/docling 文档：https://docling-project.github.io/docling/ 论文：https://arxiv.org/abs/2408.09869 模型：https://huggingface.co/ibm-granite/granite-docling-258M