今回の論文
今回取り上げるのは、Manuel Faysse、Hugues Sibille、Tony Wu、Bilel Omrani、Gautier Viaud、Celine Hudelot、Pierre Colombo による論文「ColPali: Efficient Document Retrieval with Vision Language Models」です。初出は 2024 年 6 月の arXiv で、その後 ICLR 2025 採択版として公開されています。研究分野は文書検索、マルチモーダル検索、RAG 基盤です。URL は https://doi.org/10.48550/arXiv.2407.01449 です。
この論文を選んだ理由は、RAG や社内文書検索で面倒になりがちな OCR、レイアウト解析、チャンク設計、図表キャプション生成といった前処理をかなり短絡できるからです。PDF を画像としてそのまま検索対象にする発想は大胆ですが、実験では精度も高く、実務上の設計ヒントが多い技術です。
どんな技術か
ColPali は、PDF やスキャン文書の各ページをテキストへ変換してから検索するのではなく、ページ画像を Vision Language Model で直接ベクトル化し、検索クエリと照合する技術です。
普通の文書検索では、まず PDF をパースしてテキストを抽出し、表や図を別処理し、段落単位にチャンク化してから埋め込みを作ります。しかし実際の文書には、表の罫線、図の配置、見出し構造、太字、フォント差、ページレイアウトなど、テキストだけでは落ちる情報が多く含まれます。
ColPali はここを逆転させます。文書ページを画像として入力し、画像パッチごとの埋め込みを持つマルチベクトル表現を作り、クエリ側のトークンと後段で照合します。一言でいえば、OCR に寄りすぎた RAG から、ページそのものを理解して検索する RAG へ寄せる技術です。
課題
この技術が解決しようとしているのは、視覚的に豊かな文書を、無理にテキストだけへ潰して検索しようとすると起きる情報損失です。
何が難しいのかというと、業務文書や論文、報告書、マニュアルでは、内容が文字列だけで成立していないからです。表の行と列の対応、図中のラベル、左右カラムの関係、注釈の位置、見出しの階層、ページ内の視覚的まとまりなどが意味に効きます。OCR で文字列を抜き出しても、こうした構造は崩れやすいです。
既存の方法では、PDF パーサ、OCR、レイアウト検出、チャンク分割、必要に応じた図表キャプション生成を組み合わせます。うまく作れば強いですが、構成が長くなりやすく、どこかの前処理が崩れると検索全体が弱くなります。特に図、表、インフォグラフィック、スキャン文書では、その限界が目立ちます。
なぜこの課題を解く必要があるのかというと、RAG の失敗原因は生成モデルより前段の検索にあることが多いからです。欲しい情報を含むページが存在していても、OCR が崩れたり、表が壊れたり、図の意味が文字列化されなかったりすると、検索候補に上がりません。
実際の AI システムでは、社内規程検索、契約書検索、研究論文検索、財務報告検索、製造マニュアル検索などで問題になります。特に PDF が多く、構造化されていない現場では、前処理パイプラインの複雑さそのものが運用コストになります。
用語解説
- Vision Language Model
- 画像とテキストを同じモデル系で扱うモデルです。ColPali では文書ページ画像と検索クエリを同じ意味空間へ寄せる土台になっており、単なる OCR では拾いにくい視覚要素を検索に使えるのが重要です。
- Late Interaction
- 文書を 1 本のベクトルへ潰さず、複数ベクトルのまま保持し、検索時にクエリ各トークンと文書側の各ベクトルを細かく照合する方式です。ColPali の精度向上の中心で、図表や局所パッチとの部分一致を拾いやすくします。
- マルチベクトル検索
- 1 文書につき 1 ベクトルではなく、トークンや画像パッチごとの複数ベクトルで文書を表す検索手法です。ColPali はページ全体を画像パッチ列として表現するため、この考え方を理解しておくと仕組みを追いやすくなります。
- OCR
- 画像や PDF から文字を抽出する技術です。従来の文書検索は OCR に強く依存しますが、ColPali は OCR を検索の主役から外し、ページ画像自体を直接検索対象にします。
- nDCG@5
- 検索上位 5 件の順位品質を測る指標です。正解ページが上位にあり、しかも順位が高いほど値が上がります。この論文では ViDoRe ベンチマークの主指標として使われ、ColPali が既存方式よりどれだけ良い順位でページを返せるかを示しています。
技術の仕組み
ColPali の基本アイデアは、文書ページを画像として理解する Vision Language Model と、ColBERT 系の late interaction 検索を組み合わせることです。これにより、ページ全体を 1 本の埋め込みに潰すのではなく、ページ内の細かい視覚要素を残したまま検索できます。
基本アイデア
通常の埋め込み検索では、文書側もクエリ側もそれぞれ 1 ベクトル、もしくは少数ベクトルへ圧縮します。この方式は速い一方で、「表のこの列」「図中のこのラベル」「ページ右下の注記」のような局所的な対応を持ちにくいです。
ColPali では、クエリはトークン列のまま、文書は画像パッチ列のままベクトル化し、検索時にクエリトークンごとに最も近いページパッチを探してスコア化します。論文では、この late interaction のスコアを「各クエリベクトルに対して、文書側で最も似ているベクトルとの内積を取り、その総和を取る」と定義しています。
つまり、「この質問語はページのどこに対応するか」をあとから探す設計です。文書全体を先に要約しないので、細粒度の一致を残しやすいです。
モデル構造
論文の ColPali は PaliGemma-3B をベースにしています。PaliGemma は、画像エンコーダで得たパッチ表現を言語モデル側へ流し込み、画像とテキストを同じ系列として扱える Vision Language Model です。
著者らはこの出力に対して、ColBERT 系で使う低次元の検索空間へ写す射影層を追加しています。これで、画像パッチとクエリトークンの両方を検索用の共通埋め込み空間へ入れられるようにしています。
重要なのは、SigLIP のような画像エンコーダ単体ではなく、PaliGemma の言語モデル側を通した「文脈化された画像パッチ表現」を使っている点です。論文でも、単純な bi-encoder 化より、late interaction を足した ColPali が大きく伸びています。
学習方法
学習はクエリと正解ページの組を使う対照学習です。バッチ内の他ページを負例として扱い、正解ページのスコアが他より高くなるように学習します。late interaction 自体が微分可能なので、そのまま end-to-end で最適化できます。
訓練データには既存の公開データセットに加えて、Web 収集した PDF ページに対し Vision Language Model で疑似質問を作った合成データも使っています。英語中心の学習ですが、論文ではフランス語データへのゼロショット一般化も検証しています。
また、クエリ側には ColBERT 系に近い特殊トークン拡張を入れています。これは微分可能なクエリ拡張のように振る舞い、検索時にどの情報を強く見るかを学習しやすくする工夫です。
推論方法
オフラインでは、各 PDF ページを画像化して ColPali でエンコードし、ページごとのマルチベクトル埋め込みを保存します。オンラインでは、ユーザーの検索クエリをテキストとしてエンコードし、各クエリトークンとページパッチ群の類似度を計算してランキングします。
ここで重要なのは、ページ画像を直接入れるので、OCR、レイアウト抽出、タイトル単位チャンク化、図表キャプション生成を必須にしなくてよいことです。検索基盤として見ると、前処理を減らして検索器の表現力で取りに行く構成です。
データの扱い方
ColPali はページ単位検索を前提にしています。つまり、論文やマニュアルの全文を一度に扱うのではなく、まずページを検索単位としてインデックスします。この設計は実務でも扱いやすく、ヒットしたページの周辺ページだけ後続処理へ流す構成が作りやすいです。
一方で、ページ単位である以上、長い文書の中で段落レベルのピンポイント抽出をしたい場合は、後段に追加の領域抽出や reranking を組み合わせる余地があります。ここは論文の直接提案ではなく、実運用に向けた拡張ポイントです。
重要な工夫
実務上いちばん重要なのは、「検索精度を上げるために前処理を増やす」のではなく、「検索モデルがページの視覚情報を直接使えるようにする」という方向転換です。
論文では、Unstructured を使った一般的な PDF 取り込み、OCR 付きパイプライン、図表へ追加 OCR をかける方式、さらに Claude 3 Sonnet で図表キャプションを作る方式まで比較しています。そのうえで ColPali は、前処理の簡潔さと精度の両方で強い位置を取っています。
実験と結果
論文では、ColPali が本当に既存の文書検索パイプラインより強いのか、視覚要素が多い文書でどれだけ差が出るのか、速度や保存サイズではどんなトレードオフがあるのかを検証しています。
何を検証したのか
検証の中心は 3 つです。1 つ目は、テキスト中心の既存検索より高い検索順位を出せるかです。2 つ目は、図、表、インフォグラフィックのような視覚的に複雑な文書で効くかです。3 つ目は、実運用で重要なインデックス作成速度や保存コストがどうなるかです。
データセットと評価指標
評価には著者らが作成した ViDoRe ベンチマークを使っています。Academic Tasks として DocVQA、InfoVQA、TAT-DQA、arXivQA、TabFQuAD があり、Practical Tasks として Energy、Government、Healthcare、AI、Shift Project が含まれます。英語中心ですが、フランス語タスクも含まれています。
主指標は nDCG@5 です。これは、正解ページを上位 5 件のどこに返せるかを見る指標で、RAG の一次検索品質を見るのに相性がよいです。補助的に Recall@1 なども付録で示されています。
精度はどれだけ改善したか
論文の Table 2 では、ViDoRe 全体平均の nDCG@5 が ColPali (+Late Inter.) で 81.3 でした。比較として、強い既存ベースラインの Unstructured + Captioning + BGE-M3 は 67.0、BiPali (+LLM) は 58.8、BiSigLIP (+fine-tuning) は 58.6 です。つまり、PaliGemma を単純な bi-encoder として使うだけでは足りず、late interaction が効いていることが分かります。
個別タスクでも差は大きいです。たとえば、図や図表理解が重要な arXivQA では ColPali が 79.1、BiSigLIP は 58.5 でした。インフォグラフィック中心の InfoVQA では ColPali が 81.8、BiSigLIP は 70.5 です。フランス語の表中心タスク TabFQuAD では ColPali が 83.9、BiPali が 76.9、BiSigLIP が 62.7 でした。
さらに practical tasks でも強く、AI タスクで 96.2、Government で 92.7、Healthcare で 94.4 を出しています。視覚的に複雑な文書だけでなく、比較的テキスト寄りの業務文書でも高い検索性能を示した点が重要です。
結果から何が言えるのか
まず言えるのは、文書検索では埋め込みモデル単体より前処理設計がボトルネックになりやすいということです。論文でも、BGE-M3 と BM25 の差より、図表をどう扱うかの差のほうが大きい場面が多いと述べています。
そのうえで ColPali は、「前処理を複雑化してテキスト検索へ寄せる」より、「画像のまま検索する」ほうが強いケースが多いことを示しました。これは RAG 開発にとってかなり示唆的です。
レイテンシと保存コスト
論文では、クエリのエンコード時間は BGE-M3 で約 22ms、ColPali で約 30ms とされています。オンライン検索時の追加オーバーヘッドは小さく、late interaction でも小規模から中規模のコーパスでは十分現実的です。
一方で、保存サイズは軽くありません。DocVQA で比較すると、BGE-M3 の埋め込みサイズが 8.60KB、BM25 の dense 表現が 3.00KB に対し、ColPali は float16 保存で 256KB です。したがって、精度と前処理簡素化の対価として、マルチベクトル由来のストレージ負担は増えます。
ただし論文は、OCR やキャプション生成を含む従来の PDF インデックス作成より、ColPali のほうがインデックス処理を単純化しやすいと述べています。ここは、前処理コストと保存コストのどちらを重く見るかで評価が変わります。
何に使える？
ColPali は、単なる論文向けベンチマーク技術ではなく、PDF や画像化文書を扱う検索基盤の作り方そのものを変えうる技術です。
PDF 中心の社内検索
規程、監査報告書、提案書、仕様書、見積書などが PDF で散らばっている組織では、OCR 品質やレイアウト崩れが検索失敗の原因になります。ColPali を使うと、まずページ単位で広く拾い、その後に必要な箇所だけ OCR や LLM 抽出へ回す構成が作れます。前処理を全部高品質に作り込まなくても、検索入口を強くしやすいです。
図表が多い RAG
財務資料、製造レポート、研究論文、医療レポートでは、図や表が本文以上に重要なことがあります。従来のテキスト RAG では、図表の意味が落ちやすいですが、ColPali は図表の視覚構造をページ画像として保持したまま検索できます。図表付き文書 QA の前段としてかなり相性がよいです。
スキャン文書や低品質 PDF の検索
紙の契約書、手書き注記入り資料、古いスキャン PDF では、テキスト抽出の時点で品質が不安定です。ColPali がこれを完全に解決するとは限りませんが、少なくとも検索器の入口を OCR 一本に依存させない設計にできます。OCR を後段の補助へ下げられるのは大きいです。
マルチモーダル RAG の一次検索
ページ単位で候補を絞ったあとに、そのページだけ高精度 OCR、領域抽出、VLM QA、構造化抽出をかける多段パイプラインに向いています。つまり、ColPali は最終回答器ではなく、マルチモーダル RAG の一次検索エンジンとして使うと特に活きます。
文書 UI と組み合わせた探索
クエリトークンとページパッチの対応を使えば、「なぜこのページがヒットしたか」を視覚的に示す UI も作れます。論文でも類似度マップの例が示されており、実装すれば検索結果の説明可能性やレビュー体験の改善につながりそうです。これは論文の直接検証というより応用上の推測ですが、かなり自然な延長です。
開発や事業へのヒント
この論文から得られるヒントは、文書 AI の勝負どころが「LLM に何を答えさせるか」だけでなく、「どの単位で、どんな表現を検索対象にするか」にあるということです。
OCR パイプラインを前提にしすぎない
文書 AI を作ると、最初に OCR とチャンク分割を前提に設計しがちです。しかし ColPali は、その前提自体を崩してもよいと示しています。もし PDF の質が悪い、図表が多い、文書レイアウトが重要という条件なら、最初から画像検索ベースで組むほうが全体最適になる可能性があります。
検索と抽出を分離する
全文書に高精度 OCR や構造化抽出をかけるのは重いです。ColPali でまず候補ページを絞り込み、上位数ページにだけ高価な抽出をかける構成なら、小規模プロダクトでも実装しやすいです。これは推論コストを後段へ寄せる設計として実務的です。
SaaS の差別化ポイントになる
文書検索 SaaS や社内ナレッジ基盤では、検索できるかどうかの差が大きな価値になります。特に請求書、申請書、報告書、研究資料のようにフォーマットが多様な領域では、OCR 品質より「ページ全体を見て候補を返せるか」が効く場面があります。ColPali 系はそこを差別化要素にしやすいです。
小規模でも試せる導入順序がある
いきなり全文書を置き換えなくても、図表が多いコーパスだけ ColPali にする、あるいは既存 BM25/BGE とハイブリッド検索にするなど、段階導入が可能です。最初は特定部門の PDF 群だけで AB テストし、ヒット率や問い合わせ解決率を見る進め方が現実的です。
今後注目すべき方向性
今後は、ページ単位検索の次に、ページ内領域まで返す検索や、検索と領域抽出を一体化した retrieval が重要になるはずです。ColPali はその手前の基盤として非常に強いですが、実務では「どのページか」だけでなく「ページ内のどこか」まで返したくなるからです。これは論文の直接範囲を少し超える推測ですが、技術の延長として妥当です。
限界
ColPali には明確な限界もあります。まず、マルチベクトル検索なので保存サイズが大きくなります。論文でも 1 ページあたりの埋め込みサイズは BGE-M3 よりかなり重く、数百万ページ規模ではストレージ設計が重要です。
次に、ページ単位検索なので、段落単位やセル単位の精密抽出にはそのままでは向きません。実運用では reranker、領域抽出、OCR、後段 VLM などの補助が必要になることが多いはずです。
また、クエリはテキストですが、文書は画像パッチ列です。このため、ANN の設計や late interaction の高速化が必要になり、通常の 1 ベクトル検索より実装難度は上がります。論文でも最適化エンジンを使えば大規模化できると述べていますが、導入のしやすさはベクトル 1 本の検索より低いです。
さらに、画像ベースである以上、画質や解像度、ページレンダリングの仕方に依存する可能性があります。非常に低品質なスキャンや極端に細かい表は、依然として難しいかもしれません。ここは論文で完全には検証し切れていない点です。
最後に、学習データは英語中心です。フランス語へのゼロショット性能は良かったものの、日本語文書で同じ傾向がそのまま出るかは追加検証が必要です。多言語実運用では、日本語 PDF での再評価を前提に見るべきです。
よくある質問
Q. ColPali は OCR を完全に不要にする技術ですか？
A. 完全に不要にするというより、検索の一次段を OCR 依存から外しやすくする技術です。最終回答生成や引用抽出では OCR や領域抽出が依然として役立つので、実務では「検索は画像、抽出は必要に応じてテキスト化」という分担が現実的です。
Q. 普通のベクトル検索より何が強いのですか？
A. 1 ベクトルに潰す検索では失われやすい局所対応を、late interaction で保持できる点です。クエリ語ごとにページ内の最も関連するパッチを見るので、図表、見出し、注記のような細かい一致を拾いやすくなります。
Q. RAG に入れるならどこに置くのがよいですか？
A. いちばん自然なのは一次検索です。まず ColPali で関連ページを数件取り、そのページだけに高精度 OCR、抜粋抽出、LLM 要約をかける構成が相性よいです。いきなり回答生成を全部 ColPali に担わせるより、検索器として使うほうが導入しやすいです。
Q. 小規模プロダクトでも使えますか？
A. 使えますが、保存サイズと実装複雑性は考慮が必要です。全文書へ一斉導入するより、図表が多い重要コーパスに限定して使う、既存検索とのハイブリッドにする、といった始め方が現実的です。
Q. 日本語の PDF にもそのまま効きますか？
A. 効く可能性はありますが、論文の学習は英語中心なので断定はできません。PaliGemma 系の多言語性やレイアウト理解は期待できますが、日本語文書では検索語の粒度、縦書き、フォント、表組みの違いがあるため、実データでの評価が必要です。
今日の学び
この論文は、PDF や図表入り文書を OCR とチャンク分割中心で検索すると、視覚情報が落ちて検索精度も運用性も下がりやすいという課題を扱いました。これに対して、ページ画像を Vision Language Model で直接マルチベクトル化し、late interaction でクエリと照合する ColPali を提案しました。
ここから得られるヒントは、文書 AI では前処理を積み上げるだけが正解ではなく、検索対象の表現そのものを変える余地が大きいということです。特に PDF 中心の RAG や社内検索では、OCR を完璧にしようとする前に、画像のまま拾う設計を検討する価値があります。