DeepSeek-OCR解説：スケーラブルなロングコンテキストおよびRAGシステムのための光学的圧縮
大規模言語モデル（LLM）は、長いコンテキストを処理する際にいまだ苦戦しています。長いテキストを扱うと大量の計算能力を消費し、レイテンシが増加し、出力品質が低下することもよくあります。多くの最適化の取り組みにもかかわらず、結果は満足のいくものにはなっていません。
この問題に対処するため、DeepSeekはDeepSeek-OCRを発表しました。これは、光学的2Dマッピングを使用して長いコンテキストを圧縮するオープンソースモデルです。生のテキストをモデルに入力する代わりに、テキストのページを画像に変換し、それらの画像を視覚トークンとして扱います。1枚の画像には数千のテキストトークンに相当する情報を含めることができるため、モデルははるかに少ないリソースで長い文書を処理できます。
このアイデアは賢く、かつシンプルです。視覚表現を使うことで、DeepSeek-OCRは計算量を削減しながら高い精度を維持します。これは、LLMの長いコンテキスト処理だけでなく、高コストと限られたコンテキストウィンドウに長く苦しんできたRAGシステムにとっても転換点となる可能性があります。
以降のセクションでは、DeepSeek-OCRがどのように機能するのかを説明し、この「光学的圧縮」アプローチが次世代のLLMとRAGシステムをどのように形作る可能性があるのかを探ります。
LLMがテキストを扱う従来の方法 — そしてその主要な限界
DeepSeek-OCRがなぜこれほど重要なのかを理解するには、まず大規模言語モデル（LLM）が従来どのようにテキストを扱い、どのような限界があるのかを理解すると役立ちます。LLMは人間のように単語や文を読むわけではありません。LLMはトークンを処理します。トークンとは、単語、サブワード、さらには文字など、テキストの小さな単位です。モデルが入力を受け取ると、テキストをこれらのトークンの長いシーケンスに変換します。次に、自己注意機構がすべてのトークンを他のすべてのトークンと比較し、コンテキストと意味を理解します。この方法は短い文章ではうまく機能しますが、シーケンスが長くなるにつれて急速に非効率になります。
二次関数的な計算コスト
その非効率性は数学に根ざしています。自己注意の計算コストは、トークン数に対して二次関数的（O(n²)）に増加します。入力が1,000トークンから10,000トークンに増えると、注意演算の数は100倍になります。最高級のGPUでさえ、このようなワークロードに直面するとメモリ制限や推論タイムアウトに達することがあります。
平坦化された注意: 長いコンテキストで焦点を失う
問題はそれだけではありません。シーケンスが長くなると、モデルの注意重みは平坦化する傾向があります。つまり、テキスト全体に均等に広がりすぎたり、冒頭と末尾だけに集中したりします。この焦点の喪失は、どれだけ計算リソースを投入しても、精度と関連性を損ないます。
マルチモーダルおよび構造化テキストにおける非効率性
テキストトークンは、PDF、スライド、スプレッドシートなどのマルチモーダルまたは構造化文書タスクにおいても不十分です。テキストがトークン化されると、レイアウト、表、視覚的構造は失われますが、それらは重要な意味を担っています。多言語テキストはさらに複雑さを増します。各言語には、独自の分割ルールを持つ専用のトークナイザーが必要です。そして結局、最も積極的なテキストベースの圧縮でさえ、トークン数の削減はせいぜい1〜2倍程度にとどまり、本格的な長文コンテキスト用途には到底足りません。
DeepSeek-OCR: コンテキストの光学的圧縮によって長文コンテキスト処理を強化する
前述のとおり、従来のトークンベースのアプローチには、計算コストの高さ、焦点の喪失、マルチモーダルテキストを扱う際の文書構造の喪失という3つの大きな限界があります。DeepSeek-OCRは、テキストを視覚トークンに変換することで、これらの課題を克服します。より少ない要素により多くの情報を圧縮しながら、意味と構造を保持します。
では、これはどのように機能するのでしょうか？鍵となるのは、Contexts Optical Compressionと呼ばれる新しいパラダイムです。長いテキストトークンのストリームをモデルに入力する代わりに、DeepSeek-OCRはまずテキストを画像に変換し、その画像をコンパクトな視覚トークンへとエンコードします。このプロセスは、LLMにおける2つの最大の課題、すなわち長いコンテキストの高い計算コストと、トークン化の過程で文書構造が失われることに直接対処します。
仕組みは次の3ステップです。
テキストを構造化された文書画像としてレンダリングする。 元のテキストは、チャート、表、数式とともに、視覚的レイアウトと意味的手がかりを保持する画像としてレンダリングされます。
画像を視覚トークンに圧縮する。 視覚エンコーダーが各画像をコンパクトな表現に変換し、トークン数を7〜20分の1に削減します。OmniDocBenchなどのベンチマークでは最大60分の1まで削減されます。
視覚トークンからテキストを再構築する。 言語デコーダーがこれらの視覚トークンをテキストに戻し、意味とフォーマットの両方を保持しながら、97%を超える認識精度を実現します。
このアプローチが機能するのは、文書画像が同等の意味情報をはるかに少ないトークン数で保持できるためです。同時に、通常のトークン化では破棄されるレイアウト、記号、その他の非テキスト要素も本質的に保持します。結果として、DeepSeek-OCRはテキストベースのLLMの中核的な制約を回避し、構造、意味、効率を同時に維持します。
内部では、Contexts Optical Compressionは2つの中核コンポーネントによって支えられています。文書画像を高圧縮率で圧縮するDeepEncoderと、視覚トークンから元の内容を再構築するMoE (Mixture-of-Experts) Decoderです。これらを組み合わせることで、DeepSeek-OCRは長いコンテキスト情報を高精度かつ驚くほど効率的に処理できます。
DeepEncoder: 圧縮と精度の融合
DeepEncoderはDeepSeek-OCRアーキテクチャの中核であり、視覚特徴を抽出し、それらをコンパクトで情報量の多い視覚トークンへ圧縮する役割を担うコンポーネントです。3部構成のアーキテクチャにより、精度と効率を両立しています。
SAM-base (800M parameters): windowed attentionを使用して高解像度の文書画像を処理します。この設計により、文字や句読点などの細かな詳細を捉えつつ、アクティベーションメモリを制御可能な範囲に抑えます。
16× Convolutional Compressor (2 layers): 画像トークンの数を16分の1に削減します。たとえば、最初に4,096トークンを生成する1024×1024画像は、わずか256トークンまで縮小され、品質低下を最小限に抑えながら16× compressionを実現します。
CLIP-large (300M parameters): dense global attentionを適用して、文書全体にわたる意味的一貫性を維持します。積極的な圧縮下でも、表の行と列の対応関係や数式構造などの関係を保持します。
DeepEncoderは、Tiny、Small、Base、Large、Gundam、Gundam-Mの6つの解像度モードをサポートし、タスク要件に応じて64〜1,853個の視覚トークンを生成します。この柔軟性により、適応的なコンテキスト管理が可能になります。古い、または重要度の低いコンテンツには低解像度圧縮を、最近の重要なセグメントには高解像度エンコードを使用できます。
MoE Decoder: 効率的で正確な再構築
圧縮が完了すると、MoE (Mixture of Experts) Decoderがテキストを効率的かつ正確に再構築します。DeepSeek-OCRはDeepSeek-3B-MoE-A570Mモデルを採用しており、わずかな計算量で大規模モデル並みの精度を実現します。一度に有効化されるのは570Mパラメータのみであり（64個のエキスパートから6個を選択し、さらに2個の共有エキスパートを使用）、3-billion-parameterフレームワーク内で大規模モデルに匹敵する処理精度を達成します。
デコーダーはまた、視覚トークンからテキストトークンへの非線形マッピングもサポートしており、構造化され、意味的に豊かな出力を可能にします。たとえば、チャートをHTMLテーブルに変換したり、化学式をSMILES文字列に翻訳したりすることで、複雑な視覚データがテキストで忠実に表現されるようにします。
性能の面では、MoE Decoderは高速かつスケーラブルです。
純粋なテキストデータで1日あたり最大900億トークンを処理
マルチモーダルデータセットで1日あたり700億トークンを処理
単一のA100-40G GPUで毎秒2,500トークンのスループットを達成
この圧縮効率、構造保持、デコード速度の組み合わせにより、長文コンテキスト処理のコストを劇的に引き下げながら、大規模モデルに近い精度を維持します。
DeepSeek-OCRが達成したことと、それが重要である理由
DeepSeek-OCRの影響は、OCR精度の向上をはるかに超えています。クロスモーダル圧縮を通じて、長文コンテキストLLM、マルチモーダル推論、多言語文書理解のための新たな基盤を導入します。テキストを汎用的な視覚表現に変換することで、DeepSeek-OCRは大規模モデルの効率性と汎用性の限界を押し広げる3つの重要な進歩を実現します。
1. テキストと画像が混在する文書のエンドツーエンド処理
従来のパイプラインは、チャート、数式、その他の視覚要素を含む文書の処理に苦労します。一般的には、画像をテキストに変換するために別個のOCRステップに依存しており、その際にフォーマットが失われたり、構造が崩れたり、認識エラーが発生したりすることが多く、その後テキストがさらなる処理のためにトークナイザーへ渡されます。
DeepSeek-OCRは、この壊れやすい中間ステップを排除します。 混在するテキストとグラフィックのコンテンツを、統一された視覚トークンへ直接変換し、単一の連続したワークフローの中で構造と視覚的完全性を保持します。たとえば、埋め込み折れ線グラフを含む財務レポートを分析する場合、モデルの視覚トークンはトレンドそのものを保持します。その後、デコーダーは単なるフラットな文字列ではなく、編集可能なHTMLテーブルや整形済みテキストなどの構造化された出力を生成できます。
2. 多言語処理におけるより高い普遍性
トークンベースのシステムでは、言語ごとに個別のトークナイザーが必要であり、それぞれが異なる分割規則に従います。たとえば、中国語の文字構成、英語のサブワード単位、アラビア文字の接続などです。この複雑性を管理することは、多言語モデルの学習と保守を高コストかつエラーが発生しやすいものにします。
DeepSeek-OCRは、画像を中間表現として使用することでこれを解決し、言語ファミリーを区別することなく100以上の言語を処理できるようにします。これにより、多言語文書理解への参入障壁が下がり、単一のモデルアーキテクチャで多様な文字体系をシームレスに扱えるようになります。
3. 長文書のための低コスト化とより賢いコンテキスト管理
スライディングウィンドウやスパースアテンションなどの従来の長文コンテキスト処理ソリューションは、テキストトークンのレベルで効率を最適化しますが、それでもアテンションのO(n²)計算ボトルネックの範囲内で動作します。対照的に、テキスト → 画像 → 視覚トークンへ変換することで、DeepSeek-OCRはテキストベースの計算をより低複雑度の視覚的キャリアに置き換え、長いテキスト列に伴う重い計算負荷を軽減します。
この設計は、もう一つの重要な利点をもたらします。それは適応的コンテキスト管理です。モデルは、最近の詳細に富んだコンテンツにはより高い解像度（より多くの視覚トークン）を割り当てる一方、古い情報や重要度の低い情報にはより低い解像度（より少ない視覚トークン）を割り当てることができます。これにより、DeepSeek-OCRは、メモリと精度の両方が重要となるマルチターン対話、長文書分析、検索拡張生成（RAG）のシナリオにおいて特に効果的です。
今後の展望：DeepSeek-OCRが示すRAGの未来
DeepSeek-OCRは、RAGが次にどこへ向かう可能性があるかについて貴重な洞察を提供します。その中核原理——情報を視覚トークンへ圧縮すること——は、テキストを高密度な埋め込みへ変換するSentence-BERTのようなモデルの背後にあるロジックと響き合います。どちらのアプローチも、豊かで複雑な情報をコンパクトかつ計算効率の高い形式で表現するという同じ目標を共有しています。
今後、この考え方はマルチモーダルRAGを根本的に再形成する可能性があります。図表、表、または図を含むドキュメントを処理する際、DeepSeek-OCRはデコード手順を完全に省略し、圧縮された視覚トークンを推論や生成のためにマルチモーダル大規模モデルへ直接入力できます。将来のRAGシステムも同様の道をたどり、現在の多段階プロセス（埋め込み類似検索 → テキスト再構成 → LLM入力）から、より合理化されたパイプライン、すなわち埋め込み検索 → 直接LLM入力へ進化する可能性があります。
このパラダイムシフトは、RAGが長年抱えてきたいくつかの非効率性に対処します。現在のシステムは、クエリごとにテキストを繰り返しトークン化し、埋め込みを再生成しており、計算資源を浪費し、情報損失を引き起こしています。これらのコストは、長いドキュメントではさらに増大します。なぜなら、アテンション機構はトークン数に対して二次的にスケールするためです。対照的に、埋め込みや視覚トークンを検索してLLMに直接供給できれば、トークン化による損失は排除され、 計算オーバーヘッドは劇的に低下します。
これにより、より効率的なオフライン–オンラインのワークフローも可能になります。埋め込みは一度生成して、Milvusのようなベクトルデータベースに保存し、無期限に再利用できます。クエリ時には、Top-Kの埋め込み（多くの場合20未満）だけを取得すれば、モデルに対して正確な文脈的根拠を提供できます。
読み続けて
Why I’m Against Claude Code’s Grep-Only Retrieval? It Just Burns Too Many Tokens
Learn how vector-based code retrieval cuts Claude Code token consumption by 40%. Open-source solution with easy MCP integration. Try claude-context today.
Why Context Engineering Is Becoming the Full Stack of AI Agents
Discover how context engineering unifies prompts, RAG, and tools to build smarter, production-ready AI agents powered by Milvus.
Selecting the Right ETL Tools for Unstructured Data to Prepare for AI
Learn the right ETL tools for unstructured data to power AI. Explore key challenges, tool comparisons, and integrations with Milvus for vector search.