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任務嗎？
我們的答案是肯定的，而且甚至還能更好
— 完 —
量子位 QbitAI · 頭條号簽約
關注我們，第一時間獲知前沿科技動态