Vary 团队投稿凹非寺
量子位公众号 QbitAI
在 AI-2.0 时代，OCR 模型的研究难道到头了吗！？
（OCR：一种将图像中的文字转换为可编辑和可搜索文本的技术）
Vary 作者团队开源了第一个迈向 OCR-2.0 的通用端到端模型 GOT。
用实验结果向人们证明：No~No~No~
GOT 模型效果如何？
话不多说，直接上效果图：
△ 最常用的 PDF image 转 markdown 能力
△ 双栏文本感知能力
△ 自然场景以及细粒度 OCR 能力
△ 动态分辨率 OCR 能力
△ 多页 OCR 能力
△ 更多符号的 OCR 能力
研究团队称，尽管 GOT 模型表现不错，但也存在一些局限，如更多的语言支持，更复杂的几何图，chart 上的 OCR 性能。
他们说 OCR-2.0 的研究还远的很，GOT 也还有不小提升空间（该项目在数据和算力资源上都是非常受限的）。
正是因为深知 GOT 以及 OCR-2.0 的潜力，我们希望通过开源 GOT 吸引更多的人，放弃 VQA，再次投向强感知。都说纯 OCR 容易背锅，但也正好说明做的不够 work，不是吗？
GOT: Towards OCR-2.0
通用 OCR 模型须要够通用，体现在输入输出都要通用上。
GOT 的通用具体表现为：在输入方面，模型支持 Scene Text OCR、Document OCR、Fine-grained OCR、More General OCR 等任务。
△ 通用 OCR 模型须“通用”
输出方面，模型同时支持 plain texts 输出以及可读性强、可编辑的 formatted 文本输出，如 markdown 等。
模型的结构和训练方法，采用 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。
△ GOT 结构与训练流程图
研究团队将整个训练过程分为三个步骤，没有一个阶段锁 LLM，过程中没有存在图像到文本的对齐阶段，进而导致损害 image token 的文字压缩率。
三个训练阶段分别为：
第一阶段：高效预训练 encoder，GOT 在整个训练过程中，没有 A100 级别的卡，为了节省资源，该阶段使用小型 OPT-125M 作为 decoder 为 encoder 提供优化方向，快速灌入大量数据。
第二阶段：联合训练 encoder-decoder，该阶段 GOT 的基本结构搭建完成，为上一阶段预训练好的 encoder，以及 Qwen 团队预训练好的 Qwen0.5B。
研究团队稍稍加大了 decoder 的大小，因为该阶段需要喂入大量 OCR-2.0 的知识，而不少数据（如化学式的 OCR）其实也是带点 reasoning 的，不过更小的 decoder 他们未敢尝试。
第三阶段：锁住 encoder，加强 decoder 以适配更多的 OCR 应用场景，如支持坐标或者颜色引导的细粒度 OCR（点读笔可能会用到），支持动态分辨率 OCR 技术（超大分辨率图可能会用到），多页 OCR 技术。
该 feature 主要是为了后续 follower 能更好地训练 Arxiv 这种数据，我们的设想是多页 PDF 直接训练，无须再对 .tex 断页而苦恼！
面对整个 GOT 模型设计中最困难的数据工程环节。研究团队为了构造各种各样的数据，还学习了众多数据渲染工具，包括 Latex，Mathpix-markdown-it，Matplotlib，Tikz，Verovio， Pyecharts 等等。
△ GOT 使用到的数据渲染工具
OCR 的研究才刚刚开始
关于为什么在大模型相互梭哈的时代继续研究 OCR？
研究团队有他们自己的理由：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 任务吗？
我们的答案是肯定的，而且甚至还能更好。
