端到端的开源OCR模型:GOT-OCR-2.0,支持场景文本、文档、乐谱、图表、数学公式等内容识别!

今天给大家分享一个端到端的开源 OCR 模型,号称 OCR 2.0! 支持场景文本、文档、乐谱、图表、数学公式等内容识别,拿到了 BLEU 0.972 高分。

从给出的演示图来看,一些非常复杂的数学公式都能正确的识别,颇为强大。模型大小仅 1.43GB,感兴趣的小伙伴可以试试。

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任务吗?我们的答案是肯定的,而且甚至还能更好。

相关链接

论文地址:https://arxiv.org/abs/2409.0170

代码地址:https://github.com/Ucas-HaoranWei/GOT-OCR2.0/tree/main

模型下载:huggingface.co/ucaslcl/GOT-OCR2_0

GOT: Towards OCR-2.0

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

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

图2. GOT结构与训练流程图 模型的结构和训练方法如图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能力

例5:多页OCR能力

例6:更多符号的OCR能力

总结

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

相关推荐
开源社1 分钟前
一场开源视角的AI会议即将在南京举办
人工智能·开源
FreeIPCC2 分钟前
谈一下开源生态对 AI人工智能大模型的促进作用
大数据·人工智能·机器人·开源
机器之心20 分钟前
全球十亿级轨迹点驱动,首个轨迹基础大模型来了
人工智能·后端
z千鑫21 分钟前
【人工智能】PyTorch、TensorFlow 和 Keras 全面解析与对比:深度学习框架的终极指南
人工智能·pytorch·深度学习·aigc·tensorflow·keras·codemoss
EterNity_TiMe_21 分钟前
【论文复现】神经网络的公式推导与代码实现
人工智能·python·深度学习·神经网络·数据分析·特征分析
机智的小神仙儿38 分钟前
Query Processing——搜索与推荐系统的核心基础
人工智能·推荐算法
AI_小站44 分钟前
RAG 示例:使用 langchain、Redis、llama.cpp 构建一个 kubernetes 知识库问答
人工智能·程序人生·langchain·kubernetes·llama·知识库·rag
Doker 多克1 小时前
Spring AI 框架使用的核心概念
人工智能·spring·chatgpt
Guofu_Liao1 小时前
Llama模型文件介绍
人工智能·llama
WeeJot嵌入式1 小时前
OpenCV:计算机视觉的瑞士军刀
计算机视觉