ハクソク

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

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

2025年7月22日原文(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ステップを追加して、（画像に注釈を付けられるから）結果を比較してみたいな。特許や建築図面など、特定のケースではエンドツーエンドの画像アプローチが意味を持つけど、最後の手段だね。

Hacker Newsで議論の続きを見る