2023年09月03日
大規模言語モデルが長いコンテキストをどのように使用するか
| Tweet |
|
言語モデルが長いコンテキストをどのように使用するか
自然言語処理をやってる人には、先頭（または終端）にバイアスがあると言う事は何年も前から分かってた事ですよね？ 多言語同時翻訳モデルの勉強
しかし研究の内容をよく見てみると
入力プロンプトの中間をまるで利用しないって事なので、むしろ大規模言語モデルの役に立たなさを裏付けていると思うんですが...
Lost in the Middle: How Language Models Use Long Contexts
Nelson F. Liu, John Hewitt, Percy Liang Stanford University
Kevin Lin University of California
Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni Samaya AI
arXiv preprint arXiv:2307.03172 (2023).
最近の言語モデルには長いコンテキストを入力として受け取る機能がありますが、言語モデルがどの程度適切にコンテキストを使用するかについてはほとんど知られていません。
入力コンテキストが長くなると、たとえ明示的に長いコンテキストモデルであっても、パフォーマンスが大幅に低下する事が分かりました。
特に長い入力 (法律文書や科学文書、会話履歴など) に対して言語モデルを使用する場合、または外部情報 (検索エンジンからの関連文書、データベースクエリ結果など) で言語モデルを拡張する場合には、入力コンテキストには数千のトークンが含まれる可能性があります。
これらのユースケースを処理するには、言語モデルが長いシーケンスに渡って正常に動作する必要があります。
言語モデルは通常、Transformer を使用して実装されますが、長いシーケンスにはあまり対応出来ません (たとえば、自己注意の複雑さが入力シーケンスの長さの 2次であるため)。
OpenAI の GPT-4 モデル (2023年3月) の最大コンテキストウィンドウは 32000 トークンです。
2023 年 5 月に、Claude のコンテキストウィンドウが 8K トークンから 100K トークンに拡張されました。
2023年 6 月、OpenAI は GPT-3.5-Turbo モデルの拡張コンテキストバージョンを発表し、コンテキストを 4K から 16K トークンに増やしました。
MPT-30B の最大コンテキスト長は 8K トークン
LongChat-7B の最大コンテキスト長は 16K トークンです。
これらの実験では、モデルの入力は (i) 質問の回答、および (ii) k文書 (例: Wikipedia の一節)
文書の1つに質問に対する答えが含まれており、k-1の不正解文書は関係ありません。
このタスクで入力コンテキストの長さを調整するには、回答を含まない文書の数を増減します。
スタンフォード大などの研究グループによると、大規模言語モデルに対して"重要な情報"はプロンプトの"最初や最後"に配置すると、モデルがより効果的に利用できる可能性があります。
— AIDB (@ai_database) July 7, 2023
論文：https://t.co/IZcIgEwXIJ… pic.twitter.com/1KqFEycH4K
自然言語処理をやってる人には、先頭（または終端）にバイアスがあると言う事は何年も前から分かってた事ですよね？ 多言語同時翻訳モデルの勉強
しかし研究の内容をよく見てみると
入力プロンプトの中間をまるで利用しないって事なので、むしろ大規模言語モデルの役に立たなさを裏付けていると思うんですが...
Lost in the Middle: How Language Models Use Long Contexts
Nelson F. Liu, John Hewitt, Percy Liang Stanford University
Kevin Lin University of California
Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni Samaya AI
arXiv preprint arXiv:2307.03172 (2023).
最近の言語モデルには長いコンテキストを入力として受け取る機能がありますが、言語モデルがどの程度適切にコンテキストを使用するかについてはほとんど知られていません。
入力コンテキストが長くなると、たとえ明示的に長いコンテキストモデルであっても、パフォーマンスが大幅に低下する事が分かりました。
特に長い入力 (法律文書や科学文書、会話履歴など) に対して言語モデルを使用する場合、または外部情報 (検索エンジンからの関連文書、データベースクエリ結果など) で言語モデルを拡張する場合には、入力コンテキストには数千のトークンが含まれる可能性があります。
これらのユースケースを処理するには、言語モデルが長いシーケンスに渡って正常に動作する必要があります。
言語モデルは通常、Transformer を使用して実装されますが、長いシーケンスにはあまり対応出来ません (たとえば、自己注意の複雑さが入力シーケンスの長さの 2次であるため)。
2 LANGUAGE MODELSハードウェアおよびアルゴリズム の進歩によって、言語モデルの最大コンテキスト長が急速に増加しました。
Increasing language model maximum context length.
OpenAI の GPT-4 モデル (2023年3月) の最大コンテキストウィンドウは 32000 トークンです。
2023 年 5 月に、Claude のコンテキストウィンドウが 8K トークンから 100K トークンに拡張されました。
2023年 6 月、OpenAI は GPT-3.5-Turbo モデルの拡張コンテキストバージョンを発表し、コンテキストを 4K から 16K トークンに増やしました。
MPT-30B の最大コンテキスト長は 8K トークン
LongChat-7B の最大コンテキスト長は 16K トークンです。
3 MULTI-DOCUMENT QUESTION ANSWERING実験の質問応答タスクは、商用検索および質問応答アプリケーションの基礎となる検索拡張生成セットアップとよく似ています。
3.1 EXPERIMENTAL SETUP
これらの実験では、モデルの入力は (i) 質問の回答、および (ii) k文書 (例: Wikipedia の一節)
文書の1つに質問に対する答えが含まれており、k-1の不正解文書は関係ありません。
このタスクで入力コンテキストの長さを調整するには、回答を含まない文書の数を増減します。
3.2 MODELS
オープン言語モデル (MPT-30B-Instruct（8192 トークン)、LongChat-13B(16K))
クローズド言語モデル (OpenAI の GPT-3.5-Turbo (16K) および Anthropic の claude-1.3 （8K）と claude-1.3-100k（100k）
を使用して実証的に調査します。
10、20、 30 個のドキュメント (それぞれ 2.7K のサンプル) を含む入力コンテキストを試します。
...
モデルのパフォーマンスには独特の U字型の曲線が見られます。
モデルは、コンテキストの最初と最後に発生する関連情報を識別して使用する事が優れています。入力コンテキストの途中の情報を使用する事を強制されると、パフォーマンスが低下します。
...と書かれているのですが、グラフを見る限り、最初の情報は最も精度が高いですが、最後の情報は、そんなに精度が良くならないと思うんですが...？
これらの結果は、現在のモデルが下流タスクを実行する時にコンテキストウィンドウ全体を効果的に推論する事が出来ない事、およびモデルが入力コンテキストの最初または最後にある情報を取得して使用する事が容易である事を示しています。
入力コンテキストがモデルとその拡張コンテキストの両方のコンテキストウィンドウに収まる設定では、それらのパフォーマンスはほぼ同じです。
これらの結果は、最大コンテキストが長いモデルが、拡張コンテキストの使用に必ずしも優れている訳ではない事を示しています。
4 HOW WELL CAN LANGUAGE MODELS RETRIEVE FROM INPUT CONTEXTS?入力は (i) 文字列でシリアル化された kキーと値のペアJSON オブジェクトです。
4.1 EXPERIMENTAL SETUP
各キーと値は一意でランダムに生成された UUID
目標は、指定されたキーに関連付けられた値を返す事です。
4.2 RESULTS AND DISCUSSION合成キーと値の取得タスクでは、入力コンテキスト内で完全に一致するものを識別するだけで済みますが、全てのモデルが高いパフォーマンスを達成出来る訳ではありません。
claude-1.3 と claude-1.3-100k は、評価された全ての入力コンテキスト長でほぼ完璧に機能しますが、他のモデルは特に困難を伴います。
5 WHY DO LANGUAGE MODELS STRUGGLE TO USE THEIR ENTIRE INPUT CONTEXT?言語モデルがコンテキストを使用する方法に対するモデル アーキテクチャの潜在的な影響をより深く理解するために、デコーダーのみの言語モデルとエンコーダー - デコーダー言語モデルを比較します。
我々は、Flan-T5-XXL および Flan-UL2 を使って実験します。
Flan-T5-XXL は、512 個のトークン (エンコーダーとデコーダー) のシーケンスを使用してトレーニングされます。
Flan-UL2 は最初に 512 個のトークン (エンコーダーとデコーダー) のシーケンスでトレーニングされますが、その後、デコーダ内のトークンは 512 個、エンコーダー内の2048 個のトークンを含むシーケンスで命令チューニングを行う前に、1024 個のトークン (エンコーダーとデコーダー) で追加の 100K ステップの事前トレーニングが行われます。
ただし、これらのモデルは相対位置埋め込みを使用するため、(原則として) これらの最大コンテキスト長を超えて推定する事が出来ます。
Flan-UL2 が 2048 トレーニング時間コンテキスト ウィンドウ内のシーケンスで評価されると、そのパフォーマンスは、入力コンテキスト内の関連情報の位置の変化に対して比較的堅牢です。
2048 トークンより長いシーケンスを含む設定で評価すると、関連情報が中間に配置されると Flan-UL2 のパフォーマンスが低下し始めます。
Flan-T5-XXL も同様の傾向を示しており、入力コンテキストが長くなると、関連情報を入力コンテキストの中央に配置するとパフォーマンスが大幅に低下します。
エンコーダ/デコーダ モデルでは、双方向エンコーダにより将来のドキュメントのコンテキストで各ドキュメントを処理出来るため、ドキュメント間の相対重要度の推定が強化される可能性があるため、コンテキストウィンドウをより有効に利用出来るのではないかと推測しています。
5.2 EFFECT OF QUERY-AWARE CONTEXTUALIZATIONここまでの実験では、処理するデータ (ドキュメントまたはキーと値のペア) の後にクエリ (つまり、回答する質問または取得するキー) を配置しました。
クエリはプロンプトの最後にのみ表示され、デコーダ専用モデルは各タイムステップで前のトークンにしか対応出来ないため、ドキュメントまたはキーと値のペアのコンテキストを設定する時に、デコーダ専用モデルはクエリトークンに対応出来ません。
一方、エンコーダ/デコーダ モデルは、双方向エンコーダを使用して入力コンテキストをコンテキスト化するため、入力コンテキスト内の関連情報の位置の変更に対してより堅牢であるようです。
この直感を利用して、データの前後にクエリを配置する事でデコーダのみのモデルのパフォーマンスも向上させる事が出来ます。
クエリを意識したコンテキスト化により、キーと値の取得タスクのパフォーマンスが大幅に向上します。
GPT-3.5-Turbo (16K) では、300 個のキーと値のペアで評価すると完璧なパフォーマンスを達成します。対照的に、クエリを意識したコンテキスト化を使用しない場合、同じ設定では 45.6% という最低のパフォーマンスに達します。
.................
これらの観察は、言語モデルが最近のトークン (入力コンテキストの終わり ) に偏っている事を発見した以前の研究を補完します。
この最新性バイアスは一般に、言語モデルが長距離情報からほとんど恩恵を受けない、連続したテキストの次の単語の予測のコンテキストで示されます。
.................
.................
7.3 THE SERIAL-POSITION EFFECTこの研究で観察される U字型の曲線には、系列位置効果として知られる心理学との関連性があります。
リストからの要素の自由連想想起において、人間はリストの最初と最後の要素を最もよく記憶する傾向があります。
Transformer LLM の基礎となるセルフアテンションメカニズムは技術的に同等にコンテキストからトークンを取得出来るため、LLM で系列位置効果のような効果が観察される事はおそらく驚くべき事です。
