Granite Docling 文档解析小模型

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

大多数文档 AI 对页面使用大型通用模型。IBM 走了另一条路：一个只有 2.58 亿参数的小型模型，专门为一项工作构建——文档转换——它匹配或击败了大得多的系统。诀窍不在于大小，而是一种叫做 DocTags 的标记格式。

在本系列的早期文章中，我们介绍了 Docling，这个开源库已成为将 PDF 转换为干净、结构化、机器可读文档的标准。Docling 是工具包。

本文介绍的是现在位于其核心的模型：Granite Docling，IBM Research 的紧凑型视觉语言模型，用于文档转换。

头条数字几乎令人怀疑。Granite Docling 拥有 2.58 亿参数，按 2026 年的标准来说很小，只是大多数 OCR 流水线所使用的多十亿参数视觉模型的一小部分。

然而，在对文档解析至关重要的基准测试中，它匹配或击败了比它大好几倍的系统。在表格结构识别上，它获得了 0.97 的 TEDS 分数，几乎完美。在代码识别上，它的错误率几乎为零。

这么小的模型是怎么做到这么好的？不是通过成为一个更小的通用模型。而是通过成为一个专门构建的模型，并通过使用专门为文档设计的格式来实现。

1、使用大型通用模型进行解析的问题

VLM 时代文档解析的默认方法是使用一个大型通用视觉语言模型来阅读页面。

这有效，但浪费且脆弱。通用模型携带与文档无关的巨大容量，它从未针对表格、公式、代码和多列布局的特定结构进行优化。

结果是高成本、高延迟和不一致的结构保真度。

更旧的替代方案更糟糕：一系列单一用途组件的链。将 PDF 栅格化，运行通用 OCR 引擎获取文本，运行单独的布局模型，运行表格模型，将输出拼接在一起。

每个阶段都对其他阶段一无所知，因此错误会在链中累积，最终结构仅与最薄弱的环节一样好。

Granite Docling 拒绝了这两种方法。它是一个紧凑的模型，专门为文档构建，单次读取整个页面并直接输出其结构。

无需协调集成，无需托管巨型模型。

2、DocTags：使其工作的想法

核心创新不是模型架构，而是模型被训练生成的输出格式，称为 DocTags。

DocTags 是一种结构化标记格式，描述页面上的每个元素——文本、表格、图表、代码、公式、表单、标题——及其空间位置以及与其他元素的逻辑关系。关键的是，它将内容与结构分开。模型不是产生散文并希望布局存活下来，而是发出明确的标签，说 "这是一个表格，这是它的位置，这是它的单元格" 或 "这是一个方程式，这是它的 LaTeX"。

这很重要，原因有两个。

首先，它最大限度地减少了歧义：模型不是猜测如何在纯文本中表示表格，而是填充为表格构建的格式。

其次，它最大限度地减少了 token：紧凑的标签流比冗长的标记更便宜地生成，这是小型模型保持快速和准确的部分原因。

一旦模型发出 DocTags，Docling 库就会将其转换为 DoclingDocument，这是我们在 Docling 文章中介绍的统一表示，然后可以干净地导出到 Markdown、HTML 或 JSON。

DocTags 是模型所见内容与 RAG 管道可以使用的结构化文档之间的桥梁。

3、它是如何构建的

Granite Docling 是 SmolDocling-256M-preview 的生产后继者，后者是 2025 年初发布的实验模型。

架构经过精心选择，刻意谦逊：

• 基于 Idefics3 架构。
• 视觉编码器是 SigLIP2（siglip2-base-patch16-512），是 SmolDocling 中原始 SigLIP 的升级。
• 语言骨干是 Granite 165M LLM，取代了 SmolDocling 的 SmolLM-2。
• 两者通过像素混洗连接器连接，整个模型使用轻量级 nanoVLM 框架在 IBM 的 H100 集群上训练。

训练数据是故事的另一半。

IBM 构建了专门针对文档难点的合成数据集：SynthCodeNet 用于超过 50 种编程语言的代码，SynthFormulaNet 用于数学表达式与真实 LaTeX 配对，SynthChartNet 用于注释为结构化表格的图表，以及 DoclingMatix，一个真实世界文档页面的语料库。

该模型在微调期间直接学习 DocTags，团队指出这加速了收敛并减少了 SmolDocling 中看到的不稳定性。

4、数字

与其前身的基准测试比较显示了专门构建方法获得了多少收益。

最引人注目的是表格识别，这是最难也是最有价值的文档解析任务：

任务（vs SmolDocling-256M）           SmolDocling    Granite Docling
-------------------------------------------------------------------
表格 TEDS（结构）                      0.82            0.97
表格 TEDS（含内容）                     0.76            0.96
代码识别（F1）                          0.915           0.988
代码识别（编辑距离）越低越好              0.114           0.013
公式识别（F1）                          0.947           0.968
整页 OCR（F1）                          0.80            0.84
OCRBench（越高越好）                    338             500

表格数字是头条新闻：结构 TEDS 为 0.97 意味着预测的表格树几乎与真实表格完全匹配，这是表格在摄取中存活下来与变成糊状之间的区别。

代码识别几乎解决了，编辑距离下降了近一个数量级。通用 OCR 基准从 338 跳到 500，在饱和指标上是一个巨大的提升。

重点不是这些击败了地球上的每个模型。重点是 258M 模型达到了这个水平，而该领域认为需要更大的模型。

5、如何使用它

最简单的路径是通过 Docling 库，它为我们下载并运行模型。

一个 CLI 命令即可转换文档：

pip install docling

# 使用 Granite Docling VLM 管道解析 PDF，导出为 Markdown 和 HTML
docling --to md --to html --pipeline vlm --vlm-model granite_docling "https://arxiv.org/pdf/2501.17887"

对于编程使用，它作为 VLM 管道插入 Docling SDK：

from docling.document_converter import DocumentConverter, PdfFormatOption
from docling.datamodel.base_models import InputFormat
from docling.pipeline.vlm_pipeline import VlmPipeline

converter = DocumentConverter(
    format_options={
        InputFormat.PDF: PdfFormatOption(pipeline_cls=VlmPipeline),
    }
)
doc = converter.convert("https://arxiv.org/pdf/2501.17887").document
print(doc.export_to_markdown())

一个真正有用的功能是模型接受指令，而不仅仅是单个固定任务。

除了用于整页转换的 "Convert this page to docling" 之外，它还接受有针对性的命令：将图表转换为表格，将公式转换为 LaTeX，将表格转换为 OTSL，对特定边界框中的文本进行 OCR 或检测特定元素类型。

文档在解析时变得可查询，而不仅仅是可转换。

一个值得了解的部署说明：在当前的 vLLM 版本中，模型的绑定权重可能无法加载，因此 IBM 提供了一个 untied 分支。使用 vllm serve ibm-granite/granite-docling-258M --revision untied 来服务它，它就可以工作了。

6、DocTags 实际上是什么样子的

值得看看这个格式，因为 DocTags 是整个想法，而且很容易错误地想象。

给定一个页面，模型发出包裹在 <doctag> 中的标签流。每个块都是有类型的，通过 <loc_> 标签在固定的 0 到 500 网格上携带其位置，表格使用 OTSL 词汇表，其中单元格 token 与内容交织在一起。

简化的标题加段落如下所示：

<doctag>
  <section_header><loc_52><loc_61><loc_294><loc_82>3. Results</section_header>
  <text><loc_52><loc_90><loc_294><loc_140>The fine-tuned model improves...</text>
  <otsl><loc_52><loc_150><loc_294><loc_300>
    <ched>Method<ched>Accuracy<nl>
    <rhed>Baseline<fcel>0.82<nl>
    <rhed>Ours<fcel>0.97<nl>
  </otsl>
</doctag>

OTSL token 是赚取其价值的部分：<ched> 标记列标题，<rhed> 标记行标题，<fcel> 标记填充单元格，<nl> 标记新行，因此表格的结构和内容在一个流中同时到达，而不是作为需要重新解析为网格的散文。这就是产生 0.97 表格 TEDS 的原因。

然后 Docling 库将此 DocTags 流转换为 DoclingDocument 并将其导出到 Markdown、HTML 或 JSON。

我们通常永远不会自己读取标签；它们是模型的内部语言，Docling 隐藏了它们。

7、超越整页转换：有针对性的指令

Granite Docling 不限于 "convert the whole page"。因为它是在指令上训练的，所以它可以指向单个任务或单个区域，这使其不仅是一个批量转换器，更是一个精确的工具。

模型卡直接记录了这些：

"Convert this page to docling."          整页转换（默认）
"Convert chart to table."                将柱状图/折线图转换为结构化数据
"Convert formula to LaTeX."              仅提取数学
"Convert table to OTSL."                 结构化表格提取
"OCR the text in <loc_...>"              仅读取指定的边界框
"Identify element at <loc_...>"          分类位置上的内容

最后那组比看起来更重要。

它意味着文档在解析时是可查询的：我们不必转换所有内容然后搜索，而是可以问"这个页面上的章节标题是什么"或"仅将图表提取为表格"，当我们只需要复杂页面的一部分时，这是更便宜、更干净的路径。

8、诚实的评估

8.1 真正令人信服的地方

效率论点是真实且有充分证据的：一个 258M 模型达到 0.97 表格 TEDS，可以在多十亿参数模型无法运行的地方运行，包括在笔记本电脑或 WebGPU 浏览器演示中，成本和延迟只是一小部分。

单次设计避免了集成管道的错误累积。

DocTags 是一个真正的好想法，将内容与结构分开，而不是希望结构在散文中存活下来。加上 Apache 2.0 许可证和深度 Docling 集成意味着它可以无缝地放入真正的管道中，没有摩擦或法律担忧。

8.2 需要权衡的地方

IBM 在模型卡本身中非常明确地说明了限制。

Granite Docling 不是一个通用图像模型：要求它描述一张照片，你就是在使用错误的工具，IBM 指向 Granite Vision。

除英语之外的多语言支持仍然是实验性的，日语、阿拉伯语和中文被标记为早期阶段。

因为输出是自回归生成的，它继承了 SmolDocling 论文诚实记录的失败模式：偶尔缺少标签，如缺少位置标记，格式错误的结构，如缺少闭合标签，以及经典的小模型陷阱——无限期地重复 token 直到页面无法解析。

Granite Docling 在其前身的稳定性方面有所改进，但风险并未消失，这就是为什么 IBM 建议仅作为 Docling 的一部分运行它，并且对于安全敏感的使用，将其与 Granite Guardian 配对。虽然与 SmolDocling 的基准测试很强，但它们在很大程度上是 IBM 自己的评估，因此在标准化之前，与当前解析器的独立比较仍然是负责任的下一步。

9、它在技术栈中的位置

Granite Docling 位于本系列构建的管道的解析层内，作为 Docling 中的引擎选项：

解析层
   Docling 库（编排、格式、DoclingDocument）
        |
   Granite Docling（读取页面 -> DocTags 的紧凑型 VLM）
        |
  DoclingDocument -> Markdown / HTML / JSON
        |
  分块 + 检索 -> RAG / Agent

它不与 Docling 竞争；它是我们选择 VLM 管道时 Docling 运行的模型。它与我们已经介绍的其他选择并列：MinerU 作为替代解析器，MinerU-Popo 作为解析后重建跨页结构的后处理层。

Granite Docling 对此的贡献是一个具体的赌注：解析模型本身应该是小的、专门的和快速的，而不是大的和通用的。

10、结束语

文档 AI 的本能一直是使用更大的模型。Granite Docling 是反证：对于像文档转换这样特定的任务，一个专门为这项工作训练的小型模型，发出专门为该结构设计的格式，可以匹配比它大好几倍的系统。

大小吸引了注意力，但 DocTags 才是使其工作的原因，因为将内容与结构分开正是让紧凑型模型远超其重量级的关键。

如果我们的 RAG 管道需要准确的、保留结构的解析，而不需要巨型 VLM 的成本，那么 258M 的专家模型值得认真考虑。

这个教训超越了这一个模型：在文档处理中，专门构建一直在击败通用构建，正确的输出格式可能比原始参数数量更重要。

原文链接：Granite Docling: A 258M Model That Parses Documents Better Than Models Ten Times Its Size

汇智网翻译整理，转载请标明出处