RAGの検索を軽くする「mSlideOn」――意味を捉えて転置索引で探す仕組み｜2026年10月26日版
生成AIに社内文書などを参照させるRAGでは、回答の前に、質問に合う資料を探す必要がある。LightOnが10月19日に公開した「SlideOn」と「mSlideOn」は、この検索を、意味を捉えるAIと転置索引の組み合わせで実現するモデルだ。
核心は、既存の検索モデルが学んだ表現を、少数の特徴だけが有効になる「疎なベクトル」へ変換すること。質問と共通する特徴を持つ文書に検索対象を絞れるため、検索品質と索引の扱いやすさを両立させる設計になっている。公式発表
2026年10月26日、日本時間時点の公開資料をもとに、その仕組みと導入時の確認点を整理する。
- 何が新しいか： 学習済み検索モデルを、転置索引で扱える疎な表現へ変換する。
- 何に使えるか： 多言語文書、長文、コードの検索を担うmSlideOnを公開。
- 何を確かめるか： ベンチマークの平均値だけでなく、日本語の検索品質と実際の応答時間を見る。
検索対象を絞る鍵は「少数の特徴」
転置索引は、ある語や特徴が現れる文書を逆引きする仕組みだ。mSlideOnでは、その手がかりをモデルが学習する。
処理の流れは次のようになる。
- 質問と文書をモデルに入力し、文脈を含むトークン表現を得る。
- その表現を、少数の特徴だけが有効なベクトルへ変換する。
- 文書側の特徴と重みを、転置索引に登録する。
- 質問で有効になった特徴から文書を探し、重みの積を足して順位を付ける。
質問と有効な特徴を共有しない文書は、照合の対象から外せる。重要なのは、特徴が単なる入力語の一覧ではなく、学習された潜在的な特徴であることだ。表記が一致するかどうかに加え、モデルが学んだ意味の近さを検索へ持ち込む。仕組みの解説
ただし、各特徴に人間が読める単語名が付いているわけではない。「疎な表現だから、検索理由をすべて単語で説明できる」と受け取るのは早計だ。
mSlideOnは何を引き継ぎ、何を変えたのか
mSlideOnは、多言語検索モデル「mLateOn」を出発点にする。ゼロから検索能力を学ぶのではなく、既存モデルの表現を疎な形式へ移す。
まず、スパースオートエンコーダーを使い、元の表現を少数の特徴から再構成するよう学習する。その後、質問に適切な文書を上位へ出すための教師あり学習を行う。表現を復元できることと、検索に役立つことの両方を学ぶ二段階の構成だ。学習方法
公開されたモデルカードによる主な仕様は次の通り。
- パラメーター数は3億3,900万。
- 最大入力長は、特殊トークンなどを含め8,192トークン。
- 出力は32,768次元の非負の疎ベクトル。
- ライセンスはApache 2.0。
ここで混同しやすいのが、トークンごとの特徴選択と、文書全体の特徴数だ。各トークンでは上位32個の特徴を選ぶが、その後に複数トークンの情報をまとめるため、文書全体が32個の特徴だけになるわけではない。
評価結果は「どの方式より優れるか」まで読む
公開評価では、mSlideOnは同社の単一ベクトル型モデル「mDenseOn」を、多言語検索と長文検索で上回った。
一方、出発点となったmLateOnには、両分野で届いていない。検索品質を全面的に更新したというより、索引で扱う表現の選択肢を増やした発表と読むのが適切だ。
モデルカード掲載の平均nDCG@10は次の通り。上位10件の検索順位の良さを測る指標で、数値は0〜100の尺度。いずれも開発元による評価で、mSlideOnは最終ベクトルを追加削減しない条件となる。
- 多言語検索・MIRACL： mSlideOnは62.78、mDenseOnは58.02、mLateOnは67.04。
- 長文検索・MLDR： mSlideOnは61.68、mDenseOnは51.50、mLateOnは77.92。
転置索引へ移せる利点と、保持できる検索品質の差を合わせて判断する必要がある。なお、公開資料の「Retrieval FLOPS」は検索コストの代理指標であり、実測の待ち時間ではない。評価条件と比較結果
日本語RAGで試すなら、検索品質と索引費用を分けて測る
日本の開発現場では、多言語ベンチマークの平均値を、そのまま日本語文書の成績として扱わないことが重要になる。
例えば社内規程を検索するなら、次のような質問を評価セットに含めたい。
- 規程の正式名称を含む質問。
- 正式名称を知らず、日常語で言い換えた質問。
- 例外条件が長い文書の途中にある質問。
- 英語の製品名と日本語の説明が混在する質問。
これは導入時の検証項目であり、mSlideOnでこれらの成功を確認したという意味ではない。正解文書が上位に入る割合を測り、現在の検索方式と比較するための切り口だ。
実装面では、モデルが出す疎ベクトルと、それを格納して検索する索引をつなぐ必要がある。LightOnは学習・評価コードも公開しているが、既存RAGへの採用では、文書更新時の再処理や索引構築を含む検証が残る。
比べるべき費用も、検索時だけではない。
- 文書をベクトル化する時間。
- 索引の構築時間と保存容量。
- 質問を処理してから検索結果を返すまでの時間。
- 文書追加・更新時の処理量。
継続ウォッチ：特徴を削ったとき、何を取りこぼすか
mSlideOnでは、質問と文書それぞれについて、残す特徴数を調整できる。特徴を減らすことで索引や検索処理を軽くできる余地がある一方、必要な手がかりまで失えば検索品質は下がる。
次に見るべき点は、次の3つだ。
- 日本語での再現性： 社内用語、言い換え、日英混在の質問で正解文書を拾えるか。
- 削減後の品質： 特徴数を減らしても、長文の例外条件や細かな違いを捉えられるか。
- 実測の運用費用： 索引容量、応答時間、更新処理まで含めて既存方式より扱いやすいか。
最初の比較では、同じ文書と質問を使い、検索結果の上位10件と応答時間を並べたい。そこから特徴数を段階的に減らせば、自社の資料でどこまで軽くできるかを判断しやすくなる。