{"notes":[{"id":"deepseek/deepseek-ocr-2","category":"deepseek","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"DeepSeek-OCR 2","subtitle":"視線の順序","author":"Z. Yuan","paperDate":"2026-01-28","publishedOn":"2026-11-08","world":"external/deepseek-ocr2","paperTitle":"DeepSeek-OCR 2: Visual Causal Flow","paperUrl":"https://arxiv.org/abs/2601.20552","bibliography":{"title":"DeepSeek-OCR 2: Visual Causal Flow","authors":["Haoran Wei","Yaofeng Sun","Yukun Li"],"url":"https://arxiv.org/abs/2601.20552","pdfUrl":"https://arxiv.org/pdf/2601.20552v1","codeUrl":"https://github.com/deepseek-ai/DeepSeek-OCR-2","preprint":{"id":"2601.20552","submittedOn":"2026-01-28","url":"https://arxiv.org/abs/2601.20552"},"publication":null,"citation":"@misc{deepseekdeepseekocr22026,\n  title = {{DeepSeek-OCR 2: Visual Causal Flow}},\n  author = {Haoran Wei and Yaofeng Sun and Yukun Li},\n  year = {2026},\n  eprint = {2601.20552},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2601.20552}\n}\n","citationPath":"/content/papers/citations/deepseek/deepseek-ocr-2.02901bc9ba9f.bib"},"thumbnail":{"src":"/content/papers/assets/2ba25df8f4e3579425551e93bdce7b8b0f180bb349cef46511dce7f44ffd68f3.png","width":1194,"height":483},"locale":"ja","path":"/content/papers/ja/deepseek/deepseek-ocr-2.1c98ca1e0e8b.md","headings":[{"id":"問題の定義","text":"問題の定義","depth":2},{"id":"問題の解決","text":"問題の解決","depth":2},{"id":"clipを言語モデルに置き換える","text":"CLIPを言語モデルに置き換える","depth":3},{"id":"マスクが誰が誰を見るかを決める","text":"マスクが「誰が誰を見るか」を決める","depth":3},{"id":"1ページにトークンはいくつ","text":"1ページにトークンはいくつ？","depth":3},{"id":"学習","text":"学習","depth":3},{"id":"考察","text":"考察","depth":2},{"id":"omnidocbench-v15","text":"OmniDocBench v1.5","depth":3},{"id":"9種類の文書を個別に見る","text":"9種類の文書を個別に見る","depth":3},{"id":"運用後に何を見るか","text":"運用後に何を見るか","depth":3},{"id":"著者らの展望とその後の成績","text":"著者らの展望とその後の成績","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"deepseek/deepseek-ocr","relation":"referenced","topic":""}]},{"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":""}]}],"text":"3段組みの新聞を、人はどう読むでしょうか。\n\n左上から右下まで一気に走査したりはしません。まず見出しを読み、1段目を下へたどり、下まで来たら2段目の上へ戻ります。「5面へ続く」とあれば、視線もそこへ飛びます。次にどこを見るかは、いま読んだ内容で決まります。\n\nVLMの読み方は違います。画像はマス目状のパッチに切られ、「左から右、上から下」という固定の順で1列に並べられ、位置エンコーディングを付けて言語モデルへ渡されます。普通の写真なら大きな問題はありません。けれどもレイアウトが複雑な文書では、この順序が内容の論理的な順序と食い違うことがよくあります。\n\nDeepSeek-OCR 2は、**どこを先に見て、次にどこを見るか**をエンコーダー自身に決めさせようとします。DeepSeek-AIが2026年1月28日に投稿した技術報告で、本稿はv1に基づきます。コードと重みも同時に公開されています。\n\n\n> [!TIP]\n> \n> 前世代のDeepEncoderと光学圧縮の設計は、先にこちらをどうぞ。\n> \n> - **[[25.10] DeepSeek-OCR：一枚の絵は千語に値する](/blog/papers/deepseek/deepseek-ocr)**\n\n\n## 問題の定義\n\n著者らの出発点は一つの観察です。人の視線の動きには因果関係があり、次の注視点はそれまでに見たものによって決まります。ところが現在のVLMエンコーダーは、2Dの画像を1Dの系列に並べるとき、内容と無関係な固定の順序を使っています。\n\n言語モデルは、1次元で前後の順序があるテキストで学習されています。そこで著者らは問います。「1次元で因果的な順序を持つ」推論を2段つなげて、2次元の画像を処理できないか？\n\n- 1段目はエンコーダーの中で、画像の内容に応じて視覚トークンを読み順に並べ直す。\n- 2段目はデコーダーの中で、その順序に従って自己回帰的にテキストを出力する。\n\n試験場には文書の読み取りを選びました。文書には段組み、数式、表があり、読み順そのものに論理が含まれているからです。\n\n## 問題の解決\n\n### CLIPを言語モデルに置き換える\n\n[![左：DeepEncoder。80MのTokenizerにCLIP ViT 300Mをつなぐ。右：DeepEncoder V2。同じTokenizerに、Qwen2 500Mをベースにした言語モデルをつなぎ、視覚トークンの後ろに学習可能なクエリを並べる。下流へ渡すのはクエリの出力だけ](/content/papers/assets/e199e1e56c505533eb91beb5fa681e7a2366dac66b585a0317ab82b1c950d79d.png)](/content/papers/assets/e199e1e56c505533eb91beb5fa681e7a2366dac66b585a0317ab82b1c950d79d.png)\n\n*原論文Figure 1。[**v1 PDFの1ページ**](https://arxiv.org/pdf/2601.20552v1#page=1)から抜粋、CC BY 4.0。左が前世代のDeepEncoder、右がDeepEncoder V2です。*\n\n左右とも上半分は同じです。約8,000万パラメータのTokenizerで、前世代のSAM-baseと2層の畳み込みをそのまま使い、トークン数を16分の1に圧縮します。\n\n違いは下半分です。前世代は3億パラメータのCLIPで大域注意を行っていました。V2はこれを**Qwen2-0.5B**で初期化した言語モデルのアーキテクチャに置き換え、視覚トークンの後ろに**学習可能なクエリ**（著者らはcausal flow tokenと呼びます）を並べます。\n\nクエリの数は視覚トークンと同じです。最終的にデコーダーへ渡るのはクエリ側の半分の出力だけで、視覚トークン自体は下流へ送られません。\n\n著者らは別のつなぎ方も試しています。視覚トークンを独立したエンコーダーに入れ、cross-attentionでクエリに読ませる、mBARTのようなエンコーダー・デコーダー構造です。ところが、学習が収束しませんでした。視覚トークンが別のエンコーダーに隔離され、クエリとのやり取りが足りなかったのだろうと著者らは推測しています。視覚トークンをprefixとして同じ系列に置き、各層で情報を交換できるようにして、ようやく学習が進むようになりました。\n\n### マスクが「誰が誰を見るか」を決める\n\n[![注意マスクの模式図：ViT式の双方向マスクとLM式の因果マスクを組み合わせて、DeepEncoder V2のマスクを作る。最初の3行の視覚トークンは互いに参照し合い、後の3行のクエリはすべての視覚トークンと先行するクエリを参照できる](/content/papers/assets/2ba25df8f4e3579425551e93bdce7b8b0f180bb349cef46511dce7f44ffd68f3.png)](/content/papers/assets/2ba25df8f4e3579425551e93bdce7b8b0f180bb349cef46511dce7f44ffd68f3.png)\n\n*原論文Figure 5。[**v1 PDFの7ページ**](https://arxiv.org/pdf/2601.20552v1#page=7)から抜粋、CC BY 4.0。緑は注意可能、ピンクは注意不可、白丸は自分自身です。*\n\nこの図が設計全体の核心です。3個の視覚トークン$v_0,v_1,v_2$と3個のクエリ$q_0,q_1,q_2$で、順にたどってみます。行が「見る側」、列が「見られる側」で、1は注意できることを表します。\n\n```text\n       v0 v1 v2 | q0 q1 q2\nv0      1  1  1 |  0  0  0\nv1      1  1  1 |  0  0  0\nv2      1  1  1 |  0  0  0\n----------------+---------\nq0      1  1  1 |  1  0  0\nq1      1  1  1 |  1  1  0\nq2      1  1  1 |  1  1  1\n```\n\n- **左上**：視覚トークンは互いにすべて見えます。ViTと同じ双方向注意で、CLIPのように画像全体を見渡す視野を保ちます。\n- **右上**：視覚トークンからクエリは見えません。そのため、画像の特徴はクエリの順序に左右されません。\n- **左下**：各クエリは、すべての視覚トークンを見られます。\n- **右下**：クエリ同士は下三角です。$q_1$に見えるのは$q_0$と自分だけで、decoder-only言語モデルの因果注意と同じです。\n\n論文では次の式で書かれています。\n\n$$\nM=\\begin{bmatrix}\\mathbf{1}_{m\\times m} & \\mathbf{0}_{m\\times n}\\\\ \\mathbf{1}_{n\\times m} & \\mathrm{LowerTri}(n)\\end{bmatrix},\\quad n=m\n$$\n\n右下の下三角こそが「順序」の源です。まず$q_0$が、画像から何を取り出すかを決めます。$q_1$は$q_0$が何を取ったかを知ったうえで、次を決めます。以下同様です。クエリの出力を1列に並べたもの自体が、一種の読み順になります。\n\n著者らは処理全体を次のように書きます。\n\n$$\n\\mathbf{O}=\\mathcal{D}\\big(\\pi_Q(\\mathcal{T}^L(\\mathcal{E}(\\mathbf{I})\\oplus\\mathbf{Q}_0;\\mathbf{M}))\\big)\n$$\n\n$\\mathcal{E}$はTokenizer、$\\oplus$は視覚トークンとクエリの連結、$\\mathcal{T}^L$はマスク付きの$L$層Transformerです。$\\pi_Q$は最後の$n$個、つまりクエリの出力だけを取り出し、$\\mathcal{D}$はデコーダーです。\n\n### 1ページにトークンはいくつ？\n\n解像度ごとにクエリを用意しなくて済むよう、著者らはビューを二つに固定しています。\n\n- **全体ビュー** 1024×1024：1024/16 = 64、64×64 = 4,096ブロック。16分の1に圧縮すると**256**トークンで、256個のクエリと組みます。\n- **局所クロップ** 768×768：768/16 = 48、48×48 = 2,304ブロック。圧縮後は**144**個で、すべてのクロップが同じ144個のクエリを共有します。\n\nクロップ数$k$は0〜6で、縦横とも768未満なら切り出しません。したがってデコーダーに渡るトークン数は$144k+256$で、最少256、最多$6\\times144+256=1{,}120$です。\n\n著者らは特に上限を比べています。前世代のGundamモードは最大1,156個、Gemini 3 Proの視覚トークン上限も1,120です。\n\nデコーダーは替えておらず、前世代と同じ3B MoEで、活性化されるのは約5億パラメータです。\n\n### 学習\n\nデータソースは前世代と同じで、OCRデータが80%を占めます。小さな調整が二つあります。OCR 1.0データを内容によってテキスト、数式、表に分け、3:1:1でサンプリングすること。そしてレイアウトのアノテーションで、意味の近いカテゴリを統合することです。たとえばキャプションと図のタイトルがそうです。\n\n学習は3段階です。\n\n1. **エンコーダーの事前学習**：Tokenizerは前世代のものを使い、言語モデル型エンコーダーはQwen2-0.5B-baseから初期化します。小型のデコーダーをつなぎ、次トークン予測で学習します。A100を160枚使い、画像とテキストのペアは約1億組です。\n2. **クエリの強化**：Tokenizerを凍結し、エンコーダーとDeepSeekデコーダーを一緒に学習して、クエリの並べ替え能力を高めます。\n3. **デコーダーの特化**：エンコーダー全体を凍結し、デコーダーだけを学習します。同じbatch sizeで、学習速度は2倍以上になります。\n\n## 考察\n\n### OmniDocBench v1.5\n\n主な評価はOmniDocBench v1.5です。全1,355ページ、9種類の文書を含み、中国語と英語の両方があります。\n\n| モデル | 視覚トークン上限 | Overall | テキストED | 読み順ED |\n| --- | ---: | ---: | ---: | ---: |\n| DeepSeek-OCR（9クロップ） | 1,156 | 87.36 | 0.073 | 0.085 |\n| DeepSeek-OCR 2 | 1,120 | 91.09 | 0.048 | 0.057 |\n\n*表：原論文Table 1から抜粋。EDは編集距離で低いほど良く、Overallは高いほど良い値です。*\n\n似たデータソースのもとで、全体スコアは3.73上がり、読み順の編集距離は0.085から0.057に下がりました。著者らはTable 2で、全体の編集距離をGemini 3 Proとも比べています。同じ1,120トークンの上限で、DeepSeek-OCR 2は0.100、Gemini 3 Proは0.115です。\n\n同じTable 1には、注目すべき相手が二つあります。PaddleOCR-VLは92.86、MinerU2.5は90.67です。どちらも先にレイアウト解析を行い、切り出した領域を認識する方式で、論文ではPipelineに分類されています。つまりこのベンチマークでは、エンドツーエンドのDeepSeek-OCR 2は2段階のシステムにかなり迫っているものの、最良のものにはまだ届いていません。\n\n### 9種類の文書を個別に見る\n\nTable 3は、2世代のモデルの成績を9種類の文書ごとに分けています。読み順の編集距離は**9種類すべてで改善**しました。たとえばカラー教科書は0.125から0.066へ、ノートは0.089から0.035へ下がっています。\n\nテキストの編集距離は、そこまで一様ではありません。多くのカテゴリで良くなりましたが、書籍は0.022から0.033に、新聞は0.131から0.139になりました。新聞について、著者らは原因を二つ挙げています。一つは、視覚トークンの上限が低く、文字が極端に多い新聞には足りないこと。今後はクロップ数を増やせます。もう一つは、新聞の学習データが25万件しかなく、新しいエンコーダーには少なすぎることです。\n\n### 運用後に何を見るか\n\nこの節は短いのですが、私は論文全体でいちばん実践的な部分だと思います。\n\nDeepSeek-OCRは、社内で二つの用途に使われています。DeepSeekの言語モデルのために、ユーザーがアップロードした画像や文書を読むこと。そしてPDFをバッチ処理して、事前学習データを作ることです。本番環境には比べるべき正解がないため、著者らは**繰り返し率**を主な観測可能な品質指標に選びました。\n\n| モデル | オンラインのユーザー画像 | 事前学習用PDF |\n| --- | ---: | ---: |\n| DeepSeek-OCR | 6.25% | 3.69% |\n| DeepSeek-OCR 2 | 4.17% | 2.88% |\n\n*表：原論文Table 4。繰り返し率は低いほど良い値です。*\n\n繰り返しは、生成型OCRでいちばん観測しやすい失敗です。同じ文字列を出力し続けるので、プログラムですぐに検出できます。\n\n逆に言えば、正解がない状況では、「文章は滑らかなのに字が間違っている」という種類の誤りは、繰り返し率では見えません。OCRの結果を意思決定に使うアプリケーションにとって、この表は一つの注意喚起です。本番の監視には、この種の誤りが見える仕組みを別に設計する必要があります。たとえばテキスト層との照合、項目の形式チェック、抜き取りによる人手の再確認などです。\n\n### 著者らの展望とその後の成績\n\n考察の節では、著者らは少し大きな話をしています。視覚を並べ替える因果エンコーダーに、タスクを推論する因果デコーダーをつなげば、2段の1次元推論が「本当の2次元推論」へ近づけるかもしれない。同じ言語モデル型エンコーダーでも、クエリの組を替えるだけで、画像、音声、テキストを扱えるとも構想しています。どれも現時点では展望で、論文が検証したのは文書の読み取りだけです。\n\nOmniDocBenchはその後v1.6に改訂され、難しめのサンプルが296ページ加わりました。公式リーダーボードでのDeepSeek-OCR 2のスコアは90.25です。上位5位は10億パラメータ前後の専用モデル群で、最高は約97点です。[OmniDocBench README](https://github.com/opendatalab/OmniDocBench)\n\n## 結論\n\nDeepSeek-OCR 2の変更点は一か所に集中しています。エンコーダーの後半だけを入れ替え、学習可能なクエリの組に画像を順に読ませて、視覚トークンを読み順に並べ直しました。\n\n1. **マスク設計が鍵**。視覚トークン同士は双方向に見え、クエリ同士は因果的です。下流へ渡るのはクエリの出力だけです。\n2. **読み順は全面的に改善**。OmniDocBench v1.5の読み順の編集距離は0.085から0.057に下がり、9種類の文書すべてで良くなりました。\n3. **テキスト認識は一部のカテゴリで悪化**。書籍と新聞では、テキストの編集距離がかえって少し上がりました。新聞はトークン上限と学習データに制約されています。\n4. **本番の指標で見えるのは繰り返しだけ**。繰り返し率は6.25%から4.17%に下がりましたが、この指標では滑らかな誤字は見えません。\n\n読み順を、順番に画像を見るクエリの組に任せる。とても直感的な発想です。モデルの文書の読み方は人に近づきました。ただ、読んだ文字がはっきり見えたものか、文脈から補ったものかは、やはり別に確かめる必要があります。\n","imageSizes":{"/content/papers/assets/e199e1e56c505533eb91beb5fa681e7a2366dac66b585a0317ab82b1c950d79d.png":{"width":1111,"height":588},"/content/papers/assets/2ba25df8f4e3579425551e93bdce7b8b0f180bb349cef46511dce7f44ffd68f3.png":{"width":1194,"height":483}}}