Docling：把多格式文档解析成可供生成式AI使用的结构化内容
一个把PDF、DOCX等文档整理成生成式AI可用结构的Python工具，区别是兼顾版面理解、本地运行和多框架集成。
GitHub docling-project/docling 更新 2026-09-20 分支 main 星标 67.1K 分叉 4.8K
Python 文档解析 DoclingDocument GraniteDocling 本地与隔离网络环境

🧭 决策指南

为什么现在热： 无法从材料判断。已知当日新增129颗星、总星67,053颗星并登上2026-09-20 daily Trending，但材料没有说明这次关注与v2.129.0、README新增格式或其他事件之间的因果关系。

适合，如果你

  • 你需要把PDF、DOCX、PPTX或XLSX转换成Markdown、HTML或lossless JSON。
    README的Features列出多格式解析和Markdown、HTML、lossless JSON导出。
  • 你的生成式AI应用使用LangChain、LlamaIndex、Crew AI或Haystack。
    README的Features列出这些agentic AI集成。
  • 文档包含扫描PDF、表格、公式或复杂版面，需要OCR和高级PDF理解。
    README的Features列出扫描PDF和图片OCR，以及版面、阅读顺序、表格结构和公式理解。
  • 敏感数据不能离开内部环境，且部署目标包含local或air-gapped环境。
    README的Features明确写有Local execution capabilities for sensitive data and air-gapped environments。

不适合，如果你

  • 运行环境只能使用Python 3.9或更低版本。
    README Quickstart说明Python 3.9支持已在docling 2.70.0移除，需要Python 3.10或更高版本。
  • 核心需求是标题、作者、参考文献、语言等metadata extraction。
    README的Coming soon将Metadata extraction列为尚未完成内容。
  • 核心需求是复杂化学结构理解，例如Molecular structures。
    README的Coming soon将Complex chemistry understanding列为尚未完成内容。
  • 项目必须依据公开材料中的准确率、延迟或内存数字选型。
    提供的README和发布信息没有给出PDF、OCR或VLM的这些数字。

前置条件

  • Python 3.10或更高版本；README写明Python 3.9支持已在docling 2.70.0移除。
  • 支持macOS、Linux和Windows，x86_64与arm64架构均可运行。
  • 安装命令为README Quickstart中的pip install docling。
  • 若使用GraniteDocling等VLM，需要按CLI的--pipeline vlm与--vlm-model granite_docling方式运行。

第一步命令（README 原文）

pip install docling

要注意

  • 使用GraniteDocling等模型时，代码MIT许可不等于模型许可；README要求查看原始包中的模型许可。
    README License章节：代码库使用MIT license，individual model usage需参考original packages的model licenses。
  • VLM CLI示例使用--pipeline vlm和--vlm-model granite_docling，不应按普通转换命令理解。
    README Quickstart的VLM命令明确包含这两个参数。
  • README的What's new列出视频、ODF、XBRL、邮件和EPUB解析，但未提供各格式限制或兼容性矩阵。
    README What's new章节只列出新增格式与能力，没有给出限制和兼容性数字。

材料未说明

  • {'text': 'README没有说明PDF、OCR、表格和VLM在真实数据上的准确率。', 'text_en': 'The README does not state accuracy for PDF, OCR, tables, or VLMs on real-world data.'}
  • {'text': 'README没有说明CPU、GPU、内存、磁盘或单文档处理时延要求。', 'text_en': 'The README does not state CPU, GPU, memory, disk, or per-document latency requirements.'}
  • {'text': 'README没有说明各解析格式的大小上限、失败行为和批处理能力。', 'text_en': 'The README does not state size limits, failure behavior, or batch-processing capability for each format.'}
  • {'text': 'README没有说明GraniteDocling及其他VLM的具体硬件要求和模型下载方式。', 'text_en': 'The README does not state the exact hardware requirements or model download process for GraniteDocling and other VLMs.'}

💡 深度解析

6
不适合 我负责 Python 归档系统中的专利和技术报告，PDF 里有公式、代码、表格和多栏版面；我需要后续审计时尽量追溯原始结构。应该把 Docling 的 Markdown 作为唯一归档格式吗？
适合读者： 负责专利和技术报告归档的 Python 信息管理工程师，需要保留版面、公式、代码和原始结构以便审计

不适合把 Markdown 作为唯一归档格式，因为 README 同时提供无损 JSON 和统一 DoclingDocument，而 Markdown 更偏向下游阅读与消费。

  • Advanced PDF understanding 覆盖版面、阅读顺序、表格、代码和公式，说明解析结果包含超出线性文本的结构信息。
  • Export formats 同时列出 Markdown、HTML、DocTags、DocLang 和 lossless JSON；其中 lossless JSON 更符合审计所需的结构保留目标。
  • 项目洞察明确指出 Markdown 不一定能无损表达原始版面信息，而复杂阅读顺序、浮动图片、跨页表格和脚注可能发生结构丢失或重排。
  • 因此 Markdown 可以作为检索、预览或交付副本，但不能在 README 证据范围内替代结构化中间结果。

README 没有说明无损 JSON 是否保存原始页坐标、字体、渲染信息或二进制附件，也没有承诺能精确复原原始页面，因此归档保真边界仍需确认。

  • Features：Advanced PDF understanding incl. page layout, reading order, table structure, code, formulas
  • Features：Various export formats ... including Markdown ... and lossless JSON
  • 项目洞察：Markdown 是便于下游消费的输出格式，但不一定能无损表达所有原始版面信息
  • 项目洞察：多栏 PDF、跨页表格、脚注、浮动图片和复杂阅读顺序可能被错误重排或出现结构丢失
  • Features：A unified, expressive DoclingDocument representation format
docling https://arxiv.org/pdf/2206.01062
材料未说明：README 未说明 lossless JSON 是否包含页坐标、字体、渲染信息和原始附件。；README 未承诺从任一导出格式精确重建原始 PDF 页面。；README 未说明专利 PDF 中特殊符号、化学结构和手写内容的支持程度。
视情况 我用 Python 维护扫描 PDF、PNG 和 TIFF 的数字化流水线，文档里有多栏版面、复杂表格和公式；我应该直接采用 Docling 的传统解析流水线，还是使用 OCR/VLM 能力？
适合读者： 维护包含扫描 PDF、PNG 和 TIFF 的文档数字化流水线、使用 Python 并需要处理复杂表格和多栏版面的数据工程师

视情况，Docling 覆盖扫描文档所需的 OCR 和视觉理解能力，但 README 没有保证复杂版面在所有文档上稳定正确。

  • Features 明确提供 extensive OCR support for scanned PDFs and images，适合处理 PNG、TIFF 以及图片型 PDF。
  • Advanced PDF understanding 覆盖 layout、reading order、table structure 和 formulas；此外还支持 GraniteDocling 等 Visual Language Models，可用于更复杂的视觉文档理解。
  • CLI 可显式选择 VLM pipeline，例如 docling --pipeline vlm --vlm-model granite_docling ...，说明传统流水线与 VLM 是可区分的处理路径。
  • 但项目洞察指出扫描质量、噪声、多栏 PDF、跨页表格和复杂阅读顺序都可能导致结果错误；VLM 还会增加算力、显存和模型依赖。

因此，普通数字 PDF 可先用常规路径，扫描件或版面困难文件才考虑 OCR/VLM；不过 README 未给出自动选择规则或准确率阈值。

  • Features：Extensive OCR support for scanned PDFs and images
  • Features：Advanced PDF understanding incl. page layout, reading order, table structure, code, formulas
  • Features：Support for several Visual Language Models, such as GraniteDocling
  • Quickstart：docling --pipeline vlm --vlm-model granite_docling https://arxiv.org/pdf/2206.01062
  • 项目洞察：扫描件质量、字体、倾斜、噪声和复杂背景会显著影响 OCR 结果
docling https://arxiv.org/pdf/2206.01062
材料未说明：README 未提供 OCR、表格识别、公式识别和阅读顺序的量化准确率。；README 未说明 GraniteDocling 在 CPU、GPU、显存和处理速度方面的最低要求。；README 未说明传统 pipeline 与 VLM pipeline 的自动回退机制。
适合 我正在用 Python 和 LangChain 构建 RAG 知识库，输入同时包含 PDF、DOCX、PPTX 和 XLSX；我希望保留表格、阅读顺序和文档结构，而不是只得到纯文本。Docling 适合做统一的预处理层吗？
适合读者： 使用 LangChain 构建企业 RAG 知识库、需要同时接入 PDF、DOCX、PPTX 和 XLSX 的 Python AI 应用开发者

适合，因为 Docling 的统一 DoclingDocument 表示可以把多种输入格式接到同一条下游处理链路中。

  • README 明确支持 PDF、DOCX、PPTX、XLSX 等多种格式，并提供 LangChain、LlamaIndex、Crew AI 和 Haystack 集成。
  • PDF 解析不仅输出文本，还覆盖页面布局、阅读顺序、表格结构、代码、公式和图像分类，适合在切分前保留语义层次。
  • 结果可导出为 Markdown、HTML、DocTags 及无损 JSON；RAG 快速消费可用 Markdown，需要保留更多结构时应评估无损 JSON。

但 README 没有承诺各格式的表格准确率、跨页表格处理效果或与具体 LangChain loader 的版本兼容性，因此仍需确认下游切分器如何读取 DoclingDocument 的层级和元数据。

  • Features：Parsing of multiple document formats including PDF, DOCX, PPTX, XLSX
  • Features：Advanced PDF understanding incl. page layout, reading order, table structure, code, formulas
  • Features：Plug-and-play integrations incl. LangChain, LlamaIndex, Crew AI & Haystack
  • Features：A unified, expressive DoclingDocument representation format
  • Features：Various export formats ... including Markdown ... and lossless JSON
pip install docling
材料未说明：README 未说明不同格式的表格、公式和跨页结构准确率。；README 未说明 LangChain 集成对应的具体版本和元数据映射方式。
适合 我用 Python 开发内部文档服务，希望多个客户端通过 API Server 调用解析，并让 Agent 通过 MCP 使用同一能力；Docling 能否直接作为服务层基础？
适合读者： 需要把文档解析能力提供给多个内部客户端的 Python 服务开发者，计划通过 API Server 或 MCP 接入 Agent

适合，Docling 已提供 API Server 和 MCP Server 入口，能够覆盖普通客户端调用与 Agent 工具调用两种接入方式。

  • README 的 Features 明确列出 “Connect to any agent using the MCP server”，可把解析能力暴露给支持 MCP 的 Agent。
  • 同一节还列出 “Run Docling as a service with the API server (docling-serve)”，说明项目提供服务化接口，而不是只能作为单机库调用。
  • CLI 和 Python API 也同时存在，便于在服务外复用相同的转换逻辑；输入支持本地文件或 URL，输出可选择 Markdown、HTML 或无损 JSON。
  • 但项目洞察指出，高并发、严格 SLA、队列、缓存、限流和故障恢复需要自行设计，Docling 本身不等于完整的企业级服务平台。

因此它适合作为解析引擎和接口基础，不应直接假定已经具备生产所需的认证、租户隔离、弹性扩缩和观测能力。

  • Features：Connect to any agent using the MCP server
  • Features：Run Docling as a service with the API server (docling-serve)
  • Quickstart：Python usage (recommended)
  • 项目洞察：提供 CLI、Python API、API Server 和 MCP Server
  • 项目洞察：高并发或严格 SLA 场景需要自行进行服务化、队列、缓存、限流和故障恢复设计
pip install docling
材料未说明：README 未说明 API Server 和 MCP Server 的认证、授权、租户隔离和限流能力。；README 未提供并发吞吐、延迟、最大文件大小或服务部署拓扑。；README 未说明 API Server 与 MCP Server 是否支持完全相同的格式和配置。
适合 我在 Python 内容迁移项目中同时处理 EML、MSG、MP4、WAV 和 MP3，希望统一转换后接入搜索索引。Docling 是否能覆盖这些输入，而不必为邮件、音频和视频分别维护解析器？
适合读者： 需要处理 EML、MSG、MP4、WAV 和 MP3 的 Python 内容迁移工程师，目标是把邮件与多媒体内容纳入统一搜索入口

适合用作统一入口，因为 README 已列出邮件、音频和视频解析能力，并支持面向内容处理的多种输出格式。

  • Features 列出邮件格式 EML、MSG，以及 WAV、MP3 和 WebVTT；What’s new 进一步列出 MP4、AVI、MOV、MKV 和 WebM 视频解析。
  • 音频支持基于 ASR 模型，视频解析可生成 ASR transcript 和 representative keyframes，因此不仅限于识别文件是否可读。
  • Docling 还支持 plain text、Markdown、HTML、WebVTT 和 lossless JSON 等输出，便于将不同来源接入统一的索引或归档流程。
  • 统一 DoclingDocument 表示可以减少上游针对每种格式分别编写转换逻辑。

不过音频、视频转录的说话人、时间戳、关键帧质量以及邮件附件和线程关系是否完整保留，README 没有说明；如果搜索依赖这些元数据，不能仅凭格式支持声明确认结果满足要求。

  • Features：Parsing of multiple document formats including WAV, MP3, WebVTT, email formats (EML, MSG)
  • What's new：Parsing of video files (MP4, AVI, MOV, MKV, and WebM) with an ASR transcript and representative keyframes
  • Features：Audio support with Automatic Speech Recognition (ASR) models
  • Features：Various export formats ... including Markdown, HTML, WebVTT ... and lossless JSON
  • Features：A unified, expressive DoclingDocument representation format
pip install docling
材料未说明：README 未说明音频转录是否提供说话人分离、词级时间戳或语言识别。；README 未说明视频关键帧的抽取策略、时间间隔和图像描述能力。；README 未说明 EML/MSG 的附件、邮件线程、HTML 正文和元数据保留范围。
视情况 我在隔离网络中用 Python 批量处理 XBRL 财务报告，不能把敏感文件上传到第三方云服务；我还需要把结果交给后续归档或检索流程。Docling 是否适合？
适合读者： 处理金融报告的 Python 数据工程师，需要解析 XBRL 文件并在隔离网络中完成本地处理

视情况，Docling 在格式覆盖和本地执行方面匹配需求，但隔离网络中的模型、依赖和运行资源准备会决定能否落地。

  • README 的 What’s new 明确加入了 XBRL 财务报告解析，说明该格式属于项目支持范围。
  • Features 声明支持 Local execution capabilities for sensitive data and air-gapped environments，符合不能外传文件的约束。
  • 输出包括 HTML、Markdown、DocTags 和 lossless JSON，可接入归档、搜索或二次处理；代码库本身采用 MIT license。
  • 但 README 也指出 individual model usage 要查看原始模型许可证，且初次运行可能需要模型和依赖。隔离环境需要预先准备安装包、模型缓存和容器或运行时资源。

README 没有给出 XBRL 覆盖的具体版本、复杂报表准确率、离线安装流程或批量吞吐数据，所以不能仅凭项目说明确认生产级财务字段完整性。

  • What's new：Parsing of XBRL (eXtensible Business Reporting Language) documents for financial reports
  • Features：Local execution capabilities for sensitive data and air-gapped environments
  • Features：Various export formats ... including ... lossless JSON
  • License：For individual model usage, please refer to the model licenses found in the original packages
  • Quickstart：Please use Python 3.10 or higher
pip install docling
材料未说明：README 未说明支持的 XBRL 版本、扩展 taxonomy 和复杂财务报表字段覆盖率。；README 未说明完全离线安装所需的模型清单、缓存路径和磁盘规模。；README 未提供 XBRL 批处理吞吐、内存占用或失败恢复指标。

✨ 核心亮点

  • 支持PDF、DOCX、PPTX、XLSX与EPUB等多格式解析
  • 高级PDF理解覆盖版面、阅读顺序、表格与公式
  • DoclingDocument统一表示并可导出Markdown和JSON
  • 支持LangChain、LlamaIndex、Haystack与Crew AI集成
  • Python 3.9支持已在docling 2.70.0移除

🔧 工程化

  • 用DocumentConverter从本地路径或URL转换文档并导出Markdown
  • CLI支持GraniteDocling等VLM处理PDF文档
  • 提供MCP server、docling-serve API server和简单CLI
  • OCR覆盖扫描PDF与图片，另支持音频ASR模型

⚠️ 风险

  • Python 3.9已不受支持，docling 2.70.0起需Python 3.10以上
  • MIT仅覆盖代码，GraniteDocling等模型需另查原始模型许可
  • 元数据提取和复杂化学结构理解仍列在Coming soon
  • README未提供PDF、OCR或VLM的准确率与资源消耗数字

👥 适合谁？

  • 需要把PDF、DOCX等资料接入生成式AI应用的Python团队
  • 使用LangChain、LlamaIndex、Crew AI或Haystack的Agent项目
  • 处理敏感文档且要求本地执行或air-gapped环境的团队
  • 需要扫描PDF OCR、表格结构或阅读顺序的文档管线