複雑さとレイテンシを大幅に削減する新アプローチ
はじめに：この記事を読むメリット
「自社の情報を大規模言語モデル（LLM）に取り込む際、RAG（Retrieval-Augmented Generation）は有力な手段だけれど、実装が難しくて時間もコストもかかりそう……」そんな悩みを抱えていませんか？
実は最近の研究で、RAGを使わずに、もっとシンプルかつ高速にカスタムLLMを実現する方法が注目を集めています。それがCAG（Cache-Augmented Generation）と呼ばれるアプローチです。
本記事では、RAGの限界やCAGの仕組み、実際の比較実験の結果までを分かりやすく解説します。今、生成AIの導入や開発を検討している方にとって、「自社のドキュメントをどうLLMに反映させるか」は大きな課題のはず。この記事を読むことで、「一見手間がかかりそうなLLMカスタマイズを、驚くほど効率的に進める方法」が明らかになるはずです。
「LLMに一度に大量の文章を放り込んでも本当に大丈夫？」「RAGのチューニングが面倒くさそうだけど、代わりになる方法なんてあるの？」といった、意外な疑問や不安もきっと解消できるでしょう。
RAG（Retrieval-Augmented Generation）の限界
まずは従来よく使われてきたRAGの仕組みをおさらいしましょう。RAGは、ユーザーのリクエストに対して最適な回答を生成するため、関連ドキュメントを検索（リトリーブ）してLLMに与える手法です。たとえば商品カタログから詳細情報を取り出し、それをLLMに渡して回答の精度を高める──これがRAGの基本的な流れです。
しかし、RAGには以下のような課題が指摘されています。
- レイテンシの増大
毎回ドキュメント検索を挟むため、ユーザーが回答を得るまでの待ち時間が長くなりがちです。 - 検索段階での精度への依存
ドキュメントの切り分けやランキング精度が低いと、LLMが適切な情報を得られません。 - 開発・運用の複雑化
検索エンジンやEmbeddingモデルなど、LLM以外に追加コンポーネントを開発・統合する必要があります。
RAG自体は優れた手法ですが、小規模で頻繁に更新がない知識ベースの場合、実はこの複雑さとレイテンシがオーバーヘッドとなり、導入や運用が面倒になることも多いのです。
CAG（Cache-Augmented Generation）とは
こうしたRAGの課題を解消するアプローチとして注目されているのが、台湾の国立政治大学（National Chengchi University）の研究チームが提案したCAG（Cache-Augmented Generation）です。研究によれば、「長大なコンテキストを扱えるLLM」と「プロンプトの一部をキャッシュする技術」を組み合わせることで、RAGの複雑さを省きつつ高精度な回答を得られるといいます。
1. 大容量コンテキストを活用
CAGでは、ドキュメント検索を挟む代わりに、あらかじめ全ドキュメントをLLMのプロンプトに入れておく発想を取ります。
- 近年、Claude 3.5 Sonnetは最大20万トークン、GPT-4oは12.8万トークン、さらにGoogleのGeminiは200万トークンもの長大なコンテキストウィンドウをサポートすると報じられています。これにより、一度に大量のドキュメントを与え、モデル自身に必要な部分を選ばせることが可能になりました。
2. キャッシュ技術を活用
プロンプトが長くなるほど推論に時間とコストがかかるのではないか、と心配になるかもしれません。ここで活躍するのがキャッシュ（Cache）です。
- CAGでは、ユーザーからのリクエストごとに共通する情報（企業内ドキュメントなど）をあらかじめキャッシュしておくことで、推論時の計算コストを大幅に削減できます。
- OpenAIやAnthropic、Googleなど主要なLLMベンダーは、「プロンプトキャッシュ」機能を提供しており、Anthropicの例では最大でコスト90％削減、レイテンシ85％削減も期待できるといいます。
3. モデルの長文処理能力向上
さらに、モデルのアーキテクチャ自体も改善が進んでおり、長文の中から必要な情報を引き出す能力が高まっています。
- 研究コミュニティではBABILongやLongICLBench、RULERなど「長文推論」をテストするベンチマークが次々と登場。複数の文書をまたいだ検索や多段階推論といった高度なタスクに対応できるよう、LLMが進化しています。
RAGとCAGの比較：実験結果
研究チームは、代表的なQ&AベンチマークであるSQuADと、複数文書にまたがる多段階推論が必要なHotPotQAを使って、RAGとCAGを比較しました。
- RAG：
- ベーシックなBM25アルゴリズム
- OpenAI Embeddingsによる検索
- CAG：
- 複数文書をそのままプロンプトに入れ、モデルが自動で必要な部分を参照
結果は、大きな文脈ウィンドウを備えたLlama-3.1-8B（128,000トークン対応）を用いた場合、CAGの方がRAG（BM25/Embedding）を上回る回答精度を発揮し、処理時間も短縮されたとのことです。
理由としては、RAGで問題になりがちな「検索段階での取りこぼし」「不正確なランキング」が排除され、モデルが提示された全情報を一貫して処理できる点が大きいようです。
CAGを導入する際の注意点
もちろん、CAGにも限界は存在します。
- 知識ベースの頻繁な更新への対応
ドキュメントが頻繁に更新されると、キャッシュの更新も必要になります。ただし、RAGでも更新のたびにインデックスを作り直す手間はあります。 - コンテキストウィンドウのサイズ
モデルが扱えるトークン数を超える大規模データセットには向きません。
ただし、最新のLLMはコンテキスト拡張が続いており、今後ますます容量は大きくなる見込みです。 - ドキュメント内の矛盾
一度に大量のドキュメントを渡すと、内容が相互に矛盾する場合にモデルが混乱する恐れがあります。事前にドキュメントの整合性を保つ工夫が必要です。
まとめ：CAGは「まず試してみる」価値がある
- 「知識ベースが比較的小規模」
- 「頻繁に更新しない」
- 「できるだけシンプルにLLMを運用したい」
上記の条件に当てはまる企業やプロジェクトなら、CAGは非常に魅力的な選択肢になりえます。
RAGのように複雑な検索パイプラインを組む必要がなく、実装も容易。そのうえ、キャッシュ機能を使えば、大量のコンテキストを保持しながら推論コストを抑えられます。
本研究チームも、「まずCAGを試してみて、十分なパフォーマンスが得られなかったらRAGを検討するのでも遅くない」と提案しています。いきなり複雑なシステムを構築するよりも、シンプルなソリューションを試し、効果を検証してから判断するのが賢明といえるでしょう。
「RAGが当たり前」と思われがちな今だからこそ、意外性のあるCAGが選択肢に入ってくるのは興味深いトレンドです。長大なコンテキストウィンドウを活用できる新世代LLMの登場もあいまって、CAGが今後のスタンダードとして定着する可能性は十分にあるでしょう。気になる方は、ぜひ一度試してみてはいかがでしょうか。
