リランキング

RAGの検索精度を向上させるテクニック。初回検索で多めに候補を取得し、より精密なモデルで関連度を再評価してTop-Kに絞る。

仕組み

1. 初回検索: ベクトルデータベースでTop-20〜50件を取得
2. リランキング: 専用モデルでクエリとの関連度を再計算
3. 絞り込み: 上位5〜10件に絞ってLLMに渡す

なぜリランキングが必要か

ベクトル検索の限界

埋め込みは意味の近さを捉えるが完璧ではない：

• クエリ: 「JWTトークンの有効期限設定方法」
• 初回Top-5に含まれるもの:
  1. 「JWT概要」（関連度: 高いが回答にならない）
  2. 「トークン発行の仕組み」（関連するが的外れ）
  3. 「有効期限設定のコード例」（これが正解）
  4. 「セッション管理」（意味は近いが無関係）
  5. 「認証全般の説明」（広すぎる）

リランキングで3番を1位に引き上げることができる。

リランキングモデル

専用モデル

• Cohere Rerank API
• BGE Reranker
• Cross-encoder models

特徴

• 双方向注意機構: クエリとドキュメントを同時に見て関連度を判定
• 高精度: ベクトル検索よりも文脈を正確に理解
• 遅い: 候補1件ごとに推論が必要

リランキングの戦略

1. 2段階検索

ステップ1: ベクトル検索でTop-50（高速だが粗い）
ステップ2: リランカーでTop-5に絞る（遅いが精密）

2. LLM自身でリランキング

• LLMに候補リストと質問を渡し、「最も関連度が高いものを選んで」と依頼
• 追加のモデル不要だが、コストとレイテンシが増加

コストとレイテンシ

使い分け

• 検索精度が重要: カスタマーサポート、医療、法律 → リランキング推奨
• 速度重視: リアルタイムチャット、軽い質問 → ベクトル検索のみ
• 予算が限られる: 小規模サービス → ベクトル検索のみ

リランキングの限界

1. レイテンシ増加: 候補ごとに推論が必要で時間がかかる
2. コスト: API利用の場合、従量課金が増加
3. 過剰最適化リスク: リランカーが特定パターンに偏る可能性

ベストプラクティス

1. 初回検索は広めに: Top-20〜50件を取得
2. リランキング後は絞る: Top-5〜10件に絞ってLLMに渡す
3. キャッシュを活用: 同じクエリのリランキング結果をキャッシュ
4. 評価データで検証: リランキングが実際に精度を上げているか測定

関連

• RAG
• セマンティック検索
• ベクトルデータベース
• 埋め込み
• ハイブリッド検索
• LLM