DeepSeek OCR、テキストを画像に圧縮してAIのコスト削減とコンテキスト拡張を実現

読了時間:約10分
DeepSeek OCR、テキストを画像に圧縮してAIのコスト削減とコンテキスト拡張を実現

長文書をAIのコンテキストに収める新たな手法

DeepSeekは、長い文章を画像に変換して圧縮し、モデルが必要とする際に内容を復元する視覚言語システム「DeepSeek-OCR」を公開した。この手法では、設定や文書の種類に応じて、大規模言語モデルが処理するトークン数を7分の1から20分の1に減らせる。圧縮率が中程度であれば高い精度も保たれるという。DeepSeekによると、圧縮率が約10倍の時点で復号精度は約97%に達し、さらに高い圧縮率でも有用な結果が得られる。開発者向けにコードと重みが公開されており、現代のAIで最もコストがかかる課題の一つである、長いコンテキストを妥当な費用で処理することを目指す。

目次
  1. 長文書をAIのコンテキストに収める新たな手法
  2. テキストを画像に変換するとトークンが減る仕組み
  3. トークンとコンテキストウィンドウとは
  4. 保存ではテキストよりピクセルの方が低コストになり得る理由
  5. モデルの内部:DeepEncoderとデコーダー
  6. ベンチマークと精度の数値が示すもの
  7. AIのコスト、メモリー、製品設計に起こり得る変化
  8. 限界、リスク、未解決の課題
  9. DeepSeek OCRを今すぐ試す方法
  10. 要点

システムは2段階で動作する。DeepEncoderと呼ばれる視覚エンコーダーが、テキストのページや表、グラフなど、さまざまなレイアウトを少数の視覚トークンに変換する。次に、軽量な言語モデル「DeepSeek3B MoE A570M」が、そのトークンを構造化テキストに復号する。この構成は必要に応じてレイアウトや書式を保持し、多言語に対応するほか、プレーンテキストやMarkdownの表など構造化された形式で出力できる。

この手法の意義は、言語モデルが読み書きする基本単位であるトークンにある。トークンが増えるほどメモリー使用量と処理遅延が増し、コストも上がる。また、モデルが一度に扱えるコンテキスト量には上限がある。コンテキストを画像として保存し、視覚トークンを使って再び参照するDeepSeek-OCRは、長時間の対話や大規模文書向けに、より低コストのメモリー層を提供する。テキストだけの場合を大幅に超えて、実質的なコンテキストウィンドウを広げられる可能性がある。

処理規模も主要な訴求点だ。学習には約100言語のPDFページ約3,000万枚を使い、グラフや数式、図版向けに合成データも追加した。運用面では、Nvidia A100 GPU 1基で1日当たり20万ページ超を処理できるとチームは報告している。同等のサーバー20台で構成するクラスターなら、1日約3,300万ページに達するという。こうした数値は、文書のデジタル化や、大規模な学習データ生成を高速化できる可能性を示している。

広告

テキストを画像に変換するとトークンが減る仕組み

言語モデルは、単語や文字ではなくトークン単位で入力を読み取る。一般的な記事や報告書でも、数千のトークンになることがある。多くのトランスフォーマーに組み込まれたアテンション機構は、多数のトークンの組み合わせを比較するため、系列が長くなるほど処理量が急増する。長いコンテキストはメモリーと処理時間を押し上げ、大規模運用では予算上の問題となる。

トークンとコンテキストウィンドウとは

トークンとは、モデルが理解する言語の断片だ。短い単語は1トークンの場合がある一方、長い単語は複数に分割されることがあり、句読点もトークンとして数えられる。モデルが一度に扱えるトークン数の上限がコンテキストウィンドウだ。実際のファイルの多くはこの上限を超えるため、利用者は文書を途中で切るか、長いコンテキストに対応する特別なモデルに高い費用を払うことになる。

保存ではテキストよりピクセルの方が低コストになり得る理由

視覚エンコーダーは画像を小さなパッチのグリッドに変換し、さらにそのグリッドを視覚トークンの集合に圧縮する。DeepSeekのエンコーダーは圧縮ブロックを使い、特徴をデコーダーに渡す前にトークン数を減らす。技術資料の例では、1,024×1,024ピクセルの画像は当初4,096個のパッチトークンになるが、圧縮後は256個になり、視覚言語モデルの処理系に渡される。1,500個以上のテキストトークンを要する密度の高いページの要点を、この256個のトークンで捉えられるなら、すぐに削減効果が得られる。

仕組みは単純だ。長いコンテキストをテキストトークンで保存する代わりに、圧縮した視覚トークンでスナップショットを保存し、必要に応じて意味を再構成する。これによりメモリー予算を抑え、レイアウトや図表を保ちやすくなるほか、テキストのトークナイザー特有の問題も一部回避できる。一方、エンコードとデコードの工程が加わり、圧縮率が非常に高い場合は精度が徐々に低下する。

広告

モデルの内部:DeepEncoderとデコーダー

DeepEncoderは、局所的な認識と全体的な理解という、よく知られた2つの手法を組み合わせている。細かな領域や輪郭を捉えるためSegment Anything Modelのバックボーンを使い、より広い意味的なレイアウトの把握にはCLIP型のモジュールを採用する。その間には畳み込み型の圧縮器があり、言語モデルの処理系に渡す前に視覚トークンの数を大幅に削減する。複数の解像度モードに対応しており、ページごとの複雑さに合わせてトークン予算を調整できる。シンプルなスライドなら少ないトークンで済むが、情報量の多い新聞ページや複雑な科学図版では、より多くのトークンが必要になる。

デコーダーは、30億パラメーターの設計を基盤とし、トークンごとに約5億7,000万パラメーターを有効化するMixture of Experts型の言語モデルだ。専門家の振り分けによって、すべてのトークンで30億パラメーター全体を動かさずに、内容の種類に応じて処理を集中させられる。これにより品質を保ちながら計算量を抑える。プレーンテキストの出力やMarkdownによる構造の保持に加え、表やグラフから機械処理しやすい形式でデータを抽出できる。多言語OCRに対応し、図表や化学構造式、幾何学図形も解釈できる。

設定のプリセットにはTiny、Small、Base、Largeがあり、非常に複雑なページ向けの動的モードも用意されている。プリセットは画像サイズとトークン数のバランスを取る。DeepSeekは一般的なページにはSmallから始め、情報量が多い場合やレイアウトが複雑な場合にのみ上位の設定に切り替えることを推奨している。

ベンチマークと精度の数値が示すもの

圧縮が有用なのは、デコーダーがテキストを高い忠実度で復元できる場合に限られる。DeepSeekによると、圧縮率が10倍未満の復号テストでは、精度は約97%。圧縮率が約20倍になると約60%に低下する。さらに、700〜800個のテキストトークンを要する文書を100個の視覚トークンで表現し、対象を絞ったベンチマークで約97%の精度を維持した例も示している。こうした数値は、中程度の圧縮が削減効果と精度の最良のバランスをもたらすという主張に沿っている。

文書理解の一般的な評価テスト「OmniDocBench」では、トークン数を抑えながら、広く知られたOCRシステムを上回る。必要なトークン数は文書の種類によって異なる。スライドやシンプルなパンフレットなら、1ページ当たり約64個の視覚トークンで済むことがある。一方、段組みや画像が多い雑誌や新聞では、数百個必要になる場合がある。利用者の設定に応じて、書式を維持することも、取り除くこともできる。

運用性能の数値は野心的だ。チームは、Nvidia A100カード1基で1日当たり20万ページ超、サーバー20台のクラスターで1日当たり約3,300万ページを処理できるとしている。学習・推論用コードとモデルの重みは、制約の緩やかなライセンスで公開されている。これにより、研究や実運用の現場で迅速な試験が可能になる。

広告

AIのコスト、メモリー、製品設計に起こり得る変化

多くのAI製品は、対話や文書のやりとりが長くなると処理の限界に達する。過去のコンテキストを視覚トークンとして保存すれば、より低コストのメモリー層をモデルに持たせられる。以前のやりとりを画像に要約・圧縮し、必要なときにだけ詳細を復号する仕組みが可能になる。これにより、現在処理するテキストのコンテキストを小さく保ちながら、過去の段階で出てきた事実や引用、レイアウトを呼び戻せる。また、従来のトークナイザーでは扱いにくい複雑な表や数式を含むページにも対応しやすくなる。

利用者にとっては、実用的な作業が可能になる。アシスタントが長文のPDFや契約書、スプレッドシート全体を取り込み、コンパクトなメモリーに保持したうえで、求められれば構造を保ったまま該当箇所を復元できる。デコーダーは文字列だけでなく構造も再構成するため、表から行をコピーしたり、図表のキャプションを抽出したりする作業も容易になる。圧縮したページのスナップショットを索引化し、必要に応じて抜粋を復号する、効率的な企業向け検索の実現も期待される。

開発者や研究者にとっては、処理能力が重要だ。このシステムは言語モデルや視覚モデル向けの大規模な学習コーパスを作成でき、GPU1基当たり1日数十万ページを処理できる。この速度は、教師ありデータを低コストで作る助けになる。金融、医療、科学など、グラフや帳票に依存する業界では、構造をより適切に保持しながらデジタル化を加速できる可能性がある。ただし、圧縮後の出力を将来の学習に使う場合、小さな復号エラーが大規模なノイズ付きラベルにつながり得るため、注意が必要だ。

限界、リスク、未解決の課題

圧縮率を上げると必要なトークン数は減るが、忠実度は下がる。報告された精度は、圧縮率が約20倍の場合、約60%に低下する。多少の誤りが許容されるタスクも多いが、氏名や数値、法的条項などはほぼ完全な復元が求められる。重要なページは圧縮率を低く設定し、厳密な再現を要しないコンテキストに限って強い圧縮を使うといった運用ルールが必要になる。

推論への影響も課題だ。モデルはテキストトークンを使って学習しているため、テキスト上での推論を得意とする。視覚トークンには異なる帰納バイアスがある。デコーダーはまずテキストを再構成し、その後に推論しなければならない。この追加工程が、長い思考の連鎖を要するタスクに影響する可能性がある。重要なコンテキストが画像層の背後にある場合の多段階推論を検証し、精度が特に重要なタスク向けに代替手段を用意することが望ましい。

処理遅延とインフラ計画も引き続き重要だ。エンコードとデコードの追加工程には処理が必要となる。文書の量が増えたり、対話が長くなったりして初めて削減効果が現れる。導入に際しては、複数種類の文書で実時間、メモリー、コストを測定し、圧縮する場合とテキストをそのまま渡す場合の基準を定めるべきだ。保存形式も変わり、生のテキストファイルに代わって画像や画像に似たテンソルが使われるため、検索システムやコンプライアンス処理に影響する可能性がある。

プライバシーとセキュリティにも注意が必要だ。機密ファイルを画像や視覚トークンに圧縮しても、リスクがなくなるわけではない。圧縮後のデータにもアクセス制御、暗号化、監査記録を適用しなければならない。低解像度のスキャン画像や判読しにくい手書き文字など、モデルが依然として苦手とする文書もある。重要な業務では、動的モードの選択と人による確認が引き続き賢明だ。

広告

DeepSeek OCRを今すぐ試す方法

Hugging Faceのプロジェクトページでは、モデルカードやクイックスタート手順、ダウンロードを提供している。コードと重みはGitHubでも公開されており、学術・商用の両方を対象とする制約の緩やかなライセンスが適用されている。開発者は、こちらから始められる。Hugging Faceのモデルページ、およびこちら。GitHubリポジトリ。

リファレンス環境はPython 3.12.9とCUDA 11.8を指定しており、依存関係にはPyTorch、Transformers、Tokenizers、Einops、Addict、Easydict、Flash Attentionが含まれる。速度を重視する場合はNvidia GPUが推奨される。プリセットモードでは詳細度とコストを調整できる。一般的なビジネス文書ならSmallモードが妥当な出発点となる。科学や法律に関する情報量の多いページでは、より高い解像度や動的モードが適している場合がある。

一般的な処理手順は、PDFをページ画像に変換し、選んだ解像度で各ページをDeepEncoderに入力した後、言語モデルで生成された視覚トークンを復号するというものだ。検索向けのプレーンテキストや、表と見出しを保持するMarkdownで出力できる。GitHubリポジトリには一括処理用スクリプトと処理能力を高めるためのヒントが含まれている。圧縮率を上げる場合は精度を監視し、重要なページには保守的な設定を維持すべきだ。

要点

  • DeepSeek-OCRは長いテキストを画像として保存して圧縮し、必要に応じてデコーダーで内容を復元する。
  • 設定や文書の複雑さに応じて、トークン使用量をおおむね7分の1から20分の1に削減する。
  • 報告された復号精度は、圧縮率が約10倍の時点で約97%、約20倍では約60%。
  • DeepEncoderと、トークンごとに約5億7,000万パラメーターを有効化するMixture of Experts型デコーダーを組み合わせている。
  • TinyからLargeまでのモードに加え、非常に複雑なページ向けの動的設定があり、明示的にトークン予算を決められる。
  • ベンチマークでは、一般的なOCRの比較対象より少ないトークンでOmniDocBenchの高い成績を示している。
  • 処理能力について、Nvidia A100 GPU 1基で1日20万ページ超、サーバー20台のクラスターで1日約3,300万ページという数値を挙げている。
  • Markdownの表やグラフデータなどの構造化出力に対応し、図表、数式、多数の言語も扱える。
  • オープンソースのコードと重みは、制約の緩やかなライセンスの下、Hugging FaceとGitHubで公開されている。
  • 長いコンテキストのメモリーコスト削減、大規模な文書デジタル化、学習データ生成が主な用途。精度が重要な作業では慎重な設定が必要となる。
この記事を共有

こちらもおすすめ