［技術解説］RAGかCAGか？あなたのAIプロジェクトに最適な知識拡張技術の選び方

2025-05-16

はじめに

　大規模言語モデル（LLM）が抱える知識の限界という課題と、その解決策として注目されている2つの拡張生成技術、RAG (Retrieval Augmented Generation) と CAG (Cache Augmented Generation) が注目されています。

　本稿では、IBMがYouTube上で公開している「RAG vs. CAG: Solving Knowledge Gaps in AI Models」を基に、RAGと CAG について解説していきます。

引用元記事

タイトル: RAG vs. CAG: Solving Knowledge Gaps in AI Models
発行元: IBM
発行日: 2024年11月4日
URL: https://www.youtube.com/watch?v=HdafI0t3sEY

要点

大規模言語モデル（LLM）は、その訓練データに含まれていない情報や、訓練期間終了後に発生した出来事に関する知識を持たないという限界がある。
RAG (Retrieval Augmented Generation) は、外部の知識ベースから関連情報を検索し、その情報をLLMに提供することで、LLMの回答生成を支援する技術である。
CAG (Cache Augmented Generation) は、知識ベース全体をLLMのコンテキストウィンドウに事前に読み込み、キャッシュすることで、クエリ応答時の情報アクセスを高速化する技術である。
RAGは、知識ベースが大規模で頻繁に更新される場合や、情報の出典を明示する必要がある場合に適している。
CAGは、知識ベースが比較的小さく静的であり、コンテキストウィンドウに収まる場合や、応答速度（レイテンシ）が重視される場合に適している。
両技術は、精度、レイテンシ、スケーラビリティ、データ鮮度の点で異なる特性を持ち、ユースケースに応じて最適な技術を選択、あるいは両者を組み合わせたハイブリッドアプローチを検討することが重要である。

詳細解説

大規模言語モデル（LLM）とその知識の限界

　近年、目覚ましい発展を遂げている大規模言語モデル（LLM）は、人間が書いたような自然な文章を生成したり、質問に答えたりする能力を持っています。これらのモデルは、インターネット上の膨大なテキストデータなどを学習することで、その能力を獲得します。

　しかし、LLMにはいくつかの知識に関する限界があります。

訓練データの範囲: LLMが知っているのは、基本的に訓練に使われたデータセットに含まれる情報のみです。訓練データに含まれていない最新の出来事（例：昨日のニュース）や、特定の企業や個人しか持っていない専有情報（例：顧客の購買履歴）については答えることができません。
訓練期間の固定: 一度訓練が完了すると、そのモデルの知識は固定されます。そのため、モデルの訓練終了後に起きた新しい出来事や情報は反映されません。

　このような知識のギャップを埋めるために、拡張生成 (Augmented Generation) という技術が用いられます。

拡張生成技術とは？

　拡張生成技術とは、LLMが外部の知識源にアクセスし、そこから得た情報を利用して回答を生成する仕組みのことです。これにより、LLMは訓練データにない情報や最新情報に基づいて、より正確で適切な回答を生成できるようになります。本稿で紹介するRAGとCAGは、この拡張生成技術の代表的なアプローチです。

RAG (Retrieval Augmented Generation) の仕組み

　RAG（ラグと読みます） は、その名の通り「検索（Retrieval）」によってLLMの知識を「拡張（Augmented）」して「生成（Generation）」を行う技術です。

　RAGのシステムは、大きく分けて2つのフェーズで動作します。

オフラインフェーズ（知識の準備とインデックス作成）:

まず、LLMに参照させたい知識源（Wordファイル、PDF、ウェブページなど）を用意します。
これらのドキュメントを、扱いやすいように小さな「チャンク（塊）」に分割します。
次に、「埋め込みモデル（Embedding Model）」という特殊なAIモデルを使って、各チャンクをベクトル埋め込みに変換します。ベクトル埋め込みとは、テキストの意味を数値のベクトル（配列）で表現したもので、意味が近いチャンクはベクトル空間上で近くに配置されます。
これらのベクトル埋め込みを、「ベクトルデータベース」という専用のデータベースに保存し、検索可能なインデックスを作成します。これで、知識ベースの準備は完了です。

オンラインフェーズ（検索と生成）:

ユーザーがLLMに質問（クエリ）を投げると、オンラインフェーズが開始されます。
まず、「RAGリトリーバー」がユーザーの質問を受け取り、オフラインフェーズで使用したのと同じ埋め込みモデルを使って質問をベクトル化します。
次に、この質問ベクトルを使ってベクトルデータベース内で類似性検索を行います。これにより、質問に最も関連性の高いドキュメントチャンクがいくつか（通常3～5個程度）見つかります。
これらの関連チャンクと元のユーザーの質問を合わせて、LLMのコンテキストウィンドウ（LLMが一度に処理できる情報量の上限）に入力します。
LLMは、ユーザーの質問と提供された関連情報を基に、最終的な回答を生成します。

　RAGの大きな利点は、モジュール性が高いことです。つまり、ベクトルデータベース、埋め込みモデル、LLMといった各コンポーネントを、システム全体を再構築することなく比較的容易に交換したり更新したりできます。また、知識ベースが非常に大規模であっても、必要な部分だけを検索して利用するため効率的です。

CAG (Cache Augmented Generation) の仕組み

　CAG は、RAGとは異なるアプローチを取ります。CAGの基本的な考え方は、知識データベースをその都度検索するのではなく、知識ベース全体を事前にLLMのコンテキストウィンドウに読み込んでしまう（プリロードする）というものです。

　CAGの仕組みは以下の通りです。

知識のプリロード:

まず、利用したい全ての知識ドキュメントを集めます。
これらのドキュメントを、LLMのコンテキストウィンドウに収まるように、一つの巨大なプロンプトとしてフォーマットします。これには数万から数十万トークン（LLMが処理するテキストの単位）が含まれることもあります。
LLMは、この大量の入力情報を一度に処理します。
この処理の過程で、LLMの内部状態（特に各自己注意層から生成される情報）が「KVキャッシュ（Key-Value Cache）」と呼ばれる形で保存されます。このKVキャッシュは、LLMが全てのドキュメントを読み込み、その内容を符号化したもの、いわば「記憶」した状態と考えることができます。

クエリ処理:

ユーザーが質問をすると、この事前に生成されたKVキャッシュとユーザーの質問がLLMに渡されます。
LLMは、既にKVキャッシュ内に知識トークンを持っているため、再度ドキュメント全体を処理することなく、キャッシュされた情報を活用して迅速に回答を生成できます。

　CAGの主な利点は、一度知識がキャッシュされれば、検索のステップがないため応答が非常に速い（低レイテンシ）ことです。

RAGとCAGの比較

　RAGとCAGは、LLMに外部知識を与えるという目的は同じですが、そのアプローチと特性にはいくつかの重要な違いがあります。

	RAG (Retrieval Augmented Generation)	CAG (Cache Augmented Generation)
知識処理のタイミング	クエリ時に必要な情報のみを検索・取得	事前に全知識をコンテキストウィンドウにロードし、キャッシュ
知識ベースのサイズ	非常に大規模（数百万ドキュメント）に対応可能。検索対象は一部のみ。	モデルのコンテキストウィンドウサイズに制約される（通常32k～100kトークン、数百ドキュメント程度）。
精度	リトリーバーの性能に依存。関連文書を取得できれば高精度。無関係な情報を遮断できる可能性。	全情報がコンテキスト内にあるため、理論上は見つけられる。ただし、LLMが大量情報から適切に抽出できるか、無関係な情報と混同しないかが課題。
レイテンシ（応答速度）	検索ステップがあるため、やや高い。	キャッシュ後は検索がないため、非常に低い。
スケーラビリティ	ベクトルデータベースの許容量までスケールしやすい。	モデルのコンテキストウィンドウサイズというハードリミットがある。
データ鮮度	インデックスの更新が容易で、新しい情報を迅速に反映可能。インクリメンタルな更新も可能。	データ変更時には再計算（キャッシュの再構築）が必要。頻繁な更新には不向き。
必要なリソース	ベクトルデータベース、リトリーバーなどが必要。	長いコンテキストウィンドウを扱えるモデルが必要。
出典の明示	検索した情報源を特定しやすいため、出典の提示に向いている。	全てがコンテキスト内にあるため、特定の出典を分離するのは比較的難しい。

実践的なユースケース

　では、どのような場合にRAGやCAGが適しているのでしょうか？以下のような事例が参考になります。

ITヘルプデスクボット

シナリオ: 製品マニュアル（約200ページ、更新は年に数回）を知識源として、ユーザーの質問に答えるボット。
推奨: CAG
理由: 知識ベース（製品マニュアル）が比較的小さく、多くのLLMのコンテキストウィンドウに収まります。また、情報は静的（頻繁に更新されない）ため、キャッシュの再構築の頻度も低く抑えられます。キャッシュを利用することで、ユーザーの質問に迅速に回答できます。

法律事務所向けリサーチアシスタント

シナリオ: 数千件に及ぶ法的ケース（新しい判例や修正で常に更新される）を検索し、弁護士の質問に対して関連法規への正確な引用と共に回答するシステム。
推奨: RAG
理由: 知識ベースが非常に巨大かつ動的（常に新しい情報が追加される）です。これを全てCAGでキャッシュしようとすると、ほとんどのモデルのコンテキストウィンドウを超えてしまいます。また、RAGは検索メカニズムを通じて情報源への正確な引用を自然にサポートできます。新しい法的文書が登場した際にベクトルデータベースを増分更新できるため、システムは常に最新情報にアクセスできます。

病院向け臨床意思決定支援システム

シナリオ: 医師が患者の記録、治療ガイドライン、薬物相互作用などを照会し、診察中に利用するための包括的で非常に正確な回答が必要。医師は複雑なフォローアップの質問をすることもある。
推奨: ハイブリッドアプローチ (RAG + CAG)
理由: このような複雑なケースでは、両方の技術の長所を組み合わせることが有効です。
- まず、RAGを使用して、膨大な知識ベース（患者の全病歴、多数の研究論文など）から、医師の最初の質問に最も関連性の高い情報のサブセット（特定の患者の病歴の関連部分、関連する研究論文など）を取得します。
- 次に、取得したこれらの情報を単にLLMに渡すのではなく、CAGのアプローチを用いて、これらの情報を長文コンテキスト対応モデルのコンテキストウィンドウに全てロードします。これにより、特定の患者ケースに関する「一時的な作業メモリ」のようなものが作成されます。
- このハイブリッドアプローチにより、RAGの効率的な大規模検索能力と、CAGの広範な情報を手元に置いて複雑なフォローアップ質問に対応できる能力（データベースへの繰り返しクエリなしに）を両立できます。

どちらを選ぶべきか？ – 選択の指針

　RAGとCAGのどちらを選択するか、あるいは組み合わせるかは、解決しようとしている課題の特性によって決まります。

RAGを検討するケース:
- 知識源が非常に大きい場合。
- 知識源が頻繁に更新される場合。
- 回答に出典の明示が必要な場合。
- 長いコンテキストウィンドウを持つモデルを実行するためのリソースが限られている場合。
CAGを検討するケース:
- 知識源が固定的で、使用するモデルのコンテキストウィンドウに収まる場合。
- 応答速度（低レイテンシ）が非常に重要な場合。
- デプロイメントを簡素化したい場合（外部データベース管理の複雑さを避けたいなど）。