Lost in the Middle：LLMにおける位置バイアスと金融AIへの影響
DocFinQAのエントリを振り返ると、リトリーバルベースのパイプラインとロングコンテキストLLMの両方が、123Kトークンのコンテキストを持つSEC提出書類で崩壊した際、私は「なぜか」という問いを残しました。Liuらによるこの論文（TACL 2024, arXiv:2307.03172）は、そのメカニズム的な回答であり、失敗のモードは私が予想していたよりも単純で頑固なものであることが判明しました。
論文の概要
Nelson F. Liuらによる「Lost in the Middle: How Language Models Use Long Contexts（迷子の中央：言語モデルは長いコンテキストをどのように利用するか）」では、2つの焦点を絞った実験が行われました。1つはNaturalQuestions-Openを用いたマルチドキュメント質問応答（取得ドキュメント数10、20、30）、もう1つは合成キー・バ リュー・リトリーバル（ペア数75、140、300）です。各実験では、入力コンテキスト内の関連ドキュメントやキー・バリュー・ペアの位置（最初、中間、最後）を系統的に変化させ、他の条件はすべて固定しました。その結果は明白でした。パフォーマンスはコンテキストの中央を底とするU字型の曲線を描き、この曲線はテストされたすべてのモデルで現れました。
主なアイデア
- U字型は実在し、一貫している。 20ドキュメントのQA設定では、最初の位置でのパフォーマンスは約75%でしたが、10番目の位置では約55%まで低下し、20番目の位置で約72%まで回復しました。端と中央の間には約20ポイントの差があります。
- すべてのモデルが同じパターンに従う。 テストされたモデルは、クローズドソースからオープンソース、小規模から大規模まで多岐にわたります：GPT-3.5-Turbo (4Kおよび16K)、GPT-4、Claude-1.3 (8Kおよび100K)、MPT-30B-Instruct、LongChat-13B。U字曲線は、拡張コンテキストウィンドウを明示的に謳っているモデルを含め、すべてのモデルで確認されました。
- Claude-1.3-100Kでさえ免れない。 100Kコンテキスト版も他と同様の挙動を示しました。長いコンテキストウィンドウがあるからといって、モデルがその全域にわたって均一に注意を払っているわけではありません。
- クローズドブック・ベースラインが突きつける厳しい現実。 ド キュメントなしのGPT-3.5-TurboはNaturalQuestionsの56.1%に正解しました。関連する1つのドキュメントのみにアクセスできるオラクル状態では88.3%に達しました。しかし、20ドキュメント設定の最悪の中間位置では、パフォーマンスはクローズドブック・ベースラインを下回りました。つまり、コンテキストを追加することがかえって有害となったのです。
- エンコーダ・デコーダモデル（Flan-T5-XXL, Flan-UL2）は、訓練された長さの範囲内ではより堅牢だが、コンテキストがそれを超えると劣化する。 アーキテクチャの違いは重要ですが、スケールアップするとどちらも依然として劣化します。
- 根本的な原因は因果的アテンション・マスキング（Causal Attention Masking）にある。 各トークンは先行するトークンにしか注意を向けられないため、最初の位置は中央の位置よりもモデル全体で累積的なアテンションの重みをより多く獲得します。また、近接効果（Recency effects）により、コンテキストの最後の方も引き上げられます。
妥当な点とそうでない点
この実験設計は見事なほどクリーンです。位置だけが操作された変数であり、タスクは標準的なベンチマークであり、結果は幅広いモデルファミリーで再現されています。中心的な結果に異論はありません。
一方で、キー・バリュー・リトリーバルタスクを実務の有効な代用（プロキ シ）として位置づけている点には、あまり納得がいきません。UUIDからUUIDへのルックアップは、モデルが記憶された文字列をそのまま返せるかどうかをテストするものであり、推論を必要とする能力をテストするものではありません。U字曲線がそこでも現れることは位置バイアスの主張を強めますが、同時にこの論文が「完全一致タスクにおけるリトリーバル精度」と「関連パッセージにわたる推論の質」という2つの異なる現象を混同していることも意味します。私が知りたいのは、最終的な回答の前にマルチステップの推論が必要な場合、U字型の劣化が悪化するのか、それとも改善するのかという点です。
また、著者が概ね認めていながら解決していないギャップもあります。彼らはインストラクション・ファインチューニングやRLHFが位置感度を変化させるかどうかをテストしておらず、コンテキストウィンドウの大きさが影響するかどうかのみをテストしています。根本原因がアーキテクチャ（因果的マスキング）にあることを考えると、インストラクション・チューニングでは解決しないのではないかと推測しますが、論文では確認されていません。
なぜこれが金融AIにとって重要なのか
この論文は、私が頻繁に直面する経験的なパターンにメカニズム的な説明を与えてくれます。DocFinQAは長いSEC提出書類で崩壊しま した。IRCoTやFLAREは、推論の前に複数のパッセージを取得して連結します。私が金融コンテキストで見てきたすべてのRAGパイプラインは、取得したパッセージを順次プロンプトに投入し、モデルが正しいものに注意を向けることを期待しています。
Beancountエージェントへの示唆は具体的です。エージェントが10個の元帳エントリをコンテキストとして取得した場合、3番目から7番目の位置にあるエントリは、無視されたり、その周囲でハルシネーション（幻覚）が発生したりするリスクが最も高くなります。これはリトリーバルの問題ではなく、提示（プレゼンテーション）の問題です。この論文から導き出される対応は2つあります。診断的に最も関連性の高いエントリを最初（および最後）に配置するか、あるいは連結を一切行わず、一度に1つのパッセージに対して推論を行うかです。
この発見は、ロングコンテキストLLMのナラティブを複雑にします。四半期ごとに、新しいモデルがより大きなコンテキストウィンドウを発表します。しかしこの論文は、証拠を均一に分散させているのであれば、ウィンドウが長いことは期待通りの意味をなさないと述べています。関連する取引を60Kの位置に埋没させてしまう128Kコンテキストモデルは、正確に正しいパッセージを取得する4Kコンテキストモデルよりも劣ります。
ライトバック（書き戻し）の安全性に関しても、不穏な示唆があります。モデルが元帳セッションの要約を求められ、関連する「この取引を投稿してはならない」というポリシー・ルールが長いシステムプロンプトの中央に現れた場合、モデルはそのルールを一度も読んでいないかのよう に振る舞う可能性があります。
次に読むべきもの
- "Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding" (Zhang et al., arXiv:2403.04797) — RoPEスケーリングを介した訓練不要の修正案としてMulti-scale Positional Encoding (Ms-PoE)を提案。Zero-SCROLLSで最大3.8ポイントの改善を謳い、U字曲線に直接対処しています。
- "Never Lost in the Middle: Mastering Long-Context Question Answering with Position-Agnostic Decompositional Training" (arXiv:2311.09198) — 逆のアプローチをとり、明示的に位置に依存しないようにモデルを訓練。Ms-PoEとの比較により、ファインチューニングと推論時の工夫のどちらがより効果的かが明確になります。
- "Mitigate Position Bias in Large Language Models via Scaling a Single Dimension" (arXiv:2406.02536) — バイアスの原因となっている特定のポジショナル隠れ状態の次元を特定し、再訓練なしでスケール調整を行う手法。これまでに提案された中で最も外科的な修正であり、既存モデルを再訓練なしでデプロイする際に関連します。
