RAG（検索拡張生成）が「それっぽいのに的外れ」な答えを返すとき、原因のほとんどは生成モデルではなく検索（Retrieval）の質にあります。必要な根拠を上位に拾えていなければ、どんなに優秀なモデルでも正しく答えようがありません。本章では、検索品質を底上げする2本柱――ハイブリッド検索とリランカー（再ランキング）――を、仕組みから実務の勘所まで具体的に整理します。
FIG.1 検索品質の改善は「広く拾って、厳しく絞る」二段構えが基本形
01なぜ検索が9割なのか
RAGは「検索した文書を根拠としてLLMに渡し、それを基に答えさせる」仕組みです。だからこそ、渡す前の検索で正しい根拠を拾えていなければ、回答は構造的に正しくなりません。LLMは渡された材料からしか答えを作れず、材料が間違っていれば自信たっぷりに間違えます。
逆に言えば、検索の精度を上げることが、モデルを高価なものに替えるより費用対効果の高い改善になりがちです。検索品質の指標としては、正しい根拠が上位K件に入っているか（例：Top-5の再現率＝Recall@5）が実務でよく使われます。公開ベンチマークでも、後述の二段構えはこの再現率を単段の検索より明確に押し上げることが報告されています。
02ハイブリッド検索：得意分野の違う2つを足す
検索には大きく2つの方式があり、それぞれ得意・不得意が逆です。
| ベクトル検索（密／dense） | キーワード検索（疎／sparse・BM25） |
|---|---|
| 文を意味のベクトルに変換し、意味の近さで拾う | 語の出現を統計的に評価し、一致で拾う（BM25が定番） |
| 言い換え・表記ゆれ・同義語に強い | 型番・条文番号・固有名詞・略語など「字面の一致」に強い |
| 未知の専門用語や厳密な一致は取りこぼしやすい | 言い回しが違うだけで拾えないことがある |
ハイブリッド検索は、この2方式を同時に走らせて結果を統合する手法です。「型番Z-440の不具合対応」のように、意味（不具合対応）と厳密一致（Z-440）の両方が要る質問で特に効きます。片方だけでは必ずどちらかの質問型を取りこぼすため、両取りで取りこぼしを減らせます。
