Embedding on KnightLiブログ

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

Mon, 04 May 2026 06:01:10 +0800

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 リクエストに入れられる。

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 を使える。

# 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. 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 を使える。

# 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 次元を推奨している。

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 システムを実世界のデータ形態に近づけられる。

代表的な埋め込みモデルはどう選ぶべきか: OpenAI・BGE・E5・GTE・Jina の比較

Thu, 23 Apr 2026 15:23:47 +0800

RAG、セマンティック検索、ナレッジベース検索を始めると、多くの人が最初に同じ疑問にぶつかります。埋め込みモデルはたくさんあるけれど、結局どれを選べばいいのか、ということです。

代表的なモデルは大きく二つに分けられます。一つは中国語・英語・多言語タスクを広くカバーする汎用テキスト埋め込みです。もう一つは中国語向けの用途により適していて、中国語検索、中国語 QA、中国語ナレッジベースでの性能を重視したものです。

まず短い結論だけ言うなら、次のように考えると分かりやすいです。

手間を減らして API をそのまま使いたいなら: text-embedding-3-small または text-embedding-3-large
中国語検索をやりたくて、かつオープンソースを自前で運用したいなら: bge-base-zh-v1.5、bge-m3、gte-large-zh
多言語にも対応したいなら: multilingual-e5-base、multilingual-e5-large、jina-embeddings-v3
中国語用途でコストを抑えたいなら: bge-small-zh-v1.5、gte-base-zh

1. まずは種類ごとに見る

1. OpenAI 系

text-embedding-3-small
text-embedding-3-large

この系統の特徴は、呼び出しが簡単で安定していることです。API を直接使って検索、RAG、分類、類似度マッチングを行うのに向いています。強みは「特定の中国語ベンチマークで飛び抜けて高得点」という点ではなく、全体としての使いやすさにあります。導入ハードルが低く、品質が安定していて、エンジニアリングコストも低いです。

チームとしてモデルを自前でホストしたくない、推論サービスの運用もしたくないなら、OpenAI 系はたいてい最も時間を節約しやすい選択です。

2. BGE 系

BAAI/bge-small-zh-v1.5
BAAI/bge-base-zh-v1.5
bge-m3

BGE は中国語検索で非常によく見かける系統です。bge-small-zh-v1.5 と bge-base-zh-v1.5 は中国語単一言語タスク寄りで、中国語セマンティック検索、ナレッジベース検索、FAQ マッチングに向いています。bge-m3 はより汎用的で、多言語、多粒度、より複雑な検索シナリオもカバーできます。

データの大半が中国語テキストなら、BGE は候補に入れやすいモデル群です。

3. E5 系

intfloat/multilingual-e5-base
multilingual-e5-large

E5 系の特徴は、多言語性能のバランスがよいことです。中国語と英語が混在する環境、クロスリンガル検索、国際向けコンテンツ基盤に向いています。中国語だけを見るモデルではなく、「異なる言語を一つの検索基盤にまとめる」ことを重視した設計です。

コーパスが中国語だけでなく、英語、日本語、あるいはさらに多くの言語を含むなら、中国語専用モデルより E5 の方が安定しやすいです。

4. GTE 系

Alibaba-NLP/gte-base-zh
gte-large-zh

GTE も中国語タスクでよく使われます。位置づけは BGE に近く、どちらも中国語検索の実用派です。比較的バランスが良く、導入のハードルも高くありません。中国語ナレッジベース、サイト内検索、社内ドキュメント検索に向いています。

中国語オープンソースモデルを複数比較したいなら、GTE は一緒に評価する価値があります。

5. Jina Embeddings

jina-embeddings-v3

Jina はより汎用的で、現代的な実装シナリオに寄った選択肢です。多言語検索、長文、Web コンテンツ処理などでよく使われます。「一つのモデルでより多くのタスク形態をカバーしたい」という文脈でよく名前が挙がり、embedding 層を統一したいチームに向いています。

Web ページ、文書、多言語テキストなど、データソースが混在しているなら、Jina は試す価値のある候補です。

2. 中国語シナリオでよく使われるモデル

対象を中国語シナリオに絞ると、代表的な候補はほぼ次の通りです。

bge-small-zh-v1.5
bge-base-zh-v1.5
bge-m3
gte-base-zh
gte-large-zh
multilingual-e5-base
multilingual-e5-large

ここで大事なのは、「どれが絶対に一番強いか」ではなく、次の三つです。

データの中心は中国語か
多言語対応が必要か
品質、コスト、導入しやすさのどれを優先するか

3. これらのモデルを並べて考える

1. 中国語性能だけを見る場合

中国語ナレッジベース、中国語 QA、中国語文書検索であれば、まず BGE と GTE を見るのが一般的です。

bge-small-zh-v1.5: 軽量で、コスト重視の場面に向く
bge-base-zh-v1.5: 中国語用途でバランスが良い定番
gte-base-zh: 軽量 BGE に近く、まずベースラインを作るのに向く
gte-large-zh: 検索品質をより重視する場面に向く
bge-m3: 中国語検索に加えて、より複雑な要件も視野に入れたいときに向く

コーパスがほぼ中国語だけなら、E5 も使えますが、最優先になることは多くありません。

2. 多言語が必要な場合

この場合は優先順位がかなり変わります。

multilingual-e5-base と multilingual-e5-large は多言語を統一的に検索するのに向いています
jina-embeddings-v3 も多言語と汎用テキスト処理に向いています
bge-m3 は従来の中国語専用モデルより、多言語へ拡張しやすいです
text-embedding-3-small と text-embedding-3-large は API ベースで素早く進めたい場合に向いています

中国語、英語、製品ドキュメント、Web コピー、ユーザー問い合わせが同じ基盤に入るなら、多言語モデルの方が後からの改修コストをかなり減らせます。

3. 推論コストと保存コストを抑えたい場合

ここでは軽量モデルが有利です。

bge-small-zh-v1.5
gte-base-zh
multilingual-e5-base
text-embedding-3-small

これらは次のようなケースに向いています。

文書量が多い
更新頻度が高い
大量のベクトル化が必要
レイテンシとコストに敏感

データ規模が大きい場合、embedding の次元数、推論速度、インデックスサイズは総コストに直結します。そのため、まず小さいモデルでベースラインを作るのは堅実なやり方です。

4. まず性能上限を優先したい場合

より大きいモデルは、複雑な検索や高品質な再現率を求める場面に向いています。たとえば次のようなモデルです。

text-embedding-3-large
multilingual-e5-large
gte-large-zh
bge-base-zh-v1.5
bge-m3

ただし、モデルが大きいほど本番体験が必ず良くなるわけではありません。多くのプロジェクトでは、本当のボトルネックはモデルそのものではなく、チャンク分割、取得件数、再ランキング、データクリーニング、評価方法にあります。

4. 各モデルはどんなタスクに向くか

モデル	向いている場面	ざっくりした判断
`text-embedding-3-small`	汎用検索、RAG、素早い導入	API 利用が簡単でコストにも優しい
`text-embedding-3-large`	品質重視の汎用検索	品質優先で実装負担も小さい
`bge-small-zh-v1.5`	中国語の軽量検索	中国語用途の定番入門モデル
`bge-base-zh-v1.5`	中国語ナレッジベース、FAQ、セマンティック検索	中国語シナリオでバランスが良い
`bge-m3`	中国語中心だが、より複雑な検索にも広げたい場合	拡張性が高い
`multilingual-e5-base`	多言語の基本検索	国際化プロジェクトでよく使われる
`multilingual-e5-large`	多言語で高品質な再現率が欲しい場合	より品質重視
`gte-base-zh`	中国語の軽量検索	まずベースラインを作るのに向く
`gte-large-zh`	中国語で品質重視の場面	BGE との比較対象として使いやすい
`jina-embeddings-v3`	多言語、Web、汎用テキストタスク	embedding 層を統一したいときに試す価値がある

5. 実際の選定をどう進めるか

論文を書くのではなく、実際にシステムを作るなら、選定手順はもっとシンプルで大丈夫です。

シナリオ 1: 中国語ナレッジベース

まずは次の組み合わせを試します。

bge-base-zh-v1.5
gte-large-zh
bge-small-zh-v1.5

予算が厳しいなら小さいモデルから始めて、検索品質をより重視するなら大きいモデルへ広げます。

シナリオ 2: 中国語と英語が混在するナレッジベース

まずは次を試します。

multilingual-e5-base
multilingual-e5-large
text-embedding-3-small
text-embedding-3-large

自前運用を避けたいなら OpenAI がより直接的です。自前でホストしたいなら、E5 の方が一般的です。

シナリオ 3: 今は中国語中心だが、将来的に多言語へ広げる可能性がある

まずは次を試します。

bge-m3
multilingual-e5-base
jina-embeddings-v3

このタイプの場面で一番怖いのは、最初は中国語だけを前提に設計し、後からベクトル基盤を丸ごと作り直すことです。

6. 最後に大事なのは「ランキング1位」ではない

埋め込みモデル選定で最も陥りやすい失敗は、公開ベンチマークの点数だけを見て、そのまま本番投入してしまうことです。

より確実なのは、だいたい次の手順です。

まず 2 から 4 個の候補モデルを選ぶ
自分たちの実データで embedding を作る
一度検索評価を回す
そのうえでコスト、遅延、導入方法を合わせて最終判断する

実際に結果を決めるのは、モデル名そのものよりも、そのモデルが自分のコーパス、チャンク戦略、クエリ形式に合っているかどうかだからです。

まとめ

実用的な結論だけ覚えるなら、次のように整理できます。

中国語優先: bge-base-zh-v1.5、gte-large-zh
コスト優先: bge-small-zh-v1.5、gte-base-zh、text-embedding-3-small
多言語優先: multilingual-e5-base、multilingual-e5-large、jina-embeddings-v3
API をそのまま使いたい: text-embedding-3-small、text-embedding-3-large
中国語と将来の拡張性を両立したい: bge-m3

すべてのプロジェクトに合う単一のモデルはありませんが、多くのプロジェクトでは、まずこの数グループから第一候補をかなり素早く絞り込めます。