从第一次做RAG知识库被PDF里的表格折磨到怀疑人生到后来把Docling当成本地文档解析管线的主力工具我中间试过不少方案。Docling是IBM开源的一套文档解析工具链核心价值在于把PDF、DOCX、PPTX这些非结构化文档转换成带完整结构信息的中间表示再导出成Markdown、JSON、HTML这些下游好用的格式。它不是一个简单的文本抽取库而是整合了布局分析、表格识别、OCR、阅读顺序还原的完整管线尤其适合做RAG知识库预处理、合同审阅、财报抽取这类场景。这篇文章我不打算写成官方文档的复述而是把我从零跑通到实际接入RAG管线的完整过程、关键参数选择、底层原理以及踩过的坑一次性讲清楚给正在选型文档解析工具的同学一份能直接参考的实战笔记。1. 为什么我被PDF解析反复折磨先从RAG场景痛点说起先说说我最初的需求。当时在做一个面向企业内部的文档问答系统输入是几十份几百页的PDF有扫描版合同、有带复杂表格的财报、有双栏排版的论文。最初用简单的文本抽取库结果惨不忍睹表格里的数字全乱了、双栏文章的阅读顺序错乱、扫描件直接抽不出文字。我意识到RAG系统检索质量的上限其实取决于文档解析这一步把结构保住了多少。文本抽取库之所以不行是因为它只做一件事把页面上的字符按物理顺序抠出来。但文档是有结构的表格有行和列标题和正文有层级图片和文字有交叉关系。如果解析阶段把这些结构信息丢掉后面无论Embedding模型多强、向量检索多快拿到的都是“半残”的内容。Docling的设计思路刚好是反过来它先做版面分析识别出页面上的每个区域标题、正文、表格、图片、页眉页脚再对每个区域用专门的模型处理最后把结果组装成一个结构化文档对象。另一个痛点是格式碎片化。前期调研时我列过一张工具清单PyMuPDF擅长抽取文本和坐标但表格结构要自己写逻辑复原Camelot处理规整表格很强但面对复杂边框和合并单元格就吃力Tesseract OCR倒是能识别扫描件但只有纯文本没有版面概念。每个工具都只解决一个环节我需要自己拼装管线还得处理各种边界情况。Docling的吸引人之处在于它把“PDF到结构化文档”整条链路都封装好了CLI一行命令或者Python三行代码就能跑通背后是IBM Research的DocLayNet布局模型和TableFormer表格结构模型边界情况比一堆散装工具拼出来的方案稳得多。先用一个真实例子说明差异。同样一份带合并单元格的三栏财报PDFPyMuPDF抽取出来是所有文字按行排列表格行列关系完全丢失表格里的数值和表头根本对不上而Docling经过布局检测和TableFormer表格结构还原之后能拿到每个单元格的行列坐标、合并范围、表头关系导出成Markdown后是一张结构完整、在浏览器里能正常渲染的表格。就冲这一点Docling就值得被当成RAG预处理链路中的核心组件。2. Docling的核心能力拆解从文件到结构化文档的完整管线Docling处理一份文档的完整流程我把它拆成五个环节输入解析、布局分析、内容识别、结构组装、导出序列化。这套管线设计才是它区别于普通抽取库的本质所在。2.1 输入解析不止PDF还有DOCX和PPTX很多文档解析工具只支持PDFDocling原生支持PDF、DOCX、PPTX、XLSX和图片。PDF走专门的解析后端支持数字原生PDF和扫描版PDFDOCX和PPTX则绕开渲染步骤直接读取Office文档内部的结构信息因为Office文档本身就有段落、表格、标题这些语义标记解析的准确率反而比PDF更高。我目前的版本里PDF后端是可插拔设计的默认是pypdf实现同时也保留了其他PDF处理库的接口。这意味着如果遇到某些加密或特殊编码的PDF需要额外处理可以替换成更合适的后端而不需要改上层逻辑。对于图片输入Docling会先把图片当作一个完整的页面输入布局模型扫描版PDF则是把页面渲染成图片后再走同一套视觉识别链路。2.2 布局分析与OCRDocLayNet模型和它的替代逻辑布局分析是Docling最有含金量的环节。每个页面会被送入DocLayNet——一个基于目标检测思路训练的深度学习模型在IBM内部标注的大量文档数据集上训练而来。它能识别出页面上每个区域的类别和边界框类别包括标题、正文文本、表格、图片、公式、页眉、页脚、页码、侧栏等十几种。这一步就解决了“双栏文档顺序错乱”的问题模型先定位每个文字块的位置后续再按阅读顺序重排。扫描版PDF没得说必须走OCR。Docling的OCR能力是可配置的用于识别图片或扫描页中的文字内容。我在实际使用中普通清晰扫描件效果足够但如果原稿特别模糊或者有复杂排版OCR结果的准确性会下降这一点后面避坑部分详细展开。OCR环节有个很重要的参数OCR引擎选择。Docling支持EasyOCR和Tesseract两种后端我在CPU环境下测下来EasyOCR的识别效果略好但速度慢Tesseract在速度和资源占用上更均衡。选择哪个取决于你的机器配置和文档质量没有绝对的最佳答案。2.3 表格结构还原TableFormer是如何工作的表格识别是Docling最值得说的能力。布局模型只负责找到“这里有一张表格”但表格里面的行列结构、合并单元格、表头关系需要专门的模型来完成这就是TableFormer的职责。TableFormer会把表格区域图像编码成特征序列然后预测每个单元格的相对位置、行索引、列索引、合并关系最终恢复出完整的二维表格结构。这个模型解决了我之前遇到过的一个大难题无边线表格。很多工具依赖表格的边框线来判断行列边界遇到没有边框的表格就废了。TableFormer不依赖视觉线它基于内容特征学习单元格边界所以即使是无边框表格也能还原出相对合理的结构。这个能力导出成Markdown之后就是一个能正常渲染的Markdown表格这在RAG知识库里的价值极高——表格内容一旦变成结构化Markdown切块的时候可以按行按列切检索的时候Embedding才能把行列关系编码进去。2.4 阅读顺序重建与DoclingDocument统一表示识别出所有区域之后还有一个非常关键但又容易被忽略的问题怎么确定这些区域的阅读顺序Docling通过布局阅读顺序分析来完成重排让双栏文档的正文按从左到右、从上到下的正确逻辑顺序输出而不是按物理位置顺序输出。这一步对RAG切块的语义连贯性影响很大。所有解析结果最后都会被组装进一个统一的数据结构DoclingDocument。它是一棵由类型化节点组成的树状结构节点类型包括文档、章节标题、段落、表格、列表、图片、公式等。这么设计的核心好处是不管输入是PDF还是DOCX还是扫描图片下游拿到的都是同一种结构导出逻辑、切块逻辑、检索逻辑都不需要针对格式写分支。2.5 导出序列化Markdown、JSON、HTML三种主流输出对比DoclingDocument作为中间表示可以导出成多种格式。我实际使用中导出过Markdown、JSON和HTML各有各的用途。Markdown是最常用的RAG输入格式轻量、可读性好、LLM理解成本低表格和代码块都有标准语法。JSON保留了最完整的结构信息包括节点类型、层级关系、边界框坐标适合做精细的文档分析或自定义切块逻辑。HTML则适合需要保真渲染的场景比如网页端文档预览。我自己的选择策略是RAG知识库的正文存储用Markdown因为切块、Embedding、LLM生成都方便如果要做文档结构化分析和信息抽取保留JSON这份原始结构结果因为Markdown毕竟还是有信息损失。3. 环境准备与快速上手三种跑通方式由浅入深Docling的上手成本比我预想的低很多安装就是一条pip命令的事。但想要顺利把整条管线跑起来还是有几个环境细节需要提前处理好我把从简单到复杂的三种使用方式依次介绍一下。3.1 安装环节的两个关键选择Python版本和依赖包安装命令很简单pip install docling看起来一行搞定但有两个坑要先说明。第一个是Python版本Docling对Python版本有要求建议直接用3.10及以上版本旧版本可能在依赖解析阶段报错。第二个是依赖包的安装顺序docling会拉取torch、transformers等一堆深度学习依赖体积比较大第一次安装建议用虚拟环境隔离避免污染其他项目的依赖。如果你想用OCR功能需要额外安装对应的OCR引擎依赖。Docling对OCR模块进行了抽象EasyOCR和Tesseract需要你按自己的偏好安装。我用Tesseract的时候装的是系统级依赖EasyOCR则直接用pip安装即可。如果你不想折腾OCR跑纯数字版PDF默认依赖就足够了。3.2 命令行走一遍最快验证解析效果的方式安装完成后最快验证效果的方式是命令行。进到存放PDF的目录执行docling ./input/your.pdf --to md --output ./output/首次运行时Docling会从模型仓库下载DocLayNet和TableFormer的权重文件需要联网等待一段时间之后会用本地缓存。执行完成后在输出目录里就能看到同名Markdown文件打开对比一下PDF原文和导出的Markdown就能直观感受到结构保留效果。命令行的参数也很丰富。我用得比较多的是--to指定导出格式可以传md、json、html也可以传多个值一次性生成多种格式的导出结果--from指定输入格式处理图片时传image--ocr强制启用OCR--abort-on-error在遇到解析失败时直接退出方便在批量处理时定位问题文件。3.3 Python集成三行代码接入自定义管线命令行适合验证效果但真正的生产链路一定是要用Python API集成的。最精简的调用方式是这样的from docling.document_converter import DocumentConverter converter DocumentConverter() result converter.convert(input.pdf) doc result.document markdown_content doc.export_to_markdown()convert方法把输入路径解析成文档返回的结果对象里有两个核心字段document是解析后的DoclingDocument结构status是转换状态。转换失败时状态字段会记录具体的错误原因方便排查。拿到document对象之后可以根据下游用途灵活处理。最简单的是直接export_to_markdown()拿字符串如果要做自定义切块就遍历文档树把段落、表格、标题分别提取出来按自己的逻辑组织切块粒度。我在实际项目里就是这么做的遍历文档树标题和大纲作为切块的元数据表格单独切块并保留标题上下文正文按段落聚合切块再统一交给Embedding接口。4. 深层机理DoclingDocument如何解决“格式再表达”难题如果你只用CLI把PDF转成Markdown其实已经够用大多数场景了。但Docling真正的设计精华在DoclingDocument这个中间表示层理解了它你才能在复杂场景下发挥出这个工具的完整价值。4.1 类型化树状结构的设计逻辑DoclingDocument不是简单的文本流而是一棵类型化节点树。每个节点都有明确的类型文档根节点、章节级别节点、段落节点、表格节点、列表节点、图片节点、公式节点。节点之间有父子关系和兄弟关系比如一个章节标题节点下面是若干个段段落节点和一个表格节点。为什么要这样设计直接一点说RAG切块的时候需要知道哪些内容属于同一个语义单元哪些内容有层级关系。纯文本拿不到这些信息而一棵类型化树能让切块逻辑变得非常清晰——我可以按照文档树的层级决定哪些内容聚合成一个块哪些内容需要单独成块哪些内容可以作为上下文的元数据附加到切块上。这在纯文本抽取方案里是很难做到的。举个具体例子。我处理一份产品说明书时文档里有一个“技术参数”表格下面几段是对表格里某些参数的解释说明。如果按纯文本切块表格内容和解释段落可能被切成两个独立的块检索“某参数含义”时可能会漏掉表格里对应的数值。但基于DoclingDocument我可以在遍历时识别“表格节点之后的段落节点共同属于同一个章节”把表格和解释段落组合成一个完整的切块检索效果明显提升。4.2 元数据与标签体系切块策略的“情报来源”DoclingDocument为每个节点保留了丰富的元数据包括但不限于页面位置信息边界框坐标、所属页码、区域类别标签、文本块的置信度。这些元数据在精细化的文档处理任务里非常有用。以我的经验最有价值的元数据组合是“页码区域类别置信度”。页码在RAG场景里对应引用溯源回答问题时能定位到原文出处区域类别让切块逻辑具备语义感知能力例如可以把注释、页眉页脚、页码这些非正文内容直接过滤掉避免干扰检索置信度则能识别哪些区域可能解析不准确后续可以做二次复核或人工介入。我在实际处理中做过一个过滤规则区域类别是页眉页脚或页码的节点直接丢弃置信度低于阈值的文本块单独记录到一个“待复核”队列不直接进RAG知识库。这套策略让知识库的检索噪声明显降低因为以前OCR误识别的文字片段会作为噪声进入向量库现在能在入口处拦截掉相当一部分。4.3 从文档树到Markdown导出过程中的信息取舍Docling导出的Markdown并不是简单地把节点内容拼接起来而是遵循了一套还原逻辑。标题节点对应Markdown的#/##层级段落对应普通文本行表格节点生成标准Markdown表格列表节点生成有序或无序列表图片节点保存为外部引用。这些看起来不复杂但有一个细节值得注意表格导出为Markdown时会进行结构简化。TableFormer还原出的合并单元格、行跨度、列跨度这些复杂结构在Markdown表格语法里没有对应的原生表达所以导出时会退化为重复单元格内容或拆分单元格。如果需要对表格做非常精细的还原分析建议用JSON格式导出Markdown适合给LLM和通用场景使用。也正是因为如此我通常在RAG管线中保留两份导出结果Markdown用于Embedding入库JSON用于结构分析、自定义切块和精确引用。这种“双轨制”策略虽然存储开销多一点但在检索效果和可追溯性上的收益远大于成本。5. 实战配置与API详解一次性讲清CLI参数和Python集成前面介绍了基本用法这一节我把实际项目中用到的详细配置和API能力展开讲。Docling的配置体系是以JSON文件为核心的CLI参数和Python API最终都会转化成配置对象理解了配置结构你就掌握了这个工具的“控制面板”。5.1 CLI参数实战从单文件到批量处理的完整指令先从命令行最常用的操作说起逐个演示参数组合和适用场景。单文件转Markdowndocling ./input/report.pdf --to md --output ./output/批量处理时输入路径直接传目录Docling会递归处理目录中的所有支持格式文件docling ./input/ --to md json --output ./output/ --abort-on-error上面的指令一次性导出Markdown和JSON两种格式。我强烈建议在批量导出时加上--abort-on-error这样遇到解析失败的文件会直接报错退出而不会生成一堆只有部分内容的残缺文件。根据错误信息里记录的文件路径单独处理问题文件比事后逐份检查输出结果高效得多。对于扫描版PDF需要显式启用OCRdocling ./scan_files/ --to md --ocr --output ./output/OCR开关还有细分选项比如要强制对每一页都执行OCR、即使页面包含文本层docling ./mixed_files/ --to md --ocr --ocr-option force --output ./output/使用该参数前最好确认自己确实需要强制OCR否则会增加处理耗时而且可能会丢失原有文本层的排版精度。默认情况下Docling会比较聪明地判断如果页面已经有文本层就不走OCR扫描版页面则自动走OCR。我第一次踩的坑就是以为必须手动开启OCR才能处理扫描版后来发现默认配置对扫描PDF已经能自动识别手动开OCR反而会多消耗不少时间和计算资源。5.2 Python API的核心对象DocumentConverter与转换选项Python侧的核心入口是DocumentConverter对象。在最新的版本中Docling引入了DocumentConverterFactory来创建转换器同时还提供一个便捷的转换接口DoclingConverter用法更简洁。但无论用哪种方式核心思路是实例化转换器调用convert方法传入文件路径或文件对象得到结果。from docling.document_converter import DocumentConverter converter DocumentConverter() result converter.convert(input.docx) if result.status.is_success(): print(result.document.export_to_markdown())convert方法支持多种输入本地文件路径、URL、文件对象。URL方式可以远程拉取文档进行解析这个在自动化处理网络来源文件时很方便。转换选项控制着解析流程的关键行为。比较核心的几个配置选项包括OCR开关及引擎选择、模型选项设置、输出格式选项。以OCR为例选项里可以指定OCR引擎类型、设置每页OCR的详细程度等。批量处理时我通常用配置对象的方式统一管理而不是在每个调用点散落一堆魔法参数。5.3 分页处理与大批量文档的工程化建议处理长文档时Docling提供了分页控制能力。你可以指定只处理部分页面result converter.convert(large.pdf, page_numbers[1, 2, 3, 10])这个特性在调试时特别有用。比如解析一份100页的报告但发现第87页的表格有问题不需要每次调试都全量解析整个文件只解析那一页就行大大缩短调试反馈周期。大批量处理时我总结经验是三条并行化、缓存、断点续跑。Docling的转换是计算密集型操作特别是在启用OCR时CPU占用很高多进程并行处理能显著提升吞吐。缓存方面模型权重文件首次下载后要确认缓存目录是否正常避免每次跑都重新下载。断点续跑方面批量解析时建议逐文件记录处理状态某个文件失败了不要中断整个批次最后统一处理失败清单中的文件。5.4 表格与图片选项解析深度调优Docling在表格处理上有独立的配置维度。默认情况下TableFormer会对检测到的表格进行结构还原但如果文档只有简单表格可以关闭精细的表格结构分析只做表格检测节省计算时间。反之如果表格极其复杂有大量合并单元格和跨行内容建议保留完整的TableFormer还原流程。图片处理方面默认行为是保存图片引用不会把图片内容做额外分析。对于扫描版PDFOCR引擎识别出来的文本会被写入对应位置的文本节点对于包含大量信息图的文档Docling当前的策略还是以文本为中心的图片内容本身不会做深度视觉理解。这点需要明确预期Docling解决的是“版面和文本结构”问题不是“图片内容理解”问题。5.5 转换结果对象与错误排查从status到document转换结果对象里承载了所有需要的信息。核心字段是status和document。status是一个枚举值表示转换是否成功。document就是DoclingDocument对象。如果你要检查转换过程中OCR引擎是否正常工作、模型推理是否顺利完成可以查看状态对象中的详细输出信息。我自己在项目里会保留一份“转换日志”记录每个文件的处理时长、是否触发OCR、导出的格式列表、是否有页面解析失败。这些统计信息对于优化管线和发现数据质量问题非常有帮助不只是排错时才看。6. 踩坑记录模型下载、OCR效果与性能调优的真实经历这一节记录我实际使用Docling时撞过的墙以及最后的解决方案。如果只看官方文档这些坑大概率要自己重踩一遍。6.1 首次运行卡在模型下载缓存管理与离线部署方案第一次运行docling命令时终端会输出一段下载进度信息下载DocLayNet和TableFormer的权重文件。这个下载过程有几个常见问题网络环境不稳定导致下载中断默认模型仓库连接超时下载过程中途取消后缓存目录里留下半成品文件导致后续再跑直接报错。我在第一次跑通时也遇到了模型下载超时的问题最后改成手动下载权重文件并放到指定缓存目录的方式解决了网络不稳定的问题。不同版本的Docling使用不同的模型缓存目录具体路径可以参考对应版本的文档通常位于用户目录下的缓存目录中。建议第一次运行之前先确认权重文件能否正常下载再开始处理正式文档。如果跑得很慢优先排查模型下载。离线部署的情况更要提前准备好。Docker部署场景下把模型权重文件和代码一起打进镜像网络不通的内网环境才能正常使用。6.2 OCR结果差强人意的几种情况清晰度、语种与阈值调整OCR效果有几个容易被低估的影响因素。第一个是图片清晰度。Docling内部的OCR流程对低分辨率图像比较敏感过小的字体、被压缩严重的图片识别率会明显下降。我处理过一批微信传阅的合同拍照件文字边缘严重模糊OCR结果里出现了大量同音错别字这种情况换什么引擎都很难根治只能在上游尽量获取清晰原始文件。第二个是语种混合问题。中文文档里出现英文专有名词、数字、公式时OCR引擎需要额外的语种参数配置才能保持准确度。Docling的OCR选项里可以指定语言集合比如中英文混排的场景配置中英文语言支持。如果不配置默认语言模型遇到非常规字符组合时可能出现识别偏差。第三个容易被忽略的是阈值设置。OCR本身是一个概率输出Docling在把OCR结果写入文档树时会应用置信度阈值低于阈值的文本会被丢弃或标记。阈值设得太高会把一些低清晰度但内容正确的文本丢掉设得太低又会有大量误识别文本进入知识库。我在实际项目中找到一个相对合理的阈值既能拦掉大部分噪声又不会误伤有效文本。这个值需要根据自己的文档集做标注采样调优才能定下来没有万能设定。6.3 长文档处理的内存波动与分批解析策略处理超长文档几百页的扫描版PDF时我遇到过一次内存占用持续高位波动的情况。原因在于Docling会把文档页面的图像特征、OCR结果、布局检测结果同时保存在内存中页面越多中间表示占用的内存越高。再加上PyTorch模型推理本身有显存的额外开销资源占用很容易失控。我的解决方案是分批解析。先在PDF层面做页面切分比如每50页一个任务逐个交给Docling处理再把各批次的DoclingDocument合并。虽然合并逻辑需要自己实现但内存可控性有很大提升。如果只是做RAG预处理分批导出Markdown再合并文本也是一个可接受的简化方案。不过也要提醒一句不是所有场景都适合分页处理。跨页表格的识别和合并单元格的行跨页边界如果被硬切到不同批次表格结构可能会被破坏。遇到这种文档建议适当调大每批页数甚至整份处理尽量避免破坏跨页内容。6.4 下游消费端的格式兼容Markdown渲染器的差异Docling导出的Markdown表格在不同渲染器里的展示效果有差异。GitHub的Markdown渲染器对表格的宽容度较高表格语法稍微不规范也能渲染有些LLM工具链对复杂的Markdown表格处理能力较弱会导致解析错乱。这个问题的应对思路是进入LLM之前做一次格式清洗。我写过一个简单的规则脚本把Markdown表格中的冗余空格去除、统一分隔行格式、处理特殊情况下的单元格内容。稳定使用一段时间后LLM对表格内容的理解准确度提升了不少。这条经验说明了一个更普适的道理解析工具输出的结果不一定能直接作为另一套系统的输入中间加一层适配器往往是工程实现里的必要步骤。7. 生态位思考Docling与Marker、Unstructured怎么选聊完实操细节最后把Docling放进文档解析工具坐标系里做个横向对比。市面上好用且活跃的开源工具不止Docling一个Marker、Unstructured、以及更专注表格结构的Camelot各有各的适用边界。我根据自己的实际使用经验整理了一个选型对照逻辑。7.1 Marker另一条技术路线的代表Marker是另一个广受好评的PDF转Markdown工具底层也用深度学习模型做版面分析和OCR。它与Docling有相同的目标但技术路线有差异Marker更侧重输出高质量的Markdown整个管线是围绕“PDF直接转Markdown”这个目标设计的Docling则多做了一步构建了DoclingDocument中间表示层输出格式更灵活。实际使用中我的感受是如果只需把PDF变成Markdown跑RAGMarker的默认输出效果很好尤其在减少格式错乱方面有不错表现但如果还需要做精细结构分析、按需定制输出格式、把解析能力和自己的代码管线深度集成Docling的中间表示层带来的自由度是Marker不具备的。7.2 Unstructured面向RAG生态的一站式方案Unstructured主打的是从各种格式文档中抽取结构化内容它提供了包括分区、清理、切块、Embedding在内的一整套工具链与LangChain生态结合紧密。它的优势在于围绕RAG场景的周边设施更完整。Docling更聚焦“文档解析”这个环节在版面结构识别和表格还原的精度上有独特优势。选型时我的建议是如果你已经在LangChain生态里追求快速跑通Unstructured的学习曲线更平滑但如果你对文档解析质量有更精细的要求尤其是表格密集型文档比较多Docling的解析效果更值得配置。两者也可以并行使用用Docling做解析把导出的结构化结果交给Unstructured或自研的切块链路做后续处理。7.3 表格场景再细化Camelot与Docling的搭配使用Camelot是表格抽取的专项工具对边框规整、格式统一的PDF表格有高精度的抽取能力。但它的局限也很明显依赖PDF中的文本层扫描版PDF要先OCR对复杂布局、无边框表格的鲁棒性不足。Docling把表格检测和结构还原纳入全流程天然处理扫描件和复杂表格。但在某些极端规整的表格上Docling的表格单元格内容精度不一定比Camelot纯视觉算法高。我实践中的组合方式是先用Docling做全文档解析得到整体结构和Markdown如果某个表格在报告中地位重要且结构复杂再对表格所在页面区域用Camelot做精细抽取两套结果对比后取更可靠的一份。7.4 表格与图片选项解析深度调优最后说一说模型选型的思考。Docling自身的模型在通用性上已经不错但遇到特定领域文档时通用的版面模型不一定全是上限很高的比如科学论文的双栏排版、法律合同的条款嵌套、金融财报的多层表头。针对这些特殊版面可能需要在Docling基础上做模型微调或规则后处理。这已经属于进阶玩法一般情况下直接用默认模型配合少量后处理规则就能解决绝大多数问题。对我而言选解析工具的终极标准是两条一是结构保真度二是格式灵活性。Docling在两条上都给出了足够有说服力的答案。当然它也有短板比如较重的依赖、初次下载模型的网络问题、OCR对清晰度的敏感度。但综合来看在“文档解析”这个垂直环节上Docling是当前开源生态里最值得投入时间去掌握的工具之一。如果你正好在做RAG知识库、文档问答或信息抽取类的项目建议从一份带复杂表格的PDF开始跑一遍Docling的完整流程你大概率会和我一样有一种“以前白折腾了”的感觉。