ロングコンテキストLLMに対応したRAGの新アーキテクチャ
以下の記事が面白かったので、簡単にまとめました。
1. はじめに
Googleは、1Mコンテキストウィンドウを持つ「Gemini 1.5 Pro」をリリースしました。初期ユーザーは、数十もの研究論文や財務報告書を一度に入力した結果を共有しており、膨大な情報を理解する能力という点で印象的な結果を報告しています。
当然のことながら、ここで疑問が生じます。「RAG」は死んだのでしょうか？そう考える人もいますが、そうではない人もいます。
幸運にも「Gemini 1.5 Pro」の機能をプレビューすることができ、それを試してみることで、ロングコンテキストLLMを適切に使用するには、RAGがどのように進化するのかについてのまとめました。
2. Gemini 1.5 Pro の 初期観察
「Gemini」の結果は印象的で、テクニカルレポートやソーシャルで見てきたものと一致しています。
・Gemini は特定の詳細を見事に思い出すことができる
10万から100万トークンを入力し、これらの文書の非常に具体的な詳細について質問しましたが、すべてのケースで「Gemini」は詳細を思い出すことができました。
・Gemini は素晴らしい要約能力を持つ
複数のドキュメントにわたる大量の情報を分析し、回答を合成できました。
「Gemini」が苦手としていることに気づいた部分がいくつかあります。
・Gemini はすべての表やグラフを正しく読むことができない
図や複雑な表を読むのにまだ苦労しています。
・Gemini は時間がかかることがある
「Uber 10K Filing」(~160k) で応答を返すには~20 秒、「LHS Schematic Design Binder」(~890k) で応答を返すには~60 秒以上かかりました。
・Gemini はページ番号の幻覚を見ることがある
概要だけでなくページ番号も引用するよう求められた時、「Gemini」はページ番号の幻覚を見ました。
3. ロングコンテキストLLMが解決するもの・しないもの
ロングコンテキストLLMが解決すると考えられる既存の「RAG」の問題点は、次のとおりです。
・チャンクの調整に頭を悩ませる必要がなくなる
ロングコンテキストLLMにより、ネイティブチャンク サイズを大きくすることができます。チャンクのセパレータ、サイズ、メタデータなどの決定に、頭を悩ませる必要がなくなります。ロングコンテキストLLMを使用すると、チャンクをドキュメント全体レベル、または少なくともページグループレベルにすることができます。
・思考連鎖エージェントの調整に頭を悩ませる必要がなくなる
small-chunk top-k RAG の問題は、ドキュメントの特定のスニペットに関して特定の質問に回答できる一方で、セクション間またはドキュメント間の詳細な分析 (比較など) が必要な質問もあることです。これらのユースケースでは、思考連鎖エージェントに依存する必要がなくなりました。代わりに、LLMのワンショットで応答を求めることができます。
・要約が容易になる
大きなドキュメントに対する要約の多くには、逐次改良や階層的要約などの「ハック」が含まれます。この問題は、1 回のLLM 呼び出しで軽減できるようになりました。
・パーソナライズされた記憶の構築が向上し容易になりる
会話アシスタントを構築する際の重要な問題は、プロンプトウィンドウに十分な会話コンテキストを読み込む方法を見つけることです。4Kトークンは、非常に基本的なWeb検索エージェントのこのウィンドウを簡単にオーバーフローさせます。1M ～ 10Mのコンテキストウィンドウにより、開発者はより少ない圧縮ハック (ベクトル検索や自動KG構築など) で会話型メモリをより簡単に実装できるようになります。
ただし、依然として残る課題がいくつかあります。
・10Mトークンは大規模な文書コーパスには十分ではない
10Mトークンは、小さな文書コーパスには十分ですが、企業内の多くの知識コーパスはGBやTBに及びます。このような知識コーパスにLLMを搭載したシステムを構築するには、開発者は、言語モデルをコンテキストで補強するために、このデータを取得する何らかの方法を組み込む必要があります。
・埋め込みモデルはコンテキスト長の点で遅れている
埋め込みに関して確認した最大のコンテキストウィンドウは、together.aiの32Kです。これは、ロングコンテキストLLMでの合成に使用されるチャンクが大きくても、取得に使用されるテキスト チャンクはさらに小さくする必要があることを意味します。
・コストとレイテンシー
コストとレイテンシーに関する懸念は時間の経過とともに軽減されます。それにもかかわらず、1Mのコンテキストウィンドウを埋めるには最大60秒かかり、現在の価格では 0.50 ドルから 20 ドルの費用がかかる可能性があります。Yao Fu が提案したこれに対する解決策は、「KV Cache」でドキュメントのアクティベーションをキャッシュできるため、後続の生成が同じキャッシュを再利用できるようにするというものです。
・KVキャッシュは大量のGPUメモリを占有し、逐次的な依存関係を持つ
Yao とチャットしたところ、現時点では 1Mトークン相当のアクティベーションをキャッシュすると、約100GBのGPU メモリが使用されるとのことでした。また、特に基礎となるコーパスが大きい場合に、キャッシュを最適に管理する方法についても興味深い課題があります。各アクティベーションは、それに至るまでのすべてのトークンの関数であるため、「KV Cache」
内のドキュメントを置き換えると、ドキュメントに続くすべてのアクティベーションに影響します。
4. ロングコンテキストLLMに対応したRAGの新アーキテクチャ
ロングコンテキストLLMを適切に使用するには、残りの制約を回避しながら、その機能を最大限に活用するために、RAGの新アーキテクチャが必要になります。
以下にいくつかの提案を概説します。
4-1. Small-to-Big Retrieval
ロングコンテキストLLMが大規模な知識ベース (例: GB単位) にわたる検索の拡張を必要とする限り、「Small-to-Big Retrieval」が必要になります。つまり、小さなチャンクにインデックスを付けて取得しますが、各チャンクは最終的には大きなチャンクにリンクされます。
このアーキテクチャは、「LlamaIndex」にさまざまな形式 (sentence window retriever と recursive retrieval over chunk sizes)ですでに存在していますが、長いコンテキストのLLM向けにさらにスケールアップすることができます。つまり、文書の概要を埋め込みますが、文書全体にリンクします。
より小さいチャンクを埋め込み、インデックスを付けたい理由の1つは、現在の埋め込みモデルがコンテキストの長さの点で「LLM」に追いついていないためです。もう1つの理由は、ドキュメントに対する単一のドキュメントレベルの埋め込みと比較して、複数の粒度の高い埋め込み表現を持つ方が実際に検索上の利点があることです。ドキュメントに単一の埋め込みがある場合、その埋め込みには、ドキュメント全体のすべての情報をエンコードするという負担がかかります。一方で、多数の小さなチャンクを埋め込み、それぞれの小さなチャンクを大きなチャンクにリンクさせると、関連情報の取得が向上することがわかっています。
4-2. レイテンシーとコストのトレードオフを実現するルーティング
ロングコンテキストLLMの登場により、各ユースケースに適したコンテキスト量について必然的に疑問が生じます。ロングコンテキストLLM の挿入には実際のコストとレイテンシのトレードオフが伴い、すべてのユースケースやすべての質問に適しているわけではありません。コストとレイテンシーは将来的には減少しますが、今後 1～2 年の間、このトレードオフについて慎重に検討する必要があると予想されます。
知識ベース上の複数のRAGおよびLLM合成パイプライン上で動作するインテリジェントなルーティング層を想像します。質問が与えられると、ルーターは理想的には、質問に答えるためのコンテキストを取得する際のコストと遅延の観点から最適な戦略を選択できます。これにより、法外に高価になることなく、単一のインターフェイスでさまざまな種類の質問を処理できるようになります。
4-3. Retrieval Augmented KV Caching
Googleや他の企業が確実に取り組んでいる最適化は、「KV Cache」を通じてレイテンシーとコストの問題を解決することです。大まかに言うと、「KV Cache」は既存のキー ベクトルとクエリベクトルからのアクティベーションをアテンションレイヤーに保存し、LLM生成中にテキストシーケンス全体にわたるアクティベーションを再計算する必要を防ぎます。
「KV Cache」を使用してコンテキストウィンドウ内のすべてのドキュメント トークンをキャッシュすると、後続の会話でこれらのトークンのアクティベーションを再計算する必要がなくなり、待ち時間とコストが大幅に削減されます。
しかし、特にコンテキストの長さを超える知識コーパスの場合、キャッシュを最適に使用する方法に関する興味深い検索戦略につながります。そこで、ユーザーがキャッシュ内にあるドキュメントを引き続き使用することを期待しながら、ユーザーが答えたいと思う最も関連性の高いドキュメントを取得する「Retrieval Augmented Caching」パラダイムの出現を想像しています。
これには、LRUキャッシュなどの従来のキャッシュアルゴリズムと取得戦略をインターリーブすることが含まれる可能性があります。しかし、既存の「KV Cache」アーキテクチャとの違いは、キャッシュされたベクトルはドキュメント自体内のトークンだけでなく、その位置に至るまでのすべてのトークンの関数であるため、位置が重要であるということです。これは、位置的にその後に発生するすべてのキャッシュされたトークンに影響を与えずに、
「KV Cache」からチャンクを単にスワップアウトすることはできないことを意味します。
一般に、「KV Cache」を使用するための API インターフェイスは未定です。また、キャッシュ自体の性質が進化するのか、それともキャッシュを最大限に活用するアルゴリズムが進化するのかについても未定です。
この記事が気に入ったらサポートをしてみませんか？