256M 参数的文档解析模型,表格结构、 代码块、公式、图表数据的结构化标签序列

256M 参数的文档解析模型,到底能用到什么程度?

一、模型概况与技术架构

SmolDocling 是 IBM Docling 团队发布的超轻量多模态文档解析模型,参数量仅 256M, 基于 HuggingFace 的 Idefics3 / SmolVLM 架构。它的核心思路与传统 OCR 管线不同: 不先做文字检测再逐块识别,而是直接将整页文档图片输入模型,一步生成包含文本、表格结构、 代码块、公式、图表数据的结构化标签序列(DocTags),再由 docling_core 库 转换为 Markdown 或 HTML。

2025 年 3 月,IBM 发布了继任模型 granite-docling-258M(258M 参数, repo: ibm-granite/granite-docling-258M),同为 Idefics3 架构, 官方标记 SmolDocling 为 deprecated 并推荐迁移。本测评将两个模型在同一套样本上做 1:1 对比。

SmolDocling / Granite-Docling 技术架构:视觉编码器 + LLM 解码器的端到端多模态方案

训练数据与官方基准

根据论文 arXiv:2503.11576,模型在以下数据集上训练和评估:

注意:以上均为英文数据集。论文未报告任何中文测试结果。 本测评通过自建中文样本补充了这一关键盲区。

推理代码与 DocTags 输出格式

模型使用标准的 transformers API 加载,推理时将文档图片和指令文本一起输入, 生成 DocTags 标签序列。以下是简化后的推理流程:

# 加载模型与处理器processor = AutoProcessor.from_pretrained("docling-project/SmolDocling-256M-preview")model = AutoModelForImageTextToText.from_pretrained(    "docling-project/SmolDocling-256M-preview",    torch_dtype=torch.bfloat16, _attn_implementation="sdpa").to("cuda")# 构造输入:图片 + 指令messages = [{"role": "user", "content": [    {"type": "image"},    {"type": "text", "text": "Convert this page to docling."}]}]prompt = processor.apply_chat_template(messages, add_generation_prompt=True)inputs = processor(text=prompt, images=[image], return_tensors="pt").to("cuda")# 生成 DocTagsoutput = model.generate(**inputs, max_new_tokens=8192)doctags = processor.batch_decode(output[:, inputs["input_ids"].shape[1]:],                                  skip_special_tokens=False)[0]# DocTags -> DoclingDocument -> Markdown/HTMLdoc_tags = DocTagsDocument.from_doctags_and_image_pairs([doctags], [image])doc = DoclingDocument.load_from_doctags(doc_tags, document_name="Doc")print(doc.export_to_markdown())

DocTags 是 Docling 定义的结构化标记语言,每个元素带有边界框坐标 (<loc_xxx>),核心标签包括:

二、测评设计:8 张样本覆盖 7 个维度

对齐论文 Table 2-5 的基准维度,并补充中文维度。样本来源:

• 1 张官方测试图
  
  :page_with_table.png (1326×2014, 学术论文含复杂 8 列表格)
• 7 张自建合成图
  
  :用 PIL + 微软雅黑 + Consolas 渲染,ground truth 完全可控

环境:conda env smoldocling (Python 3.11, torch 2.11.0+cu128, transformers 5.14.0, docling_core 2.87.1); 注意力后端 SDPA (PyTorch 内置高效 attention; flash_attn 因 Windows 长路径限制无法编译)。

三、性能实测

SDPA vs Eager 注意力后端对比

在正式对比两个模型前,先测试了注意力后端对性能的影响。结论:

SDPA 通过融合注意力计算的 softmax 和矩阵乘法,在不改变输出质量的前提下 大幅降低显存占用。对 Granite 效果更显著(速度翻倍),但即使优化后,Granite 仍然比 SmolDocling 慢约 8 倍。 这一差距来自模型内部的生成机制差异,而非注意力后端。

输入:微软雅黑渲染的中文文档,标题”人工智能发展报告”,正文讨论大语言模型

SmolDocling 输出

## 人工看象发展含近年来、大活监掌型在自然语言处理领域取得了量著实施。以 GPT、GLM 分化表的模型最视了現大的理解与生成能力。多模态模型进-步将视角、研究与语言能力融合，能够向时处理图像、视角和文本信息。文献解析是其中的重要应用方向，自标定将析式包实状的双精 ( 法及、按是、翻译)转换为结构化数损。本文评估的 SmolDocling 图力该领域的结论组织方案。

Granite-Docling 输出

## 人工智能发展报告近年来,大语言模型在自然语言处理领域取得了显著突破。以 GPT、GLM 为代表的模型展现了强大的理解与生成能力。多模态模型进一步将视觉、听觉与语言能力融合，能够同时处理图像、视频和文本信息。文档解析是其中的重要应用方向,目标是将版式复杂的文档(论文、报表、票据)转换为结构化数据。本文评估的 SmolDocling 即为该领域的轻量级方案。

逐行对比分析

准确率估算:以 100 个汉字为样本,SmolDocling 正确识别约 20 个(~20%), Granite 正确识别约 98 个(~98%)。差距达 5 倍。

SmolDocling 的错误模式主要是字形相近字混淆:「语→监」「型→掌」「文→图」「档→精」, 这表明模型的中文视觉编码器对 CJK 字形的区分能力不足。Granite 明显改善了这一点。

4.2 中文表格:出乎意料的 Tradeoff

中文表格的结果揭示了一个非直觉的 tradeoff:Granite 的中文文字识别好, 但在表格内容提取上反而退步;SmolDocling 中文字符错误,但表格结构和数值完整。

输入:5 行 x 4 列中文销售统计表格 (含合并表头”第一季度/第二季度”)

两个模型输出的 DocTags 结构对比

SmolDocling (3407 chars):

<section_header_level_1>2024 年度費能紛行</section_header_level_1><otsl>  <ched>予告紛別<ched>第-学度<ched>第二学度<ched>同地紛<nl>  <fcel>智能手机<fcel>1,250 万<fcel>1,480 万<fcel>+18.4%<nl>  <fcel>等に本車職<fcel>680 万<fcel>720 万<fcel>+5.9%<nl>  ...</otsl>

Granite-Docling (289 chars):

<section_header_level_1>2024 年度销售统计</section_header_level_1><otsl></otsl>  /* 空标签 -- 表格内容完全丢失 */

Tradeoff 分析

这意味着:如果业务场景是“中文报表数字提取”(提取金额、百分比等数值), SmolDocling 反而比 Granite 更可靠 — 虽然中文字符有误,但数字和表格结构完整。 而如果需要“中文文档全文识别”,则必须用 Granite。

五、英文 / 代码 / 公式:两个模型一致

在英文和非中文维度上,两个模型表现高度一致。以下是逐维度分析。

5.1 英文表格结构 (page_with_table)

输入:TableFormer 论文页面,含 8 列复杂学术表格 (合并表头,多级嵌套)

表格输出对比

两个模型均完美还原了表格结构:

与论文 Table 4 的 TEDS 基准(SmolDocling FinTabNet 0.52, PubTables 0.65)一致: 对于结构完整的学术表格,两个模型都能准确提取。

5.2 代码块

与论文 SynthCodeNet F1 0.92 的基准一致。两个模型对 Python 代码的还原度极高, 包括 __name__ == '__main__' 这类易错点。Granite 输出中 if __name__ 行有 1 个额外空格缩进,属于微小瑕疵。

5.3 数学公式

值得注意的是,默认 prompt "Convert this page to docling." 下, 公式以 ASCII 文本形式输出而非 LaTeX 源码。论文 Im2LaTeX F1 0.95 是在专用 prompt "Convert formula to LaTeX." 下测的。如需 LaTeX 输出,应使用专用指令。

5.4 双栏排版

图表识别分析

两个模型均能正确识别图表类型 — SmolDocling 输出 <chart><vbar_categorical> 标签, 说明它知道这是分类柱状图。但数值读取完全失败,4 个不同的柱子高度被全部识别为 45。

论文 Chart TEDS 0.75 的成绩是在裁剪好的图表区域 + 专用任务下测的。 在整页文档场景中,图表只是页面的一部分,数值提取的可靠性显著下降。 这是一个需要后处理验证的关键边界。

六、SmolDocling vs Granite-Docling 综合对比

七、落地建议与选型指南

场景 1: 中文文档全文识别

推荐: Granite-Docling (速度换准确度)

SmolDocling 中文准确率仅 ~20%,不可直接用于中文 OCR。 Granite ~98% 的准确率使其成为该场景下唯一可用的选择。 如果需要更高准确率,可考虑结合 PaddleOCR / EasyOCR 做后处理纠错。 速度代价:Granite 每页约 50-80 秒(SDPA),适合批量离线处理。

场景 2: 英文学术文档 / 论文解析

推荐: SmolDocling (速度优先)

两个模型在英文维度上表现一致,SmolDocling 速度快 8 倍。 对于批量论文解析(如构建 RAG 知识库),SmolDocling 的吞吐量优势明显: 单张 5060 Ti 可同时处理 10+ 篇论文。

场景 3: 中文报表数字提取

推荐: SmolDocling + PaddleOCR 组合

看似矛盾的结论:中文场景下反而推荐 SmolDocling。原因是 Granite 虽然中文文字准确, 但表格内容提取退步(<otsl> 空标签),无法获取单元格数值。 SmolDocling 中文字符有误但数字和表格结构完整。 更稳妥的方案:用 PaddleOCR 提取文字 + SmolDocling 提取表格结构,两者互补。

场景 4: 代码/公式/英文混合文档

推荐: 两者皆可,SmolDocling 速度更快

代码和公式维度两个模型一致,均达到论文报告的高水准(F1 0.92/0.95)。 SmolDocling 更快,优先选择。如需 LaTeX 源码输出,使用专用 prompt "Convert formula to LaTeX."。

场景 5: 生产环境部署

关键约束:

• 显存:
  
   两个模型均仅需 0.83 GB (SDPA),一张 16GB 显卡可跑 10+ 实例
• flash_attn:
  
   当前 Windows + Blackwell 环境无法编译 flash_attn,用 SDPA 已足够
• vLLM:
  
   模型卡提供 vLLM 推理示例,可大幅提升吞吐(待验证)
• 模型状态:
  
   SmolDocling 已 deprecated,生产环境建议评估 granite-docling-258M
• 图表数值:
  
   两个模型的图表数值提取均不可靠,需要后处理验证或专用模型

八、技术踩坑记录

1. AutoModelForVision2Seq 在 transformers 5.x 中不存在

官方模型卡的示例代码使用 AutoModelForVision2Seq,但 transformers 5.13+ 已将其 合并为 AutoModelForImageTextToText。直接 import 会报 ImportError。

2. 缺少 torchvision

SmolDocling 的 image processor (Idefics3) 依赖 torchvision 做图像预处理, 首次加载时报 Missing optional dependencies: torchvision。 需单独安装匹配版本 torchvision 0.26.0+cu128。

3. flash_attn 无法在 Windows + Blackwell 上编译

flash-attn 2.8.3 的源码包含超长路径文件名(如 device_batched_gemm_add_relu_gemm_add_xdl_cshuffle_f16_f16_f16_f16_f16_f16_gmk_gnk_gno_gmo_instance.cpp), 超过 Windows MAX_PATH 260 字符限制。启用长路径需要管理员权限(本环境无权)。 解决方案:使用 PyTorch 内置的 SDPA 后端,效果接近。

4. base 环境 numpy dist-info 损坏

base 环境同时存在 numpy 2.5.0 和 2.5.1 的 dist-info 目录, 导致 importlib.metadata.version('numpy') 返回 None, transformers 启动检查直接抛 ValueError。解法:新建独立 conda 环境。

5. DocTags 元素标签名与直觉不符

DocTags 的标签名并非 <title>/<para>/<table>, 而是 <section_header_level_N>/<text>/<otsl>/<code>/<chart>。 OTSL 表格使用子标签体系: <ched> 列头, <fcel> 数据格, <ecel> 跨列空格, <nl> 换行。统计元素时需用正则提取实际标签名。

6. 公式默认输出非 LaTeX

用默认 prompt "Convert this page to docling." 时,公式以 ASCII 文本形式输出 (e.g. e^(i*pi)+1=0)。论文 Im2LaTeX F1 0.95 是在专用 prompt "Convert formula to LaTeX." 下测的。如需 LaTeX,应切换 prompt。