Unlimited OCR — Baiduのワンショット長文パースモデル

 (github.com/baidu)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • DeepSeek OCR をベースにデコーダのすべてのアテンションを置き換え、数十ページの文書を 1回の順伝播（forward pass） で転写するE2E OCRモデル
  • 中核は Reference Sliding Window Attention（R-SWA） で、デコード長が伸びても KVキャッシュを定数に維持 し、メモリ・計算コストの増加を防止
  • 本を書き写す人間の 作業記憶（working memory） を模倣し、離れた出力はなだらかに忘れ、隣接する文脈だけを参照する方式を採用
  • OmniDocBench v1.5で 93% を記録し、DeepSeek OCR比で6%優位、v1.6では93.92%でend-to-end SOTA を達成
  • R-SWAはOCRを超えて ASR・翻訳 など、参照ベースの長文タスクにも適用可能な汎用パース用アテンション機構

背景と問題設定

  • 人間は数百ページの転写や数時間の音声翻訳のような長文タスクでも効率を落とさず実行できるが、既存のOCRモデルは単一の順伝播で10ページすらパースできない
    • 現在のモデルはページごとの処理（for-loop）方式で、各ステップごとにメモリを初期化する
    • この方式は、一貫した長文処理を孤立した短期タスク群へ分断する エンジニアリング上の迂回策 にすぎず、AGI志向の知能への進展ではない
  • LLMをデコーダとして使うと、言語の事前分布を活用して性能は向上するが、出力が長くなるほど蓄積された KVキャッシュ がメモリ消費を増大させ、生成速度を徐々に低下させる
  • 人間の転写行動は、標準的なfull attentionでもlinear attentionでもない
    • すでに書いた全文を再度なぞるのではなく、隣接文脈だけを参照 して方向性を保つ
    • 視覚／参照トークンは循環的な状態更新を受けない — 更新すると視覚特徴が徐々にぼやけ、認識精度が低下する

Reference Sliding Window Attention（R-SWA）

  • 各トークンはすべての 参照トークン（視覚トークン + プロンプト）にアクセスしつつ、出力アテンションは直前のn個のトークン（デフォルト値128）にのみ制限
    • これにより各トークンは画像全体を認識しながら、因果的スライディングウィンドウ内の状態遷移によってOCRの進行状況を自律的に追跡する
    • 推論中のKVキャッシュを定数に維持し、メモリ負荷の緩和と計算コスト削減を実現
  • アテンションをサイズm+nの2区間ウィンドウに制限
    • mは視覚トークンとプロンプトを含む prefixウィンドウ で、単一推論中は固定され、ページ数・解像度のみに依存し、デコード長には依存しない
    • nはデコード領域のウィンドウで、サイズ固定のまま因果的にスライドする

  • KVキャッシュ管理

    • DeepSeek OCRベースラインは標準MHAを使用するため、KVキャッシュサイズが Lm + T として無限に増加する
    • R-SWAはprefixキャッシュ全体Lmは維持しつつ、生成分は最新n個のみ保持し、キャッシュサイズを Lm + min(n,T) ≤ Lm + n に抑えて定数上限化
    • 出力長が十分長くなるとキャッシュ比率ρ(T)は0に収束 → 線形増加を定数に削減

  • カーネル分析

    • Flash Attention v3カーネルの測定では、DeepSeek OCRの標準MHAはデコード段階ごとにレイテンシが増加する一方、Unlimited OCRはR-SWAにより持続時間を一定に維持
    • DeepSeek OCRはKVキャッシュ長が特定のアライン境界を超えるとデータ転送効率が急落しスパイクが発生するが、R-SWAでは発生しない
    • 推論時のGPUメモリも元モデルは線形増加するのに対し、Unlimited OCRは固定維持 — 計算・メモリ両面の安定性が長文パースを可能にする

モデルアーキテクチャ

  • DeepSeek OCRをベースラインとし、DeepEncoder と MoEデコーダ（総計3B、アクティブ500Mパラメータ）を結合
    • 既存のMHAをR-SWAに置き換え、参照KVキャッシュmに固定容量の出力KVバッファnを加えて長文パースを実現
    • KVキャッシュはm+n容量のキューとして実装され、新しいトークン生成のたびに（m+1）番目のトークンのKVを追い出し、コスト・メモリが増加しないことを保証

  • DeepEncoder

    • SAM-ViTとCLIP-ViTをカスケードし、ブリッジで16倍のトークン圧縮を適用 — 前半はウィンドウアテンションで元画像トークンを処理し、グローバルアテンションは圧縮トークン専用
    • 高解像度画像エンコード時も活性値を低く保ってGPUメモリを節約し、1024×1024のPDF画像をわずか256トークンに圧縮
    • マルチページ向けの「Base」（1024×1024）と、単一ページ向けの「Gundam」（動的解像度）の2モードを採用
    • 視覚トークンは出力とともに状態遷移を受けず、1度だけエンコードされて全工程で静的に維持される

学習設定

  • 約200万件の文書OCRデータで学習し、単一ページ対マルチページの比率は9:1
    • 単一ページPDFはPaddle OCRでアノテーションし、各ブロックの座標と内容を連結してground truthを構成、座標は0–1000範囲に正規化
    • マルチページは単一ページを連結して合成し、約20万サンプル（2〜50ページ）で <page> 区切りを使用、全体を32Kトークン列としてパッキング
  • DeepSeek OCRチェックポイントから4,000ステップ追加学習し、グローバルバッチ256、最大シーケンス32K、8×16 A800 GPU を使用
    • 学習中はDeepEncoderを凍結し、LLMパラメータのみ学習
    • AdamWオプティマイザ、コサインアニーリングスケジューラ、初期学習率1e-4、DeepEP（EP=4）、Megatron-LMフレームワークベース
    • 推論ではTransformersライブラリにR-SWA向けのKVキャッシュ管理を実装し、SGLangエンジンに最適化サポート — 両フレームワークとも定数TPS・GPUメモリで動作

評価結果

  • 主ベンチマークはOmniDocBench（v1.5/v1.6）で、テキスト・数式・表構造・読み順など多次元のパース能力を評価
    • v1.6はv1.5よりテスト画像が296枚追加された最新版で、v1.5はDeepSeek OCRを含む従来モデルとの比較を提供
    • 長文OCR評価用の独自テストセットを構築し、小説・文書・論文を2/5/10/20/40+ページに分類（各カテゴリ10冊以上）

  • 主要性能

    • わずか2Mデータの追加学習だけでend-to-end SOTAを達成し、v1.5でテキスト編集距離を 0.035低減、表TEDSを 5.96%改善
    • v1.6総合指標 93.92% でend-to-end SOTA — 幅128のR-SWAで標準アテンションを全面置換しても有効かつ無損失であることを実証
    • MoEアクティブ0.5Bパラメータによる高効率推論で、「Base」モードでは 5580 TPS（DeepSeek OCRの4951 TPS比で12.7%高速化）

  • 下位カテゴリ分析

    • DeepSeek OCR比で全指標にわたり一貫した向上を示し、「ただ乗りの改善（free lunch）」級の改善を実現
    • DeepSeek OCR 2比ではテキスト編集距離・読み順の両方で9項目中7項目で優位
    • PPT・新聞・雑誌・ノートなど複雑なレイアウトでも劣勢はない

  • 長文パース

    • R-SWA搭載により数十〜数百ページを単一パスでprefillし、最初のページから最後まで連続パースしながらKVキャッシュ固定で出力レイテンシを一定に維持
    • 20ページ同時入力でも堅牢な結果を示し、40+ページで編集距離0.11未満、Distinct-35 97% を維持
    • 反復エラーはマルチページ「Base」モード（1024×1024）で小さな文字の識別が難しいことに起因し、R-SWAの方向喪失が原因ではない

効率分析

  • 理想的な同時実行条件での出力TPS比較（prefill長10固定）
    • 256トークンでは両モデルの推論速度はほぼ同一
    • 出力長が増えるとDeepSeek OCRのTPSは着実に低下し、6,000トークン時点でUnlimited OCRより35%遅い
    • 一貫した生成速度が長文OCRタスクの中核要件であることを再確認

限界と今後の課題

  • 有限のコンテキスト長（例: 32K）ではprefill長の制約により真の無制限パースは不可能 — DeepEncoderの高圧縮率にもかかわらず、ページが蓄積するとprefillが長くなる
  • 短期的には128Kなどより長いコンテキストモデルを学習し、より多くのページのprefillをサポートする予定
  • 長期的には prefill pool を構築し、モデルがprefill KVチャンクを自動でfetchするよう学習させることで、人間がページをめくる効果を模倣し、真の無制限OCR達成を目指す
  • R-SWAを ASR・翻訳 などの参照ベースタスクへ移行する計画

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの意見

  • かなり興味深い。理解した限りでは、研究チームは長文書を読むときにAIがメモリを延々と積み上げ続けないようにするアーキテクチャ上のハックを見つけたようだ。
    通常、AIが100ページのPDFを転写するときは、すでに読んだすべての単語を記憶しようとし、この短期記憶であるKVキャッシュが O(N) で線形増加して、VRAMが尽きるか制限に引っかかる。だから開発者は、PDFをページごとに分割して処理し、あとでつなぎ直す雑なコードを書くことになる。
    Unlimited OCRはReference Sliding Window Attention（R-SWA）によって焦点を2つの経路に分けている。1つは元の文書画像全体を見るグローバル参照、もう1つはモデル自身が生成したテキストの記憶を、直近128語のような狭いスライディングウィンドウに制限するローカル生成だ。ローカルAIにとってかなり面白そうで、コミュニティが何を作り、どう拡張していくのか楽しみだ。

    • 会話にもまさに当てはまる点があるように思う。かなり前から長い会話のカプセル化を試してきたが、あまり変化しない上位の文脈や事実があり、参加者の名前や背景のような情報はそこに属する。
      一方で、今朝何を食べたかのような非常に細かい事実は、その場では有用でも、長期的には一般的な傾向以外ほとんど意味がない。会話を再構成するには、これまで議論されたすべてを引っ張り出さずに適切なバランスを見つける必要があるので、この方式はさらに見る価値がありそうだ。
    • 論文全体はまだ読んでいないが、ローカル生成ウィンドウは少し小さく見える。特に画像入力はトークンを多く使うので、ローカル注意レイヤーがどこにあるかにもよるが、最低でも4096語程度でもっと大きいほうがよさそうだ。
    • 画像OCRをするときは、まさにこのようにしている。大きな画像1枚を複数の小さな画像に切ってLLMに送ると毎回完璧だったが、画像全体を入れると結果はひどかった。
    • 主要なLLMツールはすでにスライディングウィンドウ注意をサポートしているものだと思っていた。
    • だからLeetCodeは役に立つ。LeetCodeを解き続けていると、こうした手法がなぜ存在するのか、そして実際にどう使われるのかが見えてくる。興味深いものが多い。

  • 最近、楽譜用のタブレットを買った。主な目的は、ジャムセッションでジャズの Real Book 集を置き換えることだった。スマホのカメラでスキャンしたものでもそこそこ使えるが、サイズが固定でノイズも多い
    Bb や Eb 楽器向けにその場で移調できれば理想だが、スキャン画像なので当然無理。光学楽譜認識の現状を掘ってみると、音楽は AI の観点ではほとんど未開拓に近いという結論になる。光学楽譜認識はかなり出来が悪く、AI の音楽理論理解も、実際の楽譜を見る領域ではひどい。LLM は、オンラインのテキストが学習に入っていそうな理論概念の文章説明ならそこそこうまくできる
    問題は、音楽家が紙の上の点として読む情報をきちんとエンコードできるデジタル形式がまだ不足していることにあるようだ。楽譜表記はかなり豊かだ。MIDI は主に再生や演奏に必要な側面を扱うために作られているので、記号的理解に必要なすべてを保持できない。MusicXML は音楽家が欲しがる情報を格納するデジタル形式として最も近そうだが、MusicXML 表現と楽譜画像や音声を結び付けた良質な学習コーパスが不足している。MusicXML だけでは楽譜の組版に必要な情報が十分でないからだと思われる
    MuseScore のようなツールは、MusicXML では表現できないレイアウト情報を大量に追跡しなければならない。LilyPond 形式は MusicXML より冗長さが少なく、譜面制作者に有用な情報もやや多く含むが、ほとんどの人は LilyPond で楽譜を作らない。付け加えると、ジャズ用フォントの事情のせいで LilyPond には不満がある。ジャズの文脈で「クラシック風」の譜面を見るのは嫌だ。OCR の着実な改善を見るたびに、OMR の惨状を思い出す

    • 音楽学者や音楽研究者が使う形式は MEI: https://music-encoding.org/。そして基準となる組版エンジンは verovio: https://www.verovio.org/index.xhtml
      verovio は、元の MEI 楽譜の情報をできる限り保ったまま SVG 形式に組版できるため、ディープラーニングモデル向けの実際の検出データセットを作れるだけのメタデータを抽出できる。verovio で組版した楽譜セットから COCO データセットを作る雑なハックスクリプトもある: https://github.com/kwon-young/music/blob/main/svg2pl.py
      ここで作られた合成楽譜データセットも公開されている: https://www.kaggle.com/datasets/kwonyoungchoi/trompa-coco/da...。この上で検出器を学習してみたい人は歓迎する。OMR がこれほど放置されている理由は、たいていの人がこの作業の難易度を大幅に過小評価しているからだ。極端に多様な形状と、非常に複雑なグラフィック文法が混在する特殊な作業だ
    • 「音楽は AI から見るとほとんどどこも未開拓地」というのは本当にその通り。恋人が音楽学を学んでいて、身体障害のために時々ノートを取るのが難しいので、AI ベースの TTS/OCR のようなアプリを少しずつ作って手伝っている
      そうしていると、音楽がどの AI 学習データセットでも重要な要素として考慮されたことがないのが痛いほど明白になる。最近の Opus 4.8 は音楽理論を理解して説明する能力はかなり驚異的だが、楽譜の書き起こしや OCR/OMR をさせると、自信満々に MusicXML/LilyPond 版の「2 + 2 = 馬」のような結果を出してくる。この無視されてきた領域も、膨らみ続ける AI の波に乗ってほしいが、今のところ不当に過小評価されている
    • コード分析だけが必要なら、音を曖昧さなく表現しようとする Harte 記法がある: https://ismir2005.ismir.net/proceedings/1080.pdf
      もちろん、組版や音楽全体の表現に必要な追加情報まですべて与えてくれるわけではないが、https://github.com/smashub/choco のような研究データセットがある。分析作業には https://github.com/MarkGotham/When-in-Rome データセットも使ったことがあるが、これも求めているものと 100% 一致するわけではない。タブレットでのジャズスタンダード代替と移調用途なら、「iReal Pro」アプリが気に入るかもしれない。カメラスキャンより、その用途にはかなり向いている
    • https://abcnotation.com/ のような 楽譜組版形式はどうだろう?
    • 音楽 OCR の分野を見ていると、今のところ本当にまともな解決策は soundslice だけのように思える。スキャン後に一部のエッジケースだけ確認すれば、結果はかなり良い。小さな会社の有料サービスだが、十分支援する価値がある

  • 「Deepseek-OCR、Deepseek-OCR-2、PaddleOCR の価値あるモデルとアイデアに感謝する」と書いてあるのは、品のある態度だ

    • なぜ皮肉るのか理解できない

  • ちなみに「Unlimited OCR Works」は Fate/stay night の Unlimited Blade Works のパロディだ。元の Unlimited Blade Works は、他人が作った武器を複製する魔法という設定になっている

  • 論文は https://arxiv.org/abs/2606.23050 にある
    ちなみに、自分は本で読んだ引用文のための小さな RAG 用途でローカル OCR を使っていて、RAM を節約するために入力をチャンクに分けてもいるのだが、こうした自然なアプローチがストリーミングモデルでも通用するのは興味深い

  • Mistral がたった今リリースしたものより有望に見える。偶然かって? そうは思えない
    このアプローチは画像生成にも何らかの形で応用できそうだ。画像を読んだり見たりしたあと、Illustrator や Inkscape のようなツールや SVG で描き始め、欠けた部分をあとで埋めるようなことができそうに思える

  • これが、他の OCR ツールを圧倒しているように見えた infinty parser 2 と比べてどうなのか気になる: https://huggingface.co/datasets/allenai/olmOCR-bench
    公平に言えば、単一の勝者を決める OCR ベンチマークはなく、このツールもまだどこにも載っていない

  • 世間知らずみたいに聞こえるかもしれないけれど、企業が本当に優れたソフトウェアをオープンソースとして公開する実際の理由は何なのだろう？
    Baidu や Google なら、競合に真似されないよう自社だけで保有して価値を引き出すべきではないのか？

    • 大企業の中にも オープンソースの理想 を信じ、雇用主を説得してプロジェクト公開の許可を得る人たちがいる
      企業は評判を得られ、それが採用ファネルの助けになる。ときには Meta が Ollama を公開したように、戦略的に競合を揺さぶることもできる
    • オープンソースのモデル公開は、米国の AI 研究所の売上を奪える可能性がある。そうした研究所が長期競争で勝つために再投資する資金を減らせれば、中国に有利に働くかもしれない

  • AI で OCR を試した取り組みでは、いつもでっち上げた結果が混ざっていて、そのため本番環境で使いにくかった。これにもそういう問題があるのか気になる
    簡単な例では、別の言語のままであるべき単語が自動的に英語へ翻訳されてしまい、効果を損なうことがある

    • ほぼ単語より大きいレベルの機械学習、つまり単語対・句・文・文書・コーパス単位のものは望まなくなる
      転写では、ほぼ確実な結果か、あるいは確実に読めなかったという表示が欲しい。文脈から推測することはできても、ある OCR が文字が順番に並んで単語を成すという事実以外の根拠で推測したのかどうかは分かる必要がある
      たとえば familysearch.com の国勢調査文書で、転写者が名前を Joseph と「修正」したが、手書き文書の実際の文字は Josepth で、実際にその地域の異綴りだった。別の文書では、記入者が "Joh" を略語として使っており、おそらく人間の転写者が John と転記したのだろうが、もっともらしくても実際には誤りだった。推測であること自体が重要な場合もあれば、単に最善の推測が必要な場合もある
    • 100% の認識結果が欲しいなら、この方法に原本文書再構成画像モデルを組み合わせるだろう。転写テキストとレイアウトを合わせて、原本文書を再生成させる方式だ
      テストしたいページや段落だけを除いて残りの文書を使えば、画像アーティファクトから試験対象の句をそのまま再生成してしまうのを避けられる。再構成後は、ずれた文字を特定して突き合わせる光学比較を行い、誤りを見つけて反復すればよい。高価にはなるだろうが、100% の認識を保証できる
    • 4090 でこのモデルを使って日本語文法の PDF を転写している。英語で書かれていて日本語の例文が多い文書だが、自分が一部照合した範囲ではかなりうまく動いている
      出力は必要な箇所で漢字・ひらがなと英語を適切に維持し、翻訳しようとはしない。1 時間あたり約 200 ページを変換した
    • これまでどのモデルやツールを使ってきたのか気になる

  • Reducto がどうなったのか分からない。12〜15 か月前にはかなり有望に見えた