mPLUG-DocOwl2とは？論文の要点と324トークン圧縮・多ページ解析の採用判断

mPLUG-DocOwl2は、アリババの mPLUG チームが2024年9月に公開した、OCRを介さずに文書画像を読む8Bのマルチモーダル大規模言語モデルです。最大の特徴は、文書1ページをわずか324個のビジュアルトークンに圧縮したうえで、DocVQAのANLS 80.7という水準を保つ点にあります。ただし「あらゆる文書AIの中で最も精度が高いモデル」ではありません。同じ8BのInternVL 2はDocVQAで91.6を出しており、精度だけを見ればmPLUG-DocOwl2は上位ではないからです。このモデルが優位に立つのは、トークン数あたりの精度と、最初の応答が返るまでの待ち時間です。ここでは論文の書誌情報から圧縮アーキテクチャ、ベンチマークの実測値、そして公開チェックポイントに残る制約までを、arXiv論文と公式リポジトリの記述に沿って整理します。

まとめ

• 正式な論文名は「mPLUG-DocOwl2: High-resolution Compressing for OCR-free Multi-page Document Understanding」、arXiv:2409.03420 として2024年9月5日に投稿され、2025年5月16日に公式リポジトリでACL 2025採択が告知されました。
• 中核はHigh-resolution DocCompressorという2層のクロスアテンション圧縮モジュールで、504×504のサブ画像群を1ページあたり324トークンへ縮約します。
• DocVQAのANLSは80.7で、前身のDocOwl 1.5(82.2)やInternVL 2(91.6)を下回ります。勝っているのはトークン数(324 対 約1,806・約3,198)とファーストトークンレイテンシ(0.26秒 対 0.58秒・0.94秒)です。
• 多ページ側では優位が明確で、MP-DocVQA 69.42・DUDE 46.77・NewsVideoQA 64.09を、比較対象すべてより短い待ち時間で達成しています。
• ただし精度はページ数に強く依存し、MP-DocVQAは1ページで83.3、2から10ページで70.2、10ページ超では42.5まで落ちます。長い文書をそのまま投げる使い方は成立しません。
• モデルとコードはApache-2.0でHuggingFaceとModelScopeに公開済みですが、GitHubリポジトリの最終pushは2025年5月30日で、2026年8月時点では1年以上更新が止まっています。

mPLUG-DocOwl2の論文情報と参照先

検索で「mplug-docowl2 論文名」にたどり着く読者が最初に必要とするのは、引用可能な書誌情報です。以下がarXivの登録内容そのものです。

正式名称・著者・公開日

日本語の解説記事では「DocOwl2」と略されることが多いものの、論文中およびHuggingFace上のモデル名は mPLUG-DocOwl2 および mPLUG/DocOwl2 です。引用時は正式名称を使ってください。

DocOwlシリーズ内での位置づけ

mPLUG-DocOwl2は独立した新モデルではなく、mPLUG-DocOwl 1.5（arXiv:2403.12895、EMNLP 2024採択）のアーキテクチャを土台にしています。論文の記述どおり、DocOwl 1.5がすでに備えていた Shape-adaptive Cropping Module と、視覚特徴を言語モデル側へ橋渡しする H-Reducer をそのまま引き継ぎ、その後段に圧縮モジュールを差し込んだ構成です。パラメータの初期値も、同チームの汎用モデルである mPLUG-Owl2 から引き継いでいます。

つまりDocOwl 1.5からDocOwl2への変更は「精度を上げるための改良」ではなく「同等の精度をより少ないトークンで出すための改良」です。この設計意図を押さえておくと、後述するベンチマークで精度が微減している理由がそのまま理解できます。

High-resolution DocCompressorによる324トークン圧縮の仕組み

OCRを使わない文書理解モデルが抱える構造的な問題は、解像度を上げるほどビジュアルトークンが増え、GPUメモリと推論時間を圧迫することです。論文はこの点を出発点に、圧縮の置き場所と圧縮の効かせ方の両方を作り替えました。

切り出しとViTによる特徴抽出

入力ページはまず切り出しモジュールで複数のサブ画像に分割され、ページ全体を縮小したグローバル画像とあわせてViT/L-14で符号化されます。公開チェックポイントの config.json では、視覚エンコーダの image_size が504、patch_size が14、層数が24と定義されています。公式サンプルが crop_anchors へ渡す grid_12 は、最大12分割までのアスペクト比候補を持つという意味です（配布実装の DocProcessor 側の既定値でもあります）。

グローバル特徴をクエリにしたクロスアテンション圧縮

DocCompressorの発想は、圧縮のクエリに学習可能なパラメータやダウンサンプリング結果ではなく、低解像度のグローバル視覚特徴そのものを使う点にあります。論文が挙げる問題は、二段組の論文で「Related Work」節の文字と、同じ行に並んでいながら「Method」節に属する文字とが、レイアウトを見ない圧縮方式では一緒くたに要約されてしまうことです。DocCompressorはこれを避けるため、グローバル特徴マップ上の各クエリに対し、元画像で同じ相対位置を占める高解像度特徴だけをグループとして集め、2層のクロスアテンションで畳み込みます。このグループはサブ画像の境界をまたぐこともあり、切り出しで分断された同一レイアウト領域を元どおりまとめ直せる点が要になっています。

この設計が効いていることは、論文のアブレーション実験で確認できます。同じ256トークンという条件で圧縮方式だけを差し替えると、DocVQAのスコアは学習可能クエリのResamplerで69.0、適応平均のCAbstractorで73.0、DocCompressorで76.1でした。さらに基準解像度を448から504へ引き上げた設定（トークン数324）で78.7まで伸び、これが最終構成に採用されています。

（論文 Table 5 の r1・r2・r3・r10 を抜粋）

324という数字は経験的な調整値ではなく、解像度とH-Reducerの圧縮率から一意に決まります。グローバル画像の一辺504をパッチサイズ14で割ると36、パッチ総数は36×36で1,296です。config.json の visual_hreducer に conv_shape が 1×4 と定義されているとおり、H-Reducerは横方向4個を1トークンへまとめるので、1,296÷4＝324になります。基準解像度が448だった設定では (448÷14)²÷4＝256となり、アブレーション表の256トークンと一致します。なお分割数はトークン数に影響しません。448で9分割した設定も12分割した設定もどちらも256トークンで、324へ増えたのは解像度を504へ上げたためです。

3段階トレーニングと学習データの実数

圧縮モジュールを入れただけでは多ページの文脈は扱えないため、学習も3段階に分けられています。各段階で使うデータセットと件数は論文に明記されています。

（論文 Table 1 より）

どの段階が多ページ性能を生んでいるかも、論文が分解して示しています。MP-DocVQAの10ページ超セグメントで見ると、事前学習もファインチューニングも単一画像だけの構成は5.8で、ほぼ答えられていません。ファインチューニングを単一画像から複数画像へ差し替えると34.6へ跳ね上がり、事前学習にも複数画像の段階を加えて37.9、さらに単一画像のファインチューニングを併用した最終構成で42.5になります。MP-DocVQA全体のスコアで見ても54.2から69.4です。多ページ対応を作っているのは圧縮モジュールではなく学習設計だ、と読むのが正確です。

ベンチマーク実測値で見る精度と待ち時間の交換比

論文がIntroductionの貢献リストで挙げる成果は3点あります。既存の圧縮方式より少ないトークンで単一画像の文書理解性能を上回った点。多ページ文書のベンチマークで、ファーストトークンレイテンシを従来の50パーセント未満に抑えたうえで最高水準に達した点。そしてモデル規模と学習データが同等の既存モデルに対し、10種類の単一画像ベンチマークでビジュアルトークン20パーセント未満のまま同等の性能を出したことです。見落とされやすいのは、最高水準と言えるのが多ページ側に限られる点で、単一ページの精度でも優位に立つモデルだと誤解されがちです。論文の同一表から引いた数値を並べると、何と何を交換したモデルなのかがはっきりします。

単一ページでの精度順位とレイテンシ優位の内訳

（論文 Table 3 より。トークン数はDocVQA評価時の実測で、単一画像の総合表である Table 2 の値とは異なります）

DocVQAで見れば、mPLUG-DocOwl2はInternVL 2に10.9ポイント、前身のDocOwl 1.5にも1.5ポイント負けています。一方でトークン数はDocOwl 1.5の約18パーセント、初回応答は0.58秒から0.26秒へ55パーセント短縮されました。ChartQAは324トークン・0.21秒で70.0、TextVQAは324トークン・0.23秒で66.7と、いずれも精度をほぼ維持したまま待ち時間だけを削っています。

したがって、単一ページの文書から高精度に値を抜きたい用途であれば、mPLUG-DocOwl2を選ぶ理由はありません。InternVL 2のほうが素直に強いからです。選ぶ理由が生まれるのは、1リクエストあたりのGPU占有時間を削りたい場合と、次に述べる多ページの場合に限られます。

多ページでの精度と待ち時間の同時優位

（論文 Table 4 より。トークン数は原典の注記どおり1ページまたは1フレームあたりの平均値です）

多ページ側では精度でも待ち時間でも比較対象を上回ります。DUDEではIdefics3-8Bに8.1ポイント差をつけ、NewsVideoQAでは待ち時間が6.39秒から1.17秒へ縮んでいます。もっとも待ち時間の差は相手と課題によって幅があります。LongVAとIdefics3に対しては3ベンチマークとも半分以下ですが、LLaVA-next-interleaveに対してはNewsVideoQAで約27パーセントまで縮む一方、MP-DocVQAとDUDEでは6割程度にとどまります。mPLUG-DocOwl2の価値はこの表に集約されている、と考えて差し支えありません。

ページ数別に見たスコアの減衰

ただし多ページ性能は一定ではありません。MP-DocVQAをページ数別に分解すると、1ページで83.3、2から10ページで70.2、10ページ超では42.5まで落ちます。証拠ページの位置で分けた場合も、1ページ目にあれば78.6、2から10ページ目で60.9、10ページ目より後ろでは53.6です。長い契約書や報告書をそのまま投げて後半の記述を引かせる用途は、この数値の時点で成立しません。数十ページの文書を扱うなら、該当しそうなページを先に絞り込む検索工程を前段に置く設計が要ります。考え方はマルチモーダルRAGとは？図表・画像を検索する仕組みと実装方式の選び方で整理した検索併用型の構成と同じです。

公開モデルの入手と推論コード

HuggingFace・ModelScope配布とApache-2.0の適用範囲

重みはHuggingFaceの mPLUG/DocOwl2 とModelScopeの iic/DocOwl2 で配布されており、ライセンスはリポジトリ・モデルカードともにApache-2.0です。ただしApache-2.0が掛かるのはmPLUGチームが配布する成果物までで、LLM部分は同チームの mPLUG-Owl2 から初期化されたLLaMA系のアーキテクチャです（config.json の語彙数32,000・隠れ層4,096・32層がそれを示します）。商用導入では上流モデルと各学習データセットのライセンス条件を別途確認してください。学習データ側は MP-DocStruct1M、DocDownstream-2.0、MP-DocReason51K、DocGenome12K が公開済みで、追加学習の再現に必要な素材はそろっています。2024年12月にはms-swift経由の学習コードも公開されました。

transformersからの推論

推論は transformers の AutoModel に trust_remote_code を渡してカスタム実装を読み込む形です。以下は公式リポジトリのサンプルから未使用のインポートを除いたもので、init_processor と chat はいずれも配布実装の modeling_mplug_docowl.py に定義されているメソッドであり、引数名がシグネチャと一致することを確認しています（実行にはGPUと重みのダウンロードが必要です）。

import torch
from transformers import AutoTokenizer, AutoModel


class DocOwlInfer:
    def __init__(self, ckpt_path):
        self.tokenizer = AutoTokenizer.from_pretrained(ckpt_path, use_fast=False)
        self.model = AutoModel.from_pretrained(
            ckpt_path,
            trust_remote_code=True,
            low_cpu_mem_usage=True,
            torch_dtype=torch.float16,
            device_map='auto',
        )
        self.model.init_processor(
            tokenizer=self.tokenizer, basic_image_size=504, crop_anchors='grid_12'
        )

    def inference(self, images, query):
        messages = [{'role': 'USER', 'content': '<|image|>' * len(images) + query}]
        return self.model.chat(messages=messages, images=images, tokenizer=self.tokenizer)


docowl = DocOwlInfer(ckpt_path='mPLUG/DocOwl2')
images = ['./examples/docowl2_page%d.png' % i for i in range(6)]
print(docowl.inference(images, query='what is this paper about? provide detailed information.'))

ページ数ぶんの <|image|> プレースホルダを本文の先頭に連結する点が独特です。画像リストの並び順がそのままページ順として解釈されるため、ソート順の取り違えは回答内容の誤りに直結します。

導入前に確認したい制約

論文とベンチマークだけを読むと採用したくなりますが、公開されている成果物には論文に書かれていない事情が残っています。採用判断の前に、次の点は潰しておきたいところです。

学習時の想定文脈長2048とページ数の関係

HuggingFaceで配布されている config.json の max_position_embeddings は2048です。1ページ324トークンを消費するので、7ページで2,268トークンとなり、画像だけでこの想定長を超えます。ただしこれは入力を弾くハードリミットではありません。同梱の modeling_llama2_mam.py にある回転位置埋め込みの実装は、入力長が確保済みのキャッシュを超えたときに自動でキャッシュを作り直す作りになっており、長い入力もエラーにはならず通ります。論文自身も同じモデルで10ページ超のセグメントを評価しています。

問題は通るかどうかではなく、ページ数が増えるほど精度が落ちることです。ベンチマークの節で見た10ページ超の42.5がその実測で、想定文脈長の超過は一因と考えられます。ただし2から10ページの帯でも70.2まで下がっており、2048という値だけで説明できる現象ではありません。いずれにせよ数十ページの文書を丸ごと投げる設計は、動くけれども答えが合わない、という最も厄介な失敗の仕方をします。

stage1・stage2は未公開のまま、開発は2025年5月で停止

公式のDocOwl2ディレクトリにあるチェックリストでは、最終モデルのDocOwl2は公開済みですが、中間段階のDocOwl2-stage1とDocOwl2-stage2、およびオンラインデモは未完了のまま残っています。配布表のリンクも空欄です。さらにGitHubリポジトリの最終pushは2025年5月30日で、2026年8月時点で1年以上コードが更新されていません。HuggingFace側のモデル更新日も2024年9月27日のままです。

同じmPLUGチームは、その後GUIエージェント向けのGUI-Owlシリーズに軸足を移しています。HuggingFace上の直近30日ダウンロード数を比べると、GUI-Owl-1.5-8B-Instructが4,793に対しDocOwl2は153です。名前の似た mPLUG-Owl3 は公開されていますが、こちらは長い画像系列を扱う汎用のマルチモーダルモデルで、文書理解に特化したDocOwl系列の後継ではありません。DocOwl3にあたるモデルは2026年8月時点で存在しません。長期の保守を前提とする基幹システムに組み込むなら、この停滞は無視できない材料です。文書処理基盤として継続的な更新を求めるなら、従来OCRの限界を超えるdots.mocrのマルチモーダル解析という新発想で扱ったような、より新しいOCRフリー系モデルも並行して評価対象に入れるべきです。

日本語文書は対象外の扱い

HuggingFaceのモデルカードに付与された言語タグは en のみで、学習・評価に使われたDocVQA、InfoVQA、DUDE、NewsVideoQAもいずれも英語の文書・映像データセットです。日本語の請求書や契約書に対する精度は公式には一切測定されていません。日本語の帳票処理を目的にしているなら、まずOCRとは？光学文字認識の仕組み・種類・精度と実装での組み込み方を解説で扱った従来型OCRや、日本語を含む多言語で評価されているmistral-document-ai-2512の基本仕様と既存OCRモデルとの位置づけの差異のような選択肢を先に検討するほうが、検証コストは低く済みます。

よくある質問

mPLUG-DocOwl2の論文名は何ですか？

「mPLUG-DocOwl2: High-resolution Compressing for OCR-free Multi-page Document Understanding」です。arXiv:2409.03420 として2024年9月5日に投稿され、2025年5月にACL 2025へ採択されました。

DocOwl 1.5との違いはどこですか？

アーキテクチャの土台は同じで、H-Reducerの後段にHigh-resolution DocCompressorを追加した点が違いです。結果としてビジュアルトークンは約1,806から324へ減り、DocVQAの初回応答は0.58秒から0.26秒になりました。ANLSは82.2から80.7へわずかに下がっています。

GPT-4VやClaudeと比べてどうですか？

論文には比較データがありません。arXiv版の本文・表を通して GPT-4V も Claude も一度も登場しないため、これらとの優劣を論じた記述は論文に基づくものではありません。論文が比較対象としているのはInternVL 2、IXC 2.5、DocOwl 1.5、TextMonkey、Idefics3、LongVAなどのオープンモデルです。

何ページまでの文書を処理できますか？

入力を弾く上限は設定されていませんが、config.json の max_position_embeddings が2048で1ページあたり324トークンを消費するため、7ページ目から学習時の想定文脈長を超えます。精度もページ数とともに落ち、MP-DocVQAは1ページ83.3、2から10ページ70.2、10ページ超42.5です。長い文書は前段でページを絞り込む設計にしてください。

商用利用はできますか？

GitHubリポジトリとHuggingFaceのモデルカードのいずれもApache-2.0です。ただしこれはmPLUGチームの配布物に対する条件で、初期値を引き継いだ上流モデルと各学習データセットのライセンスは別途確認が必要です。また2025年5月30日以降リポジトリの更新が止まっている点も、採用判断で考慮してください。

関連記事

• OCRとは？光学文字認識の仕組み・種類・精度と実装での組み込み方を解説
• 従来OCRの限界を超えるdots.mocrのマルチモーダル解析という新発想
• mistral-document-ai-2512の基本仕様と既存OCRモデルとの位置づけの差異
• 0.9BパラメータGLM-OCRが提唱する次世代基準を詳細に、これからのドキュメント処理がどう変わるか
• マルチモーダルRAGとは？図表・画像を検索する仕組みと実装方式の選び方