MemGPT: LLMエージェントのための仮想コンテキスト管理
ほとんどのLLMエージェントを制限している制約は知能ではなく、メモリです。私は、数年にわたる取引を含むBeancountの帳簿（レジャー）という文脈で、これを具体的に考えてきました。基礎となるモデルがいかに有能であっても、帳簿の履歴がコンテキストウィンドウを超えると、エージェントは忘れ始めます。MemGPT (Packer et al., UC Berkeley, 2023) は、オペレーティングシステムが数十年前に解決した手法を借りることで、この問題に直接取り組んでいます。
論文の概要
論文「MemGPT: Towards LLMs as Operating Systems」（Packer, Wooders, Lin, Fang, Patil, Stoica, Gonzalez; arXiv:2310.08560）は、仮想コンテキスト管理を提案しています。これは、高速なRAMと低速なディスクの間でページングを行うことで、大規模な仮 想メモリの錯覚を作り出すOSの仕組みを意図的に模倣したものです。LLMのコンテキストウィンドウは、RAMの役割を果たします。つまり、希少で高速、かつ直接アクセス可能です。2つの外部ストレージがディスクの役割を果たします。一つはリコールストレージ（最近のメッセージ履歴）、もう一つはアーカイブストレージ（任意のテキストを検索可能な長期データベース）です。エージェント自身が、明示的な関数呼び出し（階層間でデータを移動させるツール）を使用して、外部ストレージから何を読み込み、コンテキストから何を退避（エビクト）させるかを決定します。システムはコンテキスト容量の70%で退避警告を発し、100%で強制的にフラッシュを行い、情報の完全な損失を避けるために退避されたメッセージの再帰的な要約を生成します。
この論文では、MemGPTを2つの領域で評価しています。マルチセッションの対話型エージェント（Multi-Session Chatデータセット）と、モデルのネイティブなコンテキストウィンドウを超える大規模なコーパスにわたるドキュメント分析です。
主なアイデア
- 3つのメモリ階層: コンテキスト内のワーキングメモリ（高速、限定的）、リコールストレージ（最近のメッセージ、検索可能）、およびアーカイブストレージ（長期、インデックス化）。エージェントはツール呼び出しを介してこれら3つすべてに書き込みます。
- Deep Memory Retrieval (DMR): 過去の複数のセッションにわたって一貫した想起を必要とする評価タスク。GPT-4を使用した場合、標準的な固定コンテキストのベースラインは32.1%の精度でしたが、MemGPTは92.5%まで急上昇しました。GPT-4 Turboのベースラインでは、35.3%から93.4%になりました。
- ネストされたキーバリュー検索: ドキュメント分析のストレステスト。標準的なGPT-4は、3レベルのネストで精度0%になりますが、MemGPTとGPT-4の組み合わせは、反復的なアーカイブ検索を行うことでパフォーマンスを維持します。
- 割り込みによる制御フロー: エージェントは、応答する前に（メモリ操作を実行するために）さらに時間が必要な場合に信号を送ります。これはOSの割り込みに類似しています。これにより、すべてを単一の推論パスに詰め込むことなく、システムの応答性を維持します。
- 退避の問題: コンテキストがいっぱいになると、コンテンツは要約されてフラッシュされます。再帰的な要約は要点を保持しますが、必然的に詳細が失われます。これは論文でも認められているトレードオフですが、完全には定量化されていません。
評価できる点と課題
DMRの数値は驚異的です。Multi-Session ChatデータセットにおけるMemGPTと標準的なGPT-4ベースラインの間の60ポイントの精度の差は、単なる誤差ではありません。ネストされたKVの 結果（ベースラインが0%で失敗する一方で、MemGPTが動作し続けること）は、受動的なロングコンテキストへの露出と比較して、反復的でツールを介した検索の価値が本物であることを示しています。これは、Liuらによる「Lost in the Middle（中だるみ現象）」（arXiv:2307.03172）の発見とも結びつきます。情報が物理的にコンテキストウィンドウに収まっていても、モデルは中間に埋もれたコンテンツに対して性能が低下します。MemGPTは、すぐに必要なものだけを検索することでこれを回避します。
とはいえ、評価には現実的な穴もあります。Multi-Session Chatデータセットは限定的です。これは、厳密に制御された形式の人間のペルソナチャットです。このアプローチが、より乱雑な現実世界の会話や、ドメイン固有のコーパス（財務書類、規制関連の通信など）にどのようにスケールするかは検証されていません。実験におけるアーカイブストレージは単純なベクトルデータベースです。アーカイブが数百万のドキュメントに成長したときに検索品質が維持されるかどうかは未解決のままです。より根本的には、エージェントの検索戦略は、そのクエリの質に依存します。エージェントが「自分が何を知らないか」を知らない場合（長期的なタスクでよくある失敗モード）、適切なアーカイブ検索を発行できず、アーキテクチャ全体が固定コンテキストと同じ失敗モードに陥ります。
また、論文では軽く扱われていますが、レイテンシのコストもあります。アーカイブ検索のたびに追加のLLM推論（クエリ生成のため）とベクトル検索が発生します。数年分のデータを対象に日常的な照合を行うBeancountエージェントの 場合、1つの応答に対して多くの往復が発生する可能性があります。論文では、実時間（ウォールクロック）でのレイテンシ比較は報告されていません。
その後の研究では、これらの批判がより鋭くなっています。A-MEM (arXiv:2502.12110) は、マルチホップタスクにおいてMemGPTよりも少なくとも2倍優れたパフォーマンスを主張し、MemGPTの硬直した階層構造は、より動的なメモリ管理に劣ると論じています。Mem0のベンチマーク（2024-2025年）では、いくつかの設定でMemGPTを精度と速度で上回る競合アプローチが示されています。原著者はその後、プロジェクトをLetta（2024年9月）へと進化させました。これは、メモリ統合のための非同期の「スリープタイム計算」を備えたオープンソースのエージェントフレームワークであり、同期的な単一エージェント設計にはスケーリングの限界があることを暗に認めています。
なぜこれが財務AIにとって重要なのか
小規模企業のBeancount帳簿には、10年間で数万件の取引が蓄積されます。年度末の照合、異常値の調査、または数年にわたるトレンド分析を任されたエージェントは、すべてをコンテキストに収めることはできません。MemGPTの3層設計は、これにほぼ直接対応します。ワーキングメモリには現在レビュー中の取引バッチを保持し、リコールストレージには最近のセッションコンテキスト（ 前回何を照合していたか）を保持し、アーカイブストレージには帳簿の全履歴、仕訳入力、および以前の異常報告を保持します。メモリ操作のための関数呼び出しインターフェースは、エージェントが書き戻し操作ですでに必要としているインターフェースと本質的に同じです。これは新しい機能クラスではなく、同じツール呼び出しの仕組みの新しい応用です。
より深い関連性は、フレーミングの転換にあります。「コンテキストにもっと詰め込めるか？」と問う代わりに、MemGPTは「エージェントは自分の注意を管理できるか？」と問います。財務においては、これが正しい問いです。税務調査では、3年前の取引について質問が出るかもしれません。有能な人間の会計士は、元の請求書を取り出し、帳簿と照合し、その年のポリシーコンテキストを思い出します。この「オンデマンドの検索」動作こそが、MemGPTが私たちに設計を促しているものです。
正直な注意点として、MemGPTは財務データで評価されたわけではなく、財務ドキュメントは構造的にペルソナチャットとは異なります。高密度の数値データ、多通貨取引、および複式簿記のスキーマにわたる検索品質については、独自のベンチマークが必要になるでしょう。
次に読むべきもの
- Lost in the Middle: How Language Models Use Long Contexts (Liu et al., arXiv:2307.03172) — なぜ長いコンテキストウィンドウだけでは問題が解決しない のかという実証的基礎。モデルはドキュメント中間のコンテンツに注意を払うことができず、それがMemGPTのような検索ベースのアプローチを動機付けています。
- A-MEM: Agentic Memory for LLM Agents (arXiv:2502.12110) — MemGPTの硬直した階層構造を動的なメモリ管理に置き換えることで、優れたマルチホップメモリ性能を主張する2025年の後続研究。必要な比較対象です。
- Gorilla: Large Language Model Connected with Massive APIs (arXiv:2305.15334) — このリストの次にあるもの。そこでの検索拡張ツール呼び出し設計は、大規模なAPIセットからエージェントが適切なツールを選択する方法に対処することで、MemGPTのメモリ管理を補完します。
