【論文紹介】Lost in the Middle: How Language Models Use Long Contexts

 

原論文

tacl_a_00638.pdf (silverchair.com)

最新の言語モデルは長いコンテキストを入力として扱うことができますが、長いコンテキストをどれだけうまく活用しているかはまだよくわかっていません。この研究では、複数の文書からの質問応答やキーバリュー情報の取得など、入力コンテキスト内の関連情報を特定するタスクにおける言語モデルの性能を分析しました。その結果、関連情報の位置を変更すると性能が大幅に低下することがわかりました。これは、現在の言語モデルが長い入力コンテキスト内の情報を十分に活用できていないことを示唆しています。特に、関連情報がコンテキストの先頭または末尾にある場合に性能が最も高くなり、長いコンテキストであっても、モデルがコンテキストの中央にある関連情報にアクセスしなければならない場合に性能が著しく低下することが観察されました。この分析は、言語モデルが入力コンテキストをどのように活用しているのかをより深く理解するのに役立ち、将来的に開発される長いコンテキストを扱う言語モデルの評価方法の構築にも貢献します。

Introduction

言語モデルは、対話型インターフェース、検索や要約、共同執筆など、さまざまなユーザー向けの言語技術において重要で柔軟なビルディングブロックとなっています (Shuster et al., 2022; Thoppilan et al., 2022; Lee et al., 2022 など)。これらのモデルは、主に「プロンプティング」と呼ばれる手法で下位タスクを実行します。タスク仕様と処理すべきデータはすべてテキスト入力コンテキストとしてフォーマットされ、モデルは生成されたテキスト補完を返します。これらの入力コンテキストには、特に言語モデルが長い文書 (法律文書や科学論文、会話履歴など) を処理する場合や、外部情報 (検索エンジンの関連ドキュメント、データベースのクエリ結果など) で拡張されている場合 (Petroni et al., 2020; Ram et al., 2023; Shi et al., 2023; Mallen et al., 2023; Schick et al., 2023 など) には、数千トークンに達することがあります。このようなユースケースを扱うには、言語モデルが長いシーケンスに対してうまく動作することが必要です。

既存の言語モデルは一般的に、Transformer (Vaswani et al., 2017) を用いて実装されていますが、Transformer はメモリと計算量を必要とし、シーケンス長さに応じて2乗的に増加します。その結果、Transformer 言語モデルは、比較的小さなコンテキストウィンドウ (512 ～ 2048 トークン) で訓練されるのが一般的でした。しかし、最近ではハードウェア (より高速でメモリが多い GPU など) やアルゴリズム (Dai et al., 2019; Dao et al., 2022; Poli et al., 2023; Rubin and Berant, 2023 など) の改善により、より大きなコンテキストウィンドウ (4096、32K、さらには 100K トークン) を持つ言語モデルが登場しています。しかし、このような拡張コンテキスト言語モデルが、下位タスクを実行する際にどのように入力コンテキストを利用しているのかは依然として不明確です。

我々は、最新のオープンソース (MPT-30B-Instruct, LongChat-13B (16K)) やクローズド (OpenAI の GPT-3.5-Turbo と Anthropic の Claude-1.3) 言語モデルを用いた制御実験を通して、この疑問を実証的に検証します。特に、実験では入力コンテキストのサイズと、入力コンテキスト内における関連情報の位置を制御された変更を加え、それらが言語モデルのパフォーマンスに与える影響を調べます。もし言語モデルが長い入力コンテキスト内の情報を確実に利用できるならば、関連情報の位置によってパフォーマンスがほとんど影響を受けることはないはずです。

まずはマルチ文書質問応答で実験を行いました。このタスクでは、モデルは提供された文書を読み解いて関連情報を見つけ、その情報を使って与えられた質問に答えることが求められます。このタスクは、多くの商用生成検索や質問応答アプリケーション (例: Bing Chat) の基盤となっている検索拡張生成設定を模倣したものです。この設定では、(i) 入力コンテキストの長さ (検索拡張生成でより多くの文書を取得したり、より少ない文書を取得したりすることに相当) を入力コンテキスト内の文書数を変更することで制御し、(ii) 関連情報の位置を、関連文書を入力コンテキストの先頭、中間、末尾に配置するように文書の順序を変更することで制御します。

実験の結果、入力コンテキスト内における関連情報の位置を変更すると、モデルのパフォーマンスに大幅な影響を与える可能性があることがわかりました。これは、現在の言語モデルが長い入力コンテキスト内の情報を確実にアクセスして利用できていないことを示唆しています。さらに、図 1 に示すように、特徴的なU字型の性能カーブが観察されました。言語モデルのパフォーマンスは、関連情報が最初 (初出効果) または最後 (近接効果) にあるときに最も高く、モデルが情報にアクセスして、コンテキストの中央部分を利用しなければならない場合に著しく低下します (§2.3)。例えば、GPT-3.5-Turbo は、マルチ文書質問タスクにおいて、関連情報が入力コンテキストの中央に配置された場合のパフォーマンスが、文書が全くない場合 (つまり、閉鎖型の設定) の予測パフォーマンス (56.1%) よりも低くなりました。

さらに、拡張コンテキストを持つモデルは必ずしも入力コンテキストをよりうまく利用できるわけではないことも明らかになりました。拡張コンテキストを持つモデルとそうでないモデルのパフォーマンスが同一であることが多く見られたからです (§2.3)。言語モデルがマルチ文書質問応答タスクで関連情報を取得して利用することに苦労していることを考えると、言語モデルはそもそも入力コンテキストから情報を取得する能力がどの程度あるのでしょうか？ この疑問を調べるために、合成キーバリュー抽出タスクを用いました。このタスクは、入力コンテキストから一致するトークンを抽出する基本的な能力を最小限のテストベッドで調べるために設計されたものです。このタスクでは、モデルは JSON フォーマットのキーバリューペアのコレクションを与えられ、特定のキーに関連付けられている値を返す必要があります。

マルチ文書質問応答タスクと同様に、キーバリュー抽出タスクでも、入力コンテキストの長さ (キーバリューペアの追加) と関連情報の位置を制御することができます。一部のモデルは合成キーバリュー抽出タスクを完璧にこなす一方、他のモデルは単純に入力コンテキストの中央にある一致するトークンを抽出することに苦労し、U字型の性能カーブを示し続けることもありました。

長い入力コンテキスト内の情報を確実にアクセスして利用する際の言語モデルの課題をより深く理解するために、モデルアーキテクチャ (デコーダのみ vs. エンコーダ-デコーダ)、クエリ依存型状況依存化、および指示微調整 (§4) の役割を調べました。その結果、以下が明らかになりました。

• エンコーダ-デコーダモデルは、入力コンテキスト内における関連情報の位置の変化に対して比較的頑強ですが、訓練時のシーケンス長以内のシーケンスに対して評価された場合に限ります。訓練中に見たことのない長さのシーケンスに対して評価を行うと、U字型の性能カーブが観察されます (§4.1)。
• クエリ依存型状況依存化 (文書やキーバリューペアの前後にクエリを配置する) は、合成キーバリュータスクにおいてほぼ完璧なパフォーマンスを実現しますが、マルチ文書質問応答での傾向はわずかにしか変化しません (§4.2)。
• 基本的な言語モデル (つまり、指示微調整なし) であっても、入力コンテキスト内における関連情報の位置を変更すると、U字型の性能カーブを示します。

これらの結果は、長い入力コンテキストで言語モデルにプロンプトを与えることはトレードオフであることを示唆しています。つまり、言語モデルに多くの情報を提供することで下位タスクのパフォーマンスを向上させることができる一方で、モデルが推論しなければならないコンテンツ量も増加し、潜在的に精度が低下する可能性があるということです。

このトレードオフを実際の世界でより理解するために、オープン領域質問応答におけるレトリバー-リーダーモデルを用いたケーススタディを行いました (§5)。制御されたマルチ文書質問応答タスクとは異なり、このタスクでは、コンテキストは常に質問に答える正確に 1 つの文書を含んでいますが、オープン領域質問応答の設定では、上位 k 個の文書の中に答えが含まれている文書が全くないか、または複数存在する可能性があります。NaturalQuestions-Open からのクエリに答えるために Wikipedia から情報を取得する場合、モデルのパフォーマンスは、レトリバーのリコールが飽和するよりもはるかに前に飽和することがわかりました。これは、現在のモデルが追加で取得した文書を効果的に利用できていないことを示唆しており、50 個の文書を取得した場合と 20 個の文書を取得した場合のパフォーマンス向上はわずか (GPT-3.5-Turbo で約 1.5%、claude-1.3 で約 1%) です。

私たちの分析は、言語モデルが入力コンテキストをどのように利用するかをより深く理解するのに役立ち、将来的に開発される長いコンテキストを扱う言語モデルの評価方法を新たに提案します。言語モデルが長い入力コンテキスト内の情報を確実に利用できると主張するには、そのパフォーマンスが関連情報の位置の影響を最小限に受ける必要があることを示すことが必要です (例: 最高と最低のパフォーマンスの差が最小限であること)。言語モデルが入力コンテキストをどのように利用するかを理解し、改善するためのさらなる研究を促進するために、コードと評価データの公開を行います。

1 https://arxiv.org/abs/2307.03172

Conclusion

一連の制御実験を通して、言語モデルが長い入力コンテキストをどのように利用するかを検証しました。その結果、関連情報の位置を変更すると、言語モデルのパフォーマンスが著しく低下することが明らかになりました。これは、モデルが長い入力コンテキスト内の情報を確実にアクセスして利用することに難渋していることを示唆しています。特に、長い入力コンテキストの中央部分にある情報を使用しなければならない場合に、パフォーマンスが最も低くなる傾向がありました。

次に、(i) モデルアーキテクチャ、(ii) クエリ依存型状況依存化、(iii) 指示微調整が、言語モデルによるコンテキストの利用方法にどのように影響するかをより深く理解するために、予備的な調査を行いました。

最後に、オープン領域質問応答の実際的なケーススタディを行い、言語モデルによる回答生成の性能が、情報を取得する部分 (レトリバー) のリコールが飽和するよりもはるかに前に飽和することを確認しました。

今回の結果と分析は、言語モデルが入力コンテキストをどのように利用するかをより深く理解するのに役立ち、将来的に開発される長いコンテキストを扱う言語モデルの評価方法を新たに提案します。