别再迷信 OCR 专用小模型：8 个 7B 以下 VLM 实测，抽取 JSON 结构还得靠通用选手

你有没有想过，博物馆里那些泛黄的登记册，其实是一座座数据金矿？

一件史前石器的出土地、尺寸、描述文字；一张 19 世纪珠宝的材质、重量、保险价值——这些信息如果变成结构化数据，研究者可以瞬间检索百年馆藏。问题是：这些登记册是手写的德文，排版是一百多年前的，而且——最致命的——它们是机构的资产，不能随便上传到商业 API。

这就是德国埃尔朗根-纽伦堡大学（FAU）团队在这篇论文里面对的现实。他们的答案不是训练一个更大的模型，而是一份扎实的实测报告：8 个 7B 以下的开源视觉语言模型（VLM），3 个真实馆藏，从零样本、少样本到微调全部拉出来遛一遍。结果相当有意思。

论文地址：arXiv:2610.11818代码仓库：github.com/uddipan77/A…

任务不是"认字"，是"认字+填表"

先明确任务：给定一张文档图片，模型要输出一个严格符合预定义 schema 的 JSON 对象。不是自由文本，不是 Markdown，是那种能直接灌进机构数据库、可以被程序校验的结构化数据。

看一个真实样本——FAU 史前收藏的登记卡：

这张卡上，表头是印刷的（"Anthropologisch-prähistorische Sammlung..."），正文是手写的花体德文，左下角还有一幅石器素描。模型要抽出来的字段包括：库存号（J.-Nr. Eo 2）、尺寸（L 7,25 B 4 cm D 4,2）、出土地（Spy, Belgien）、采集时间、描述全文……8 个字段，一个都不能错位。

数据集一共三个，风格差异拉满：

第三个最狠。Regensburg 的"楼梯学"（Scalalogy，真的有这门学问）调查表，schema 里有嵌套对象和几十个布尔字段——螺旋楼梯还是直梯、木质还是石质、扶手在哪一侧……这是给层级 schema 遵从能力上的压力测试。

珠宝卡长这样：

八个选手，两种"赛制"

参与实测的 8 个模型，参数量从 200M 到 7B：

• 固定提示组（接口僵化，只能吐固定 OCR 指令）：Donut-Base、Donut-CORD（各 200M）、Florence-2-Large（0.77B）、PaddleOCR-VL（0.9B）
• 自定义提示组（能接受自然语言指令）：Nanonets-OCR-s（4B）、Gemma-3-4B、Phi-3.5-Vision（4.2B）、Qwen2.5-VL-7B

这里有个容易被忽略的细节，也是这篇论文方法上最讲究的地方：约束感知协议。两组模型的接口能力完全不同——前者连"请按这个 schema 输出 JSON"都说不了，你没法用同一个 prompt 硬套。论文的做法是让每个模型在它支持的接口下参赛，固定提示组只做最小后处理。这才是对"轻量模型能不能用"这个问题的公平回答。

评测指标也值得展开讲讲。除了常规的 CER（字符错误率）和 ANLS*（结构化相似度），团队提出了一个 mAP-F1：把预测和真值的 JSON 展平到叶子键，逐字段算 1−CER 的重叠度，在 4 个阈值上取宏平均。关键规则是——JSON 解析失败，直接 0 分。这个设计把"内容认得准"和"结构吐得对"拆开了，恰好照出了两类模型的差距。

结果：OCR 专用模型，翻车了

零样本（zero-shot）成绩单，mAP-F1（越高越好，三个数据集）：

是的，你没看错——Donut 系和 PaddleOCR-VL 在结构化指标上全是 0。不是它们认不出字，而是它们的输出根本解析不成合法 JSON（论文披露这几家的 JSON 合成率微调后依然很低）。OCR 专用模型在"纯文本转写"赛道上是尖子生，但接口僵化 + 结构化能力缺失，让它们在这条赛道上直接弃权。

Qwen2.5-VL-7B 零样本就全面领先，珠宝卡上 mAP-F1 到 96.3——印刷体+平面 schema 接近饱和。但手写史前册（56.2）和嵌套楼梯表（33.3）还有很大空间。

微调之后，格局清晰了。Top-3 全是通用指令模型：Qwen2.5-VL-7B（90.0 / 99.4 / 62.8）、Phi-3.5-Vision（82.2 / 99.5 / 72.0，楼梯表最佳）、Gemma-3-4B（83.1 / 99.4 / 46.9）。

论文的总结一针见血：可靠的结构化抽取，不只取决于"认字准"，还取决于指令跟随、字段绑定、稳定输出 schema 合规内容的能力——这恰恰是通用指令模型的主场。

楼梯调查表这个高难度样本长这样，感受一下什么叫"深嵌套"：

三项「增强大体检」：两项经常帮倒忙

选出 top 3 后，团队做了三组对照实验,每项独立隔离测贡献。这部分对实践者的价值可能比榜单本身还大。

① 超参优化（Optuna）——最靠谱的温和增强。 三个模型在楼梯表上全涨（Gemma-3 的 mAP-F1 从 46.9 飙到 77.9）。但注意"温和"二字：不是免费的全面提升，Gemma-3 在史前册上反而从 83.1 掉到 65.4。结论是 HPO 值得做，但做完要在验证集上验，别假设稳赚。

② 经典图像预处理——多数情况下有害。 光照平坦化、去噪、CLAHE 这些传统 OCR 时代的标准操作，放到现代 VLM 上，多数设置性能下降：Qwen2.5-VL 在楼梯表上 62.8→53.6，Gemma-3 从 46.9→43.6。个别 CER 改善也不传导到结构化指标。直觉解释：这些模型预训练时见的是"原始"图像分布，你精心PS过的图反而偏离了它的舒适区。

③ 多阶段训练——纯看模型。 Gemma-3 三个数据集全涨，Phi-3.5 小幅波动，Qwen2.5-VL 两个数据集不升反降（珠宝卡 99.4→90.2）。课程学习不是万金油。

联合训练：一个 checkpoint 管所有馆藏？

机构最理想的部署形态是：一个模型服务所有馆藏。论文测了"单数据集专精 checkpoint" vs "三馆合并训练的通用 checkpoint"。

结果再次分裂：

• Gemma-3-4B：合并训练全面变强——史前册 83.1→87.9，楼梯表 46.9→68.0。跨 schema 训练反而提升了它的泛化。
• Qwen2.5-VL-7B：明显负迁移——楼梯表 CER 从 7.6 恶化到 24.9，mAP-F1 从 62.8 跌到 41.4。

同一个操作，一个模型受益、一个模型受损，而且都不是小数目。论文的立场很克制：这不存在统一规律，机构部署前必须按自己的模型和数据实测——要么养一个通用 checkpoint，要么每个馆藏专精一个，没有想当然的答案。

微调的实际改善长什么样？看论文给的定性对比：Gemma-3 微调后，库存号的格式绑定对了（J.-Nr. E024 → Eo 24），尺寸字段从三个空串变成了 6,25 / 3,95 / 1,7，单样本 CER 从 26.8% 降到 13.9%。但长段手写描述、出土地与采集时间的字段边界混淆，依然没完全解决。

泼冷水时间

这篇论文扎实，但有几个点值得拎出来：

数据集小。 楼梯表测试集只有 25 张，珠宝卡 89 张。这种量级下，几个百分点的差异可能落不出统计显著区间，而且论文没有报多次运行的方差。榜单名次的细节要谨慎看。

部分真值来自 Gemini。 史前册的转录由 Gemini 生成后人工校验。校验环节的质量（比如标注者间一致性）论文没有披露——虽然已发布 Zenodo 供复查，但"AI 标注+人审"的闭环本身值得留意。

没测约束解码。 对"JSON 解析失败=0分"这个痛点，业界有 constrained decoding 这类强制输出合法 JSON 的手段，论文只把它列进 future work。如果补上，OCR 专用模型的 0 分惨案会不会改写？不好说，但这是个合理的追问。

时效性强。 模型迭代太快（PaddleOCR-VL 就在快速更新），论文自己也承认结论只对被测版本负责。

理性看待

把视角拉高，这篇论文回答的其实是一个"最后一公里"问题：当大模型能力已经溢出，机构如何在数据主权约束下用得起、用得好。

三条可带走的实践结论：

1. 选型看任务，别看赛道标签。 "OCR 专用"不等于"文档抽取专用"。要结构化输出，优先测支持自定义指令的通用 VLM。
2. 微调是主策略，HPO 是稳妥的增强，而图像预处理、多阶段训练这类"传统智慧"要先验证再上，别默认有效。
3. 联合训练按模型实测。 Gemma 型的能吃成胖子，Qwen 型的会消化不良。

对国内做企业文档数字化、档案系统的团队，这份报告几乎就是一张部署避坑清单。数据不能出门的场景，7B 以下模型+一台消费级 GPU（sub-1B 全参微调，4-7B 用 QLoRA）已经能到"可用"档位——这在两年前还是不可想象的事。

至于剩下的那几个点——手写长文本的字段边界、强制 JSON 的解码策略——就留给下一批论文了。

（本文是「智能文档」系列第 13 篇。同主题延伸阅读：EVICALC：LLM 做文档算术为何折戟、TRACE：文档证据定位的契约缺失、FoveDoc：检索增强补上阅读短板。）