本番運用RAGガイド: なぜリトリーバルは失敗するのか、どう直すのか

2026年において、素朴なRAG — 固定長チャンキング + 単一ベクトルの類似度検索 — は約40パーセントのケースで正しいコンテキストを取れない。ドキュメント集合が大きくなり、クエリが具体的になるほどこの数値は上がる。生成器は仕事をしている。リトリーバが必要な材料を渡していないだけだ。

根本原因は4つ。それぞれに対応する修正があり、修正は投資対効果順に並んでいる。上から順に取り組もう。

固定長チャンキング — 内容を見ずに512や1,024文字ごとに区切るやり方 — は文を途中で切り、質問を回答から引き離し、その一節を意味あるものにしているコンテキストを落とす。埋め込みモデルは不完全な観念をエンコードする。類似度スコアは本来より低くなる。リトリーバは外す。

どの戦略を選ぶにせよ、デプロイ前にサンプルクエリ集合での再現率指標で検証すること。チャンキングの品質は、計測するまで見えない。

ベクトル検索は意味的に類似する一節を取り出す — 言い換えや概念マッチングに強いが、完全一致のキーワードを外す。BM25は完全一致や希少語に強いが、意味関係を取り逃す。多様なクエリ種別をさばく本番RAGには、いずれか単独では不十分だ。

ハイブリッド検索は両方を並列で走らせ、ランクリストを Reciprocal Rank Fusion で融合する。ハイブリッド検索とコンテキスチュアル手法を組み合わせると、エラー率は素朴なベクトル単独検索に比べて約69パーセント低下する。実装は本番ベクトルストアならどれでも素直だ。Weaviate はハイブリッド検索を標準で出荷、Pinecone は2025年に追加、pgvector は BM25 インデックスと手動で組み合わせる必要がある。

リランキングのステップは独立で強調する価値がある。クロスエンコーダモデルは取得済みの各チャンクを元クエリに対してフルアテンションで再スコアする — クエリとチャンクを一緒に見る点で、両者を別々にスコアするバイエンコーダと異なる。典型的な本番パイプラインは、ハイブリッド検索でトップ50を取得し、クロスエンコーダでトップ5にリランキングし、その5チャンクを言語モデルに渡す。コストは小さく、精度の改善は実質的だ。

本番安全性で最重要なのは faithfulness だ。faithfulness が0.85未満ということは、モデルが取得した内容に裏付けられていない主張を恒常的に生成しているということ — それは定義上のハルシネーションだ。デプロイ前に検索を直すか top-k を増やすこと。

RAGAS の評価はユーザリクエストとインラインで走らせず、本番トラフィックのサンプルに対して非同期で走らせる。応答パイプラインを評価でブロックすると、レイテンシが増えるだけでユーザには何の恩恵もない。集めて、夜間に評価し、閾値の逸脱でアラートを上げる。

素朴なRAGはどんなクエリにも同じことをする: 取得して生成。アダプティブRAGはその前段に分類ステップを置く。単純な事実確認のクエリは高速ベクトル検索に流す。複雑な多段クエリは反復検索や階層検索に流す。ナレッジベース外のクエリは検索を飛ばし、モデルのパラメトリック知識へ直接ルーティングする。

ルーティングロジックは多くの場合、小さなLLM呼び出しか分類器だ。コストは低く — 数ミリ秒と数トークン — 精度の向上は有意だ。検索の信頼度が低いとき検索をスキップするシステムは、常に検索して低品質コンテキストを渡すシステムよりハルシネーションがはるかに少ない。

2026年に新しくRAGシステムを構築するなら、最初からアダプティブルーティングを前提に設計すること。後から追加するには検索パイプラインを構成し直す必要があり、ラップするだけでは済まない。

RAGをメモリやナレッジ層として使う本番のエージェンティックAIシステムについては、私の エージェンティックAIコンサルティングサービス を参照してほしい。検索がより広いエージェンティックアーキテクチャの中でどう位置づくかをカバーしている。