Kapa.ai が画像を RAG にインデックスする方法

Kapa.ai は、インデックス段階で画像をテキスト記述に変換することで、画像を RAG パイプラインに統合する戦略を実装しました。このアプローチにより、クエリごとに生画像をマルチモーダルモデルに送信する必要がなくなり、クエリ時のマルチモーダル処理と比較してクエリあたりのコストを 27%〜51% 削減し、統計的に回答品質も向上させます（p < 0.05）。

技術文書における画像の役割

技術文書の画像は一般的に、イラスト系と本体系の 2 つのカテゴリに分かれます。UI 要素のスクリーンショットなどのイラスト系画像は、既存のテキストを明確にし、指示を実行しやすくします。本体系画像は、配線図や仕様表のように、テキストの他に存在しない主要データを含んでいます。

Kapa.ai は、画像コンテキストを提供することで LLM が生成する回答が大幅に改善されることを確認しました。3 つの顧客プロジェクトと 2 つのモデルでのテストでは、LLM ジャッジはテキストのみのベースラインに対し、画像コンテキスト付きの回答を統計的に有意な差で好みました。

なぜクエリ時のマルチモーダル RAG はスケールで失敗するのか

クエリフェーズで画像を処理することは、以下の 3 つの主な制約により、高ボリュームの本番環境では構造的に非効率です。

経済的コスト: 生画像はトークン使用量を大幅に増加させます。Kapa.ai のテストでは、画像により GPT モデルでクエリあたりのコストが 27%、Claude モデルで 51% 増加しました。
コンテキストウィンドウの制限: 一般的なクエリは 10〜30 のチャンクを取得し、20〜30 枚の画像を参照することがあります。Claude の 30 MB、OpenAI の 50 MB のペイロード上限により、多数の画像はすぐに利用可能なコンテキストウィンドウを使い果たします。
検索精度の低下: CLIP スタイルのマルチモーダル埋め込みは、技術的なチャートや表に必要な細かなディテールを欠くことが多いです。さらに、短い技術的クエリは画像ベクトルと効果的にマッチさせるためのシグナルが不足しがちです。

インデックス時の記述戦略

これらの課題を解決するために、Kapa.ai は「イーガー処理」アプローチを採用しています。画像はインデックス時にビジョン言語モデル（VLM）で一度だけ記述され、そのキャプションはテキストチャンクとして保存されます。

クエリ時には、リトリーバーが該当するテキストキャプションを取得します。LLM はテキスト記述を参照し、元の画像 URL を引用しますが、生ピクセルを処理することはありません。本体系画像については、VLM がデータを文字起こし（例：評価表をテキストグリッドに変換）し、回答が実際の図表データに根拠付けられるようにします。

本番実装の詳細

画像フィルタリング

不要な画像に対するキャプション作成コストを回避するため、Kapa.ai は 2 段階のフィルタリングプロセスを採用しています。

ヒューリスティック: 未対応フォーマット、サイズが小さい、極端なアスペクト比などの基準で画像を除外します。
ゼロショット分類: マルチモーダル埋め込みに基づく分類器が明らかな「ジャンク」（ロゴ、アバター、バナー）を除去します。この分類器は明確な画像で 96.8% の精度を達成しますが、画像の目的が周囲のテキストに完全に依存する曖昧な画像では精度が 59.8% に低下します。

キャプション品質の最適化

キャプションの品質は、使用するモデルのサイズよりもコンテキストによって左右されます。Kapa.ai は、画像の直前と直後の段落を VLM に提供することで、キャプションの根拠付けが大幅に向上することを確認しました。さらに、より小型のモデル（例：GPT-4o mini）は、はるかに高価なモデルとほぼ区別がつかないキャプションを生成し、大規模インデックスにおいて最もコスト効果の高い選択肢であることが分かりました。

ストレージアーキテクチャ：別々 vs. インライン

Kapa.ai はキャプションの保存方法として 2 つを比較しました。

インライン: 文書内の画像 alt テキストを置き換える方式で、画像を含むすべてのチャンクにキャプションが含まれます。
別々: 各キャプションを独立したチャンクとして保存します。

別々のチャンクが優れていることが判明しました。インラインキャプションはそれが含まれるすべてのチャンクのサイズを膨らませ、画像が不要でもコストが増加します。別々のチャンクは、リトリーバーが関連性があると判断したときにのみコンテキストウィンドウに入ります。画像が多いあるプロジェクトでは、別々のチャンクはインラインキャプションに比べてクエリあたりのコスト増加が 6% で済んだのに対し、インラインキャプションは 19% 増加しました。

パフォーマンス結果

GPT-4o と Claude 3.5 Sonnet を使用した 3 つの顧客プロジェクトでの結果は以下の通りです。

指標	テキストのみベースライン	画像キャプションあり
回答で引用された画像	0%	10%〜64%
回答品質（LLM ジャッジ）	ベースライン	統計的に有意に優れた（p < 0.05）
クエリあたりコスト	ベースライン	+1%〜6%
レイテンシ（TTFT）	ベースライン	サブ秒の増加
モデルの不確実性	ベースライン	変わらないかやや低下
インデックスコスト	該当なし	一度きりのコスト

コミュニティの視点

この技術的アプローチはメディア取り込みの標準パターンとして広く認識されていますが、コミュニティのメンバーの中には潜在的なリスクと利点を指摘する声もありました。

"LLM の非決定的な性質により、新しいモデルはデータに関する新たな情報を明らかにします… これらのコンテキスト調整は、時には LLM の処理を再実行する必要があるかもしれません。"

他のユーザーは、このアーキテクチャはコスト効率が非常に高いものの、クエリがリアルタイムで画像を確認しなければ唯一回答できない場合は、事前生成された記述に依存せずに変更が必要になる可能性があると指摘しました。