通用端到端OCR模型開源，拒絕多模態大模型降維打擊
在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任務嗎？
我們的答案是肯定的，而且甚至還能更好
