なぜ埋め込みが重要か
大規模言語モデル(LLM)がどれほど優秀でも、モデルが学習していない社内文書や最新情報を扱うには外部知識を取り込む必要があります。このとき「どの文書を取り込むか」を決めるのが**検索(retrieval)**であり、現代的な検索の中核ツールが**テキスト埋め込み(text embedding)**です。
埋め込みとは、単語・文・段落といったテキストを固定長の実数ベクトルに変換することです。ある文を768次元ベクトルに変えるなら、その文の「意味」を768個の数値に圧縮して表すことになります。このベクトル空間では、意味が近い文どうしが集まり、意味が異なる文どうしは離れます。
本記事では、検索とRAGの心臓とも言えるテキスト埋め込みモデルの原理を見ていきます。対照学習という学習方法、デュアルエンコーダ構造、ハードネガティブマイニング、E5/BGE/GTEに代表される最新オープンソース系列、Matryoshka表現学習、MTEBベンチマーク、最後に再ランキングとの関係までを扱います。AIのSOTAは非常に速く変わるため、特定の順位や具体的な数値よりも、概念とアーキテクチャの原理に集中します。
意味ベクトル: 埋め込みの基本概念
ベクトル空間における意味
従来のテキスト表現であるTF-IDFやBM25は単語の出現頻度に基づきます。この方式では「子犬」と「犬」のように表記が異なるが意味が同じ語を結び付けられません。これを語彙不一致(lexical mismatch)問題と呼びます。
一方、密な埋め込み(dense embedding)は意味をベクトルで表すため、表記が違っても意味が近ければベクトルも近くなります。次のような関係をベクトル空間で捉えられます。
"子犬が公園で走る" ---- 近い ---- "犬が外で遊ぶ"
| |
遠い 遠い
| |
"利上げが株式に与える影響" --------------------
類似度の測定
2つの埋め込みベクトルがどれだけ近いかは、通常コサイン類似度(cosine similarity)で測ります。これは2ベクトル間の角度のコサインで、方向が同じほど1に近く、逆ほど-1に近づきます。
コサイン類似度(a, b) = dot(a, b) / (norm(a) * norm(b))
- 範囲: -1 (正反対) ~ 1 (同方向)
- 多くの埋め込みモデルは正規化ベクトルを出力するため、
コサイン類似度は内積(dot product)と等しくなります。
検索システムは質問(query)を埋め込んだベクトルと、あらかじめ埋め込んで保存した文書ベクトルとの類似度を計算し、最も近い文書を見つけます。これを最近傍探索(nearest neighbor search)と呼びます。文書数が多い場合は近似最近傍(ANN)アルゴリズムとベクトルデータベースを使って高速に検索します。
対照学習: 埋め込みを学習する方法
対照学習の直観
良い埋め込みを作るには、「近いべきものは近く、遠いべきものは遠く」配置するようモデルを学習させる必要があります。その代表的手法が**対照学習(contrastive learning)**です。
対照学習の基本単位は三角関係です。基準となるアンカー(anchor)、アンカーと意味が通じる正例(positive)、そしてアンカーと無関係な負例(negative)です。
アンカー (質問)
/ \
引き寄せて近く 押して遠く
/ \
正例 (正解文書) 負例 (無関係な文書)
学習が進むと、アンカーと正例のベクトルは引き合って近づき、アンカーと負例のベクトルは反発して離れます。これを膨大なデータで繰り返すと、意味構造をよく反映するベクトル空間が形成されます。
InfoNCE損失関数
対照学習で最も広く使われる損失関数がInfoNCEです。NCEはNoise Contrastive Estimationの略で、1つの正例と複数の負例から正例を選び出す分類問題として学習を定義します。
InfoNCE損失 (アンカー q, 正例 p, 負例集合 N)
exp(sim(q, p) / T)
L = -log ---------------------------------------
exp(sim(q, p)/T) + sum exp(sim(q, n)/T)
n in N
- sim: 類似度 (通常は内積またはコサイン)
- T: 温度パラメータ。小さいほど分布が鋭くなる
- 分子に正例、分母に正例+全負例が入る
直観的には、この損失は「正例との類似度を高め、負例との類似度を下げよ」という信号を与えます。ソフトマックス形式なので、正例が負例より相対的にどれだけ高いかが重要です。
インバッチネガティブ
負例をどう確保するかが学習効率を左右します。最もよく使われるのがインバッチネガティブ(in-batch negatives)です。1つのバッチに複数の(質問, 正解)ペアがあるとき、ある質問から見れば、自分の正解を除く他のペアの正解はすべて負例になります。
バッチに (質問, 正解) が4組ある場合
正解1 正解2 正解3 正解4
質問1 [ 正例 負例 負例 負例 ]
質問2 [ 負例 正例 負例 負例 ]
質問3 [ 負例 負例 正例 負例 ]
質問4 [ 負例 負例 負例 正例 ]
対角線は正例、残りは負例として一度に学習
この方式は追加データなしでバッチサイズに比例する負例を無料で得られ効率的です。そのため埋め込み学習では大きなバッチサイズが性能に有利な傾向があると言われています。
デュアルエンコーダ構造
デュアルエンコーダとは
検索用の埋め込みモデルはほとんどが**デュアルエンコーダ(dual encoder, bi-encoder)**構造を使います。質問と文書をそれぞれ独立に符号化してベクトルにし、その2つのベクトルの類似度だけで関連性を判断します。
質問 文書
| |
[エンコーダ A] [エンコーダ B]
| |
質問ベクトル 文書ベクトル
\ /
\-- 類似度計算 -----/
|
関連性スコア
要点は、質問と文書が互いを見ずにそれぞれベクトルになる点です。おかげで文書ベクトルを事前計算して保存でき、検索時には質問だけを符号化すればよくなります。この事前計算可能性が大規模検索を実用的にする決定的特徴です。
多くの場合、エンコーダAとBは重みを共有します。つまり1つのエンコーダで質問も文書も符号化します。ただし「これは質問だ」「これは文書だ」と伝えるプレフィックス(指示文)を付けて役割を区別することもあります。E5系列が「query:」と「passage:」の接頭辞を使うのが代表例です。
クロスエンコーダとの対比
デュアルエンコーダとよく比較されるのがクロスエンコーダ(cross-encoder)です。クロスエンコーダは質問と文書を1つに連結してエンコーダに入れ、両者の相互作用をアテンションで直接計算します。
[質問 + [SEP] + 文書] → [エンコーダ] → 単一の関連性スコア
クロスエンコーダは質問と文書を一緒に見るため精度が高い一方、文書ごとに質問と組んで毎回計算する必要があり、事前計算ができず遅くなります。そのためクロスエンコーダは通常、再ランキング段階に使われ、一次検索はデュアルエンコーダが担う役割分担が一般的です。この関係は後の再ランキングの節で改めて扱います。
ハードネガティブ: 難しい負例
なぜハードネガティブが必要か
インバッチネガティブで得る負例はほとんどが質問と完全に無関係な文書で、区別が簡単です。モデルが簡単な負例ばかり繰り返し見ると、表面的には似ているが実際は正解でない微妙な文書を除く能力が伸びにくくなります。
そこであえて「紛らわしい負例」、すなわち**ハードネガティブ(hard negative)**を作って学習に入れます。ハードネガティブとは、質問と表面的には関連ありそうに見えるが正解ではない文書を指します。
質問: "Pythonでリストをソートする方法"
簡単な負例: "猫の餌のおすすめ" (全く無関係、区別容易)
ハードネガティブ: "Pythonでリストを (話題は同じだが
生成する方法" 質問の答えではない)
ハードネガティブマイニング
ハードネガティブは通常マイニング(mining)で収集します。代表的には、すでに学習済みの検索モデルで質問に対し上位文書を取り出し、そのうち正解でない上位文書をハードネガティブとして採ります。こうして集めたハードネガティブを再び学習に入れると、モデルはより微細な差を区別するようになります。
ただしマイニングした文書には、ラベルが付いていないだけで実は正解の場合(false negative)が混じることがあります。これを誤って負例として学習すると性能が悪化するため、上位数件は除外するなどのフィルタリングが必要です。
学習データと学習段階
データの種類
埋め込みモデルの性能は学習データの量と多様性に大きく左右されます。よく使われるデータの形は次のとおりです。
- クエリ-文書ペア: 検索ログ、QAデータセット等から得た(質問, 関連文書)ペア
- 自然言語推論(NLI)データ: 含意/矛盾関係で正例と負例を定義
- 文ペア類似度データ: 人が付けた類似度スコアのある文ペア
- ウェブ上で自然に対になったデータ: タイトル-本文、質問-回答、引用-原文など
対照事前学習と教師あり微調整
多くの最新オープンソース埋め込みモデルは2段階で学習されます。
[1段階: 大規模弱教師あり対照事前学習]
ウェブ上で自然に対になった膨大なテキストペアで
対照学習。ラベル品質は低いが量が非常に多い。
|
v
[2段階: 高品質教師あり微調整]
精選された検索/QA/NLIデータセット + ハードネガティブで
対照学習。量は少ないが品質が高い。
E5系列がこの「弱教師あり事前学習の後に教師あり微調整」の流れを明確に示した代表例として知られています。1段階で幅広い意味構造を身につけ、2段階で検索タスクに合わせて磨く構造です。
E5、BGE、GTE系列の概念
ここでは代表的なオープンソース埋め込み系列の概念を見ます。具体的なバージョン番号やベンチマーク順位は時点とバージョンで頻繁に変わるため、系列ごとのアイデアを中心に整理します。
E5系列
E5は「EmbEddings from bidirectional Encoder rEpresentations」に由来する名と言われ、前述の弱教師あり対照事前学習と教師あり微調整の2段階学習を体系的に整理した系列です。質問と文書にそれぞれ「query:」「passage:」の接頭辞を付けて役割を区別するのが特徴です。以後、多言語版や大型モデル、LLMをバックボーンとして指示文(instruction)ベースで埋め込みを作る方向にも拡張されてきました。
BGE系列
BGEはBAAI General Embeddingの略で、北京智源人工知能研究院(BAAI)が公開した埋め込み系列です。大規模対照事前学習と教師あり微調整を組み合わせ、多様な言語とタスクを幅広く支援すると言われています。特に密な埋め込みだけでなく、疎表現と多ベクトル表現を併せて扱う方向に拡張された版も公開され、複数の検索方式を1つのモデルで結合しようとする試みがありました。
GTE系列
GTEはGeneral Text Embeddingsの略で、アリババ系列が公開した埋め込みモデルです。同様に多段階の対照学習を用い、複数ドメインのデータを幅広く混ぜて汎用性を高めたと言われています。
系列比較のまとめ
| 系列 | 公開主体(既知) | 特徴の概念 | 役割接頭辞 |
| --- | --- | --- | --- |
| E5 | Microsoft研究系列 | 弱教師事前学習 + 教師あり微調整の確立 | query/passage使用 |
| BGE | BAAI | 多言語、多表現の結合拡張 | 指示文ベース変形あり |
| GTE | Alibaba系列 | 多ドメイン混合対照学習 | 指示文ベース変形あり |
上表の細部は時点とバージョンで変わりうるため、導入時は各モデルカードと公式文書の確認が望ましいです。
Matryoshka表現学習
次元切り詰めのアイデア
埋め込み次元が大きいほど表現力は上がりますが、保存コストと検索コストも一緒に増えます。ここで登場したのが**Matryoshka表現学習(Matryoshka Representation Learning, MRL)**です。名はロシアの人形マトリョーシカに由来します。
核心は、1つの大きな埋め込みを学習しつつ、前方の一部の次元だけを切って使っても意味が保たれるように学習する点です。すなわち768次元ベクトルの前256次元だけ、前128次元だけでもそれなりに良い埋め込みになるようにします。
全体の埋め込み (例: 768次元)
[####################]
|前64|
|-- 前128 --|
|---- 前256 ----|
|-------- 前512 --------|
|---------- 前768 (全体) ----------|
前から切っても各切断点が
独立して使える埋め込みになるよう学習
学習方法と利点
MRLは複数の切断点それぞれについて対照学習の損失を計算し、その和を最小化する方式で学習します。その結果、1つのモデルで複数の次元の埋め込みを同時に提供できます。
実務ではこの性質をこう活用します。まず短い次元(例: 前128次元)で大量の候補を高速に一次検索し、上位候補についてのみ全次元で精密に再計算します。保存領域と検索速度を節約しつつ精度の損失を最小化するのです。ただし次元を減らしすぎると精度が落ちるため、タスクに合った切断点を実験で見つける必要があります。
MTEBベンチマーク
MTEBとは
埋め込みモデルを互いに比較するには共通の評価基準が必要です。そのための代表的ベンチマークが**MTEB(Massive Text Embedding Benchmark)**です。MTEBは埋め込みが使われる複数のタスク種別を一堂に集めて総合的に評価します。
MTEBが含むタスク種別(代表)
- Retrieval : 検索 (質問で関連文書を探す)
- Reranking : 再ランキング
- Clustering : クラスタリング
- Classification: 分類
- STS : 文の意味類似度
- Pair Classification / Summarization など
複数タスクにまたがるスコアを総合するため、特定タスクだけに過適合したモデルが全体順位で高く出にくくなります。以後、多言語を幅広く包含する方向に拡張されてきました。
ベンチマーク解釈時の注意
MTEBのリーダーボードは有用ですが、順位を絶対視するのは危険です。いくつか注意点があります。
- 順位とスコアはバージョン、時点、評価設定で変わります。「現在1位」という表現はすぐに古くなります。
- ベンチマークのスコアと実サービスデータでの性能が常に一致するとは限りません。ドメイン特性が異なれば順位が覆ることもあります。
- モデルサイズ、埋め込み次元、推論速度、ライセンスといった実務制約も併せて見る必要があります。
したがってMTEBは候補を絞る出発点とし、最終選択は自分のデータで直接評価するのが望ましいです。
検索とRAGへの適用
RAGパイプライン内の埋め込み
RAG(Retrieval-Augmented Generation)は、検索で関連文書を見つけてLLMの入力に付け、回答を生成する構造です。埋め込みはこのうち検索段階の中核です。
[文書索引準備段階 (オフライン)]
文書 → チャンク化 → 埋め込み → ベクトルDB保存
[質問処理段階 (オンライン)]
ユーザー質問 → 質問埋め込み
→ ベクトルDBから類似文書検索(top-k)
→ (任意) 再ランキング
→ 文書 + 質問をLLMに渡す
→ 回答生成
チャンク化と埋め込み
長い文書をまるごと埋め込むと意味がぼやけるため、通常は適度な大きさのチャンク(chunk)に分けてそれぞれ埋め込みます。チャンクの大きさと重なり(overlap)をどう決めるかが検索品質に大きく影響します。大きすぎると無関係な内容まで混じり、小さすぎると文脈が切れて意味が弱まります。
またモデルごとに処理できる最大入力長が異なるため、これを超えないようチャンク化します。最近は長い文脈を支援する埋め込みモデルも増えていますが、入力が長いほど意味が薄まりうる点は依然として考慮が必要です。
ハイブリッド検索
密な埋め込みだけでは正確なキーワード一致(固有名詞、コード、数値など)に弱いことがあります。そのため密検索とBM25のような疎検索を併用するハイブリッド検索がよく活用されます。両方式のスコアを結合すると、意味検索と正確一致の長所を両取りできます。
[密検索] 意味類似度で候補A
[疎検索] キーワード一致で候補B
\ /
スコア結合(例: RRF)
|
最終候補リスト
ここでRRFはReciprocal Rank Fusionで、各検索結果の順位を逆数で合算して結合する単純で頑健な方法です。
再ランキングとの関係
先にデュアルエンコーダとクロスエンコーダを対比しました。実務の検索は2段階に分かれることが多いです。
[1段階: 検索 (デュアルエンコーダ)]
ベクトルDBからtop-k候補を高速に取得
(例: 上位100件)
|
v
[2段階: 再ランキング (クロスエンコーダ)]
100件の候補だけ精密に採点し直して順位再調整
上位数件だけをLLMに渡す (例: 上位5件)
1段階は速度が重要なので事前計算可能なデュアルエンコーダが担い、2段階は精度が重要なので質問と文書を一緒に見るクロスエンコーダが担います。こうすると全文書をクロスエンコーダで採点する費用を避けつつ、最終結果の精度を高められます。埋め込み検索と再ランキングは競合ではなく相互補完の関係です。
ベクトルデータベースと近似最近傍
なぜ近似が必要か
文書が数百万、数千万個になると、質問ベクトルとすべての文書ベクトルの類似度を逐一計算するのは遅すぎます。そこで実務では近似最近傍(ANN, Approximate Nearest Neighbor)アルゴリズムを使います。わずかな精度を譲る代わりに検索速度を数十〜数百倍に引き上げます。
[完全探索(正確)]
質問ベクトル vs 全文書ベクトルを1つずつ比較
→ 正確だが文書数に比例して遅い
[近似最近傍(ANN)]
ベクトルをあらかじめインデックス構造に整理し、
近い領域だけを選んで探索
→ わずかな取りこぼしの可能性、はるかに速い
代表的なインデックス方式
ANNインデックスには複数の方式があります。グラフベースのHNSW(Hierarchical Navigable Small World)はベクトルを多層グラフでつなぎ、近い隣をたどって高速に探索します。別の方式として、ベクトルを複数の断片に分けて圧縮する積量子化(PQ, Product Quantization)があり、メモリを大きく節約します。実務のベクトルデータベースはこうしたインデックスを内部に持ち、フィルタ条件(例: 特定の文書種別のみ)と併せた検索を支援します。
インデックスには再現率(recall)と速度、メモリのトレードオフがあります。パラメータを調整して「どれだけ速く、どれだけ正確に」をバランスよく合わせることが実務チューニングの核心です。
検索品質の評価指標
埋め込みと検索品質を定量的に評価するには指標が必要です。代表的なものを整理します。
[代表的な検索評価指標]
- Recall@k : 上位k個の中に正解が含まれる割合
- MRR : 正解が初めて現れた順位の逆数の平均
- nDCG@k : 順位の位置に重みを置いた累積利得
- MAP : 複数の正解に対する平均適合率の平均
ここでRecall@kは「正解を取りこぼしていないか」を、MRRとnDCGは「正解をどれだけ上位に配置したか」を見ます。RAGのように上位少数だけをLLMに渡す状況では、上位の順位品質(nDCG, MRR)が特に重要です。自分のデータでこうした指標を測定してモデルとパラメータを選ぶ方が、リーダーボードよりはるかに信頼できます。
自前データでの微調整
汎用の埋め込みモデルが自分のドメインで不足するなら、自前データでの微調整を検討できます。よくある手順は次のとおりです。
[自前微調整の流れ]
1. (質問, 正解文書) ペアを収集 (検索ログ、手作業ラベルなど)
2. ハードネガティブマイニング (既存モデルで上位の誤答を収集)
3. InfoNCEなどの対照学習で微調整
4. 自前の評価セットでRecall@k、nDCGを測定
5. 改善すれば配備、駄目ならデータ/設定を再調整
微調整はドメイン性能を大きく高められますが、データが少ないと過適合のリスクがあり、モデルを変えると索引を作り直す費用もあります。そのため、まずプレフィックス調整、ハイブリッド検索、再ランキングのような低コストの改善を試し、それでも不足するときに微調整へ進む順序が合理的です。
実務導入チェックリスト
埋め込みモデルを実サービスに導入する際の考慮点を整理します。
- 言語: サービス対象言語をよく支援する多言語モデルか確認します。
- ドメイン: 自分のデータで直接評価します。リーダーボード順位だけを信じません。
- 次元とコスト: 埋め込み次元が保存/検索コストに直結します。MRL支援モデルなら次元を調整してコストを節約できます。
- 接頭辞/指示文: モデルが要求する接頭辞や指示文の形式を必ず守ります。これを抜かすと性能が大きく落ちることがあります。
- 正規化: コサイン類似度を使うならベクトル正規化が必要か確認します。
- 再ランキング: 精度が重要ならクロスエンコーダの再ランカー追加を検討します。
- ライセンス: 商用利用可否とライセンスを確認します。
限界と注意点
埋め込みベースの検索にも明確な限界があります。
- ドメイン移動: 学習データと性格が異なるドメインでは性能が落ちることがあります。専門用語が多い分野ほど自己評価が重要です。
- 正確一致の弱点: 密な埋め込みは固有名詞、コード、数値などの正確一致に弱いことがあり、ハイブリッド検索が必要な場合が多いです。
- チャンク化への感度: チャンクの大きさと境界設定で結果が大きく変わります。
- 最新性: ベンチマーク順位と最新モデル情報は非常に速く変わります。本記事の系列説明も概念理解のためであり、具体スペックは公式文書で確認が必要です。
- バイアス: 学習データのバイアスが埋め込みに反映されうるため、機微な応用では検証が必要です。
まとめ
テキスト埋め込みは検索とRAGの心臓です。対照学習とInfoNCEという学習原理、デュアルエンコーダという構造、ハードネガティブという学習技法、そしてMatryoshka表現学習とハイブリッド検索、再ランキングまで — これらの要素がかみ合って現代的な意味検索を成します。
覚えておきたい核心は次のとおりです。第一に、埋め込みは意味をベクトルに圧縮したもので、対照学習で「近いべきものは近く」配置するよう学習されます。第二に、検索はデュアルエンコーダで高速に、再ランキングはクロスエンコーダで精密にする2段階構造が実用的です。第三に、モデル選択はリーダーボードでなく自分のデータで決めるべきです。AI分野のSOTAは速く変わりますが、こうした原理は長く有効です。
参考資料
- InfoNCE / Contrastive Predictive Coding (arXiv 1807.03748): [arxiv.org/abs/1807.03748](https://arxiv.org/abs/1807.03748)
- Dense Passage Retrieval (arXiv 2004.04906): [arxiv.org/abs/2004.04906](https://arxiv.org/abs/2004.04906)
- Sentence-BERT (arXiv 1908.10084): [arxiv.org/abs/1908.10084](https://arxiv.org/abs/1908.10084)
- Text Embeddings by Weakly-Supervised Contrastive Pre-training, E5 (arXiv 2212.03533): [arxiv.org/abs/2212.03533](https://arxiv.org/abs/2212.03533)
- Matryoshka Representation Learning (arXiv 2205.13147): [arxiv.org/abs/2205.13147](https://arxiv.org/abs/2205.13147)
- MTEB: Massive Text Embedding Benchmark (arXiv 2210.07316): [arxiv.org/abs/2210.07316](https://arxiv.org/abs/2210.07316)
- MTEBリーダーボード (Hugging Face): [huggingface.co/spaces/mteb/leaderboard](https://huggingface.co/spaces/mteb/leaderboard)
- BGE (FlagEmbedding) リポジトリ: [github.com/FlagOpen/FlagEmbedding](https://github.com/FlagOpen/FlagEmbedding)
- Sentence Transformers ドキュメント: [sbert.net](https://www.sbert.net)
현재 단락 (1/197)
大規模言語モデル(LLM)がどれほど優秀でも、モデルが学習していない社内文書や最新情報を扱うには外部知識を取り込む必要があります。このとき「どの文書を取り込むか」を決めるのが**検索(retrieva...