ハクソク

世界を動かす技術を、日本語で。

解析に悩むな: RAGには画像を使おう

308日前原文(morphik.ai)

概要

  • Morphikは RAGツール を開発し、複雑なドキュメントの正確な検索を実現
  • 従来の OCRやパース手法 の限界を指摘し、画像としてページを扱う理由を解説
  • Vision Language Model による画像ベースの理解で情報損失を防止
  • ColPaliやMUVERAなど最新技術を活用し、圧倒的な 精度と高速化 を実現
  • 今後は マルチドキュメント推論 など、さらなる発展を目指す方針

複雑なドキュメント検索で画像ベースを選ぶ理由

  • Morphikは RAG（Retrieval-Augmented Generation）ツール で開発者向けに高精度な検索体験を提供
  • PDFや技術マニュアルなどの 複雑な資料 では、表や図、テキストの混在が一般的
  • 従来の OCRやレイアウト解析 では、重要な情報がしばしば失われる現実
  • 例：会計報告書の図表やIKEAマニュアルのような 非テキスト情報 の扱いに課題
  • パースパイプライン の複雑さとコスト、そして情報損失のリスク

従来手法の課題と限界

  • OCRでの 誤認識 （例：「1,000」が「l,0O0」になる等）による精度低下
  • レイアウト検出や チャンク分割 での構造崩壊
  • 表・図・キャプション等の 文脈や空間情報の喪失
  • テキストと画像を別々に扱う ハイブリッド手法 では、空間的な関係性が失われる問題
  • 解析パイプラインへの 信頼性の欠如

画像としてページを「見る」アプローチ

  • 人間がドキュメントを理解するように、 ページ全体を画像として処理
  • ColPaliなどの Vision Language Model で直接画像を理解
  • 解析・再構築不要、 一度の処理で全情報を保持
  • 図表、色、空間配置など、 視覚的手がかり も完全に活用
  • LLMが直接ページ全体を「見て」 位置情報や関係性 を維持

技術的仕組みとColPaliの特徴

  • 各ページを 高解像度画像 化し、グリッド状に分割（パッチ化）
  • Vision Transformer（SigLIP-So400m） でパッチごとに埋め込み生成
  • さらに PaliGemma-3B などの言語モデルで文書構造を理解
  • クエリ時は「late interaction」で テキスト・図・表・色分け など多様な要素を横断的に検索
  • 人間の専門家のような 総合的な理解力 を実現

実運用での課題と最適化

  • ColPali実装当初は 検索速度が遅い （3〜4秒/クエリ）
  • MUVERA論文の手法で マルチベクター検索を単一ベクター化 し、高速化
  • Turbopuffer など専用ベクターデータベースにより30msまで短縮
  • バイナリ量子化やハミング距離計算など 最適化手法 の導入

ベンチマーク評価と精度

  • TLDCと共同で 金融ドキュメント向けベンチマーク を構築（NVIDIA 10-Q, Palantir, JPMorgan等）
  • 他社のRAGシステムが 67%前後 の正答率、LangChain+OpenAIでも72%
  • Morphikは 95.56%の正答率 を実現
  • OpenAI File Searchは 13.33%、ViDoReベンチマークでもMorphikは 81.3% nDCG@5 で従来法を大きく上回る

ユースケースと導入メリット

  • 金融資料 ：表やグラフが核心情報の場合に強み
  • 技術マニュアル ：図解やレイアウトが重要な場面
  • 請求書・レシート ：構造や配置が意味を持つドキュメント
  • 研究論文・医療記録 ：図やレイアウトの文脈理解が必要なケース
  • APIは シンプル で、PDFや画像をアップロードし自然言語で検索可能

今後の展望：マルチドキュメント知能へ

  • 単一文書 を超え、複数資料間の 関係性や文脈理解 の実現を目指す
  • 例：財務報告書と取締役会資料の連携、契約書の改訂履歴の自動追跡
  • 複雑な推論やワークフロー統合 への拡張を計画
  • ユーザー自身が ベンチマーク評価 を試せるフレームワークも提供中
  • 今後も 視覚的文書理解 の進化と実用化を推進

Morphik のアプローチは、従来のOCR・パース依存の限界を打破し、 画像ベースのドキュメント理解 で現場の課題を根本から解決します。今後も、より深い文脈理解と高速な検索を両立し、業務現場の生産性向上を支援していきます。

Hackerたちの意見

6ヶ月前に、同僚たちと一緒にフランスの政府機関向けにこれを実装したんだ。オープンソースで、ここにあるよ: https://github.com/jolibrain/colette うちのメインのビジネスじゃないから、あんまり宣伝してないけど、なんとか動いてるし、ちょっと調整すればかなり効率的になるよ。本当にすごいのは、全体が完全に微分可能にできることで、ターゲットデータセットに対してファインチューニングできるようになるんだ。レイアウトモデルも、細かい文書理解のためにカスタマイズできるよ。

└

そうだね、ファインチューニングは確かに一番のポイントだよ。よくあるブロッカーは高品質な評価セットだよね（これがいつもブロッカーになる気がする）。

└

リポジトリのトップレベルにライセンスがないね。それだと、ライセンスを真剣に考えている人は、参考のためにも君のものを使えないよ。

そうそう、こっちの方面でかなり研究してるよ[1]（OCRと直接画像＋一般的なLLMのベンチマーク）。直接画像抽出の最大の問題は、複数ページの文書なんだ。単一ページの抽出（OCR=>LLM vs 画像=LLM）では、直接画像抽出が少し有利だった。でも、5ページを超えると、OCRを先に使った場合に比べて精度が急激に落ちるんだ。長文のコンテキストをテキストで思い出すのは難しい問題だから、LLMはそのために最適化されてるけど、画像に関してはまだまだ悪いね。[1] https://getomni.ai/blog/ocr-benchmark

└

それは面白いポイントだね。ほとんどのユースケースでは、5ページ以上のコンテキストはオーバーキルだってわかったよ。画像の上に小さなLLM変換レイヤーを置くのも、結構うまくいくんだ（つまり、直接OCRの代わりに、必要なら5枚の画像を小さなビジョンモデルに渡して、文書から重要なポイントを抽出させる感じ）。今は、LLMがより大きな画像バッチをうまく扱えるように、キャッシュやアテンションマップの調整を研究してるところ。スライディングウィンドウや無限リトリーバルが有望な方向かもしれないね。それと、これは推測だけど、今見てるマルチモーダル能力の向上は、これからも増えていくと思うから、モデルが改善されるにつれて、画像の長文コンテキストは大きな障害にはならないんじゃないかな。

誰か、マルチモーダルRAGがこの問題を解決しない理由を教えてくれない？[1] 何か見落としてるのかな？Flash 2.5やSonnet 3.7は、いつも満足のいく画像分析を提供してくれたんだけど。もしかしたら勘違いかもしれないけど、テキストを「ただの」テキストとして渡すより、画像として渡した方がいい反応をするモデルもある気がする。[1] https://www.youtube.com/watch?v=p7yRLIj9IyQ

└

マルチモーダルRAGはまさに私たちが主張していることだよ。ただ、元の状態では、マルチベクトル（マルチモーダルRAGの基盤となるもの）は非常に扱いにくいんだ。類似度スコアを計算するのはすごくコストがかかるから、この状態でスケールアップするのは難しい。量子化や単一ベクトル変換（固定次元エンコーディングを使用）や、より良いインデックスを適用する必要があるんだ。これでマルチモーダルRAGがスケールで機能するようにしてるんだよ。私たちMorphikがやってることそのものだね :)

これは悪いアイデアだって経験から言えるよ。文書に、同じように見える文字が多くのフォントに含まれている場合があるからね。例えば、0とOは多くのフォントで同じに見える。だから、doc/xls/PDF/htmlを画像に変換すると情報が失われるんだ。シリアルナンバーのような場合では、人間でも0とO（またはlとI）を見ただけでは区別できないからね。

└

これはOCRの代替として使う文脈の中での話で、同じ問題が出てくるけど、もっと手間がかかってコストもかかるよ。

└

PDFには実際のテキストが含まれているとは限らないよね。時々、文字を描くための指示だけが含まれていることもある。そのため、PDFページを画像としてレンダリングするのは情報を抽出するための非常に合理的な方法だと思う。他のフォーマットについては、文書をパースする方がいいと思う。

└

HTMLの場合、多くのケースでタグを使ってうまく分けるのが効果的だよね。でも、ページをデザインしてるときに、モデルに実際のページの画像を見せると、コードを送るよりもずっと良いデバッグができることが分かった。1とI、0とOの問題は確かにあるけど、実際には、図やチャートがたくさんある文書（画像として扱う方がずっと簡単）を見てきたから、選択バイアスがあるかもしれないね。

いくつかの基本的な問題があるから、みんな知っておくべきだよ。- LLMは通常、4kのテキストトークンで事前学習されて、そこから長いコンテキストウィンドウに拡張されるんだ（4000トークンから4001トークンにするのは簡単）。でも、画像の場合はトークン化の仕組みのせいでそれができない。だから、分布外になっちゃうんだよね。数枚の画像を扱うと、ハルシネーション（幻覚）が大きな問題になる。- 1536 × 2048のPDFは、生のテキストよりも3〜5倍多くのトークンを使う（つまり、推論コストが高くなって、応答も遅くなる）。解像度を下げると、画像がぼやけちゃうし。- 画像は生のサイズでも重い表現だから、必要な画像をダウンロードするだけで遅延が生じる。彼らの小さなベンチマークは、チャートやテーブルが多い金融文書の基本的なテキストチャンクよりも明らかに優れている。GeminiにOCRステップを追加して、（画像に注釈を付けられるから）結果を比較してみたいな。特許や建築図面など、特定のケースではエンドツーエンドの画像アプローチが意味を持つけど、最後の手段だね。

└

GeminiでOCRを追加できるけど、それは比較したOCRモデルよりも良い結果をもたらすだろうね。ただし、処理する文書の全体が大きなVLMを通ることを保証することになるから、それは非常に高コストで遅くなる可能性がある。ここには明らかにトレードオフがあって、私たちはほとんどのケースでこれが最も効果的だと感じたよ。

└

確かに、gemma3のような最新のモデルや、複数の解像度からのトレーニングなどのテクニックは、これらの問題を軽減してくれるよね。gemma3ファミリーの面白い特性は、入力画像のサイズを増やしても処理メモリの要求が増えないことなんだ。なぜなら、二段階のエンコーダーがそれを固定サイズのトークンに圧縮するから。実際にやってみると、すごく便利だよ。

└

それは理にかなってるけど、RAGパイプラインを揺るがす何かが必要なのかな？各RAGの結果を使って、ユーザーのクエリに直接関係する情報を画像から抽出するモデル処理ステップを一回ずつ行って、その結果を集約して最終生成の入力にするっていうのはどう？それなら、複数の画像のトークン制限を回避できるし、画像理解のステップを並行処理できるよ。

└

それが彼らの文書解析製品の役割だよ。人々は時々LLMに何かを渡すけど、確かにそれがうまくいくこともあるけど、仕事に対して間違ったツールかもしれないよ。すべてをLLMに通す必要はないからね。

└

伝統的なOCRとLLMを組み合わせて、間違いを修正したり図の表現を追加するのは良いと思う。LLMは読めないときに信じられるようなテキストを作り出す問題があるから、結果がただの混乱になるよりは悪いよね。例えば、GPT4.1は1296 × 179のスクリーンショットで君のコメントに完璧に対応したけど、50%にズームアウトして650 × 84のスクリーンショットを渡すと、結果はこうなる。「人々が認識すべき根本的な問題がいくつかある。- LLMは通常、テキストトークンで事前学習され、長いコンテキストウィンドウに外挿される（4000のテキストトークンから4001に行くのは簡単）。画像ではトークン化の方法からこれが不可能。結果として、分布外になり、複数の画像を扱うと幻覚が大きな問題になる。- 512x2048のPNGは生のテキストよりも3.5k多くのトークンを使う（つまり、推論コストが高く、応答が遅くなる）。解像度を下げるとぼやけた画像になる。- 画像は生のサイズでも本質的に重い表現で、必要な画像をダウンロードするためにすべてのリクエストに遅延を追加している。彼らの非常に小さなベンチマークは、チャートやテーブルが多いファイナンス文書の基本的なテキストチャンクよりも明らかに優れている。GeminiにOCRステップを追加して（画像に注釈を付けられる）、結果を比較するのがもっと興味深いと思う。特定のケース（特許や建築図面など）では、エンドツーエンドの画像アプローチが理にかなうけど、それは最後の手段だね。」ほとんど正確だけど、「1536 × 2048のPDFは3から5倍のトークンを使う」と言ってるのが「512x2048のPNGは3.5k多くのトークンを使う」に変わってるのに気づいてね。

└

コンテキストウィンドウの外挿は、Haarウェーブレットみたいな階層的・マルチスケールのトークン化された画像でも機能するはずだよ。

昨年、特許文書を分析するシステムにかなりの時間をかけたんだ。特許は抽象的な図や化学式、数学の方程式など、いろんなものが含まれるから、LLMが後で使えるようにデータを準備するのが本当に難しい。私が見つけた一番シンプルなアプローチは、文書の各ページを「写真に撮る」ことだった。そして、LLMに内容を説明するJSONを生成してもらう（ページ番号や視覚要素の数などのメタデータも含めて）。もし複雑な画像があれば、モデルにそれを説明させればいい。そうすれば、選んだベクターストアに埋め込めるJSONファイルができる。コストパフォーマンスについては言えないけど、このアプローチは著者が提案しているものよりも簡単で効率的に見えるね。

└

でも、モデルが画像をハルシネートすることはどのくらいあるの？

└

これはLLMの使い方の素晴らしい例だね、ありがとう。でも、今のLLMの機会は主に特許文書のような既存の価値を再分類したり再処理したりすることに関するものだと感じる。90年代から00年代にかけて、多くの成功したソフトウェアビジネスが伝統的なファイリングを置き換えるためのデータベースを構築していた。新しい価値のコレクションを作るには前払いの投資が必要だけど、まだ経済には挑戦があるみたい。

└

モデルに画像を説明させることはできるけど、それは本質的に情報が失われるよね。もしそれがチャートで、モデルがほとんどのx、yのペアを取得したとして、ユーザーが欠けている「x」や「y」の値について尋ねたらどうなる？推論時に画像を提示するのは効果的だよ。そうすれば、LLMがユーザーの質問に正確に答えられることが保証されるから。ここでの唯一の障害は、リトリーバルの精度で、それは解決すべき小さな問題だね。このアプローチでは、関連するコンテキストを渡すことだけを解決すればいいから、残りはLLMが処理してくれる。そうしないと、問題の範囲がOCRの修正やパース、モデルから画像に対するすべての可能な説明を取得することに広がっちゃう。

文書をテキストや構造化フォーマットに変換する必要があるかもしれない。これは、情報を構造化データベースやデータレイクに同期させるために重要だよね。その場合、OCRは機能するけど（ちょっとした癖があるけど）、私の経験では、元の文書をLLMに渡す方が良いと思う。LLMの解析が従来のOCRと比べてどれくらい良いか評価した人はいるのかな？私の持っているのは、LLMの方がいいという逸話的な証拠だけなんだ。でも、試してみると、いつも許容できないレベルの幻覚があった。

スケジュールをGeminiにコピーして質問しようとしてたんだけど、コピー＆ペーストに数分も苦労したんだ。HTMLにしてあったのに、うまくいかなかった。結局諦めて、スクリーンショットを撮って、Geminiに無視してほしい部分（関係ない情報）に黒いボックスをかぶせて、その画像をペーストしたら、すごくうまくいったよ。

テキストはフラットになってるの？そうじゃないなら、PDFをOCRにかける必要はないよ。テキストは抽出できるからね。ウェブブラウザのJavaScriptを使ってもできるし。手書きのテキストやフラットなテキストにだけOCRが必要なんだ。Googleの文書解析も役立つよ。最初にPDFに対してもっと安いツールを使うこともできるし。すべてをLLMに送るのはコストが高いからね。巨大なPDFはどうするの？時々コンテキストウィンドウに収まらなかったり、すごく高くついたりするよ。LLMは素晴らしいけど、仕事に合ったツールを使うのが大事だね。

└

一般的に言いたいのは、フラットでない場合でも、テキストベースのアプローチではうまくいかない複雑な図がドキュメントに現れるってこと。RAGの文脈では、モデルに情報を送るのが目的だから、LLMがその仕事にぴったりなんだよね。

RAGにPDFを重視するのって、90年代の感じがするよね。うちの会社みたいに、ドキュメントをバンバン作らないところでもRAGを使うための良いフレームワークってあるのかな？結局、ドキュメントやメール、プレゼンが一番一般的な使い方をカバーするし。でも、うちにはRAGが聞かれるであろう質問が全部入ったデータベースがあって、ドキュメントにあるよりもずっと多くの回答があるんだよね。

└

それはPDFが難しいからなんだよね。小さなテキストから始めると、RAGはずっと楽になるよ。