必要なのは視覚だけ：視覚言語モデルを用いた知的文書検索システムの構築 (Vision RAG)

はじめに

Vision-is-all-you-needは革新的なビジュアルRAG（Retrieval Augmented Generation）システム実証プロジェクトであり、文書処理領域にビジュアル言語モデリング（VLM）を適用するという新境地を開くものである。従来のテキストチャンキング手法とは異なり、このシステムでは、視覚言語モデルを直接使用してPDFファイルのページ画像を処理し、ベクトル形式に変換して保存します。システムはColPaliをコア視覚言語モデルとして採用し、QDrantベクトルデータベースと共に効率的な検索を実現し、インテリジェントなQ&AのためにGPT4またはGPT4-miniモデルを統合します。このプロジェクトは、PDF文書のインポート、画像変換、ベクトル保存からインテリジェント検索までの全プロセスを完全に実現し、便利なAPIインターフェースとユーザーフレンドリーなフロントエンドインターフェースを提供し、文書インテリジェント処理の分野に全く新しいソリューションを提供します。

デモアドレス：https://softlandia-ltd-prod--vision-is-all-you-need-web.modal.run/

機能一覧

• PDFページ埋め込みPDFファイルのページを画像に変換し、視覚言語モデルを使ってベクトルとして埋め込みます。
• ベクター・データベース・ストレージ埋め込み画像ベクトルを格納するベクトルデータベースとしてQdrantを使用します。
• お問い合わせ検索埋め込み画像に類似したベクトルを検索し、応答を生成することができます。
• APIインターフェースファイルのアップロード、クエリ、検索操作を容易にするRESTful APIインタフェースを提供します。
• フロントエンド・インタラクションスルー 反応 フロントエンドのインターフェイスは、ユーザーフレンドリーな体験を提供するためにAPIと相互作用する。

ヘルプの使用

設置プロセス

1. Python 3.11以降のインストール::

   pip install modal
モーダルのセットアップ

2. 環境変数の設定を作成する。 環境 ファイルに以下を追加する：

   OPENAI_API_KEY=your_openai_api_key
HF_TOKEN=あなたの_huggingface_token

3. 実行例::

   モーダルサーブ main.py

使用例

1. PDFファイルのアップロードブラウザを開き、モーダル社から提供されたURLにアクセスし、URLに以下を追加する。 /ドキュメント. クリック POST /コレクション エンドポイントを選択します。 試してみる ボタンをクリックしてPDFファイルをアップロードし、実行します。
2. 類似ページのクエリー使用 POST /search エンドポイントで、ページ画像とクエリを OpenAI API に送信し、レスポンスを返します。

フロントエンド開発

1. Node.jsのインストール::

   cd frontend
npm install
npm run dev

2. フロントエンド環境の設定修正 .env.development ファイルにバックエンドのURLを追加します：

   VITE_BACKEND_URL=your_backend_url

3. フロントエンドの立ち上げ::

   npm run dev

詳しい操作手順

1. PDFページ埋め込み::
   • 利用する ピプドフィウム PDFページを画像に変換。
   • 画像を視覚言語モデル（ColPaliなど）に渡して埋め込みベクトルを得る。
   • 埋め込みベクトルをQdrantベクトルデータベースに格納する。
2. お問い合わせ検索::
   • ユーザはクエリを入力し、クエリ埋め込みベクトルは視覚言語モデルを通して得られる。
   • ベクトルデータベースから類似の埋め込みベクトルを検索します。
   • クエリとベストマッチの画像は、応答を生成するモデル（GPT4oなど）に渡される。
3. APIの使用::
   • PDFファイルのアップロード POST /コレクション エンドポイントはファイルをアップロードする。
   • 類似ページのクエリ: by POST /search エンドポイントはクエリーを送信し、レスポンスを取得する。
4. フロントエンド・インタラクション::
   • Reactフロントエンドインターフェースを使用して、APIと対話する。
   • ファイルアップロード、クエリ入力、結果表示機能を提供。

参考記事：RAGを作る？ チャンキングに飽きた？必要なのはビジョンだけかもしれない！

ほとんどの最新のジェネレーティブAI（GenAI）ソリューションの中核には、次のようなものがある。 ラグ RAG（Retrieval-AugmentedGeneration）の手法は、応用AIの分野のソフトウェアエンジニアによってしばしば「RAG」と呼ばれる。応用AIの分野のソフトウェアエンジニアは、しばしばこれを「RAG」と呼ぶ。RAGでは、言語モデルが組織の独自データに基づいて質問に答えることができる。

RAGの最初の文字Rは、Retrieve (回収)、検索プロセスを指す。ユーザーがGenAIロボットに質問をすると、バックグラウンドの検索エンジンは、幻覚のない完璧な回答を生成するために、質問に関連する資料を正確に検索する必要がある。AおよびGはそれぞれ、検索されたデータの言語モデルへの入力および最終的な回答の生成を指す。

本稿では、RAGアーキテクチャを実装する上で最も重要で、時間がかかり、困難な部分である検索プロセスに焦点を当てる。まず、検索の一般的な概念について説明し、次に従来のチャンクベースのRAG検索メカニズムについて紹介する。論文の後半では、検索と生成のために画像データに依存する新しいRAGアプローチに焦点を当てる。

情報検索の歴史

グーグルをはじめとする大手検索エンジン会社は、何十年もの間、情報検索の問題を解決しようとしてきた。情報検索はいまだに期待されるほど単純ではない。その理由のひとつは、人間の情報処理が機械とは異なることだ。自然言語を、多様なデータセットを横断する賢明な検索クエリに変換するのは容易ではない。グーグルの上級ユーザーは、検索エンジンを操作するためのありとあらゆるテクニックを熟知しているかもしれない。しかし、そのプロセスは依然として面倒であり、検索結果も満足のいくものではないことがある。

言語モデルの進歩により、情報検索は突然自然言語インターフェースを持つようになった。しかし、言語モデルは、学習データが学習時の世界のスナップショットを反映しているため、事実に基づいた情報を提供するには不十分である。さらに、知識はモデル内で圧縮され、よく知られている錯覚の問題は避けられない。結局のところ、言語モデルは検索エンジンではなく、推論マシンなのだ。

言語モデルの利点は、データサンプルと指示を与え、これらの入力に基づいて応答するよう求めることができることである。これは チャットGPT また、同様の会話型AIインターフェースの典型的な使用例もある。しかし、人は怠け者であり、同じ労力をかければ、自分でそのタスクをこなせるかもしれない。だからこそRAGが必要なのだ。応用AIソリューションに質問するだけで、正確な情報に基づいた答えを得ることができる。少なくとも、検索が完璧な世界では、それが理想的な状況だ。

従来のRAGでは、検索はどのように機能するのですか？

RAGの検索方法は、RAGの実装そのものと同じくらい多様である。検索は常に最適化の問題であり、すべてのシナリオに適用できる汎用的な解決策は存在しない。AIアーキテクチャは、検索であれ他の機能であれ、それぞれの特定の解決策に合わせて調整されなければならない。

とはいえ、典型的なベースライン・ソリューションは、いわゆるチャンキング手法である。この手法では、データベース（通常は文書）に格納された情報を、段落程度の小さなチャンクに分割する。そして各チャンクは、言語モデルに関連付けられた埋め込みモデルによって数値ベクトルに変換される。生成された数値ベクトルは、専用のベクトルデータベースに格納される。

単純なベクトルデータベース検索は以下のように実装されている：

1. ユーザーは質問をする。
2. 問題から埋め込みベクトルを生成する。
3. ベクトルデータベースのセマンティック検索を行う。
   1. セマンティック検索では、質問ベクトルとデータベース内のベクトルとの近さは、テキストブロックの文脈と意味を考慮して数学的に測定される。
4. ベクトル検索は、例えば、最も一致する10個のテキストブロックを返す。

検索されたテキストのブロックは、言語モデルの文脈（キュー）に挿入され、モデルは元の質問に対する答えを生成するよう求められる。検索後のこの2つのステップがRAGのAフェーズとGフェーズである。

チャンキング技術やインデックス作成前の前処理は、検索品質に大きな影響を与える。このような前処理は何十種類もあり、検索後に情報を整理したり、フィルタリング（並び替えと呼ばれる）することもできる。ベクトル検索に加えて、従来のキーワード検索や、構造化された情報を検索するためのその他のプログラミング・インターフェースを使用することもできる。例えば、ユーザーの質問に基づいて新しいSQLやAPIクエリを生成するためのtext-to-SQLやtext-to-API技術などがある。非構造化データに対しては、チャンキングとベクトル検索が最も一般的に使用される検索技術である。

チャンキングに問題がないわけではない。異なるファイル形式やデータ形式を扱うのは面倒だし、形式ごとに別々のチャンキングコードを書かなければならない。既製のソフトウェア・ライブラリもありますが、完璧ではありません。さらに、チャンクのサイズや重複する領域も考慮しなければなりません。さらに、画像、図表、その他のデータでは、視覚情報とその周囲の文脈（見出し、フォントサイズ、その他の微妙な視覚的手がかりなど）を理解することが非常に重要です。そして、これらの手がかりは、チャンキング・テクニックでは完全に失われてしまう。

もし、このチャンキングが全く不要で、検索が人間が文書のページ全体を閲覧するようなものだとしたらどうだろう？

画像は視覚情報を保持する

高度なマルチモーダルモデルの開発により、画像ベースの検索方法が可能になった。画像データに基づく模範的なAIソリューションは、テスラの自動運転ソリューションで、完全にカメラに依存している。このアプローチの背景にある考え方は、人間は主に視覚を通じて周囲の状況を認識するというものだ。

同じコンセプトがRAGの実装にも当てはまる。チャンキングとは異なり、ページ全体が画像として、つまり人間が見るのと同じフォーマットで直接インデックス化される。例えば、PDF文書の各ページは画像として専用のAIモデルに送り込まれる（例えば コルパリ)、このモデルは、ビジュアルコンテンツとテキストに基づいてベクトル表現を作成する。これらのベクトルは、ベクトルデータベースに追加される。この新しいRAGアーキテクチャを ビジュアル検索 エンハンスド・ジェネレーション(Vision Retrieval-Augmented Generation：V-RAG）。

このアプローチの利点は、マルチモーダルモデルがテキストとビジュアルの両方の要素を考慮したベクトル表現を生成するため、従来の方法よりも検索精度が高くなることであろう。検索結果は文書のページ全体となり、それが画像としてGPT-4のような強力なマルチモーダルモデルに送り込まれる。このモデルは、図表の情報を直接参照することができます。

V-RAGは、まず複雑な構造（図や表など）をテキストに抽出し、次にそのテキストを新しいフォーマットに再構築し、ベクトルデータベースに格納し、検索し、首尾一貫したヒントを形成するために並べ替え、最終的に答えを生成する必要性を排除します。これは、古いマニュアルや表の多い文書、内容が単なるテキスト以上の人間中心の文書形式を扱う場合に大きな利点となる。また、インデックス作成は、従来のレイアウト検出やOCR処理よりもはるかに高速です。

コルパリ紙のインデックス速度統計

とはいえ、文書からテキストを抽出することは依然として価値があり、画像検索と並んで支援を提供することができる。しかし、チャンキングは近い将来、AI検索システムを実装する方法として利用可能な多くの選択肢のひとつとなるだろう。

Vision-RAGの実践：Paligemma、ColPali、ベクターデータベース

従来のテキストベースのRAGとは異なり、V-RAGの実装には特殊なモデルとGPU計算へのアクセスが依然として必要である。V-RAGの最適な実装は、この目的のために特別に開発されたモデルを使用することである。 コルパリ.

ColPaliは、ColBERTモデルによって導入されたマルチベクトル検索アプローチと、GoogleのマルチモーダルPaligemma言語モデルに基づいています。ColPaliはマルチモーダル検索モデルであり、テキストコンテンツだけでなく、ドキュメントのビジュアル要素も理解します。実際、ColPaliの開発者は、ColBERTのテキストベースの検索アプローチを拡張し、Paligemmaを利用してビジュアル領域をカバーした。

埋め込みを作成する際、ColPaliは各画像を32×32のグリッドに分割し、各画像は約1024個のチャンクを持ち、各チャンクは128次元ベクトルで表現されます。各画像には "describe image "コマンドトークンも付加されるため、チャンクの総数は1030となる。

検索処理においてチャンクとクエリ部分を比較するために、ユーザのテキストベースのクエリは同じ埋め込み空間に変換される。検索処理自体は、いわゆるMaxSim法の この記事 で詳しく説明されている。この検索方法は、マルチベクトル検索をサポートする多くのベクトルデータベースに実装されている。

必要なのはビジョンだけ - V-RAGのデモとコード

私たちはV-RAGのデモを作成し、そのコードはSoftlandiaのGitHubリポジトリで公開されている！ ビジョンこそすべて で検索してください。応用AIの他のデモも、私たちのアカウントでご覧いただけます！

ColPaliを実行するには、大量のメモリを搭載したGPUが必要なので、GPUを使用できるクラウドプラットフォーム上で実行するのが最も簡単な方法です。そのため、GPUのサーバーレス利用をシンプルかつ手頃な価格で実現できる、優れたModalプラットフォームを選びました。

ほとんどのオンライン・アカデミックJupyter Notebookプレゼンテーションとは異なり、Jupyter Notebookのプレゼンテーションでは、Jupyter Notebookの基本的な使い方を説明します。 必要なのはビジョンだけ デモでは、ユニークなハンズオンを体験できます。リポジトリをクローンして自分でデプロイし、クラウドGPU上でフルパイプラインを数分で無料で実行できます。このエンド・ツー・エンドのアプリケーションAIエンジニアリングの例は、他のほとんどのデモにはない実体験を提供することで、際立っています。

そのデモでは クドラント Qdrant のインメモリバージョンです。Qdrantはバージョン1.10.0からマルチベクトル検索をサポートしています。Qdrantはバージョン1.10.0からマルチベクトル検索をサポートしています。デモはPDFファイルのみをサポートしており、pypdfium2ライブラリを使用してページを画像に変換しています。また、ColPaliモデルを実行するために、ColPali開発者が作成したtransformersライブラリとcolpali-engineを使用しています。その他、opencv-python-headless（ちなみにこれは私の作品です）などのライブラリも使用しています。

このデモは、インデックスを作成し、質問をするためのHTTPインターフェースを提供する。その上に、Reactを使ってシンプルなユーザーインターフェースを構築しました。UIはまた、それぞれの トークン コルパリモデルが重要視している部分を簡単に見ることができる。

Vision is All You Needデモのスクリーンショット

ビジョンが本当に必要なのか？

デモのタイトルとは裏腹に、ColPaliのような検索モデルは、特に多言語データに対してはまだ十分とは言えない。このようなモデルは通常、限られた数の例で学習され、ほとんどの場合、特定のタイプのPDFファイルです。その結果、このデモはPDFファイルしかサポートしていません。

もう一つの問題は、画像データとそこから計算される埋め込みデータのサイズである。これらのデータはかなりのスペースを占め、大規模なデータセットでの検索は、従来の一次元ベクトル検索よりもはるかに多くの計算能力を消費する。この問題は、埋め込みをより小さな形式（バイナリまで）に定量化することで部分的に解決できる。しかし、これは情報の損失と検索精度の若干の低下につながる。我々のデモでは、最適化は重要ではないため、定量化はまだ実装されていない。さらに、以下の点に注意することが重要である。 Qdrantはまだバイナリベクトルを直接サポートしていません。しかし、それは可能だ。 Qdrantで定量化を可能にするQdrantは内部でベクトルを最適化します。しかし、ハミング距離に基づくMaxSimはまだサポートされていません。

このため、最終的なページ検索にColPaliを使用する前に、従来のキーワードベースの検索と合わせて最初のフィルタリングを行うことが推奨される。

マルチモーダル検索モデルは、従来のテキスト埋め込みを生成する埋め込みモデルと同様に、進化し続けるだろう。OpenAIや同様の組織が、検索精度を次のレベルに引き上げるColPaliのようなエンベッディング・モデルを近いうちに発表することは間違いない。しかしこれは、チャンキングや伝統的なベクトル検索手法で構築された現在のシステムを根底から覆すことになるだろう。

柔軟なAIアーキテクチャーなしでは遅れをとる

AI分野では、言語モデルや検索手法などのイノベーションが加速度的に発表されている。これらのイノベーションそのものよりも重要なのは、それらを素早く取り入れる能力であり、競合他社よりも早い企業には大きな競争優位性がもたらされる。

そのため、検索機能を含むソフトウェアのAIアーキテクチャは、最新の技術革新に迅速に対応できる柔軟性と拡張性を備えていなければなりません。開発が加速する中、システムのコア・アーキテクチャが単一のソリューションに限定されることなく、従来のテキスト検索、マルチモーダル画像検索、あるいはまったく新しい検索モデルなど、多様な検索方法をサポートすることが重要です。

ColPaliは将来の氷山の一角に過ぎません。将来のRAGソリューションは、複数のデータソースと検索テクノロジーを組み合わせることになり、アジャイルでカスタマイズ可能なアーキテクチャのみが、それらのシームレスな統合を可能にする。

この問題を解決するために、私たちは以下のサービスを提供しています：

• 既存のAIアーキテクチャの状態を評価する
  • 技術リーダーや開発者とともに、コードレベルの詳細を含むAI技術を深く掘り下げる。
  • 検索方法、スケーラビリティ、アーキテクチャの柔軟性、セキュリティ、（生成）AIがベストプラクティスに従って使用されているかどうかを検証する。
  • 改善点を提案し、開発のための具体的な次のステップを挙げる。
• チームの一員としてAI機能またはAIプラットフォームを導入する
  • 専属のアプリケーションAIエンジニアが、お客様のAIプロジェクトが他の開発タスクに遅れをとらないようサポートします。
• 外注製品開発チームとしてAI製品を開発する
  • 私たちは、最初から最後まで、完全なAIベースのソリューションを提供します。

私たちは、AIの導入を加速し、そのシームレスな統合を確実にすることで、お客様が大きな競争優位性を獲得できるよう支援します。もっと詳しくお知りになりたい方は、御社がAI開発の最前線に立ち続けるために当社がどのようなお手伝いができるか、ぜひご相談ください。