今回の論文
今回取り上げるのは、Charles Packer、Sarah Wooders、Kevin Lin、Vivian Fang、Shishir G. Patil、Ion Stoica、Joseph E. Gonzalez による論文「MemGPT: Towards LLMs as Operating Systems」です。2023年10月12日に arXiv へ投稿され、2024年2月12日に改訂版が公開されています。公開元は arXiv、研究分野は LLM エージェントと長文コンテキスト処理です。URL は https://arxiv.org/abs/2310.08560 です。
この論文を選んだ理由は、長い文書や長期会話を扱うときに「もっと長いコンテキストを持つモデルを使う」以外の選択肢を示しているからです。RAG、社内アシスタント、対話エージェント、調査ボットなど、実務でそのまま応用しやすい考え方が詰まっています。
どんな技術か
MemGPT は、LLM のコンテキストウィンドウを「有限なRAM」のように見なし、外部ストレージを「ディスク」のように使いながら、必要な情報を自分で出し入れさせる仕組みです。
普通の LLM は、今プロンプトに入っている情報しか直接見られません。そのため、会話が長くなると昔の話を忘れたり、長い文書では必要な箇所まで届かなかったりします。MemGPT はこの問題に対して、モデル自身にメモリ管理の役割を持たせます。必要なときだけ外部メモリを検索し、重要な情報は作業メモリに残し、不要になったものは外へ逃がします。
要するに MemGPT は、「最初から全部コンテキストに入れる」のではなく、「今読むべき情報だけをコンテキストに載せ続ける」技術です。長文対応モデルそのものではなく、固定長 LLM を賢く運用するためのシステム設計だと考えるとわかりやすいです。
課題
この技術が解決しようとしているのは、LLM の固定長コンテキストが、長文処理や長期対話の現実的なボトルネックになっていることです。
何が難しいのかというと、実際のアプリでは必要な情報が「今のターンに近い発話」だけにあるとは限らないからです。たとえば長期対話では、数日前に話したユーザーの好みや過去の出来事が必要になります。長文読解では、数十ページ前に出てきた定義と別章の記述をつなげないと答えられない質問が普通にあります。
既存の方法ではどこに限界があるのかというと、単純な会話履歴の切り捨ては重要情報の消失につながりますし、再帰要約だけに頼ると情報が圧縮されるたびに細部が失われます。長コンテキスト化も有効ですが、計算コストが増えるうえ、論文でも参照されているように、長い入力を与えてもモデルがその全部を均等に活用できるわけではありません。
なぜこの課題を解く必要があるのかというと、AI アプリの価値は単発の一問一答よりも、継続的な文脈の保持に依存する場面が増えているからです。社内ナレッジアシスタント、顧客対応ボット、調査エージェント、契約レビュー支援、長文レポート分析などは、どれも文脈をまたいだ記憶が必要です。
実際の AI システムでは、次のような場面で問題になります。会話エージェントが昔の約束や好みを忘れる、RAG がトップ数件の取得だけで答えられない、長文文書の中盤にある重要情報を見落とす、といったケースです。MemGPT はこの問題を、モデルの学習ではなく「運転のしかた」で改善しようとします。
用語解説
- コンテキストウィンドウ
- LLM が一度の推論で直接読めるトークン範囲です。MemGPT はこの限られた領域を固定資源とみなし、その中に何を残し何を外へ逃がすかを制御します。
- 仮想メモリ
- OS が RAM より大きなデータを扱えるようにする仕組みです。MemGPT の中心的な発想で、LLM でも「見かけ上はもっと長い文脈を扱える状態」を作ろうとしています。
- 関数呼び出し
- LLM がテキストを返す代わりに、検索や書き込みなどの操作を明示的に要求する仕組みです。MemGPT ではこの機能を使って、メモリ検索、メモリ更新、ページ送りのような操作を実行します。
- 作業メモリ（working context）
- 現在のタスクに必要な要点を保持する、LLM の書き換え可能な短期メモリです。ユーザーの好み、今の問題設定、途中で見つけた重要事実などをここに残すことで、毎回すべてを検索し直さずに済みます。
- アーカイブメモリ（archival storage）
- 長文文書や過去ログのような大きい外部保存領域です。MemGPT はここを検索して必要な情報だけを取り込みます。RAG の外部知識庫に近いですが、読み出しの主導権を LLM 側に持たせる点が重要です。
技術の仕組み
MemGPT の仕組みは、「有限なメインコンテキスト」と「外部メモリ」を分け、その間を LLM 自身に移動させる設計にあります。
基本アイデア
コアの発想は、LLM のプロンプト全体を単なる入力文字列ではなく、管理対象のメモリ空間として扱うことです。今すぐ必要な情報だけをメインコンテキストに置き、それ以外は外部メモリに退避させます。必要になったら検索して呼び戻します。
これは OS のページングにかなり近い考え方です。従来の LLM アプリは、全履歴を入れるか、切るか、雑に要約するかの三択になりがちでした。MemGPT はそこに「自分で情報を出し入れする」という選択肢を足しています。
メインコンテキストを3つに分ける
論文では、メインコンテキストを大きく3つに分けています。
1つ目は system instructions です。これは MemGPT の動作ルールや関数の使い方を記した固定領域です。2つ目は FIFO queue で、最近の会話や関数実行結果が時系列で入る領域です。3つ目は working context で、LLM が重要事項を書き残す短期メモリです。
この分割が重要なのは、「最近見た情報」と「長く保持したい要点」を分けられるからです。会話ログ全体をそのまま残すのではなく、要点だけを working context に昇格させられます。
外部メモリを2種類に分ける
MemGPT は外部メモリも2種類に分けています。
1つは recall storage です。これは会話履歴や過去イベントをそのまま蓄積する領域で、タイムスタンプ検索やテキスト検索に向いています。もう1つは archival storage で、長文文書や永続化した知識を保存するための汎用ストアです。
この分離によって、「過去ログをたどりたい」のか「知識ベース全体から必要箇所を探したい」のかで検索先を変えられます。実装面では、前者は会話ログDB、後者はベクトル検索付き文書ストアとして分ける設計がしやすいです。
LLM が自分で検索・書き込みを判断する
MemGPT の特徴は、メモリ管理を外部オーケストレーターが全部決めるのではなく、LLM 自身が関数呼び出しで決める点です。たとえば、会話中に「これは今後も必要な好みだ」と判断したら working context や archival storage に書き込みます。逆に、今の答えに必要な過去情報が足りなければ recall storage や archival storage を検索します。
つまり、RAG の検索タイミングが固定ではありません。ユーザーの質問に即答する前に、何回か検索してページ送りし、十分に材料が揃った段階で答えることができます。
メモリ圧迫時の警告と退避
論文では、コンテキスト使用量が閾値に近づくと queue manager が memory pressure 警告を挿入します。これを見た LLM は、重要そうな情報を working context や archival storage に退避させます。
さらに上限に達すると、FIFO queue の古い部分は再帰要約付きで圧縮されます。ここで重要なのは、要約に頼り切らず、その前段で「残すべき事実」を LLM が明示的に保存しておくことです。単なる自動要約より、失いたくない情報を選別できる設計になっています。
関数チェーンで複数回検索できる
MemGPT は1回の関数呼び出しで終わりません。ある検索結果を見て、さらに次の検索を呼び、必要なら別のページを開き、十分な根拠が集まってから最終応答します。論文では heartbeat のような再実行フラグを使い、LLM が制御をすぐ取り戻して連続操作できるようにしています。
この仕組みにより、普通の「retrieve once, answer once」という RAG より柔軟になります。特に、検索クエリの一発目で当たり文書が上位に出ない場合でも、検索語を変えたりページを進めたりして追跡できます。
文書読解では外部検索がそのままリトリーバになる
文書分析タスクでは、アーカイブストレージに大量の Wikipedia 文書を保存し、ベクトル検索付きの検索機能を MemGPT に持たせています。固定長ベースラインは top-K 文書を一度に渡されるだけですが、MemGPT は必要に応じて何度も検索し、結果を順に取り込めます。
この違いは、取得上位に答えがないときに効きます。普通の RAG は top-K の外に正解文書があると詰みますが、MemGPT は検索を継続できるぶん、実効的な探索深度を伸ばせます。
実験と結果
論文では、MemGPT を長期対話と長文文書分析の2領域で評価しています。ポイントは、単に長い入力を処理できるかではなく、必要な情報を適切に思い出せるかです。
何を検証したのか
対話では、過去セッションに依存する質問へ一貫して答えられるか、そして過去情報を使って自然で魅力的な会話を始められるかを検証しています。文書分析では、長い文書群から必要な情報を繰り返し取得して答えられるか、さらに複数段の検索が必要な問題を解けるかを見ています。
どんなデータセットや評価指標を使ったのか
長期対話では Multi-Session Chat（MSC）を拡張し、新たに Deep Memory Retrieval という課題を作っています。これはセッション1から5で話した内容を前提に、セッション6で狭い正答範囲の質問を投げる設定です。評価には、正答判定と ROUGE-L が使われています。
会話の魅力を測る実験では、過去のペルソナ情報を踏まえた会話オープナーを生成させ、類似度指標で人手作成文と比較しています。
文書分析では、NaturalQuestions-Open を使った multi-document QA と、論文独自の nested key-value retrieval を使っています。前者は Wikipedia 文書群から質問に必要な文書を探す課題で、後者はキーをたどって次の値を探し、さらにその値を次のキーとして追跡する多段検索タスクです。
長期対話では記憶想起の精度が大きく上がった
Deep Memory Retrieval の結果では、固定長の GPT-4 が正答率 32.1% だったのに対し、MemGPT を組み合わせると 92.5% まで上がっています。GPT-4 Turbo でも 35.3% から 93.4%、GPT-3.5 Turbo でも 38.7% から 66.9% へ改善しています。
この結果が示しているのは、ベースモデル自体の知能だけではなく、「必要な過去情報へ戻れるかどうか」が長期対話の品質を大きく左右するということです。特に GPT-4 系では、記憶アクセスの設計が当たると性能差が非常に大きく出ています。
会話オープナーでも過去情報の活用が効いた
会話の出だしを作る実験では、MemGPT は過去のペルソナ情報を踏まえた、より具体的なオープナーを作れました。論文では、人手作成のオープナーと同程度か、一部指標では上回るケースも報告されています。
ここで重要なのは、単に昔の事実を覚えているだけでなく、それを会話の自然さやパーソナライズに変換できている点です。実務でいうと、継続利用される AI アシスタントや CS ボットの体験改善に直結しやすい部分です。
文書QAでは「一度で取り切れない」状況に強かった
multi-document QA では、固定長ベースラインは最初に渡された top-K 文書の質に強く縛られます。論文では、正解文書が最初の十数件より後ろに出ることも多く、その場合ベースラインは正解文書自体を見られません。
一方の MemGPT は、アーカイブストレージを繰り返し検索し、結果をページ送りしながら追えるため、取得の浅さに起因する失敗を減らせます。論文本文でも、MemGPT は複数回の検索によって、固定長方式より大きい実効コンテキストを扱えると説明されています。
多段検索タスクでは2段超えでも安定した
nested key-value retrieval では、MemGPT は2段を超えるネストでも一貫して解けたのに対し、通常の固定長 LLM は深いネストで崩れやすい結果でした。論文では、MemGPT が「キーを探す → 対応する値を得る → その値を次のキーとしてまた探す」という逐次探索を継続できることが効いています。
これはかなり実務的な示唆があります。現場の問い合わせや業務フローは、1回の検索で答えが出るよりも、「1つ見つけた手がかりを次の検索に使う」形が多いからです。MemGPT はこの連鎖をアプリ構造として内包しています。
何に使える？
MemGPT の価値は、長文に強いモデルを使わなくても、固定長 LLM をより長期的で探索的な仕事に使いやすくする点にあります。
長期記憶を持つ社内アシスタント
社内ヘルプデスクや業務アシスタントでは、ユーザーごとの設定、過去の問い合わせ、未解決の論点を覚えていると体験が大きく変わります。MemGPT 型の構成なら、短期的な会話は working context に、長期的な履歴は recall storage に分けて保持できます。
長文ドキュメントを読む調査エージェント
契約書、監査資料、仕様書、障害報告書のように長い文書を横断する調査タスクと相性が良いです。最初の検索で必要箇所が全部そろわなくても、検索語を変えながら段階的に追跡できるためです。
RAG の上に乗る探索型ワークフロー
普通の RAG は「検索して回答」の1往復で終わりがちですが、MemGPT 的な設計を入れると、検索結果を読んで追加検索するループを作れます。複数段の社内ナレッジ探索、FAQ の根拠確認、法務・規程チェックなどに向いています。
パーソナライズされた対話プロダクト
英会話コーチ、健康相談、学習支援、営業支援のような継続利用前提のプロダクトでは、利用者の傾向や過去の課題を覚えていることが重要です。MemGPT の working context と archival storage の分離は、この種のパーソナライズにかなり応用しやすいです。
開発や事業へのヒント
この論文から得られるヒントは、「長期記憶」は巨大モデルの能力として待つより、アプリケーション側のメモリ設計として作るほうが早い、ということです。
会話履歴を全部詰め込む発想をやめる
自分で AI アプリを作るなら、履歴を毎回全部送る設計は早めに捨てたほうがよいです。最近の対話、重要な事実、永続知識を分けて持つだけでも、コストと品質の両方を改善しやすくなります。
RAG を「検索一発」で終わらせない
既存サービスの改善でも、top-K を一度取って終わる構成には限界があります。MemGPT の考え方を応用し、検索結果から追加検索を起動する二段・三段の探索パスを作るだけでも、複雑質問への耐性が上がるはずです。
小規模プロダクトでも部分導入しやすい
MemGPT をそのままフル実装しなくても、考え方だけを切り出せます。たとえば、重要情報を専用メモに昇格する仕組み、検索結果のページ送り、会話履歴DBと知識DBの分離などは、小さな SaaS や社内ツールでも実装可能です。
今後注目すべき方向性は「長い入力」より「長い運用」
今後注目すべきなのは、単純な長コンテキスト競争だけではなく、有限コンテキストをどう運用するかという方向性です。エージェント、RAG、ワークフロー自動化が進むほど、記憶管理、状態管理、検索戦略の設計が差別化要因になります。
限界
まず、MemGPT はアーキテクチャとしては賢いですが、実装は単純ではありません。関数呼び出し、メモリ管理、検索基盤、ページ送り、状態保持など、通常のチャットボットより管理対象が増えます。
次に、ベースモデルの関数呼び出し性能に依存します。論文でも GPT-3.5 ベースの MemGPT は GPT-4 ベースよりかなり弱く、検索やメモリ更新の判断が不安定だと全体性能も落ちます。
また、検索基盤が弱いと限界があります。MemGPT は検索を何度も回せますが、検索結果に正解候補がまったく出てこなければ答えられません。つまり、万能な記憶ではなく、あくまで外部ストレージと検索品質に支えられた記憶です。
さらに、再帰要約やメモリ昇格の判断には誤りがありえます。重要な事実を保存し損ねたり、逆にノイズを残しすぎたりすると、後の回答品質に影響します。実運用では、何を自動保存し、何を後で再取得させるかの方針設計が必要です。
最後に、この論文は長期記憶の方向性を示す強い提案ですが、評価領域は対話と文書読解が中心です。業務システム連携や多数ツール併用エージェントでどう最適化すべきかは、追加検証が必要です。
よくある質問
Q. MemGPT は普通の RAG と何が違うのですか？
A. 普通の RAG は多くの場合、検索して結果をまとめて渡し、そのまま答えます。MemGPT は検索を1回で終わらせず、必要なら追加検索し、重要事項を作業メモに保存しながら進めます。検索と記憶管理を LLM の行動として扱う点が大きな違いです。
Q. 長コンテキストモデルがあれば MemGPT は不要ですか？
A. そうとは限りません。長コンテキスト化で一度に読める量は増えますが、必要情報をどう選ぶか、どこを重点的に参照するかは別問題です。MemGPT は有限コンテキストの運用設計なので、長コンテキストモデルと併用する余地もあります。
Q. 小規模なアプリでも導入できますか？
A. できます。論文の完全版は大がかりですが、会話の重要事項だけ別メモに保存する、検索結果をページ送りする、履歴DBと知識DBを分ける、といった部分導入でも効果があります。
Q. どんな用途で最も効果が出やすいですか？
A. 過去の情報を参照しないと答えにくい用途です。たとえば長期対話、調査エージェント、長文 QA、社内ナレッジ探索、継続支援型のアシスタントなどです。逆に単発 FAQ だけなら、通常の RAG で十分なこともあります。
Q. 実装時に一番注意すべき点は何ですか？
A. メモリに何でも保存しないことです。重要度判定が甘いと working context がノイズで埋まり、検索回数も増えます。保存ポリシー、検索ポリシー、要約ポリシーを分けて設計するのが重要です。
今日の学び
この論文は、LLM の固定長コンテキストが長期対話や長文読解で足りなくなる課題を扱いました。
それに対して、MemGPT はコンテキストを RAM、外部ストレージをディスクのように扱い、LLM 自身に検索・保存・呼び戻しをさせることで解こうとしました。
そこから得られるヒントは、AI アプリの記憶力はモデルサイズだけで決まるのではなく、メモリ構造と検索ループの設計でも大きく伸ばせるということです。