6月29日、KDNuggetsが「Your RAG Pipeline Is Probably Useless. Here's a Better Alternative」と題した記事を公開した。エンタープライズRAG実装の初年度失敗率が**72%**に達するという統計が示すように、デモで動くRAGが本番規模で壊れるのは偶然ではなく、構造的な必然だ。

RAG（Retrieval-Augmented Generation）は、ドキュメントコーパスをベクトル化し、クエリに近いチャンクを取得してLLMのプロンプトに注入するという設計で、デモや多くの本番システムでは機能する。しかし、規模が大きくなると予測可能な形で壊れる。

RAGが本番で失敗する理由

最も頻出する失敗が「検索の無関連性（retrieval irrelevance）」だ。たとえば育児休業ポリシーを問い合わせると、2022年版・2024年版の文書と社内ブログ記事が返ってくる。それぞれ語彙的には近いためスコアが高く、モデルはそれを正しい文脈として受け取り、自信満々に事実として間違った回答を生成する。トピックが類似しているだけで、事実として関連しているわけではない。

より厄介なのが「コンテキスト汚染（context poisoning）」だ。企業のナレッジベースには同一ポリシーの複数バージョンが混在していることが多い。チャンクが両方返ってきてもモデルは矛盾に気づかず、どちらかを選ぶか、あるいは両者を混ぜ合わせた回答を返す。ユーザーは答えを得た気になるが、その答えは間違っている。

根本的な原因はチャンクサイズのジレンマにある。高い再現率（recall）のためには100〜256トークン程度の小さなチャンクが必要で、文脈の一貫性のためには1,024トークン以上が必要だ。どちらかを選べば、もう一方を犠牲にするしかない。

「複雑化」という間違った解法

標準的なRAGが機能しないとき、多くの現場が選ぶのは「より高次元の埋め込み」「多段階検索」「洗練されたリランキング」だ。これは問題を深刻にするだけだ。

記事が引用した実例は厳しい。ある製造業の企業はRAGシステムに40万ドルの予算を組んだが、初年度のコストは120万ドルに膨らんだ。技術文書への回答精度は23%でプロジェクトは終了。あるヘルスケア企業では6ヶ月目にベクトルDBのコストが月7.5万ドルに達した。記事はこうした事例の背景として、2025年におけるエンタープライズRAG実装の**初年度失敗率が72%**に上ると言及しているが、この統計の一次ソースは元記事内では明示されておらず、あくまで記事著者が示した数字として参照されている点は留意が必要だ。

状況に応じた4つの代替アーキテクチャ

1. ロングコンテキストプロンプティング

コーパスがモデルのコンテキストウィンドウに収まるなら、検索を丸ごとスキップしてすべてのドキュメントをそのまま入力する方法が有効だ。arXivのベンチマーク研究では、コンピューティングリソースが確保できる環境でロングコンテキストLLMがQAタスクでRAGを一貫して上回り、チャンクベースの検索が最も遅れを取ったと報告されている。

コスト面では注意が必要だ。100万トークン規模では、レイテンシはRAGパイプラインの30〜60倍、クエリあたりのコストは約1,250倍になる。ただし高トラフィックなアプリケーションではプロンプトキャッシングによりコスト競争力が生まれる。

判断基準はシンプルだ。コーパスがコンテキストウィンドウに収まり、クエリ量が中程度であれば、ロングコンテキストから始めるのが筋がいい。コーパスがウィンドウを超えるか、レイテンシがSLOに違反するか、クエリ量が経済的損益分岐点を超えたときに初めて検索を追加する。

2. メモリ圧縮（要約ベース検索）

コーパスがコンテキストウィンドウに収まらない場合、生チャンクを取得する前に要約でドキュメントを圧縮してから注入する手法が有効だ。前述のベンチマークによれば、この手法はフルコンテキスト手法と同等の精度を示し、チャンクベース検索を一貫して上回る。

具体的な数字として、4.8万トークンの精選されたトークン群を使った順序保持RAGが、11.7万トークンのフルコンテキスト検索をF1スコアで13ポイント上回り、トークン予算は7分の1だったという結果がある。関連性の高い圧縮済みドキュメントは、周辺的なチャンクの生ダンプより強い。

3. 構造化検索（クエリルーティング）

検索自体が適切なアーキテクチャである場合、解決策は「より良い埋め込み」ではなくクエリタイプによるルーティングだ。

EMNLP 2024で発表された「Self-Route」は、実行前にモデルがクエリを分類し、単純な事実検索はフォーカスRATに、複雑なマルチホップ質問（複数文書にまたがる推論が必要なもの）はロングコンテキストに振り分ける手法だ。精度向上とコスト削減を両立する。

重要なのはルーティングを明示的に行うことだ。すべてのクエリを同じ埋め込み問題として扱うのをやめ、検索前に必ず分類する。

4. グラフベース推論（GraphRAG）

「Q3に取締役会が覆した意思決定と、その都度の理由は？」のような問いに、単一チャンクは答えられない。答えは文書間のつながりにある。

Microsoftが2024年に発表した**GraphRAG**は、コーパスから知識グラフを構築し、ベクトルマッチングではなくエンティティ間の関係をトラバースする手法だ。テーマ分析や複数ドキュメントにまたがる関係的推論に有効で、標準RAGが構造的に対処できない合成クエリを直接解決する。

トレードオフはコストだ。知識グラフの抽出はベースラインRAGの3〜5倍のコストがかかり、ドメイン固有のチューニングも必要になる。単純な事実検索にGraphRAGは過剰だが、関係的推論が必要な用途では投資に見合う。

まとめ

RAGは多くのユースケースで合理的なデフォルト選択だ。しかし壊れ方は予測可能であり、壊れた設計に複雑さを重ねてもコストが増えるだけだ。記事の結論はシンプルだ。アーキテクチャをクエリタイプに合わせること。コーパスがウィンドウに収まるならロングコンテキスト、圧縮が必要なら要約ベース、クエリが多様なら明示的ルーティング、関係的合成が必要ならグラフベース推論を選ぶ。

※編集部の考察：日本のエンタープライズ現場では、社内文書の多言語混在や文書バージョン管理の甘さがコンテキスト汚染をさらに深刻にしやすい。「まずデモで動かす」ことと「本番で設計する」ことを最初から分けて考える習慣が、RAG導入を成功させる上での出発点になるだろう。

詳細はYour RAG Pipeline Is Probably Useless. Here's a Better Alternativeを参照していただきたい。