- 「テキストを画像として表現すれば、はるかに少ないトークンで同じ情報を保持できる」 という洞察から出発
- テキスト情報を 2D視覚表現に圧縮する新しいアプローチを提案したモデルで、長いコンテキストを効率的に扱うための ビジョンベース圧縮（Optical Compression） の概念を実験的に検証
- モデルは DeepEncoder（エンコーダ） と DeepSeek3B-MoE-A570M（デコーダ） で構成され、高解像度入力でも低いアクティブメモリと 10〜20倍レベルのトークン圧縮率 を達成
- 10倍圧縮でも97%のOCR精度、20倍圧縮でも60%以上の精度 を維持し、これは 長文コンテキスト圧縮・記憶忘却メカニズム研究 に実質的な可能性を示す
- OmniDocBench では GOT-OCR2.0（256トークン/ページ）と比べて 100個のビジョントークンだけで上回る性能、MinerU2.0（平均6000+トークン/ページ）と比べて 800トークン以下で優れた性能 を記録
- 単一のA100-40G GPUで 1日20万ページ以上のデータ生成 が可能で、LLM/VLM大規模学習用データエンジン として実用価値が高い
1. 研究背景
- 既存のLLMはシーケンス長に応じて 計算量が二乗で増加 するという構造的限界を持つ
- 論文は 「テキストを画像として表現すれば、はるかに少ないトークンで同じ情報を保持できる」 という洞察から出発
- これを 視覚トークンベースの長文コンテキスト圧縮（Context Optical Compression） と定義し、OCRをその実験の舞台に設定
- 結果として 視覚表現がLLMのコンテキスト処理効率を改善できる新しい経路 を示した
2. モデル構造
- DeepSeek-OCR = DeepEncoder + DeepSeek3B-MoE デコーダ
- DeepEncoder: SAM（Window Attention） + CLIP（Global Attention） + 16倍トークン圧縮器
- DeepSeek3B-MoE: 64個のエキスパートのうち6個を活性化、合計 570Mアクティブパラメータ
- マルチ解像度モード をサポート（Tiny〜Gundam）
- 512〜1280解像度入力をサポートし、最大9個のタイルを合成処理
- Gundamモードは超高解像度文書（新聞など）に対応し、最大800ビジョントークンを使用
3. データエンジン
- 合計3種類のデータ構成:
- OCR 1.0データ: 30Mページ（100言語）文書ベースで、詳細なレイアウト・テキスト注釈を含む
- OCR 2.0データ: チャート・化学式（SMILES）・幾何図形など複合認識用の16Mデータ
- 一般ビジョンデータ: CLIPベースの視覚理解維持用で、全体の20%
- テキスト専用データ: 10%比重で言語能力を補完
- 全体の学習データ構成比率
- OCR 70% / ビジョン 20% / テキスト 10%
4. 学習パイプライン
- DeepEncoder → DeepSeek-OCR の2段階で学習
- 合計20ノード（8×A100 GPU）で データ並列度 DP=40、グローバルバッチ 640
- 学習速度: テキストデータ 90Bトークン/日、マルチモーダルデータ 70Bトークン/日
5. 評価結果
(1) 圧縮実験（Foxベンチマーク）
- 10倍圧縮で 97%の精度、20倍圧縮でも 60%以上を維持
- 文書が長い、または複雑であるほど性能低下が発生するが、これは 「忘却メカニズム」シミュレーションの可能性 と解釈できる
- 圧縮率10×以下では ほぼ損失のないコンテキスト復元 が可能
(2) 実文書認識（OmniDocBench）
- Tiny（64トークン）〜Gundam（800トークン）モードを比較
- GOT-OCR2.0（256トークン）と比べて Small（100トークン）モードで優位
- MinerU2.0（7,000トークン）と比べて Gundam（800トークン）で上回る性能
- 文書タイプごとに必要トークン数は異なる
- スライド、レポート: 64〜100トークンで十分
- 新聞、論文: 400〜800トークンが必要
6. 質的分析（Qualitative Study）
- Deep Parsingモード
- チャート、図形、化学式、自然画像まで 単一プロンプトで構造的抽出 が可能
- 多言語認識
- 約 100言語のPDF をサポートし、アラビア語・シンハラ語など少数言語も含む
- 一般視覚理解
- 画像説明、物体検出、グラウンディングまで実行
- LLM連携時には ビジョン・言語の複合推論の基盤モデル として活用可能
7. 議論と示唆
- DeepSeek-OCRは ビジョントークンベースの長文圧縮の境界 を探る初の実験として、
「1枚の画像は千の言葉を含む」という概念を定量化した
- 圧縮率10×でもほぼ損失のない復元が可能 → 対話履歴圧縮、長期記憶最適化 などへ拡張可能
- 「時間の経過とともに画像解像度を下げる方式」 により、生物学的忘却曲線に似たトークン減衰シミュレーション を提案
8. 結論
- DeepSeek-OCRは テキスト-視覚間の10〜20倍圧縮マッピングの実証モデル として、
LLMの 長文コンテキスト処理限界の克服 に向けた新しいパラダイムを提示
- OCRを超えて、今後は デジタル・光学混合プリトレーニング および
「Optical Context Memory」ベースの超長期コンテキストモデル へ拡張される見込み
- コードは公開されており、研究および商用データエンジンとして活用可能
- DeepSeek-OCRは既存の OCR オープンソースと比べて、視覚情報を効果的にエンコード する大規模言語モデル（LLM）ベース構造として注目される
- 多様な 解像度サポート（512×512〜1280×1280） と、動的解像度向けのGundamモードが含まれ、さまざまな環境への対応力が高い
- 明確なプロンプト設計により 一般画像説明、Markdown変換、レイアウト無視OCR、図表パースなど多様な作業モードをサポート する
- Fox、OminiDocBench など業界ベンチマークとの連携性能を確認し、実文書処理実験ベースの検証を実施している
- GOT-OCR2.0、PaddleOCR など 他の人気プロジェクトの長所とアイデア を取り入れて実装されている
- 対応解像度
- Tiny: 512×512（64 vision tokens）
- Small: 640×640（100 vision tokens）
- Base: 1024×1024（256 vision tokens）
- Large: 1280×1280（400 vision tokens）
- Dynamic mode（=Gundam）: 自由解像度（n×640×640 + 1×1024×1024）
- PDF、画像に対する並列推論および高速処理速度
- A100 GPU基準でPDF処理は約2,500トークン/秒が可能
- 技術的背景およびエコシステム連携
- Python 100%で実装 されている
- vLLM・Transformers の2つの主要推論環境をどちらもサポート
- OpenChart、Fox、OminiDocBench など主要ベンチマークおよび評価フレームワークを活用
- GOT-OCR2.0、PaddleOCR、Vary などの先行モデルと連携し、アイデアを借用し、性能を強化
1件のコメント
Hacker Newsの意見
この論文は、OCRのための単なる別のVLMにとどまらず、圧縮などのより興味深いテーマへ進んでいる
たとえば、「私たちはビジョン-テキスト圧縮の限界を探る初期研究を行い、テキストトークンを復号するためにいくつのビジョントークンが必要かを調べた。予備結果として、DeepSeek-OCRは約10倍の比率でほぼ無損失のOCR圧縮を達成し、20倍に圧縮しても60%の精度を維持した」という引用がある
直感的には、ビジョントークン1つがテキストトークン10個分の情報を持つ計算になる
情報理論的に、なぜこのような結果になるのかを初心者にも分かるように説明してほしい
テキストトークンがまだ細かすぎるだけなのか（冗長だったり、エントロピー符号化に達していなかったりするのか）、それともビジョントークン方式に移ることで「単語単位」の限界を離れ、エントロピーに近づけるのかが気になる（算術符号化とハフマン符号の違いのように）
また論文では、大規模コンテキストを扱う際に実際に画像をダウンスケールし、テキストドメインと画像ドメインにおける情報損失の対応関係も議論している
テキストトークンは量子化された下位単位（サブワード）であり、ビジョントークンは埋め込み空間にのみ存在する
LLMにおけるテキストのトークナイズ方式は、（小さい）トークンIDと（大きい）ベクトル埋め込みのルックアップテーブル構造になっている
テキストをLLMに渡すときは、文字列をトークン境界で切り、トークンIDに変換し、その後ルックアップテーブルからベクトルを取り出して行列（context matrix）を作る
実際のテキストトークン列の送信は効率的だ。単に数字の配列（ID）を渡せばよいからだ（通常はおよそ10万個の一意なトークンID）
逆に埋め込み行列そのものを送るのは非効率的で、埋め込みは数千個の浮動小数点数で構成される
画像は異なる形でエンコードされる。画像データを前処理し、そのままニューラルネットワークベースの画像エンコーダに入れてベクトルへ変換し、そのベクトル群をコンテキストに結合する
つまり画像トークンにはトークンIDもルックアップテーブルもなく、データから直接埋め込みへ進む
結果として画像トークンを送るには埋め込みそのものを送る必要があり、非効率になる
画像がより少ないトークン数でエンコードされても、各トークンの容量ははるかに大きい
要するに、テキストトークンは整数（0〜n）からベクトルへの対応が明確で、したがって「n」通りの選択肢しかない
一方、画像トークンはm次元の浮動小数点配列（ベクトル）なので、はるかに大きなトークン空間を持つ
パターンの面でも、テキストトークンは連続したUTF-8バイトに直接対応し、多くの場合は単語境界から大きく外れないため、グローバルなパターン（例:「この台詞はハムレットのもの」「この部分はスペイン語だ」）を単一トークンで表すことはできない
マルチモーダルLLMで画像入力をどう埋め込んでいるのかは正確には分からないが、基本的には画像をグリッドに切り分けて各領域をエンコードすると理解している
DeepSeekの実験で出ているのは情報理論的な性質というより、どれだけ解像度を落としたりグリッド（パッチ）サイズを小さくしたりしても、なお十分なディテールを保持して正確にOCRできるか、という点が核心に見える
KarpathyがNanoChatをマルチモーダルに拡張して、この種のエンコードプロセスの知見を共有してくれたらと思う
適切な圧縮率は結局、1文字あたりの解像度と各ビジョントークンのパッチサイズの相対的な大きさに依存せざるを得ない
そうでなければ、最終的にOCRで抽出されたテキストトークン数を画像解像度と独立に保つことはできない
各テキストトークンは主にsubword単位だが、VLMのビジョントークンは意味空間（semantic space）に置かれる
意味空間はsubword分割よりもはるかに強力に情報を圧縮できる
参考までに: 専門家ではなく、即興で考えた内容
LLMはトークン数に応じて計算量が二乗で増える構造だ
そのためVLMではテキストトークンをビジョントークンへ圧縮しようとする
おそらく、まずテキストを画像としてレンダリングしてからトークナイズし、計算コストを減らそうとしているのだと思う
NVIDIA Spark(ARM64)でPyTorchはやや厄介だが、Claude Codeをroot権限で新しいDockerコンテナ内で実行したら動かせた
詳しいノートはこちらで見られる
実際の出力結果はこのリンクで確認でき、OCR画像の元データ（こちら）を対象にテストしている
OCR結果は全体として非常に堅実だ
ただし引用文のすぐ下の段落で不要な内容を付け足してハルシネーションを起こし、その次のカラムとつなげてしまっていた
迅速なテストの実施に感謝する
テキスト冒頭の「A」を取りこぼしたのは理解できる（おそらくデータセットにニュース記事の比率が低かったのだろう）
しかし「Hallucination is a risk and...」全体と、著者の横の話題（"theme"）および最後のメール部分まで完全に抜けている点のほうが興味深い
この実験だけでも別の投稿にする価値があると思う
「Claude Codeを新しいDockerコンテナでrootとして実行」
root権限で実行させる設定方法を具体的に知りたい
（もし説明があるなら本文で確認する）
論文ではAnna’s Archiveへの言及がない
DeepSeekが、OCR研究者に750万冊（350TB）の中国語ノンフィクションコレクションへのアクセスを許可するというAnna側の提案を実際に活用した可能性があると思う
この量はLibrary Genesisよりも大規模だ
参考ブログ
DeepSeekの過去の論文ではAnna’s Archiveに直接言及している
「Anna’s Archiveから860K冊の英語、180K冊の中国語電子書籍、および数百万件のK-12教育用試験問題を精製した」
DeepSeek-VL論文 参照
他人の本を保管しているという理由で、わざわざアクセス権を得る必要があるのか疑問だ
私もすぐにAnna’s Archiveを思い浮かべたし、いつOCR処理済みのデータセットが公開されるのか気になる
それはつまり、データセットが永久に公開されない可能性を意味する
こうした状況だと、Anna’s Archiveも結局はLLM企業に濫用されて消えてしまうのではと心配だ
METAがlibrary genesisから70TBをtorrentで吸い上げた件だけでも十分なのに
現在のベンチマークと実際の水準についての経験共有
OmniAIベンチマークはあまり良くない
代わりにOmniDocBenchを勧める
Mistral OCRはオープンソースOCRモデルやGeminiに比べて明らかに劣る
E2E OCRは依然として非常に難しい
パイプライン方式（レイアウト検出 → 読み順の決定 → 各要素のOCR）のほうがうまく機能する
複雑な表の解析は依然として大きな難題だ
Apple Vision Frameworkもこうしたモデル群と比較ベンチマークされた例があるのか気になる
ほぼすべてのAppleデバイスに内蔵されていて、実際に高品質かつ高速なOCRを出せるのに（特にPDF変換用途）、あまり知られていないように思う
ベンチマーク上でどのあたりに位置するのか非常に気になる
OmniAIベンチマークによればOmni OCRが最高性能を示している
みんなこういう結果に何の疑問も持たないのだろうな
LLMベースのOCRがAzure AI Document Intelligence(リンク)、Google Vision API(リンク)のようなサービスと比べて、どんな利点や違いがあるのか気になる
OmniAIでは自社LLMとクラウドOCRを相互にベンチマークしている
OmniAIブログのベンチマーク（2025年2月時点）
その後LLMは急速に進化した
Qwen3-VL系、特にQwen3-VL-235B-A22B-Instructの結果が最近では最も良く見える
私の予想では、商用・独自OCRモデルのほうが実際の文書では引き続き優れていると思う
高品質なプライベート学習データセットを大量に持っているためだ
公開LLMはarxivや電子書籍など論文中心のデータで訓練されているので、実務文書ではどうしても劣るはずだ
LLM方式は文字の置換ミス（誤字、変形）は減らすが、ページ全体レベルの一貫性はむしろ低い
非OCRのLLMのように完全に的外れな結果を出すこともある
CJK文字では従来方式のOCRは依然として不適切な置換を多く生む
非常によく似た文字が多すぎて、顕微鏡レベルやバイナリレベルでしか区別できない場合もある
LLMはあり得る文字列シーケンスにより強い制約をかけられるので、より正確な結果を期待できる
少なくとも、こうした悩みそのものがLLMベースOCR導入の動機にはなる
他のモデルは分からないが、うちの会社ではAzure AI Document Intelligenceで履歴書解析システムを回していて、かなり満足している
最初に少しチューニングへ気を配ればよく、ここ1年ほどはほとんど手を入れていない
複数のVLM（Granite、Qwenなど小型から大型まで）を試したが、既存OCRを完全に置き換えるには期待外れという結論だ
私たちのシステムは顧客文書を受け取り、要求どおりにマークアップされた標準文書（ラスタ方式のマルチページビットマップ）を返す構成だ
私たちにとってはデータから個々の文字や単語レベルまでの座標抽出精度が重要だが、実際にはVLMの位置情報はばらつきが大きすぎるか、完全に幻覚的（hallucinated）か、曖昧すぎて、求める精度や粒度を保証できない
現時点ではTesseractベースに結果のクリーンアップルーチンを使い、構造化データセットがないときだけVLMのテキスト出力を補助的に使うことがある
うちのケースはかなりニッチで、多くの人にとっては単なるテキストダンプやMarkdown/HTML変換ができれば十分なのだろうと思う
しかし、こうしたモデルが「OCRを完全に解決した」とする主張と、実際の体験との間にはかなり大きな隔たりがあると感じる
moondream 3 previewモデルを試してみてはどうかという提案
ブログ記事では複数のVLMの性能を上回るとされており、軽量モデルでもある
メインページ、モデル、ブログ 参照
顧客文書には手書き文字は含まれていないのか気になる
先にCNNでテキストのバウンディングボックスを見つけて、各ボックスごとにVLMを実行する方法もあり得る
個人的な印象では、OCRはある程度解決済みの問題だと感じていた
OmniAIベンチマークも最近のモデルに更新されていないが、その理由は汎用LLMがそのベンチマーク自体のOCRより良くなったからだと思っている
実際、各ページ画像をGemini 2.5 Flash Liteに入れてMarkdown形式で抽出させると、約1000ページあたり20セント程度のコストで、結果も非常に良かった
最近のOCRで難しい点は何なのか気になる
ほとんどのOCR/LLM（特にGemini Pro 2.5）でさえ、複雑な表 → Markdown/HTML変換は依然として苦手だ
複数ヘッダー、結合セル、チェックボックス付きの列などで問題が頻発し、複数ページにまたがる表も正しく理解できない
Llamaindexも同様にひどく失敗する
どのOCR/LLMがこうした問題により強いのか気になる
複雑な表の例, ICAOチェックリスト全体の例
実際にはOCRではなくHTR（手書き文字の転写/認識）が依然として厄介だ
LLMのおかげで精度はかなり改善したが、ミスは人間にも見つけにくくなった（読めない部分を勝手に作り上げてしまう）
認識できない部分を「分からない」と示さず、完全に想像で埋めた結果を受け入れられるなら、たしかに問題なく解決されたと言える
（皮肉ではなく、状況によっては本当にそれでよい場合もある）
私はOmniAIベンチマークの著者だ
最新モデルへの更新がない理由は、OCR API自体をプロダクト内で縮小したからだ
内部では今も使っているし、ベンチマークは面倒で最新化していないだけだ
GeminiはOCRに最も優れている
ただし、学習データに近すぎる結果が出ると、出力の約10%が突然途切れる「recitation」エラーが頻繁に発生する
PDFミックスに空白ページが入ると、妙な内容を新たに作り出すおかしなハルシネーションもある
OpenAIも悪くはないが、GPT5はGPT-4oや4.1と性能差がない
ヘッダーやフッターなど一部の内容がしばしば消え、ページが横向きに回転しているとおかしくなる
身分証、医療文書、PIIリスクの高い内容を自発的に拒否することも多い
絶対に解決済みの問題ではないと感じる
独特なレイアウトの雑誌をOCRしようとすると不可能だ
ヴィンテージ雑誌を集めていて、常に最新技術でOCRを試しているが、結局いつも大量の人手が必要になる
小さな「OCRモデル」はないのだろうか
製造現場の写真からシリアル番号だけを抜き出したく、文書全体の解析は不要という状況だ
30億パラメータのモデルでこの程度の作業をするのは大げさすぎる
DeepSeek-OCRがTesseract(リンク)と比べてどうなのか気になる
私はocrmypdf(リンク)を愛用していて、ローカルで非常にうまく使えている
実際にtesseractが80%の性能で、最新モデルが95%まで上がるとしても
その代わりにストレージ100倍、Kubernetes/Docker、GPU 16GB VRAMなどのインフラ要件を背負う構図なら、十分に検討の余地がある
最新研究を追えていない立場として、これが何で、なぜ重要なのかをELI5で分かりやすくまとめてくれる人はいないだろうか
GitHubや論文のタイトルはOCRなのに、要約やreadme.mdではLLMコンテキスト圧縮の話をしていて混乱する
この2つがどうつながるのか、上位の文脈で説明してくれる人を探している
その画像は「1000トークン」分の情報を含んでいる
実際には画像をfeature/埋め込みへ変換（デコード）する必要があるので
もしその画像が100個の「画像トークン」として処理され、それらの画像トークンが1000個の「テキストトークン」に変換されるなら
純粋にデコードの観点では、出力情報を10倍に圧縮して渡したことになる
LLMの観点では、もし事前に10倍小さい潜在表現へ圧縮できるなら、1000個のトークン/埋め込みを使わなくても、それ以上の結果を出せることを意味する