EmbeddingGemma 2で変わる社内RAG｜画像・音声・動画の検索設計

EmbeddingGemma 2でできることと提供状況

埋め込みとは、内容の特徴を数値の並びに変換する処理です。EmbeddingGemma 2はテキスト、コード、画像、動画、音声を共通のベクトル空間へ変換します。たとえば文章で質問し、関連する画像や音声を探す仕組みに利用できます。回答文を作る生成モデルとは役割が異なり、RAGでは主に参照情報を探す部分を担います。

公式発表では全体が7億4,000万パラメータで、テキストのみなら2億7,000万パラメータの構成を選べます。モデルの重みはApache 2.0で公開されています。一方、Gemini Enterprise Agent Platform Model Gardenへの提供は、発表時点では近日予定です。

Google AI Edgeの同日付記事には、動画の該当場面をタイムスタンプで示す検索例が掲載されています。以下は、こうした機能を社内資料へ応用するときの設計提案です。当社の導入事例や、実機で確認した性能を示すものではありません。

まず「答えがどこにあるか」で検索対象を決める

すべてのファイルを一度に取り込む前に、利用者が探したい内容を整理します。想定例として、保守担当者が「警告灯が点滅したときの復旧手順」を調べる場面を考えます。答えが手順書の本文にあるのか、配線図にあるのか、動画内の実演にあるのかで必要な入力が変わります。

文章だけで答えが見つかる資料は、まずテキスト検索の対象にします。図の位置関係や実演の動きが答えに関係する資料から、画像・動画の検索を追加する方法を勧めます。録音についても、発言内容を探すのか、機械音など音そのものを探すのかを分けると、文字起こしとの役割を決めやすくなります。

• 本文に答えがある：見出しや段落を含めたテキストを候補にする。
• 図や画面に答えがある：ページや画像を、資料名・説明文と結び付ける。
• 時間の流れに答えがある：動画や音声を区間に分け、開始・終了位置を持たせる。

検索単位を、読者が確認できる大きさにする

ファイル全体が見つかっても、数百ページのどこを読めばよいか分からなければ、確認作業は残ります。検索単位は保存形式だけで決めず、根拠として提示したときに意味が通じる大きさを目指します。手順書なら見出しと手順、図なら凡例や注記、動画なら一つの操作が完結する区間が候補です。

想定例の復旧動画では、「ボタンを押す瞬間」だけを切り出すと、その前に必要な準備が抜ける可能性があります。まず操作のまとまりで区切り、該当区間の前後も開けるようにします。逆に長すぎる区間なら、利用者が目的の場面へ到達できるかを見ながら分割します。

公式モデルカードの入力枠は8,192トークンで、各形式がこの枠を共有します。ただし、入力できる最大量が最適な検索単位とは限りません。長い資料や録音は分割し、どの範囲から作ったベクトルなのかを管理する設計が必要です。

ベクトルと一緒に、ページ・時刻・版を保存する

ベクトルは似た内容を探すための表現であり、それだけでは引用元の位置を説明できません。検索結果に資料名だけを添えるのではなく、該当ページや再生位置まで戻れる情報を持たせます。検索対象を作る段階から、原本との対応を残すことを勧めます。

PDFでは、紙面に印字されたページ番号とビューアのページ数がずれることがあります。両方を区別して保存すると、回答に「12ページ」と書いても別の箇所が開く、といった混乱を減らせます。動画は開始時刻と終了時刻を保持し、回答から該当区間へ移動できるようにします。

また、関連する映像が見つかったことと、その映像が回答内容を裏付けることは別です。回答生成の段階でも実際の参照内容を確かめられる構成にし、確認できない内容を引用付きの断定に変えないようにします。

• 資料の識別：文書ID、資料名、保存先URL、版や更新日。
• 検索単位の識別：区間ID、対象ページ、画像の位置、開始・終了時刻。
• 回答への受け渡し：関連する本文やメディアの参照先と、引用表示に使う位置情報。

日本語資料では、正解の場所までたどれるかを見る

公式モデルカードは100以上の言語への対応を説明する一方、言語ごとの性能が同じとは限らないとしています。日本語の社内略語、型番、図中の小さな文字を含む資料については、自社の質問と資料で判断する必要があります。

検討時は、担当者が答えの場所を知っている質問を用意し、正解となるページや動画区間を先に記録します。既存のテキスト検索や文字起こしを使う方法と、マルチモーダル検索を加えた方法で、見つかる根拠がどう変わるかを比較する設計にします。これは検証の進め方の提案であり、本記事で比較実験を行った結果ではありません。

• 見つかるか：必要なページや区間が検索結果の上位に含まれるか。
• 取り違えないか：似た型番、旧版の手順、別製品の画像が混ざらないか。
• 確認できるか：引用先を開いた担当者が、回答の根拠をその場で判断できるか。

必要な入力と検索品質から構成を選ぶ

公式開発ガイドでは、不要な画像・音声の処理部分を読み込まない構成を案内しています。まず対象資料に必要な構成を選びます。また、検索用テキストにはクエリと文書で異なるタスクプロンプトを使います。

出力ベクトルは768次元から512・256・128次元へ短縮できますが、公式モデルカードは128次元でマルチモーダル品質が低下する点を説明しています。短縮する場合は同じEmbeddingGemma 2のモデル版を使い、クエリと文書の次元を揃え、再正規化も行います。保存量だけで決めず、必要な根拠を落とさないかを確認して選びましょう。

最初の対象は、文章検索で困っている資料群と具体的な質問に絞ると判断しやすくなります。担当者が見つけられなかった根拠へたどれるかを起点に、検索単位と引用の戻り先を整えていきます。