【文档智能 & RAG】浅看开源的同质化的文档解析框架-Docling

前言

RAG火了之后，文档结构化解析这块的关注度直线上升，随之而来的一个问题是——这个赛道越来越同质化。各家方案看起来差不多，但真正落地时，能精准应对自己场景的实用工具其实并不多。

关于文档智能解析各个环节的技术细节，之前已经聊过不少。

今天换个角度，直接拿Docling这个PDF解析框架来拆一拆，看看它内部到底用了哪些技术。

方法

1. 布局分析模型
   ：Docling首先通过一个布局分析模型来干活，本质上是个目标检测器，专门预测页面上各种元素的边界框和类别。它的架构源自

   RT-DETR
   ，并在

   DocLayNet
   数据集上重新训练。推理跑在

   onnxruntime
   上。

   这里需要多说一句：版式分析非常吃

   场景数据
   。DocLayNet毕竟是英文为主的通用数据集，直接拿来处理常见的中文场景（比如研报、论文带段落信息那种细粒度布局）难免水土不服。而且RT-DETR模型参数偏大，如果换成之前开源的

   轻量版式分析模型
   ，效果会更好——那套模型专门针对中文细粒度检测做了优化，资源占用也友好很多。

2. 表格结构识别模型
   ：接下来是

   TableFormer
   ，专门用来搞表格的行列逻辑结构。输入一张表格图像，输出结构化的行列信息。推理依赖PyTorch。

3. OCR文字识别
   ：针对扫描件PDF这类没有内嵌文本的情况，Docling提供了可选的OCR支持。默认用的是

   EasyOCR
   引擎，而且会以216 dpi的高分辨率去处理页面图像，小字体细节也能抓得住。

4. 处理管道
   ：整体流程是线性的——按顺序一篇文档一篇文档地处理。每个文档先由PDF后端解析，拿到程序化文本标记，同时渲染出每页的位图。然后标准模型管道逐页提取布局和表格结构。最后把所有页面的结果汇总到一起，经过后处理阶段来

   增强元数据、检测文档语言、推断阅读顺序
   ，最终组装成一个可序列化为JSON或Markdown的类型化文档对象。

结果

• 处理速度
  ：在MacBook Pro M3 Max上，4线程时方案耗时177秒，吞吐量约每秒1.27页，峰值内存6.20 GB；16线程时耗时167秒，吞吐量约每秒1.34页（峰值内存未记录）。

• OCR性能
  ：默认高分辨率OCR速度偏慢，每页超过30秒。

• 资源效率
  ：在Intel Xeon E5-2690上，4线程时耗时375秒，吞吐量每秒0.60页；16线程时耗时244秒，吞吐量每秒0.92页，峰值内存6.16 GB。

总结

文档智能解析现在确实同质化严重，但真正能解决实际场景问题的工具少之又少。不过Docling在工程优化上有些值得参考的地方，比如多线程处理、流水线设计等。完全可以结合其他开源或自研的轻量小模型来做替换，打造一套真正属于自己的文档解析工具。