実際に効く検索拡張
多くの RAG パイプラインが冴えない理由と、効く打ち手:チャンク分割、ハイブリッド検索、再ランク、引用の規律。
原因は生成ではなく検索にあることが多い
RAG の回答が誤っていると、チームはモデルを疑いがちです。まず測りましょう。正しい記述がそもそも検索で取れていたかを確認します。
- その記述は取れていたか? 否 → 検索の問題
- 取れていたのに無視された? → コンテキスト/プロンプトの問題
- 取れていても誤答? → ここで初めてモデルを見る
「ハルシネーション」と診断された症例の多くは最初のケースです。
チャンク分割は結果を変える
チャンクサイズは最も効くノブで、普遍的な正解はありません。適切な大きさは「1 つの質問に答える最小の証拠単位」で決まります。
- 事実ベースの Q&A:小さめ(200〜400 トークン)、1 チャンク 1 論点
- 手順書:手順全体を切らずに。ステップを分断すると答えが壊れる
- 法務・規程:条項単位。文中で切らず、見出しを各チャンク本文に含める
最後の点は一般化できます。構造的文脈(タイトル、見出し階層)を前付けする ことです。「期限は 30 日」という断片は、どの規程か分からなければ無意味です。
| 文書種別 | 分割境界 | 理由 |
|---|---|---|
| FAQ | Q&A 1 組 | 自己完結している |
| API リファレンス | エンドポイント 1 件 | 説明とパラメータが分離するため |
| 物語文 | 段落、10〜15% オーバーラップ | 流れを保つ |
| コード | 関数またはクラス | 構文単位、import 込み |
単独よりハイブリッド検索
- ベクトル検索:意味や言い換えに強いが、エラーコード・SKU・固有名などの完全一致に弱い。
- キーワード/BM25:正確なトークンに強いが、同義語や概念検索に弱い。
両方走らせて統合します。単純な和集合でも実務では単独より良く、スコア融合(RRF)ならさらに良く、実装も簡単です。
ERR_2049 や Model-3B のような検索があるなら、キーワード検索は任意ではなく必須です。
生成の前に再ランク
top-k=20 の取得は安価で、それを厳密な top-5 に再ランクすると回答品質が大きく上がります。パターンは次:
- 20〜50 件を取得(高速・再現率重視)
- クロスエンコーダや LLM で関連度を採点し並べ替え
- 上位 3〜5 件だけを生成に渡す
呼び出しが 1 回増えるだけで、「誤った記述を取得」する失敗の多くが直ります。
引用を強制し、検証する
各主張にチャンク ID の引用を必須にします。利点は 2 つ。ユーザーが検証できることと、引用されたチャンクが本当にその主張を含んでいるかを機械的に検査できる ことです。
回答させた後、採点器で抜き取り確認します。チャンク X は文 Y を裏付けるか。取得済みチャンクを安定して引用する回答は、記憶から言い換えた回答よりはるかに信頼できます。
測るべき指標
| 指標 | 分かること |
|---|---|
| Recall@k | 正しいチャンクが候補に入ったか |
| 引用精度 | 引用チャンクは本当に主張を支えるか |
| 有効文脈なし率 | 検索が無駄骨に終わる頻度 |
| チャンク利用率 | 取得したチャンクが実際に参照されたか |
再現率が高く利用率が低いなら、コンテキストにゴミを詰めている証拠です。増やすのではなく k を減らします。