RAG 検索における Dense + Sparse Hybrid Search

RAG システムでは、検索層が LLM の見られる証拠を決めます。生成モデルがどれほど強くても、重要な文書を recall できなければ、最終回答を信頼できるものにするのは困難です。

そのため、本番向け RAG は通常、一つの検索方式だけに依存せず、次を組み合わせます。

Dense Search：意味の類似度で検索する
Sparse Search：語句または sparse feature で検索する

二つの方式で候補文書を並列に取得し、RRF などのアルゴリズムで順位を融合します。この方式は一般に Dense + Sparse Hybrid Search と呼ばれます。Qdrant、Elasticsearch、OpenSearch、Azure AI Search などの主要製品は、hybrid retrieval を標準でサポートしています。(Qdrant)

1. Dense Search：意味に基づく検索

Dense Search は Embedding モデルを使って query と文書を固定次元の dense vector に変換します。

ユーザーの質問
「子どもが生まれた後、仕事を休めますか？」
        ↓ Embedding
[0.13, -0.28, 0.51, ...]

その後、vector similarity search で意味の最も近い文書を探します。

文書に次のように書かれていても、

従業員は育児休業制度に基づいて休暇を申請できます。

query に「育児休業」という語がなくても、Dense Search は両者が近い概念を表していると理解できます。

Dense Search が得意なこと

• 自然言語の質問
• 同義語と類似表現
• Query rewriting
• 言語をまたぐ意味検索
• ユーザーと文書の表現が異なる場面

Dense Search の限界

Dense Search は、次のような正確な識別子では不安定になりがちです。

ERR-1047
RFC 9110
X-Telegram-Bot-Api-Secret-Token
注文番号 A-2026-0715

Embedding は似た番号を意味的に近いと判断する可能性がありますが、業務上は ERR-1047 と ERR-1048 がまったく違う問題を表すことがあります。

また、「話題は似ているが質問には答えられない」文書を取得しやすいという弱点もあります。

2. Sparse Search：語句と Sparse Feature に基づく検索

Sparse representation の次元空間は通常とても大きい一方、各文書で 0 以外になる次元は少数です。BM25 と inverted index は、企業検索で最も一般的な Sparse 検索方式です。

BM25 は主に次を考慮します。

• Query の語が文書に含まれるか
• 語の出現頻度
• corpus 全体における語の希少性
• 文書の長さ

OpenSearch は keyword search に BM25 を標準使用しており、明確な keyword を含む query に強い一方、その背後の意味を十分には理解できないと説明しています。(OpenSearch Documentation)

Sparse Search が得意なこと

• 製品型番
• エラーコード
• API 名
• 人名、会社名、固有名詞
• 法令条項番号
• 完全一致する phrase
• 数字、日付、略語

たとえば次の query では、

ERR-1047 とは何ですか？

BM25 は通常、意味の近い別のエラーコードと混同せず、ERR-1047 を含む文書を直接見つけられます。

Sparse Search の限界

Sparse Search は表現の変化にあまり強くありません。

文書に次の語があり、

育児休業

ユーザーが次のように尋ねたとします。

子どもの世話をするため、一時的に仕事を止められますか？

同義語展開やほかの言語処理がなければ、従来の keyword search は一致しない可能性があります。

3. Sparse は必ずしも BM25 を意味しない

Hybrid Search の議論で「Sparse」は二種類の技術を指す場合があります。

従来の Lexical Retrieval

BM25
TF-IDF
Inverted Index

文書と query に実際に現れる語句へ依存し、高速で説明可能、かつ完全一致に強い方式です。

Neural Sparse Retrieval

SPLADE や、検索エンジンが提供する Neural Sparse モデルなどがあります。

モデルが語句ごとの sparse weight を生成し、query に関連語を展開する場合もあります。そのため、inverted index の効率と一定の説明可能性を残しながら、意味理解を一部加えられます。OpenSearch は Neural Sparse Search を sparse representation と inverted index に基づく検索と定義し、Dense Search との組み合わせにも対応しています。(OpenSearch Documentation)

多くの RAG v1 では、まず次から始めるのが現実的です。

Dense Embedding + BM25

従来の BM25 では recall 要件を満たせないと評価で分かった場合に、Neural Sparse モデルを検討します。

4. なぜ二つを併用するのか

Dense と Sparse の長所と失敗パターンは互いに補完します。

Dense：
ユーザーが何を意味しているかを理解する

Sparse：
ユーザーが実際に使った語を確認する

次の query では、

さきほど買った商品を取り消すにはどうすればよいですか？

Dense Search は原文の語が違っていても、「返品と注文キャンセル」という題名の文書を見つけられます。

一方、次の query では、

注文 A-20260715-009 の現在の状態

Sparse Search の方が注文番号の完全一致に適しています。

Hybrid Search は次を同時に扱えます。

• 意味表現の違い
• 正確な keyword
• 専門用語
• 番号とコード
• long-tail の自然言語質問

Elastic は Hybrid Search を、keyword retrieval と semantic retrieval を一つの ranking に統合し、lexical precision と意味理解を同時に利用する方式と説明しています。(Elastic)

ただし、すべての dataset で Hybrid Search が単一方式より優れるとは限りません。index、query、tuning、評価の複雑性が増えるため、実際の効果を独自の検索評価セットで検証する必要があります。

5. 二つの結果をどう融合するか

Dense と Sparse の raw score は通常、そのまま足せません。

Dense cosine score：0.82
BM25 score：14.6

数値の尺度と意味が違うため、14.6 の方が 0.82 より関連性が高いとは言えません。

RRF：一般的な標準案

RRF は Reciprocal Rank Fusion の略で、raw score を比較せず、別々の結果リストにおける文書順位を使って融合します。

簡略化した式は次のとおりです。

RRF(document) = Σ 1 / (k + rank)

• rank は各検索結果における文書順位です。
• k は上位順位間の差を弱める定数です。

結果が次のようになったとします。

Dense ranking：
A：1 位
B：2 位
C：3 位

Sparse ranking：
C：1 位
A：2 位
D：3 位

A と C は両方の検索で上位にあるため、融合後も高く評価されます。

Azure AI Search は並列実行した全文 query と vector query を RRF で統合します。Elastic も RRF を Hybrid Search の一般的な出発点として推奨しています。(Microsoft Learn)

RRF の利点は次のとおりです。

• 二つの score scale を合わせる必要がない
• parameter が少ない
• 異なる retriever に対して安定している
• 初期 baseline に向いている

一方、主に順位へ依存し、raw score の細かな差を利用しません。Dense と Sparse の比重を明示的に制御したい場合には、weighted fusion、score normalization、learning to rank が必要になることがあります。

6. 典型的な本番検索 Pipeline

企業向け RAG では、次のような流れが一般的です。

ユーザー Query
   │
   ├── Dense Query Embedding
   │       ↓
   │   Dense Top K
   │
   └── BM25 / Sparse Encoding
           ↓
       Sparse Top K
           │
           ▼
        RRF Fusion
           │
           ▼
       重複排除と Filter
           │
           ▼
       Cross-Encoder Rerank
           │
           ▼
       最終 Top N Chunks
           │
           ▼
          LLM

たとえば次の設定から実験できます。

Dense Top K：20〜50
Sparse Top K：20〜50
融合後の候補：20〜50
Rerank 後：5〜10
LLM へ渡す数：3〜8

これは出発点であり、普遍的な最適値ではありません。Qdrant は同じ collection に Dense と Sparse の representation を保存し、server 側で RRF または DBSF を使って複数結果を融合できます。(Qdrant)

7. Hybrid Search と Reranker の関係

Hybrid Search が主に解くのは次の問題です。

関連文書をできるだけ候補集合へ recall する。

Reranker が主に解くのは次です。

候補集合の中で、どの文書が最も関連しているかを正確に判断する。

役割は異なります。

Dense + Sparse Hybrid Search
→ Recall を高める

Cross-Encoder / ColBERT / Rerank API
→ 最終順位の精度を高める

一般的な二段階設計は次のとおりです。

第1段階：
Dense + Sparse で数十件の候補を高速に取得する

第2段階：
より高価なモデルで Query–Document pair を再評価する

データ量が少ない、または query が単純なら、Hybrid Search の結果を直接返すだけで十分なこともあります。Reranker は latency と cost を増やすため、必要性を評価結果で判断します。

8. Hybrid Search に適した場面

Hybrid Search は一般に次の用途に向きます。

• 社内ナレッジベース
• 技術文書と API 文書
• カスタマーサポートのナレッジベース
• 法令、規制、契約書
• 製品マニュアル
• コード検索
• 型番、番号、略語、固有名詞が多い corpus
• 多言語ナレッジベース

Dense Search だけで十分な可能性があるのは次のような場合です。

• データ量が少ない
• 内容の大半が自然言語である
• 正確な番号や識別子がほとんどない
• 迅速な prototype の段階である
• offline 評価で Sparse に明確な効果がない

妥当な原則は「すべての RAG が Hybrid でなければならない」ではなく、次の考え方です。

Dense、Sparse、Hybrid の三つの baseline を作り、実データで追加の複雑性を負う価値があるか判断する。

9. どう評価するか

数件の手作業の質問だけで Hybrid Search の有効性を判断してはいけません。関連文書を annotation した検索 dataset を作り、次を別々に実行します。

Dense-only
Sparse-only
Dense + Sparse Hybrid
Hybrid + Reranker

重要な指標は次のとおりです。

Recall@K
Precision@K
MRR
nDCG@K
Hit Rate
検索 latency
query 当たりの cost

query type ごとの分析も必要です。

自然言語 query
完全一致 keyword
エラーコードと番号
多言語 query
回答なし query
略語と専門用語

結果は次のようになる可能性があります。

• 自然言語 query では Dense が最良
• 番号と固有名詞では Sparse が最良
• 全体平均では Hybrid が最良
• Hybrid の改善は小さい一方、latency は大きく増える

このような評価を行って初めて、具体的な system に Hybrid Search が適しているか判断できます。

まとめ

Dense + Sparse Hybrid Search は新しい検索アルゴリズムではなく、組み合わせ戦略です。

Dense が意味的な recall を提供する
Sparse が lexical precision を提供する
RRF が ranking を融合する
Reranker が精度をさらに高める

企業文書には自然言語だけでなく、番号、用語、製品名、エラーコードが含まれるため、企業 RAG で広く使われています。

ただし Hybrid Search は無条件に最良ではありません。index size、query latency、system complexity、evaluation cost が増えます。より安全な進め方は次のとおりです。

Dense-only と Sparse-only を baseline とし、検索評価で Hybrid Search の実際の効果を確認してから、本番導入を決める。