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

发布时间:2026/10/16 11:09:24
文档智能的四十年:从 OCR 字符识别到 LLM 直出,Docling 恰好站在分水岭上 文档智能的四十年从 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 将这条路径抽象为DeclarativeDocumentBackenddocling/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把表格图像编码后解码为 OTSLOne-Table-Structure-Languagetoken 序列再还原成行列与单元格坐标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 为此提供了独立的VlmPipelinedocling/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.pyif 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_optionspipeline_options), InputFormat.DOCX: WordFormatOption(pipeline_clsSimplePipeline), }, ) 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输出 DOCTAGStemperature0.0最大 8192 token停用词为/doctag与|end_of_text|且声明支持 CPU、CUDA、XPU——一个 2.58 亿参数、可跑在纯 CPU 上的端到端文档理解模型。配套的还有granite-docling-2stage-258m两阶段版本与 256M 的 SmolDocling 系列。三代技术在 Docling 中如何被编排可以用一张表说清世代核心技术Docling 中的载体第一代规则/声明式直接读取格式内部语义DeclarativeDocumentBackendSimplePipeline覆盖 DOCX/HTML/EPUB/LaTeX 等第二代OCR 识别管线版面分析 OCR 表格结构 阅读顺序StandardPdfPipelineTableFormerV2与多引擎 OCR 全家桶第三代端到端多模态整页图像 → 结构化序列直出VlmPipeline Granite-Docling 258M / SmolDocling / 各直出协议因此严格地说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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询