Sparse Retrieval

ひとことで言うと：Sparse Retrievalは、語彙などに対応する高次元ベクトルの大部分がゼロであるsparse representationを使い、転置インデックスなどで関連文書を効率よく取得する検索方式です。^[1][2][3]

Sparse Retrievalとは

Sparse Retrievalは、クエリと文書をsparse vector（疎ベクトル）で表し、その一致や重みを使って関連文書を取得する情報検索方式です。「sparse」とは、ベクトルの次元数は非常に多い一方、その多くの値がゼロであることを意味します。

伝統的な情報検索では、語彙の各語を次元として文書を表し、TF-IDFやBM25のような重み付けで検索します。近年はSPLADEのようにニューラルネットワークでSparse表現や語展開を学習する方式もあり、Sparse Retrieval＝古典的検索だけ、とは言えなくなっています。

BM25もSparse Retrievalなのか

広い意味では、BM25を使った全文検索はSparse Retrievalの代表例として扱えます。文書中に現れる語だけが非ゼロの情報を持ち、転置インデックスによって「ある語を含む文書」を効率よく検索します。

BM25は、語の出現頻度、文書集合全体での希少性、文書長などを考慮して関連度を計算します。検索語が文書に実際に現れるというlexical matchが重要な信号です。

ただし、製品説明で「Sparse Retrieval」と書かれている場合、単なるBM25ではなく、学習型Sparse Encoderを指していることもあります。用語だけでは方式を特定できないため、モデル名や索引形式を確認する必要があります。

Learned Sparse Retrievalとは

SPLADEは、BERT系のMasked Language Modelの出力を利用し、語彙空間上でSparseな重みを生成する代表的な学習型retrieverです。文書やクエリに明示的に書かれていない関連語にも重みを持たせる「expansion」を学習できるため、素朴な語一致より意味的なギャップを埋めることがあります。

たとえば文書に「automobile」、クエリに「car」と書かれているとき、単純な語一致では弱いものの、学習型Sparseモデルが関連語を展開できれば候補として結びつけられる場合があります。

それでも表現はSparseなので、転置インデックスを利用しやすく、どの語彙次元が効いたかを比較的追いやすいという特徴があります。

Dense Retrievalとの違い

Dense Retrievalでは、数百〜数千次元程度の連続ベクトルの多くが非ゼロ値を持ち、各次元は通常、人間が語として直接解釈できません。Sparse Retrievalでは、より高次元でゼロが多く、語彙と対応した次元を使う方式が代表的です。

Denseは言い換えや概念的な近さを扱いやすい一方、Sparseは固有名詞や専門用語など明示的な語一致に強いことがあります。ただし、learned sparseは意味的な語展開を行えるため、「Sparse＝完全一致」「Dense＝意味検索」という二分は単純すぎます。

現在のRAGでは、Dense RetrievalとSparse Retrievalを両方実行して結果を融合するHybrid Searchがよく使われます。

Worked example

法務文書を検索するとします。ユーザーが「下請法 支払遅延」と入力し、文書Aにはその語がそのまま書かれています。文書Bには「取引代金の支払期日を徒過した場合」と書かれています。

BM25系Sparse Retrievalでは、文書Aの明示語一致が非常に強い信号になります。文書Bは語が違うため弱いかもしれません。learned sparseが関連語を展開できればBも拾える可能性がありますが、モデルの学習範囲や日本語能力に依存します。

Dense RetrievalならBを意味的に近いと判断できる可能性があります。しかし、法令名や条文番号の正確な一致はSparse側が強い場合があります。両者をHybridにする理由がここにあります。

転置インデックスとの関係

Sparse表現は、非ゼロの次元だけを記録すればよいため、転置インデックスとの相性が良いです。各語や特徴から、それを持つ文書のリストへ逆引きできます。

Dense vectorでは通常、全次元が値を持つため、同じ転置索引の仕組みをそのまま使うのではなく、HNSWなどのANN索引を使います。Sparse RetrievalとDense Retrievalでは、データ構造や計算特性が異なります。

ただし現代の検索基盤では、denseとsparseを同一製品内で扱い、同じAPIからHybrid Searchする例もあります。基盤が同じでも検索表現は別物です。

Sparse Retrievalの強み

Sparse Retrievalが実務で残り続ける理由には次があります。

• 型番、製品名、人名、法令名、コードなどのexact lexical signalを利用しやすい。
• 転置インデックス技術が成熟しており、大規模全文検索で高速。
• BM25のような方式では挙動を比較的説明・デバッグしやすい。
• 学習型Sparseでは、語展開によってvocabulary mismatchを緩和できる。
• DenseだけよりHybrid構成でRecallやRobustnessを改善できる場合がある。

一方、語彙が大きく異なる言い換え、抽象的な概念検索、クロスリンガル検索ではDenseが有利になる場合があります。

設定を見るときの注意

Sparse Retrievalの品質は「sparseであること」だけでは決まりません。BM25ならTokenizer、Analyzer、同義語、フィールド重み、k1やbなどの設定が影響します。Learned Sparseならモデル、学習データ、Sparsity regularization、query/document expansionなどが影響します。

また、Sparse Vectorの次元数が大きいから高性能というわけではありません。ゼロでない項目数、索引サイズ、Latency、Recallとのトレードオフがあります。

次に起こりやすい誤解

最も多いのは、「Sparse Retrievalは古いKeyword Searchの別名で、生成AI時代には不要」という誤解です。BM25は今も強力なbaselineであり、learned sparseの研究も続いています。Hybrid Searchでは重要な構成要素です。

逆に、「Sparse Retrievalなら結果理由が完全に説明できる」とも限りません。学習型Sparseでは、モデルがなぜ特定の拡張語に重みを与えたかまで単純に説明できるわけではありません。Denseより語彙次元を観察しやすい、という程度に理解する方が安全です。

元文脈へ戻るためのチェックリスト

Sparse Retrievalという語を見たら、次を確認します。

• BM25／TF-IDF系か、learned sparse encoderか。
• 語彙の次元は何に対応するか。
• query expansionやdocument expansionを行うか。
• どのTokenizer／Analyzerを使うか。
• 転置インデックスで検索するか。
• Dense RetrievalとのHybrid構成か。
• 結果融合はRRF、weighted scoreなど何を使うか。
• 日本語や対象ドメインでの評価があるか。
• Recall、Latency、index sizeのトレードオフはどうか。

Sparse Retrievalというラベルから推論できるのは「疎な表現を主要な検索信号として使う」ことまでです。古典的BM25なのか、ニューラルなSparse Encoderなのかで性質が大きく異なるため、元の実装を確認することが重要です。

Query ExpansionとDocument Expansion

Learned Sparse Retrievalの特徴の一つは、入力に明示されていない関連語へ重みを広げることができる点です。Query Expansionでは検索クエリ側、Document Expansionでは文書側に関連語の信号を加えます。

たとえば「心筋梗塞」という文書に対して「heart attack」に相当する語をモデルが関連付けられれば、語の完全一致がなくてもSparse空間上で接点を作れる可能性があります。

ただしExpansionは誤った関連語も増やし得ます。広げすぎると索引サイズやLatencyが増え、Precisionが下がることがあります。Sparsity regularizationは、性能と効率のバランスを取る重要な要素です。

Sparse Vectorの「解釈可能性」

Sparse Retrievalでは、非ゼロの次元が語彙tokenに対応する場合、どの語へ高い重みが付いたかを観察できます。これはDense vectorより人間が追いやすい特徴です。

しかし、観察できることと、モデルの判断過程を完全に説明できることは別です。SPLADEが入力にない語へ高い重みを付けた理由は、学習データとニューラルネットワーク内部の表現に依存します。

「SparseだからExplainable AI」と短絡せず、「検索スコアに寄与した語彙特徴を可視化しやすい」と限定して理解する方が適切です。

OOVとTokenization

古典的な語彙検索では、表記揺れや未知語が課題になります。日本語では形態素解析の辞書にない新語、製品名、固有名詞が適切に分割されないと検索品質が下がることがあります。

Subword vocabularyを使うlearned sparseでは未知語問題をある程度緩和できますが、製品コードのような文字列が細かく分割されすぎると、exact matchの強みが弱くなる可能性があります。

そのためSparse RetrievalでもTokenizerは重要です。「語彙次元で検索する」という説明だけでは、実際のtoken単位や日本語処理は分かりません。

Efficiencyを見るとき

Sparse Retrievalの強みとして転置インデックスの効率が挙げられますが、learned sparseでは一文書あたりの非ゼロtoken数が増えるとposting listも増え、index sizeやLatencyに影響します。

モデル研究では、EffectivenessだけでなくSparsityやLatencyを同時に評価することがあります。精度がわずかに高くても、索引が数倍になり本番要件を満たさない可能性があります。

DenseとSparseを比較するときは、同じRecall水準でのLatency、メモリ、index size、更新コストを見ると実用性を判断しやすくなります。

Hybridでの役割分担

Hybrid Searchでは、Sparse側とDense側を単純に競わせるのではなく、異なるエラーを補わせます。Sparseが固有語を拾い、Denseが言い換えを拾うという役割は代表例です。

ただし、learned sparse自体が意味的Expansionを行うため、Denseとの重複も増えます。どの組み合わせが有効かは評価が必要です。BM25＋Dense、SPLADE＋Dense、複数Dense＋Sparseなど構成はさまざまです。

「Hybrid Searchを使うならSparseはBM25」と決まっているわけではありません。元文脈でSparse Retrieverの種類を確認することが重要です。

関連するAI用語

• Keyword Search
• Hybrid Search
• Dense Retrieval
• Re-Ranking

注・出典

1. arXiv, SPLADE: Sparse Lexical and Expansion Model for First Stage Ranking — 学習型sparse representation、explicit sparsity、first-stage retrieval ↩
2. arXiv, SPLADE v2 — sparse representations、inverted index、denseとの対比 ↩
3. Elastic Docs, Full-text search — BM25を含むlexical/full-text searchと転置インデックス ↩

AI協働制作について