llamaIndex blog - ロングコンテキストRAGに向けて

2024年3月12日 19:15

ジェリー・リュー 氏の2024 年 3 月 1 日のブログより

Googleは最近、1Mのコンテキストウィンドウを備えたGemini 1.5 Proをリリースし、限られた開発者と企業顧客が利用できるようになった。そのパフォーマンスは、AIツイッターの想像力をかきたてました。これは、Greg Kamradtによって普及した「干し草の山の中の針」実験で99.7%の再現率を達成しました。初期のユーザーは、数十の研究論文や財務レポートを一度にフィードする結果を共有し、膨大な情報の宝庫を統合する能力という点で印象的な結果を報告しています。

当然のことながら、これは疑問を投げかけます-RAGは死んでいますか?そう考える人もいれば、そう思わない人もいます。最初の陣営の人たちは、有効なポイントを作ります。ほとんどの小さなデータのユースケースは、1〜10Mのコンテキストウィンドウに収まります。トークンは、時間の経過とともにより安価で迅速に処理できるようになります。アテンション層を介してLLMがネイティブにインターリーブ検索/生成を行うと、ナイーブRAGに存在するワンショット検索と比較して、応答品質が高くなります。

幸運なことに、Gemini 1.5 Proの機能のプレビューを見ることができ、それをいじってみて、コンテキスト拡張LLMアプリケーションがどのように進化するかについての論文を作成しました。このブログ記事では、データフレームワークとしての私たちの使命と、ロングコンテキストLLMアーキテクチャがどのようなものになるかについての見解を明確にします。ロングコンテキストLLMはRAGパイプラインの特定の部分(チャンクなど)を簡素化しますが、ロングコンテキストLLMがもたらす新しいユースケースを処理するには、RAGアーキテクチャを進化させる必要があると考えています。どのような新しいパラダイムが出現しようとも、LlamaIndexの使命は、その未来に向けたツールを構築することです。

私たちの使命はRAGを超えています

LlamaIndex の目標は非常に単純で、開発者が自分のデータに対して LLM アプリケーションを構築できるようにすることです。このミッションはRAGだけにとどまりません。これまで、既存のLLMのRAG技術を進化させるためにかなりの労力を費やしてきましたが、これは、開発者が半構造化データ、複雑なドキュメント、マルチドキュメント設定でのエージェント推論など、何十もの新しいユースケースを解き放つことができたからです。

しかし、私たちはGemini Proにも期待しており、LlamaIndexをロングコンテキストLLMの未来におけるプロダクションデータフレームワークとして進化させていきます。

LLMフレームワークは本質的に価値があります。オープンソースのデータフレームワークであるLlamaIndexは、プロトタイプから本番環境まで、あらゆるLLMユースケースを構築するための道筋を開きます。フレームワークを使用すると、ゼロから構築するよりも、これらのユースケースを簡単に構築できます。私たちは、すべての開発者が、コア抽象化を使用して適切なアーキテクチャを設定する場合でも、エコシステムの何百もの統合を活用する場合でも、これらのユースケース向けに構築できるようにします。基礎となるLLMの進歩が何であれ、RAGが現在の形で存在し続けるかどうかに関係なく、私たちは、完全な抽象化、ファーストクラスのドキュメント、一貫性など、フレームワークを本番環境に対応し続けます。

また、先週はLlamaCloudもリリースしました。LlamaCloudのミッションは、あらゆる企業が膨大な非構造化データソース、半構造化データソースをLLMで使用できるようにするデータインフラを構築することです。

Gemini 1.5 Proの初期観測

最初のテストでは、SEC 10K ファイリング、ArXiv 論文、このモンスター Schematic Design Binder など、いくつかの PDF を試しました。APIが利用可能になったら、より詳細な分析を行いますが、それまでの間、以下の観察結果を共有します。

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

Geminiは、特定の詳細について印象的な思い出を持っています。私たちは100k-1Mのコンテキストトークンを投入し、これらの文書の非常に具体的な詳細(非構造化テキストと表形式のデータ)について質問し、すべてのケースでGeminiは詳細を思い出すことができました。2019 年の Uber 10K ファイリングにおける Gemini の比較表については、上記を参照してください。
Geminiには優れた要約機能があります。このモデルでは、複数のドキュメントにまたがる大量の情報を分析し、回答を合成できます。

この図は、2019 年の Uber 10K ファイリングに関する Gemini からの質問と回答のペアを示しています。質問と回答が上部に表示され、ソーステーブルが下部に表示されます。双子座は正しい答えを返すことができます。

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

Geminiは、すべての表とチャートを正しく読み取るわけではありません。Gemini Proは、図や複雑な表を読み取るのにまだ苦労しています。
双子座は長い時間がかかることがあります。Uber 10K ファイリング (~160k) で回答を返すには、~20 秒かかります。LHS 回路図設計バインダー (~890k) で回答を返すには、~60+ 秒かかります。
Geminiはページ番号の幻覚を見ることがあります。要約とページ番号の引用を求められたとき、Geminiは情報源の幻覚を見ました。

Gemini 1.5 Proがまだ幻覚を見ている例。このモデルは、すべてのセグメントの総予約数について尋ねられると、数字の幻覚を見ます - その数字はグラフに表示され、表からつなぎ合わせることもできます。

しかし、方向性としては、未来を垣間見るエキサイティングなものであり、どのRAGパラダイムが衰退し、新しいアーキテクチャが出現するかについて、より大きな議論が必要です。以下を参照してください!

長いコンテキストはいくつかの問題点を解決するが、いくつかの課題が残る

Gemini 1.5 Proは、多くのロングコンテキストLLMの初登場に過ぎず、必然的にユーザーがRAGを構築する方法を変えるでしょう。

ここでは、ロングコンテキストLLMが解決できると思われる既存のRAGの問題点をいくつか紹介します。

開発者は、チャンクアルゴリズムを正確に調整する方法について心配する必要がなくなります。正直なところ、これはLLM開発者にとって大きな祝福になると思います。ロングコンテキスト LLM を使用すると、ネイティブチャンクサイズを大きくすることができます。トークンあたりのコストとレイテンシーも下がると仮定すると、開発者は、チャンクセパレーター、チャンクサイズ、および慎重なメタデータインジェクションを調整することで、チャンクを細かいストリップに分割する方法を決定する必要がなくなります。ロングコンテキスト LLM を使用すると、チャンクをドキュメント全体のレベル、または少なくともページのグループにすることができます。
開発者は、1 つのドキュメントに対する検索と思考の連鎖の調整に費やす時間を減らす必要があります。小さなチャンクのtop-k RAGの問題は、特定の質問がドキュメントの特定のスニペットに対して回答される可能性がある一方で、セクション間または2つのドキュメント間の詳細な分析が必要な質問(比較クエリなど)があることです。これらのユースケースでは、開発者は弱いレトリーバーに対して2つの検索を行うために思考の連鎖エージェントに頼る必要がなくなります。代わりに、LLMに回答を取得するように促すだけで済みます。
要約が簡単になります。これは上記の記述に関連しています。大きな文書に対する多くの要約戦略には、逐次的洗練や階層的要約などの「ハック」が含まれます(リファレンスガイドとして、応答合成モジュールを参照してください)。これは、1 回の LLM 呼び出しで軽減できるようになりました。
パーソナライズされたメモリは、より良く、より簡単に構築できます。会話型アシスタントを構築するための重要な問題は、十分な会話コンテキストをプロンプトウィンドウにロードする方法を見つけることです。4kトークンは、非常に基本的なウェブ検索エージェントの場合、このウィンドウを簡単にオーバーフローさせます - 例えば、ウィキペディアのページにロードすることを決定した場合、そのテキストは簡単にコンテキストをオーバーフローします。1M-10Mのコンテキストウィンドウにより、開発者はより少ない圧縮ハック(ベクトル検索や自動KG構築など)で会話型メモリをより簡単に実装できます。

ただし、いくつかの課題が残っています。

10Mトークンでは、大規模な文書コーパスには不十分であり、Kilodocの検索は依然として課題です。1Mトークンは、Uber SECの10Kファイリングの約~7件に相当します。10Mトークンは、約~70のファイリングになります。10Mトークンは、おおよそ40MBのデータで制限されます。多くの「小規模な」ドキュメントコーパスにはこれで十分ですが、企業内の多くのナレッジコーパスはギガバイトまたはテラバイト単位です。これらの知識コーパス上にLLMを利用したシステムを構築するには、開発者は、このデータを取得して言語モデルをコンテキストで補強する何らかの方法を構築する必要があります。
埋め込みモデルは、コンテキストの長さが遅れています。これまでのところ、埋め込みで確認された最大のコンテキストウィンドウは、together.ai の 32k です。つまり、ロングコンテキストLLMでの合成に使用されるチャンクが大きくなる可能性がある場合でも、取得に使用されるテキストチャンクははるかに小さくする必要があります。
コストとレイテンシー。はい、コストとレイテンシーに関するすべての懸念は、時間の経過とともに軽減されます。それにもかかわらず、1M コンテキストウィンドウを詰め込むには ~60 秒かかり、現在の価格では $0.50 から $20 の費用がかかります。Yao Fu氏が提起した解決策は、KVキャッシュがドキュメントのアクティベーションをキャッシュして、後続の世代が同じキャッシュを再利用できるようにすることです。これは、以下の次のポイントにつながります。
KV キャッシュは大量の GPU メモリを消費し、シーケンシャルな依存関係を持ちます。Yao氏と話をしたところ、現時点では、1Mトークン相当のアクティベーションをキャッシュすると、約100GBのGPUメモリ、つまり2つのH100が消費されるとのことでした。また、特に基礎となるコーパスが大きい場合、キャッシュを最適に管理する方法に関する興味深い課題もあります - 各アクティベーションは、それに至るまでのすべてのトークンの関数であるため、KVキャッシュ内のドキュメントを置き換えると、ドキュメントに続くすべてのアクティベーションに影響します。

新しいRAGアーキテクチャに向けて

ロングコンテキストLLMを適切に使用するには、残りの制約を回避しながら、その機能を最大限に活用するための新しいアーキテクチャが必要になります。以下にいくつかの提案の概要を示します。

1. 文書の小規模から大規模への検索

長いコンテキストのLLMが大きな知識ベース(例えばギガバイト単位)で検索の拡張を必要とする限り、小さなチャンクにインデックスを付けて取得するが、各チャンクは合成中に最終的にLLMに供給される大きなチャンクにリンクさせるという、小さなものから大きなものへの検索が必要になります。

このアーキテクチャは、さまざまな形式(センテンスウィンドウレトリーバーとチャンクサイズでの再帰的検索)でLlamaIndexにすでに存在しますが、ロングコンテキストLLMではさらにスケールアップできます(ドキュメントの要約を埋め込みますが、ドキュメント全体にリンクします)。

小さなチャンクを埋め込んでインデックスを付けたい理由の1つは、現在の埋め込みモデルがコンテキストの長さの点でLLMに追いついていないという事実によるものです。もう 1 つの理由は、1 つのドキュメントに対して 1 つのドキュメントレベルの埋め込みを行う場合と比較して、複数の詳細な埋め込み表現を持つことで、実際には検索の利点があることです。ドキュメントに 1 つの埋め込みがある場合、その埋め込みには、ドキュメント全体のすべての情報をエンコードする負荷がかかります。一方、多くの小さなチャンクを埋め込み、それぞれの小さなチャンクを大きなチャンクにリンクさせることで、関連情報の取得がしやすくなることがわかっています。

上の図は、小規模から大規模までの 2 種類の取得の図です。1 つはドキュメントの概要にインデックスを付けてドキュメントにリンクする方法で、もう 1 つはドキュメント内の小さなチャンクにインデックスを付けてドキュメントにリンクする方法です。もちろん、両方を行うこともできますが、検索を改善するための一般的なベストプラクティスは、一度に複数の手法を試し、後で結果を融合することです。

2. レイテンシーとコストのトレードオフのためのインテリジェントルーティング

ロングコンテキストLLMの登場により、各ユースケースに適したコンテキストの量について疑問が生じることは避けられません。長いコンテキストを持つLLMの挿入には、実際のコストとレイテンシーのトレードオフが伴い、すべてのユースケースやすべての質問に適しているわけではありません。将来的にはコストとレイテンシーは減少しますが、ユーザーは今後1〜2年の間、このトレードオフについて慎重に検討する必要があると予想されます。

特定の詳細について尋ねる特定の質問は、top-kの検索と合成の既存のRAG手法に適しています。

より複雑な質問では、異なるドキュメントの異なる部分からより多くのコンテキストが必要であり、そのような設定では、レイテンシーとコストを最適化しながら、これらの質問に正しく答える方法が明確ではありません。

要約の質問では、ドキュメント全体に目を通す必要があります。
複数の部分からなる質問は、思考の連鎖を行い、検索と推論をインターリーブすることで解決できます。また、すべてのコンテキストをプロンプトに押し込むことで解決することもできます。

私たちは、ナレッジベース上の複数のRAGおよびLLM合成パイプライン上で動作するインテリジェントなルーティングレイヤーを想像しています。質問が与えられた場合、ルータは、質問に答えるためのコンテキストを取得するという点で、コストと遅延の観点から最適な戦略を理想的に選択できます。これにより、1 つのインターフェイスでさまざまな種類の質問を処理でき、法外なコストがかかることはありません。

3. 検索拡張KVキャッシング

Googleや他の企業が確実に取り組んでいる最適化は、KVキャッシュを通じてレイテンシーとコストの懸念を解決することです。大まかに言うと、KVキャッシュは既存のキーベクトルとクエリベクトルからのアクティベーションをアテンションレイヤーに格納し、LLM生成中にテキストシーケンス全体のアクティベーションを再計算する必要がなくなります(これはKVキャッシュがどのように機能するかについての優れた入門書であることがわかりました)。

KVキャッシュを使用してコンテキストウィンドウ内のすべてのドキュメントトークンをキャッシュすると、後続の会話でこれらのトークンのアクティブ化を再計算する必要がなくなり、レイテンシーとコストが大幅に削減されます。

しかし、これは、特にコンテキストの長さを超えるナレッジコーパスに対して、キャッシュを最適に使用する方法に関する興味深い検索戦略につながります。「検索拡張キャッシュ」パラダイムの出現を想像し、ユーザーがキャッシュ内のドキュメントを引き続き使用することを期待して、ユーザーが回答したいと思う最も関連性の高いドキュメントを取得したいと考えています。

これには、LRU キャッシングなどの従来のキャッシングアルゴリズムを使用した検索戦略のインターリーブが含まれる場合があります。しかし、既存のKVキャッシュアーキテクチャとの違いは、キャッシュされたベクトルは、ドキュメント自体のトークンだけでなく、その位置に至るまでのすべてのトークンの関数であるため、位置が重要であることです。つまり、KV キャッシュからチャンクをスワップアウトするだけで、その後に発生するすべてのキャッシュされたトークンに位置的に影響を及ぼすことはできません。

一般に、KVキャッシュを使用するためのAPIインターフェースは宙に浮いています。また、キャッシュ自体の性質が進化するのか、それともキャッシュを最大限活用するためにアルゴリズムが進化するのかについても、議論の余地があります。