6月26日、Google CloudのMLエンジニアであるDr. Roushanak Rahmatが「Beyond RAG: The Evolution of Knowledge Augmentation (CAG vs. RAG vs. CRAG)」と題した記事を公開した。「RAGを導入した」で思考が止まっていないか——本番AIシステムで顕在化しつつある検索品質・レイテンシ・コストの問題を正面から問い直し、RAG・CAG・CRAGという3つのアーキテクチャのトレードオフと使い分けを整理している。
RAGは「標準」だが、限界も見えてきた
近年、エンタープライズAI開発における知識拡張の定番手法としてRAG（Retrieval-Augmented Generation）が広く普及してきた。ユーザーのクエリに応じてリアルタイムで外部ナレッジベースを検索し、取得した情報をプロンプトに注入する仕組みだ。
RAGの強みはスケーラビリティにある。頻繁に更新される大規模かつ多様なデータセットに対して、ソースを明示しながら回答を生成できる。一方でレイテンシの増大と検索のズレ（retrieval drift）という課題が本番環境で顕在化しつつある。「どのドキュメントを取得するか」の精度がそのまま出力品質に直結するため、検索ロジックの設計と評価が常に問われる構造になっている。
CAG：検索を「事前に」済ませてしまう
記事が「レイテンシキラー」と呼ぶCAG（Cache-Augmented Generation）は、RAGの発想を根本から逆転させる。クエリが来るたびに検索するのではなく、ナレッジベース全体をLLMのコンテキストウィンドウにKV（Key-Value）キャッシュとして事前ロードしておく手法だ。CAGに関する先行研究としては、Chan et al.（2024）"Don't Do RAG: When Cache-Augmented Generation is Better than Retrieval Augmented Generation"が参考になる。
ユーザーがクエリを送る前に「プリフィル」フェーズを完了させることで、通常の検索では実現できないサブ秒レベルの応答速度が得られる。検索インフラそのものが不要になるため、運用コストの削減という観点でも注目される。
ただし制約は明確だ。モデルのコンテキストウィンドウサイズに厳しく縛られる上に、データが頻繁に変わる場合はキャッシュの再計算コストが重くなる。静的で予測可能なデータセットに対して、速度が最優先要件である場合に適している。
CRAG：「検索失敗」を自己修正するパイプライン
記事の中で最も面白い進化として紹介されているのがCRAG（Corrective RAG）だ。CRAGはYan et al.（2024）"Corrective Retrieval Augmented Generation"で提案されたアーキテクチャで、RAGの検索品質問題を構造的に解決しようとするアプローチである。
本番RAGシステムの大きな失敗パターンのひとつが「質の低い検索結果に基づいたハルシネーション」である。CRAGはこの問題に対して、パイプラインに検索品質の評価ステップを組み込むことで対処する。
仕組みはシンプルだ。ドキュメント取得後、システムがその品質を評価する。取得した情報が無関係または低品質と判断されると、ウェブ検索の実行や代替ソースへの切り替えといった「修正アクション」を自動でトリガーし、LLMが回答を生成する前に情報の品質を担保する。
ノイズが多く整備されていないデータ環境や、誤った出力を許容できないユースケースに適している。一方でパイプラインが複雑化する分、レイテンシとインフラコストはRAGより高くなりやすい点は設計時に織り込んでおく必要がある。
3つの使い分け：判断基準は「コスト・レイテンシ・正確性」
記事は3つの手法の選択基準を整理している。本文で明示された判断軸であるコスト・レイテンシ・正確性の観点で各手法の特性をまとめると以下のようになる。
| 手法 | コスト | レイテンシ | 正確性・信頼性 | 向いているケース |
|---|---|---|---|---|
| RAG | 中 | 中〜高 | 検索精度に依存 | データが頻繁に更新され、ソースの明示が必要な場合 |
| CAG | 低（検索インフラ不要） | 最小 | コンテキスト範囲内で高い | ナレッジベースが比較的静的で、即時応答が求められる場合 |
| CRAG | 高 | 高（評価ステップ分） | 最も高い | 検索ソースの信頼性が低く、自己修正パイプラインが必要な場合 |
Google Cloudのサービスとの文脈では、Vertex AI SearchやVertex AI RAG Engineがこれらのアーキテクチャを実装する際の基盤として参照されることが多い。
記事は最後にこう問いかけている。「『うちのRAGは完璧だ』と言う人がいたら、深く掘り下げてほしい。検索失敗をどう処理しているか？レイテンシへの影響は？モデルに渡すコンテキストがユーザーの意図に本当に沿っているか？」
RAGを「入れれば終わり」とせず、評価パイプラインまで設計することが本番品質の分岐点になる、というのが本記事の核心だ。3手法はいずれも優劣があるのではなく、ユースケースの要件をコスト・レイテンシ・正確性の3軸で整理したうえで選択するものという視点が、本番AIシステムの設計者には求められている。
詳細はBeyond RAG: The Evolution of Knowledge Augmentation (CAG vs. RAG vs. CRAG)を参照していただきたい。
