今回の論文
今回取り上げるのは、Thibault Formal、Benjamin Piwowarski、Stéphane Clinchantによる「SPLADE: Sparse Lexical and Expansion Model for First Stage Ranking」です。2021年のSIGIRで発表された情報検索の論文で、arXiv初版の公開日は2021年7月12日です。公開元はACMとarXivで、論文URLとACMのDOIから参照できます。著者所属機関の書誌情報
選んだ理由は、「意味を考慮した検索には密なベクトルが必要」という見方を広げてくれるためです。SPLADEは言語モデルの知識を、検索に使う語と重みへ変換します。既存の検索の考え方とニューラルモデルをつなぐ仕組みは、RAGの候補検索や社内文書検索を設計するヒントになります。以下では2021年の原論文を扱い、後続のSPLADE v2とは区別します。
どんな技術か
SPLADEは、文章を「語彙の各項目にどれだけ重みを付けるか」という表現に変換するニューラル検索技術です。大半の重みをゼロにし、一部の語だけを残すため、疎なベクトルになります。
特徴は、入力に書かれている語だけでなく、文脈から検索に役立つ語も活性化できることです。例えば「ログインできない」という問い合わせと「認証失敗の対処」という文書を近づけるには、表面上の文字列だけでは足りません。これは仕組みを説明するための例で、日本語での動作を原論文が検証したものではありません。
検索時は、質問と文書で同じ語彙の項目に付いた重みを掛け合わせます。意味の対応を学習しながら、実際の検索は語彙の一致と転置インデックスで処理するのが基本です。著者の公式実装による概要
課題
キーワード検索では、利用者の言葉と文書の言葉が違うと、必要な資料を候補に入れられません。後段に優秀な再順位付けモデルや回答生成モデルがあっても、最初の検索で落ちた資料は利用できません。RAGで回答が不十分な場合、生成モデルの能力より候補検索が原因になっていることがあります。
密なベクトルによる検索は意味の近さを扱えますが、スコアがどの語に由来するかを追いにくい場合があります。また、近傍探索のインデックスを設計する必要があります。一方、文書へ関連語を大量に追加するだけでは、検索対象が広がりすぎて処理量が増えます。
SPLADEが扱うのは、言い換えを拾う力と、少ない語で効率よく検索する力の両立です。用語が多様な問い合わせ検索や、大量の短い文書から根拠を探す仕組みでは、この両方が必要になります。
用語解説
- 疎な語彙ベクトル
- モデルの語彙に対応する各次元へ重みを付け、大部分をゼロにした表現です。SPLADEでは次元が語彙項目と対応するため、どの項目の一致が検索スコアに寄与したかを調べられます。
- 転置インデックス
- 語ごとに、その語の重みが非ゼロである文書と重みを記録する索引です。質問で有効になった語の一覧だけを参照でき、全文書の全次元を毎回比較せずに済みます。
- MLMヘッド
- BERTなどが、文脈から語彙内の各トークンのスコアを出すための出力層です。SPLADEはこの層を語彙の重要度予測に転用し、入力にない語にも重みを付けられるようにします。
- 語彙拡張
- 入力にない関連語にも検索上の重みを与えることです。SPLADEでは文章を生成して追記するのではなく、ベクトルの別の次元を活性化します。利用者と文書の言葉のずれを埋める役割があります。
- 疎性の正則化
- ランキングの学習に、語の重みを抑える目的も加える方法です。単に関連文書を高く評価するだけでなく、索引の大きさや検索計算を増やしすぎない表現を学びます。
技術の仕組み
BERTの出力を語彙全体への重みにする
質問と文書を、それぞれBERTとMLMヘッドで処理します。原論文の語彙は30,522項目のWordPieceです。これは単語だけでなく単語の一部分も含むため、「検索語」は必ずしも自然言語の単語と一対一ではありません。
各入力位置で、語彙内の全項目に対するスコアを計算します。ある文書に出ていない項目でも、文脈に応じて正のスコアになれます。そのため、文書の語の重要度調整と、関連語による拡張を同じ構造で扱えます。
対数で強すぎる重みを抑えて足し合わせる
語彙項目 j の最終的な重みは、各入力位置 i のスコアを使い、次のように作ります。
重み[j] = Σ_i log(1 + max(0, スコア[i, j]))
負のスコアはゼロにし、正の値は対数で伸び方を緩めます。例えば変換前の値が1から10になっても、変換後は約0.69から2.40への増加にとどまります。特定の語だけが極端にスコアを支配しにくくする工夫です。
その後、入力位置全体で足し合わせ、文章を一つの語彙ベクトルにします。ここで扱う原論文は和による集約です。後続版で使われる最大値による集約と混同しないことが重要です。また、対数そのものが正の値をゼロにするわけではありません。非正のスコアをゼロにする処理と、学習時の正則化を組み合わせて疎な表現を得ます。原論文の式4と学習方法
検索品質と計算負担を一緒に学習する
質問に対する関連文書、BM25などで見つけた紛らわしい非関連文書、同じ学習バッチに含まれる別の質問の文書を用意します。関連文書との内積が他の文書より高くなるように学習します。
そこへ疎性の正則化を加えます。重要なのは「一つの文書に残す語数」だけではなく、「同じ語が多数の文書で有効になっていないか」も見ることです。頻繁に使われる語の一覧が長くなると、その語を含む質問の処理量が増えるためです。
FLOPS正則化では、学習バッチ内で語彙項目ごとの平均重みを求め、その二乗を合計して罰則にします。多くの文書で強く活性化する項目ほど大きく抑える考え方です。質問側と文書側の罰則の強さを別々に設定でき、オンライン処理に直結する質問側を強く絞る選択もできます。
文書は事前処理し、質問は検索時に変換する
実装の流れは、文書の変換、索引作成、質問の変換、重みの積の集計、候補の取得です。文書は事前に処理し、非ゼロ項目と重みを転置インデックスへ保存します。質問が来たら同じ語彙空間へ変換し、一致する項目の積を足して順位を付けます。
生成モデルへ渡すなら、この候補の後に再順位付けや文書の整形を加えます。SPLADEが担当するのは主に最初の候補検索です。公式リポジトリでは、学習・索引作成・検索の実装と、拡張後の項目を確認するノートブックが公開されています。ただし公開モデルには後続版も含まれるため、重みと方式の版を記録する必要があります。公式コードと公開モデルの説明
実験と結果
大量の文章から候補を取り出せるか
原論文は、約880万パッセージを持つMS MARCOで学習し、6,980質問の開発セットと、43質問のTREC DL 2019で評価しました。全コレクションから検索する設定で、後段のBERT再順位付けは含めていません。
MRR@10は最初の関連文書が上位10件のどこに出るか、NDCG@10は上位10件の関連度と順位、Recall@1000は関連文書を上位1,000件に含める割合を見る指標です。いずれも高いほどよい値です。
| 手法 | MS MARCO MRR@10 | MS MARCO Recall@1000 | TREC DL NDCG@10 | TREC DL Recall@1000 |
|---|---|---|---|---|
| BM25 | 0.184 | 0.853 | 0.506 | 0.745 |
| doc2query-T5 | 0.277 | 0.947 | 0.642 | 0.827 |
| SPLADE（FLOPS正則化） | 0.322 | 0.955 | 0.665 | 0.813 |
| TCT-ColBERT | 0.335 | 0.964 | 0.670 | 0.720 |
SPLADEはBM25やdoc2query-T5より上位のランキング指標を改善しています。一方、TREC DLのRecall@1000はdoc2query-T5が上回り、MS MARCOの指標ではTCT-ColBERTが上回っています。「すべての指標で最良」ではなく、疎な表現でも密検索に近い品質を出せる結果です。原論文の表1
品質を少し譲ると、どこまで疎にできるか
表1のSPLADEでは、推定検索演算量の指標が0.73でした。正則化を強めた別の設定では、同指標0.05でMRR@10は0.296となりました。その設定の非ゼロ項目は平均で質問6項目、文書18項目で、索引のディスク容量は1.4 GB未満です。これはMRR@10が0.322の設定とは異なります。
この演算量指標は、質問と文書で語彙項目が同時に有効になる頻度から推定したものです。実測のミリ秒や、BERTによる質問変換を含む総コストではありません。「0.05だからBM25より応答が速い」とは判断できません。原論文の図1と疎性の分析
結果から読み取れるのは、正則化の強さで品質と索引の負担を調節できることです。索引を小さくしたい用途と、関連文書を取りこぼしたくない用途では、選ぶ設定が変わります。
何に使える？
以下は技術の仕組みから考えられる応用です。原論文がRAGの回答品質や、各業務での効果を直接検証したわけではありません。
RAGで、言い換えによる検索漏れを減らす
マニュアルと利用者の質問で表現が違う場合、語彙拡張が候補の取得に役立つ可能性があります。まず検索だけを比較し、根拠文書が上位候補へ入るかを測るとよいでしょう。候補が改善してから同じ生成モデルへ渡せば、検索変更の効果を切り分けられます。
問い合わせやFAQの候補検索
利用者の自由文から、定型のFAQや過去の対応記録を探す用途が考えられます。単純な一致では見つからない表現を拾い、候補を担当者へ提示できます。ただし、似た話題でも製品バージョンや契約条件が違う文書はあります。属性フィルターと組み合わせる設計が必要です。
検索失敗の原因を調べる社内ツール
質問と文書の非ゼロ項目、および内積への寄与を表示するツールも作れます。「元の語が消えた」「拡張した項目に偏った」「そもそも共通項目がない」といった原因を調べられます。語彙項目を見られることは分析に役立ちますが、人間が納得する意味の説明が自動で得られるわけではありません。
開発や事業へのヒント
小規模なサービスは、再学習より検索比較から始める
まず少量の代表的な質問と、正解となる文書を用意し、BM25と公開SPLADEモデルを比較する方法が現実的です。最初から大規模学習を再現する必要はありません。
比較には、上位候補への正解の入りやすさ、上位順位、質問変換を含む応答時間、索引容量を入れます。日本語や専門用語を扱うなら、それらを含む質問群を別に集計すると、平均値だけでは見えない弱点がわかります。
検索の費用を、事前処理とオンライン処理に分ける
文書を一度変換して何度も検索する構成は、更新頻度が低い資料に向いていると考えられます。一方、文書が頻繁に変わるサービスでは、変換と索引更新の費用も見積もる必要があります。
プロダクトの判断では、質問1件の待ち時間だけでなく、文書更新1件の処理量も測るとよいでしょう。モデルを変更すると文書側の表現も変わるため、索引の再構築と切り替えを計画する必要があります。
正確な識別子は別の経路でも守る
SPLADEは語を残すだけでなく、不要と判断した入力項目を消すこともあります。したがって、型番やエラーコードを必ず保持する仕組みではありません。
実務上の設計案として、識別子の完全一致検索やメタデータ検索と候補を統合し、SPLADEで言い換えを拾う構成が考えられます。この併用の効果は自分のデータで検証する必要があります。検索方式を一つに統一することより、業務で落としてはいけない情報を守ることが優先です。
限界
まず、疎な最終表現を得るまでにはBERTと語彙全体への予測が必要です。検索スコアの計算が軽くても、質問の変換や大量文書の索引作成にはコストがかかります。原論文の学習は32 GBのV100を4台使い、入力の最大長は256トークンでした。長い資料では分割と根拠位置の管理が別途必要です。原論文の実験設定
データの制約もあります。中心的な実験は英語のMS MARCOとTREC DL 2019です。日本語、社内独自の略語、コード、表を含む資料への性能は保証されません。語彙とトークン化、検索用の学習データの両方が影響します。
拡張した語がすべて適切とは限りません。また、語彙項目の重みだけでは、検索対象の事実が正しいか、条件に合うかを保証できません。検索後の確認、再順位付け、回答の根拠評価は引き続き必要です。
再現時には、正則化の係数、負例の作り方、集約方法、索引形式をそろえる必要があります。公式リポジトリの後続モデルの結果を、原論文の表1と同一条件として比較することもできません。実運用の遅延は同時アクセス数や転置リストの偏りにも左右されるため、実データでの測定が必要です。
よくある質問
Q. SPLADEは密なベクトル検索と何が違いますか？
A. 次元がモデルの語彙項目に対応し、大半の重みがゼロになる点が違います。質問と文書の共通項目の重みでスコアを作り、転置インデックスで検索できます。ただし、元の文章に同じ文字列がなくても、学習で活性化した項目同士が一致する場合があります。
Q. 文書に関連語の文章を追加するのでしょうか？
A. 追加するのは検索表現の重みです。元の文書を書き換えたり、関連語を含む新しい文章を生成したりする必要はありません。RAGへ渡す根拠は元の本文を保持し、検索用表現と対応付けます。
Q. 日本語のRAGへそのまま導入できますか？
A. 原論文の英語での結果だけでは判断できません。日本語を扱える語彙とモデルを選び、専門用語や言い換えを含む質問で正解文書の取得率を確認する必要があります。公開重みを使う場合も、対応言語と学習条件を確認してください。
Q. BM25と同じ速さで動きますか？
A. 原論文の推定演算量から、そのようには言えません。SPLADEには質問をニューラルモデルで変換する時間が加わります。変換、索引検索、後段処理を含む時間を、同じ文書集合と実行環境で比較してください。
Q. 元のキーワードは必ず残りますか？
A. 必ず残るわけではありません。原論文は入力の一部項目をゼロにすることも報告しています。型番や識別子を落とせない用途では、完全一致の検索経路を併用し、その取得率を別に測る設計が考えられます。
今日の学び
この論文は、検索語と文書の言葉のずれを解消しながら、候補検索の負担を抑える課題を扱いました。BERTの語彙予測、対数による重みの調整、疎性の正則化を組み合わせ、関連語の拡張と不要な項目の削減を同時に学習します。
得られるヒントは、意味を考慮した検索にも、語と索引を使う設計があることです。検索の品質、索引容量、質問処理の時間を分けて測れば、RAGや社内検索を改善する選択肢が増えます。