RAG vs. CAG: AIモデルにおける知識拡張戦略の理解

はじめに

大規模言語モデルは、私たちが人工知能と対話する方法に革命をもたらしましたが、根本的な課題に直面しています。それは知識のカットオフです。モデルの訓練データに含まれていない情報は、モデルは単純に思い出すことができません。最近のニュース、企業の機密データ、リアルタイム情報など、従来のLLMは訓練期間外の知識について正確な回答を提供することに苦労しています。この制限により、外部の知識ソースに接続することでAIモデルの能力を拡張する手法である、拡張生成技術の開発が促進されました。この問題を解決するために、2つの主要なアプローチが登場しました。検索拡張生成(RAG)とキャッシュ拡張生成(CAG)です。それぞれが明確な利点とトレードオフを提供しており、効果的なAIシステムを構築するためには、どちらのアプローチをいつ使用するかを理解することが重要です。この包括的なガイドでは、両方の技術を深く掘り下げ、そのアーキテクチャ、能力、実世界での応用を検証します。

大規模言語モデルにおける知識の問題

解決策に入る前に、RAGとCAGが対処する核心的な問題を理解することが不可欠です。大規模言語モデルは、特定の時点で収集された膨大なデータセットで訓練されます。訓練が完了すると、モデルの知識は静的になります。新しい情報を学習したり、世界に対する理解を更新したりすることはできません。これにより、実世界のアプリケーションにおいていくつかの重大な問題が発生します。第一に、モデルは最近の出来事を認識していません。2025年のアカデミー賞作品賞の受賞者について尋ねても、訓練データが授賞式の前に収集された場合、モデルはこの情報を持っていない可能性があります。第二に、モデルは機密情報や独自情報にアクセスできません。カスタマーサービスチャットボットは、特定の顧客の購入履歴やアカウント詳細に関する質問に答えることができません。なぜなら、この情報は訓練データセットの一部ではなかったからです。第三に、事実が変化すると、モデルは古い情報を提供する可能性があります。医療ガイドライン、法的先例、製品仕様、企業ポリシーはすべて時間とともに進化しますが、静的なモデルはこれらの変化を反映できません。これらの制限により、現在の関連情報でモデルの知識を拡張する何らかのメカニズムなしに、多くの企業やミッションクリティカルなアプリケーションにLLMを展開することは不可能になります。

知識拡張の理解:現代AIの基盤

知識拡張は、AIシステム設計へのアプローチにおけるパラダイムシフトを表しています。訓練中にモデルが学習した内容だけに依存するのではなく、拡張技術はモデルの固有の能力と外部情報ソースとの間に橋を架けます。このアプローチは、根本的な真実を認めています。最良のAIシステムは、最大の訓練データセットを持つものではなく、必要なときに関連情報に動的にアクセスして統合できるものです。知識拡張技術にはさまざまな形式がありますが、すべてが共通の目標を共有しています。それは、正確で文脈に即した最新の応答を提供するモデルの能力を強化することです。拡張の美しさは、知識の保存をモデルの訓練から切り離すことにあります。モデルを再訓練することなくナレッジベースを更新でき、高価なファインチューニングプロセスなしに新しい情報を追加でき、単一のモデルが含むことができる範囲をはるかに超えてシステムの知識を拡張できます。この柔軟性により、情報が絶えず変化する動的な実世界環境で動作しなければならない本番グレードのAIシステムを構築するために、拡張技術が不可欠になっています。

実践における知識拡張

このガイドで説明されているRAGとCAGの技術は、すでに実世界のAIプラットフォームで適用されています。FlowHuntは、Knowledge Sources機能を通じてRAGを実装しており、企業が企業文書、FAQ、ウェブサイトにAIチャットボットとワークフローを接続できるようにしています。これにより、一般的な訓練データではなく、検証済みの企業情報に基づいたAI応答が可能になります。LiveAgentは、AI回答アシスト(AI Answer Improver)やAI ChatbotなどのAI機能を統合しており、ナレッジベースを参照して正確なカスタマーサポート応答を提供できます。

SmartWebは、両方のプラットフォームを活用して、制御された知識ソース(企業FAQ、製品マニュアル、サポートドキュメント)を使用するAIソリューションを構築し、応答が企業ポリシーと一致して正確で一貫性があることを保証します。知識拡張技術が進化し続けるにつれて、これらのプラットフォームもそれに伴って進化します。つまり、今日RAGベースのソリューションを実装する企業は、将来の検索精度と応答品質の改善から恩恵を受けることができます。

RAG:検索拡張生成の説明

検索拡張生成は、知識拡張に対するより確立された広く採用されているアプローチを表しています。RAGは、シンプルながら強力な原則に基づいて動作します。必要な情報を、必要なときにのみ取得する。すべての知識を事前にロードするのではなく、RAGはナレッジベースの検索可能なインデックスを維持し、クエリプロセス中にオンデマンドで関連する部分を取得します。この2段階のアーキテクチャ(オフラインインデックス作成とオンライン検索)は、驚くべき柔軟性とスケーラビリティを提供します。

RAGアーキテクチャ:オフラインフェーズとオンラインフェーズ

RAGの力は、知識の準備とクエリ処理を分離するモジュラー設計から来ています。オフラインフェーズでは、ナレッジベースが効率的な検索のために準備されます。これは、すべての知識ソース(Word文書、PDF、ウェブページ、データベースレコード、またはモデルにアクセスさせたい情報を含むその他の形式)を収集するドキュメント取り込みから始まります。これらのドキュメントは、通常数文から数段落の範囲の管理可能なチャンクに分割されます。このチャンク化プロセスは、モデルが受け取る情報の粒度を決定するため、重要です。チャンクが大きすぎると無関係な情報が含まれる可能性があり、小さすぎると重要なコンテキストが断片化される可能性があります。ドキュメントがチャンク化されると、埋め込みモデルが各チャンクを数値ベクトル表現に変換します。この埋め込みはテキストの意味的意味を捉えます。類似した意味を持つチャンクは、異なる単語を使用していても類似した埋め込みを持ちます。これらの埋め込みは、類似性検索に最適化された特殊なデータベースであるベクトルデータベースに保存されます。ベクトルデータベースは、ナレッジベース全体の検索可能なインデックスを作成し、関連情報の高速検索を可能にします。オンラインフェーズでは、ユーザーがクエリを送信すると、システムが動作を開始します。ユーザーの質問は、ドキュメントを処理したのと同じ埋め込みモデルを使用してベクトルに変換されます。このクエリベクトルは、ベクトルデータベースを検索するために使用され、最も類似したドキュメントチャンクを見つけます。システムは通常、上位K件の結果(多くの場合、答えを含む可能性が最も高い3〜5つのパッセージ)を取得します。これらの取得されたチャンクは、元のユーザークエリとともに、大規模言語モデルのコンテキストウィンドウに配置されます。モデルは、質問と関連するコンテキスト情報の両方を持つようになり、より正確で情報に基づいた応答を生成できます。重要なことに、モデルは情報がどこから来たかを見ることができるため、ソースを引用し、その推論について透明性を提供できます。

RAGの主な利点

スケーラビリティは、RAGの最も説得力のある利点です。システムはクエリごとにデータの小さなスライスのみを取得するため、膨大なナレッジベースを処理できます。RAGシステムは1,000万のドキュメントをインデックス化でき、それでも任意の質問に対して最も関連性の高いいくつかのドキュメントのみを取得します。言語モデルは1,000万のドキュメントすべてを一度に見ることはありません。取得されたサブセットのみを処理します。このスケーラビリティは、ナレッジベースが継続的に成長する企業アプリケーションにとって重要です。データの鮮度も重要な強みです。ナレッジベースが変更されると、RAGはインデックスを段階的に更新できます。新しいドキュメントを追加し、古い情報を削除でき、システムは再訓練や再計算なしにこの新しい知識をすぐに使用できます。これにより、RAGは情報が頻繁に変化する領域(新しい判例がある法的調査、更新された治療ガイドラインがある医療システム、進化する製品情報があるカスタマーサポート)に理想的です。透明性と引用は、規制された専門的なコンテキストで大きな価値を提供します。RAGは特定のドキュメントを取得するため、システムは情報がどこから来たかを正確に伝えることができます。法的調査にRAGを使用する弁護士は、特定の議論を支持するケースを確認できます。臨床決定にRAGを使用する医師は、推奨事項を通知した特定の研究論文やガイドラインを参照できます。このトレーサビリティは信頼を構築し、システムの推論の検証を可能にします。

RAGの制限とトレードオフ

利点にもかかわらず、RAGは検索レイテンシを導入します。各クエリは、言語モデルが回答の生成を開始する前に、質問の埋め込み、ベクトルデータベースの検索、関連ドキュメントの取得を必要とします。これにより、検索を必要としないシステムと比較して、測定可能なオーバーヘッドが追加されます。応答時間が重要なアプリケーションでは、このレイテンシが問題になる可能性があります。検索品質も重要な考慮事項です。RAGの精度は、検索エンジンが関連ドキュメントを正常に見つけられるかどうかに完全に依存します。検索ステップが失敗した場合(埋め込み検索が答えを含むドキュメントを返さない場合)、言語モデルは正しく応答するために必要な情報を持ちません。不適切に構成された埋め込みモデルやベクトルデータベースは、システムのパフォーマンスを大幅に低下させる可能性があります。システムの複雑さは、RAGの実装により増加します。埋め込みモデル、ベクトルデータベース、検索メカニズム、言語モデルという複数のコンポーネントを管理する必要があります。各コンポーネントは潜在的な障害点を導入し、慎重なチューニングと監視を必要とします。この複雑さにより、RAGシステムは、よりシンプルなアプローチと比較して、展開と保守がより困難になる可能性があります。

CAG:キャッシュ拡張生成の説明

キャッシュ拡張生成は、知識の問題に対して根本的に異なるアプローチを取ります。オンデマンドで情報を取得するのではなく、CAGはクエリを処理する前に、すべての関連知識をモデルのコンテキストウィンドウに事前ロードします。この戦略は、柔軟性を速度と引き換えにし、固定されたナレッジベースで迅速で一貫した応答に最適化されたシステムを作成します。

CAGアーキテクチャ:事前ロードとKVキャッシング

CAGのアーキテクチャは、RAGと比較してエレガントにシンプルです。別個のベクトルデータベースと検索メカニズムを維持する代わりに、CAGは言語モデルの内部アーキテクチャと直接連携します。プロセスは、すべての知識をモデルのコンテキストウィンドウに収まる単一の巨大なプロンプトにフォーマットすることから始まります。これは数万、さらには数十万トークンになる可能性があります。製品マニュアルから法的文書、医療ガイドラインまで、すべてが1つの巨大な入力に連結されます。次に、言語モデルは、ニューラルネットワークを通じた単一のフォワードパスでこの知識ブロブ全体を処理します。モデルがこのすべての情報を読み取って処理すると、KVキャッシュ(キー・バリューキャッシュ)と呼ばれる内部表現が作成されます。このキャッシュは、トランスフォーマーアーキテクチャの各自己注意層から作成され、事前ロードされたすべてのドキュメントに対するモデルのエンコードされた理解を表します。これは、モデルがすでにすべてのドキュメントを読んで記憶しているようなものと考えてください。KVキャッシュは、その知識に対するモデルの内部メモリです。

KVキャッシュが作成されて保存されると、それがすべての後続のクエリの基盤になります。ユーザーが質問を送信すると、システムは何も取得したり、ドキュメントを再処理したりする必要はありません。代わりに、ユーザーのクエリをKVキャッシュに追加し、すべてを言語モデルに送信するだけです。トランスフォーマーのキャッシュにはすでにすべての知識トークンが含まれているため、モデルは元のドキュメントを再読み取りまたは再処理することなく、回答を生成する際に関連情報を参照できます。これは驚くほど効率的です。モデルは、検索や取得の計算コストなしに、事前ロードされたナレッジベースのどこからでも情報を使用して応答を生成できます。

CAGの主な利点

レイテンシの削減は、CAGの決定的な強みです。知識がキャッシュされると、クエリへの回答は、ユーザープロンプトと生成に対するモデルの単一のフォワードパスになります。検索ルックアップ時間、埋め込み計算、ベクトルデータベース検索はありません。応答時間は、外部検索メカニズムではなく、モデルの生成速度のみに依存します。速度が最優先のアプリケーション(リアルタイムの顧客対話、時間に敏感な意思決定支援、または大量のクエリ処理)では、CAGの低レイテンシは非常に貴重です。計算効率は、レイテンシの利点から自然に続きます。検索ステップを排除することにより、CAGは全体的な計算オーバーヘッドを削減します。別個の埋め込みモデルやベクトルデータベースを維持する必要はありません。類似性検索を実行する必要もありません。システムはよりシンプルで、より無駄がなく、よりリソース効率的です。この効率は、運用コストの削減に直接つながり、コストに敏感なアプリケーションにとってCAGを魅力的にします。展開のシンプルさは過小評価できません。CAGは、RAGよりも可動部品が少なくて済みます。ベクトルデータベース、埋め込みモデル、検索パイプラインを管理する必要はありません。システムは、実装、テスト、展開がより簡単です。このシンプルさにより、バグの表面積が減少し、システムの理解と保守が容易になります。

CAGの制限とトレードオフ

コンテキストウィンドウの制約は、CAGの根本的な制限を表しています。現代の言語モデルは、32,000から100,000トークンの範囲のコンテキストウィンドウを持ち、一部の大型モデルはこれを超えています。しかし、これはまだ有限です。モデルに知ってもらいたいすべてのものは、このウィンドウ内に収まる必要があります。100,000トークンのコンテキストウィンドウの場合、せいぜい数百のドキュメントしか収まらない可能性があります。このハードリミットは、CAGがRAGが楽々と処理する大規模なナレッジベースにスケールできないことを意味します。ナレッジベースがコンテキストウィンドウに収まる範囲を超えて成長すると、CAGは実用的でなくなります。静的な知識も重要な制約です。CAGは知識を一度事前ロードし、キャッシュします。ナレッジベースが変更された場合(新しいドキュメントが追加された、情報が更新された、または古いコンテンツを削除する必要がある場合)、KVキャッシュ全体を再計算する必要があります。この再計算は、キャッシングの利点を無効にし、大きなオーバーヘッドを導入します。情報が頻繁に変化する領域では、CAGの静的な性質が負債になります。モデルの応答における混乱の可能性は、微妙ですが重要な考慮事項です。すべての可能な関連情報を事前ロードすると、モデルに答えを与えるだけでなく、すべてを与えることになります。モデルは、この大きなコンテキストから正しい情報を抽出し、無関係な情報を混ぜないようにする必要があります。現代の言語モデルは一般的にこれが得意ですが、モデルが情報を混同したり、複数の無関係な知識を不適切にブレンドした回答を提供したりするリスクは常にあります。

RAGとCAGの比較:精度、レイテンシ、スケーラビリティ、データの鮮度

RAGとCAGのトレードオフを理解するには、実世界のアプリケーションにとって重要な複数の次元でそれらを検証する必要があります。

精度:検索 vs. 包括性

RAGの精度は、検索コンポーネントに決定的に依存します。検索エンジンが関連ドキュメントを正常に見つけた場合、言語モデルは正しく回答するために必要な情報を持っています。検索エンジンはフィルターとして機能し、モデルを無関係な情報から保護し、重要なことに注意を集中させます。ただし、検索エンジンが失敗した場合(関連ドキュメントを見つけられない場合)、モデルは正確な回答に必要な事実を欠いています。RAGの精度は、検索メカニズムと同じくらい良いだけです。CAGの精度は異なる動作をします。すべての潜在的に関連する情報を事前ロードすることにより、CAGは情報がコンテキストのどこかに存在することを保証します。ナレッジベースに実際に質問に対する答えが含まれていると仮定すると、情報は確実にそこにあります。ただし、負担はモデルに移り、大きなコンテキストから正しい情報を抽出する必要があります。モデルが混乱したり、無関係な情報を混ぜたり、複数の知識を不適切にブレンドした回答を提供したりする可能性があります。CAGは、検索失敗のリスクをモデルの混乱のリスクと交換します。

レイテンシ:速度が重要

RAGは検索ステップを通じてレイテンシを導入します。各クエリは、言語モデルが回答を生成する前に、質問の埋め込み、ベクトルデータベースの検索、関連ドキュメントの取得を必要とします。このオーバーヘッドは測定可能であり、ナレッジベースが成長するか、検索インフラストラクチャがより複雑になるにつれて、より重要になります。応答時間が重要なアプリケーションでは、このレイテンシが問題になる可能性があります。CAGは検索ステップを完全に排除することでレイテンシを最小化します。知識がキャッシュされると、クエリへの回答はモデルの1回のフォワードパスだけです。応答時間は、外部検索メカニズムではなく、モデルの生成速度のみによって決定されます。これにより、CAGはクエリ処理が大幅に高速になりますが、初期のキャッシングステップには事前に計算が必要です。

スケーラビリティ:ナレッジベースのサイズ

RAGは大規模なナレッジベースにスケールします。クエリごとに小さな部分のみを取得するためです。ベクトルデータベースに1,000万のドキュメントをインデックス化でき、モデルは任意の質問に対して最も関連性の高いいくつかのドキュメントのみを見ます。このスケーラビリティは、ナレッジベースが継続的に成長する企業アプリケーションにとって重要です。CAGには、モデルのコンテキストウィンドウサイズによって決定されるハードスケーラビリティ制限があります。典型的な32,000から100,000トークンのコンテキストウィンドウでは、せいぜい数百のドキュメントしか収まりません。コンテキストウィンドウが成長しても(そして成長すると予想されます)、RAGは検索メカニズムが任意に大きなナレッジベースを処理できるため、スケーラビリティで優位性を維持する可能性があります。

データの鮮度:知識を最新に保つ

RAGはデータの鮮度をエレガントに処理します。ナレッジベースが変更されると、ベクトルデータベースを更新するだけです。新しいドキュメントを段階的に追加し、古いドキュメントを削除でき、システムはこの新しい情報をすぐに使用します。ダウンタイムは最小限であり、何も再計算する必要はありません。これにより、RAGは情報が頻繁に変化する領域に理想的です。CAGはデータが変更されると再計算が必要です。ナレッジベースが更新された場合、新しい情報を反映するためにKVキャッシュを再計算する必要があります。この再計算は、キャッシングの利点を無効にし、大きなオーバーヘッドを導入します。ナレッジベースが頻繁に変更される場合、CAGは魅力の多くを失います。なぜなら、常に再ロードと再計算を行っているため、キャッシングの目的が無効になるからです。

実世界のアプリケーションシナリオ:RAGかCAGか?

RAGとCAGの選択は抽象的ではありません。特定のユースケースに依存します。この決定を行う方法を理解するために、いくつかのシナリオを検証しましょう。

シナリオ1:製品マニュアルを使用したITヘルプデスクボット

製品マニュアルの200ページを使用して回答を拡張するITヘルプデスクチャットボットを構築していると想像してください。マニュアルは年に数回しか更新されず、ユーザーは製品の使用方法について質問を送信します。これはCAGシナリオです。ナレッジベースは、ほとんどの言語モデルのコンテキストウィンドウに快適に収まるほど小さいです。情報は静的であるため、KVキャッシュは頻繁な更新を必要としません。製品マニュアルをキャッシュすることにより、システムは最小限のレイテンシでユーザーの質問に回答でき、迅速なサポート応答を提供できます。CAG展開のシンプルさも、このユースケースに意味があります。小さな静的なナレッジベースに対して、ベクトルデータベースと検索パイプラインの複雑さは必要ありません。

シナリオ2:法律事務所の法的調査アシスタント

次に、新しい判決や修正で常に更新されている数千の法的ケースを検索する必要がある法律事務所の調査アシスタントを考えてみましょう。弁護士は、関連する法的文書への正確な引用を含む回答を必要とします。これは明らかにRAGシナリオです。ナレッジベースは大規模で動的であり、新しいコンテンツが継続的に追加されています。このすべての情報をキャッシュしようとすると、ほとんどのモデルのコンテキストウィンドウをすぐに超えてしまいます。ソース資料への正確な引用の要件は、RAGが検索メカニズムを通じて自然にサポートするものです。情報がどこから来たかを正確に伝えます。新しい法的文書が出現するにつれてベクトルデータベースを段階的に更新する能力は、システムが完全なキャッシュ再計算を必要とせずに常に最新の情報にアクセスできることを意味します。

シナリオ3:病院の臨床意思決定支援システム

医師が患者記録、治療ガイド、薬物相互作用を照会する臨床意思決定支援システムを考えてみましょう。応答は包括的で非常に正確でなければなりません。なぜなら、患者の診察中に使用されるからです。医師はしばしば複雑なフォローアップの質問をします。これはハイブリッドシナリオです。システムは、最初にRAGを使用して、大規模なナレッジベースから最も関連性の高いサブセットを取得できます。医師のクエリに基づいて、患者の履歴の特定のセクションと関連する研究論文を引き出します。取得されたチャンクを単に言語モデルに渡すのではなく、システムは取得されたすべてのコンテンツをCAGを使用する長いコンテキストモデルにロードし、特定の患者ケースのための一時的な作業メモリを作成できます。このハイブリッドアプローチは、RAGの膨大なナレッジベースを効率的に検索する能力と、CAGのデータベースを繰り返し照会することなくフォローアップの質問に包括的な知識を提供する能力を組み合わせます。

高度な洞察:ハイブリッドアプローチと将来の方向性

最も洗練されたAIシステムは、RAGとCAGのどちらかを選択するのではなく、両方を戦略的に使用します。ハイブリッドアーキテクチャは、初期検索にRAGのスケーラビリティとデータの鮮度を活用し、詳細な処理にCAGの速度と包括性を使用します。このアプローチは、システムが大規模なナレッジベースにアクセスしながら、複数の質問にわたってコンテキストを維持する必要がある複雑なマルチターン会話に特に強力です。コンテキストウィンドウの拡張は、RAG対CAGの計算を変えています。言語モデルがより大きなコンテキストウィンドウを開発するにつれて(一部は現在200,000トークン以上をサポートしています)、CAGはより大きなナレッジベースに対して実行可能になります。ただし、拡張されたコンテキストウィンドウがあっても、RAGは真に大規模なナレッジベースと頻繁に更新される情報に対して利点を維持する可能性があります。検索の最適化は、RAGのレイテンシを改善し続けています。密なパッセージ検索、キーワードとセマンティック検索を組み合わせたハイブリッド検索、学習された検索メカニズムなどの技術により、RAGはより高速で正確になっています。これらの改善により、RAGとCAGの間のレイテンシギャップが狭まっています。キャッシングの革新により、CAGはより柔軟になっています。部分的なキャッシュ更新と選択的再計算の技術により、CAGは最終的に完全な再計算なしでより動的なナレッジベースを処理できるようになる可能性があります。将来は、両方の技術の強みを組み合わせた、ますます洗練されたハイブリッドアプローチを含む可能性があります。

結論

RAGとCAGは、外部知識で言語モデルを拡張するための2つの根本的に異なる哲学を表しています。RAGは必要なものだけをオンデマンドで取得し、検索レイテンシを犠牲にして、比類のないスケーラビリティ、データの鮮度、透明性を提供します。CAGはすべての知識を事前にロードし、優れた速度とシンプルさを提供しますが、コンテキストウィンドウサイズと静的な知識によって制約されます。それらの間の選択、またはハイブリッドアプローチで両方を使用する決定は、特定の要件に依存します。ナレッジベースのサイズ、情報が変更される頻度、ソース引用が必要かどうか、アプリケーションにとって応答レイテンシがどれほど重要かです。現代のAIシステムは、これが二者択一ではなく、特定のユースケースに対して組み合わせて最適化できる戦略のスペクトルであることをますます認識しています。各アプローチの強みと制限を理解することにより、実世界のアプリケーションで精度と効率の両方を提供するAIシステムを設計できます。