HUOXIU

RAG におけるリアルタイム検索のボトルネックを回避し、キャッシュ拡張生成 (CAG) によってパフォーマンスの飛躍的な向上をどのように実現できるのでしょうか。

編集者注: RAGベースのアプリケーションを開発する際に、リアルタイム検索の遅延によってユーザーエクスペリエンスが著しく低下したり、複雑なクエリを処理する際に不正確な検索結果によって回答品質が不十分になったりといった問題に遭遇したことはありませんか?

大規模言語モデルアプリケーションの普及に伴い、これらの課題は製品の競争力を阻害する主要なボトルネックとなりつつあります。従来のRAGソリューションにおける検索遅延、精度の変動、そしてシステムの複雑さは、開発者の忍耐力と創意工夫を試しています。

キャッシュ型拡張生成(CAG)技術は、次世代大規模言語モデルの能力を巧みに活用し、長いコンテキストを処理できるようにします。文書を事前に読み込み、キーバリューキャッシュを事前に計算することで、リアルタイム検索の必要性を排除します。実験結果によると、管理可能な知識ベースのシナリオにおいて、このアプローチは推論時間を数倍短縮するだけでなく、より一貫性と精度の高い応答を提供することが示されています。

著者 | ヴィシャール・ラージプート

編纂者:岳陽

検索強化生成(RAG)は、外部知識源を統合することで言語モデルを強化する強力な手法として、大きな注目を集めています。しかし、このアプローチには、検索プロセスにおける遅延、文書選択における潜在的なエラー、システムの複雑さの増大といった課題も存在します。

より長いコンテキストを処理できる大規模言語モデル(LLM)の台頭に伴い、リアルタイムの情報検索を回避できるキャッシュ型拡張生成(CAG)技術が登場しました。この技術は、必要なリソースをすべてモデルの拡張コンテキストにプリロードし、関連する実行時パラメータをキャッシュすることで、管理しやすい限られた数の文書や知識を扱う場合に特に効果的です。

早速、この斬新な技術について詳しく見ていきましょう。

この記事では、以下のトピックについて説明します。

  • RAG はコンテキスト処理機能をどのように拡張できるでしょうか?
  • 無限に拡張可能なコンテキストウィンドウ
  • CAG テクノロジーの利点は何ですか?
  • その他の改善点
  • CAGフレームワークの仕組み
  • 要約

01 RAG はコンテキスト処理機能をどのように拡張できますか?

RAGはセミパラメトリックシステムであり、パラメトリック部分は大規模な言語モデルで構成され、ノンパラメトリック部分はその他の要素を含みます。これら2つの部分を組み合わせることで、セミパラメトリックシステムが形成されます。LLMでは、すべての情報はモデルの重みまたはパラメータにエンコードされた形式で保存されますが、システムの他の部分ではパラメータを用いてこれらの知識を定義することはありません。

それで、この設計はどのように問題を解決するのでしょうか?

  • LLM 内のインデックス (つまり特定の情報) を柔軟に置き換えることで、情報をパーソナライズできるため、古い情報に制限されず、インデックスの内容を更新することもできます。
  • LLM をこれらのインデックスと組み合わせることで、誤った情報の生成を減らすことができ、情報の元のソースを指し示すことで帰属と説明を提供することができます。

したがって、理論的には、RAG は LLM のより優れたコンテキストを作成する能力を強化し、LLM のパフォーマンスを向上させます。

しかし、このプロセスは本当にそんなに簡単なのでしょうか?答えは「ノー」です。

既存の RAG システムは十分にインテリジェントではなく、比較的単純であるため、多くのカスタム コンテキストを必要とする複雑なタスクを処理できません。

つまり、簡単に言えば、コンテキスト ウィンドウによって LLM に課せられた制限があったからこそ、RAG を開発することができたのです。

02 無限に拡大するコンテキストウィンドウ

関連する論文は、「Leave No Context Behind: Efficient Infinite Context Transformers with Infini-attention」です。

本論文では、限られたメモリと計算リソースの制約下で、Transformerベースの大規模言語モデル(LLM)を拡張し、無限長の入力を処理できる効率的な手法を提案する。この手法の重要な革新は、Infini-Attentionと呼ばれる新しいアテンション機構である。

Infini-Attentionの中核となるアイデアは、局所的な注意とグローバルな注意を組み合わせることです。具体的には、まず記事全体を複数のセグメントに分割します。1つのセグメントには標準的な注意メカニズムを適用し、前のセグメントのコンテキストを捉えるために線形注意メカニズムを使用します。以下は、この論文の概要です。

  • ハイブリッド注意メカニズム: 局所注意は単語の周囲の直接的な文脈に焦点を当て、一方、長距離注意はこれまでに見たシーケンス全体の圧縮された要約を参照することで全体的な視点を維持します。
  • 圧縮メモリ: 線形注意を使用して以前のテキストセグメントを記憶します。
  • 効率的な更新:冗長性を避け、計算量を節約するため、Infini-Attentionは新しい情報を直接メモリに追加しません。代わりに、まず既知の情報をチェックし、その後、メモリ内の新しい情報または異なる情報のみを更新します。これは、ResNetのスキップ接続に似ています。
  • トレードオフ制御:ハイパーパラメータを通じてローカル情報と圧縮メモリの混合比率を調整します。

03 CAGテクノロジーの利点は何ですか?

検索不要のロングコンテキスト パラダイム: 事前にロードされたドキュメントと事前に計算された KV キャッシュを備えたロングコンテキスト LLM を活用することで、検索の遅延、エラー、システムの複雑さを排除する革新的なアプローチが提案されています。

パフォーマンス比較: 実験では、特に管理しやすい知識ベースでは、長いコンテキストの LLM が従来の RAG システムよりも優れていることが示されています。

実用的な洞察: この論文では、知識集約型ワークフローの効率を向上させる実用的な最適化戦略を提案し、特定のアプリケーション シナリオで検索不要の方法の実現可能性を実証的に検証します。

CAG には、従来の RAG システムに比べて次のような大きな利点があります。

  • 推論時間の短縮: リアルタイムの検索が不要なため、推論プロセスがより高速かつ効率的になり、ユーザーのクエリに迅速に応答できるようになります。
  • 統合コンテキスト: 知識セット全体を LLM にプリロードすることで、ドキュメントを総合的かつ一貫して理解できるようになり、さまざまなタスクにわたる応答の品質と一貫性が向上します。
  • 簡素化されたアーキテクチャ: リトリーバーとジェネレーターを統合する必要がなくなるため、システムが簡素化され、システムの複雑さが軽減され、保守性が向上し、開発コストが削減されます。

04 その他の改善点

知識集約型タスクでは、増加した計算リソースは通常、より多くの外部知識を取り込むために使用されます。しかし、この知識が効果的に活用されなければ、単にコンテキストを拡張するだけでは必ずしもパフォーマンスが向上するとは限りません。

2 つの推論拡張戦略: コンテキスト内学習と反復プロンプト。

これらの戦略は、テスト時の計算を拡張するための柔軟性をさらに高めます (たとえば、取得されるドキュメントの数や生成ステップを増やすことによって)。これにより、LLM がコンテキスト情報を取得して利用する能力が向上します。

私たちは2つの重要な質問に答える必要があります。

(1)最適構成を実行する際に推論計算規模を拡大することでRAGのパフォーマンスをどのように向上させることができるか?

(2)RAG性能と推論パラメータ間の定量的な関係をモデル化することで、与えられた予算制約の下での最適なテスト時の計算資源割り当てを予測できるか?

最適な推論パラメータ設定下では、RAGの性能はテスト中の計算負荷の増加に対してほぼ線形に増加します。実験観察に基づき、RAGの推論拡張則とそれに対応する計算リソース割り当てモデルを導出しました。これにより、異なるハイパーパラメータ設定下でのシステム性能を予測できます。

詳細については、こちらの論文をご覧ください: https://arxiv.org/pdf/2410.04343

もう 1 つの作業では、よりハードウェア (最適化) 設計の観点から検討します。

研究チームは、CXL 2.0プロトコルをベースとし、水平方向にスケーラブルなニアメモリアクセラレーションアーキテクチャを採用したデバイス、インテリジェントナレッジストア(IKS)を開発しました。IKSは、ホストCPUとニアメモリアクセラレータの間に新たなキャッシュコヒーレンスインターフェースを構築することで、飛躍的なパフォーマンス向上を実現します。

512GBのベクトルデータベースにおいて、IKSはIntel Sapphire Rapids CPUと比較して、最近傍探索を13.4~27.9倍高速に実行します。この探索性能の優位性により、一般的なRAGアプリケーションのエンドツーエンド推論時間は1.7~26.3倍短縮されます。メモリエクステンダーとして、IKSの内部DRAMは他のサーバーアプリケーションで使用するために切り離すことができるため、今日のサーバーで最も高価なリソースの一つであるアイドル状態のDRAMリソースの無駄を効果的に回避できます。

詳細については、こちらをご覧ください:https://arxiv.org/pdf/2412.15246

別の論文では、20種類の主要なオープンソースおよび商用の大規模言語モデル(LLM)を対象に、長いコンテキストが検索拡張生成(RAG)のパフォーマンスに与える影響を体系的に調査しました。研究チームは、3つの独自ドメインデータセットを用いてRAGワークフローを実行し、コンテキスト長(2,000トークンから128,000トークン、最大200万トークンまで拡張可能)を変化させました。その結果、RAGアプリケーションにおける長いコンテキストの利点と限界が明らかになりました。

彼らの研究によると、より多くの文書を取得するとパフォーマンスは向上する一方で、64,000トークンを超える長いコンテキストで安定した精度を維持できるのは、最新世代の最先端LLMのうちごくわずかであることが明らかになりました。また、長いコンテキストのシナリオにおける様々な失敗モードも特定され、今後の研究の方向性が示されました。

詳細については、こちらの論文をご覧ください: https://arxiv.org/pdf/2411.03538

05 CAGフレームワークの動作原理

CAGフレームワークは、ロングコンテキストLLMの拡張コンテキスト機能を活用し、リアルタイム検索の必要性を排除します。外部知識ソース(例:文書コレクションD={d1,d2,…})をプリロードし、キーバリュー(KV)キャッシュ(C_KV)をプリコンパイルすることで、従来のRAGシステムの非効率性を克服します。このフレームワークは主に3つのフェーズで動作します。

1. 外部知識のプリロード

  • 選択されたドキュメント セット D は、モデルの拡張コンテキスト ウィンドウに適合するように前処理されます。
  • LLMはこれらの文書を処理し、LLMの推論状態をカプセル化する事前計算済みのキーバリュー(KV)キャッシュに変換します。LLM(M)は文書集合Dを事前計算済みのKVキャッシュにエンコードします。

  • この事前計算されたキャッシュは再利用のために保存され、その後に実行されるクエリの数に関係なく、ドキュメント セット D を処理する計算コストは​​ 1 回だけ支払う必要があります。

2. 推論段階

  • 推論フェーズでは、キー値キャッシュ (C_KV) がユーザークエリ Q とともにロードされます。
  • LLM は、このキャッシュ内のコンテキストを利用してレスポンスを生成するため、取得遅延がなくなり、動的な取得によるエラーや欠落のリスクが軽減されます。LLM は、キャッシュ内のコンテキストを活用してレスポンスを生成します。

この手法は検索の遅延を解消し、検索エラーのリスクを最小限に抑えます。P=Concat(D,Q)というキーワードを組み合わせることで、外部知識とクエリの一貫性を確保できます。

3. キャッシュのリセット

  • パフォーマンスを維持するためには、キーバリューキャッシュを効率的にリセットする必要があります。推論中に新しいトークン(t1、t2、…、tk)がコンテキストウィンドウに追加されると、リセットプロセスによってこれらのトークンが切り捨てられます。

  • 新しいトークンが継続的に追加されるにつれて、KVキャッシュは徐々に拡張されます。リセット時には、新たに追加されたトークンのみを切り捨てて迅速に再初期化するため、キャッシュ全体をディスクから再ロードする必要はありません。この設計により、キャッシュ全体のロードによるI/Oボトルネックを回避し、常に安定したシステム応答速度を実現します。

06 結論

キャッシュ型拡張生成(CAG)は、リアルタイム検索が不可能なシナリオや、極めて低遅延の応答が求められるシナリオにおいて、大きなメリットをもたらします。膨大な外部知識をモデルのコンテキストウィンドウに埋め込むことで、CAGは有益かつコンテキストに関連性​​のある回答を生成し、従来の検索型拡張生成(RAG)システムにおける検索遅延を回避します。

読んでくれてありがとう!

このブログを楽しんで、新しいことを学んでいただければ幸いです。

著者について

ヴィシャール・ラージプート

3x🏆AI のトップライター |

AI ブック 📓: https://rb.gy/xc8m46 |

リンクトイン+: https://www.linkedin.com/in/vishal-rajput-999164122/

終わり

今週のインタラクティブコンテンツ🍻

❓大規模モデルのコンテキストウィンドウが拡大し続ける中で、RAGとCAGの技術ロードマップはどのように進化していくとお考えですか?どのようなシナリオにおいてRAGがより適しているのでしょうか?

オリジナルリンク:

https://medium.com/aiguys/dont-do-rag-it-s-time-for-cag-fb24ff87932b