67,088 颗星、平均每两天一个版本：Docling 正在把「喂给 AI 的文档」变成一条正经的工程管线

星眸·GitHub 观察者技术创作者 2026-09-20 70 阅读

67,088 颗星、平均每两天推一个版本：Docling 正在把”喂给 AI 的文档”变成一条正经的工程管线

过去一年，做 RAG 的人几乎都会卡在同一个地方：模型很聪明，但你手里的 PDF 一点都不聪明。表格被拆成乱序的文字，双栏排版被读成一行行断句，公式直接变成问号。于是大家开始到处找”文档解析”这条链路上的工具——而在这条链路上，目前星数最高、迭代最猛的，是 IBM 出身、现在归属 Linux Foundation 的 Docling（GitHub 仓库）。

它到底解决什么问题

一句话概括：Docling 把”人可以读、但机器读不懂”的文档，转换成”AI 可以直接吃”的结构化数据。官方定位写得很克制——”Get your documents ready for gen AI”——但支持面铺得很宽：PDF、DOCX、PPTX、XLSX、HTML、EPUB、LaTeX、邮件（EML/MSG）、图片（PNG/TIFF/JPEG），甚至连视频（MP4/AVI/MOV/MKV/WebM）、音频（WAV/MP3）、Apple Pages、以及金融领域专用的 XBRL 报告都在支持列表里（官方文档）。

它和普通 OCR 的关键差别在于：OCR 只在乎”像素变成字符”，而 Docling 在乎”版面变成结构”。它会做页面布局分析、阅读顺序还原、表格结构识别、代码块与公式识别、图像分类。这些能力归到一个统一的中间格式 DoclingDocument 里，再导出成 Markdown、HTML、JSON、DocTags 或 DocLang（论文 arXiv:2408.09869）。对下游的 LangChain、LlamaIndex、Crew AI、Haystack，官方都做了即插即用的集成。

数据与版本节奏

截至今天，仓库处在 67,088 颗星、4,833 个 Fork、935 个 open issues 的体量上。更值得注意的是版本节奏：v2.127.0（9 月 14 日）、v2.128.0（9 月 16 日）、v2.129.0（9 月 18 日）——几乎每两天就是一个 release（Releases 页）。

最近的几个版本能看出它的方向：

v2.129.0：重构了图表抽取引擎，允许更通用的引擎选项；给 S3 增加了环境凭据支持。
v2.128.0：加入 NVIDIA 的 Nemotron-Parse-2.0 作为可视化语言模型后端；把 docling-parse 后端里对 pypdfium 的依赖移除。
v2.127.0：新增 MHTML、RTF 输入支持。

把这几条连起来看，它在做三件事：扩输入格式、换更专业的解析后端、支持更多 VLM（视觉语言模型）。其中图表理解（柱状图、饼图、折线图转成表格或代码）是最近明确在推的新能力。

项目边界：它不是什么

得说清楚几条边界，避免踩坑：

它不生成答案。 Docling 只负责”把文档转成结构”，不做检索、不做问答、不做总结。它是 RAG 管线里最靠前的一环，不是完整方案。
它不是免维护的云服务。 默认本地执行——这既是它的卖点（数据不出内网、支持 air-gapped 环境），也意味着 GPU/CPU 开销得你自己扛。要当服务用，得自己起 docling-serve。
解析质量取决于文档类型。 干净的电子版 PDF 效果好；扫描件要走 OCR；手写、复杂化学结构、极端版面（比如多栏混排的学术期刊）仍是难点，官方把”复杂化学结构理解”列在 Coming soon 里。

真实使用门槛

Python 版本：docling 2.70.0 之后已放弃 Python 3.9，需要 Python 3.10+。这在老服务器上是个真实的坑。
安装：pip install docling 一行能装，但首次运行会拉取模型权重，网络不好的环境建议先预取（支持离线/内网预下载模型）。
硬件：纯 CPU 能跑，但批量解析 PDF 会明显慢；要跑 VLM 后端（比如 GraniteDocling 258M、Nemotron）最好有 GPU。
平台：macOS / Linux / Windows，x86_64 与 arm64 都支持。

快速上手是这样：

pip install docling
# CLI 直接转
docling my_report.pdf --to md

from docling.document_converter import DocumentConverter

conv = DocumentConverter()
result = conv.convert("my_report.pdf")
print(result.document.export_to_markdown())

如果要接 Agent，官方提供了 MCP server；要部署成 HTTP 服务，用 docling-serve。

适合谁，不适合谁

适合：

在做 RAG / 知识库，卡在”PDF 解析质量差”这一步的团队；
有合规或数据安全要求、必须本地/内网跑文档解析的场景；
需要批量处理报表、合同、专利（有 USPTO XML 支持）、技术文档的工程团队；
想要一个统一中间格式、不想为每种格式写一套解析代码的开发者。

不适合：

只想让 AI “读一下这个 PDF 回答个问题”的轻量需求——那用现成的聊天工具更省事；
完全没有 Python/运维能力、指望开箱即用 SaaS 的个人用户；
需要开箱即得问答、检索、Agent 编排整套能力的团队——Docling 只给你解析层。

下一步建议

如果你正准备接文档进 RAG，建议这么走：

先用 CLI 做一次基线测试：挑 20-30 个你业务里最”脏”的 PDF（双栏、表格多、扫描件），docling x.pdf --to md 跑一遍，人工看表格和阅读顺序还原得怎么样。这一步能直接判定它是否适合你。
对比 Unstructured / Marker：社区里已有针对 500 份企业 PDF 的三方精度对比（Ertas AI 基准），表格抽取是重点观测项，别只看总评。
锁定版本 + 预取模型：它的发布节奏很快，生产环境务必固定版本号；内网环境先按文档预下载模型权重。
想省事就用 docling-serve：不想在业务代码里塞解析逻辑，就把它当独立服务起起来，业务侧走 HTTP。

参考链接：

仓库：https://github.com/docling-project/docling
文档：https://docling-project.github.io/docling/
官网/部署说明：https://docling.ai/deployments
论文：https://arxiv.org/abs/2408.09869
Hugging Face 模型（GraniteDocling）：https://huggingface.co/ibm-granite/granite-docling-258M

评论区

0 条评论

登录后可评论。