{"notes":[{"id":"deepseek/deepseek-ocr","category":"deepseek","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"DeepSeek-OCR","subtitle":"一枚の絵は千語に値する","author":"Z. Yuan","paperDate":"2025-10-21","publishedOn":"2026-03-09","world":"external/deepseek-ocr","paperTitle":"DeepSeek-OCR: Contexts Optical Compression","paperUrl":"https://arxiv.org/abs/2510.18234","bibliography":{"title":"DeepSeek-OCR: Contexts Optical Compression","authors":["Haoran Wei","Yaofeng Sun","Yukun Li"],"url":"https://arxiv.org/abs/2510.18234","pdfUrl":"https://arxiv.org/pdf/2510.18234v1","codeUrl":"https://github.com/deepseek-ai/DeepSeek-OCR","preprint":{"id":"2510.18234","submittedOn":"2025-10-21","url":"https://arxiv.org/abs/2510.18234"},"publication":null,"citation":"@misc{deepseekdeepseekocr2025,\n  title = {{DeepSeek-OCR: Contexts Optical Compression}},\n  author = {Haoran Wei and Yaofeng Sun and Yukun Li},\n  year = {2025},\n  eprint = {2510.18234},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2510.18234}\n}\n","citationPath":"/content/papers/citations/deepseek/deepseek-ocr.66e8e5a7db8d.bib"},"thumbnail":{"src":"/content/papers/assets/6f53ecfe63f39804454a69ef4468c93e8018fa1afbe08d1bb52b7e8d52d194c3.png","width":1288,"height":350},"locale":"ja","path":"/content/papers/ja/deepseek/deepseek-ocr.68375c40aca1.md","headings":[{"id":"問題の定義","text":"問題の定義","depth":2},{"id":"問題の解決","text":"問題の解決","depth":2},{"id":"全体のアーキテクチャ","text":"全体のアーキテクチャ","depth":3},{"id":"10241024の画像を1枚たどってみる","text":"1024×1024の画像を1枚たどってみる","depth":3},{"id":"デコーダー圧縮された表現から文字を復元する","text":"デコーダー：圧縮された表現から文字を復元する","depth":3},{"id":"データと学習","text":"データと学習","depth":3},{"id":"考察","text":"考察","depth":2},{"id":"圧縮率の実験foxの100ページ","text":"圧縮率の実験：Foxの100ページ","depth":3},{"id":"実際の文書omnidocbench","text":"実際の文書：OmniDocBench","depth":3},{"id":"光学圧縮と忘却","text":"光学圧縮と忘却","depth":3},{"id":"公開後の議論","text":"公開後の議論","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"model-evaluation/linguistic-crutch","relation":"referenced","topic":""}]},{"id":"model-evaluation/linguistic-crutch","category":"model-evaluation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Linguistic Crutch","subtitle":"脳内補完の代償","author":"Z. Yuan","paperDate":"2026-01-07","publishedOn":"2026-02-21","paperTitle":"Visual Merit or Linguistic Crutch? A Close Look at DeepSeek-OCR","paperUrl":"https://arxiv.org/abs/2601.03714","bibliography":{"title":"Visual Merit or Linguistic Crutch? A Close Look at DeepSeek-OCR","authors":["Yunhao Liang","Ruixuan Ying","Bo Li","Hong Li","Kai Yan","Qingwen Li","Min Yang","Okamoto Satoshi","Zhe Cui","Shiwen Ni"],"url":"https://arxiv.org/abs/2601.03714","pdfUrl":"https://arxiv.org/pdf/2601.03714v2","codeUrl":null,"preprint":{"id":"2601.03714","submittedOn":"2026-01-07","url":"https://arxiv.org/abs/2601.03714"},"publication":null,"citation":"@misc{modelevaluationlinguisticcrutch2026,\n  title = {{Visual Merit or Linguistic Crutch? A Close Look at DeepSeek-OCR}},\n  author = {Yunhao Liang and Ruixuan Ying and Bo Li and Hong Li and Kai Yan and Qingwen Li and Min Yang and Okamoto Satoshi and Zhe Cui and Shiwen Ni},\n  year = {2026},\n  eprint = {2601.03714},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2601.03714}\n}\n","citationPath":"/content/papers/citations/model-evaluation/linguistic-crutch.af1f73a098b5.bib"},"thumbnail":{"src":"/content/papers/assets/3dfc834dee089d76acab6a1ce767b06c592ef84c6b48c2a5f79a7723f9cc3f09.png","width":644,"height":300},"locale":"ja","path":"/content/papers/ja/model-evaluation/linguistic-crutch.2b28ca115eeb.md","headings":[{"id":"問題の定義","text":"問題の定義","depth":2},{"id":"問題の解決","text":"問題の解決","depth":2},{"id":"画像の条件をそろえる","text":"画像の条件をそろえる","depth":3},{"id":"3つの壊し方","text":"3つの壊し方","depth":3},{"id":"ほかの二つのテスト","text":"ほかの二つのテスト","depth":3},{"id":"考察","text":"考察","depth":2},{"id":"文が意味を失うと","text":"文が意味を失うと","depth":3},{"id":"単語が単語らしくなくなると","text":"単語が単語らしくなくなると","depth":3},{"id":"ほかのモデルは","text":"ほかのモデルは？","depth":3},{"id":"質問応答と長いコンテキスト","text":"質問応答と長いコンテキスト","depth":3},{"id":"この論文を読むときの注意点","text":"この論文を読むときの注意点","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"deepseek/deepseek-ocr","relation":"citing","topic":""}]}],"text":"名前を見れば、OCRモデルです。ところが要旨まで読むと、著者らが本当に問いたいのは別のことだとわかります。\n\nLLMが長文を処理するとき、注意機構の計算量は長さの2乗で増えます。1ページの文書に1,000個のテキストトークンがあるなら、それを1枚の画像にして、100個、さらには64個の視覚トークンでモデルへ渡し、そこから原文を読み取らせることはできないでしょうか。\n\nできるなら、画像はテキストを圧縮する手段になります。著者らはこの発想を**コンテキストの光学圧縮**（contexts optical compression）と呼び、OCRをその検証の試験場にしました。入力は画像、答えは原文なので、合っているかどうかは比べればすぐにわかります。\n\n本論文はDeepSeek-AIが2025年10月21日にarXivへ投稿した技術報告で、本稿はv1に基づきます。重みとコードも同時に公開されています。\n\n## 問題の定義\n\n著者らは関連研究の節で、問いを率直に立てています。1,000語の文書を復元するには、最低いくつの視覚トークンが必要か？\n\nこれに答えるには、視覚トークンの数を調整できるエンコーダーが必要です。著者らは当時のオープンソースVLMでよく使われていた三つの方式を整理し、それぞれの欠点を挙げます。\n\n1. **デュアルタワー型**（例：Vary）：高解像度を扱うSAMエンコーダーを別に並列で置きます。パラメータとメモリはまだ制御できる範囲ですが、画像に2系統の前処理が必要で、学習時のパイプライン並列もやりにくくなります。\n2. **タイル分割型**（例：InternVL2.0）：大きな画像を小さなタイルに切り、それぞれを符号化します。非常に高い解像度も扱えますが、ネイティブ解像度が通常512×512未満なので、大きな画像は細かく切り刻まれ、視覚トークンがすぐに増えます。\n3. **適応解像度型**（例：Qwen2-VL）：元画像のままパッチに分割します。柔軟ですが、大きな画像ではアクティベーションのメモリが大きく、視覚トークンが長くなるとprefillも生成も遅くなります。\n\n著者らがエンコーダーに求める条件は五つです。高解像度を扱えること、高解像度でもメモリが溢れないこと、視覚トークンが少ないこと、複数の解像度に対応すること、パラメータ数がほどほどであること。既存の方式はどれも全条件を満たさないため、自分たちで作りました。それが**DeepEncoder**です。\n\n## 問題の解決\n\n### 全体のアーキテクチャ\n\n[![DeepSeek-OCRのアーキテクチャ図：入力ページを16×16のパッチに分け、SAM（局所注意）、16倍ダウンサンプリングの畳み込み、CLIP（大域注意）からなるDeepEncoderを通し、プロンプトとともにDeepSeek-3B MoEデコーダーへ渡してテキストを出力する](/content/papers/assets/6f53ecfe63f39804454a69ef4468c93e8018fa1afbe08d1bb52b7e8d52d194c3.png)](/content/papers/assets/6f53ecfe63f39804454a69ef4468c93e8018fa1afbe08d1bb52b7e8d52d194c3.png)\n\n*原論文Figure 3。[**v1 PDFの5ページ**](https://arxiv.org/pdf/2510.18234v1#page=5)から抜粋、CC BY 4.0。左半分の破線枠内がDeepEncoder、右側がデコーダーです。*\n\nまず左から右へ、順に見ていきます。\n\n- **SAM**（8,000万パラメータ、ViTDetアーキテクチャ）が知覚を担い、主に局所的なウィンドウ注意を使います。\n- **Conv 16x**は2層の畳み込みで、トークン数を16分の1に減らします。\n- **CLIP**（ViT、3億パラメータ）が大域注意を担います。入力はすでに前段が出力したトークンなので、元のpatch embedding層は取り除かれています。\n- **DeepSeek-3B**はデコーダーで、30億パラメータのMoEです。推論のたびに約5.7億パラメータが活性化されます。\n\nDeepEncoder全体は約3.8億パラメータです。この並べ方の理屈は、**トークンが多いうちは安価な局所注意だけを行い、圧縮してから高価な大域注意を行う**ことにあります。\n\n### 1024×1024の画像を1枚たどってみる\n\n論文自身の例、Baseモードの1024×1024ページを使います。\n\n1. SAMが16×16ピクセルを1ブロックとして読み、1024/16 × 1024/16 = 64×64 = **4,096**個のパッチトークンを得ます。この段はウィンドウ注意が中心で、パラメータも8,000万だけなので、メモリはまだ持ちこたえます。\n2. 畳み込みモジュールは、kernel 3、ストライド2、padding 1の畳み込み2層で、チャネル数は256から1024へ増えます。各層で縦横をそれぞれ半分にして、64×64 → 32×32 → 16×16。トークンは4,096 / 16 = **256**個になります。\n3. この256個のトークンがCLIPに入り、大域注意を受けます。256個のトークン同士の注意は、4,096個の場合と比べて、スコア表が256分の1の大きさです。\n4. デコーダーはこの256個の視覚トークンとプロンプトを受け取り、自己回帰的にテキストを出力します。\n\nつまり「ページがいくつのトークンになるか」は、入力解像度だけで決まります。\n\n| モード | 解像度 | 視覚トークン | 処理方法 |\n| --- | --- | ---: | --- |\n| Tiny | 512×512 | 64 | そのままリサイズ |\n| Small | 640×640 | 100 | そのままリサイズ |\n| Base | 1024×1024 | 256 | 縦横比を保ってパディング |\n| Large | 1280×1280 | 400 | 縦横比を保ってパディング |\n| Gundam | n枚の640×640局所＋1024×1024大域 | n×100＋256 | タイル分割、nは2〜9 |\n\n*表：原論文§3.2.2とFigure 4をもとに整理。ほかにGundam-masterモード（1024×1024局所＋1280×1280大域）があり、学習済みのモデルに追加学習したものです。*\n\n\n> [!TIP]\n> \n> **パディングの後、有効なトークンはいくつ残る？**\n> \n> BaseとLargeモードは、縦横比を保つために画像を正方形へパディングします。パディング部分のトークンには内容がありません。論文は有効トークン数の計算式を示しています。\n> \n> $$\n> N_{valid}=\\left\\lceil N_{actual}\\times\\left[1-\\frac{\\max(w,h)-\\min(w,h)}{\\max(w,h)}\\right]\\right\\rceil\n> $$\n> \n> A4縦向きのページで試算してみましょう。縦横比は約1:1.414で、角括弧の中は$1-(1.414-1)/1.414\\approx0.707$です。Baseモードでは$\\lceil256\\times0.707\\rceil=182$、Largeモードでは283になります。\n> \n> 後で出てくるOmniDocBenchの表では、Baseが256(182)、Largeが400(285)と記されています。表の値はテストセット全体の平均で、ページの縦横比はまちまちです。ここではA4で桁を確かめただけです。\n\n\n### デコーダー：圧縮された表現から文字を復元する\n\n著者らはデコーダーの仕事を一つの写像として書いています。圧縮後の$n$個の視覚トークン$\\mathbf{Z}\\in\\mathbb{R}^{n\\times d_{latent}}$から、$N$個のテキストトークンの表現を再構成する写像です。\n\nデコーダーにはDeepSeekMoEを使います。推論時には64個のルーティング対象エキスパートから6個を活性化し、さらに共有エキスパートを2個使います。著者らによれば、30億パラメータモデルの表現力を持ちながら、推論コストは5億パラメータ級の小型モデルに近いといいます。\n\nここで少し立ち止まりましょう。$N$が$n$の10倍以上になると、デコーダーは各視覚トークンを「一つずつ翻訳する」だけでは済みません。学習した言語知識を使って、圧縮された情報を完全な文へ展開する必要があります。これが手法の成り立つ理由であり、後続研究が疑問を向ける点でもあります。考察の節でまた戻ってきます。\n\n### データと学習\n\n中心は文書データです。著者らはWebから約3,000万ページのPDFを集めました。約100言語にわたり、うち中国語と英語が約2,500万ページです。アノテーションは2種類あります。\n\n- **粗いアノテーション**：fitzでPDFから直接テキストを抽出します。主に、さまざまな言語の文字を見分けられるようにするためのものです。\n- **細かいアノテーション**：中国語と英語それぞれ200万ページについて、PP-DocLayoutのようなレイアウトモデルと、MinerU、GOT-OCR2.0などのOCRモデルを使い、「座標＋カテゴリ＋テキスト」が交互に並ぶアノテーションを作ります。少数言語では、fitzで作った小さな画像でGOT-OCR2.0を1つ学習させ、それでアノテーションして60万件を用意しました。\n\nほかに、300万件のWord文書、PaddleOCRでアノテーションした中国語・英語それぞれ1,000万件のシーンテキスト、そして著者らが「OCR 2.0」と呼ぶデータがあります。1,000万枚のチャート（HTMLの表としてラベル付け）、500万件の化学式（SMILES）、100万件の平面幾何です。\n\n全体の配合は、OCRデータ70%、一般的な視覚データ20%、テキストのみのデータ10%です。\n\n学習は2段階です。まず小型の言語モデルをつなぎ、次トークン予測を目的としてDeepEncoderだけを学習します。次にSAMと圧縮器を凍結し、デコーダーと一緒にモデル全体を学習します。本番の学習には20ノード、各ノードにA100-40Gを8枚使い、マルチモーダルデータを1日約700億トークン処理しました。\n\n## 考察\n\n### 圧縮率の実験：Foxの100ページ\n\n[![左図：Foxベンチマークにおける64個と100個の視覚トークンの、テキスト長ごとの精度と圧縮率。右図：OmniDocBenchにおける各モデルの平均視覚トークン数と全体の編集距離の関係](/content/papers/assets/45775893f2592575b0f63ed52ce871bcfdd8aacf7f1772a97ee461c2c1e86e52.png)](/content/papers/assets/45775893f2592575b0f63ed52ce871bcfdd8aacf7f1772a97ee461c2c1e86e52.png)\n\n*原論文Figure 1。[**v1 PDFの1ページ**](https://arxiv.org/pdf/2510.18234v1#page=1)から抜粋、CC BY 4.0。(a)棒が精度（左軸）、破線が圧縮率（右軸）です。(b)横軸は右へ行くほど視覚トークンが少なく、縦軸は上へ行くほど編集距離が低くなります。*\n\nまず左図です。横軸は各ページの正解テキストのトークン数で、紫の棒は64個の視覚トークン（Tiny）、青は100個（Small）、破線は対応する圧縮率です。\n\n著者らは、Foxベンチマークからテキストトークンが600〜1,300の英語ページをすべて選び出しました。ちょうど100ページです。テストには、レイアウトを求めない「Free OCR」というプロンプトを使います。Table 2から数行を見てみましょう。\n\n| テキストトークン | 視覚トークン64個 | 視覚トークン100個 | ページ数 |\n| --- | --- | --- | ---: |\n| 600–700 | 96.5%（10.5×） | 98.5%（6.7×） | 7 |\n| 800–900 | 83.8%（13.2×） | 96.8%（8.5×） | 28 |\n| 1000–1100 | 79.3%（16.5×） | 91.5%（10.6×） | 11 |\n| 1200–1300 | 59.1%（19.7×） | 87.1%（12.6×） | 4 |\n\n*表：原論文Table 2から抜粋。括弧内は圧縮率です。*\n\nこの表を読むときは、二つの点に注意が必要です。\n\n1. **ページ数に偏りがある**。要旨の「20倍圧縮でも約60%」は最終行の値で、わずか4ページです。中ほどの700〜800と800〜900の区間には、それぞれ28ページあります。\n2. **形式の違いが点数を押し下げる**。モデルの出力形式はFoxの正解と完全には一致しないため、実際の性能は表より少し高いはずだと著者らは述べています。\n\n圧縮率が10倍を超えてからの低下について、著者らは考えられる原因を二つ挙げています。長い文書ほどレイアウトが複雑なこと、そして512×512や640×640の解像度では長いテキストがすでにぼやけていることです。後者は一種の「忘却メカニズム」とみなせる、と著者らは考えています。\n\n### 実際の文書：OmniDocBench\n\n右図とTable 3では、実際の文書解析ベンチマークOmniDocBenchに移ります。論文はバージョンを明記していません。表は英語と中国語を分けて採点しており、v1.5より前の形式と一致します。指標はいずれも編集距離で、低いほど良い値です。著者らが強調するのはトークン効率です。\n\n- **Smallモード**は視覚トークン100個だけで、英語の全体編集距離が0.221です。256トークンを使うGOT-OCR2.0（0.287）より低くなっています。\n- **Gundamモード**は平均795トークンで、英語0.127、中国語0.181。どちらも、平均6,790トークンを使うMinerU2.0（0.133、0.238）より良い値です。\n\nTable 4は文書の種類別に分けており、どの文書にどれだけのトークンが必要かが見えます。スライドはTinyモードで、すでに編集距離が0.116です。書籍とレポートはSmallモードで十分な成績を出しています。新聞はまったく事情が違います。Tinyでは0.94で、Gundamになってようやく0.122まで下がります。著者らの説明では、新聞は1ページに4,000〜5,000個のテキストトークンがあり、ほかのモードの約10倍という圧縮範囲を大きく超えているからです。\n\n### 光学圧縮と忘却\n\n考察の節で、著者らは発展的な構想を示しています。マルチターン対話の古い部分を画像にレンダリングして圧縮する。古い会話ほど画像を小さく縮め、トークンを減らし、文字もぼやけさせる。人の記憶が少しずつ薄れていくように、というものです。\n\n著者ら自身も、これはごく初期の探索だと述べています。結論ではっきり書いています。**OCRだけでは、本当のコンテキスト光学圧縮を十分に検証できない**。今後、デジタルテキストと画像中のテキストを交互に含む事前学習や、needle-in-a-haystackテストなどの評価が必要だとしています。\n\n### 公開後の議論\n\n論文の公開後、多くの議論が起きました。Andrej Karpathyは2025年10月20日の投稿で、良いOCRモデルだと評価しつつ、もっと興味があるのは別の問いだと述べています。ピクセルは、テキストより良いLLMの入力になるのではないか？ 理由として挙げたのは、情報の圧縮、太字や色といった書式を保てること、そしてトークナイザーをなくせることなどです。[Karpathy、2025-10-20](https://x.com/karpathy/status/1980397031542989305)\n\n別の方向の反応は、高得点のうちどれだけが画像から来ているのかを確かめることでした。2026年1月の〈Visual Merit or Linguistic Crutch?〉は、Foxの段落をランダムな文字列に置き換えました。Tinyモードは88%から約20%に落ちます。同じデータで、行ごとに認識するPaddleOCR-v5は94%から90%への低下にとどまりました。\n\n先ほどの写像に戻りましょう。1個の視覚トークンが平均して十数個のテキストトークンに対応するなら、デコーダーの言語知識が多くを補う必要があります。内容が普通の英語なら、この知識のおかげで圧縮が成り立ちます。内容に規則性がなければ、補いきれません。\n\n\n> [!TIP]\n> \n> 意味を崩す摂動実験の詳しい設定は、こちらを参照してください。\n> \n> - **[[26.01] Linguistic Crutch：脳内補完の代償](/blog/papers/model-evaluation/linguistic-crutch)**\n\n\n## 結論\n\nDeepSeek-OCRは「1ページの文書に視覚トークンがいくつ必要か」を測定できる問いに変え、実用的な答えを示しました。\n\n1. **DeepEncoderの並べ方は有効**。局所、圧縮、大域の順に処理することで、1024×1024のページから視覚トークンを256個しか生まず、メモリも持ちこたえます。\n2. **約10倍の圧縮なら、英語ページはおおむね読み取れる**。Foxでは10倍以内で約97%です。圧縮率がそれ以上になると低下し始め、20倍前後の数字を支えているのはごく少数のページです。\n3. **OCRツールとしてのトークン効率は高い**。SmallモードですでにGOT-OCR2.0を上回り、GundamモードはMinerU2.0の8分の1未満のトークンでMinerU2.0を上回ります。著者らは、A100-40G 1枚で1日20万ページ以上の学習データを生成できるとも述べています。\n\n「画像でLLMの長いコンテキストを圧縮する」という構想については、論文は第一歩を踏み出したところです。OCRの点数は、デコーダーが文字を復元できることを示しました。けれども、復元された文字のうちどれだけが画像から来たのかには答えていません。この問いは、3か月後に別の研究者たちが引き継ぎました。\n","imageSizes":{"/content/papers/assets/6f53ecfe63f39804454a69ef4468c93e8018fa1afbe08d1bb52b7e8d52d194c3.png":{"width":1288,"height":350},"/content/papers/assets/45775893f2592575b0f63ed52ce871bcfdd8aacf7f1772a97ee461c2c1e86e52.png":{"width":1272,"height":558}}}