OmniHandwritingOCR:别让多模态大模型把手写公式读成幻觉

简介: OmniHandwritingOCR 是首个面向手写OCR的细粒度诊断基准,含7.7万图像-标签对、6项子任务与12个子集,聚焦多行公式等难点;首创“事实性标注”,拒绝语义纠错,直击模型幻觉问题。(239字)

氛围图

💡 一句话总结:OmniHandwritingOCR 用 77,572 个图像-标签对、6 个子任务和 12 个子集把手写 OCR 从“总分游戏”变成失败模式诊断;它最刺眼的发现是,多行公式一难,最强模型的字符错误也会失控。

导语:你的 OCR pipeline 真的“看见了”吗?

先问一个可能戳到你的问题:你把手写作业拍照丢给多模态大模型,它输出了一段流畅 LaTeX,你敢直接进题库、判分系统或知识库吗?

做文档智能的人大概都经历过这种时刻:单行文字看起来没问题,一到多行公式、语言切换、写作者手滑,模型就开始“脑补”。它不是识别不出字符,而是把语言先验、题目语义和图像证据混在一起,最后给你一个看起来合理、图像上却不存在的答案。

这对印刷体可能是小问题,对手写数学就是大问题。一个负号、上标、括号或一行结构错了,公式的数学语义可能完全改变。更麻烦的是,很多 OCR 基准偏干净印刷体、单行输入或整体分数,很难告诉你错误到底来自漏字、行结构崩坏,还是生成式补全。

这篇论文的立场很直接:手写 OCR 要测“忠实转录”,也就是报告图像上真实写了什么,而不是猜作者本来想写什么。

想自己动手试?

这篇论文到底想解决什么问题?

论文要解决的是多模态大模型在手写 OCR 中的诊断问题:它们能否忠实转录真实手写文本和结构复杂的手写数学公式,而不是只生成看起来合理的文本。

已有基准各有强项,但往往把两条线分开:手写文本识别(HTR,Handwritten Text Recognition)关注真实书写风格,手写数学表达式识别(HMER,Handwritten Mathematical Expression Recognition)关注公式结构。OmniHandwritingOCR 把英文和中文手写、单行与多行文本、单行与多行公式放进同一个协议里,形成 77,572 个图像-标签对、6 个子任务和 12 个子集。

基准总览
图说:基准同时覆盖手写文本与手写公式,重点不是给一个总榜,而是把不同能力轴拆开检查。

这带来的第一个价值是覆盖面。77,572 对样本里有 38,088 个多行公式样本,正好压在结构复杂度这个薄弱点上。第二个价值是诊断粒度:模型可以在英文、中文、单行、多行、公式难度和事实性标注之间被分层比较,而不是只看一个 Overall 分数。

第三个价值最容易被忽视:fact-based annotation,事实性标注。真实标签保留写作者可见的拼写、数字和符号错误,只删除被划掉的内容,不根据题目语义修正。换句话说,学生真的写错了,模型也要照着错的样子转录。

任务与标签体系
图说:6 个子任务展开为 12 个子集,让语言、内容类型和结构复杂度可以分别归因。

我认为这是整篇论文最锋利的设计。很多 OCR 系统会把“合理纠错”当成优点,但在证据转录任务里,它其实是幻觉:答案来自语言先验,而不是图像。论文把这类行为显性化了。

它的思路是什么?

OmniHandwritingOCR 不是新训练一个 OCR 模型,而是做了一套基准构建与统一评估流程。可以把它的方法看成四层。

  • 📚 数据收集层:混合公共手写数据、真实学生手写和新采集数学公式,清洗重复、模糊和无法验证的样本,再统一任务定义与标注格式。公共数据提供覆盖面,新采集私有数据提供更贴近真实教学场景的压力测试。
  • 🪜 难度分层层:把多行公式划分为 ml-easy、ml-medium 和 ml-hard。分层不只看模型错误率,还检查模型无关统计量,确认标签长度、LaTeX 命令数和非空行数单调上升。
  • 🧾 事实标注层:专家按可见证据转录,保留写作者错误,并复核边界、符号、行结构、Unicode 与 LaTeX 表达。
  • 📏 统一评估层:对 13 个开源和闭源系统使用统一提示,比较 BLEU-4、F1、1-NED、CER 和 Overall。BLEU-4 衡量 n-gram 相似度,F1 衡量词级精确与召回的平衡,1-NED 衡量归一化编辑距离相似度,CER 是字符错误率、越低越好,Overall 是综合分。

数据构建流程
图说:从多来源候选图像到质量过滤、任务归一化、难度分层、专家标注和交叉验证,构成完整质控链路。

难度分层的统计很值得看。ml-easy 的平均标签长度是 156.9,平均 LaTeX 命令 4.1 个,平均非空行 3.7 行;ml-hard 分别涨到 488.8、25.7 和 13.0。也就是说,难度不是拍脑袋分的,而是长度、命令密度和行结构同步增加。

为什么这很重要?因为多行公式的失败往往不是“完全不认识字符”,而是局部识别正确、全局结构错位。模型可能漏一个上标、合并两行、重复一个宏命令;字符级看只是几个错误,数学语义上已经不可用。

这套流程的工程味道很浓。它像是在给 OCR 系统做体检:先分科室,再查病灶,而不是最后只给一张“健康指数 72”的报告单。

效果到底怎么样?

先说总体结论:13 个系统没有一个能称得上可靠手写转录。表现最好的 Qwen3-VL-8B Overall 为 72.16,BLEU-4 为 59.24,F1 为 81.60,1-NED 为 75.63。这个分数听起来还不错,但复杂公式会把伪装撕开。

多行公式子集 平均标签长度 平均 LaTeX 命令 平均非空行数 Qwen3-VL-8B F1
ml-easy 156.9 4.1 3.7 86.92
ml-medium 213.0 7.6 7.1 中等退化
ml-hard 488.8 25.7 13.0 70.45

更关键的是 CER。同一个最佳模型在 ml-easy 上 CER 为 24.95,到 ml-hard 恶化到 57.08。CER 是字符错误率,越低越好;57.08 意味着即便输出里有大量正确片段,字符级错误也足以破坏公式语义。

这就是我读这篇时最在意的地方:F1 从 86.92 到 70.45 已经明显下滑,CER 从 24.95 到 57.08 则说明错误密度在放大。对于下游计算系统,这类输出不能直接当可靠 OCR 用。

另一个发现是模型排名并不稳定。语言、内容类型、公式设置变化时,排名会波动。总分第一不等于在每个子集第一,这进一步说明单榜阅读有风险。

论文还观察到多个生成式模型会出现 unsupported correction:视觉上不存在的修正。比如写作者真的写错了,模型却按语义合理性“顺手改正”。在普通纠错场景里这可能是服务,在忠实转录场景里就是错误。

为什么你要关心?

如果你做 OCR、文档智能、教育科技或多模态评测,这个基准至少有三处能直接用上。

  • 🧪 建立回归测试集:把多语言、多行公式、写作者错误和视觉 grounding 样本纳入上线前测试,别只测干净扫描件。尤其要为长公式加入结构级断言,而不只比较最终答案。
  • 🧯 区分识别失败和生成幻觉:对教育、审批、档案和法务场景,显式定义“照抄图像证据”的验收标准。模型若自动纠错,应记录差异并触发人工复核。
  • 📉 重估多模态模型能力边界:不要因为模型在印刷体 OCR 上表现好,就假设手写数学也可靠。这篇的最佳系统已经很强,但 ml-hard 的 CER 仍是明确红灯。

换个角度看,它也给数据标注团队提了个醒:标注规范里必须写清楚“保留作者错误”还是“规范化作者错误”。这两个目标都合法,但混在一个标签里,评测就会失真。

自问一个实际问题:能不能拿它来选型?可以看趋势,但别只看总榜。你应该看自己业务所在的语言、内容类型和结构复杂度分层,再决定哪个模型更接近你的失败分布。

理性看待

这份基准也有边界。公共数据可能被预训练模型见过,私有新采集数据能缓解污染,但不能完全排除;论文也缺少可追溯的 contamination audit。

LaTeX 字符串比较可能低估语义等价但排版不同的答案。等价宏、空白、括号和排版差异会被字符级或序列级指标惩罚。这个问题解释不了 ml-hard 上 CER 的大幅恶化,但会影响细排名。

另外,论文没有提供模型间差异的显著性检验或置信区间;12 个子集的样本量也不同。我的读法是:总体趋势可信,模型细排名要谨慎。它更像一份诊断工具,而不是最终裁判。

作者:lusca
版本:lusca-paper-blog v1.5.0
出处:https://github.com/yjmm10/lusca-skill/tree/main/skills/lusca-paper-blog

相关文章
人工智能 缓存 前端开发
9146 40
人工智能 JavaScript 开发工具
3765 9
开发工具 Swift git
1429 2
缓存 JavaScript Shell
1732 2
人工智能 JavaScript 测试技术
1307 0
Shell API 调度
949 3
人工智能 JavaScript 测试技术
523 4
人工智能 Java BI
610 0