2026年9月24日。RAGの回答品質を上げようとして、ベクトル検索の件数やプロンプトだけを調整しても、検索候補に必要な文書が入っていなければ改善には限界があります。検索では「候補を漏らさず集める段階」と「候補を質問に合う順へ並べ直す段階」を分けて設計します。
この記事は、公開ドキュメントをもとにした設計案です。自社データセットでの検索評価や本番運用の実績を示すものではありません。
技術的な問いと前提
製品番号や固有名詞は語句一致が強く、言い換えられた質問は意味の近さが重要です。単一の検索方式では、どちらかの要求を取りこぼすことがあります。
ここでの問いは「どの検索方式が最強か」ではなく、「検索漏れを抑えながら、生成モデルへ渡す候補をどう選ぶか」です。検索結果は回答の根拠候補であり、順位が高いこと自体は正しさの証明になりません。
設計選択肢を比較する
| 方式 | 得意な場面 | 主な弱点 |
|---|---|---|
| BM25などの語句検索 | 製品名、型番、エラーコード、正確な語句 | 言い換えや表現の違いに弱い |
| ベクトル検索 | 質問と文書の意味的な近さ | 固有語の一致や数値条件を落とすことがある |
| ハイブリッド検索 | 語句一致と意味検索の候補を組み合わせる | 異なる尺度のスコアを混ぜる設計が必要 |
| リランキング | 取得済み候補を質問との関連度で再評価する | 候補に入らなかった文書は復活できず、追加の計算時間もかかる |
ハイブリッド検索とリランキングは代替関係ではありません。前者は候補集合を作る検索段階、後者はその候補集合の順位を調整する段階です。
採用する責務分担
まず語句検索とベクトル検索を並行して実行し、候補一覧を統合します。スコアの尺度が異なる場合は、固定の重みを根拠なく足すより、順位に基づくRRF（Reciprocal Rank Fusion）など、統合方法を明示します。そのうえで上位候補だけをリランカーに渡します。
質問
├─ 語句検索 ─────┐
└─ ベクトル検索 ─┴─ 候補を統合 → 重複除去 → 上位候補を再順位付け
↓
根拠・鮮度・権限を検査 → 回答または人手確認
RRFは各検索結果での順位を使って統合し、元のスコア値を直接比較しません。スコア差の情報を活用したい場合は、正規化したスコアを組み合わせる設計もあります。どちらを選ぶかは、検索ログと評価用クエリで比較します。
リランキングでは、質問と各候補文書を一緒に見て関連度を判定するクロスエンコーダなどを使えます。すべての文書を毎回再評価するのではなく、第一段階で候補を絞ってから適用します。候補数を増やせば見落としを減らせる可能性がある一方、推論回数・遅延・費用も増えるため、件数は測定して決めます。
実装で固定する境界
検索結果をそのまま回答モデルへ渡す前に、少なくとも次を別々に記録します。
- 第一段階の方式ごとの順位と、統合後の順位
- リランキング前後の文書ID、モデル識別子、実行時間
- 文書の版・更新日時・アクセス条件
- 最終回答で引用した文書IDと該当箇所
検索スコアを「回答の信頼度」と読み替えないことが重要です。リランカーが関連文書を上位にしても、記述の矛盾、情報の古さ、権限外の文書までは自動的に解決しません。回答前に根拠箇所、文書の鮮度、利用者の閲覧権限を別の品質ゲートで確認します。
失敗とトレードオフ
候補集合が狭すぎると、リランカーは不足した情報を補えません。検索段階のRecallを評価し、候補数を上げる余地を調べます。
候補集合を広げすぎると、再順位付けの時間と費用が増え、無関係な文書が混ざる余地も増えます。上位何件を渡すかは固定の正解があると考えず、実クエリで品質と遅延を同時に測ります。
異なる検索スコアをそのまま加算すると、値の尺度や分布の違いが順位を支配することがあります。RRFかスコア正規化かを選び、検索評価セットで比較します。
検索精度だけを見ると、回答の誤引用や古い情報を見逃します。検索評価と、根拠付き回答の評価を分けて追います。
本番運用で測ること
評価用クエリには、型番などの完全一致、言い換え、複数条件、該当文書なし、古い版と新しい版が競合するケースを含めます。候補段階ではRecall@k、最終順位ではMRRやnDCGなどを使い、回答段階では根拠との整合性、引用の正確さ、回答不能時の振る舞いを人手の判定基準と合わせて確認します。
本番では検索方式別の遅延、リランキング対象件数、タイムアウト率、空振り率を監視します。リランカーがタイムアウトしたときに第一段階の順位へフォールバックするなら、その事実をログに残し、通常経路と同じ品質として集計しないようにします。品質が確認できない質問では、無理に回答を作らず人手確認へ送る境界も設けます。
次に改善すること
最初に評価用クエリと正解文書の組を作り、語句検索、ベクトル検索、ハイブリッド検索、リランキング追加の順に比較します。一度に複数の設定を変えず、検索候補の取りこぼしと順位の誤りを分けて調べると、改善箇所を説明しやすくなります。
参考リンク
- OpenSearch: Hybrid search
- OpenSearch: Reciprocal rank fusion
- OpenSearch: Normalization processor
- Elasticsearch: Semantic reranking
- Elasticsearch: Text similarity re-ranker retriever
同様の仕組みの設計・構築・運用については相談可能。
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。