在 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 任務嗎？
我們的答案是肯定的，而且甚至還能更好
論文地址：https://arxiv.org/pdf/2409.01704
項目地址：https://github.com/Ucas-HaoranWei/GOT-OCR2.0
— 完 —
投稿請發郵件到：
标題注明【投稿】，告訴我們：
你是誰，從哪來，投稿内容
附上論文 / 項目主頁鏈接，以及聯系方式哦
我們會（盡量）及時回複你
點這裏關注我，記得标星哦～
一鍵三連「分享」、「點贊」和「在看」
科技前沿進展日日相見 ~
>
