サイトアイコン IT & ライフハックブログ|学びと実践のためのアイデア集

GeminiとLangChainで始めるマルチモーダルRAG:仕組みと構築手順、設計の注意点

blue and white miniature toy robot

Photo by Kindel Media on Pexels.com

GeminiとLangChainを組み合わせると、テキストだけでなくPDF内の図や画像を含む資料から、質問に関係する根拠を探して回答する仕組みを組み立てられます。

ただし、Geminiに画像を渡すだけではRAGにならず、どの資料を検索し、どの根拠を回答に使ったかを追える設計が必要です。

この記事で分かること

RAGとマルチモーダルRAGの違い

RAG(検索拡張生成)は、質問に関係する情報を外部の文書やデータベースから検索し、その情報を大規模言語モデルへ渡して回答を組み立てる手法です。

モデルが学習時に得た知識だけに頼らず、社内資料や製品マニュアルなど、対象を限定した情報を回答の根拠にできます。

検索と回答生成の役割は同じではありません。

検索部分は関連する資料を探し、生成部分は取得した資料に基づいて読みやすい回答を作ります。

両者の違いは、関連記事のベクトル検索と生成AI検索の使い分けでも整理しています。

マルチモーダルRAGは、検索や回答に使う情報を文章だけに限定せず、画像、図表、PDFなどへ広げた構成です。

たとえば、製品マニュアルの文章に加えて部品図も参照できれば、部品名だけでは探しにくい質問にも根拠を提示しやすくなります。

一方で、RAGは正しさを自動的に保証する仕組みではありません。

検索対象の資料が古い場合や、質問に合う箇所を取得できなかった場合は、回答も不正確になる可能性があります。

回答ができるまでの流れ

工程 役割 確認すること
取り込み PDF、画像、テキストを読み込む 対象範囲、更新日、閲覧権限
前処理 文章の分割、画像の説明、メタデータ付与を行う ページ番号や資料名を失っていないか
索引化 検索しやすい表現へ変換して保存する 検索単位が細かすぎないか、大きすぎないか
検索 質問に関係する文章や画像を取得する 根拠として十分な資料が選ばれたか
生成 取得した根拠に沿ってGeminiが回答を作る 資料にない内容を断定していないか
提示 回答と参照元を利用者へ示す 出典を確認できるか、情報不足を伝えられるか

GeminiとLangChainが担う役割

Geminiは複数形式の情報を読み取る

Geminiは、文章と画像などを同じ要求の中で扱えるマルチモーダル対応のモデルです。

画像を質問と一緒に渡し、写っている内容の説明や、画像に関する質問への回答を求められます。

対応する入力形式や制限はモデルごとに変わるため、実装時はGemini APIの画像理解に関する公式資料で確認します。

LangChainは検索と生成の流れを接続する

LangChainは、文書の読み込み、分割、検索、モデル呼び出しなど、RAGを構成する処理をつなぐためのフレームワークです。

検索方法や保存先を部品として分けられるため、試作後にベクトルストアや検索条件を変更する場合も、処理の境界を保ちやすくなります。

現在の構成要素と基本的な流れは、LangChainの検索に関する公式資料で確認できます。

モデル名、パッケージ名、呼び出し方法は更新されるため、古いサンプルの固有名をそのまま使わず、Gemini連携の公式資料に合わせて選びます。

画像を検索対象にする二つの設計例

画像の内容を文章にして検索する

一つ目は、OCRで読み取った文字や画像の説明文を、元画像の場所を示す情報と一緒に保存する方法です。

文章と同じ検索基盤へ載せやすい反面、変換時に図の位置関係や細かな文字を取りこぼすことがあります。

検索後に元画像をGeminiへ渡す

二つ目は、資料名、ページ、見出しなどで候補を絞り、該当する元画像を質問と一緒にGeminiへ渡す方法です。

画像そのものを確認できる反面、ファイルの大きさ、処理時間、権限管理を含めて設計する必要があります。

どちらか一方に固定する必要はなく、文章検索で候補を絞ってから必要な画像だけを渡す構成も考えられます。

マルチモーダルRAGの構築手順

1. 回答する範囲を決める

最初に、誰のどの質問へ答えるのか、どの資料を根拠として認めるのか、情報が見つからないときにどう返すのかを決めます。

「社内のすべての質問に答える」のような広い目標では評価できないため、製品マニュアルの操作案内など、資料と質問の範囲が対応する単位から始めます。

2. データと閲覧権限を整理する

PDF、画像、テキストファイルを集め、重複、古い版、公開範囲を確認します。

部署や利用者によって閲覧権限が異なる場合は、検索結果にも同じ制限を適用しなければなりません。

3. 文書を読み込み、検索単位へ分ける

LangChainの文書ローダーなどを使って内容を読み込み、見出しや段落を手掛かりに検索しやすい単位へ分割します。

チャンクとは、この分割後の情報単位です。

チャンクには資料名、ページ番号、更新日、画像の参照先などを付け、回答から元資料へ戻れるようにします。

4. エンベディングを作り、検索先へ保存する

エンベディングは、文章の意味的な近さを比較しやすい数値の並びへ変換したものです。

作成したエンベディングとメタデータを、ChromaやVertex AI Vector Searchなどのベクトルストアへ保存します。

保存先は試作のしやすさだけでなく、データ量、権限、更新方法、監視方法を踏まえて選びます。

5. 検索結果をGeminiへ渡す

利用者の質問から関連するチャンクを検索し、必要に応じて元画像と一緒にGeminiへ渡します。

回答には取得した情報だけを使うこと、根拠が不足する場合は不足を明示すること、参照元を示すことを指示します。

6. 実際の質問で評価する

回答文だけを見ず、正しい資料を取得したか、回答が資料の内容に沿っているか、参照元を開けるかを分けて確認します。

RAGと周辺機能を組み合わせても誤回答が自動的に消えるわけではなく、原因別の対策はRAGでハルシネーションを抑える設計でも解説しています。

精度を下げる原因と対処の方向

症状 確認する原因 対処の方向
関係のない回答になる 質問と異なるチャンクを取得している 分割方法、検索語、メタデータの条件を見直す
図表の説明が欠ける 画像の文字や位置関係が前処理で失われている 元画像を参照できる形で残し、必要な画像を再入力する
古い手順を答える 旧版と最新版を区別できていない 版、更新日、有効期間をメタデータに持たせる
資料にない内容を断定する 根拠不足時の応答規則がない 回答不能の条件と参照元の表示を定める
閲覧できない資料が出る 検索索引へ権限が反映されていない 取り込み時と検索時の両方でアクセス範囲を確認する

用途別に変わる設計上の注意

教育資料の検索

教材の文章と図を対応付けておけば、学習者は質問に関係するページを見つけやすくなります。

ただし、回答だけで学習や評価を完結させず、参照した教材へ戻れる導線を用意します。

カスタマーサポート

製品マニュアル、FAQ、画像付き手順書を検索対象にすると、問い合わせ内容に合う説明を探す作業を支援できます。

資料にない不具合や判断が必要な問い合わせは、担当者へ引き継ぐ条件を決めておきます。

医療など慎重な判断が必要な領域

診療記録や画像には機微な情報が含まれるため、利用目的、閲覧権限、保存先、記録方法を先に定める必要があります。

検索結果は専門家が資料を確認するための補助として扱い、診断や治療の判断をシステムだけに委ねる使い方は避けます。

マルチモーダルRAGのアクセシビリティ

画像を扱えることと、利用者が情報へアクセスできることは別の課題です。

生成した説明文だけに頼らず、元資料の代替テキストや周辺の説明も整え、利用者が根拠を確認できるようにします。

設計と運用の確認点は、Webアクセシビリティの実務ポイントも参考になります。

小さく検証するためのチェックリスト

この確認を通じて検索、生成、画面表示を別々に直せる状態にすると、不具合の原因を特定しやすくなります。

GeminiとLangChainでRAGを構築する判断軸

マルチモーダルRAGの価値は、扱えるデータ形式の多さだけでは決まりません。

信頼できる資料を整え、質問に合う根拠を検索し、回答と参照元を分かりやすく示せることが、実用性を左右します。

Geminiは文章や画像の処理を担い、LangChainは取り込み、検索、生成の流れを接続します。

まず対象業務を絞って評価し、検索精度、権限、更新、アクセシビリティを確認しながら範囲を広げる進め方が適しています。

参考にした公式資料

マルチモーダルRAGを業務で生かすには、資料整理、検索精度の評価、運用ルールを一体で設計する必要があります。株式会社greedenは、生成AIを用いた施策を、課題整理から業務フロー改善、システム実装、定着まで支援します。

モバイルバージョンを終了