Gemini Embedding 2：テキスト、画像、動画、音声を同じベクトル空間に入れる

Google Developers Blog が Gemini Embedding 2 の開発方法を紹介した。このモデルは Gemini API と Gemini Enterprise Agent Platform を通じて GA になっている。重要なのは、単なる新しい embedding モデルではなく、テキスト、画像、動画、音声、ドキュメントを同じ意味空間にマッピングできる点だ。

これにより、検索システムが扱える範囲は広がる。従来の多くの RAG パイプラインでは、画像、動画、音声を先にテキストやメタデータへ変換し、それぞれ別にインデックスする必要があった。Gemini Embedding 2 はマルチモーダル入力を直接処理できるため、エージェント、検索、分類システムが実際の業務資料を扱いやすくなる。

原文リンク：Building with Gemini Embedding 2: Agentic multimodal RAG and beyond

モデルの機能

Gemini Embedding 2 は 100 以上の言語をサポートする。1 回のリクエストで処理できる内容は次の通り。

最大 8,192 text tokens
最大 6 枚の画像
最大 120 秒の動画
最大 180 秒の音声
最大 6 ページの PDF

中心にある考え方は「統一された意味空間」だ。開発者は異なるモダリティの内容を同じベクトル表現に入れ、同じ検索、クラスタリング、再ランキングのロジックで処理できる。

たとえば、テキスト説明と画像を同じ embedding リクエストに入れられる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


from google import genai
from google.genai import types

client = genai.Client()

with open('dog.png', 'rb') as f:
    image_bytes = f.read()
result = client.models.embed_content(
    model='gemini-embedding-2',
    contents=[
        "An image of a dog",
        types.Part.from_bytes(
            data=image_bytes,
            mime_type='image/png',
        ),
    ]
)

print(result.embeddings)

入力ごとに個別の embedding が必要で、集約された 1 つのベクトルでは困る場合は Batch API を使える。原文では、この種のバッチ対応について Agent Platform 側はまだ対応中だとも説明している。

RAG にとっての意味

マルチモーダル embedding はエージェント型 RAG に向いている。AI agent は、コードリポジトリ、PDF、スクリーンショット、図表、音声会議録、商品画像を同時に確認する必要があるかもしれない。すべての資料を同じ意味空間に入れられれば、形式ごとに別々の検索入口を作る必要がなくなる。

Google は、タスクの目的に応じて task prefix を使うことを勧めている。これにより、embedding が検索目的に合いやすくなる。たとえば、質問応答、ファクトチェック、コード検索、検索結果には異なる prefix を使える。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Generate embedding for your task's query:
def prepare_query(query):
    return f"task: question answering | query: {content}"
    # return f"task: fact checking | query: {content}"
    # return f"task: code retrieval | query: {content}"
    # return f"task: search result | query: {content}"
# Generate embedding for document of an asymmetric retrieval task:
def prepare_document(content, title=None):
    if title is None:
        title = "none"
    return f"title: {title} | text: {content}"

この prefix は非対称検索に適している。ユーザーのクエリは短く、ドキュメントは長いことが多い。query と document をタスクに合わせて別々に整形すると、短い検索語と長い文書のマッチングを改善できる。

原文では 2 つの導入例が紹介されている。

Harvey は法律検索ベンチマークで、以前の embedding と比べて Recall@20 precision が 3% 向上した。
Supermemory は Recall@1 の検索精度が 40% 向上し、記憶、インデックス、検索、Q&A パイプラインに利用している。

これらの数字はすべての場面で同じ改善を保証するものではない。ただし、マルチモーダル embedding がデモだけでなく、実際の検索プロダクトで効果を出していることはわかる。

ビジュアル検索

Gemini Embedding 2 は、画像検索、画像とテキストを組み合わせた検索、商品識別にも使いやすい。原文では、URBN の衣料レンタル会社 Nuuly が、倉庫で撮影したタグ未付与の衣類写真をカタログと照合するために使っている例が紹介されている。この導入により、Match@20 は 60% から約 87% に向上し、全体の識別成功率は 74% から 90% 超に上がった。

この種の場面で重要なのは生成ではなく、「この画像はどの在庫、文書、商品レコードに最も近いか」を理解することだ。業務に大量の画像、動画クリップ、スキャン資料があるなら、マルチモーダル embedding はテキストだけのインデックスより自然に使える。

検索結果の再ランキング

Embedding は rerank にも使える。一般的には、まず基本検索で候補を取得し、その候補とユーザーのクエリとの類似度を計算して、より関連性の高い内容を上位に並べる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 1. Define a function to calculate the dot product (cosine similarity)
def dot_product(a: np.ndarray, b: np.ndarray):
  return (np.array(a) @ np.array(b).T)
# 2. Retrieve your embeddings
# (Assuming 'summaries' is your list of search results)
search_res = get_embeddings(summaries)
embedded_query = get_embeddings([query])

# 3. Calculate similarity scores
sim_value = dot_product(search_res, embedded_query)

# 4. Select the most relevant result
best_match_index = np.argmax(sim_value)

原文では別の考え方も紹介されている。まずモデルに内部知識から仮の基準回答を生成させ、その回答を embedding し、候補コンテンツとの類似度を比較して、意味的に最も近い結果を選ぶ方法だ。これは質問応答型 RAG で特に役立つ。

クラスタリング、分類、異常検知

検索以外にも、embedding はクラスタリング、分類、異常検知に使える。前述の質問応答検索とは異なり、これらは対称的なタスクなので、query と document に同じ task prefix を使える。

1
2
3
4
5


# Generate embedding for query & document of your task.
def prepare_query_and_document(content):
    # return f'task: clustering | query: {content}'
    # return f'task: sentence similarity | query: {content}'
    # return f'task: classification | query: {content}'

この種のタスクは、評判分析、コンテンツ審査、類似アセットの分類、異常サンプルの発見に使える。また、agent が大量のコンテキスト資料を先に整理してから、後続の推論に入る用途にも向いている。

保存とコスト

Gemini Embedding 2 はデフォルトで 3,072 次元のベクトルを出力する。Matryoshka Representation Learning を使っているため、output_dimensionality でより小さい次元に切り詰められる。Google は効率を優先する場合、1,536 または 768 次元を推奨している。

1
2
3
4
5


result = client.models.embed_content(
    model="gemini-embedding-2",
    contents="What is the meaning of life?",
    config={"output_dimensionality": 768}
)

ベクトルは Agent Platform Vector Search、Pinecone、Weaviate、Qdrant、ChromaDB などに保存できる。コスト面では、原文は Batch API がより高いスループットを提供し、デフォルト embedding 価格の 50% で利用できると説明している。

開発者はどう使うか

すでにテキスト RAG がある場合は、まず次の 2 種類の改善から始めるとよい。

PDF、スクリーンショット、画像説明、テキスト文書を同じインデックスに入れ、検索の再現率が安定するか確認する。
質問応答、ファクトチェック、コード検索、商品検索など、タスクごとに task prefix を付ける。すべての内容を同じ embedding 形式で処理しない。

新しいプロダクトを作るなら、次の方向を優先して検討できる。

企業ナレッジベース：文書、図表、プレゼン資料のスクリーンショット、会議資料をまとめて検索する。
ビジュアル検索：画像、テキスト、混合入力で商品、アセット、デザイン案、アーカイブを探す。
Agent ツールチェーン：coding agent、research agent、customer support agent が複数形式の業務資料を検索できるようにする。
コンテンツガバナンス：テキスト、画像、動画クリップを統一的に分類、クラスタリング、異常検知する。

Gemini Embedding 2 の価値は、マルチモーダル資料を同じ検索可能な資産に変えることにある。開発者にとっては、「先にテキストへ変換してから検索する」中間層を減らし、RAG システムを実世界のデータ形態に近づけられる。