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

RAGのための画像インデックス作成方法

概要

  • Kapa は技術ドキュメントの画像を効率的に活用するAIアシスタントを開発
  • 画像を インデックス時 にテキスト化し、クエリ時はテキストのみで処理
  • この方式で コスト増加は最小限、回答品質は大幅向上
  • 画像の種類・役割 と処理フローの最適化が鍵
  • 本記事は実際の運用ノウハウと検証結果を解説

技術ドキュメントにおける画像の役割と分類

  • 技術ドキュメントの画像は 「説明補助型」と「本質情報型」 に大別
    • 説明補助型 :テキスト内容を視覚的に補強するスクリーンショットやUI案内図
    • 本質情報型 :配線図、スペック表、認証マトリクスなど画像自体が唯一の情報源となるケース
  • 画像があることで 回答の具体性・即応性 が飛躍的に向上
    • 例:「設定アイコンをクリック」+そのアイコンのスクリーンショット
  • LLM評価 でも画像を活用した回答が統計的に有意な品質向上(McNemar’s test, p < 0.05)

クエリ時マルチモーダル処理の課題

  • 画像を クエリ時に都度処理 する従来型手法の問題点
    • コスト増大 :GPTで27%、Claudeで51%のコスト増
    • ペイロード制限 :画像数が多いとAPI上限(Claude 30MB, OpenAI 50MB)にすぐ到達
    • 検索精度低下 :CLIP等の画像ベクトルは細部情報を失いがち
  • これらは 現状のエコシステムの構造的制約 であり、単なる技術的なチューニングでは解決不可

インデックス時に画像をテキスト化するアプローチ

  • 画像はインデックス時のみ ビジョンモデルで説明文(キャプション)生成
    • キャプションはテキストチャンクとして保存し、通常のテキストと同様に検索・取得
    • クエリ時は 画像そのものは参照せず、キャプションのみを利用
    • 画像URLも同時に記録し、必要なら参照可能
  • 説明補助型 には内容説明、 本質情報型 には表・図の値やラベルを転記
  • Microsoftの研究チーム も同様の手法を採用

運用上の要点

  • フィルタリング :ノイズ画像(ロゴ、アイコン、バナー等)はヒューリスティクスとゼロショット分類器で除去
    • 明確な画像には96.8%の精度、曖昧なケースは59.8%(文脈依存のため完全判別は困難)
  • キャプション生成 :周囲テキストを入力することで品質向上
    • モデルサイズは小型(GPT 5.4 mini)でも十分、超小型(nano)は品質低下
  • 保存方法 :キャプションは 独立チャンク で保存が最適
    • インライン保存は全チャンク肥大化でコスト増、独立保存なら必要時のみ取得
    • 画像重視のプロジェクトでインラインは19%コスト増、独立は6%増(Claudeでは逆にコスト減)

実験結果と効果

  • 3つの顧客プロジェクト(GPT 5.1 & Claude 4.6 Sonnet)で検証
    • 画像キャプション導入で回答品質が有意に向上
    • 画像引用率:10%~64%、誤配置率:1%~6%
    • コスト増加は1%~6%、レイテンシー増加はごく僅か
    • モデルの不確実性は変化なし、もしくは僅かに減少
    • インデックスコストは一度きり、以降の画像処理コストは発生しない

まとめ:最適な画像活用アーキテクチャ

  • インデックス時に 一度だけ画像をテキスト化 する方式が最も合理的
    • クエリごとに画像処理を繰り返す必要がなく、 経済的かつ高品質
  • 画像が「補助」でも「本質」でも、 一度読めば十分
  • 制約は「克服すべき障害」ではなく、 最適な設計指針
  • 本方式は現在プレビュー展開中

Hackerたちの意見

クエリ時にモデルに画像を送信することはないんだ。各画像を一度だけ、インデックス作成時に安価なビジョンモデルで説明して、その説明をテキストとして保存して、普通のテキストチャンクと一緒に取得するんだ。これが、私がObsidianの情報ダンプでやってることなんだ。もし画像が重要だとわかっていれば、テキストの説明を生成して(可能ならMermaid、無理なら英語で)、画像の後にブロックとして貼り付ける。これで、エージェントが画像を実際に見えなくても、見ることができるんだ。私のプロセスは手動だけど、テキスト検索や取得に依存するエージェントの結果が改善されるのは本当に実感できるし、やる価値があるよ。

マーメイドテキストの画像説明って何?最初からチャートや図の説明なの?

クライアントのためのRAGプロジェクトで、PDFやパワーポイントに画像がたくさんあったから、1年前にColPaliを使ったんだ。提供者のColiVaraはまだオンラインだけど、なんか勢いがなくなってるみたい。テキストに基づいて取得して、生成モデルに画像を渡す方が、画像に基づいて取得するよりずっと賢いよ。画像ベースの取得は遅いし高いからね。モデルに画像を渡すのと、構造化された表現を渡すのも同じことだね。

メディアの取り込みでは、これを「イager」処理って呼ぶんだ。歴史的には、画像や動画のサムネイルを引っ張ったり、一般的なサイズを事前に生成したりするために使われてきた。このパターンに従っていて、すごく理にかなってるよ。私の唯一の懸念は、LLMの非決定的な性質のせいで、新しいモデルがデータに関する新しい情報を明らかにする可能性があること。例えば、画像の中の車を特定できても、その文脈が赤信号を無視して走っている車だったりすることがある。新しいモデルはそれを拾うかもしれないけど、古いモデルはそうじゃないかも。こうした文脈の調整は、時にはLLM処理を再実行する必要があったり、複数回の実行のために一対多の関係を持つ必要があるかもしれないから、最良の結果を得たり、結果を組み合わせたりできるようにする必要があるね。実際の使用では、最もよく使われるアセットが明らかになって、トラフィックが多いものをターゲットにして、処理コストを大幅に削減できるよ。

画像をvlmで前処理するのは昔からの一般的なやり方だったよね。

デジタルフォレンジックソフトウェアで働いてた頃を思い出すなぁ… もちろん、規模は小さかったけど、アイデアは似たような感じだった。できるだけ多くの生データを抽出して、いろんな処理のスレッドやパイプラインを通して処理して、最後に分類してレポートを作るっていう。今回は、トレーニングのために全部まとめるって感じかな。人間のレビューも入るんじゃないかな?価値のあるモデルを作りたいなら、人間に物事を説明させた方がいいと思う。出力が格段に良くなるっていうのが私の理解。トレーニングでパターンは見つけられるけど、説明するための言葉をちょっとでも詳しくできれば、違いが出るよね。

それは賢いね。ついこの前、RAGシステムで画像やグラフ、リッチPDFの問題をどう解決するか考えてたんだ。これで少し理解が深まった、ありがとう!

助けになってよかった!

誰かがデプロイしたい場合に備えて、オープンソースのフレームワークに入ってるよ:https://github.com/Qbix/AI/blob/6753f6e453908682401f49760002... https://github.com/Qbix/AI/blob/main/config/observations.jso... 数ヶ月前にここに書いたよ:https://community.safebots.ai/t/building-cultural-infrastruc...

なんでマルチモーダル埋め込みモデルじゃないの?

記事では、なぜマルチモーダル取得を使わないのかが言及されてるよ。それに、このアプローチはマルチモーダル取得よりも安価(計算的に)だと思う。記事からの引用:「マルチモーダル取得はこのドメインには合わない。CLIPスタイルの埋め込みは、チャートや表、注釈付きスクリーンショットで重要な細部を消してしまうし、短い技術的なクエリ(『Xをどう設定するの?』)は画像ベクトルと照合するには信号が少なすぎる。」

記事では、これが重要な詳細を見落としていると言ってる。例えば、画像の中にあるかもしれないデータとか。

これが他の人にも知られているかはわからないけど、私はこれを2年前からやってて、本当にうまくいってるよ。ただ、画像を含むドキュメントをチャンクに分ける必要があって、そのために著者たち(複数)にキャプションを更新してもらう必要があったのが大変だった。マルチモーダルよりもコスト効率がいいし、全体的に取り込み時間も少ない。ただ、もし取得クエリが画像を見ないと答えられない質問だったら、このアーキテクチャにはちょっとした修正が必要になるかも。

そのキャプションはどれくらい詳細なの?色や形とかも含まれてるの?

これは彼らの製品の広告だね。このアプローチに特別なことはないし、他の誰もが同じようにやってると思う。

マジで? - マーケティング資料?チェック - 極端に膨れ上がってる?チェック - 最後に「無料トライアルをゲット」?チェック - 完全にLLM生成?チェック

「これが耐荷重ケースを機能させるんだ」って、ああ、AIのライティングの癖が嫌いだな。ワークフローを共有しようとするその感覚はありがたいけど、AIに情報密度の高い説明をまとめさせるのはまだ難しいよね。長くて曖昧になっちゃうことが多いし。