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）の両方が要る質問で特に効きます。片方だけでは必ずどちらかの質問型を取りこぼすため、両取りで取りこぼしを減らせます。
FIG.2 RRF（Reciprocal Rank Fusion）＝両方の順位を逆数で足し、統合ランキングを作る
2つの結果をどう混ぜるかでよく使われるのが RRF（Reciprocal Rank Fusion） です。各文書について「ベクトル検索で何位だったか」「キーワード検索で何位だったか」を、順位の逆数（おおむね 1/(k＋順位)）で足し合わせて並べ替えます。ポイントはスコアの絶対値ではなく順位だけを使うこと。ベクトル検索とBM25ではスコアの尺度がそもそも違うため単純な加重平均は破綻しやすいのですが、RRFは順位で扱うのでこの問題を回避できます。定数 k は60前後が無難な初期値で、小さくするほど上位の順位を重視します。一次検索の取得件数（各方式 50〜200 件程度）はリランカーに渡す前提で広めに取るのが一般的です。
03リランカー：広く拾った候補を「精査」して並べ替える
ハイブリッド検索で候補を広く集めたあと、リランカー（再ランキングモデル）で質問との関連度を厳密に測り直して並べ替えます。手順はシンプルです。
広く取得する
ハイブリッド検索で候補を多め（例：上位50〜100件）に集める。ここでの目標は「正解を取りこぼさない」こと（再現率重視）。
関連度を測り直す
リランカーが、質問と各候補を1組ずつ突き合わせて関連度スコアを付け直す。一次検索より精密だが計算は重い。
上位だけを渡す
並べ替えた上位（例：5〜10件）だけを生成プロンプトに渡す。無関係な候補が減り、ノイズと文脈コストを抑えられる。
なぜ一次検索より精度が高いのか。鍵は仕組みの違いです。通常のベクトル検索が使う埋め込みモデル（バイエンコーダ）は、質問と文書を別々にベクトル化してから距離を測ります。速い代わりに、両者の細かい対応関係までは見ていません。一方リランカーの主流であるクロスエンコーダは、質問と文書を1つの入力として一緒にモデルへ通し、質問の各語が文書の各語に「注目」し合った上で関連度を算出します。だから精密ですが、候補1件ごとに毎回モデルを走らせるため重くなります。
FIG.3 別々に符号化する一次検索 vs 一緒に符号化して精査するリランカー
実際のリランカーは、ホスティング型API（例：Cohere Rerank、Voyage rerank など）と、オープンソースで自前運用できるもの（例：BGE Reranker、軽量な FlashRank など）に分かれます。どれを選ぶかは精度・遅延・コスト・データを社外に出せるかで決めます。料金やモデルのラインナップは頻繁に変わるため、採用時は必ず公式の最新情報を確認してください。
RAGの品質は、最終的に「上位5件に正解を載せられるか」で決まる。広く拾い、厳しく絞る。
04二段構えはどれくらい効くのか
「ハイブリッド検索 → リランカー」の二段構えは、公開ベンチマークでも単段の検索を一貫して上回ることが報告されています。たとえばテキスト＋表を含む文書群の評価では、二段構えの Recall@5 が単独のハイブリッド検索を明確に上回る結果が示されています。リランカー追加による上積みは、用途やデータにもよりますが、関連性指標（NDCG@10など）で数ポイント規模の改善として観測されるのが一般的です。「単に動くRAG」と「実際に正しく答えるRAG」の差が、ここで生まれることが多いのです。
ただし数値はデータセット・ドメイン・設定に強く依存します。他社の数字をそのまま自社に当てはめず、自分たちの評価データで測ってから採否を決めるのが鉄則です。
05検索品質を上げる、その他の打ち手
チャンク設計の見直し
精度問題の多くは「切り方」が原因。長すぎ／短すぎ、文脈の途切れを直すだけで効くことが多い。検索の前段として最優先で点検。
クエリ書き換え
曖昧・口語的な質問を検索向けに整える。同義語の補完や、複数の検索クエリに分解して候補を広げる手も。
メタデータフィルタ
部署・製品・年度・文書種別や閲覧権限で先に対象を絞る。ノイズが激減し、関連度の母数が改善する。
これらは併用できますが、足せば足すほど良いわけではありません。工程が増えるほど遅く・高くなり、運用も複雑になります。次の鉄則を守ってください。
Evaluate Before You Adopt
「効いた気がする」で入れない
改善策はどれも、入れれば賢くなりそうに見えます。だからこそ危険です。プロンプト評価の章と同じ原則がここでも効きます――評価用のQ&Aセットで効果を測ってから採用する。30〜100問の小さなテストセットでも、改善が本当に効いたのか／むしろ悪化したのかが見えるようになります。
FIG.4 改善案は評価セットで「効果・遅延・コスト」を測ってから採否を決める
見るのは精度だけではありません。遅延とコストも同時に測ります。たとえばクロスエンコーダのリランクは、候補50件規模でも構成によってCPU上で数百ミリ秒オーダーの追加になることがあります（軽量実装やAPI利用で大きく変わる）。精度の上積みと応答時間・費用が見合うかは、必ず自分の環境で確かめてください。
06本章のまとめ
実用RAGの核心は「検索が9割」。検索品質を上げる基本形は、得意分野の違うベクトル検索とキーワード検索をRRFで統合するハイブリッド検索で広く拾い、クロスエンコーダのリランカーで厳しく絞り込む二段構えです。さらにチャンク設計・クエリ書き換え・メタデータフィルタが土台を支えます。
そして何より――足した改善は必ず評価データで効果（と遅延・コスト）を計測してから採用する。やみくもに積み上げると、遅く・高くなるだけで賢くはなりません。広く拾い、厳しく絞り、必ず測る。これが検索品質を上げる王道です。
