「Don’t Do RAG」巨大コンテキストを活かした超高速なCAGという新手法【論文解説】
あけましておめでとうございます🎍
年末年始で､RAG（Retrieval-Augmented Generation） に関する記事や論文を読んでいたところ、とても挑発的なタイトルの論文に出会いました。それがDon’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasksです。
Paper:
GitHub:
要するに「検索なんてせずに、必要な文書は全部まとめてロードしちゃえ」という発想のようで、実験では 最大40倍の高速化 を達成したとのこと。今回は、この論文が提案する Cache-Augmented Generation (CAG) の要点を、ざっくり解説してみます。
1. RAGとCAGの違い：そもそも何が新しいの？
■ RAG：従来のRetrieve + Generate手法
- Retrieval-Augmented Generation (RAG) は、大規模言語モデル（LLM）の知識を補うために、必要な文書を検索エンジン等からその都度取得する仕組み。
- 「文書Aを見つけて→LLMに読み込ませ→回答を生成」という流れが基本。
- 高い汎用性がある一方、検索レイテンシや文書選択ミスなどのリスクがある。
■ CAG：Cache-Augmented Generation
- 一方、Cache-Augmented Generation (CAG) では、最初にすべての必要文書をLLMにロードしておき、リアルタイム検索をしないというアプローチを取る。
- 具体的には、LLMの長大なコンテキストを活かして、関連文書をまとめて Key-Valueキャッシュ として保存。あとは推論時にユーザ質問を加えるだけ。
- 検索がない分、処理がシンプルで高速、かつ間違った文書を拾う心配もほぼない。
2. RAGの課題とCAGの登場意義
RAGは便利な一方、以下のデメリットを抱えています。
-
検索レイテンシ
問い合わせごとに文書検索が走り、レスポンスが遅くなりがち。 -
文書選択ミス
間違った文書を拾ったり、ランキングの問題で回答がズレるリスク。 -
複雑化
検索・再ランキング・生成を組み合わせるため、開発・保守の負荷が高い。
CAGは、こうした問題の大部分を 「検索段階を無くす」 ことで解消するわけです。長大なコンテキストウィンドウが当たり前になった昨今、事前に文書を一気にロードできるなら、わざわざ検索しなくてもいいのでは､という合理的な問いに基づいています。
3. 論文から見るCAGのワークフロー
論文中には、RAGとCAGの手順を対比する Figure 1 が掲載されています。
Figure 1. (上段) RAGのパイプラインでは、問い合わせ（Q1, Q2）に応じてモデルが外部知識を取得している
(下段) CAGのパイプラインでは、あらかじめKnowledge Cacheに文書をすべて読み込んでおき、推論時は検索なしで回答
-
上段: RAG
質問(Q1, Q2)ごとにRetrieval Modelで外部知識(K1, K2)を取り込み、LLMに供給。 -
下段: CAG
全知識を事前にキャッシュ化し、推論時は一切のRetrievalが不要。
これだけ見ると、CAGはやたらシンプルな構成に見えますが、論文実験を見るとこれが非常に効果的であることがわかります。
4. 実験結果：スピードと精度の両立
論文では、SQuAD と HotPotQA という有名なQAベンチマークを使い、CAGとRAG（Sparse/Dense両方）を比較しています。
4.1 データセットの概要
下記の Table 1 は、実験で使用された各データセット（SQuAD & HotPotQA）の規模をまとめたものです。
Table 1. Small/Medium/Largeと3種類ずつ用意。文書数やトークン数が増えるほどRAGの難易度が上がる設定
4.2 精度比較（BERTScore）
次に示す Table 2 では、CAG が多くの設定で BERTScore が最も高く、Sparse RAG / Dense RAG より良い結果が得られています。
Table 2. 例えばHotPotQA (Small) でCAGのBERTScoreは0.7759と高い値を示している
これは「リアルタイム検索時のミス」が起こらないことや、LLMが文書全体を最初から包括的に処理していることが大きいと考えられます。
4.3 生成時間比較
そして注目は速度面。下記 Table 3 でわかるように、CAGは従来のやり方より大幅に高速。大きいデータセットほど差が顕著で、最大40倍以上もスピードが速いケースが報告されています。
Table 3. HotPotQAのLargeセットでは「CAG: 2.32667秒」対「w/o CAG: 94.34917秒」という劇的な差が出ている
5. どんな場面でCAGが有効？
-
医療情報のQA
- 診療ガイドラインや文献をあらかじめまとめてロードし、問い合わせごとの検索遅延をゼロに。
- 検索ミスが減り、リアルタイム性が向上。
-
財務データ分析
- 企業データや市場レポートを初期ロードしておき、繰り返し問い合わせる業務を高速化。
-
企業のFAQやナレッジベース
- 更新頻度が低い社内文書なら、一度キャッシュすれば長期間使い回せる。
-
大規模LLM開発の一部
- 研究開発などで、特定の固定データを参照するシナリオにはCAGがかなり有効。
文書の更新が頻繁な場合や、膨大な文書をすべて事前読み込みするのが難しい場合にはRAG的アプローチとの併用も考えられます。しかし、「更新頻度が低い」「文書量が限られている」環境では、CAGが非常に有力な選択肢になり得ると考えられます｡
6. CAGの弱点とハイブリッド提案
CAGには、当然ながら弱点もいくつか挙げられます。
- 文書が膨大すぎると、事前ロードがそもそも難しい。
- 頻繁に更新がある領域だと、キャッシュを作り直すコストが増える。
- まったく新しい文書を後から取り込むには、別途RAG的なステップが必要。
論文でも、こうした制約があることを認めつつ、CAG + 選択的にRAGのハイブリッド手法を示唆しています。つまり、「基本はCAGで高速化しつつ、特殊な質問や更新分だけRetrievalを使う」などといった運用が考えられそうです｡
7. 個人的考察：ロングコンテキスト時代の到来
昨今、GPT-4oなどのモデルは数万トークン単位のコンテキストウィンドウを扱えます。今後さらに拡張されていけば、必要な文書を丸ごと入れるスタイルが広範囲で可能になるはずです。
- 大規模データでも、要約や分割などの工夫をすればCAGに載せられる場合が増えそう。
- リアルタイム検索の複雑さを省略し、単純なパイプラインにできるのは魅力的。
- もちろん、データ鮮度が要求される場合はRAGが欠かせないため、使い分けが重要。
また､近頃は「RAG × エージェント」のような複雑なシステムが脚光を浴びていますが、CAGのアプローチはむしろ逆方向というか、あえてシンプルに作ることで「速いし間違いにくい」という利点を得ています。
たとえ論文タイトルが「Don’t Do RAG」と挑発的でも、実際は“RAG不要”の世界がすべてに成り立つわけではありません。大規模データや鮮度が必要なユースケースでは、依然としてRAGが強いはず。
とはいえ、「文書量そこそこ」「更新頻度少なめ」「高速化重視」な場面なら、このCAGは案外ベストソリューションなのかもしれません。
そして、そもそも検索って本当に必要かと一度立ち止まって考えるうえで、CAGは非常に興味深い選択肢を提示してくれてるように感じました｡
8. まとめ
-
CAG（Cache-Augmented Generation） とは？
- 必要な知識をすべてLLMに一括ロードし、検索せずに回答を生成する手法。
- 大きなコンテキストウィンドウを持つ最新LLMをフル活用することで、最大40倍の高速化を実現。
-
メリット
- 検索レイテンシや文書選択ミスがほぼゼロ
- アーキテクチャが単純化
- スコア面でもRAGと同等かそれ以上
-
デメリット & ハイブリッド案
- 文書が極端に多い、または頻繁に変わる環境では完全なCAGは難しい
- 必要に応じて「RAGで補う」ハイブリッド運用が推奨される場合も
「Don’t Do RAG」という大胆なタイトルですが、それだけLLMのコンテキスト拡張の力を強調していると感じました。これからますますコンテキストが大きくなると、CAGの適用領域は広がり、実用シーンも増えていくでしょう。
興味を持った方は、ぜひ論文をご覧ください。
新しい観点でLLMやRAGの可能性を捉え直す良いヒントになるはずです。
■ 参考リンク
次におすすめな記事
【免責事項】
本記事の情報は執筆時点（2025年1月6日）のものです。本記事は、公開されている情報に基づいて作成されていますが、誤りが含まれている可能性もあります。内容の正確性については、読者ご自身の責任で判断をお願いいたします。AI技術は急速に進化しており、製品の仕様、価格、可用性などが予告なく変更される可能性があります。また、本記事の内容は一般的な情報提供を目的としており、専門的なアドバイスとしては意図していません。適切な専門家にご相談ください。
Discussion