文档智能的四十年：从 OCR 字符识别到 LLM 直出，Docling 恰好站在分水岭上

【免费下载链接】doclingGet your documents ready for gen AI项目地址: https://gitcode.com/GitHub_Trending/do/docling

把一份扫描件、一份排版混乱的 PDF 或一段音视频变成"AI 能读懂的结构化数据"，这件事人类已经做了四十年。上世纪 70 年代，OCR 只能把印刷字符一个一个抠出来；90 年代的版面分析开始关心"哪里是标题、哪里是表格"；2010 年代深度学习把版面与表格识别做成独立模型；而到 2024 年之后，一条新的路径出现了——一个几百兆参数的多模态小模型，看一眼整页图像，直接吐出带结构标签的文档内容。IBM 开源的 Docling 恰好横跨了这条演进的完整光谱：它既保留规则式与 OCR 式两代传统管线，又原生接入第三代"端到端多模态直出"（Granite-Docling 258M）。本文结合仓库源码，拆解这四十年三次范式转移，以及 Docling 为何正站在分水岭上。

一、三代演进：规则、OCR 与端到端多模态

第一代：规则与声明式解析

最早的文档数字化完全依赖规则：字体、缩进、模板位置都是"特征"，版面分析靠人工编写的启发式规则硬编码完成。这一代至今没有过时——对于 DOCX、HTML、EPUB 这类"结构可内读"的格式，解析根本不需要视觉模型，直接读取文件内部的语义树即可。

Docling 将这条路径抽象为DeclarativeDocumentBackend（docling/backend/abstract_backend.py）：它无需任何识别管线，就能"直接产出DoclingDocument"。对应的SimplePipeline甚至没有任何模型阶段，只做一次backend.convert()调用：

# docling/pipeline/simple_pipeline.py class SimplePipeline(ConvertPipeline): def _build_document(self, conv_res: ConversionResult) -> ConversionResult: # Instead of running a page-level pipeline to build up the document structure, # the backend is expected to be of type DeclarativeDocumentBackend, which can output # a DoclingDocument straight. conv_res.document = conv_res.input._backend.convert() return conv_res

这正是第一代思想的工程化延续：DOCX、XLSX、PPTX、HTML、EPUB、LaTeX、Apple Pages/Numbers/Keynote 等 20+ 格式走这条路，零推理成本、零延迟、精度由格式规范本身保证。

第二代：OCR 与"分而治之"的识别管线

真正棘手的是扫描件与复杂 PDF。这里 OCR 从"字符识别"升级为系统工程：先做版面分析，定位段落、表格、图片区域；再做 OCR 识别文字；再做表格结构还原；最后按阅读顺序组装。Docling 的默认 PDF 管线正是这条流水线的现代形态（docling/pipeline/standard_pdf_pipeline.py），阶段被编排为六个线程化节点：

# 阶段接线（节选） preprocess.add_output_queue(layout.input_queue) # PDF 解析 layout.add_output_queue(ocr.input_queue) # 版面预测 ocr.add_output_queue(layout_postprocess.input_queue) # OCR layout_postprocess.add_output_queue(table.input_queue) # 版面后处理 table.add_output_queue(assemble.input_queue) # 表格模型 assemble.add_output_queue(output_q) # 组装

其中表格结构模型是这套体系的招牌：TableStructureModelV2加载TableFormerV2，把表格图像编码后解码为 OTSL（One-Table-Structure-Language）token 序列，再还原成行列与单元格坐标（docling/models/stages/table_structure/table_structure_model_v2.py）。OCR 引擎则是一个可插拔全家桶：RapidOCR、EasyOCR、Tesseract、Nemotron-OCR、macOS Vision 乃至 KServe v2 远程推理均可挂载（docs/concepts/OCR.md），语言选择统一走 BCP-47 的iso:前缀规范化，保证不同引擎间配置可移植。

这一代的本质是"分而治之"：一个模型干一件小事，用工程编排把碎片拼回完整语义。优点是每个环节可解释、可替换、可评测；缺点是环节越多，误差累积越深，且每个环节都要单独训练和维护。

第三代：端到端多模态，"看图说话"直出结构

2024 年以来的范式转移在于：多模态大模型（VLM）把整页图像一次性看完，直接输出 Markdown、HTML 或带结构标签的序列，版面分析、OCR、表格识别、阅读顺序被"遗忘"进同一个模型参数里。Docling 为此提供了独立的VlmPipeline（docling/pipeline/vlm_pipeline.py），核心是一个运行时无关的VlmConvertModel：准备页面图像 → 拼接提示词 → 批量推理 → 把模型输出解析回DoclingDocument。

直出格式的覆盖面本身就是一个时代注脚。ResponseFormat枚举列出的协议包括 DOCTAGS、DOCLANG、MARKDOWN、HTML、DEEPSEEKOCR_MARKDOWN、MINERU2、NEMOTRON_PARSE_V2、DOTS_JSON、CHANDRA_HTML、UNLIMITED_OCR_MARKDOWN——几乎囊括了当前所有主流端到端文档模型的语言（docling/models/stages/vlm_convert/vlm_convert_model.py）：

if response_format == ResponseFormat.DOCTAGS: document = self._doctags_page_document(predicted_text, image) elif response_format == ResponseFormat.DOCLANG: document = self._doclang_page_document(conv_res, page, predicted_text) elif response_format == ResponseFormat.DEEPSEEKOCR_MARKDOWN: document = parse_deepseekocr_markdown(...) elif response_format == ResponseFormat.MINERU2: ...

以 DOCTAGS 为例，模型输出的带<doctag>标注的序列会被DoclingDocument.load_from_doctags反序列化为标准文档结构——VLM 直出与 Docling 的统一表示在此汇合。而驱动这一切的提示词，在 docling/datamodel/vlm_prompts.py 里只有朴素的一句话：

DOCLING_BASE_PAGE_PROMPT = "Convert this page to docling."

第三代把"四十年的领域知识"压缩进了模型权重与序列格式设计里。

二、Docling 与 Granite-Docling 各属于哪一代

答案藏在 Docling 的架构分层里：它不是一个"代"的产物，而是一个能同时容纳三代技术的统一框架。

DocumentConverter维护着"格式 → backend + pipeline"的映射（docling/document_converter.py）：每种输入格式可以指定各自的解析后端与管线。PDF 可以走第二代的多阶段识别管线，也可以切到第三代 VLM 管线；DOCX 走第一代的声明式路径；图像与扫描件则可以任选 OCR 或 VLM。三条路径的最终输出都是同一个DoclingDocument表示（docs/concepts/docling_document.md）——它以 Pydantic 类型承载文本、表格、图片、键值项，用body/furniture双树区分正文与页眉页脚，保留每个元素的空间坐标与溯源信息，并天然编码阅读顺序。

# docs/v2.md 中的典型用法 doc_converter = DocumentConverter( allowed_formats=[InputFormat.PDF, InputFormat.IMAGE, InputFormat.DOCX, ...], format_options={ InputFormat.PDF: PdfFormatOption(pipeline_options=pipeline_options), InputFormat.DOCX: WordFormatOption(pipeline_cls=SimplePipeline), }, ) result = doc_converter.convert("https://arxiv.org/pdf/2408.09869") print(result.document.export_to_markdown())

而 Granite-Docling 则是纯粹的第三代产物。在 docling/datamodel/vlm_model_specs.py 中可以看到它的完整规格：ibm-granite/granite-docling-258M，输出 DOCTAGS，temperature=0.0，最大 8192 token，停用词为</doctag>与<|end_of_text|>，且声明支持 CPU、CUDA、XPU——一个 2.58 亿参数、可跑在纯 CPU 上的端到端文档理解模型。配套的还有granite-docling-2stage-258m（两阶段版本）与 256M 的 SmolDocling 系列。

三代技术在 Docling 中如何被编排，可以用一张表说清：

因此严格地说：Docling 是三代技术的容器，Granite-Docling 是第三代范式的最强注脚。前者用统一文档模型消化了范式差异，后者用微型模型把整条识别链压成一个推理调用。

三、下一站：解析会被小模型彻底吞掉吗

社区对文档解析的讨论正滑向一个激进猜想：既然 258M 的模型都能端到端直出结构，那条由版面模型、OCR、表格模型拼装而成的第二代管线是不是该退休了？Docling 的代码给出了一个更冷静的答案：端到端小模型负责"看懂"，确定性工程负责"校准"，两者不是替代关系，而是合流关系。

证据之一是两阶段设计。granite-docling-2stage-258m把任务拆成"布局识别 + 内容直出"两步；同样，VlmConvertModel对 MinerU2 协议的处理是"先整页出布局，再按区域裁剪逐块识别，最后合并转录"（docling/models/stages/vlm_convert/vlm_convert_model.py 中的_predict_mineru2）——精度靠裁剪与多轮推理补偿，这本质上还是"分而治之"，只是算子从 CNN 换成了 VLM。

证据之二是"以 bbox 回源取文本"的混合策略。VlmPipeline里有一个force_backend_text选项：VLM 只负责预测元素的位置框，真实文本则用框去 PDF backend 里按坐标截取（extract_text_from_backend，见 docling/pipeline/vlm_pipeline.py）。这等于让"幻觉率最低的规则层"和"泛化最强的模型层"各干最擅长的事——第二代与第三代在此直接拼接。

所以"解析被小模型吞掉"的说法只对了一半。被吞掉的，是模型的堆叠方式——不再需要为版面、OCR、表格各训一个模型，参数预算集中在一个端到端模型里；没有被吞掉的，是工程化的对齐与校验——坐标回源、格式协议解析、统一文档表示、可插拔引擎，这些恰恰是 Docling 这类框架的价值所在。社区里的 OmniDocBench 评测、企业级 RAG 选型讨论（MinerU、Docling、Unstructured 横评）也印证了这一点：竞品拼的是"端到端能力"，Docling 拼的是"同一套框架内三条路线自由切换"。

更值得注意的是 Docling 的扩张方向：图表转表格/代码、代码与公式理解、音视频转录（ASR + 关键帧）、Apple 生态格式、XBRL 财报、MCP 服务与 docling-serve API 化部署，以及路线图上即将到来的元数据提取与复杂化学分子结构理解。这说明"文档智能"正在从"把版面读对"走向"把内容读懂"——而读懂这件事，恰好是第三代模型的强项，也是分水岭之后的真正战场。

站在 2026 年回望：四十年前我们教机器识别字符，十年前我们教机器识别版面，今天我们在教一个 258M 的模型"把这一页转成 docling"。Docling 的可贵之处在于它没有押注单一世代，而是让规则、OCR、端到端三种能力在同一套文档模型下并存、互备、可插拔。分水岭从来不是"旧技术消亡"的时刻，而是"新范式可用"的时刻——对文档智能而言，这个时刻已经到来。

【免费下载链接】doclingGet your documents ready for gen AI项目地址: https://gitcode.com/GitHub_Trending/do/docling