Meta Princeton は LLM コンテキストの究極のソリューションを提案します。モデルを自律エージェントにして、コンテキストノードツリーを自ら読み取る

LLM ロングコンテキスト モデルの究極のソリューションは何ですか?

プリンストン大学とMeta AIの研究者らが最近提案した解決策では、LLMをインタラクティブエージェントとして扱い、反復的なプロンプトを通じてテキストの読み方を決定させます。

論文アドレス: https://arxiv.org/abs/2310.05029

彼らは、長いコンテキストを要約ノードのツリーに処理できる MemWalker と呼ばれるシステムを設計しました。

クエリを受信すると、モデルはこのノードのツリーを検索して関連情報を見つけ、十分な情報を収集したら応答します。長いテキストの質問応答タスクでは、この方法は、長いコンテキスト ウィンドウ、再帰、および検索を使用するベースライン メソッドよりも大幅に優れています。

LeCun氏も彼らの研究をリツイートして支持を表明した。

MemWalker は主に 2 つの部分で構成されています。

まず、メモリ ツリーを構築する必要があります。

長いテキストを要約ノードに分割します。集約ノードはさらに上位レベルのノードに集約され、最終的にルートに到達します。

2番目の部分はナビゲーションです。

クエリを受信すると、LLM はツリーをナビゲートして関連情報を見つけ、適切に応答します。 LLM は推論によってこれを行います。つまり、答えに向かって作業したり、さらに進む道を選択したり、あるいは道に迷った場合には後戻りしたりします。

このナビゲーション プロセスはゼロ ショット プロンプトで実現でき、任意の大規模言語モデルに簡単に適用できます。

研究チームは、このモデルによって構築されたメモリツリーのインタラクティブな読み取りを通じて、特に長い例の場合、MemWalker が他の長いコンテキストのベースラインや検索および再帰のバリエーションよりも優れていることを示しました。

MemWalker の有効性は、次の 2 つの主要な部分に依存します。

1) 作業メモリのサイズ - LLM が検索パスに沿ってより多くの情報にアクセスできるようになると、LLM のグローバル コンテキスト機能が向上します。

2) LLM の推論能力 - LLM が推論しきい値に達すると、MemWalker が有効になります。推論能力が閾値を下回ると、ナビゲーション中のエラー率が高くなります。

MEMWALKER: インタラクティブリーダー

研究チームは、長い文脈での質問への回答に関連するタスクを研究しています。長いテキスト x とクエリ q が与えられた場合、モデルの目標は応答 r を生成することです。

MEMWALKER は 2 つのステップを実行します。

1) 長いコンテキストがツリー データ構造に分割されるメモリ内ツリー構築。この構築はクエリに依存しないため、シーケンス データが事前に利用可能な場合は事前に計算できます。

2) ナビゲーション: モデルはクエリを受信するとこの構造をナビゲートし、適切な応答を作成するための情報を収集します。

MEMWALKER は基盤となる LLM へのアクセスを想定しており、構築とナビゲーションは LLM プロンプトを反復処理することによって実現されます。

ナビゲーション

クエリ q を受信した後、言語モデルはルート ノードからツリーをナビゲートして応答 r を生成します。

LLM が通過するノードでは、次のレベルのノードの要約を観察します。

LLM は、+1 アクションのうち 1 つ (さらに検査するために子ノードを選択するか、親ノードに戻る) を選択することを決定します。

リーフノードでは、LLMは2つのアクションのいずれかを決定できます。リーフノードをコミットしてクエリに応答するか、リーフノードの情報が

不十分な場合は親ノードに戻ります。

ナビゲーションの決定を行うために、研究チームはプロンプトを介して LLM に、まず自然言語でアクションを正当化する理由を生成し、次にアクションの選択そのものをするように依頼することもできます。

具体的には、各ノードで、モデルは応答 r ∼ LLM(r | s, q) を生成します。ここで、応答は 2 つのタプルのいずれかです。1) r = (推論、アクション、回答) (LLM がリーフ ノードに配置されている場合)、2) r = (推論、アクション) (LLM が非リーフ ノードに配置されている場合)。

ナビゲーションプロンプトのデザイン

研究チームはゼロショットプロンプトを通じて LLM ナビゲーションを可能にしました。具体的には、次の 2 種類のプロンプトが必要です。

1) トリアージ チップと 2) リーフ チップ (下の表で強調表示)。

トリアージ プロンプトには、クエリ、子ノードの概要、および LLM が従うべき指示が含まれます。トリアージヒントは、非リーフノードに使用されます。

リーフ プロンプトには、段落の内容、クエリ (およびオプション)、および LLM が回答を生成するか親ノードに戻るための指示が含まれます。

トリアージ プロンプトとリーフ プロンプトの両方で、LLM が従う必要のある出力形式を指定します。フォーマットに従わないと無効なアクションが発生し、LLM を再生成する必要があります。 LLM が解析可能な出力を 3 回連続で生成できなかった場合、ナビゲーションは終了し、「応答なし」が返されます。

ワーキングメモリ

LLM がツリーの検索を終了すると、ナビゲーション トレースに情報を保持し、コンテキストに追加できます。

具体的には、LLMは応答r ∼ LLM(r | s, q, m)を生成する。ここで、追加のワーキングメモリ

空であるか、以前にアクセスしたノードのコンテンツが含まれています。

研究チームは、LLM のコンテキスト ウィンドウ内に収まるように作業記憶を切り捨てました。

上記の表には、[WORKING MEMORY] を介してプロンプトにワーキングメモリを追加する方法も示されています。

実験構成

データセットと評価

研究チームは、SCROLLS ベンチマークからの 3 つのデータセット、QuALITY、SummScreenFD、GovReport を使用しました。研究チームはすべてのデータセットにわたって正確性を実証しました。

品質

QuALITY は、複数選択の質問に回答するデータセットです。

このデータセットには、プロジェクト・グーテンベルクの長編ストーリーと、人間の注釈者によって注釈が付けられた質問が含まれています。研究チームは、187 個の例のサブセットを実験に使用しました。

サマースクリーンFD

SummScreenFD は、もともと要約用に設計されたテレビや映画の脚本を含むデータセットです。

脚本は俳優同士の会話として表現されます。研究チームはデータセットを質問応答タスクに変換し、最初に提供された真実の概要テキストを使用して、Stable Beluga 2 を使用して「誰」の質問を生成し、その後、その回答を人間の専門家が確認しました。

元の長いテキストとペアになった質問は、再ターゲットされた QA タスクの 306 個の例になります。

政府レポート

GovReport データセットには、議会調査局と米国政府監査院の文書と、専門家による要約がまとめられています。

研究チームは、このデータセットを、SummScreenFDと同じ方法で101個の例を含む質問応答データセットに変換しました。

3 つのデータセットには、サンプル機能として長さの異なる長いコンテキストが含まれており、その中には短いサンプルや長いシーケンスもあります。

そのため、研究チームは、より困難で長いコンテキストでのメモリアクセスをより適切に評価するために、元のデータセットと、より長いシーケンスのみを含む各タスクのサブセットの両方の結果を提示します。

閾値はQuALITYの場合は8000トークン、SummScreenFDの場合は6000トークン、GovReportの場合は12000トークンです。

モデル

ほとんどの実験では、他のいくつかの LLM バリアントと比較して最先端のパフォーマンスを提供する Stable Beluga 2 をベース LLM として使用しました。これについては後で説明します。

Stable Beluga 2 は、70B LLaMA-2 をベースにした命令調整モデルであり、微調整は研究チームの評価タスクと重複しません。

最大コンテキスト長は 4,096 トークンです。研究チームは、さらなる微調整や研究チームのタスクの文脈における少数の例の提供を行わずに、ゼロショットキューイング方式でモデルを使用しました。

研究チームは、メモリツリーの構築とナビゲーションアクションおよび推論の生成にトップ p サンプリングを使用しました。

研究チームは、QuALITY、SummScreenFD、GovReport の最大ノード数 maxt Mt = 8、5、8、セグメント サイズ |c| = 1000、1000、1200 をそれぞれ設定しました。

ベンチマーク

研究チームは、Stable Beluga 2 と同じ基盤となる LLM に基づく 3 つのメモリ テクノロジを比較しました。

1) フルコンテキストウィンドウ

2) 再帰

3) 検索

フルコンテキスト ウィンドウ ベースラインは、長い入力テキストと生成を処理するために 4,096 個のトークンすべてを使用します。データセット内のインスタンスはコンテキスト制限を超えることが多いため、研究チームは長さを切り捨て、テキストの右側 (最も近い) または左側 (最も新しい) を入力として取り、両方の方法を評価します。

検索のために、研究チームはContriever (Izacard et al., 2022) を使用して、クエリに基づいて長いコンテキストから文章を選択しました。最も高いスコアの段落は、コンテキストがいっぱいになるまで LLM の入力コンテキストとして連結されます。

最後に、研究チームは、要約を介して前の段落トークンからの情報を現在の段落にループするベースラインを実装しました。各段落は 2,500 トークンで、要約の最大サイズは 500 トークンです。

結果と分析

主な結果

以下の表 2 は、MEMWALKER と他のベースラインとの比較を示しています。

MEMWALKER は、すべてのタスクにおいて再帰ベースラインを大幅に上回ります。

これは再帰の制限を示しており、数ステップ後にクエリに関する関連情報が失われます。

MEMWALKER は、段落が個別のドキュメントからではなく、一貫した長いストーリーから取得される場合の検索を超えています。

これらのタスクでは、フルコンテキスト ベースラインは、比較的短いシーケンスが含まれる可能性が高い「raw」タスク設定で良好なパフォーマンスを発揮できますが、最良のパフォーマンスを得るための左切り捨てまたは右切り捨ての選択はデータセットに依存するようです。

ただし、QuALITY の右側のバリアントと GovReport の左側のバリアントを保持することを除いて、MEMWALKER は元の設定でフルコンテキスト ベースラインよりも高いパフォーマンスを達成します。これは、関連する段落が通常テキストの先頭または末尾に表示されるデータセット内の位置の偏りによるものである可能性があります。

ただし、3 つのタスクすべての長いバージョンでは、MEMWALKER はすべてのベースラインを上回ります。つまり、メモリ アクセスがより重要になったときに強力なパフォーマンスを示します。

MEMWALKER は、LongChat や MPT など、公開されている他のモデルよりも優れたパフォーマンスを発揮します。

MEMWALKER は長いシーケンスでのパフォーマンスを向上します。研究チームは、上の図 2 で各タスクの入力シーケンスの長さ別のパフォーマンスの内訳を示しています。

MEMWALKER は、テキストの長さが短い場合はフルコンテキスト (左または右の切り捨て) ベースラインよりも劣りますが、すべてのタスクにおいて、より長いシーケンスでは両方の切り捨てタイプよりも優れています。

インタラクティブな読み取りの利点は、テキストの長さが適切に増加するにつれて明らかになります。つまり、シーケンスの長さが LLM コンテキストの長さ 4,096 よりも大幅に大きくなると、パフォーマンスが向上します。

推論機能はメモリツリーのナビゲーションに不可欠です。

MEMWALKER の有効性は、基礎となる LLM の推論能力に大きく依存します。研究チームは、ナビゲーションの決定ごとに LLM プロンプトを使用し、LLM が最初に自然言語で理由を生成して次の予測アクションを正当化することを要求しました (下の表 1 を参照)。

研究チームは、以下の表 3 で、Llama 2 Chat (13B および 70B パラメータ バリアント) と Stable Beluga 2 (70B) を比較し、プロンプトから「決定を下す前にまず推論を提供してください...」という行を削除することで、推論がパフォーマンスにどのように影響するかを示しています。

小型で性能の低いモデル (13B) の場合、指示に従えないため、パフォーマンスは 70B モデルに比べて大幅に劣ります。実際、弱いモデルに対して推論の正当性を要求すると、おそらくこれらの正当性を生成して活用できないため、パフォーマンスが低下します。

安定した Beluga 2 は、同じ LLM サイズの Llama 2 Chat よりもパフォーマンスが優れており、推論機能も強化されています。

Stable Beluga 2 では、正当化を要求すると、すべてのタスクのパフォーマンスが向上します。これは MEMWALKER の重要な特徴を強調しています。LLM が重要な推論能力のしきい値を通過すると、ラウンド間で急速にエラーが発生することなく、複数のラウンドで長い入力を推論できます。

適切なナビゲーション決定を下せない弱い LLM の場合、エラーが蓄積され、全体的なパフォーマンスが低下する可能性があります。

今後数年間で LLM の推論能力が向上し続けるため、研究チームは MEMWALKER のような方法がますます効果的になると予想しています。

メモリツリーをナビゲートするには、作業メモリが必要です。 MEMWALKER がメモリツリーをトラバースして関連する段落を読むことを決定すると、全体的なコンテキストの認識が失われる可能性があります。

したがって、モデルはナビゲーション パスに沿ったノードからの情報を作業メモリとして保持し、モデルが次のパスを選択すると作業メモリの内容が更新されます。

研究チームは、ワーキングメモリの有無にかかわらず MEMWALKER のパフォーマンスを評価しました。その結果が下の図 3 に示されています。

研究チームは、すべてのタスクにおいて、作業記憶の枯渇によりパフォーマンスが大幅に低下し、精度が5～13%低下することを発見し、この要素の重要性を浮き彫りにしました。

MEMWALKER は障害のあるパスから回復できます。

MEMWALKER がメモリ ツリーをナビゲートする際、最も関連性の高い段落へのパスを見つける必要があるだけでなく、完全な検索エラーから回復する必要がある場合もあります。

研究チームは、以下の表 4 に回復統計を示します。 MEMWALKER は、約 15% ～ 20% の例に対してナビゲーション アクションの再開 (したがってパスの変更) を実行しますが、これらの例から回復して、QuALITY では 70%、SummScreenFD では 60%、GovReport では約 80% の時間で正しく取得できます。

MEMWALKERは効率的な読み取りを実現します。 MEMWALKER は長いテキストのどの部分を読み取る必要があるかを判断するため、読み取る必要のある実際のコンテンツはシーケンス全体よりも小さくなる可能性があります。

研究チームは、3 つのタスクそれぞれについて、すべての例におけるロングコンテキスト読み取りの割合の平均を示しています (下の図 4 を参照)。研究チームは、質問に答えるには、ツリーノードの内容を含め、平均してテキストの63%～69%だけを読む必要があることを発見しました。

成功したパスでは、必要な読み取りがさらに 59% - 64% に削減されました。

メモリ内ツリー構築のトレードオフ

研究チームがメモリツリーを構築したとき、根本的なトレードオフが発生しました。大きな段落をノードに要約するとツリーの深さは減りますが、コンテンツの正確さが失われる可能性があります。

同様に、多くの下位レベルのノードを上位のノードに接続すると、ツリーを平坦化するのに役立ちますが、各ノードでの LLM ナビゲーション タスクが困難になる可能性があります。

下の図 5 は、QuALITY 上のメモリ ツリーのさまざまな構成のパフォーマンスを示しています。多くの場合、小さな段落を要約してより多くの子ノードを親ノードに接続するよりも、大きな段落を要約する方が効果的です。

ただし、最大ノード数が増加するとパフォーマンスは一定になり、メモリ内ツリー構築時にノードに詰め込める情報量とのトレードオフが示されます。