OCR研究不曾结束，它才刚刚开始——GOT-OCR-2.0模型开源！

▲ 图1. 通用OCR模型须“通用”

论文标题：

General OCR Theory: Towards OCR-2.0 via a Unified End-to-end Model

论文地址：

https://arxiv.org/abs/2409.01704

项目地址：

https://github.com/Ucas-HaoranWei/GOT-OCR2.0

OCR 一直是离落地最近的研究方向之一，是 AI-1.0 时代的技术结晶。到了以 LLM（LVLM）为核心的 AI-2.0 时代，OCR 成了多模大模型的一项基本能力，各家模型甚至有梭哈之势。

多模态大模型作为通用模型，总有种降维打击 OCR 模型的感觉。那么纯 OCR 的研究真的到头了吗？我们想说：当然没有！没准才刚刚开始。首先盘一下 AI-1.0 OCR 系统和 LVLM OCR 的缺点：

首先是 AI-1.0 流水线式的 OCR 系统，缺点不用多说，各个模块比较独立，局部最优，维护成本也大。最重要的是不通用，不同 OCR 任务需路由不同模型，不太方便。那么多模态大模型在 pure OCR 任务上有什么缺陷呢？我们认为有以下两点：

1. 为 Reasoning 让路必然导致 image token 数量过多，进而导致在纯 OCR 任务上存在 bottle-neck。Reasoning（VQA-like）能力来自 LLM（decoder），要想获得更好的 VQA 能力（至少在刷点上），就要充分利用起 LLM 来，那么 image token 就得越像 text token（至少高维上，这样就会让 LLM 更舒服）。

试想一下，100 个 text token 在 LLM 词表上能编码多少文字？那么一页 PDF 的文字，又需要多少 token 呢？不难发现，保 VQA 就会导致在做 OCR 任务上，尤其是 dense OCR 任务上，模型搞得比较丑陋。

例如，一页 PDF 图片只有 A4 纸大小，很多 LVLM 要都需要切图做 OCR，切出几千个 image token。单张都要切图，拿出多页 PDF 拼接图，阁下又当如何应对？我们认为对于 OCR 模型这么多 token 大可不必。

2. 非常直观的一点就是模型太大，迭代困难。要想引入新 OCR feature 如支持一项新语言，不是 SFT 一下就能训进模型的，得打开 vision encoder 做 pre-training 或者 post-training，这都是相当耗资源的。对于 OCR 需求来说太浪费了。有人会说，小模型能同时做好这么多 OCR 任务吗？我们的答案是肯定的，而且甚至还能更好。

▲ 图2. GOT结构与训练流程图

GOT: Towards OCR-2.0

通用 OCR 模型须要够通用，体现在输入输出都要通用上。我们可以笼统地将人造的所有信号都叫字符，基于此，我们提出通用或者广义 OCR（也就是 OCR-2.0）的概念，并设计开源了第一个起步 OCR-2.0 模型 GOT，该模型名字就是由 General OCR Theory 的首字母组成。

在输入方面，模型支持图 1 中全部的 OCR 任务；输出方面，模型同时支持 plain texts 输出以及可读性强、可编辑的 formatted 文本输出，如 markdown 等。

模型的结构和训练方法如图 2 所示，采用 vision encoder+input embedding layer+decoder 的 pipeline。Encoder 主体采用带 local attention 的 VITDet 架构，这不至于 CLIP 方案的全程 global attention 在高分辨率下激活太大，炸显存。

Encoder 后两层采用 Vary 的双卷积设计方案。整个 Encoder 将 1024×1024×3 的图像压缩为 256×1024 的 image tokens，这足以做好 A4 纸级别的 dense OCR。

整个训练过程分为 3 个步骤，没有一个阶段锁 LLM，也就是不会存在图像到文本的对齐阶段，进而导致损害 image token 的文字压缩率。3 个训练阶段分别为：

1. 高效预训练 encoder，GOT 在整个训练过程中，没有 A100 级别的卡，为了节省资源，该阶段使用小型 OPT-125M 作为 decoder 为 encoder 提供优化方向，快速灌入大量数据。

2. 联合训练 encoder-decoder，该阶段 GOT 的基本结构搭建完成，为上一阶段预训练好的 encoder，以及 Qwen 团队预训练好的 Qwen0.5B。我们稍稍加大了 decoder 的大小，因为该阶段需要喂入大量 OCR-2.0 的知识，而不少数据（如化学式的 OCR）其实也是带点 reasoning 的，更小的 decoder 未敢尝试。

3. 锁住 encoder，加强 decoder 以适配更多的 OCR 应用场景，如支持坐标或者颜色引导的细粒度 OCR（点读笔可能会用到），支持动态分辨率 OCR 技术（超大分辨率图可能会用到），多页 OCR 技术（该 feature 主要是为了后续 follower 能更好地训练 Arxiv 这种数据，我们的设想是多页 PDF 直接训练，无须再对 .tex 断页而苦恼！）

▲ 图3. GOT 使用到的数据渲染工具

当然，整个 GOT 模型设计最困难的还是数据工程。为了构造各种各样的数据，我们学习了众多数据渲染工具，如图 3 所示，包括 Latex，Mathpix-markdown-it，Matplotlib，Tikz，Verovio，Pyecharts 等等。

结果可视化

多说无用，效果才是一切，GOT 的输出可视化效果如下：

▲ 例1：最常用的 PDF image 转 markdown 能力

▲ 例2：双栏文本感知能力

▲ 例3：自然场景以及细粒度 OCR 能力

▲ 例4：动态分辨率 OCR 能力

▲ 例4：多页 OCR 能力

▲ 例5：更多符号的 OCR 能力

总结

尽管 GOT 模型表现不错，但也存在一些局限，如更多的语言支持，更复杂的几何图，chart 上的 OCR 性能。OCR-2.0 的研究还远的很，GOT 也还有不小提升空间（该项目在数据和算力资源上都是非常受限的），正是因为深知 GOT 以及 OCR-2.0 的潜力，我们希望通过开源 GOT 吸引更多的人，放弃 VQA，再次投向强感知。都说纯 OCR 容易背锅，但也正好说明做的不够 work，不是吗？

更多阅读

#投 稿 通 道#

 让你的文字被更多人看到 

如何才能让更多的优质内容以更短路径到达读者群体，缩短读者寻找优质内容的成本呢？答案就是：你不认识的人。

总有一些你不认识的人，知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁，促使不同背景、不同方向的学者和学术灵感相互碰撞，迸发出更多的可能性。 

PaperWeekly 鼓励高校实验室或个人，在我们的平台上分享各类优质内容，可以是最新论文解读，也可以是学术热点剖析、科研心得或竞赛经验讲解等。我们的目的只有一个，让知识真正流动起来。

📝 稿件基本要求：

• 文章确系个人原创作品，未曾在公开渠道发表，如为其他平台已发表或待发表的文章，请明确标注 

• 稿件建议以 markdown 格式撰写，文中配图以附件形式发送，要求图片清晰，无版权问题

• PaperWeekly 尊重原作者署名权，并将为每篇被采纳的原创首发稿件，提供业内具有竞争力稿酬，具体依据文章阅读量和文章质量阶梯制结算

📬 投稿通道：

• 投稿邮箱：hr@paperweekly.site 

• 来稿请备注即时联系方式（微信），以便我们在稿件选用的第一时间联系作者

• 您也可以直接添加小编微信（pwbot02）快速投稿，备注：姓名-投稿

△长按添加PaperWeekly小编

🔍

现在，在「知乎」也能找到我们了

进入知乎首页搜索「PaperWeekly」

点击「关注」订阅我们的专栏吧

·

·

·