あなたのRAGパイプラインはおそらく役に立たない。より良い代替案はこちら

検索拡張生成（RAG）は、文書と大規模言語モデル（LLM）を接続する標準的なアプローチとして登場しました。そのパターンは単純です：コーパスを埋め込み、ベクトル類似性によって最も関連性の高いチャンクを検索し、プロンプトに注入します。デモや多くの本番システムではうまく機能しますが、スケールが大きくなると予測可能な方法で失敗することもあります。

最も一般的な失敗パターンは検索の非関連性です。ユーザーが育児休暇ポリシーをクエリすると、検索エンジンは2022年版、2024年版、および文化的なブログ記事を返します。各チャンクはクエリと語彙を共有するため埋め込み距離が高くなりますが、ユーザーが実際に尋ねた質問には答えていません。モデルは検索されたコンテンツが古いかトピック外であることを知らず、複数のチャンクを混ぜ合わせて、自信に満ちた詳細な、しかし事実に反する回答を生成します。これは語彙的類似性であり事実上の関連性ではありません。これが本番RAGシステムにおける主要な失敗モードです。

より微妙なバージョンはコンテキスト汚染です。エンタープライズナレッジベースには同じポリシードキュメントの複数バージョンが含まれていることがよくあります。検索エンジンが両方のバージョンからチャンクを返すと、モデルは矛盾を浮き彫りにしません。1つを選ぶか、両方を混ぜるか、自信に満ちた合成を提示します。読者は回答を得ますが、その回答は間違っている可能性があります。ユーザーもモデルもそのことを知りません。

根本的な原因はチャンク-埋め込み-検索パイプラインにおける構造的な対立です。良好な再現率を得るには、フォーカスされた検索のために約100～256トークンの小さなチャンクが必要です。良好なコンテキスト理解を得るには、一貫性のために1024トークン以上の大きなチャンクが必要です。すべてのRAG設計者はどちらかを選び、トレードオフを受け入れます。

標準のRAGが期待通りに機能しない場合、一般的な修正はより複雑にすることです：より高次元の埋め込み、より洗練された再ランク付け、複数ステップの検索。これにより問題が悪化します。あるグローバル製造企業はRAGシステムに40万ドルの予算を計上しましたが、初年度のコストは120万ドルに達し、技術文書クエリの最終精度は23％でした。プロジェクトは中止されました。ある医療関連企業は6か月目までにベクターデータベースのコストが月額7万5千ドルに達しました。これらの結果はより広範なパターンを反映しています：2025年のエンタープライズRAG導入の初年度失敗率は72％でした。高次元の埋め込みやより洗練されたベクトルモデルは自動的にパフォーマンスを向上させるわけではなく、計算コストを引き上げ、より有用な質問を遅らせるだけです：そもそも検索アーキテクチャが正しい選択だったのか。

RAGが失敗した場合の代替案は以下の通りです。

長コンテキストプロンプティング：苦労しているRAGパイプラインを過度にエンジニアリングする代わりに、検索を完全にスキップします。コーパスがモデルのコンテキストウィンドウに収まる場合は、それを読み込んでモデルに読ませます。ベンチマーク研究によると、長コンテキストLLMは計算リソースが利用可能な場合、QAタスクでRAGを一貫して上回り、チャンクベースの検索は最も劣っていました。コストのトレードオフは重要です：100万トークンでのレイテンシはRAGパイプラインより30～60倍遅く、クエリあたりのコストは約1250倍です。ただし、高トラフィックアプリケーションではプロンプトキャッシングにより長コンテキストがコスト競争力を持つ可能性があります。一般的な判断ルール：コーパスがコンテキストウィンドウに収まり、クエリ量が中程度であれば、長コンテキストプロンプティングがよりクリーンな出発点です。コーパスがウィンドウを超える、レイテンシがSLOに違反する、またはクエリ量が経済的損益分岐点を超える場合にのみ、検索を追加します。

メモリ圧縮：コーパスがコンテキストウィンドウに対して大きすぎる場合は、検索前に要約します。要約ベースの検索は、生のチャンクを抽出する代わりに、注入前に文書を圧縮します。ベンチマークでは、このアプローチは完全な長コンテキスト手法と同等のパフォーマンスを示し、チャンクベースの検索は両方に一貫して劣ります。具体的な結果：48Kの適切に選択されたトークンを使用した順序保存RAGアプローチは、117Kトークンのフルコンテキスト検索を13F1ポイント上回り、トークンバジェットは7分の1でした。適切に圧縮された関連文書は、おおよそ関連するチャンクの生のダンプよりも優れています。

構造化検索：検索が正しいアーキテクチャである場合、解決策はより良い埋め込みを均一に適用するのではなく、クエリタイプによってルーティングすることです。EMNLP 2024の研究で導入されたSelf-Routeは、クエリを実行する前に、モデルにクエリが全文コンテキストを必要とするかフォーカスされた検索を必要とするかを分類させます。単純な事実のルックアップはフォーカスされたRAGに送られ、全体的な理解を必要とする複雑なマルチホップ質問は長コンテキストに送られます。結果は、より低い計算コストでより良い全体的な精度です。このハイブリッドアプローチを使用する適応型システムは、ハイブリッド検索と再ランク付けによって15～30％の検索精度向上を示しています。重要な変更はルーティングを明示的にすることです：すべてのクエリは検索が実行される前に分類され、システムはすべてのクエリを同一の埋め込み問題として扱うことを止めます。

グラフベース推論：特定のパッセージを取得するのではなく、データセット全体の関係を理解する必要があるクエリの場合、ベクトル検索は設計上失敗します。これらはマルチホップ質問です：取締役会が第3四半期にどの決定を覆し、その理由は毎回何だったのか？単一のチャンクではこれに答えられません。答えは文書間のつながりにあります。マイクロソフトリサーチは2024年にGraphRAGを導入しました。このシステムはコーパスからナレッジグラフを構築し、ベクトルをマッチングする代わりにエンティティ関係をトラバースします。これは標準のRAGが処理できない失敗ケース、つまり関係推論を必要とする文書間の統合を直接扱います。トレードオフはコストです：ナレッジグラフの抽出はベースラインRAGの3～5倍のコストがかかり、ドメイン固有のチューニングが必要です。GraphRAGはテーマ分析やマルチホップ推論には価値がありますが、単一パッセージの事実ルックアップには必要ありません。

RAGは多くのユースケースで合理的なデフォルトですが、予測可能な方法で壊れます：語彙は一致するがセマンティクスが異なる場合の検索非関連性、矛盾するバージョンがコーパスに存在する場合のコンテキスト汚染、チャンクサイズが再現率と一貫性の両方を満たせない場合の構造的限界。壊れた検索設計に複雑さを追加すると、それらの問題がより高価になります。状況に応じて4つのより良い道があります：コーパスがコンテキストウィンドウに収まる場合は長コンテキストプロンプティングが検索問題を完全に回避、コンテキスト圧縮が必要な場合は検索前の要約が生のチャンク検索より優れる、クエリタイプが多様な場合は明示的なルーティングと構造化検索が精度とコストを改善、クエリが文書間の関係統合を必要とする場合はグラフベース推論が適切なアーキテクチャ。アーキテクチャをクエリタイプに合わせてください。