做知识库抽取这几年PDF解析一直是我花了最多时间调教的一环。早先用的方案说白了都是“文字搬运工”把PDF里的字符抠出来按坐标拼回段落图片和表格只能另做处理。最让我没法忍受的是PDF里那些带跨行、跨页的表格抽出来的结果要么全部挤成一坨要么多列变一列交给下游做RAG也好、做结构化存储也好效果都一言难尽。直到我接触并系统用上Docling之后才发现把文档“读对”和“读出来”是两件完全不同的事。Docling是IBM开源的一个文档转换工具它做的不是简单的文本抽取而是把PDF、Word、PPT、Excel甚至图片中的版面结构——标题、段落、表格、图片、公式、阅读顺序——整体解析出来输出成结构化的Markdown或JSON。简单说它比传统解析工具多做了两件事一是识别版面结构二是还原阅读顺序。这个能力对做RAG知识库、文档结构化管理、批量转换这类场景来说价值非常大。这篇文章我会从核心机制、安装实操、输出格式取舍、踩坑记录、工具选型五个方面展开。不管你是做文档解析、知识库构建还是纯想把一批PDF批量转成Markdown里面都有可以直接参考的东西。1. 为什么我最终把Docling放进了文档解析管线先说说之前工具链的痛点不然你体会不到Docling解决了什么真问题。我早先用的是PyMuPDF加自研规则先用fitz把页面里的文本块取出来然后根据坐标算出块与块之间是同一段还是换段表格则基本靠正则硬猜边界。这个方案对一些版式规整的期刊论文勉强够用但遇到营销手册、政府公告、带双栏的学术文献就会频繁出问题。最常见的是栏目错乱左栏右栏的文本混在同一段里其次是表格列腿分叉表头跟单元格对不上抽出来之后根本没法回填到数据库里。后来我意识到文档解析这个事不能用“抠文字”的思路得用“看版式”的思路。这就需要一个模型先识别页面里哪些区域是标题、哪些是正文、哪些是表格、哪些是图片然后再按区域去解析内容。Docling的底层干的就是这样一件事先用一个布局分析模型对页面做区域分割再用表格结构模型把表格的行列关系还原出来最后按特定阅读顺序把文本组装起来。正因为Docling从设计之初就自带这个“先看版式再抠文字”的管线我才决定把它放进正式的解析流程里。它对比传统解析工具的差别可以这样理解老办法是把一页纸当成一堆随便摆放的文字块靠坐标猜关系Docling是先把一页纸当成一个包含标题、段落、图片、表格的版面再让模型把每个元素的边界和层级关系弄清楚。后面做知识库上传的时候这段结构化信息能省掉你一大半的清洗工作。另外要提一点Docling的输出不只有Markdown一种形态。它内部维护了一个叫DoclingDocument的对象模型里面记录了页面尺寸、文本元素类型、表格单元格坐标、图片位置这些信息。你既可以把完整结构导出成JSON也可以只导出成干净的Markdown这就给下游系统留了很大的弹性。如果你做RAG可以直接把JSON里的层级信息喂给分割策略如果想发布成文档Markdown就足够了。2. Docling核心机制布局分析、表格识别与OCR三段式这一节看名字可能有点偏理论但你理解了它的工作原理之后遇到具体问题就不容易慌因为你知道问题出在管线里的哪一环。2.1 布局分析它怎么知道标题、正文和表格的位置Docling在解析PDF时首先会对每个页面做一次布局分析这一步用的是基于深度学习的版面分割模型模型训练时依托的是DocLayNet数据集——IBM开源的文档布局标注集。这个模型会把页面里每一个视觉区块打上标签大致包括标题、正文、图片、表格、公式、页眉、页脚、列表项等类型并给出每个区块的边界框坐标。这一步的价值在于文本块不再是孤立的坐标点而是有了语义角色。比如页眉页脚如果能被识别出来你就可以在后续流程里选择跳过再比如公式区块被单独识别出来后你就不至于把公式符号混在正文里抽出来。对一篇双栏论文来说布局模型还承担了一个隐含任务决定阅读顺序。先读左上栏还是先读右上栏并不是简单按y坐标排序而是要理解栏目的物理边界。实际操作中布局分析的准确率基本决定了整条管线的上限。Docling使用的是深度学习模型而非传统规则所以它对之前靠规则无法处理的异形版面也要稳定得多。但模型也不是万能的后面我会专门提到一些它容易栽跟头的场景。2.2 表格识别TableFormer和规则方法的本质差异表格是整个文档解析里最麻烦的部分因为表格的信息不仅存在文字里还存在于行列的二维关系中。传统工具处理表格大都是把单元格文字提出来然后根据水平线和垂直线去猜测列边界。可现实中的表格经常不带完整的线框——比如用底纹分隔行、用缩进表示层级或者单元格合并、跨行跨列这些都会让线框派工具当场“瘫痪”。Docling里的表格结构识别走的是另一条路。它用的是Transformer结构的模型Google的TableFormer也经常在这个语境里被提到。这类模型的输入是表格区域里的视觉特征和文字特征输出是每个单元格的行号、列号以及跨行跨列信息。换句话说模型是把整个表格当成一幅图像和一个文本矩阵看而不是死板地追踪表格线。我在实测里感受最深的是对于带跨行合并的“总分总”类表格Docling的还原效果比PyMuPDF加规则高出一大截。Markdown输出时它会自动生成对应的行span和列span结构基本和原PDF一致。2.3 OCR不是必须但多数中文扫描件绕不开Docling对文本型PDF可以直接从自带的文本层读内容不需要OCR。但如果PDF本身是扫描件——没有文本层只有图片——你就必须让OCR介入。Docling把OCR作为管线中的一个可选后端来设计。你可以配置ocr开关也可以用不同的OCR引擎来跑文字识别。在这条管线里OCR识别的文字会被当成“页面上某区块内的文本”放回布局模型给出的框里所以即使整页是扫描图只要布局分析能分出标题和正文的区域OCR结果依然能保持版式结构。这一点非常关键因为很多独立的OCR工具只输出“文字流”不会保留标题、正文、表格的分层关系。就我个人经验来说中文扫描版PDF在Docling里需要把OCR模式打开而且要选对后端。关于不同OCR后端的差异我在第五节的踩坑部分会展开讲。3. 从安装到跑通第一个文档CLI和Python API实操谈到工具上手门槛往往是第一道坎。Docling的安装不算复杂Python环境准备好一条pip命令就能往里拉但模型下载和初次推理往往会卡住新手这里把整个流程完整走一遍。3.1 环境准备和初次模型下载Docling是基于Python的库建议单独建一个虚拟环境避免和项目里其他包产生依赖冲突。安装命令很直接pip install docling装好之后首次调用解析时会自动从线上拉取模型权重包括布局分析模型、表格结构模型以及你选择的OCR引擎模型。这几个模型加起来有好几百MB第一次跑会明显感觉卡了很久那不是程序死了而是在下载模型。为了不让后续解析频繁等待我建议第一次先用一个小文件跑一遍让模型全部落地到本地缓存之后再批量处理就顺了。如果你用GPUDocling会自动走CUDA加速CPU也能跑但速度会慢不少这个后面说。3.2 命令行模式一条命令完成转换Docling自带命令行工具装好包之后可以直接在终端里跑。最简单的用法是把单个PDF转成Markdowndocling input.pdf默认情况下输出文件会和源文件在同一目录下生成一个同名Markdown文件。如果你想指定输出目录可以加-o参数docling input.pdf -o ./output_dir命令行对批量转换也很友好可以一次传入多个文件docling file1.pdf file2.docx file3.pptx --to md -o ./output_dir这里注意Docling不止能处理PDFWord、PPT、Excel、图片这些格式它也能读。我日常用得最多的是PDF但偶尔会把Word报告直接丢给它转Markdown体验很顺。命令行里加--to参数可以指定输出格式除了md还支持json和html。3.3 Python API把解析能力嵌进你自己的流程如果你的需求不是一次性的转换而是要对接自己的系统用Python API会更灵活。核心用法其实就两行from docling.document_converter import DocumentConverter converter DocumentConverter() result converter.convert(input.pdf) doc result.documentconvert返回的结果里.document就是一个DoclingDocument对象。接下来你可以按需导出# 导出为Markdown文本 md_text doc.export_to_markdown() # 导出为完整结构的JSON json_data doc.export_to_dict()如果你在做一个批量处理程序我习惯的做法是逐文件convert然后立刻把Markdown和JSON都落盘后面要用哪种都方便。还需要说明的是convert方法支持传入本地路径也支持传入HTTP链接我试过直接解析线上PDF链接效果一样。另外和LangChain的集成也是现成的LangChain里有个DoclingLoader直接加载DoclingDocument并切分成Document块。如果你做RAG这一篇接一篇串起来很省事。4. 输出Markdown和JSON的取舍给下游喂什么数据最合适Docling的输出能力很强但“输出强”不等于“用得对”。很多人在这一步会踩坑把Markdown当万能格式到处喂或者把所有解析结果都存JSON结果下游处理起来反而变慢。这一节聊聊两种格式的真实差异以及我的取舍逻辑。4.1 Markdown的定位给人和大模型看从Docling导出的Markdown和传统PDF抽取工具给出的Markdown有个明显区别表格不再是碎掉的文本而是真正的Markdown表格语法标题层级会被还原成#级别图片会以占位符或引用形式保留列表也保持嵌套关系。这相当于把视觉版面变成了语义层次。如果你做RAG直接把这种Markdown喂给分割器效果会很好。因为语义层级已经天然存在标题和正文不会揉在一起表格也能作为整块内容进入向量库。实测下来召回时对“某个表格里的数值”这类问题回答准确率明显比文本流方案高。4.2 JSON的价值给系统和数据库用如果你要做的不是问答而是把文档结构化后入库那么JSON才是更完整的形态。export_to_dict()导出的JSON会包含页面信息、文本元素、表格单元格的坐标和行列归属甚至每个区块的边界框。这些信息足够你还原出一份接近原版式的数据结构。比如你要把解析后的文档录入知识管理数据库JSON里的表格行列信息可以直接映射成数据库表而Markdown里的表格就做不到这么细你还得额外写一个解析Markdown表格的模块。我的建议是面向人阅读、面向大模型生成用Markdown面向系统存储、面向程序消费用JSON。项目里最稳的做法是两种都导出因为体积都不大但下游可选择的空间就大了。4.3 批量处理时怎么组织输出避免文件名冲突批量处理时有个小麻烦Docling输出的文件名默认和源文件保持一致但如果你同时处理a.pdf和a.docxMercy覆盖风险就来了。我现在的做法是输出目录里按源文件扩展名再分一层或者在代码里拼一个带原格式前缀的新文件名out_path output_dir / f{stem}.md另一个经验是批量转换前先把文件按类型分好批次PDF一批、Word一批、图片一批。这样做最大的好处是如果某类文件触发了Bug你可以精准定位而不是整批全部失败。5. 实战中反复踩到的坑以及绕坑方案任何工具都有脾气Docling也不例外。我把它用在生产管线之后前后踩过不少坑挑几个有代表性的列出来给后来者省点时间。5.1 扫描版PDF默认不跑OCR抽出来是空文本最容易迷惑人的坑就在这里。Docling对“有文本层的PDF”默认不开启OCR它直接读文本层数据。但如果PDF是扫描版文本层压根不存在你又不主动开OCR它就只会返回图片区块信息Markdown里整页基本是空的。解决办法是在PipelineOptions里把OCR打开。在Python API里可以这么做from docling.document_converter import DocumentConverter, PipelineOptions options PipelineOptions(ocrTrue) converter DocumentConverter() result converter.convert(scan.pdf, optionsoptions)如果是命令行也有对应的参数控制OCR开关。这里提醒一下OCR打开之后运行时间会明显变长没有GPU的话一本几百页的扫描书会跑到你怀疑人生。5.2 中文PDF的OCR识别率不稳Docling默认接入的OCR后端对中文的支持不能说不好但肯定不如专门的国产OCR引擎。我拿一批中文扫描版PDF做测试部分字会识别错尤其是繁体、异体字以及表格里的窄体字。建议是如果你的扫描件是中文可以考虑切换OCR后端或者在Docling出结果后再用一个专门的中文OCR跑一遍关键字段做校验。如果你接受二段式处理还有一个思路先用Docling做版面分析和表格结构识别再把每个区块裁出来交给更专业的中文OCR识别。这种方案比整体跑Docling慢但准确率上限更高。5.3 表格复杂到一定程度结构识别会翻车Docling的表格识别虽然比传统工具强但它不是无敌的。遇到合并单元格特别多的“大乱表”或者表格里套着小表格输出结果偶尔会出现行列错位。更常见的场景是表格里只有一个单元格跨了多行表头被自动拆成了重复列。这类问题没有银弹。我现在的处理策略是表格识别结束后自动统计一下每个表格的单元格数量和行列跨度如果发现异常——比如单行跨度超过5列——就把这个表格标记出来走人工复核。Docling输出的JSON里带了坐标和行列信息这个校验逻辑写起来不算难。5.4 阅读顺序对双栏、页眉页脚依然有失灵案例Docling对阅读顺序的处理已经在向“按版面视觉流”靠拢了但双栏论文偶尔还是会乱序。特别是在左边栏底部和右边栏顶部有插图、公式栏插入的情况下模型容易把左右两栏的内容按z字形混合起来读导致段落断裂。解决思路是对这类论文我通常在做完Docling解析后先看一下输出的段落顺序是否正确如果发现乱序就用它JSON里的坐标数据做一次重排。坐标虽然不能完全代表语义顺序但配合区块类型能解决大多数乱序问题。另外页眉页脚有时候会混进正文。Docling的布局模型虽然能把页眉页脚识别成独立区块但转换成Markdown时这些区块有时仍会保留。如果你想彻底干净需要在导出后做一层后处理去掉页眉区域对应的文本行。没有现成参数能一键过滤是我比较遗憾的地方。6. 和其他工具对比后Docling适合什么场景最后聊一下工具选型。市面上的文档解析方案不少每个都有一批忠实用户但侧重点完全不一样。我只挑几个有代表性的做比较方便你判断Docling在哪类场景里是更优解。6.1 常见替代方案优缺点对照工具核心手段优势短板PyMuPDF规则坐标提取快、轻量、可控性强版面结构理解弱表格基本靠猜PaddleOCR / PP-StructureOCR版面分析中文识别强表格还原不错部署较重管线复杂度高Unstructured分区提取面向RAG上手快各种格式都接复杂表格和多栏处理一般Marker深度学习转Markdown输出干净适合直接喂LLM自托管队列和模型更新问题较多Docling深度学习版面表格识别结构化强JSON信息完整多格式统一速度不算顶级全流程定制门槛有这张表不是想论证Docling“全行业第一”而是想说明每个方案的取舍点。PyMuPDF胜在轻和快适合对结构要求不高的场景PaddleOCR胜在中文识别精度适合扫描版中文文档Docling胜在版式结构信息丰富尤其适合需要精确保留表格关系、做结构化入库或者喂RAG的场景。6.2 我现在的建议用法和场景判断如果你准备做RAG知识库Docling是我目前比较推荐的起点。原因有三个一是它能把表格作为整体结构送给向量化模型减少了“表格被撕碎”导致的召回偏差二是输出的JSON里有坐标和语义角色方便你在分割策略里按标题层级做切片三是它对Word、PPT、PDF一视同仁能统一你公司内部的文档处理管道。如果只是每天几十个PDF需要快速转Markdown做简单问答那用轻量工具完全够不需要动用深度学习管线。判断标准就是一句话你的下游是否需要“版面结构”这个信息。需要就上Docling不需要就选更轻的方案。另外补充一点Docling的模型更新迭代挺快的建议定期升级版本。我遇到过某个旧版本对特定版面解析效果特别差的情况升级之后直接缓解这类问题优先级很高。以我用了大半年的体感来说Docling已经成为我文档解析流程里一个固定环节。它不是没有毛病——速度一般、复杂版面偶尔会错、页眉页脚过滤缺失——但在“输出结构化信息”这个核心指标上它确实给项目带来了质的改变。如果你的工作也卡在“PDF抽出来结构稀烂”这个坎上值得花一个下午把Docling跑通再对照它输出的JSON看一页PDF你就明白我说的“先看版式再抠文字”到底好在哪了。
