高性能な日本語SPLADE(スパース検索)モデルを公開しました
文章検索用途で高性能なSPLADE(スパースベクトル)モデルの日本語版を作成し、公開しました。大量の文章からの検索タスク(retrieval)や、質問に関連する文章を並べ替えるリランキングタスクで、最近の高性能密ベクトルモデルである multilingual-e5-large、ruri-large、GLuCoSE-base-ja-v2、openai-text-embeddings などと比較しても、競争力がある優れた結果を得ています。
なお、日本語SPLADEモデル作成における技術的な詳細は、SPLADE モデルの作り方・日本語SPLADEテクニカルレポートをご覧ください。
SPLADEとは?
SPLADE(Sparse Lexical and Expansion Model)は、その名の通りスパース(疎)なベクトルを用いた検索モデルです。スパース検索といえば、長年利用されているBM25が代表的で、高い性能を誇るアルゴリズムとして広く利用されています。しかし、BM25はクエリとドキュメントの単語の完全一致に依存しているため、関連する単語や同義語を含む文書を見逃す可能性があります。
一方、SPLADEはTransformerアーキテクチャを活用して、文脈に基づく関連性の高い単語もベクトルに含めることができます。これにより、完全一致以外の単語も検索候補として取り込むことができ、より柔軟で効果的な検索が可能となります。
特性とメリット
SPLADEは、以下の特性を備えています。まず、事前学習済みのTransformerモデル(例:BERT)を利用することで、入力テキストの文脈を深く理解します。これにより、単語の完全一致に依存せず、文脈に基づいて関連性の高い単語も効果的に抽出することが可能です。また、各単語には重要度のスコアが付与され、検索においてどの単語が重要であるかが明確に示されます。さらに、スパースベクトルを生成することで、多くの要素がゼロとなり、計算量を抑えつつ効率的な検索を実現します。
これらの特性により、SPLADEは柔軟な検索を可能にし、関連語や同義語を含む幅広い検索ニーズに対応します。スパースベクトルの活用により、計算量が少なく高速な検索が可能となり、システム全体の効率性が向上します。さらに、各単語の重要度が明確に示されるため、検索結果の解釈が容易になり、ユーザーにとって理解しやすい結果を提供します。最後に、既存の検索エンジンへの導入が容易であるため、現在のシステムにスムーズに統合することが可能です。
具体的な例
SPLADEの動作を理解するために、具体的な例を見てみましょう。これは実際のモデル japanese-splade-base-v1 を利用した出力です。なお、SPLADE 日本語 demoからも、出力結果を簡単に取得することができます。
単語が拡張される例
"車の燃費を向上させる方法は?" の、SPLADEによる出力例
スコア | 単語(vocab) |
---|---|
2.1797 | 車 |
2.1465 | 燃費 |
1.7344 | 向上 |
1.5586 | 方法 |
1.3291 | 燃料 |
1.1377 | 効果 |
0.8716 | 良い |
0.8452 | 改善 |
0.8340 | アップ |
0.7065 | いう |
0.6450 | 理由 |
0.4355 | 価格 |
0.3184 | は |
0.2510 | 家 |
0.2417 | せる |
0.2286 | 目的 |
0.1735 | 店 |
0.1627 | 手段 |
0.0851 | 用 |
0.0752 | 率 |
0.0734 | 上昇 |
このように、クエリの文脈を理解し、元の文に含まれていない「燃料」や「効果」といった関連語も重要な単語として抽出しています。また、各単語には重要度を示すスコアが付与されています。なお「は」など、全く関係なさそうかつノイズになりそうな単語も含んでいますが、このような単語は他の出力にも多く含まれるため、無視できる程度のノイズになっていることが多いため、検索にうまくヒットさせることができるのです。
同様に、文章に対しても行うことができます。このクエリと文章のスパースベクトルの内積をスコアとすることで、どれだけ関連しているのかを計算を行えます。
性能は?
冒頭で述べたように、SPLADEモデルは多くの日本語情報検索タスクで優れた性能を示しています。JMTEB(retrieval)や JQaRA, JaCWIR でのベンチマーク結果は以下です。単語特徴量が結果に色濃く出るタスクでは、軒並み高性能な結果となっています。代わりに、jagovfaqs(FAQ)のような似ている文章の理解が必要そうなタスクでは、あまり振るわない結果となっています。
JMTEB retrieval
JQaRA, JaCWIR reranking
また、ほとんどのオープンソース検索エンジン(Elasticsearch、OpenSearch、Qdrant、Vespaなど)でスパース検索がサポートされているため、導入も容易です。検索速度の面でも、スパースベクトル検索は古くから行われており、BM25などと同様に高速です。
また、SPLADEやBM25は単語特徴量が色濃く反映されるため、mulitilingual-e5 等の密ベクトルモデルと異なった検索結果になることも多いです。そのため、ハイブリット検索として双方の検索結果を組み合わせることで、より良い結果・多様性がある結果をもたらすことが可能です。ハイブリット検索も、先ほどの検索エンジンは基本的にサポートしており、簡単に利用が可能なものが多いです。
本番環境で運用しにくいのでは?
SPLADEの運用は、密ベクトルモデルとほぼ同様に運用ができるため、難しくありません。検索エンジンは先ほど述べた通りスパース検索もサポートしているものがほとんどです。 またSPLADEのスパースベクトルを得ることも、何か複雑なことを行なっているわけではなく、単語(token)の各スコアを、SPLADE max と呼ばれる max pooling と対数飽和関数の組み合わせに通すだけです。
また、高速で本番運用しやすい推論サーバである text-embedding-inference (blog記事) からも利用可能です。
おわりに
当初、SPLADEが本当に高い性能を発揮するのか半信半疑でした。しかし、英語のMS MARCOデータセットのみで学習されたSPLADE-v3が、他の多様な検索タスクでも高性能を示していることから、日本語で適切に学習させた場合の可能性に興味を持ちました。
また、SPLADEはトークナイザの語彙に依存するため、文字レベルで分割することが多いマルチリンガルモデルのトークナイザーとは相性が悪く、そのため日本語用に特化させた学習が必要なことも、面白そうと感じたきっかけでした。(日本語にも対応した密ベクトルの高性能マルチリンガルモデルの作成は、さまざまな企業が参入しているので…)
学習の結果、既知のドメインタスク(JAQKET、mytidi)を含むとはいえ、モデルもパラメータ数も110Mのbaseサイズで、OpenAIの大規模なモデルよりもベンチマークで上回るスパース検索モデルを作成することができました。
学習時間もRTX 4090で33時間程度と、学習計算機リソースや学習時間が少なくても学習が済むため、自社のドメインにフィットした検索結果を求める方々にとって、SPLADEを使った独自ドメインデータを学習させるモデルを作ることは有用なアプローチとなりそうです。
まだまだ今後もSPLADEを用いた日本語スパース検索性能は向上すると思っており、研究対象としても興味深い分野ですね。