以下の記事が面白かったので、簡単にまとめました。

1. はじめに

Googleは、1Mコンテキストウィンドウを持つ「Gemini 1.5 Pro」をリリースしました。初期ユーザーは、数十もの研究論文や財務報告書を一度に入力した結果を共有しており、膨大な情報を理解する能力という点で印象的な結果を報告しています。

当然のことながら、ここで疑問が生じます。「RAG」は死んだのでしょうか？そう考える人もいますが、そうではない人もいます。

幸運にも「Gemini 1.5 Pro」の機能をプレビューすることができ、それを試してみることで、ロングコンテキストLLMを適切に使用するには、RAGがどのように進化するのかについてのまとめました。

2. Gemini 1.5 Pro の 初期観察

「Gemini」の結果は印象的で、テクニカルレポートやソーシャルで見てきたものと一致しています。

「Gemini」が苦手としていることに気づいた部分がいくつかあります。

3. ロングコンテキストLLMが解決するもの・しないもの

ロングコンテキストLLMが解決すると考えられる既存の「RAG」の問題点は、次のとおりです。

ただし、依然として残る課題がいくつかあります。

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 インターフェイスは未定です。また、キャッシュ自体の性質が進化するのか、それともキャッシュを最大限に活用するアルゴリズムが進化するのかについても未定です。