HUOXIU

ロングコンテキスト LLM: RAG のターミネーターか、それとも最高のパートナーか?

編集者注: 大規模言語モデル (LLM) のコンテキスト ウィンドウが拡大し続けるにつれて、複雑な検索拡張 (RAG) システムの構築に多くの時間とリソースを費やす必要があるのではないかと考え始めたことはありませんか?

本論文では、ロングコンテキストLLMとRAGシステムの長所と短所を詳細に検討し、実用アプリケーションにおけるパフォーマンスの違いを明らかにします。著者らは、最近の4つの学術研究を包括的に分析することで、特定のタスクにおけるロングコンテキストLLMの利点を明らかにするとともに、RAGシステムが特定の特殊なタスクにおいて依然として優位性を持ち、費用対効果が高いことを指摘しています。

著者らは、RAGと長期文脈LLMを組み合わせることで相乗効果を高めることを提案し、統一された評価データセットと指標を含む、より包括的かつ厳密な評価システムの構築を呼びかけています。これら2つの技術を効果的に組み合わせる方法は、将来の人工知能分野における重要な研究方向となるはずです。

著者 | フロリアン・ジューン

編纂者:岳陽

2023年当時、大規模言語モデル(LLM)のコンテキストウィンドウは一般的に4Kから8K程度でした。しかし、2024年7月には、128Kを超えるコンテキストウィンドウを持つLLMがかなり一般的になっていました。

例えば、Claude 2[1]は最大10万のコンテキストウィンドウを備えています。Gemini 1.5[2]は200万のコンテキスト情報を処理できると主張しており、LongRoPE[3]はLLMのコンテキストウィンドウを200万トークン以上に拡張しています。Llama-3--8B-Instruct-Gradient-4194k[4]のコンテキストウィンドウは4194Kに達します。大規模な言語モデルを適用する場合、コンテキストウィンドウのサイズはもはや制限要因ではないようです。

そのため、LLMは一度にすべてのデータを処理できるため、検索強化生成(RAG)システム[5]を構築することが依然として必要であると主張する人もいます。

そのため、一部の研究者は「RAGは死んだ」と宣言しています。しかし、長いコンテキストウィンドウを備えたLLMの登場によってもRAGシステムは消滅せず、RAGは依然として活性化できると考える研究者もいます。

この論文では、次の興味深いトピックに焦点を当てます。長コンテキストLLMは、検索強化生成(RAG)システム[5]の陳腐化につながるでしょうか?

図1: RAGとロングコンテキストLLMの比較。画像は著者による。

この記事の冒頭では、RAGと、長いコンテキストウィンドウを持つ大規模言語モデル(LLM)を直感的に比較します。次に、このトピックに関する最近の学術論文をいくつか分析します。最後に、私自身の考えや洞察をいくつか共有します。

01 RAGとロングコンテキストLLMの比較分析

図 2 は、長いコンテキスト ウィンドウを持つ RAG と LLM をさまざまな側面から視覚的に比較したものです。

図 2: さまざまな次元にわたる RAG と長期コンテキスト LLM の比較分析。

02 学術界における最新の研究成果

上記の内容は直感的な理解を得るのに役立ちますが、これらのテクノロジーの厳密な比較ではありません。

ロングコンテキストLLMの出現も学術界の注目を集めています。以下では、最近発表された4つの研究論文をご紹介します。

  • 長コンテキスト言語モデルは検索、RAG、SQLなどを包含できるか?[6]
  • RAG対ロングコンテキスト:環境レビュー文書理解のための最先端の大規模言語モデルの検討[7]
  • 検索拡張生成か長文脈LLMか?包括的研究とハイブリッドアプローチ[8]
  • ChatQA 2: 長期コンテキストとRAG機能における独自のLLMとのギャップを埋める[9]

2.1 ロングコンテキスト言語モデルは検索、RAG、SQL などを包含できるか?

論文[6]では、LOFTベンチマークを提案している。これは、現実世界のタスクシナリオをシミュレートし、何百万ものトークンのコンテキストを処理して、情報検索と論理的推論における長文脈言語モデル(LCLM)の能力を評価するテスト環境である

LOFT には、図 3 の上部に示すように6 つの主なミッション シナリオが含まれており、RAG はその 1 つです。

図3:LOFTベンチマークの概要。出典:ロングコンテキスト言語モデルは検索、RAG、SQLなどを包含できるか?[6]

図 3 の左下隅には、複数の専用システムの共同作業を必要とする、マルチモーダル検索ツールまたは RAG パイプラインを含む従来の処理フローが示されています

対照的に、図3の右下は長文文脈言語モデル(LCLM)を示しています。LCLMは、テキスト、画像、音声など複数のモダリティを含むコーパス全体を直接モデルへの入力として取り込むことができます。「Context in Corpus」(CiC)キューワード技術を用いることで、このモデルは検索、推論、回答生成といった複数のタスクを統一されたフレームワーク内で実行できます。

評価結果によると、マルチホップデータセット(HotpotQAやMusiQueなど)において、コーパス全体のコンテキスト処理において、Gemini 1.5 ProはRAGパイプラインよりも優れた性能を発揮しました。これは、LCLMが思考連鎖[10]を用いてコンテキストウィンドウ内の複数の段落にまたがる推論を実行できるのに対し、RAGパイプラインは通常、追加の計画・推論モジュールを搭載しない限り、この機能を備えていないためです。

全体的に、LOFTベンチマークのRAG関連タスクでは、Gemini 1.5 Pro(0.53)がRAGパイプライン(0.52)をわずかに上回りました。GPT-4o(0.48)とClaude 3 Opus(0.47)はRAGパイプライン(0.52)よりもパフォーマンスが劣っており、その結果は図4に示されています。

図4: LOFT 128kコンテキストのベンチマークセットにおける主な実験結果。出典: 長コンテキスト言語モデルは検索、RAG、SQLなどを包含できるか?[6]

さらに、図5は、128KのコンテキストウィンドウにおいてはLCLMがRAGと同等の性能を示す一方で、コンテキストウィンドウを1Mに拡張するとRAGパイプラインと比較して性能が低下することを示しています。この傾向は、LCLMのテキスト検索性能の低下と一致しています。

図5:コーパスサイズを32Kトークンから100万トークンに拡張した場合のLCLMと各種垂直シーンモデルのパフォーマンス比較。これらの結果は、各タスクに含まれるすべてのデータセットの平均値です。出典:長文脈言語モデルは検索、RAG、SQLなどを包含できるか?[6]

2.2 RAG vs. ロングコンテキスト:環境レビュー文書理解のための最先端の大規模言語モデルの検討

「RAG対ロングコンテキスト」研究[7]では、ドメイン固有の知識を必要とする特定のタスクシナリオにおけるRAGとロングコンテキストLLMのパフォーマンスを評価しました。

本研究では、NEPAQuAD 1.0 ベンチマークを構築することにより、図 6 に示すように、米国連邦政府機関が国家環境政策法 (NEPA) に基づいて作成した環境影響報告書 (EIS) の質問に答える 3 つの高度な LLM (Claude Sonnet、Gemini、GPT-4) の能力を評価しました。

図6:比較に使用された環境影響報告書(EIS)の異なるコンテキストの例。ドメイン専門家によって選択されたゴールドの文章も含まれています。出典:RAG vs. Long Context[7]。

評価結果によると、どの最先端の LLM を選択したかに関係なく、回答の精度の点で RAG ベースのモデルが長いコンテキスト モデルを大幅に上回っています。

図7:異なるコンテキスト設定におけるEIS文書に対するLLMの回答の正確性評価結果。シルバーパッセージはRAGパイプラインによってフィルタリングされ、ゴールドパッセージは専門家によって選択された。出典:RAG vs. Long Context[7]。

図7に示すように、 RAGパイプラインによって選定されたシルバーパッセージをLLMに提供した場合、参考文献を一切提供しない場合や、問題の文脈を含む完全なPDF文書を提供する場合よりも、大幅に優れたパフォーマンスが得られます。そのパフォーマンスは、専門家が選定したゴールドパッセージを提供する場合とほぼ同等です。

図 8 は、さまざまな種類の問題に対する LLM のパフォーマンスを示しています。

図8:4つの異なる文脈的応用シナリオにおける様々な種類の質問に対する、異なる言語モデルの正確性スコアの比較。出典:RAG vs. Long Context[7]。

全体的に見て、RAG強化LLM(シルバーパッセージ)は、長いコンテキストのみを提供するモデルよりも回答精度において大幅に優れています。特に特定の垂直領域の問題を扱う場合、RAG強化LLM(シルバーパッセージ)は明確な優位性を示し、ゼロショット知識やPDF文書全体をコンテキストとしてのみ利用するモデルよりも優れた性能を発揮します。

さらに、コンテキスト付き LLM (シルバーパッセージとゴールドパッセージ) は、クローズドエンド型の質問に対する回答では最高の成績を収めましたが、発散型質問や問題解決型の質問に対する成績は比較的低かったです。

2.3 検索拡張生成か長文脈LLMか?包括的研究とハイブリッドアプローチ

この論文[8]では、RAGと長コンテキストLLMの包括的な比較を行い、両者の長所を発見して活用することを目指しています。

研究方法では、最先端の LLM 3 つを使用して、複数の公開データセットで RAG とロングコンテキスト LLM をベンチマークしました。

研究によると、十分なリソース条件下では、ロングコンテキストLLMは平均してRAGよりも一貫して優れたパフォーマンスを発揮することが分かっています。しかし、 RAGは大幅に安価であり、これは依然として明らかな利点です。

図9は、GPT-4o、GPT-3.5-Turbo、Gemini-1.5-Proという3つの最先端のLLMを使用して、ロングコンテキストLLM、RAG、および本論文で提案されたSELF-ROUTE方式の比較結果を示しています。

図9:長文脈LLM(LC)は長文脈の処理と理解においてRAGよりも優れているものの、費用対効果の面ではRAGが明らかに優位である。出典:検索拡張生成か長文脈LLMか?包括的な研究とハイブリッドアプローチ[8]

SELF-ROUTEは、RAGとロングコンテキストLLMを組み合わせたシンプルで効果的なアプローチであり、ロングコンテキストLLMと同等のパフォーマンスを維持しながらコストを削減することを目指しています。この手法では、LLMが既存のコンテキストがクエリに十分かどうかを予測できると仮定し、LLMの自己反射機能を活用してクエリをルーティングします。

この方法は 2 つのフェーズで構成されます。1つ目は RAG とルーティング フェーズ、2 つ目は長いコンテキストの予測ステップです。

最初のフェーズでは、LLMにクエリと取得したテキストブロックを提供し、クエリが回答可能かどうかを予測するよう指示します。回答可能であれば、LLMは回答を生成します。このプロセスは標準的なRAGパイプラインに似ていますが、重要な違いがあります。LLMには回答しないという選択肢があり、プロンプトに「既存のテキストに基づいてクエリに回答できない場合は、「回答できません」と記入してください」と表示されます。

回答可能と判断されたクエリについては、RAG予測を最終回答として直接使用します。回答不可能と判断されたクエリについては、第2段階に進み、完全なコンテキストをLong Context LLMに提供して最終予測を取得します。関連するプロンプトは図10に示されています。

図10:各データセットには対応するプロンプト語が付与されている。出典:検索拡張生成か長文脈LLMか?包括的な研究とハイブリッドアプローチ[8]

さらに、この論文にはいくつかの興味深い分析が含まれています。

まず、この論文では、top-k 法を使用して取得されたテキスト ブロック内の検索結果に k の値がどのように影響するかを検討します。

図11:kの増加に伴うモデル性能の変化と実際に使用されるトークンの割合を示す曲線(a)と(b)。出典:検索拡張生成か長文脈LLMか?包括的な研究とハイブリッドアプローチ[8]

図11は、kが増加するにつれてモデルのパフォーマンスと実際に使用されるトークンの割合がどのように変化するかを示す曲線(a)と(b)を示しています。

パフォーマンス面では、RAGとSELF-ROUTEにおいて、k値が大きいほどパフォーマンスが向上します。kが増加すると、LLMに入力されるテキストブロックの数が増え、パフォーマンスは徐々に向上し、長いコンテキストに近づきます。

曲線からわかるように、k の値が小さい場合、SELF-ROUTE はパフォーマンス上の利点が最も顕著になりますが、k が 50 を超えると、3 つの方法のパフォーマンスは同じになる傾向があります。

kの最適値はデータセットによって異なる場合があります。例えば、平均的にはk=5が曲線上で最も低いコストを示しますが、一部のデータセット、特にマルチホップ推論を必要としない抽出型質問データセット(NarrativeQAやQMSumなど)では、k=1が最も低いコストを示します。これは、kの最適値はタスクの性質とパフォーマンス要件によって異なることを示唆しています。

本論文では、RAG-and-Routeステップが「回答不可能」と予測される事例を手動で検証することで、RAGシステムの失敗理由を分析しています。図12のAからEに示すように、典型的な4つの失敗理由をまとめています。

図12:失敗事例分析のためのプロンプト。出典:検索拡張生成か長文脈LLMか?包括的な研究とハイブリッドアプローチ[8]

次に、Gemini-1.5-Proを使用してプロンプト語を処理し、回答できなかったすべての例を識別しました。

図13は、LongBenchの7つのデータセットにおける故障理由の分布を示しています。データセットごとにRAG故障事例の数は異なる場合があり、棒グラフの高さも異なります。

図13:RAG失敗理由の典型的な分布。出典:検索拡張生成か長コンテキストLLMか?包括的な研究とハイブリッドアプローチ[8]

さまざまなデータセットで各手法のパフォーマンスを観察しました。

  • Wikipedia に基づく 3 つのマルチホップ推論データセット (HotpotQA、2WikiMQA、MuSiQue) は、図の青で示されているように、複数ステップの検索を必要とするため、RAG にとって困難です。
  • 会話の多い長いストーリーを扱う NarrativeQA の場合、ほとんどの失敗は、図の緑色の部分に示すように、全体のコンテキスト内の暗黙的なクエリ (翻訳者注: これらはテキストでは直接表現されていないが、コンテキストに隠れている可能性があり、コンテキストの理解、推論、および推測を通じて判断する必要があるクエリ) を理解する必要があることに起因します。
  • QMSumは、自由回答形式の質問を含む要約データセットです。図の赤で示されているように、主な失敗原因は一般的な質問です。
  • 「その他」に分類される例は、ほとんどが複数ステップの質問であり、あいまいさのために回答が困難です。

2.4 ChatQA 2: ロングコンテキストとRAG機能における独自のLLMとのギャップを埋める

この研究では、Llama3をベースにしたChatQA 2という新しいモデルを提案し、長いコンテキストの理解とRAG機能に関して、オープンソースの大規模言語モデルとトップのクローズドソースの大規模言語モデル(GPT-4-Turboなど)との間のギャップを縮めることを目的としています。

さらに、この研究では、最先端のロングコンテキスト LLM を使用して、RAG とロングコンテキスト ソリューションの包括的な比較も実施しました。

図14に示すように、シーケンス長が32Kの下流タスクでは、ロングコンテキストソリューションがRAGよりもパフォーマンス面で優れています。RAGを使用するとコストを節約できますが、精度がわずかに低下する可能性があります。

図14: 最大入力32KトークンのベンチマークテストにおけるRAGとロングコンテキストの評価比較。出典: ChatQA 2[9]

図 15 に示すように、コンテキストの長さが 100K を超えると、RAG は長いコンテキスト ソリューションよりも優れたパフォーマンスを発揮します。

図15: 最大入力が10万トークンを超えるタスクにおけるRAGとロングコンテキストの評価。出典: ChatQA 2[9]

これは、最先端のロングコンテキストLLMでさえ、効果的な理解と推論に苦労する可能性があり、現実世界の128KタスクではRAG法よりもパフォーマンスが低い可能性があることを示しています。したがって、このような場合には、精度を向上させ、推論コストを削減するためにRAGの使用を検討できます。

03 私の考えと洞察

ここに私の考えと洞察の一部を示します。

3.1 ロングコンテキスト LLM によって RAG が廃止されることはありません。

研究論文からわかるように、長期コンテキスト LLM は多くの点で RAG を上回っていますが、専門知識とコストが求められるニッチな分野に関しては RAG が依然として明らかに優位に立っています。

RAGは持続する可能性があります。非常に長いLLMコンテキストウィンドウは便利ですが、リクエストごとに20万または100万トークンを処理するコストは非常に高く、最大20ドルに達する可能性があります[11]。

現在、RAG が Long Context LLM に置き換えられる可能性がある唯一のシナリオは、企業のアプリケーション シナリオが比較的単純であるが、RAG システムの構築にかかる人的コスト 💰 と時間コスト ⌛️ が非常に高い場合、RAG が Long Context LLM に置き換えられる可能性があるということです。

3.2 RAGとロングコンテキストLLMの組み合わせ

RAGとLong Context LLMは互いに補完し合うことができます。RAGは数百万、あるいは数十億のトークンからタスク関連のコンテキストを効率的に取得できますが、これはLong Context LLMでは不可能です。同時に、Long Context LLMは文書全体の要約に優れていますが、RAGはこの点において欠けている可能性があります。

どちらか一方を選択するのではなく、大規模な情報を効率的に取得して処理できる Long Context LLM と RAG を組み合わせて、強力なシステムを構築するのが最善です。

RAGとLong Context LLMを統合することで、現在のRAGパラダイムは大きく変わります。例えば、将来のアプリケーションでは、チャンク化処理は不要になるかもしれませんし、検索プロセス中にチャンクレベルの正確な想起も必要なくなるかもしれません。

3.3 より包括的かつ厳密な評価を期待しています。

前述の論文では、RAGとLong Context LLMを複数の方法で評価していますが、それぞれ異なるデータセット、評価方法、評価指標を用いています。この分野には、統一された評価データセットと評価指標が欠如しています。

さらに、LLMは推論プロセス中に関連するトークンを取得するためにKVキャッシュ[12]を使用するため、推論コストの削減に役立ちます。しかし、KVキャッシュとRAGのコスト比較はまだ報告されていません。

04 結論

この記事では、まず RAG と Long Context LLM を直感的に比較し、次に最新の研究論文に基づいてそれぞれの特徴を分析し、最後に個人的な考えや洞察を共有します。

まとめると、ロングコンテキストLLMは応用分野において高い柔軟性を提供しますが、すべての問題を解決できると期待するのは現実的ではありません。鍵となるのは、ロングコンテキストLLMとRAGソリューションの長所を組み合わせ、相乗効果を生み出す手法を模索し、実装することです。

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

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

フロリアン・ジューン

LLM、RAG、エージェント、ドキュメント AI に重点を置く AI 研究者。

最新の記事: florianjune.substack.com。


終わり

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

❓あなたの意見では、どの特定のアプリケーション シナリオが RAG テクノロジの使用に適していますか。また、どのシナリオがロング コンテキスト LLM に適していると思われますか。

🔗記事内のリンク🔗

[1] https://www.anthropic.com/news/claude-2

[2] https://ai.google.dev/gemini-api/docs/long-context

[3] https://arxiv.org/pdf/2402.13753

[4] https://huggingface.co/gradientai/Llama-3-8B-Instruct-Gradient-4194k

[5] https://medium.com/ai-in-plain-english/a-brief-introduction-to-retrieval-augmented-generation-rag-b7eb70982891

[6] https://arxiv.org/pdf/2406.13121

[7] https://arxiv.org/pdf/2407.07321

[8] https://arxiv.org/pdf/2407.16833

[9] https://arxiv.org/pdf/2407.14482

[10] https://arxiv.org/pdf/2201.11903

[11] https://www.anthropic.com/news/claude-3-family

[12] https://medium.com/@florian_algo/main-stages-of-auto-regressive-decoding-for-llm-inference-915d6e0a4418

オリジナルリンク:

https://ai.gopubby.com/will-long-context-llms-cause-the-extinction-of-rag-de41ca5ddfc6