轻量级文档理解模型：从文字识别到结构化理解的工程实践

一、背景：传统 OCR 的能力边界在哪里

在文档智能领域，光学字符识别长期承担的是“把像素变成字符串”的职责。这条技术路线在扫描件转录、票据归档等场景中已经相当成熟，但当业务真正往下走时，开发者很快会遇到三类瓶颈：

第一，版面语义缺失。传统 OCR 输出的往往是一堆按坐标排列的文本行，阅读顺序需要后处理推断，跨栏排版、合并单元格、公式与正文混排时极易错乱。

第二，结构化成本高。从发票、收据、业务表单中提取字段，通常要在 OCR 结果之上再叠一层规则引擎或模板匹配，模板稍有变动就要重新维护，长尾成本居高不下。

第三，无法回答“关于文档的问题”。诸如“这份报表中第三季度营收同比增长多少”“合同里约定的违约金比例是多少”这类需求，本质上是检索、计算与语义推理的组合，超出了纯识别能力的范畴。

因此，行业的技术演进方向很明确：把 OCR 从“识别”升级为“文档理解”，用统一的模型同时覆盖解析、抽取与问答。而近期行业中出现的一类轻量级方案——参数量在 1B 以下、却宣称具备多任务全能表现——正是对这一方向的工程化回应。本文不针对任何具体产品做评测或推荐，而是把这类方案作为技术现象，讨论其设计逻辑、评测口径与落地方法。

二、轻量级全能模型的设计取舍

2.1 为什么“小尺寸”是一个真问题

文档理解任务的部署场景通常有三个特征：并发量大（批量票据、批量合同）、成本敏感（单页处理成本直接决定业务毛利）、数据敏感（票据、合同往往不便外传）。这三点共同把“单卡可部署、单页推理成本低”推到了选型的核心位置。

一个 0.8B 级别的模型，在量化后可以做到很小显存占用，适合在单张消费级或入门级加速卡上部署，也便于做水平扩容。相比之下，参数量在 7B 以上的通用多模态模型虽然能力更强，但在高吞吐文档流水线中，单位页成本往往难以接受。

但小尺寸必然带来能力压缩。要在有限参数中同时容纳文档解析、字段抽取、视觉问答三类任务，关键在于任务之间的表征共享：版面结构理解、文字识别、语义推理本质上都依赖对视觉文本的对齐建模，共用一套视觉编码与文本解码通路，比分别训练三个专用模型更节省参数。

2.2 三类核心能力的技术含义

（1）文档解析：从文本行到结构化文档

文档解析的目标不是输出文字，而是输出带层级与顺序的结构化表示。工程上通常要求：

• 正确还原阅读顺序，尤其是多栏、图文混排、页眉页脚干扰的场景；
• 表格还原为行列结构，包括合并单元格、无边框表格；
• 数学公式转写为可渲染的标记语言；
• 整体输出为 Markdown、LaTeX 等便于下游消费的格式。

这类能力的价值在于，它把“文档转结构化文本”这一步从多模块拼接简化为单次推理，显著降低流水线复杂度。

（2）关键信息抽取：从文档到 JSON

字段抽取的本质是“给定文档图像与字段语义描述，定位并输出值”。传统方案依赖模板坐标或正则，泛化性差。模型化方案通常以指令形式给出字段清单，直接生成结构化结果，例如：

{
  "invoice_no": "******",
  "issue_date": "****-**-**",
  "total_amount": "****.**",
  "tax_amount": "***.**"
}

工程上需要注意的是：生成式抽取必须配合后置校验，包括字段类型校验、金额合计校验、日期合法性校验，以及对低置信度结果回流人工复核。把模型输出直接写入业务库是高风险做法。

（3）OCR 视觉问答：从理解到推理

视觉问答把文档当作知识源，支持围绕内容做检索、数值计算与语义推理。它与前两类能力的区别在于：解析和抽取是“转换”，问答是“查询”。典型工程用法是先在解析结果上建立检索索引，再把命中的片段连同问题一起交给模型作答，从而兼顾准确率与成本。

三、评测数据该怎么读

面对“某基准排名第一”“综合榜第二”这类表述，理性的读法是拆开看：

1. 基准与任务是否匹配。文档解析类基准衡量的主要是结构还原质量（编辑距离、表格结构准确率等），与字段抽取、问答能力不是同一维度。跨任务的平均分只能作参考，不能替代场景内验证。
2. 对比组是否公平。参数量级不同的模型放在同一榜单比较时，小模型胜过大模型是值得关注的信号，但更应关注同量级内的差距，以及在你自己的数据分布上的差距。
3. 分数与成本的联合评估。单页延迟、吞吐、显存占用、量化后的精度损失，这些指标对落地决策的影响往往大于榜单上的一两分。

一个可操作的评估流程建议如下：

1. 构建场景测试集：从真实业务中抽样 200~500 页，覆盖版式长尾
2. 定义任务级指标：
   - 解析：字符级编辑距离、表格单元格准确率、阅读顺序错误率
   - 抽取：字段级精确匹配 / 归一化后匹配、漏抽率、误抽率
   - 问答：答案准确率、数值计算正确率、拒答合理性
3. 测量成本：单页 P50/P95 延迟、QPS、显存峰值
4. 交叉验证：与规则方案、更大模型方案做同集对比，形成成本-精度曲线

四、落地路径与工程注意事项

分阶段引入。建议先在“解析”环节替换，因为该环节输出可人工比对、风险可控；稳定后再引入字段抽取，并保留规则兜底；问答能力放在最后，且优先用于内部辅助场景。

输入预处理仍是刚需。图像纠偏、去噪、分辨率归一化对小模型的收益远大于对大模型，原因很简单：参数少意味着对输入退化的容忍度更低。

输出侧要有契约。无论是 Markdown 还是 JSON，都应定义 schema 并做严格校验，避免下游系统被非预期格式击穿。对公式、特殊符号的转义规则要提前约定。

关注长文档切分策略。轻量模型上下文有限，长文档需要按版面区块切分并维护跨块引用关系，切分点应避开表格与公式，否则结构还原质量会明显下降。

留出降级通道。任何模型化方案都要有 fallback：低置信度走人工、复杂版式走专用流程、服务不可用时回退到传统识别链路。这是文档类业务的基本工程纪律。

五、小结

轻量级文档理解模型的出现，本质上是在“能力”与“成本”之间重新画了一条曲线：它不追求在所有任务上达到旗舰水平，而是用较小的参数规模把解析、抽取、问答收敛到一个可部署的单元里，让文档智能从“多模块拼接”走向“单模型多任务”。

对开发者而言，真正决定成败的不是榜单分数，而是三件事：是否建立了贴合自身数据分布的测试集，是否设计了带校验与降级的输出契约，是否把单页成本算清楚了。把这三件事做好，无论最终选择哪条技术路线，都能获得稳定可预期的收益。