LLMのロングコンテキストRAGパフォーマンス

Retrieval Augmented Generation (RAG) は、お客様の間で最も広く採用されている生成 AI のユースケースです。RAG は、構造化されていないドキュメントや構造化データなどの外部ソースから情報を取得することで、LLM の精度を高めます。Anthropic Claude (200k コンテキスト長)、GPT-4-turbo (128k コンテキスト長)、Google Gemini 1.5 pro (200 万コンテキスト長) のような長いコンテキスト長を持つ LLM が利用可能になったことで、LLM アプリケーション開発者は、より多くのドキュメントを RAG アプリケーションにフィードできるようになりました。コンテキスト長を極端に長くすることについて、長いコンテキスト言語モデルが最終的に RAG ワークフローを包含するかどうかという議論さえあります。コーパス全体をコンテキストウィンドウに挿入できるのに、なぜデータベースから個々のドキュメントを取得する必要があるのでしょうか？

 

このブログ記事では、コンテキスト長の増加が RAG アプリケーションの品質に与える影響を調査します。13 の人気のあるオープンソースおよび商用 LLM に対して 2,000 を超える実験を実行し、さまざまなドメイン固有のデータセットでのパフォーマンスを明らかにしました。次のことがわかりました。

• より多くのドキュメントを取得することは、確かに有益です。特定のクエリに対してより多くの情報を取得すると、正しい情報が LLM に渡される可能性が高まります。長いコンテキスト長を持つ最新の LLM はこれを活用でき、それによって RAG システム全体を改善できます。
• RAG にとって、長いコンテキストが常に最適とは限りません。ほとんどのモデルのパフォーマンスは、特定のコンテキストサイズを超えると低下します。特に、Llama-3.1-405b のパフォーマンスは 32k トークン以降で低下し始め、GPT-4-0125-preview は 64k トークン以降で低下し始めます。また、一部のモデルしか、すべてのデータセットで一貫した長いコンテキスト RAG パフォーマンスを維持できません。
• モデルは、非常に異なる方法で長いコンテキストで失敗します。Llama-3.1-405b、GPT-4、Claude-3-sonnet、DBRX、Mixtral の長いコンテキストパフォーマンスを詳細に調査し、著作権上の懸念による拒否や、常にコンテキストを要約するといった、独自の失敗パターンを特定しました。これらの多くの動作は、十分な長いコンテキストのポストトレーニングの欠如を示唆しています。

背景

RAG: 通常の RAG ワークフローには、少なくとも 2 つのステップが含まれます。

• 取得 (Retrieval): ユーザーの質問に基づいて、コーパスまたはデータベースから関連情報を取得します。情報取得は、システム設計の豊富な分野です。しかし、シンプルで現代的なアプローチは、個々のドキュメントを埋め込んでベクトルのコレクションを生成し、それをベクトルデータベースに格納することです。次に、システムはユーザーの質問とドキュメントの類似性に基づいて関連ドキュメントを取得します。取得における重要な設計パラメータは、取得するドキュメントの数、したがって取得するトークンの総数です。
• 生成 (Generation): ユーザーの質問と取得された情報に基づいて、対応する応答を生成します (または、回答を生成するのに十分な情報がない場合は拒否します)。生成ステップでは、幅広い技術を採用できます。しかし、シンプルで現代的なアプローチは、取得された情報と質問に回答するための関連コンテキストを導入するシンプルなプロンプトを通じて LLM にプロンプトすることです。

RAG は、多くのドメインやタスクで QA システムの品質を向上させることが示されています (Lewis et.al 2020)。

長いコンテキスト言語モデル: 最新の LLM は、ますます大きなコンテキスト長をサポートしています。

元の GPT-3.5 は 4k トークンのコンテキスト長しかありませんでしたが、GPT-4-turbo と GPT-4o は 128k のコンテキスト長を持っています。同様に、Claude 2 は 200k トークンのコンテキスト長を持ち、Gemini 1.5 pro は200 万トークンのコンテキスト長を誇ります。オープンソース LLM の最大コンテキスト長も同様の傾向をたどっています。Llama モデルの最初の世代は 2k トークンのコンテキスト長しかなかったのに対し、Mixtral や DBRX のようなより最近のモデルは 32k トークンのコンテキスト長を持っています。最近リリースされた Llama 3.1 は最大 128k トークンです。

RAG に長いコンテキストを使用する利点は、システムが取得ステップを拡張して、生成モデルのコンテキストにより多くの取得ドキュメントを含めることができることです。これにより、質問に回答するためにドキュメントがモデルで利用可能になる確率が高まります。

一方、長いコンテキストモデルの最近の評価では、2 つの一般的な制限が明らかになっています。

• 「中間での喪失」問題: 「中間での喪失」問題は、モデルが長いテキストの中間部分からの情報を保持し、効果的に利用するのに苦労する場合に発生します。この問題は、コンテキスト長が増加するにつれてパフォーマンスが低下する可能性があり、モデルは広範なコンテキストに分散した情報を統合する能力が低下します。
• Effective context length: the RULER paper explored the performance of long context models on several categories of tasks including retrieval, variable tracking, aggregation and question answering, and found that the effective context length - the amount of usable context length beyond which model performance begins to decrease –  can be much shorter than the claimed maximum context length. 

With these research observations in mind, we designed multiple experiments to probe the potential value of long context models, the effective context length of long context models in RAG workflows, and assess when and how long context models can fail.

Methodology

To examine the effect of long contexton retrieval and generation, both individually and on the entire RAG pipeline, we explored the following research questions: 

1. The effect of long context on retrieval: How does the quantity of documents retrieved affect the probability that the system retrieves a relevant document?
2. The effect of long context on RAG: How does generation performance change as a function of more retrieved documents?
3. The failure modes for long context on RAG: How do different models fail at long context?

We used the following retrieval settings for experiments 1 and 2:

• embedding model: (OpenAI) text-embedding-3-large
• chunk size: 512 tokens (we split the documents from the corpus into chunk size of 512 tokens)
• stride size: 256 tokens (the overlap between adjacent chunks is 256 tokens)
• vector store: FAISS (with IndexFlatL2 index)

We used the following LLM generation settings for experiment 2:

• generation models: gpt-4o, claude-3-5-sonnet, claude-3-opus, claude-3-haiku, gpt-4o-mini, gpt-4-turbo, claude-3-sonnet, gpt-4, meta-llama-3.1-405b, meta-llama-3-70b, mixtral-8x7b, dbrx, gpt-3.5-turbo
• temperature: 0.0
• max_output_tokens: 1024

When benchmarking the performance at context length X, we used the following method to calculate how many tokens to use for the prompt: 

• Given the context length X, we first subtracted 1k tokens  which is used for the model output
• We then left a buffer size of 512 tokens

The rest is the cap for how long the prompt can be (this is the reason why we used a context length 125k instead of 128k, since we wanted to leave enough buffer to avoid hitting out-of-context errors).

Evaluation datasets

In this study, we benchmarked all LLMs on 4 curated RAG datasets that were formatted for both retrieval and generation. These included Databricks DocsQA and FinanceBench, which represent industry use cases and Natural Questions (NQ) and HotPotQA, which represent more academic settings . Below are the dataset details:

評価指標: 

• 検索指標: 検索のパフォーマンスを測定するためにリコールを使用しました。リコールスコアは、取得された関連ドキュメントの数に対する、データセット内の関連ドキュメントの総数の比率として定義されます。
• 生成指標: 生成のパフォーマンスを測定するために回答の正確性指標を使用しました。回答の正確性は、GPT-4oを搭載した、調整済みのLLMとしてのジャッジシステムを通じて実装しました。私たちの調整結果は、ジャッジと人間の合意率が人間同士の合意率と同等であることを示しました。

RAGで長文コンテキストを使用する理由

実験1：より多くのドキュメントを検索することの利点

この実験では、より多くの結果を検索することが、生成モデルのコンテキストに配置される関連情報の量にどのように影響するかを評価しました。具体的には、リトリーバーがX個のトークンを返すことを想定し、そのカットオフでのリコールスコアを計算しました。別の観点から見ると、リコールパフォーマンスは、モデルが回答生成に検索されたドキュメントのみを使用する必要がある場合の、生成モデルのパフォーマンスの上限です。

以下は、4つのデータセットと異なるコンテキスト長におけるOpenAI text-embedding-3-large埋め込みモデルのリコール結果です。チャンクサイズは512トークンを使用し、プロンプトと生成のために1.5kのバッファを残します。

 

Saturation point: テーブルからわかるように、各データセットの検索リコールスコアは、コンテキストの長さによって飽和する点が異なります。NQデータセットでは8kのコンテキスト長で早期に飽和しますが、DocsQA、HotpotQA、FinanceBenchデータセットではそれぞれ96kおよび128kのコンテキスト長で飽和します。これらの結果は、単純な検索アプローチでも、生成モデルが利用できる追加の関連情報が96kまたは128kトークンまで存在することを示しています。 したがって、最新モデルのコンテキストサイズの増加は、これらの追加情報を捉えてシステム全体の品質を向上させる可能性を秘めています。

長いコンテキストを使用しても、RAGのパフォーマンスが一様に向上するわけではありません

実験2：RAGにおける長いコンテキスト

In this experiment, we put together the retrieval step and generation step as a simple RAG pipeline. To measure the RAG performance at a certain context length, we increase the number of chunks returned by the retriever to fill up the generation model’s context up to  a given context length. We then prompt the model to answer the questions of a given benchmark.  Below are the results of these models at different context lengths.

The Natural Questions dataset is a general question-answering dataset that’s publicly available. We speculate that most language models have been trained or fine-tuned on tasks similar to Natural Question and therefore we observe relatively  small score differences among different models at short context length. As the context length grows, some models start to have decreased performance.

As compared to Natural Questions, the Databricks DocsQA dataset is not publicly available (although the dataset was curated from publicly available documents). The tasks are more use case specific, and focus on enterprise question-answering based on Databricks documentation. We speculate that because models are less likely to have been trained on similar tasks, that the RAG performance among different models varies more than that of Natural Questions . Additionally, because the average document length for the dataset is 3k, which is much shorter than that of FinanceBench, the performance saturation happens earlier than that of FinanceBench.

The FinanceBench dataset is another use case specific benchmark that consists of  longer documents, namely SEC 10k filings.  In order to correctly answer the questions in the benchmark, the model needs a larger context length to capture relevant information from the corpus. This is likely the reason that, compared to other benchmarks, the recall for FinanceBench is low for small context sizes (Table 1). As a result, most models’ performance saturates at a longer context length than that of other datasets.

By averaging these RAG task results together, we derived the long context RAG performance table (found in the appendix section) and we also plotted the data as a line chart in Figure 1. 

Figure 1 at the beginning of the blog shows the performance average across 4 datasets. We report the average scores in Table 2 in the Appendix.

As can be noticed from Figure 1:

• Increasing context size enables models to take advantage of additional retrieved documents: We can observe an increase of performance across all models from 2k to 4k context length, and the increase persists for many models up to 16~32k context length.
• However, for most models, there is a saturation point after which performance decreases,  for example: 16k for gpt-4-turbo and claude-3-sonnet, 4k for mixtral-instruct and 8k for dbrx-instruct.
• Nonetheless, recent models, such as gpt-4o, claude-3.5-sonnet and gpt-4o-mini, have improved long context behavior that shows little to no performance deterioration as context length increases. 

Together, a developer must be mindful in the selection of the number of documents to be included in the context. It is likely that the optimal choice depends on both the generation model and the task at hand.

LLMs Fail at Long Context RAG in Different Ways

Experiment 3: Failure analysis for long context LLMs

To assess the failure modes of generation models at longer context length, we analyzed samples from llama-3.1-405b-instruct, claude-3-sonnet, gpt-4, Mixtral-instruct and DBRX-instruct, which covers both a selection of  SOTA open source and commercial models.

Due to time constraints, we chose the NQ dataset for analysis since the performance decrease on NQ in Figure 3.1 is especially noticeable.

We extracted the answers for each model at different context lengths, manually inspected several  samples, and – based on those observations – defined the following broad failure categories:

• repeated_content: when the LLM answer is completely (nonsensical) repeated words or characters.
• random_content: when the model produces an answer that  is completely random, irrelevant to the content, or doesn't make logical or grammatical sense.
• fail_to_follow_instruction: when the model doesn't understand the intent of the instruction or  fails to follow the instruction specified in the question. For example, when the instruction is about answering a question based on the given context while the model is trying to summarize the context.
• wrong_answer: when the model attempts  to follow the instruction but the provided answer is wrong.
• others: the failure doesn't fall under any of the categories listed above

We developed prompts that describe each category and used GPT-4o to classify all of  the failures of the models under consideration into the above categories.  We also note that the failure patterns on this dataset may not be representative of other datasets; it’s also possible for the pattern to change with different generation settings and prompt templates. 

Commercial model long context failure analysis

The two bar charts below show the failure attribution for the two commercial language models gpt-4 and claude-3-sonnet.

GPT-4の失敗：GPT-4は、間違った回答を返す（例：「マレフィセントの最後に歌ったのは誰？」という質問に対し、正解は「Lana Del Rey」なのに生成された回答は「Ariana Grande & John Legend」）。さらに、GPT-4は時折、無関係またはランダムな回答を返すこともあります。例えば、「2000年にメキシコで大統領に選出されたのは誰？」と尋ねたところ、GPT-4の回答は「名目上15番目に大きく、購買力平価では11番目に大きい」でした。

(GPT-4が間違った回答を返す場合のサンプル)

(GPT-4がランダムな内容で回答する際のサンプル)

Claude-3-sonnetの失敗：一方、Claudeは指示に従わないことが多く、失敗の大部分は著作権上の懸念から回答を拒否することが原因であることがわかりました。以下はClaude-3-sonnetの失敗モードの例です。

(Claude-3-sonnetが指示に従わない場合のサンプル)

OSSモデルの長文コンテキストにおける失敗分析

以下の3つの棒グラフは、3つのOSSモデル（Llama-3.1-405b-instruct、Mixtral-8x7b-instruct、DBRX-instruct）の失敗の内訳を示しています。

Llama-3.1-405b-instructの失敗パターンは一貫しており、モデルは主に間違った回答を返すことで失敗します。モデルが繰り返しやランダムなコンテンツを生成することはめったにありません。また、指示追従性能も非常に良好で、全体的な失敗率と内訳はGPT-4と同様です。

(llama-3.1-405b-instruct のサンプルでは、間違った回答が提供されています)

 

一方、Mixtral-instruct と DBRX-instruct は異なるパターンで失敗します。Mixtral-instruct は、中国語で「夢」を意味する 「梦梦梦梦梦梦」（つまり「dream」）のような繰り返しコンテンツや、質問とは無関係なランダムなコンテンツを常に生成します。対照的に、DBRX-instruct は、質問に答える代わりに常に コンテンツを要約することで指示に従うのに失敗します。DBRX の棒グラフも、繰り返しまたはランダムなコンテンツで回答する可能性が高いことを示しています。詳しく見ると、これらのランダムまたは繰り返しコンテンツは、繰り返し文を使いながらも、依然としてコンテキストを要約しようとしています。以下は、Mixtral-instruct と DBRX-instruct のサンプルです。

(Mixtral-instruct が繰り返しコンテンツで回答するサンプル)

 

(Mixtral-instruct がランダムなコンテンツで回答するサンプル)

 

(DBRX-instruct が指示に従わないサンプルの例)

 

(DBRX-instruct が「ランダム/繰り返しコンテンツ」で回答するサンプルの例。これは指示に従っておらず、コンテキストの要約を開始しています。)

トレーニング後の長コンテキストの欠点: claude-3-sonnet と DBRX-instruct のパターンは特に興味深いことがわかりました。これらの特定の失敗は、特定のコンテキスト長の後で特に顕著になります。Claude-3-sonnet の著作権に関する失敗は、16k で 3.7% から 32k で 21%、64k のコンテキスト長で 49.5% に増加します。DBRX が指示に従わない失敗は、8k のコンテキスト長で 5.2% から 16k で 17.6%、32k で 50.4% に増加します。このような失敗は、より長いコンテキスト長での指示追従トレーニングデータの不足によって引き起こされると推測されます。同様の観察は、LongAlign の論文 (Bai et.al 2024) でも見られます。そこでは、より多くの長コンテキストの指示データが長タスクのパフォーマンスを向上させ、長指示データの多様性がモデルの指示追従能力に有益であることが実験で示されています。

これらの失敗パターンを組み合わせることで、長コンテキストサイズでの一般的な失敗を特定するための追加の診断セットが提供されます。これは、たとえば、モデルや設定に応じて RAG アプリケーションでコンテキストサイズを削減する必要性を示す可能性があります。さらに、これらの診断が、長コンテキストのパフォーマンスを向上させる将来の研究方法の種となることを願っています。

結論

LLM 研究コミュニティでは、長コンテキスト言語モデルと RAG の関係について激しい議論が交わされています (たとえば、長コンテキスト言語モデルは検索、RAG、SQLなどを包含できるか？ (Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?)、長コンテキスト LLM と RAG システムの概要, Cohere: RAG は定着: 大規模コンテキストウィンドウがそれを置き換えられない 4 つの理由, LlamaIndex: 長コンテキスト RAG に向けて, Vellum: RAG vs 長コンテキスト? を参照)。 上記の結果は、長コンテキストモデルと RAG が相乗効果を発揮することを示しています。長コンテキストにより、RAG システムはより関連性の高いドキュメントを効果的に含めることができます。しかし、多くの長コンテキストモデルの機能にはまだ限界があります。指示に従わない、または繰り返し出力するなど、多くのモデルで長コンテキストでのパフォーマンスが低下します。したがって、長コンテキストが RAG を置き換えることができるという魅力的な主張は、利用可能なモデル全体で長コンテキストの品質に対するより深い投資を必要とします。

さらに、このスペクトラムをナビゲートする開発者は、生成モデルと検索設定が最終結果の品質にどのように影響するかを把握するために、優れた評価ツールを利用する必要があります。このニーズに応えるため、開発者がこれらの複雑なシステムを評価するのに役立つ研究活動 (Mosaic Evaluation Gauntlet の調整) と製品 (Mosaic AI Agent Framework と Agent Evaluation) を提供してきました。

制限事項と今後の作業

シンプルな RAG 設定

RAG 関連の実験では、チャンクサイズ 512、ストライドサイズ 256、埋め込みモデル OpenAI text-embedding-03-large を使用しました。回答を生成する際には、シンプルなプロンプトテンプレート (詳細は付録参照) を使用し、取得したチャンクを区切り文字で連結しました。これは、最も単純な RAG 設定を表すことを目的としています。リランカーを含める、複数のリトリーバー間でハイブリッド結果を取得する、あるいはエンティティ/コンセプトのセットを事前生成するために LLM を使用して検索コーパスを前処理するなど、より複雑な RAG パイプラインを設定することも可能です。これは GraphRAG の論文 に似ています。これらの複雑な設定は、このブログの範囲外ですが、将来の検討に値する可能性があります。

データセット

データセットは幅広いユースケースを代表するように選択しましたが、特定のユースケースでは特性が大きく異なる可能性があります。さらに、データセットには独自の癖や制限がある可能性があります。たとえば、Databricks DocsQA は、すべての質問で 1 つのドキュメントのみを正解として使用すると想定していますが、他のデータセットではそうではない場合があります。

リトリーバー

4 つのデータセットの飽和点は、現在の検索設定では 64k、さらには 128k を超えるコンテキストを取得してもリコールスコアを飽和させることができないことを示しています。これらの結果は、ソースドキュメントを検索されたドキュメントの先頭にプッシュすることで、検索パフォーマンスを向上させる可能性があることを意味します。

付録

長コンテキスト RAG パフォーマンス表

これらの RAG タスクを組み合わせることで、上記の 4 つのデータセットにおけるモデルの平均パフォーマンスを示す次の表が得られます。この表は、図 1 と同じデータです。

 

プロンプトテンプレート

実験2では、以下のプロンプトテンプレートを使用します。

Databricks DocsQA:

 

FinanceBench:

 

 

 

{context}

 

質問:

 

{question}

 

あなたの回答:

 

 

NQとHotpotQA:

 

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事