Embeddingモデル10種を実測比較してみた —— クロスモーダル / 多言語 / Needle-in-a-Haystack / MRL

本記事の計測は 2026 年 3 月時点のものです。
Embedding まわりは半年で景色が変わる領域なので、数値そのものよりも「どの軸で測るか」の部分を参考にしていただければと思います。それ以降のモデル動向（Qwen3 Embedding、Jina v5、Voyage context-4、ColPali 系など）は後編で扱います。

本記事は Zilliz 公式ブログの記事（英語版）を、日本語向けに翻訳・統合・再構成したものです。日本語読者向けの補足は「🇯🇵」マークのセクションとして加筆しています。

TL;DR

公開ベンチマークが取りこぼしている 4 つの本番シナリオ（クロスモーダル検索 / クロスリンガル検索 / 長文書からのキー情報抽出 / 次元圧縮）で、embedding モデル 10 種を実測しました。

すべてを取るモデルは存在しません。 4 タスクすべてで 1 位のモデルはゼロでした
オールラウンダーとしては Gemini Embedding 2 が最良。クロスリンガル 1 位、長文書 1 位、モダリティカバレッジ最広
クロスモーダルでは OSS の Qwen3-VL-2B（2B）がすべてのクローズド API に勝ちました。 決め手はパラメータ数ではなくモダリティギャップ
ストレージ削減のために次元を切り詰めるなら Voyage Multimodal 3.5 か Jina Embeddings v4。 256 次元まで削っても劣化は 1% 未満
335M 以下の軽量モデルは、多言語とも長文書とも相性が悪い。 用途を英語の短文に絞れるかどうかが分水嶺です
🇯🇵 ただし日本語性能はこのテストでは測っていません。 JMTEB / JQaRA などで別途検証が必要です（詳細は本文中の 🇯🇵 セクション）

はじめに：text-embedding-3-small のその先が分からない

開発者の方と話していてよく聞くのが、「RAG を作るとき、とりあえず OpenAI の text-embedding-3-small を選んだ」という話です。確かに、可もなく不可もない堅実な選択です。

ただ、そこから一歩先に進もうとすると、途端に選定の指針がなくなります。

理由は 2 つあります。

ひとつは、本番の RAG は単一のデータ形式では終わらないこと。画像、テキスト、PDF といったファイル形態に加えて、契約書・作業手順書・社内通知といった内容の種類も混ざります。データの性質が違えば、適した embedding モデルも変わります。

もうひとつは、embedding モデル自体が正反対の 2 方向に進化していること。ひとつは「深く掘る」方向で、法務やコードといった特定ドメインに特化して精度を極めるアプローチ。もうひとつは「広く取る」方向で、マルチモーダル融合により 1 つのモデルでテキストも画像も扱おうとするアプローチです。Google が公開した Gemini Embedding 2 Preview（テキスト・画像・動画・音声・PDF の 5 モダリティ対応、100 言語以上、ネイティブ MRL、3072 次元）は後者の代表格です。

モデルの数が増え、ユースケースが細分化した結果、選定の難易度だけが上がっている状況です。

そこで今回は 2025〜2026 年に登場した主要な embedding モデルを集め、公開ベンチマークがカバーしきれていない本番寄りのシナリオに絞って独自テストを設計しました。

01. 参加モデル

API サービス型とローカル実行可能な OSS の両方から 10 モデルを選定し、対照群として OpenAI text-embedding-3-large と CLIP ViT-L-14 を加えています。

モデル	提供元	パラメータ数	次元	モダリティ	特徴
Gemini Embedding 2	Google	非公開	3072	テキスト/画像/動画/音声/PDF	全モダリティ対応
Jina Embeddings v4	Jina AI（ドイツ）	3.8B	2048	テキスト/画像/PDF	MRL + LoRA マルチタスク
Voyage Multimodal 3.5	Voyage AI（MongoDB）	非公開	1024	テキスト/画像/動画	各項目バランス型
Qwen3-VL-Embedding	Alibaba Qwen	2B	2048	テキスト/画像/動画	OSS・軽量マルチモーダル
Jina CLIP v2	Jina AI（ドイツ）	約 1B	1024	テキスト/画像	CLIP アーキテクチャの現代版
Cohere Embed v4	Cohere（カナダ）	非公開	固定	テキスト/画像/混在文書 ※	エンタープライズ検索向け
OpenAI 3-large	OpenAI	非公開	3072	テキスト	最も広く使われている
BGE-M3	BAAI	568M	1024	テキスト	OSS 多言語
mxbai-embed-large	Mixedbread AI（ドイツ）	335M	1024	テキスト	軽量・英語特化
nomic-embed-text	Nomic AI	137M	768	テキスト	超軽量
CLIP ViT-L-14	OpenAI (2021)	428M	768	テキスト/画像	ベースライン

各モデルの簡単な紹介です。

Gemini Embedding 2 — Google が 2026 年 3 月に公開した、同社初の全モダリティ対応 embedding モデル。5 モダリティすべてをサポートします。
Jina Embeddings v4 — Qwen2.5-VL-3B ベースの 3.8B モデル。3 つの LoRA アダプタ（retrieval.query / retrieval.passage / text-matching）で検索シナリオを切り替えます。テキスト・画像・PDF 対応。
Jina CLIP v2 — CLIP アーキテクチャの現代版。テキスト–画像のクロスモーダルアラインメントに特化し、多言語対応。
Voyage Multimodal 3.5 — Voyage AI 製。同社は 2025 年 2 月に MongoDB が約 2.2 億ドルで買収しています。テキスト・画像・動画対応。
Qwen3-VL-Embedding — Alibaba Qwen チームの OSS マルチモーダル embedding シリーズ。2B と 8B がありますが、今回は 2B を採用しました。11GB のコンシューマ GPU 1 枚に載るため、軽量デプロイの現実性を測る意味があります。
OpenAI 3-large — MTEB 常連のテキストモデル。RAG で最もよく使われています。
BGE-M3 — 智源研究院（BAAI）の OSS 多言語モデル。568M パラメータで 100 言語以上に対応。
mxbai-embed-large / nomic-embed-text — それぞれドイツ Mixedbread AI と米国 Nomic AI の軽量 OSS。mxbai は 335M で英語 MRL が強く、nomic は 137M と今回の最小モデルです。

02. 既存ベンチマークの何が足りないのか

モデルを決めた後、テスト項目を検討するために既存のベンチマークを一通り確認しましたが、今回知りたいことをカバーしきれていませんでした。

MTEB（Massive Text Embedding Benchmark） は現時点で最も権威のある評価体系ですが、以下の軸が抜けています。

テキストのみ — 画像・動画などのマルチモーダル入力を扱わない
同一言語内検索 — MIRACL などの多言語サブセットはあるが、測っているのは同一言語内の検索。「日本語クエリで英語文書を引く」ようなクロスリンガル項目がない
次元圧縮を測らない — MRL で切り詰めた後の品質劣化を評価しない
長文書のカバーが限定的 — LongEmbed サブセットはあるが、主流は数千トークン級の短文。数万字規模の系統的なテストが不足

MMEB（Massive Multimodal Embedding Benchmark） はマルチモーダルを補完していますが、こちらにも課題があります。

hard negative がない — 誤答候補と正解の差が大きすぎて高得点を取りやすく、モデル間の微妙な差が出ない
クロスリンガル・MRL・長文書を測らない

これらの抜けは、RAG / Agent / ベクトル検索システムを実際に構築するときに直面する問題とほぼ一致します。

CCKM ベンチマーク

そこで、標準ベンチマークが取りこぼしている 4 つの能力を測るテストセットを組み、頭文字を取って CCKM（Cross-modal, Cross-lingual, Key information, MRL）と呼んでいます。

軸	何を測るか	なぜ重要か
クロスモーダル検索	ほぼ同一の撹乱項が存在する中で、説明文と正しい画像を対応づけられるか	マルチモーダル RAG では、テキストと画像の embedding が同一ベクトル空間に乗っている必要がある
クロスリンガル検索	中国語クエリから正しい英語文書を引けるか（およびその逆）	本番のナレッジベースは多言語混在であることが多い
キー情報検索	4K〜32K 文字の文書に埋もれた特定の事実を見つけられるか（Needle in a Haystack）	RAG は契約書・論文のような長文書を頻繁に扱う
MRL 次元圧縮	256 次元に切り詰めたときにどれだけ品質を失うか	次元が減ればベクトル DB のストレージコストが下がる。ただし品質の代償は？

MTEB はこの 4 つをどれもカバーしていません。MMEB はマルチモーダルを追加していますが hard negative がないため、微妙な区別ができることを証明しないままスコアだけが高く出ます。CCKM はその隙間を埋めることを狙って設計しています。

軸 1：クロスモーダル検索（テキスト ↔ 画像）

想定シナリオ：EC の画像検索、図表混在ナレッジベース、マルチメディアコンテンツの理解。

タスク設計：COCO val2017 から 200 組の画像–テキストペアを抽出。テキストは GPT-4o-mini で生成した詳細な説明文で、各画像に対して hard negative を 3 件（正解説明と 1〜2 箇所のディテールだけが違う撹乱項）用意しています。モデルは「画像 200 枚 + 撹乱説明 600 件」の混合プールから双方向検索を行います。

実際のサンプル：

正解説明："The image features vintage brown leather suitcases with various travel stickers including 'California', 'Cuba', and 'New York', placed on a metal luggage rack against a clear blue sky."

撹乱項：同じ文で、"California" を "Florida" に、"blue sky" を "overcast sky" に差し替えたもの。文としてはまったく自然に読めてしまうので、画像内のディテールを本当に「理解」していなければ区別できません。

採点方法

全画像と全テキスト（正解 200 + 撹乱 600）を embedding 化
t2i：各説明文が 200 枚の中から最も近い画像を探し、1 位が正解なら得点
i2t：各画像が 800 件のテキストから最も近いものを探し、1 位が正解説明（撹乱項ではない）なら得点
最終スコア hard_avg_R@1 = (t2i 正解率 + i2t 正解率) / 2

結果

モデル	hard_avg_R@1	モダリティギャップ	パラメータ
Qwen3-VL-2B	0.945	0.25	2B（OSS）
Gemini Embed 2	0.928	0.73	非公開
Voyage MM-3.5	0.900	0.59	非公開
Jina CLIP v2	0.873	0.87	約 1B
CLIP ViT-L-14	0.768	0.83	428M

正直、この結果は予想外でした。2B の OSS モデルが、クローズドな API を上回っています。

理由は「モダリティギャップ」という指標を見ると分かります。

モダリティギャップとは
embedding モデルはテキストと画像を同一のベクトル空間にマッピングしますが、実際にはテキストベクトルと画像ベクトルが空間内の別々の領域に「かたまって」分布しがちです。モダリティギャップは、この 2 つのかたまりの距離（テキストベクトル平均と画像ベクトル平均の L2 距離）を表します。ギャップが小さいほどクロスモーダル検索の精度が出しやすくなります。

Qwen3-VL-2B のギャップは 0.25 で、Gemini の 0.73 を大きく下回っています。

これは実装上も意味があります。Milvus のようなベクトルデータベースで画像とテキストの混在コレクションを作る場合、モダリティギャップが小さければ、テキストベクトルと画像ベクトルを同じコレクションに入れて、そのまま双方向に検索できます。

逆にギャップが大きいモデルでは、クロスモーダルの類似度検索そのものの信頼性が落ちるため、コレクションを分ける、スコアを正規化する、あるいはリランキング工程を挟んで補正するといった対応が必要になります。つまりモダリティギャップは、精度だけでなくパイプラインの複雑さにも直結する指標です。

このラウンドの結論はシンプルです。マルチモーダル性能に関して、OSS の小型モデルはすでにクローズド API と互角に戦えます。

軸 2：クロスリンガル検索（中国語 ↔ 英語）

想定シナリオ：多言語混在ナレッジベース。ユーザーは A 言語で質問するが、答えは B 言語の文書の中にある。

タスク設計：手作業で構築した中英対訳文 166 組を、3 段階の難易度に分類。各言語につき hard negative を 152 件追加しています。

難易度	中国語	英語	Hard Negative
Easy	我爱你。	I love you.	—
Medium	这道菜太咸了。	This dish is too salty.	"This dish is too sweet." / "This soup* is too salty."*
Hard	画蛇添足	To gild the lily	"To add fuel to the fire" / "To let the cat out of the bag"

「画蛇添足」→「To gild the lily」のような文化的概念のクロスリンガルアラインメントが最難関です。

採点方法

中国語（166 + 撹乱 152）と英語（166 + 撹乱 152）を embedding 化
中→英：各中国語文が 318 件の英語文から正しい訳を探す
英→中：その逆
hard_avg_R@1 = (中→英正解率 + 英→中正解率) / 2

結果

モデル	hard_avg_R@1	Easy	Medium	Hard（慣用句）
Gemini Embed 2	0.997	1	1	1
Qwen3-VL-2B	0.988	1	1	0.969
Jina v4	0.985	1	1	0.969
Voyage MM-3.5	0.982	1	1	0.938
OpenAI 3-large	0.967	1	1	0.906
Cohere v4	0.955	1	0.98	0.875
BGE-M3 (568M)	0.940	1	0.96	0.844
nomic (137M)	0.154	0.3	0.12	0.031
mxbai (335M)	0.120	0.22	0.08	0.031

Gemini が 0.997 とほぼ満点で、慣用句レベルの対応まで正解しました。Hard グループで R@1 = 1.000 を維持したのは Gemini だけです。

注目すべき点が 2 つあります。

ひとつは、このタスクがモデルを明確に 2 グループに分断したこと。上位陣は 0.93 以上、nomic と mxbai は 0.16 未満で、中間がありません。多言語能力は「ある / ない」の二値に近く、グラデーションが存在しない領域だということが分かります。英語特化の軽量モデルは、クロスリンガル用途では事実上ゼロ点と考えたほうがよさそうです。

もうひとつは、総合スコアだけ見ても上位陣の差が分からないこと。0.93 以上のモデルは Easy / Medium ではほぼ全員が満点なので、実際に差がついているのは Hard 層（慣用句）だけです。モデル比較をするときは、総合スコアではなく最難関サブセットの内訳を見ないと意味がありません。これは自社データで評価セットを作るときにもそのまま当てはまる話で、簡単な事例ばかり集めた評価セットは、どのモデルを選んでも満点になって何も分からなくなります。

軸 3：Needle in a Haystack（長文書からのキー情報抽出）

想定シナリオ：RAG で長い契約書や研究論文を扱う。数万字のテキストの中から、embedding モデルはキー情報を拾えるのか？

タスク設計：Wikipedia 記事を「干し草の山」（4K〜32K 文字）とし、異なる位置（先頭 / 25% / 50% / 75% / 末尾）に架空の事実情報を「針」として挿入。クエリの embedding によって、針を含む文書と含まない文書を正しく判別できるかを見ます。

針の例："The Meridian Corporation reported quarterly revenue of $847.3 million in Q3 2025."
クエリ："What was Meridian Corporation's quarterly revenue?"
干し草：32,000 字の Wikipedia 記事（例：光合成に関する記事）の途中にこの一文が埋め込まれている

採点方法

クエリ、針あり文書、針なし文書の embedding を生成
クエリと針あり文書の類似度が高ければ「発見」と判定
全長さ・全位置で平均正解率を算出

最終指標は overall_accuracy と degradation_rate（最短文書から最長文書への正解率の劣化幅）です。

結果

このタスクは想定以上に差がつきました。

モデル	1K	4K	8K	16K	32K	総合	劣化率
Gemini Embed 2	1	1	1	1	1	1	0%
OpenAI 3-large	1	1	1	—	—	1	0%
Jina v4	1	1	1	—	—	1	0%
Cohere v4	1	1	1	—	—	1	0%
Qwen3-VL-2B	1	1	—	—	—	1	0%
Voyage MM-3.5	1	1	—	—	—	1	0%
Jina CLIP v2	1	1	1	—	—	1	0%
BGE-M3 (568M)	1	1	0.92	—	—	0.973	8%
mxbai (335M)	0.98	0.6	0.4	—	—	0.66	58%
nomic (137M)	1	0.46	0.44	—	—	0.633	56%

※「—」はモデルのコンテキストウィンドウ上限を超えているか、未計測であることを示します。

おおむね 3 階層に分かれました。上位 7 モデルは、それぞれのコンテキストウィンドウの範囲内では満点です。BGE-M3（568M）は 8K で軽微な劣化（0.92）。335M 以下の mxbai・nomic は 4K の時点で明確に落ち込み、8K では 0.40〜0.44 まで下がります。

ここで重要なのは、この崩れ方がモデルの「賢さ」の問題とは限らないことです。mxbai-embed-large のコンテキストウィンドウは 512 トークンしかありません。4K 文字（英語で約 1,000 トークン）の文書を入力した時点で、大半が切り捨てられています。針が切り捨てられた領域にあれば、当然見つかりません。

つまりこの表は、「長文でも意味を捉えられるか」と「そもそも文書が入り切るか」という 2 つの問題が混ざった結果です。軽量モデルを検討するときは、精度スコアより先に公称コンテキスト長を確認するべきで、それが chunk サイズの上限を決めます。

そして 4K〜32K の全レンジを走れたのは Gemini だけでした。これはスコアが良かったからというより、このテストに含めた他のモデルは 32K に届くコンテキストウィンドウを持っていないためです。

🇯🇵 日本語読者向けの補足：日本語だと劣化はもっと早く来ます

ここは日本語で RAG を組む場合に見落としやすいポイントです。

本テストの単位は文字数です。原文では「4K 文字 ≒ 約 1000 トークン」と換算していますが、これは英語の話です。多言語トークナイザにおける日本語は、おおむね 1 文字あたり 0.7〜1.5 トークン程度を消費します（漢字・ひらがな・カタカナの比率によって変動します）。

つまり、同じ「4,000 文字」でも、日本語は英語の 2〜3 倍のトークンを食います。

これを先ほどの mxbai の話と組み合わせると、事態はもっと分かりやすくなります。mxbai のコンテキストウィンドウは 512 トークン。英語なら約 2,000 文字入りますが、日本語だと 350〜700 文字程度しか入りません。 A4 半ページ分にも届かない計算です。

上の表で「335M 級のモデルは 4K 文字で崩れ始める」と書きましたが、日本語の文書であれば、それよりはるかに早い段階から情報が切り捨てられていると考えるべきです。日本語の社内文書は、議事録でも仕様書でも数千文字は普通に超えます。

実務的な指針としては、

コンテキスト長の公称値（トークン）を、日本語の実効文字数に換算し直す。 ざっくり「公称トークン数 × 0.7〜1.0 文字」が上限だと思っておくと安全側です
日本語 RAG で軽量モデル（335M 以下）を使うなら、chunk サイズを英語想定の半分以下に取る
モデル選定の前に、自分のコーパスの chunk 長分布をヒストグラムで確認する。 平均ではなく分布を見ないと、長い側の 10% が丸ごと切られていることに気づけません

このあたりは、後編で扱う「長文書 RAG」の話に直結します。

軸 4：MRL 次元圧縮

MRL とは
MRL（Matryoshka Representation Learning、マトリョーシカ表現学習）は、embedding ベクトルの先頭 N 次元だけを取り出しても意味のある低次元表現になるように学習させる手法です。例えば 3072 次元のベクトルから先頭 256 次元だけを使っても、そこそこの意味的品質を保てます。

コスト面でのインパクトは分かりやすくて、3072 次元 → 256 次元は 12 倍のストレージ削減になります。float32 で 1 億ベクトルを保持するコレクションなら、おおよそ 1.14 TB → 95 GB。インフラ費用の桁が変わります。

タスク設計：STS-B（Semantic Textual Similarity Benchmark）から 150 組の文ペアを使用。各ペアには人手による意味的類似度スコア（0〜5）が付いています。各モデルで embedding を生成し、まず全次元、次に 256 / 512 / 1024 次元に切り詰めて、それぞれの次元で人手評価との順位一致度を測ります。

文 A	文 B	人手スコア
A girl is styling her hair.	A girl is brushing her hair.	2.5
A group of men play soccer on the beach.	A group of boys are playing soccer on the beach.	3.6

1 組目（2.5 点）は中難易度です。styling と brushing は近いけれども同じではない。簡単すぎるサンプルで点を稼がないよう、意図的に中難易度（1.5〜4.0 点）のペアを多めにサンプリングしています。

採点方法

各次元で、文ペアの embedding のコサイン類似度を計算
モデルの類似度順位と人手評価の順位で Spearman 順位相関を取り、ρ を得る

Spearman ρ とは
2 つの順位付けの一致度を測る係数です。人間が「A が最も似ている > B > C」と判断し、モデルの embedding 類似度も A > B > C の順になっていれば ρ は 1.0 に近づきます。ρ = 1.0 が完全一致、ρ = 0 が無相関です。

主要指標は Spearman ρ（高いほど良い）と min_viable_dim（品質劣化が 5% 以内に収まる最小次元）です。

結果

ベクトルデータベースで次元を切り詰めてストレージコストを下げようとしている場合、この結果は重要です。

モデル	ρ（全次元）	ρ（256 次元）	劣化
Voyage MM-3.5	0.880	0.874	0.70%
Jina v4	0.833	0.828	0.60%
mxbai (335M)	0.815	0.795	2.50%
nomic (137M)	0.781	0.774	0.80%
OpenAI 3-large	0.767	0.762	0.60%
Gemini Embed 2	0.683	0.689	-0.80%

このラウンドでは Gemini が最下位でした。一方、mxbai-embed-large は 335M しかないのに MRL で 3 位に入り、OpenAI 3-large を上回っています。

Jina v4 と Voyage が MRL で強いのは、学習時に MRL 目的関数を明示的に最適化しているためです。つまり、次元圧縮の耐性はモデルサイズとほとんど相関せず、「そのための学習をしたかどうか」で決まります。

注意
MRL のランキングが表しているのは「次元圧縮後の意味保持能力」であって、「全次元での意味理解の品質」とは別物です。Gemini は全次元での検索能力が非常に高いことが（クロスリンガルとクロスモーダルで）すでに示されています。この「ダイエットテスト」でのスコアが低いだけです。次元圧縮を必要としないなら、この項目の参考価値は限定的です。

総合成績

モデル	パラメータ	クロスモーダル	クロスリンガル	Needle	MRL ρ
Gemini Embed 2	非公開	0.928	0.997	1	0.668 ※
Voyage MM-3.5	非公開	0.900	0.982	1	0.880
Jina v4	3.8B	—	0.985	1	0.833
Qwen3-VL-2B	2B	0.945	0.988	1	0.774
mxbai-embed-large	335M	—	0.120	0.66	0.815
OpenAI 3-large	非公開	—	0.967	1	0.760
BGE-M3	568M	—	0.940	0.973	0.744
nomic-embed-text	137M	—	0.154	0.633	0.780
Cohere v4	非公開	—	0.955	1	—
Jina CLIP v2	約 1B	0.873	0.934	1	—
CLIP ViT-L-14	428M	0.768	0.030	—	—

※「—」はモデルが当該能力に非対応、または未計測。CLIP は 2021 年時点のベースラインとして掲載しています。
※ 原記事では Gemini の MRL 値が総合表（0.668）と詳細表（0.683）で食い違っています。原文の表記をそのまま残しています。

この表から言えることはひとつです。すべてのタスクで 1 位を取れるモデルは存在しませんでした。

Gemini はクロスリンガルと長文書が最強ですが MRL は最下位。Qwen3-VL-2B はクロスモーダル 1 位ですが MRL は中位。Voyage は全項目が良好ですが 1 位はひとつもありません。成績表の「形」がモデルごとにまったく違います。

🇯🇵 日本語読者向けの補足：これらのテストは日本語を測っていません

ここは正直に書いておく必要があります。

多言語モデルのスコアは、往々にして学習データ量が多い言語に引っ張られます。実際、舘野祐一氏（hotchpotch）が公開している HAKARI-Bench の NanoJMTEB-v2（Retrieval）を参考のベンチマーカーの一つになると思います。

順位	モデル	Borda Score	総パラメータ
1	Nemotron-3-Embed-8B	97.38	7.95B
2	sarashina-embedding-v2-1b	91.18	1.22B
5	ruri-v3-310m	88.57	315M
6	Qwen3-Embedding-8B	88.43	7.57B
9	jina-embeddings-v5-text-small	79.34	677M
10	gemini-embedding-2	78.24	非公開
11	ruri-v3-30m	77.69	37M
12	text-embedding-3-large	77.41	非公開
15	bge-m3	74.66	568M
22	Qwen3-Embedding-0.6B	66.39	596M

（NanoJMTEB-v2 / Retrieval、Borda Score 降順。全 67 モデル中からの抜粋です）

日本語で自分の候補を絞るなら、以下を使うのが現実的です。

ベンチマーク / データセット	内容	提供
JMTEB	MTEB の日本語版。6 タスク・16 データセット	SB Intuitions
HAKARI-Bench	軽量 Nano-set による多言語 IR 評価基盤。日本語は NanoJMTEB-v2 で確認可能	hotchpotch
JQaRA	RAG 評価向け日本語 Q&A 検索データセット（nDCG@10）	hotchpotch
JaCWIR	Web タイトル・概要ベースのカジュアルな日本語 IR	hotchpotch

ただし注意点として、日本語特化モデルはクロスリンガル検索やマルチモーダルには基本的に対応していません。「日本語の社内文書だけを検索する」なら日本語特化 OSS が費用対効果が出るが、「日本語クエリで英語の技術文書も引きたい」「画像や PDF も混ざる」なら本文の上位モデル側から選ぶことになります。ここは要件次第で使い分けるところです。

まとめと選定の指針

クロスモーダル：Qwen3-VL-2B（0.945）が 1 位、Gemini（0.928）が 2 位、Voyage（0.900）が 3 位。OSS の 2B モデルがクローズド API に勝ちました。決め手はモダリティギャップです。

クロスリンガル：Gemini（0.997）が独走。慣用句レベルの対応まで満点。上位 8 モデルは 0.93 以上で、英語特化の軽量モデルは事実上ゼロ点です。

Needle in a Haystack：API 勢と大型 OSS は 8K 以内ならほぼ満点。335M 以下は 4K から劣化します。32K を完走して満点だったのは Gemini のみ。

MRL 次元圧縮：Voyage（0.880）と Jina v4（0.833）がリード。256 次元に切り詰めても劣化は 1% 未満。Gemini（0.668）は最下位。

総合的に見れば、Gemini Embedding 2 は現時点で最も汎用性の高い embedding モデルと言えます。

強み：クロスリンガル 1 位（0.997）、Needle 1 位（1.000）、クロスモーダル 2 位（0.928）、モダリティカバレッジ最広（5 モダリティ。他は最大 3）
弱み：MRL 次元圧縮が下位（ρ=0.668）、クロスモーダルは OSS の Qwen3-VL-2B に負けている

次元圧縮が不要なら、「クロスリンガル + 長文書」の組み合わせで Gemini に現時点で対抗馬はいません。ただしクロスモーダル精度と次元圧縮に関しては、特化型モデルのほうが優れています。

選定フロー

※ 日本語分岐は、日本語読者向けに本記事で加筆したものです。原記事のフローには含まれていません。

本テストの限界

最後に、今回のテストで足りていない部分を明記しておきます。

計測しきれなかったモデルがあります（NVIDIA NV-Embed-v2、Jina v5-text など）
動画・音声・PDF / 表といったモダリティは、一部モデルが対応を謳っていますが今回はカバーしていません
コード検索のような垂直ドメインにも踏み込んでいません
サンプル数が小規模なため、モデル間の僅差は統計的な誤差範囲に収まっている可能性があります
前述の通り、日本語は計測していません

順位そのものよりも、「どういう軸で測ると差が見えるか」という設計部分を持ち帰っていただければ幸いです。

おわりに：測り方を持っておくことのほうが価値がある

4 ラウンド走らせてみて、感じたことがいくつかあります。

数年前までクロスリンガルの意味的アラインメントは論文の中の研究テーマでしたが、今は API を叩けば使えます。5 年前は画像–テキスト検索のために CLIP を自前で学習する必要がありましたが、今は 1 つの汎用モデルがテキスト・画像・動画・音声・PDF を同時に扱います。この領域の変化速度は、多くの人が体感しているより速いと思います。

もうひとつ印象的だったのは OSS の追い上げです。Qwen3-VL-2B はわずか 2B でクロスモーダル精度がすべてのクローズド API を上回りました。BGE-M3 のクロスリンガル能力も多くの商用サービスに引けを取りません。embedding という領域では、データ品質と学習戦略の比重が上がり、モデル規模と計算資源投入の比重が下がっているように見えます。特定の API にロックインされることを過度に心配する必要はなさそうです。

そして選定について。この記事の結論は、1 年後にはほぼ確実に書き換えが必要になります。 どのモデルを選ぶかで悩む時間があるなら、評価パイプラインを整備するほうに時間を使ったほうがよいと考えています。自分の業務シナリオとデータの形を把握し、自社データで新モデルを素早く検証できるテストフローを組んでおけば、新しいものが出たときに一度回すだけで採否が判断できます。

公開ベンチマーク（MTEB、MMTEB、MMEB、そして日本語なら JMTEB）は候補を絞るのには有用ですが、最終的には自分のシナリオで検証するしかありません。長期的には、特定のモデルを当てることよりも、この評価能力を持っていることのほうが価値があるはずです。

本記事の評価コードは GitHub で公開しています。https://github.com/zc277584121/modern-embedding-bench

よくある質問

実際にモデルを選ぶときによく聞かれる質問をまとめておきます。

Q. 今はテキストしか扱っていませんが、マルチモーダルモデルを選んでおくべきですか？

ロードマップ次第です。今後 6〜12 か月のうちに画像や PDF を扱う見込みがあるなら、最初から Gemini Embedding 2 や Voyage Multimodal 3.5 のようなマルチモーダルモデルで始めておくと、後々の移行が楽になります。モデルを乗り換えると全データを embedding し直す必要があるので、これは無視できないコストです。逆に当面テキストのみで確定しているなら、OpenAI 3-large や Cohere Embed v4 のようなテキスト系のほうがコストパフォーマンスは良くなります。

Q. MRL の次元圧縮で、実際どれくらいストレージが減りますか？

3072 次元 → 256 次元で 12 倍です。float32・1 億ベクトルのコレクションなら約 1.14 TB → 95 GB。ただしすべてのモデルが切り詰めに耐えるわけではありません。Voyage Multimodal 3.5 と Jina Embeddings v4 は 256 次元でも劣化 1% 未満ですが、そうでないモデルは目に見えて品質が落ちます。「MRL 対応」と書いてあるかどうかではなく、自分の評価セットで切り詰め後の数値を測ってください。

Q. クロスモーダル検索で、本当に Qwen3-VL-2B のほうが Gemini より良いのですか？

このベンチマークに関しては、そうです。ほぼ同一の撹乱項を含む条件で 0.945 対 0.928 でした。主因は Qwen 側のモダリティギャップの小ささ（0.25 対 0.73）で、テキストと画像のベクトルが空間内で近くに分布しています。ただし Gemini は 5 モダリティ、Qwen は 3 モダリティです。音声や PDF を直接埋め込みたいなら Gemini 一択になります。

Q. これらのモデルは Milvus のようなベクトル DB でそのまま使えますか？

使えます。いずれも標準的な float ベクトルを出力するので、コサイン類似度・L2 距離・内積のいずれでも検索できます。PyMilvus であればモデルの SDK でベクトルを生成し、それを投入するだけです。MRL で切り詰めたベクトルを使う場合は、コレクション作成時に次元数を切り詰め後の値（例：256）で指定しておきます。

参考リンク

ベンチマーク

MTEB: https://huggingface.co/spaces/mteb/leaderboard
MMTEB: https://huggingface.co/papers/2502.13595
MMEB: https://huggingface.co/spaces/TIGER-Lab/MMEB-Leaderboard
JMTEB（日本語）: https://github.com/sbintuitions/JMTEB
JQaRA（日本語）: https://github.com/hotchpotch/JQaRA
JaCWIR（日本語）: https://github.com/hotchpotch/JaCWIR

本テストのコード

https://github.com/zc277584121/mm-embedding-bench

原記事

How to Choose the Best Embedding Model for RAG in 2026: 10 Models Benchmarked

その他

Cohere Embed 4: https://cohere.com/blog/embed-4
hakari-bench/leaderboard: https://huggingface.co/spaces/hakari-bench/leaderboard#view=Custom&bench=NanoJMTEB-v2

後編について

2026 年下半期版として、シナリオ別（普通のテキストナレッジベース / PDF・画像・音声動画 / 長文書 / 表・スクリーンショット・複雑レイアウト）の選定指針を別記事にまとめます。Qwen3 Embedding、Jina v5、Voyage context-4、ColPali / ColQwen / Nemotron ColEmbed V2 あたりを扱う予定です。