このブログは自分で調べたり理解した内容をChatGPT（o1）にまとめてもらってます。内容が間違っていたり、適切ではない箇所がありましたら、ご指摘下さい。

はじめに

近年注目されているRAG（Retrieval-Augmented Generation）と、新しく話題になってきたCAG（Cache-Augmented Generation）の仕組みや性能の違いを詳しく解説します。
「RAGは本当に過去のものになるのか？」という疑問についても、RAGとCAGそれぞれの特徴を整理したうえで結論を導きます。

1. RAGの仕組みについて

1-1. 基本的な流れ
RAG（Retrieval-Augmented Generation）は、大規模言語モデル（LLM）が回答を生成する前に「検索（Retrieval）」を行い、関連する情報を取得した上で回答を作る手法です。

RAGの処理は主に以下の3ステップで行われます。

 1. ベクトル化（埋め込み）
• ユーザーの質問を数値ベクトルに変換（埋め込み）し、検索しやすい形にする。

2. 検索（Retrieval）
• ベクトル化した質問を元に、データベース内の類似情報を検索。
• 一般的にはベクターストア（Faiss、Milvus、Pineconeなど）を利用する。

3. 回答生成（Generation）
• 検索で取得した情報をLLMに入力し、それをもとに回答を作成する。


1-2. 外部データとの連携
RAGでは、大量の文書を事前にベクトル化し、それを検索可能な形で保存（ベクターストア）しておきます。
問い合わせ（質問）が来るたびに「検索 → LLMへの入力 → 回答生成」を繰り返すため、情報の種類が多岐にわたっていても比較的対応しやすく、大規模かつ変化のあるデータにも柔軟にアクセス可能です。

2. RAGの問題点

RAGは非常にビジネスに役立つ仕組みですが、下記のような問題を抱えています。

 1. 処理コストが高い
• 毎回検索と要約を行うため、計算コストやAPIコストがかさむ。
• 同じ質問でも都度ベクトル検索を行うため、効率が悪くなることがある。

2. 回答が安定しない
• 検索結果の状態や要約プロセスによって回答が変わる可能性がある。
• 「よくある質問（FAQ）」に対しても、微妙に異なる文言で答えてしまうケースがある。

3. データ管理の負担
• ベクターストア構築・更新の手間がある。文書を追加・削除する際には再度ベクトル化を行わなければならない。
• データ量が膨大になるほど、検索用のインデックス更新などに負荷がかかる。

このような問題を解決するための手法として、CAGという仕組みが注目されています。

3. CAGとは何か？

CAG（Cache-Augmented Generation）は、事前に必要な情報をキャッシュ（保存）し、検索をせずに素早く回答を生成する手法です。
RAGのように毎回ベクトル検索を行うのではなく、特定の知識を事前に準備し、LLMが即座に利用できる形に整えておくことで、高速・低コストな応答を実現します。

3-1. 事前キャッシュを活用
CAGでは、想定される質問や必要なデータをあらかじめキャッシュ化し、LLM内部で活用します。
これにより、問い合わせが来ても「検索」を経ずに直ちに答えを出せる仕組みを作ることが可能です。

CAGはKVキャッシュというものを利用しますが、必ずしもKVキャッシュを直接利用するとは限りません。
長いコンテキストウィンドウを活用し、事前に関連文書をロードしておくアプローチもCAGに含まれます。この方式であっても、リアルタイム検索を行わずに、拡張コンテキストから必要情報を取得して回答できるため、検索による遅延やエラーを回避できます。

3-2. CAGの仕組み
CAGの仕組みは下記となります。

 1. 事前準備（キャッシュ作成）
• FAQや手順書など、あらかじめ分かっている知識をLLMに最適化した形で格納する。
• 質問と回答のペアを整理し、LLMが参照しやすい形に加工する。

2. 推論時の利用
• ユーザーからの質問を受けたら、キャッシュ（または事前ロードしたコンテキスト）を元に回答を生成。
• ベクトル検索や外部リソースへの問い合わせを行わないため、処理速度が速く、一貫性を保ちやすい。

このように外部データとの連携をリアルタイムには行わないというところが大きく違います。


3-3. どんな場面に向いているか？
• FAQやマニュアル（繰り返し同じ質問が来る）
• 企業内データベース（問い合わせパターンがある程度決まっている）
• 製品仕様や契約情報（内容が固定的または更新頻度が少ない）

こうした安定した（変わりにくい）情報を扱う際にCAGが有効です。

3-4. CAGの実装アプローチ
• KVキャッシュを活用するパターン
• 一度計算されたKey-Value情報を再利用し、推論の高速化と回答の一貫性を確保する。
• 長いコンテキストウィンドウを活用するパターン
• 必要な文書を事前にロードし、検索レスで回答を生成する。
• Function Callingや会話履歴を利用するパターン
• システム内であらかじめ用意されたデータや関数を呼び出し、回答を最適化する。

4. KVキャッシュとは何か？

4-1. 概念と動作の仕組み
KVキャッシュ（Key-Value Cache）とは、Transformerモデルの内部で計算されるKey（K）とValue（V）を保存し、後から再利用する仕組みです。
大規模言語モデルは自己注意機構（Self-Attention）を使って文脈を理解しますが、その際に各トークンの関連度や埋め込み情報をKeyとValueにエンコードし、次のトークンを生成するときに参照しています。

 • Key（K） … どの単語（トークン）を「照合対象」として見るかを決めるための指標

• Value（V） … 実際に参照される情報（文脈）を保持


同じ入力・文脈が繰り返し現れた場合、計算済みのKeyとValueを呼び出すことで再度フル計算をしなくてもよいというメリットがあります。
また、KVキャッシュは一般的にはテキストそのものを保持しているわけではなく、テキストをベクトル表現に変換したりなどのLLMが扱いやすい情報に変換されています。この保存形式は統一化されておらず、LLMごとに異なります。

一方で、直接KVキャッシュを使わないアプローチも存在し、テキストそのものを「キャッシュ」としてLLMの長いコンテキストに読み込む手法が挙げられます。
これは、「テキストデータとしてのキャッシュ」をまとめて事前ロードするようなイメージで、LLM内部のKey-Value計算を明示的に活用しない形態になります。

4-2. ChatGPT（Web/API）の場合
RAGはChatGPT（API）を利用していたりなど、クラウド上のLLMサービスと組み合わせるケースが多いかと思います。では、ChatGPT（Web/API）の場合にKVキャッシュがどう扱われるのかを例として見てみましょう。

1.モデル内部で自動的に利用
• ChatGPTのAPIやWeb版では、ユーザーがKVキャッシュを明示的に操作できません。
• ただし、会話が続く中で似た質問をした場合に、内部的にキャッシュが効いて推論速度や一貫性が上がっている可能性があります。

2.オープンソースLLMの事例
• 一部のオープンソースLLMでは、KVキャッシュをユーザーが手動で管理し、推論過程を最適化できる仕組みが提供される場合もあります。

3.ベクトル的キャッシュ vsテキスト的キャッシュ
• 前者（ベクトル的キャッシュ）は、LLM内部の計算済みKey-Valueを再利用するアプローチで、細かな再計算を省きやすい手法です。
• 後者（テキストデータのキャッシュ）は、長いコンテキストウィンドウに文書を載せておき、リアルタイム検索を省略する手法です。
• いずれも「検索レス・高速応答」を実現しやすい点が共通するものの、キャッシュの扱い方や更新の仕方が異なります。


以上のように、ChatGPT（API）で利用する場合は、直接的にKVキャッシュを扱う事が出来ないため、テキスト的なキャッシュで代替する手段を取ることとなります。

5. RAGとCAGの違い

では、RAGのCAGの違いについて考えていきましょう。

5-1. 情報取得のタイミング

 • RAG: 質問が来るたびに、ベクトル検索などを用いて外部データを取得し、回答を生成。
• CAG: 質問が来る前に、あらかじめ情報をLLMが扱える形で固めておく（キャッシュ or ロード）。


5-2. コストと処理速度

 • RAG: 毎回検索と要約を行うため、処理コストが高く、回答生成に時間がかかることがある。
 • CAG: キャッシュや事前ロードを活用することで、全体的に高速かつ低コストで回答を生成可能。


5-3. 回答の一貫性

 • RAG: 外部検索の結果が変わったり、要約の仕方が違ったりすると回答がぶれる可能性がある。
• CAG: キャッシュやロード済みのコンテキストがあれば、常に同じ回答を生成できるため、一貫性が高い。


5-4. 更新や拡張への対応

 • RAG: 新しい情報を検索に取り込めば、即座に回答に反映可能。
• CAG: データが更新されるたびにキャッシュやロード対象を作り直す必要があり、大量・頻繁なアップデートには向きにくい。

6. RAGは不要になるのか？

6-1. RAGとCAGの使い分け
結論として、RAGがすぐに不要になるわけではありません。 CAGは登場したばかりの手法ですが、それぞれが得意とする場面が異なるため、共存が望ましいでしょう。

【大規模かつ多様なデータ】
• Web情報や無数のドキュメントを横断する場合はRAGが有効。
• 新しい情報が頻繁に追加されるような環境ではRAGの検索機能が欠かせない。

【繰り返し質問が来る固定的な知識】
• FAQなどの定型問答であればCAGが効率的。
• キャッシュを増やしすぎるとトークン数制限やメモリ負荷が大きくなる点に注意が必要。


6-2. 今後の展望
今後の展開として下記のものが考えられます。

【ハイブリッド運用】
• 部分的にCAGを導入し、それ以外はRAGでカバーする二段構えが考えられる。

【KVキャッシュのさらなる拡張】
• OpenAI APIで外部からKVキャッシュを操作できる日が来るかは不透明だが、Function Callingや会話履歴の工夫により、擬似的にキャッシュ効果を高める手法も検討される。
• オープンソースLLMでのKVキャッシュ活用が進めば、CAGの応用範囲はさらに広がる可能性がある。


最終的に、RAGとCAGはどちらかが優れているわけではなく、データの更新頻度や規模、必要とされる回答の一貫性や速度などによって最適解が異なります。CAGが登場したからといってRAGが古くなるわけではなく、むしろ両者を上手に併用することで、LLMの活用の幅がさらに広がるでしょう。