RAG システムでは、多くの場合、チャンクを embedding vector（埋め込みベクトル）に変換して Vector Database に保存したあと、検索可能なレコードができます。
チャンク本文
+ embedding vector（埋め込みベクトル）
+ metadata
ユーザーが何かを質問したとき、RAG システムは次のことを判断する必要があります。
保存されているチャンクのうち、この質問に役立つ情報を含んでいそうなのはどれか？
これが retrieval strategy（検索設計） の役割です。Retrieval とは、候補検索のステップのことです。ユーザーの質問が与えられたとき、システムは保存済みのレコードを検索し、役立つ根拠を含んでいる可能性のあるチャンクを返します。
ユーザーの質問
↓
検索設計
↓
候補チャンク
↓
一部の候補が回答の根拠として使われる
注意：検索されたチャンクは、まだ候補にすぎません。自動的に LLM に渡す最終的な Context になるわけではありません。
1. Dense retrieval
1.1 基本的な仕組み
最も単純な RAG の retriever は、次のように動きます。
ユーザーの質問
↓
質問を embedding vector に変換する
↓
近いチャンクのベクトルを検索する
↓
Top-K の候補チャンクを返す
Top-K とは、検索スコアが高い上位 K 個の候補を返すことです。
これは通常、dense retrieval と呼ばれます。質問とチャンクが dense vector、つまり多くの次元が情報を持ちうる数値ベクトルとして表現されるからです。
vector retrieval や vector search という表現を見かけることもあります。これらは、dense retrieval が通常どのように実装されるか、つまり embedding vector を検索する形で実装されることを表しています。
1.2 なぜ dense retrieval は違う言い方にも対応できるのか
Dense retrieval は、質問と有用な文書が、違う言葉で似た意味を表している場合にうまく機能します。
例：
Question:
"Can a new employee take paid leave?"
Useful chunk:
"Annual vacation days are granted after joining the company."
表現は違います。
take paid leave
vs
annual vacation days are granted
しかし、意味は関連しています。Dense retrieval は、このような意味的な対応関係を、完全一致のキーワード検索より見つけやすいことがあります。
1.3 Dense retrieval における embedding model の重要性
Dense retrieval がうまく機能するのは、embedding model が検索タスクに適している場合だけです。
RAG では、質問は短い文であることが多く、保存されているチャンクはより長い文章であることが多いです。そのため、embedding model はこの 2 種類のテキストをうまく比較できる必要があります。
これはよく query-document retrieval と呼ばれます。質問は別の短い文と比較されるのではなく、文書の passage やチャンクと比較されます。
Sentence Transformers の Semantic Search では、この構成が実装の観点から説明されています。文書集合のテキストを vector space に embedding し、質問も同じ vector space に embedding したうえで、近い corpus embedding を取得します。また、似た長さのテキスト同士を比較する場合と、短い質問で長い passage を取得する場合の違いも説明されています。
1.4 大規模 dense retrieval と ANN
実装上、知っておく価値のある点がもう 1 つあります。
“Nearest-neighbor search” とは、質問のベクトルに最も近い保存済みベクトルを探すことです。小規模なデータセットであれば、質問のベクトルとすべての保存済みベクトルを比較することもできます。しかし、大規模なデータセットでは、それが遅くなることがあります。
そのため、大規模な vector search では、厳密検索ではなく近似検索がよく使われます。これは approximate nearest-neighbor search（ANN） と呼ばれます。システムは、すべての保存済みベクトルと総当たりで比較しないことで、より高速に検索します。
そのトレードオフは次の通りです。
検索が速くなる
→ 厳密検索なら見つかったはずのベクトルを一部見逃す可能性がある
Sentence Transformers の Semantic Search にある approximate-nearest-neighbor セクションでは、これが recall と speed のトレードオフとして説明されています。
2. Dense retrieval だけでは不十分な理由
Dense retrieval は、重要な手がかりが version、date、permission 条件などの正確な文字列である場合に失敗することがあります。
例えば：
Question:
"Does API v2.1 support ERR_AUTH_403?"
この質問には、いくつかの正確な文字列が含まれています。
API
v2.1
ERR_AUTH_403
“authentication errors” についてのチャンクは意味的には関連しているかもしれません。しかし、正確な API version や error code を含んでいない可能性があります。
Dense retrieval は、次のような区別を混同することもあります。
supported vs not supported
before 2024 vs after 2024
employee vs contractor
v2 vs v3
default setting vs optional setting
Retrieval score が高いということは、retriever がそのチャンクを高く順位づけしたという意味です。
それは、そのチャンクが次の条件を満たすという意味ではありません。
- 事実として正しい
- 最新である
- このユーザーが閲覧してよい
- 十分に具体的である
- 根拠として十分である
つまり、semantic similarity（意味的類似度）≠ correctness（正しさ）≠ validity（適用可能性）≠ enough evidence（十分な根拠）です。
3. Sparse retrieval
3.1 なぜ sparse retrieval が重要なのか
一部の質問は、正確な単語、identifier、記号に依存します。
例：
ERR_AUTH_403
getUserProfile()
invoice_status
v1.8.2
このような場合には、sparse retrieval（lexical retrieval とも呼ばれる） が機能します。Sparse retrieval は、テキストを単語、term、記号によって表現するからです。
BM25 は古典的な sparse retrieval 手法です。
BM25 は、Okapi の情報検索研究の流れから来ています。Okapi at TREC-3 では、TREC の検索実験の文脈で BM25 が示されています。
BM25 では、質問に含まれる重要な term を含む文書に高いスコアが与えられます。
BM25 が有用なのは、質問と文書の語彙的な重なりを評価できるからです。
例：
Question:
"What does ERR_AUTH_403 mean?"
BM25 can give higher scores to chunks that contain:
ERR_AUTH_403
3.2 BM25 scoring が大まかに考慮すること
技術的には、BM25 は単なる「完全一致」ではありません。ある term が文書内にどれくらい出現するか、また文書集合全体でどれくらい珍しいかに応じて、term に異なる重みを与えます。
Elasticsearch の BM25 similarity では、実装側から見た scoring が説明されています。BM25 は term matching に基づく lexical similarity 手法であり、term frequency と document length normalization を使います。
3.3 BM25 を機能させるために準備段階で必要なこと
ここで重要な注意点があります。
BM25 が役立つのは、identifier が検索可能な term として保持されている場合だけです。Error code、API name、version、product ID は、検索システムがそれらを直接 match できる形で保存されている必要があります。
Tokenizer、または analyzer は、文字列をどのような検索可能 term にするかを決める text-processing step です。もし ERR_AUTH_403 を不適切な形で分割してしまうと、BM25 はその identifier を安定して match できない可能性があります。
検索エンジンでは、正確な identifier には値全体を保持する field が必要になることがよくあります。Elasticsearch の keyword field type では、この exact identifier の扱いが説明されています。ID、tag、status code、version string などの値は、analyzed text field ではなく keyword field に保存されることがよくあります。
3.4 BM25 の先：neural sparse retrieval
BM25 は古典的な sparse retrieval 手法ですが、sparse retrieval は BM25 に限られません。
Neural model を使う sparse retrieval 手法もあります。SPLADE はその一例です。Sparse retrieval の考え方を保ちながら、検索のために term をどのように拡張し、重みづけするかを学習します。
4. Dense retrieval vs sparse retrieval
| Retrieval type | Other names | 主な手がかり | 得意なもの | 苦手なもの |
|---|---|---|---|---|
| Dense retrieval | Vector search / vector retrieval | Vector similarity | 言い換え、曖昧な質問、概念の一致 | 正確な文字列、小さな事実関係の違い |
| Sparse retrieval | Lexical retrieval / term-based retrieval | Term matching | Error code、API name、product ID、version | 類義語、言い換え、曖昧な意図 |
質問が dense matching と sparse matching の両方を必要とする場合、hybrid search が有用になります。
5. Hybrid search：意味と正確な語句を組み合わせる
5.1 Dense retrieval と sparse retrieval を組み合わせる
Hybrid search は、dense retrieval と sparse retrieval を組み合わせます。
例：
Question:
"Does API v2.1 support ERR_AUTH_403 during OAuth login?"
この質問には、両方が必要です。
meaning-based clue:
OAuth login / authentication support
exact-text clue:
API v2.1 / ERR_AUTH_403
Dense retrieval は、認証まわりの挙動に関するチャンクを見つけるのに役立ちます。Sparse retrieval（BM25）は、正確な identifier が無視されないようにするのに役立ちます。
この統合ステップは、しばしば fusion と呼ばれます。
Azure AI Search の Hybrid search では、full-text search と vector query を組み合わせ、その後 1 つに統合された検索結果セットを返す具体的な retrieval design が示されています。これはここで有用です。Hybrid search は単に「両方を使う」という曖昧な考え方ではなく、順位付きの検索結果を 1 つにまとめる必要があるからです。
5.2 Reciprocal Rank Fusion
Dense retrieval と sparse retrieval が別々の ranked list を生成する場合、システムにはそれらを統合する方法が必要です。よく使われる方法の 1 つが Reciprocal Rank Fusion（RRF） です。
RRF は raw score を直接比較するのではなく、順位を使います。これは有用です。Vector similarity score と BM25 score は、同じ種類の数値ではないからです。
Azure AI Search の RRF ranking では、Reciprocal Rank Fusion が複数の ranked result list を 1 つの unified ranking に統合する方法が説明されています。
6. Metadata filtering：正しい範囲の中で候補を検索する
一部のチャンクは意味的には関連していても、回答に必要な version、date、language、document type、permission の範囲から外れていることがあります。
metadata filtering
= 条件に合う範囲の中でだけ、関連するチャンクを検索する
有用な metadata には、product_version、date、language、document_type、permission_group などがあります。
Metadata filtering を機能させるには、これらの値がチャンク本文の中に書かれているだけでは不十分です。絞り込みに使える metadata として保存されている必要があります。
Qdrant では、レコードの metadata を “payload” と呼びます。Qdrant の Filtering では、payload field を vector search の絞り込み条件として使う方法が示されています。
Milvus の Filtered Search では、metadata filtering によって vector search に使う検索範囲を絞り込む方法が示されています。
Permission は relevance よりも厳格に扱うべき制約です。ユーザーがある文書を見ることを許可されていない場合、その制限対象のチャンクは単に低く順位づけされるのではなく、retrieval の時点で除外されるべきです。
7. Top-K と recall / precision のトレードオフ
Top-K = 上位 K 個の候補を返す
Top-K は一般的な検索設定です。Retriever が dense、sparse、hybrid のどれであっても、上位候補をいくつ返すかを決める必要があります。
実務上、Top-K は candidate budget です。つまり、回答準備に使える検索済みチャンクの数を制御します。
| K の大きさ | 候補数 | ノイズ | 役立つ根拠を見逃すリスク |
|---|---|---|---|
| 小さい K | 候補が少ない | ノイズが少ない | リスクが高い |
| 大きい K | 候補が多い | ノイズが多い | リスクが低い |
したがって、トレードオフは次の通りです。
役立つ根拠を見逃さない
vs
役に立たない根拠を入れすぎない
直感的には、high recall とは、役立つ根拠の大部分をうまく検索できている状態です。つまり、関連項目の見逃しが少ないということです。一方、high precision とは、検索された根拠の大部分が実際に役立つ状態です。つまり、無関係な項目の混入が少ないということです。
候補検索は通常、役立つ根拠を見逃さない方向に寄ります。なぜなら、システムは検索されたチャンクしか使えないからです。
検索されない
↓
あとで使えない
↓
最終回答を支えられない
しかし、「もっと多く検索する」ことが常に良いわけではありません。無関係な候補が多すぎると、latency、cost、後段処理での混乱が増える可能性があります。
実務上のルールはこうです。Retrieval は通常、正しい根拠を見逃さないようにすべきです。しかし、役に立たない候補を大量に後段へ渡すべきではありません。
候補検索は、それ単体で完璧な最終 Context を作る必要はありません。有用な候補集合を作る必要があります。
Stanford IR book の Evaluation of ranked retrieval results では、技術的な評価側が説明されています。Ranked retrieval では、precision と recall を上位 K 件の retrieved documents に対して考えることができます。
8. よくある retrieval の失敗パターン
検索設計が悪い状態とは、RAG システムに不適切な候補集合を渡してしまうことです。
よくある失敗には、次のようなものがあります。
| 失敗パターン | 何が起きるか | 典型的な修正 |
|---|---|---|
| Pure dense retrieval が exact term を見逃す | 結果は正しいトピックに関係しているが、正確な API name、error code、product ID を見逃す | Sparse retrieval または hybrid search を追加する。Indexing 時に identifier を保持する |
| Sparse retrieval が言い換えを見逃す | 質問が文書とは違う言葉を使っている | Dense retrieval または hybrid search を追加する |
| 検索されたチャンクは意味的に関連しているが、必要な範囲から外れている | 結果が誤った version、date、product、user group に適用される | Metadata filter を追加する |
| Top-K が小さすぎる | 正しいチャンクは存在するが検索されない | Top-K を増やす、または検索設計を改善する |
| Top-K が大きすぎる | 関連性の弱いチャンクが多すぎる状態で後段に渡される | Top-K を減らす、絞り込みを改善する、または候補を使う前により精密な ranking step を追加する |
| Retrieval score を truth として扱う | 高く順位づけされたチャンクを、正しい根拠だと仮定してしまう | 検索結果を最終的な根拠ではなく候補として扱う |
| Permission を ranking として扱う | Restricted content が検索され、後段に渡される可能性がある | Permission を retrieval の hard filter として強制する |
この表は、RAG における重要な原則も示しています。
Retrieval の問題は、retrieval より前に発生している可能性があります。
例えば、version metadata が作成されていなかった、または正しく保存されていなかった場合、version field が存在しないため、retrieval では version で絞り込めません。
Error code が parsing、tokenization、indexing の過程で壊れていた場合、BM25 はそれらを安定して match できない可能性があります。
チャンクが大きすぎる、または小さすぎる場合、dense retrieval と sparse retrieval の両方が悪化する可能性があります。
したがって、検索設計は、検索可能なデータがどのように準備されたかに依存します。
- text preparation → clean searchable text を定義する
- chunking → 検索単位を定義する
- embedding → ベクトル類似度を定義する
- filterable metadata → 何を絞り込めるかを定義する
- retrieval strategy → これらの手がかりを使って候補を見つける
References
- Sentence Transformers. Semantic Search.
- Sentence Transformers. Semantic Search: Approximate Nearest Neighbor.
- Robertson, S. E., Walker, S., Jones, S., Hancock-Beaulieu, M. M., & Gatford, M. Okapi at TREC-3.
- Elasticsearch. BM25 Similarity.
- Elasticsearch. Keyword Field Type.
- Formal, T., Lassance, C., Piwowarski, B., & Clinchant, S. SPLADE: Sparse Lexical and Expansion Model for First Stage Ranking.
- Microsoft Learn. Hybrid Search in Azure AI Search.
- Microsoft Learn. Relevance Scoring in Hybrid Search Using Reciprocal Rank Fusion.
- Qdrant. Filtering.
- Milvus. Filtered Search.
- Manning, C. D., Raghavan, P., & Schütze, H. Evaluation of Ranked Retrieval Results.