メタプリンストンは、LLMコンテキストの究極のソリューションを提案します! モデルを自律エージェントにし、コンテキスト・ノード・ツリーを単独で読み取る

原典:シン・ジユアン

画像ソース:無制限のAIによって生成

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

プリンストン大学とMeta AIの研究者によって最近提案された解決策は、LLMを、反復的なプロンプトを通じてテキストを読み取る方法を決定できるインタラクティブなエージェントと考えることです。

論文住所:

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

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

LeCunはまた、彼らの研究への支持をツイートしました。

メムウォーカーは2つの主要部分で構成されています。

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

長いテキストをサマリー ノードにスライスします。 ロールアップ ノードはさらに上位レベルのノードに集計され、最終的にルートに到達します。

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

クエリを受け入れると、LLM はツリー内を移動して関連情報を見つけ、適切に応答します。 LLMは、推論を通じてこのプロセスを達成します–おそらく答えを見つけるために働くか、1つの道をさらに進むことを選択するか、または自分自身が見当違いであることに気づき、同じように引き戻します。

このナビゲーション プロセスは、サンプルなしのプロンプトで実装でき、指定された大規模な言語モデルのいずれかに簡単に適合できます。

研究チームは、このモデルによって構築されたメモリツリーをインタラクティブに読み取ることで、MemWalkerが、特に長い例について、他の長いコンテキストベースラインと検索およびループバリアントを上回っていることを示しました。

メムウォーカーの効果は、次の2つの重要な部分に依存します。

1)ワーキングメモリサイズ– LLMは、LLMが取得するパスに沿ってより多くの情報を取得できるようにする場合、より優れたグローバルコンテキスト機能を備えています。

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

メモリウォーカー:インタラクティブな読者**

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

MEMWALKERは2つのステップに従います。

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

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

MEMWALKER は、基礎となる LLM へのアクセスを想定し、LLM プロンプトを反復処理することによってビルドとナビゲーションを実装します。

航法

クエリ Q を受信すると、言語モデルがルート ノードから削除されます

ツリーのナビゲーションを開始して、応答を生成します。

LLM でトラバースされたノード

では、次のレベルのノードを監視します

の概要。

LLMはで決定しました

+ 1 アクションのいずれかを選択 - さらに検査するために子ノードを選択するか、親ノードに戻ります。

リーフ ノード

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

(すなわち

)が十分でない場合は、親ノードに戻ります

。

ナビゲーションの決定を行うために、研究チームはLLMに、最初にアクションを促し、次にアクションの選択自体によって自然言語で正当化を生成するように依頼することもできます。

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

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

研究チームは、ゼロサンプルプロンプトでLLMナビゲーションを可能にしました。 必要なヒントには次の 2 種類があります。

1)トリアージのヒントと2)リーフのヒント(下の表で強調表示されています)。

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

リーフプロンプトには、段落コンテンツ、クエリ(およびオプション)、およびLLMが回答を生成するか親ノードに戻る必要がある命令が含まれています。

トリアージのヒントとリーフのヒントはどちらも、LLMが従う必要のある出力形式を指定します。 形式に従わないと無効なアクションが発生し、LLMを再生成する必要があります。 LLM が解決可能な出力を 3 回連続して生成できない場合、ナビゲーションは終了し、"No Answer" を返します。

ワーキングメモリ

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

正確には、LLMは追加の作業メモリを持つ応答r∼LLM(r | s, q, m)を生成します

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

研究チームは、LLMのコンテキストウィンドウに収まるようにワーキングメモリを切り捨てました。

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

実験的な構成

データセットと評価

研究チームは、SCROLLSベンチマークから得られたQuALITY、SummScreenFD、GovReportの3つのデータセットを使用しました。 研究チームは、すべてのデータセットの精度を実証しました。

品質

QuALITY は、多肢選択式の質問と回答のデータセットです。

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

サムスクリーンFD

SummScreenFDは、もともと要約用に設計されたテレビや映画のスクリプトのデータセットです。

これらのスクリプトは、俳優間の対話の形で提示されます。 研究チームはこのデータセットを質疑応答タスクに変換し、生で提供された基本的な真実の要約テキストを使用して、Stable Beluga 2を使用して「誰」の質問を生成し、それを人間の専門家によってチェックしました。

元の長いテキストとペアになった質問は、再配置されたQAタスクの306の例になりました。

政府レポート

GovReportデータセットには、議会調査局と米国政府説明責任局からの文書と、専門家から提供された要約がまとめられています。

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

3つのデータセットはすべて、長さの異なる長いコンテキスト、いくつかの短い例、およびいくつかの長いシーケンスによって特徴付けられます。

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

しきい値は、QuALITY の 8,000 トークン、SummScreenFD の 6,000 トークン、および GovReport の 12,000 トークンです。

モデル

研究チームは、研究チームが実証する他のいくつかのLLMバリアントと比較して最先端のパフォーマンスを提供するため、ほとんどの実験でStable Beluga 2をベースLLMとして使用しました。

安定版ベルーガ2は、70B LLaMA-2ベースの命令チューニングモデルであり、微調整は研究チームの評価タスクと重複しません。

コンテキストの最大長は 4,096 トークンです。 研究チームは、さらに微調整したり、コンテキスト内の研究チームのタスクの少数の例を提供したりすることなく、モデルをゼロショット方式で使用しました。

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

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

ベンチマーク

研究チームは、同じ基礎となるLLMに基づく3つのメモリ技術を安定したベルーガ2と比較しました。

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

2)再帰

3)検索

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

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

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

結果と分析

主要な結果

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

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

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

MEMWALKERはまた、検索を超えて、パッセージが別のドキュメントではなく、首尾一貫した長い形式のストーリーから来ています。

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

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

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

MEMWALKERはまた、LongChatやMPTを含む他の公開モデルを上回っています。

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

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

対話式読み取りの利点は、テキスト長の適切な増加が明らかになる、つまり、シーケンス長が4,096 LLMコンテキスト長を大幅に超えると、パフォーマンスが向上することです。

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

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

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

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

安定したベルーガ2は、同じLLMサイズのラマ2チャットを上回り、強化された推論機能も示しました。

安定版 Beluga 2 では、すべてのタスクで推論の正当性を要求すると、パフォーマンスが向上します。 これはMEMWALKERの主な特徴を浮き彫りにします:LLMがクリティカル推論能力のしきい値を超えると、ラウンド間でエラーをすばやく生成することなく、複数のラウンドにわたる長い入力について推論できます。

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

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

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

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

研究チームは、ワーキングメモリの有無にかかわらずMEMWALKERの性能を評価し、その結果を下の図3に示します。

研究チームは、ワーキングメモリの枯渇により、すべてのタスクでパフォーマンスが大幅に低下し、精度が5〜13%低下することを発見し、このコンポーネントの重要性を示しています。

MEMWALKERは間違ったパスから回復する可能性があります。

MEMWALKERがメモリツリーをナビゲートするとき、最も関連性の高い段落へのパスを見つける必要があるだけでなく、すべての検索エラーから回復する必要があるかもしれません。

研究チームは、以下の表4に回復統計を示します。 MEMWALKERは、サンプルの約15%〜20%に対してリカバリナビゲーション操作を実行します(したがってパスを変更します)が、これらの例では、QuALITY、SummScreenFDの場合は60%、GovReportの場合は約80%で正しくリカバリして取得することができます。

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

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

成功への道のりでは、必要な読み取り値はさらに59%〜64%に減少します。

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

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

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

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

ただし、ノードの最大数が増えるにつれてパフォーマンスは頭打ちになり、メモリツリーの構築中にノードにパックできる情報の量のトレードオフが示されました。

リソース：