スタンフォード大学：大きなモデルは間違った方向に「転がっている」のか？コンテキストウィンドウが長くなるほど、モデルは愚かになります。

言語モデルでは、コンテキストウィンドウは、特定のコンテキストに関連するテキストを理解して生成するために重要です。

一般的に、コンテキストウィンドウが大きいほど、より豊富な意味情報が提供され、曖昧さが排除されます。

最近のハードウェアとアルゴリズムの進歩により、大規模モデルのコンテキストウィンドウの長さもますます「大きく」なってきています。

最も人気のある企業は Anthropic で、同社は 5 月に Claude のコンテキストウィンドウを 9,000 トークンから 100,000 トークンに拡張しました。

最近更新された Claude 2 では、100K のコンテキスト機能がモデル内で「永続的」になります。

写真

大規模モデルの「バロメーター」として知られる ChatGPT も、3 月に GPT-4 モデルの最大コンテキストウィンドウを 32K に拡張し、6 月には GPT-3.5-Turbo のコンテキスト長を 16k (以前は 4k) 増加しました。

写真

「Lost in the Middle: 言語モデルで長いコンテキストを活用する方法」と題された論文の中で、スタンフォード大学、カリフォルニア大学バークレー校、サマヤの研究者らは、入力コンテキストから関連情報を識別する必要がある複数ドキュメントの質問応答とキー値検索では、入力コンテキストの長さが長くなるにつれて、大規模な言語モデルのパフォーマンスが大幅に低下すると提唱しました。

具体的には、著者らは、関連情報が入力コンテキストの最初または最後に表示される場合にパフォーマンスが一般的に最適になるが、モデルが長いコンテキストの途中で関連情報を取得する必要がある場合はパフォーマンスが大幅に低下することを示しています。

つまり、回答のテキストが記事の途中に配置されている場合、大規模な言語モデルでは回答を正確に認識して理解できない可能性があります。

したがって、大規模モデルのコンテキストウィンドウの長さが長くなっても、モデルの理解能力は向上しない可能性があります。

写真

著名なテクノロジーメディアウェブサイト「VentureBeat」もこの論文を報道し、専門家に相談した結果、ベクターデータベースが行き詰まりを打破する鍵となる可能性があると述べていることは特筆に値します。

Pinecone のようなベクターデータベースは、開発者がコンテキストウィンドウに取り込む関連情報を検索することで、LLM メモリを増やすのに役立ちます。

この発言は、上記の論文の主要著者であるネルソン・リュー氏も認めており、次のように述べています。「PDF 全体を言語モデルのコンテキストウィンドウに入れて、ドキュメントについて質問する場合、通常はベクターデータベース検索を使用する方が効果的です。」

同時に、ネルソン・リュー氏は、この論文は、ドキュメント全体を大規模モデルのコンテキストウィンドウに詰め込むとパフォーマンスが低下することを意味するものではないとも述べています。実際、結果はドキュメントの具体的な内容によって異なります。大規模なモデルでは、「密接に関連するコンテンツ」を区別するパフォーマンスは良くありません。大きなモデルは、パーツが関連していない（独立している）場合を「正確に特定」するのに非常に優れています。

編集者注：ベクトルデータベースの核心的なアイデアは、テキストをベクトルに変換し、ベクトルをデータベースに保存することです。ユーザーが質問を入力すると、質問はベクトルに変換され、次に最も類似したベクトルとコンテキストがデータベースで検索され、最終的にテキストがユーザーに返されます。

論文の詳細

この論文では、オープンソースモデルと非オープンソースモデルの両方をテストしました。前者には MPT-30B-Instruct、LongChat-13B (16K) が含まれ、後者には OpenAI の GPT-3.5-Turbo と Anthropic の Claude が含まれます。

まず、複数文書の質問応答に関する実験を行いました。このタスクの目標は、モデルにドキュメントについて推論させ、関連する情報を見つけて使用して、指定された質問に答えさせることです。

実験では、入力コンテキストのサイズと入力コンテキスト内の関連情報の位置が制御されました。

写真

上図に示すように、文書内の関連情報の位置を変更すると、モデルのパフォーマンスは独特の U 字型の傾向を示します。つまり、関連情報が入力コンテキストの先頭または末尾に現れる場合、パフォーマンスは通常最も高くなります。モデルが長いコンテキストの途中で関連情報を取得する必要がある場合、パフォーマンスは明らかに最低になります。

関連情報が入力コンテキストの途中に配置されている場合でも、GPT-3.5-Turbo は、ドキュメントが提供されていない場合よりも、複数ドキュメントの質問応答タスクでのパフォーマンスが低下します。

さらに、長いテキストの処理に特化していると主張する一部の大規模モデルは、この点ではパフォーマンスが良くありません。

では、言語モデルは入力コンテキストからどの程度の情報を取得できるのでしょうか?論文の著者らは、この問題を調査するために合成キー値検索タスクを指定しています。

このタスクでは、モデルは JSON 形式のキーと値のペアのセットを処理し、特定のキーに関連付けられた値を返す必要があります。複数ドキュメントの質問応答タスクと同様に、キー値取得タスクでも、操作中に入力コンテキストのサイズと入力コンテキスト内の関連情報の位置が制御された調整で調整されます。

結果は、依然として U 字型のパフォーマンス曲線であることを示しています。

マルチドキュメントQ&A

複数ドキュメントの質問応答タスクは、商用の検索および質問応答アプリケーション (Bing Chat など) で採用されている検索強化型生成パラダイムとほぼ同じです。

これらの実験では、モデルへの入力は回答すべき質問と k 個の文書 (たとえば、Wikipedia の段落) であり、そのうちの 1 つには質問に対する回答が含まれ、残りの k-1 個の「誤答」文書には回答が含まれません。

写真

上の図に示すように、複数ドキュメントの質問応答タスクを実行するには、モデルは入力のコンテキストで回答を含むドキュメントを取得し、それを使用して質問に回答する必要があります。

具体的なテストでは、著者は NaturalQuestions ベンチマークのデータを使用してこのタスクのインスタンスを作成しました。使用されるクエリは NaturalQuestions-Open からのものであり、段落 (つまり、100 トークン以下のテキストブロック) は入力コンテキスト内のドキュメントとして Wikipedia から抽出されます。

これらすべてのクエリについて、答えを含む 1 つのドキュメントと、答えを含まない k - 1 個のドキュメントを不正解として見つける必要があります。前者では、著者は NaturalQuestions 注釈の回答を含む Wikipedia の段落を使用しました。後者では、Contriever 検索システムを使用して、質問に最も関連しているが NaturalQuestions 注釈付きの回答を含まない k - 1 個の Wikipedia セグメントを検索しました。

最後に、予測された出力に正しい答えが表示されるかどうかを判断するための主な評価基準として精度が使用されます。

写真

予備的な準備が完了した後、著者は現在の「最も強力な」大型モデルをいくつかテストしました。上の図からわかるように、これらのモデルはすべて U 字型のパフォーマンスを示しています。

写真

上の図に示すように、入力コンテキストが増加すると、モデルのパフォーマンスは大幅に低下します。タスクに関係なく、コンテキストが拡大するにつれてモデルの機能が低下します。

キー値取得タスク

キー値取得タスクでは、大規模なモデルが入力コンテキストから直接情報を取得する能力をテストできます。キーと値の取得タスクでは、入力は k 個のキーと値のペアと特定のキーを含む JSON オブジェクトであり、目標はキーに関連付けられた値を返すことです。

写真

したがって、各 JSON オブジェクトには、関連付けられたキーと値のペア (取得する必要がある値) と、k-1 個の無関係な「ノイズ」キーと値のペアが含まれます。上の図は、キー値取得タスクの入力とそれに対応する予想される出力を示しています。

このタスクでは、ランダムなキーを追加または減算することで JSON キーと値のペアの数を変更し、入力の長さを変更することができます。また、入力内の関連する正しい情報の位置も調整されます。

写真

75、140、300のキーと値のペアを使ったテスト

上の図は、キーと値の取得のパフォーマンスを示しています。結果は、キーと値の取得タスクでは入力コンテキスト内での完全一致を見つけることだけが必要であるにもかかわらず、すべてのモデルがうまく機能するわけではないことを示しています。 Claude のモデルはさまざまな長さでほぼ完璧に動作しますが、他のモデルでは大量のキーと値のペアを取得するのが困難です。

キー値検索と複数ドキュメントの質問応答タスクでは、同様の U 字型の曲線が示されます。唯一の例外は、キー値取得タスクで優れたパフォーマンスを発揮するモデルです (claude)。 LongChat-13B は 140 個のキーと値の環境で非常に独特な動作をします。値を直接出力するのではなく、キーの値を抽出するコードを生成します。

なぜこの問題が発生するのでしょうか?

理由をより深く理解するために、著者らはモデルアーキテクチャ、コンテキストにおける回答の位置、および命令チューニングの役割に関する予備調査を実施しました。

写真

この論文では、モデルアーキテクチャレベルで、デコーダーのみのモデルとエンコーダー/デコーダーモデルを比較し、デコーダーのみの言語モデルと比較して、エンコーダー/デコーダー言語モデルはコンテキストウィンドウの点でより堅牢であると結論付けています。ただし、エンコーダー/デコーダーモデルは、トレーニング時に設定された最大長を超えるシーケンス長を処理する場合にも U 字型の曲線を示します。

さらに、コンテキスト内の回答の位置を変更すると、キー値検索タスクのパフォーマンスは完全に向上しますが、複数ドキュメントの質問応答タスクのパフォーマンス傾向にはほとんど影響がありません。

最後に、著者らは、基本言語モデルも命令チューニングなしで U 字型の曲線を示すことを発見しました。これは、命令チューニングプロセス自体がこのパフォーマンスパターンの原因ではない可能性があることを示唆しています。

つまり、言語モデルが中間情報を活用するのが難しい根本的な理由は、命令のチューニングにあるのではなく、モデル自体の構造とトレーニングプロセスについてより深い研究を行う必要があるということです。

結論

より多くのコンテキスト情報を提供することが必ずしも役立つとは限りません。言語モデルにコンテキスト情報をさらに提供すると、場合によってはパフォーマンスが向上することがありますが、ある時点を超えると、コンテキスト情報を追加してもパフォーマンスが大幅に向上しない可能性があります。

モデルは開始情報と終了情報を優先します。言語モデルは入力情報の先頭と末尾を処理する可能性が高くなるため、これらの場所に重要な情報を配置したり、ドキュメントの長さを短くしたりすると、パフォーマンスが向上する可能性があります。

このモデルでは、より長いコンテキストを活用することが困難です。コンテキストの長さを単純に増やすだけでは、言語モデルのパフォーマンスが効果的に向上しない可能性があります。長いコンテキストを処理するモデルの能力を真に向上させるには、モデルのアーキテクチャやトレーニング戦略の改善など、モデル自体の改善が必要になる場合があります。