PDF 喂给 AI 之前要先过一道工序？Docling：把文档变成 RAG 能吃的格式

GitHub 仓库

docling-project/docling

总 Stars

★ 69,760

主要语言

Python

查看 GitHub 项目

结论先说：这是编辑精选的第三篇：Docling，IBM 出品的文档解析工具，6.9 万 stars、Python 编写、MIT 协议，10 月 28 日刚更新过。它的口号一句话就能说清：Get your documents ready for gen AI——把你的文档处理成生成式 AI 能直接用的样子。

是什么：一个把 PDF、Office 文档等解析成结构化数据的工具，输出 Markdown 或 JSON 这类 LLM 友好的格式，而不是让模型去啃原始排版。

能干嘛：做 RAG、知识库、Agent 语料准备时，先用它把一堆文档统一洗成干净的结构化文本；表格、标题层级、段落结构都能保留下来，后续切块、建索引都更稳。

适合谁：正在搭企业知识库、客服问答、研报检索的人；以及手里有一大堆 PDF、每次喂给模型都丢格式的开发者。

注意点：解析质量与文档类型强相关：规整的电子文档效果好，扫描件、复杂版式要先实测几份再批量跑；它是处理环节的一步，不是万能的问答系统，后面仍需要切块、向量化与检索策略配合。

直接把 PDF 丢给模型，和先用 Docling 处理，差别在哪？

差别在“结构还在不在”。直接丢 PDF，模型拿到的是顺序混乱的文本流，表格经常散架；先解析成 Markdown 或 JSON，标题、表格、段落关系都保留着，检索命中与回答准确率都会更好。这一步省不得，尤其在文档量大的时候。

站长点评：我选它是因为它是 RAG 链路里最容易被低估的一环：大家总在比模型、比向量库，却很少认真对待“文档怎么进来”。同类里 MinerU 更偏中文与复杂版式、Marker 更轻量，Docling 胜在输出干净、生态成熟。我的判断是：做知识库先拿它跑通十份真实文档，解析效果满意再谈后面的检索优化。