本記事では、最新のLLMにおける長文コンテキスト処理能力の進化と、従来のRAG（情報検索＋生成）技術への影響について紹介します。近年、OpenAIのo1やClaude、Geminiなど、膨大なトークンを処理できるモデルが登場し、それに伴ってRAGワークフローの在り方が問い直されています。そこで今回、20種類のモデルを対象とした大規模な実験が行われました。長文コンテキストRAGの可能性と課題について見ていきましょう。

背景

LLMの長文コンテキスト処理能力は飛躍的に向上しており、例えばOpenAIのo1が12.8万トークン、AnthropicのClaudeが20万トークン、そしてGoogle Gemini 1.5 Proは200万ものトークンを処理することができるようになっています。

そのため従来のRAGワークフローが変わるのではないかという議論が生まれています。RAGとは、外部ソースから情報を取得することでLLMの精度を向上させる重要な技術です。特定のタスクに関連する情報や非公開データをLLMのワークフローに組み込む際には必須です。これまでの研究では、機械翻訳、意味解析、質問応答、そしてオープンエンドなテキスト生成など、多くの分野でRAGの有効性が実証されてきました。

なお、RAGと長文コンテキストの2者を単純に比較する研究も行われてきました。知識ベースから適宜情報を取り出して処理するのが良いのか、コーパス全体をLLMのコンテキストウィンドウに含めるのが良いのかということです。ただしどちらのアプローチが正確な結果をもたらすのか、またコスト効率が良いのかについては、まだ結論が出ていない状況です。

長文コンテキストモデルそのものの課題も指摘されています。これまでの研究では、長いテキストにおける中間部分の情報の保持・活用に苦労することや、コンテキスト長が増加するにつれて性能が低下することが示されています。”性能が低下しない範囲のコンテキストの長さ”は、プロバイダーが提供する最大のコンテキスト長よりも実ははるかに短いと言われています。

ここで、RAGと長文コンテキストLLMを組み合わせるのが良いのではないかという発想が生まれてきます。それを確かめるには、長文コンテキストモデルがRAGの性能をどのように向上させられるのか、また、その限界や課題は何かを調査する必要があります。

そこで今回研究者らは、長文処理能力を持つ代表的なモデル20種類を対象に実験を行いました。

なお、以前の記事でLongRAGという手法を紹介しましたが、本稿で紹介する研究は「シンプルなRAGを使って様々なLLMで比較実験」しているのに対し、以前紹介したLongRAGは独自のコンポーネントを新たに提案した新しいRAGアーキテクチャの「提案」が主題である点が大きな違いです。

RAGとコンテキストウィンドウの基礎

まずは、そもそもRAGとはなにか、コンテキストウィンドウ（文脈長）とはなにかといった部分から説明します。