![氛围图](https://developer.qcloudimg.com/http-save/8729876/fc58b55341f8ae92993917f41b09bfb6.jpg)

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

## 导语：你的 OCR pipeline 真的“看见了”吗？

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

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

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

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

> **想自己动手试？**
> - 📄 论文：[arXiv 2608.18586](https://arxiv.org/abs/2608.18586)
> - 💻 代码：[GitHub · ECNU-RAIL/OmniHandwritingOCR-CIKM2026](https://github.com/ECNU-RAIL/OmniHandwritingOCR-CIKM2026)
> - 📊 数据集：[GitHub · ECNU-RAIL/OmniHandwritingOCR-CIKM2026](https://github.com/ECNU-RAIL/OmniHandwritingOCR-CIKM2026)

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

论文要解决的是多模态大模型在手写 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



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

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

人工智能

算法

开发工具

OmniHandwritingOCR发布77,572对手写图像-标签对，覆盖6子任务12子集，实现文本与公式的失败模式诊断。研究发现最强模型在多行复杂公式上CER高达57.08，暴露幻觉纠错风险。该基准支持语言、结构、难度分层评估，为OCR忠实转录提供回归测试依据。

数据标注

压力测试

回归测试

GitHub

2026上云采购 | AI焕新·智启新局

documentocr

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

OmniHandwritingOCR：别让多模态大模型把手写公式读成幻觉-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐