今回の論文
今回取り上げるのは、MicrosoftのLiang Wang、Nan Yang、Xiaolong Huang、Binxing Jiao、Linjun Yang、Daxin Jiang、Rangan Majumder、Furu Weiによる「Text Embeddings by Weakly-Supervised Contrastive Pre-training」です。2022年12月7日にarXivで初公開されました。研究分野は、テキスト表現学習と情報検索です。論文ページと論文本文（2024年改訂のv2）が公開されており、この記事の技術・実験の説明はv2に基づきます。
選んだ理由は、検索用ベクトルの性能を「モデルの大きさ」だけでなく「どんな文章同士を関連付けて学ばせるか」から理解できるためです。RAGの検索部分を改善したい開発者にも、社内に蓄積された質問と回答を学習データへ変えたい開発者にも、応用しやすい考え方があります。
どんな技術か
E5は、文章を一つの固定長ベクトルへ変換するテキスト埋め込みモデルの系列です。質問と、その答えを含む文章が近いベクトルになるように学習します。検索時にはベクトル同士を比較するため、同じ単語が書かれていなくても、意味の対応を手掛かりに候補を探せます。
たとえば「サインインできません」という質問から、「認証エラーが発生したときの復旧手順」を探す場面です。単語の一致だけでは拾いにくい組み合わせを、学習した表現で結び付けることが狙いです。この例は説明用であり、論文の個別の実験結果ではありません。
中心となるのは、Web上で自然に対応している文章ペアを集め、品質を選別して対照学習する設計です。E5自体は回答文を生成しません。RAGでは、回答用LLMへ渡す資料を探す役割を担当できます。論文本文、3・4節
課題
文章検索には、表現の違いと関連性の違いを扱う難しさがあります。質問の言い換えを探す場合と、質問の答えを探す場合では、欲しい文章が異なります。「退会方法を教えてください」の言い換えだけを返しても、手順の検索には役立ちません。
単語の頻度や希少性を使うBM25は、名称や専門用語が一致する検索に強い一方、表現の違う質問と説明を結び付けるには限界があります。逆に、通常の言語モデルの隠れ状態を平均しただけでは、文章全体の検索に適した距離が得られるとは限りません。単語予測を学ぶことと、関連資料を上位へ並べることは別の目標だからです。
検索用モデルを学ぶために、人手で大量の質問と正解文書を対応付けるのは高コストです。しかし、文章をランダムに切り出して正例にするだけでは、学習の対応関係が本当の検索意図とずれることがあります。E5は、既存データに含まれる対応を利用しながら、そのノイズを減らす方向でこの課題に取り組みます。
実際のRAGでは、検索が外すと回答用モデルへ根拠が届きません。生成モデルの変更だけでなく、検索表現と学習ペアの品質を改善する必要があります。論文本文、1・3節
用語解説
- テキスト埋め込み
- 文章を固定長の数値ベクトルで表現することです。E5では、このベクトルが関連性を表すように学習します。文章を保存時に変換しておけば、検索時に全文をモデルへ読み直す必要がありません。
- 弱教師あり学習
- 人手で厳密に付けた正解の代わりに、質問と回答、タイトルと本文などの構造を学習の手掛かりにする方法です。E5では大量のペアを得られる反面、対応が弱い例も混ざるため、選別が重要になります。
- 対照学習とバッチ内負例
- 対応する文章を近づけ、対応しない文章から区別できるようにする学習です。E5の事前学習では、同じバッチの別ペアに含まれる本文を負例にします。バッチを大きくすると、比較対象も増えます。
- バイエンコーダとクロスエンコーダ
- バイエンコーダは質問と本文を別々にベクトル化し、後から比較します。クロスエンコーダは両方を一緒に読んで関連度を判定します。E5は前者で効率的に検索し、追加学習では後者の評価を教師として利用します。
- nDCG@10
- 上位10件の検索結果で、関連性の高い文書がどれだけ上位に置かれたかを評価する指標です。正しい文書が候補に入るだけでなく、先に見つかることが評価されるため、検索画面やRAGの候補選びと関係します。
技術の仕組み
自然な文章の対応を集め、選別します
事前学習用データのCCPairsには、質問と回答、Webページのタイトルと本文、論文のタイトルと要旨など、異なる種類の文章ペアを集めます。一つの情報源だけに偏らず、異なる対応関係を学ぶことが目的です。
初期のフィルタリング後には約13億ペアあります。さらに、このデータで一度学習したモデルを使い、各ペアの本文を約100万件のランダムな本文候補と比較します。元の対応本文が上位2件に入るペアを残し、約2.7億ペアへ絞ります。
これは、人手で付けた正解との照合ではなく、元の対応がモデルから見ても強いかを確かめる処理です。たとえばタイトルに関係のない定型文が本文として抽出されていれば、選別で落とせる可能性があります。一方、モデルが苦手とする珍しい正例まで除外する可能性は残ります。論文本文、3節
同じエンコーダへ、入力の役割を伝えます
質問と本文には、パラメータを共有するTransformerエンコーダを使います。出力層のトークン表現を平均して、文章全体のベクトルを作ります。二つの文章を一緒に読む必要がないため、登録文書側は事前計算できます。
同じモデルでも、質問側にはquery:、本文側にはpassage:という接頭辞を付けます。これによって、短い検索要求と、その要求に答える資料という役割を区別します。単に似た言い回しを探すだけでなく、答えを探すための非対称性を入力へ与える工夫です。
接頭辞は検索システムが後で付けるメタデータではなく、エンコーダに渡す文字列の一部です。省略すると学習時と条件が変わります。なお、文章の類似度比較やクラスタリングなど、両側の役割が対称な用途では、著者のモデルカードは両側へquery:を使う方針を示しています。論文本文、4.1節、著者のモデルカード
正しい本文を、他の候補より高く評価させます
学習では質問と本文のコサイン類似度を温度パラメータで割ったスコアを使い、InfoNCE損失で正例と負例を区別します。直感的には、「正しい本文のスコアが、比較候補全体の中で十分に高いか」を学びます。
正例だけを近づけると、どの文章も同じベクトルに寄せてしまうことがあります。負例との比較があることで、関連する文章を近づけつつ、無関係な文章を区別できます。事前学習のバッチサイズは32,768で、比較できる負例を多く確保しています。
必要なら教師付きデータで調整します
論文では、事前学習だけのモデルをE5-PTと呼び、さらにMS MARCO、Natural Questions、自然言語推論データで追加学習したモデルと区別しています。検索データでは、紛らわしい候補であるハードネガティブと、クロスエンコーダの教師スコアを使います。
関連・非関連の正解ラベルに加え、教師モデルが候補間に付けた相対的な評価も学習します。細かい関連性の判定を、全文の組み合わせを毎回読む教師から、別々にベクトル化するモデルへ移す考え方です。論文本文、4節
推論時には、本文をpassage:付きでベクトル化してインデックスへ登録し、質問をquery:付きで変換します。近い本文を検索して上位候補を返します。必要に応じて、少数の候補だけを別の再順位付けモデルで精査する構成にもできます。
実験と結果
検索の平均性能と、用途ごとの差を確認しています
BEIRの公開取得可能な15データセットで、nDCG@10を評価しています。表のスコアは0〜100の尺度です。
| 条件 | 平均nDCG@10 |
|---|---|
| BM25 | 41.7 |
| E5-PT base：対照事前学習のみ | 42.9 |
| E5-PT large：対照事前学習のみ | 44.2 |
| E5 base：教師付き追加学習あり | 48.7 |
事前学習だけのbaseモデルでも、平均でBM25を1.2ポイント上回りました。ただし、全データセットで勝ったわけではありません。たとえばHotpotQAではBM25が60.3、E5-PT baseが52.4です。検索対象の種類によって、単語一致が有効な場合も残ります。
追加学習後の48.7という平均には、学習に使ったMS MARCOとNatural Questionsの評価も含まれます。すべてが未学習の分野への転移結果という意味ではありません。またFiQAでは、baseモデルが40.0から36.4へ低下しており、追加学習はあらゆる分野を一様に改善するものではありません。論文本文、表1・2
データを増やすだけでなく、品質を変える効果があります
フィルタリングの比較では、baseモデルと6データセットの検索評価を使っています。100万ペアで学習する条件では、未選別データの平均34.9に対し、選別済みデータは40.7でした。
全データを使う条件でも、未選別の方が約4倍のペア数を持ちながら平均50.0、選別後は51.6です。これは15データセットの平均と別の実験なので、上の表と直接比較してはいけません。ペアの量だけでなく、対応関係の確かさを改善する価値を示す結果です。論文本文、表7
MTEBでは英語の56データセットを評価し、教師付き追加学習後のE5 baseの平均は60.4、事前学習のみでは55.6でした。分類、クラスタリング、検索、意味的類似度などを含むため、この平均値は検索の正答率ではありません。各用途に転用できる表現かを広く確認した評価です。これらは論文当時の比較結果であり、現在のモデル順位を示すものではありません。論文本文、表3
何に使える？
以下は仕組みと評価を踏まえた応用案です。論文がこれらの業務システムを個別に実証したという意味ではありません。
RAGで、質問の表現と異なる説明を探します
利用者の質問とマニュアルの説明文を別々にベクトル化し、根拠候補を選ぶ用途です。文書ベクトルを先に保存できるため、問い合わせのたびに全資料をモデルへ入力せずに済みます。文書ID、更新日、権限を検索結果へ付けておけば、回答用LLMへ渡す際の根拠管理にもつながります。
問い合わせの分類と重複候補の発見に使います
問い合わせ文をベクトル化し、少数のラベル付き例で分類器を学習する構成が考えられます。似た文章をまとめる処理にも利用でき、サポート担当者が共通の問題を発見する補助になります。
ただし、近い文章でも対象製品や発生時期が違う場合があります。ベクトルの近さだけで問い合わせを自動統合せず、属性と内容を合わせて確認する設計が必要です。
過去の対応記録から、解決策の候補を探します
障害の説明を質問側、解決した記録を本文側として比較する用途です。「似た報告」だけでなく「対応に役立つ記録」を探すという、queryとpassageの役割を活かせます。候補の抽出は自動化し、実行する手順の採否はログやシステム状態との照合で判断します。
開発や事業へのヒント
埋め込みの導入と、検索の改善を分けて測ります
小規模なプロダクトなら、まず学習済みモデルと少量の正解付き検索質問で試せます。代表的な質問ごとに、必要な根拠が上位5件や10件に入るかを確認します。回答用LLMの文章の良さと、根拠の検索成否を別々に記録すると、改善すべき箇所が見えます。
型番やエラーコードを含む質問では、BM25などの単語検索も比較します。論文でBM25が勝つデータセットがあることからも、ベクトル検索への全面置き換えを前提にする必要はありません。両方の候補を統合する設計は応用上の選択肢ですが、その効果は自社データで検証します。
蓄積した質問・回答を、いきなり全部学習に使わないようにします
E5から得られる実践的なヒントは、ペアの品質を開発対象にすることです。サポートの返信に挨拶だけが含まれる例、別件の回答が付いた例、古い仕様に基づく例を、良質な対応例と混ぜると目標が曖昧になります。
小規模な開発では、論文と同じ100万候補の選別を再現するより、既存モデルの順位を確認材料として使い、少量のペアを人手で点検するところから始められます。低スコアの例を全部捨てるのではなく、珍しいが重要な質問と、本当に誤った対応を見分けることが大切です。
検索と分類で、最適な調整データが違うことを意識します
同じ埋め込みでも、欲しいのが「回答を含む文書」なのか、「意味の似た文章」なのかで学習目標が変わります。論文の追加学習では、検索用データと自然言語推論データの効果が用途によって異なりました。
検索サービスを調整するなら検索の評価を、問い合わせ分類なら分類の評価を優先します。汎用ベンチマークの平均だけで採用を決めず、自社の用途で改善したかを確認する方針が、論文の結果から得られます。論文本文、表6
限界
事前学習の再現には、大量のペアの収集・選別と大きなバッチの学習が必要です。論文のbaseモデルは32台のV100で約1日、largeモデルは64台で約2日の事前学習を行っています。これは論文の条件であり、データ準備と選別を含めた開発期間や、別環境の費用を示す数字ではありません。小規模な開発では、事前学習を再現することと学習済みモデルを利用することを分けて考えます。論文本文、5.1節
元のE5の実験は英語中心です。公開されているintfloat/e5-base-v2も、モデルカードでは英語専用・最大512トークンとされています。日本語で使う場合は、対応言語を持つ別のチェックポイントを選び、そのモデル固有の評価を確認してください。この論文の英語スコアから、日本語の業務検索精度は判断できません。著者のモデルカード
長い文書を一つのベクトルへ圧縮すると、細かな条件や数値の違いが失われる可能性があります。入力上限を超えた部分は切り捨てられるので、文書分割とタイトル・見出しの付与を設計する必要があります。モデルを変更した場合には、文書側のベクトルを再計算し、インデックスの互換性も確認します。
弱教師の選別にも誤りがあります。質問と回答が対応していることは、回答が事実として正しいことを保証しません。また、バッチ内の別本文が実際には正しい回答であると、誤った負例になります。検索スコアも正答確率ではなく、採否の閾値は対象データで評価する必要があります。
よくある質問
Q. E5はRAGの回答を生成するモデルですか？
A. 文章を検索用ベクトルへ変換するモデルです。質問から根拠候補を探し、その結果を別のLLMへ渡す構成にできます。検索で候補に入ったことと、回答内容が正しいことは分けて確認します。
Q. query:とpassage:は、必ず付ける必要がありますか？
A. 対応するE5モデルでは、学習時と同じ接頭辞を使います。質問から本文を検索する場合はそれぞれquery:とpassage:です。類似文の比較など対称な用途では、モデルカードに従って両側にquery:を使います。
Q. 日本語の社内検索へ、そのまま導入できますか？
A. 元の英語E5や英語専用のbase-v2を、そのまま日本語向けの性能保証として扱うことはできません。日本語を扱えるモデルを選び、略語、固有名詞、実際の質問文で検索評価を行います。本文の実験数字は英語中心の結果です。
Q. 学習データは、多いほどよいのでしょうか？
A. この論文では、約4倍の未選別データより、選別後のデータで学習した方が6データセットの平均検索スコアが高くなりました。量を増やす前に、質問と本文が目的に合った対応になっているかを点検する価値があります。
Q. コサイン類似度が高ければ、回答根拠として採用できますか？
A. 高い値だけでは十分ではありません。内容が関連していても、古い仕様や別製品の説明かもしれません。上位候補の本文とメタデータを確認し、必要なら再順位付けや回答の根拠照合を組み合わせます。類似度をそのまま正答確率へ読み替えないことが大切です。
今日の学び
この論文は、人手の検索ラベルに大きく依存せず、関連する文章を見つける表現を学ぶ課題を扱いました。自然な文章ペアの収集・選別と対照学習、入力の役割を伝える接頭辞によって、検索に使えるベクトルを作っています。開発へのヒントは、埋め込みモデルの選択だけでなく、学習ペアの品質と「何を関連と見なすか」を設計することです。RAGでも問い合わせ分類でも、自分の用途で検索・分類の成否を測ることが改善の出発点になります。