AIエージェントの解説を読んでいると「メモリ」という言葉が当たり前のように出てきます。
ただ、これがコンテキストウィンドウと何が違うのかは、案外つかみにくいところではないでしょうか。
どちらも「覚えている量」の話に見えるのに、実装の世界ではまったく別の層として扱われています。
そこで、公開されている論文と実装ドキュメントを手がかりに、短期記憶と長期記憶がどこで線引きされているのかを整理してみました。
出発点はコンテキストウィンドウの限界
前提として、言語モデルが一度に読める文字数には上限があります。
会話が長くなれば古い発言から押し出され、モデルは直前のやり取りすら参照できなくなってしまうでしょう。
人との会話にたとえるなら、五分前に聞いた相手の名前が抜け落ちてしまう状態に近いところです。
MemGPT という研究はこの制約を出発点に置き、論文の冒頭で「限られたコンテキストウィンドウに制約され、長い会話や文書解析での有用性が損なわれている」と課題を述べました。
MemGPT: Towards LLMs as Operating Systems
同論文が持ち出した比喩がオペレーティングシステムの記憶管理です。
OS は速い記憶と遅い記憶のあいだでデータを出し入れし、あたかも広大なメモリがあるかのように見せています。
同じ発想で、必要な情報だけをコンテキストへ運び込む仕組みを作れば、実際の上限より広い記憶を持っているように振る舞えるという主張でした。
コンテキストウィンドウそのものの考え方は、別記事で整理してあります。
短期記憶と長期記憶を分ける線
実装側の定義はもっと素っ気なく、境界は「スレッドをまたぐかどうか」の一点でした。
LangChain のドキュメントでは、短期記憶をセッション内の会話履歴を保持するものと定義し、スレッド単位で状態を保存すると説明しました。
一方の長期記憶は、利用者やアプリケーション単位のデータを会話スレッドをまたいで共有するものと位置づけられています。
Memory overview – LangChain
長期記憶は名前空間とキーで整理され、中身は JSON として保存される作りです。
利用者IDなどを名前空間に含めておけば、別の会話からでも同じ記憶を引き当てられます。
引き当ての手段には意味的な検索も使えるので、ここでベクトルデータベースの話とつながってきました。
短期記憶のほうはチェックポインタと呼ばれる仕組みで会話の状態ごと保存され、同じスレッドを開き直せば読み戻されます。
言い換えると、短期記憶は「いま話している文脈をこぼさないための保存」、長期記憶は「日をまたいで相手を覚えているための保存」です。
長期記憶は一種類ではない
同じドキュメントは、長期記憶をさらに三つに分けています。
一つ目が意味記憶で、利用者の好みや設定といった事実を貯めるものです。
二つ目がエピソード記憶にあたり、過去のやり取りそのものを例として残し、次の応答の手本にします。
三つ目は手続き記憶と呼ばれ、エージェントの振る舞いを決めるルールやプロンプトが該当しました。
人の記憶の分類をそのまま借りた整理なので、名前だけを見ると身構えてしまうかもしれません。
この三分類が効いてくるのは、「何を残すか」を決める場面でしょう。
会話をすべて保存すると検索の精度が落ち、逆に絞りすぎると同じ質問を繰り返させることになります。
事実は意味記憶へ、うまくいった応答の型はエピソード記憶へ、と置き場所を先に決めておくと設計は安定するはずです。
最後に
メモリとコンテキストウィンドウの関係は、「入れ物の大きさ」と「出し入れの仕組み」と考えると整理しやすくなります。
入れ物は有限なので、外に置いた記憶を必要なときだけ運び込む——これが MemGPT の比喩そのものでした。
この見方に立つと、コンテキストウィンドウを広げる話と記憶を外に持つ話は、競合ではなく補い合う関係だと分かります。
そして実装上の分かれ目は、スレッドの中で完結するか、スレッドをまたぐかという一点です。
エージェントに「前回の続き」をさせたくなったら、それは長期記憶の設計が必要になった合図と受け取ってよいでしょう。
手順そのものを覚えさせる側の話は、Agent Skills の記事にまとめました。
以上です。
コメントを残す