今回の論文
今回取り上げるのは、Jianlv Chen、Shitao Xiao、Peitian Zhang、Kun Luo、Defu Lian、Zheng Liuによる論文「M3-Embedding: Multi-Linguality, Multi-Functionality, Multi-Granularity Text Embeddings Through Self-Knowledge Distillation」です。2024年2月5日にarXivで公開され、ACL 2024でも発表されました。公開元はarXiv、URLは https://arxiv.org/abs/2402.03216 、研究分野は情報検索、テキスト埋め込み、多言語NLPです。
この論文を選んだ理由は、RAGの検索品質を「埋め込みモデルを替える」だけで終わらせず、意味検索・語句一致・細粒度照合を用途に応じて組み合わせる、実装可能な設計を示しているためです。日本語を含む多言語の社内検索や、短いFAQと長い規程を同じ検索基盤で扱う際のヒントになります。
どんな技術か
M3-Embeddingは、単一のエンコーダから三種類の検索用表現を同時に作る埋め込みモデルです。三つのMは、100以上の言語を扱うMulti-Linguality、密検索・疎検索・マルチベクトル検索を扱うMulti-Functionality、短文から最大8,192トークンの長文まで扱うMulti-Granularityを意味します。
実務では、意味が近い文書を探す密検索、製品名・型番・条文番号のような語句一致に強い疎検索、候補内の細かな対応を確認する再ランキングがそれぞれ役に立ちます。従来は別モデルや別パイプラインになりがちでした。M3-Embeddingは同じ隠れ状態から三方式のスコアを出し、それらを統合することで、検索の取りこぼしと誤順位を減らそうとします。
課題
RAGの検索では、意味が似ていても固有名詞が異なる文書を見つけたい一方で、エラーコードやバージョン番号のように完全一致が重要な問い合わせもあります。密検索だけでは後者を、BM25のような語句検索だけでは前者を取り逃しやすいというトレードオフがあります。
既存の埋め込みモデルの多くは、一つの検索方式、短い入力、または英語中心のデータに最適化されています。そのため、日本語で質問して英語の技術資料を探す、数千トークンの規程を検索する、といった現実的な条件では、モデル・インデックス・運用を分ける必要がありました。
また、三方式を単純に同時学習すると、最適化の目標がぶつかります。意味空間を一つのベクトルへ圧縮したい密検索と、トークンごとの一致を残したい疎・マルチベクトル検索では、良い表現の条件が異なるからです。検索基盤を複雑にせず、この競合を抑えることが論文の中心課題です。
用語解説
- テキスト埋め込み
- 文書や質問を数値ベクトルへ変換した表現です。M3-Embeddingでは、一つのエンコーダの出力を三種類の検索スコアへ使い分けるため、どの情報を要約し、どの情報を残すかが重要になります。
- 密検索（dense retrieval）
- 質問と文書をそれぞれ一つの密なベクトルにし、内積やコサイン類似度で近いものを探す方法です。言い換えに強く、大規模コーパスから候補を高速に絞る一次検索の中心になります。
- 疎検索（sparse / lexical retrieval）
- 語・トークンごとの重みを使い、質問と文書に共通して出る語を重視する検索です。M3-Embeddingでは単なる出現回数ではなく、文脈を見たエンコーダが各トークンの重要度を学習します。
- マルチベクトル検索とlate interaction
- 文書を一ベクトルに潰さずトークンごとのベクトル群として持ち、質問トークンごとに最も近い文書トークンを選んで照合する方式です。精密ですが計算量が大きく、論文では主に候補の再ランキングに使います。
- 自己知識蒸留
- 外部の大型教師モデルではなく、三方式を重み付きで統合した自分自身の検索スコアを教師信号にする学習法です。各方式を個別に強くするだけでなく、互いの長所を伝える狙いがあります。
技術の仕組み
M3-EmbeddingはXLM-RoBERTa系のテキストエンコーダを土台にします。質問または文書を入力すると、先頭の[CLS]と各トークンの隠れ状態が出力されます。重要なのは、この一回のエンコード結果から、検索用途ごとに異なる読み出し方をする点です。
一つの隠れ状態から三つの検索器を作る
密検索では、正規化した[CLS]ベクトル同士の内積をスコアにします。これはベクトルDBで大量文書から候補を取得するのに向きます。
疎検索では、各トークンの隠れ状態を線形層に通してReLUで非負の重みへ変換します。質問と文書に共通するトークンについて、両者の重みの積を足したものがスコアです。同じトークンが複数回現れる場合は最大重みを残すため、転置インデックスに載せやすい形になります。
マルチベクトル検索では、全トークンの隠れ状態に学習可能な射影をかけて正規化します。質問の各トークンについて、文書側で最も似たトークンとの内積を取り、その平均をスコアにします。概念的には「質問の各要素に、文書内のどこかがきちんと対応しているか」を見るため、長い文書や複合質問の精密照合に役立ちます。
ハイブリッド検索の処理順
推論時は、まず密検索と疎検索で候補を広く集めます。マルチベクトル検索は高コストなので、論文のMIRACL評価では密検索上位200件の再ランキングに限定しています。最終スコアはw1 × dense + w2 × sparse + w3 × multi-vectorという重み付き和です。
重みは固定の正解ではありません。多言語の短いパッセージ検索では密検索とマルチベクトルに比較的重みを置き、長文検索では疎検索の重みを上げています。つまり「常に三方式を全力で回す」のではなく、コーパスとレイテンシ予算に合わせて段階的に使う設計です。
統合スコアを教師にする自己知識蒸留
各検索方式は、正例文書のスコアを負例より高くするInfoNCE損失で学習します。しかしこれだけでは、三方式が別々の都合で学び、特に疎検索が不安定になります。そこで論文は三スコアの統合値をsoftmaxで確率化し、それを各方式が追う蒸留損失を追加します。
この教師は外部モデルの答えではなく、異質な三方式を合わせたアンサンブルです。アブレーションでは自己知識蒸留を外すと、MIRACLのnDCG@10は密検索で69.2から68.7、マルチベクトルで70.5から69.3へ下がり、疎検索では53.9から36.7へ大きく低下しました。特性の異なる検索器を統合するなら、最終的な合議結果を各枝へ戻す考え方が有効だと分かります。
多段階学習と長文バッチ
学習データは、Wikipedia・mC4などから作る教師なしペア、既存の検索ラベル、GPT-3.5で生成した長文向け質問を組み合わせます。翻訳対を含めた教師なしデータは1.2 billionペア、194言語・2,655言語対に及びます。まず密検索として事前学習し、次に三方式と自己知識蒸留を有効にしてラベル付き・合成データで調整します。
長文ではパディングとGPUメモリがボトルネックです。そこで長さが近い例同士をバッチ化し、長い例はサブバッチに分割して勾配チェックポイントを使いながら埋め込みを集めます。論文では8,192トークン時のバッチサイズを20倍超にできたと報告しています。学習や追加適応ができない場合には、複数の[CLS]を長文へ挿入し、その平均を使うMCLSも提案しています。
実験と結果
論文は、同一言語内の多言語検索、言語横断検索、長文検索を分けて検証しました。これにより、一つの平均スコアだけでは見えない「どの検索方式が、どの文書条件で効くか」を調べています。
多言語・言語横断検索
MIRACLの18言語の開発セットで、nDCG@10を評価しました。M3-Embeddingの全方式統合は平均71.5で、強い比較対象であるmE5-largeの66.6、E5-mistral-7bの63.4を上回りました。日本語では全統合が75.2で、mE5-largeの70.6、E5-mistral-7bの66.8でした。
MKQAでは、25の非英語言語の質問から英語Wikipediaを検索し、Recall@100で評価しています。論文は、密検索だけでも強い結果を示し、三方式を組み合わせるとさらに改善したと報告します。ただし異なる言語間では共有語が少ないため、疎検索単独は相対的に弱くなりました。これは、翻訳または言語横断のRAGで「語句検索を足せば必ず良くなる」とは限らないことを示します。
長文検索では疎・精密照合が効く
多言語長文検索MLDRでは、全統合の平均nDCG@10が65.0でした。密検索単独は52.5、疎検索単独は62.2、マルチベクトルは57.6であり、長文では語句シグナルと統合の寄与が特に大きくなりました。
英語のNarrativeQA長文検索でも、全統合は61.7で、text-embedding-3-largeの51.6、E5-mistral-7bの49.9を上回りました。さらに長文ファインチューニングを除いた密検索は41.2でしたが、学習不要のMCLSで45.0へ改善しています。長文対応は単に入力上限を伸ばすだけでなく、長文をどう表現・照合するかを学習または推論時の工夫で補う必要があります。
何に使える？
M3-Embeddingの考え方は、検索方式を一つに決めてしまうより、問い合わせの性質に応じて候補生成と精密照合を分離するRAGに使えます。
多言語の社内ナレッジ検索
日本語の問い合わせに対し、日本語マニュアルだけでなく英語の仕様書や海外拠点のFAQも検索したい場合に向きます。まず密検索を軸に言語をまたいで候補を拾い、同言語の候補には疎検索も加えると、製品名・エラー番号・規格名を保ちやすくなります。言語ごとに別の検索器を育てる運用負担を減らせる可能性があります。
契約・規程・技術文書のRAG
長い文書では、一つのベクトルに要約すると例外条件や特定の条文を失いやすくなります。密検索で候補章を集め、疎検索で条文番号・固有語を効かせ、マルチベクトルで質問の複数条件を照合する三段構えは、規程検索や障害対応ナレッジで使いやすい構成です。
検索品質の段階的な改善
小規模なサービスでは、最初からマルチベクトル用の大きなインデックスを持つ必要はありません。密検索だけをベースラインにし、固有名詞の失敗が多ければ疎検索を併用し、上位候補の順位が悪ければ再ランキングを追加します。各段階の失敗ログを見て投資することで、計算コストを抑えながら改善できます。
開発や事業へのヒント
この論文の要点は、「埋め込みモデルは一つのベクトルを返すもの」という前提を外すことです。同じ文書表現から複数の検索観点を作れるなら、プロダクト側は検索方式を競合させるのでなく、役割分担させられます。
検索方式ではなく失敗タイプで設計する
問い合わせを、言い換え・固有名詞・複数条件・長文参照・言語横断に分類して、検索ログで失敗率を見ます。言い換えの失敗には密検索、型番の失敗には疎検索、複合条件の誤順位にはマルチベクトル再ランキングというように、技術を失敗タイプへ対応させると採用判断が具体化します。
ハイブリッドの重みを設定値として運用する
論文でも検索データセットごとに重みを変えています。プロダクトではdense_weight、sparse_weight、rerank_top_kをコードへ埋め込まず、評価セットと一緒にバージョン管理するのが有効です。長文の契約検索と短いFAQ検索に同じ重みを強制しないだけでも、RAGの改善余地が生まれます。
学習しない改善から始める
論文のMCLSは、長文をより細かな位置の[CLS]で読み、平均する推論時の工夫です。全く同じ実装が使えない場合でも、長文を意味の切れ目で複数チャンクへ分け、文書単位で候補スコアを集約する発想へ応用できます。追加学習が難しい小規模プロダクトでも、評価を取りながら試しやすい改善です。
限界
マルチベクトル検索はトークン同士を照合するため、密検索よりインデックス容量と再ランキング計算が重くなります。論文も一次検索ではなく上位候補への利用を前提にしています。低レイテンシや大量同時アクセスのサービスでは、候補数・キャッシュ・GPUの設計が必要です。
疎検索の性能は語の共有に依存します。言語横断検索では質問と文書が異なる言語なので、論文でも疎検索単独は相対的に弱くなりました。また、日本語のトークン化、社内略語、型番表記ゆれは独自データで検証しなければなりません。
評価はMIRACL、MKQA、MLDR、NarrativeQAを中心にしており、実際の社内文書の更新頻度、アクセス権、表・PDFのレイアウト、専門語には直接答えていません。学習データは大規模で、独自に同水準のモデルを訓練するコストも高いです。モデルを導入する際は、代表質問で密・疎・統合の比較を行い、平均値だけでなく重要な取りこぼしを確認する必要があります。
よくある質問
Q. M3-EmbeddingはベクトルDBだけで使えますか？
A. 密検索だけならベクトルDBで使えます。ただし論文の強みである疎検索には転置インデックス、マルチベクトルにはトークン単位の照合または対応した再ランキングが必要です。まず密検索を動かし、失敗分析に応じて他の枝を加えるのが現実的です。
Q. 日本語RAGでは疎検索を必ず足すべきですか？
A. 必ずではありません。型番、商品名、条文番号のような文字列が重要なら有効ですが、言い換え中心の質問や日英横断検索では密検索の寄与が大きくなります。論文でも言語横断では共有語が少なく、疎検索単独は弱い結果でした。自分の質問ログで比較してください。
Q. マルチベクトル検索はなぜ一次検索に使わないのですか？
A. 質問の各トークンと文書の各トークンを細かく比較するため、大規模コーパス全体へ実行すると高コストになります。論文では密検索で上位200件に絞ってから再ランキングしています。候補生成は速い方式、精密照合は狭い候補へ使う分業が基本です。
Q. 自己知識蒸留は外部の教師モデルを用意しなくても使えますか？
A. 論文の方法では不要です。密・疎・マルチベクトルの統合スコアを教師として各枝へ戻します。ただし三枝を学習させるデータ、ハードネガティブ、損失の重み付けは必要なので、独自訓練は通常の埋め込み微調整より複雑です。
Q. 長文を8,192トークンで丸ごと埋め込めばRAGのチャンク分割は不要ですか？
A. 不要にはなりません。入力上限が長くても、検索精度・インデックス容量・回答時に渡す根拠の粒度は別問題です。文書単位の検索で候補を絞った後に、節や段落へ再分割してLLMへ渡す二段階設計を、評価セットで比較するのが安全です。
今日の学び
この論文は、多言語・長文のRAGで、意味検索、語句検索、細粒度照合を一つの埋め込みモデルで両立させにくい課題を扱いました。M3-Embeddingは同じエンコーダ出力から三つの検索スコアを作り、統合スコアを教師にする自己知識蒸留で、それぞれを協調学習させます。
得られるヒントは、検索を一方式で完結させず、速い候補生成と精密な再ランキングを役割分担させることです。特に多言語・長文・固有名詞が混ざるRAGでは、失敗タイプごとに密・疎・マルチベクトルを使い分ける設計が、品質とコストの両方を改善する入口になります。