1. 背景：なぜ日本語マルチモーダル RAG か

⚠️ 注意書き：本記事の内容は参考程度にしてください
本記事における検証コードの多くはAIを活用して記述しており、細部まで完全な実行確認を行えたわけではありません。そのため、記載されている結果や手順については、あくまで参考程度に留めていただきますようお願いいたします。

gemini-embedding-2 の登場で「テキストも画像も同じベクトル空間に入れる」マルチモーダル RAG がクラウドでは手軽になりました。一方で ローカル（商用利用可・GPU 1 枚）で日本語のマルチモーダル RAG はどこまでいけるのか を知りたい、というのが出発点です。

そこで以下を実機評価しました。

日本語テキスト検索 / STS（一般・医療）
日本語クロスモーダル検索（画像↔キャプション）
日本語ゼロショット画像分類

2. 予備知識

専門用語が多いので、まずざっくり全体像を説明します。詳しい人は読み飛ばしてください。

2.1 「埋め込み（エンベディング）」とは？

埋め込み（embedding）= 文章や画像を「数字の列（ベクトル）」に変換したもの です。

たとえば「猫がソファで寝ている」という文を、[0.12, -0.85, 0.33, ...] のような数百〜数千個の数字の並びに変換します。画像も同じように数字の列にできます。

ポイントは 意味が近いものは、数字の列も近くなる ように変換されることです。

「猫がソファで寝ている」と「ねこがソファで眠っている」→ ベクトルがほぼ同じ向き
「猫がソファで寝ている」と「株価が暴落した」→ ベクトルは全然違う向き

ベクトル同士の「近さ」は コサイン類似度（向きがどれだけ揃っているか、1に近いほど似ている）で測ります。これを使うと「意味が近い文書を探す」「画像に合うキャプションを探す」が、数字の計算だけでできるようになります。これが RAG（検索して答える AI）や画像検索の土台です。

2.2 「エンベディングモデル」とは？

文章や画像を、上記のベクトルに変換してくれる AI が「エンベディングモデル」です。本記事で比較しているのは全部これです。

「マルチモーダル」なエンベディングモデルは、テキストも画像も同じ空間のベクトルに変換できます。だから「文章で画像を検索」「画像で文章を検索」が可能になります（クロスモーダル検索）。

2.3 普通の AI（GPT・Gemini などの LLM）との違い

同じ「AI」でも役割が全く違います。

	LLM（GPT, Gemini など）	エンベディングモデル
入力	基本は文章（※画像も可）	文章 or 画像
出力	文章（人間が読める答え）	数字のベクトル（人間は読めない）
用途	会話・要約・生成	検索・分類・類似度判定の「部品」
たとえると	質問に答えてくれる専門家	本に索引・住所をつける司書

LLM は「質問に文章で答える」のが仕事です。対してエンベディングモデルは「意味を座標（ベクトル）に変換して、近いものを探せるようにする」のが仕事です。

実際の RAG では、エンベディングモデルで関連文書を検索し、その文書を LLM に渡して回答を生成する、という分業になります。

2.4 スコア（精度）はどうやって出す？

タスクごとに「正解」が用意されていて、モデルの出したベクトルがどれだけ正解に沿っているかを数値化します。本記事で使う3種類：

STS（意味的類似度）→ Spearman 相関
人間が「この2文はどれくらい似てる？」を 0〜5 で採点したデータを使う。モデルが出すベクトルのコサイン類似度の順位が、人間の採点の順位とどれだけ一致するかを Spearman 相関（-1〜1、1に近いほど人間と同じ感覚）で測る。
検索（Retrieval）→ Recall@K / nDCG@10
「この質問の正解文書はコレ」というペアを用意。質問ベクトルに近い順に文書を並べ、
- Recall@K：正解が上位 K 件に入っていた割合（@1 なら1位的中率）
- nDCG@10：正解が上位の何位に来たかを重み付けして評価（上位ほど高得点。0〜1）
ゼロショット画像分類 → Top-1 Accuracy
画像ベクトルと「カテゴリ名のテキスト」ベクトルを比べ、一番近いカテゴリを予測。正解率（Top-1 = 1位の的中率）。

いずれも 数値が高いほど良い、と覚えれば十分です。

2.5 公平な「比較」の仕方（ここが一番大事）

複数モデルを比べるとき、全モデルをまったく同じ条件で測らないと比較になりません。特に：

同じデータ・同じ件数で測る：片方だけ問題数を減らすと簡単になり不公平。
検索は「干し草の山の大きさ」を揃える：正解1件を、2,000件から探すのと90,000件から探すのでは難易度が桁違い。
画像取得の成否など外乱を揃える / 併記する：欠損が多いと精度がブレる。

本記事で gemini-embedding-2 を「参考程度」とするのは、まさにこの条件が他モデルと揃っていないためです（詳細は第6章）。

3. 評価環境

項目	内容
実行基盤	Google Colab
GPU	T4（無料枠 16GB）または L4（Colab Pro, 22GB）
方針	モデルを 1 つずつロード → 評価 → メモリ解放 → 次へ
結果保存	csvに追記

Tier B（2B〜2.5B）モデルも bf16 なら VRAM 5GB 未満で動き、T4/L4 いずれでも OOM ゼロでした。

4. 評価したモデル

Tier	モデル	種別	備考
TX-1	`cl-nagoya/ruri-v3-310m`	テキスト専用	日本語ベースライン（商用可）
IM-1	`stabilityai/japanese-stable-clip-vit-l-16`	画像CLIP	日本語特化
IM-2	`google/siglip2-base-patch16-224`	画像CLIP
IM-3	`unum-cloud/uform3-image-text-multilingual`	画像CLIP
IM-4	`BAAI/BGE-VL-base`	画像CLIP	英語主体
IM-5	`BAAI/BGE-VL-large`	画像CLIP	英語主体
TA-1	`jinaai/jina-clip-v2`	マルチモーダル	画像系は撤退（後述）
TA-1'	`jinaai/jina-embeddings-v4`	マルチモーダル	TA-1 の後継
TA-2	`nvidia/llama-nemotron-embed-vl-1b-v2`	マルチモーダル
CA-1	`gemini-embedding-2`（クラウド）	マルチモーダル	参考程度（後述）
TB-1	`Qwen/Qwen3-VL-Embedding-2B`	マルチモーダル	挑戦枠
TB-2	`BidirLM/BidirLM-Omni-2.5B-Embedding`	マルチモーダル	挑戦枠（2026/4 公開の新興）

5. 評価ベンチマーク

ID	データセット	タスク	指標
T3	JSTS（JMTEB-lite）	一般STS	Spearman
M1	JCSTS（JMedBench）	医療STS	Spearman
T1	jagovfaqs_22k（JMTEB-lite）	行政FAQ検索	nDCG@10
T2	mrtydi（JMTEB-lite）	Wikipedia検索	nDCG@10
V1	XM3600（日本語）	画像↔テキスト検索	Recall@1/5/10（両方向）
V2	Recruit JP	ゼロショット画像分類	Top-1 Acc

5.1 各データセットの中身（具体例）

「どんなデータで測っているか」がわかると結果の意味も掴めます。各データセットの実際の中身は次のとおりです。

T3 JSTS（一般STS）：日常文の2文ペア＋人間の類似度スコア。
例：文1=「猫が寝ている」 / 文2=「ねこが眠っている」 / score=4.4（0〜5）。1,457ペア。
M1 JCSTS（医療STS）：臨床・医療文の2文ペア＋類似度。列は premise（文1）/hypothesis（文2）/label（0〜5の正解スコア）。3,500ペア。
※ n_label は注釈者数（常に6）でスコアではない、という罠あり（第7章）。
T1 jagovfaqs_22k（行政FAQ検索）：日本の官公庁サイトの FAQ。query（質問文）に対し、コーパス（docid+回答テキスト 22,794件）から正解の回答を当てる。
例：質問「パスポートの更新に必要な書類は？」→ 正解FAQ本文を検索。
T2 mrtydi（Wikipedia検索）：日本語 Wikipedia から作られた質問→該当記事段落の検索。コーパス 93,382件と大規模で長文。本記事で最も難しい検索タスク。
V1 XM3600（日本語クロスモーダル）：世界中で撮られた画像3,600枚＋人手の日本語キャプション。画像↔キャプションが1対1対応。「画像→キャプション」「キャプション→画像」の双方向で検索。
V2 Recruit JP（画像分類）：日本の食べ物・花・施設・ランドマークの画像（jafood101 等、計161カテゴリ）。画像本体はURL から都度ダウンロードする方式（→ URL 失効でブレやすい、第7章）。

6. ⚠️ Gemini Embedding 2（CA-1）の扱いについて（重要）

本記事の CA-1（gemini-embedding-2）の数値はすべて「参考程度」です。 他モデルと同条件ではありません。

T1 / T2：他モデルはフルコーパス（22,794 / 93,382 件）。CA-1 は クエリ200件 / コーパス2,000件の小サブセット。さらにコーパスを縮小したため正解文書がほぼ候補外（qrels 15/200）で、評価として成立していません。
V1（画像↔テキスト）：実装上の制約でクロスモーダルがほぼランダム（R@1≈0.008）。
V2（画像分類）：先頭100件・少数クラスのみで Acc=1.0 となるバイアス値。
T3 / M1 のみ はフル件数（1,457 / 3,500）で他モデルと比較可能です。

7. ハマりどころ（落とし穴）

実機で踏んだ罠です。これから日本語マルチモーダル評価をやる人の参考に。

プレフィックス必須モデル：ruri は クエリ: / 文章: （STS はなし）。付け忘れると検索精度が激落ち。
CLIP 系のテキスト 64〜77 トークン制限：日本語キャプションが超過して RuntimeError。手動トークナイズで truncation 必須。
JCSTS の列取り違え：['sample_id','premise','hypothesis','label','n_label',...]。安易な列名検出だと sample_id を文として埋め込み Spearman≈0.07 の偽値に。正しくは premise/hypothesis と label(0〜5)。n_label は注釈者数(定数6)で STS スコアではない。
XM3600 のキャプション列：floschne/xm3600 の先頭列は image_locale（言語コード）。captions 列を名前で直接指定しないと全モデル Recall≈0。
trust_remote_code モデルは transformers バージョン依存が激しい：jina-clip-v2 は新しい transformers の loader と多重非互換 → 互換パッチを当てるほど別箇所が壊れる負のスパイラルに陥り、画像系は撤退（テキスト系のみ採用）。後継の jina-embeddings-v4 に乗り換えて解決。
Gemini のクロスモーダル非対称：テキスト側だけ命令文字列を前置し画像側は生バイト、にすると共有空間がズレてクロスモーダルがほぼランダムに。両側を素の入力に揃える必要あり（修正済み・本評価には未反映）。
Recruit JP の画像 URL 失効：実行時刻依存で失敗率が 1.5%〜98% と激変。モデル間比較は評価枚数併記が必須。
persistent=False バッファ × accelerate meta init：from_pretrained 後に再計算しないと NaN/inf 化（jina-clip-v2 の rope で発生）。

8. ベンチマーク結果

8.1 日本語テキスト / STS

Tier	モデル	T3 JSTS (Spearman)	M1 JCSTS (Spearman)	T1 jagovfaqs (nDCG@10)	T2 mrtydi (nDCG@10)
CA-1	gemini-embedding-2 ※参考	0.8735	0.8554	(0.8708)※小	(0.6087)※小
TX-1	ruri-v3-310m（テキスト専用）	0.8359	0.8435	0.7609	0.4655
TA-1	jina-clip-v2（テキストのみ採用）	0.7846	0.8297	0.6784	0.3997
TA-1'	jina-embeddings-v4	0.8439	0.8002	0.6964	0.4671
TA-2	llama-nemotron-embed-vl-1b	0.7672	0.8211	0.7111	0.4930
TB-1	Qwen3-VL-Embedding-2B	0.8123	0.8526	0.6653	0.2992
TB-2	BidirLM-Omni-2.5B	0.8412	0.8415	0.7285	0.4524

※参考/※小：CA-1 は小規模データ。T3/M1 のみ比較可、T1/T2 は参考外。
テキスト検索（T1/T2）はテキスト寄りモデルが強い：T1 は TB-2（0.7285）、T2 は TA-2（0.4930）。
VL 系（Qwen3-VL / BidirLM）は T2 mrtydi（Wikipedia 長文検索）が共通弱点。特に Qwen3-VL は 0.2992 と顕著に低い。長文 dense retrieval はテキスト特化が依然有利。
医療STS（M1）はローカルでも高水準：TB-1 0.8526 / TB-2 0.8415 / ruri 0.8435。CA-1（0.8554・フル）に肉薄。

8.2 クロスモーダル検索（V1 XM3600・両方向 Recall）

Tier	モデル	i2t R@1	i2t R@5	i2t R@10	t2i R@1	t2i R@5	t2i R@10
IM-1	japanese-stable-clip	0.6792	0.8933	0.9400	0.6614	0.8897	0.9367
IM-2	siglip2-base	0.4450	0.6933	0.7833	0.3708	0.6258	0.7186
IM-3	uform3-multilingual	0.0378	0.0606	0.0753	0.0389	0.0736	0.0986
IM-4	BGE-VL-base	0.0344	0.0956	0.1361	0.0206	0.0592	0.0972
IM-5	BGE-VL-large	0.0442	0.1111	0.1628	0.0197	0.0633	0.0989
TA-1'	jina-embeddings-v4	0.6131	0.8400	0.8989	0.7236	0.9108	0.9517
TA-2	llama-nemotron-vl-1b	0.4278	0.6747	0.7575	0.5528	0.8031	0.8664
TB-1	Qwen3-VL-Embedding-2B	0.7169	0.9100	0.9489	0.7133	0.9094	0.9478
TB-2	BidirLM-Omni-2.5B	0.6936	0.8975	0.9436	0.7425	0.9231	0.9572

i2t（画像→テキスト）最高は TB-1 Qwen3-VL（R@1=0.7169）。
t2i（テキスト→画像）全 K 最高は TB-2 BidirLM。
画像専用なら IM-1 japanese-stable-clip が軽量で高水準。
IM-3/4/5 はほぼランダム（日本語クロスモーダルが機能していない）。
CA-1 gemini はクロスモーダルがほぼ 0（実装制約・参考外）。TA-1 jina-clip-v2 は画像系撤退で欠測。

8.3 ゼロショット画像分類（V2 Recruit JP）

Tier	モデル	Top-1 Acc	URL失敗率	評価枚数
CA-1	gemini-embedding-2 ※参考	(1.000)	—	97（バイアス・参考外）
IM-1	japanese-stable-clip	0.6552	80%	1,482
IM-3	uform3	0.1364	80%	—
IM-4	BGE-VL-base	0.1337	70%	—
IM-5	BGE-VL-large	0.4379	87%	—
TA-1'	jina-embeddings-v4	0.3504	36%	5,622
TA-2	llama-nemotron-vl-1b	0.5814	98%	129（信頼性低）
TB-1	Qwen3-VL-Embedding-2B	0.5311	15%	6,496（信頼可）
TB-2	BidirLM-Omni-2.5B	0.4278	1.5%	7,537（最良）

URL 生存率が実行時刻で激変するため、精度は 評価枚数とセットで読む必要があります。信頼できるのは TB-1（6,496枚）と TB-2（7,537枚）。

8.4 リソース（VRAM ピーク）

Tier	モデル	パラメータ	VRAM ピーク
TA-2	llama-nemotron-vl-1b	1.68B	3.14 GB
TB-1	Qwen3-VL-Embedding-2B	2.13B	3.96 GB
TB-2	BidirLM-Omni-2.5B	2.45B	4.56 GB
TX-1	ruri-v3-310m	315M	11.49 GB（T2 フルコーパス時）
TA-1'	jina-embeddings-v4	4B	15.10 GB

Tier B でも bf16 なら 5GB 未満。T4（16GB）でも十分動くのは大きな発見。

8.5 サイズ効率（パラメータ数あたりの強さ）

性能は「絶対値」だけでなく モデルサイズとのバランス で見るべきです。テキスト系のローカル順位（高い順）にパラメータ数を併記すると、傾向がはっきりします。

モデル	params	T3	M1	T1	T2	所感
ruri-v3-310m	315M	3位	2位	1位	3位	桁違いに小さいのに常時上位。サイズ効率は圧倒的No.1（ただしテキスト専用）
jina-clip-v2	~865M	5位	4位	5位	5位	画像系撤退・テキストも中下位
llama-nemotron-1b	1.68B	6位	5位	3位	1位	最軽量級。T2(長文)のみ突出、T3 は最下位
Qwen3-VL-Emb-2B	2.13B	4位	1位	6位	6位	M1最高だが T2 が極端に弱い
BidirLM-Omni-2.5B	2.45B	2位	3位	2位	4位	全タスク安定して上位（穴がない）
jina-embeddings-v4	4B	1位	6位	4位	2位	最大サイズ。T3最高だが M1 最下位、コスパは低め

要点：

ruri-v3-310m（315M）が事実上の効率王。2B級と同等以上のテキスト精度を 1/7 以下のサイズで出す。テキストのみで良ければ第一候補。
サイズと精度は単純比例しない。最大の jina-v4(4B) は M1 最下位、Qwen(2.13B) は T2 最下位。「大きい＝強い」ではない。
BidirLM(2.45B) は穴がないのが価値（全タスク2〜4位）。サイズなりの安定。
llama-nemotron(1.68B) の強みは“絶対精度”ではなく“最軽量級なのに T2 長文検索で1位”という効率。T3 は最下位な点を併記すべき。

9. どれを選ぶべきか（用途別推奨）

性能の絶対値だけでなく サイズ効率 も併記します。

ローカル・マルチモーダル RAG の本命 → BidirLM-Omni-2.5B（TB-2, 2.45B）
全テキスト系で2〜4位と穴がなく、t2i クロスモーダルが本ベンチ最高、i2t も2位。VRAM 4.56GB・OOM/パッチなしで最も健全。「弱点がない」点でバランス最良。
テキスト中心・省サイズ最優先 → ruri-v3-310m（TX-1, 315M）
T1 ローカル1位・M1 2位・T3 3位を わずか 315M で達成。サイズ効率は全モデル中ダントツ。ただしテキスト専用（画像不可）なので、マルチモーダルが要るなら別途画像モデルと併用。
画像→テキスト検索を最重視 → Qwen3-VL-Embedding-2B（TB-1, 2.13B）
i2t R@1 最高・M1 ローカル最高。ただし T2 長文検索が最下位（0.2992） なので長文RAGには不向き。
長文テキスト検索が重要かつ省メモリ → llama-nemotron-embed-vl-1b（TA-2, 1.68B）
最軽量級（VRAM 3.14GB）で T2 mrtydi が全ローカル中1位。一方 T3 は最下位・M1/T1 は中位で「万能」ではない。長文検索＋省メモリという尖った用途向け。
画像専用で日本語クロスモーダルだけ → japanese-stable-clip（IM-1, ~430M）
V1 が軽量・高水準。
クラウド許容 → gemini-embedding-2（CA-1）
STS は強い（T3/M1 とも最高クラス）。ただし本評価のマルチモーダル値は参考程度（小規模データ）。採用前に自前のフル評価を推奨。

10. 残った疑問・今後の検証

gemini-embedding-2 をフル件数・正しいクロスモーダル実装で再評価。
VL 系の T2 mrtydi 弱点の原因究明（query instruction の効きか、長文 dense retrieval 構造の問題か）。
MV1（日本語医療マルチモーダル） は全モデル未実施。挑戦枠として今後。
Recruit JP の URL 失効問題：同一時刻一括再評価が理想。

まとめ

ローカルでも日本語マルチモーダル RAG は十分実用域。特に TB-2（BidirLM）/ TB-1（Qwen3-VL）は T4/L4 で動き、クロスモーダルもクラウド級。
サイズ＝強さではない。315M の ruri がテキストで上位、4B の jina-v4 が M1 最下位など、パラメータ数と精度は比例しない。用途×サイズ効率で選ぶべき。
長文テキスト検索（T2 mrtydi）は VL 系が総じて弱く、最軽量級の nemotron（1.68B）が唯一際立つ。一方その nemotron も T3 は最下位で万能ではない。
クラウド（gemini-embedding-2）の本記事の数値は小規模データの参考値。STS 以外の横並び比較には使えない点に注意してください。