Embeddingの次元数は品質とコストの調整つまみになった

見るべき理由は「モデル選定」だけではない

X の投稿本文は直接確認できなかったが、検索結果から対象は Tomoko Uchida さんの Speaker Deck「【2026年版】ベクトル検索とEmbedding最前線」を紹介する投稿と判断できる。

資料は 2026-06-22 公開、2026-06-28 更新の日本語スライドで、LLM 以後の embedding モデル、ベクトル検索、rerank、次元削減、Matryoshka Representation Learning を広く整理している。

実務で重要なのは、embedding の評価軸が「強いモデルを選ぶ」だけではなくなっていることだ。検索品質、保存容量、インデックス構築時間、検索レイテンシ、rerank 後の品質を同じテーブルに置く必要がある。

MRL は、embedding の先頭部分だけを使っても有用な表現になるように学習する考え方である。arXiv の原論文では、固定長の表現ではなく、下流タスクの計算制約に合わせて粗い表現から細かい表現まで使い分けられることを狙っている。

Google docs は gemini-embedding-001 と gemini-embedding-2 が MRL で学習され、output_dimensionality で出力サイズを制御できると説明している。

OpenAI docs は text-embedding-3-small と text-embedding-3-large のデフォルト次元を示し、dimensions パラメータで次元数を下げられると説明している。

Google の推奨例では 768、1536、3072 次元が挙げられている。これは、ストレージや速度を理由に低次元へ寄せる選択が、API の標準的な使い方になりつつあることを示している。

次元削減は「品質劣化なしで安くなる魔法」として扱わないほうがよい。MRL 対応モデルでは小さい次元でも意味が残るように設計されているが、実際の検索品質はコーパス、言語、クエリの曖昧さ、chunking、rerank の有無で変わる。

見る指標	判断に使う理由
top-k / MRR / nDCG	次元を下げたときに検索結果の順序が崩れていないかを見る。
rerank 後の品質	初段検索の粗さを reranker が吸収できる範囲か確認する。
保存容量とインデックス時間	高次元化で運用コストがどれだけ増えるかを測る。
検索レイテンシ	ユーザー体験とバッチ処理時間に効くため、品質指標と同時に見る。

小規模 RAG なら 768 か 1536 で十分なことがある。一方で、品質差が重要なナレッジ検索や多言語検索では 3072 を基準にして差分を見るほうが安全である。

X 投稿はログインや公開状態の都合で本文を確認できなかった。そのため、この記事は X の投稿内容そのものの要約ではなく、投稿 URL から特定できた Speaker Deck と関連一次情報の確認である。

また、個別モデルで本当に MRL 由来の次元削減をサポートするかは、各ベンダーの公式 docs で確認する必要がある。資料の見立てと API の保証は分けて読む。

Source	Use
Speaker Deck: 【2026年版】ベクトル検索とEmbedding最前線	対象資料の主題、公開日、MRL と embedding モデル動向の確認。
Google AI for Developers: Gemini Embeddings	Gemini Embeddings の MRL、デフォルト 3072 次元、推奨次元、`output_dimensionality` の確認。
OpenAI Platform: Embeddings	`text-embedding-3` 系のデフォルト次元と `dimensions` パラメータの確認。
arXiv: Matryoshka Representation Learning	MRL の原論文と、粗い表現から細かい表現まで使い分ける考え方の確認。