エージェントのメモリ：7つのタイプ、そして実際にはメモリではないものが2つある

あなたのエージェントにメモリの問題があるわけではありません。エージェントには7つの異なるタイプのメモリが存在します。ほとんどのチームは、そのうちの2つしか構築していません。

まず理解すべきことは、モデルは何一つ覚えていないということです。LLMは純粋関数です。入力を受け取り、出力を返します。呼び出し間で状態を保持することはありません。メモリのように感じられるものは、リクエストのたびに履歴を再送しているレイヤーに過ぎません。そのトークン代は、毎回発生します。

ほとんどのエンジニアリングの取り組みは、「会話履歴」と「RAG」という2つのパターンに集約されてしまいます。これらは7つのタイプのうちの2つに過ぎません。問題は何でしょうか？ それらは、エージェントを時間の経過とともに賢くすることはないのです。

以下が7つのメモリのタイプです：

• Working（ワーキングメモリ）：現在のコンテキストウィンドウ内にあるすべて。 • Semantic（意味メモリ）：事実、好み、ドメイン知識。 • Episodic（エピソードメモリ）：過去の出来事のログ、および何が成功し何が失敗したかの記録。 • Procedural（手続きメモリ）：スキル、ワークフロー、ツールのパターン。 • Retrieval（検索メモリ）：類似性検索による知識の引き出し。 • Parametric（パラメトリックメモリ）：モデルの重みに組み込まれた知識。 • Prospective（展望メモリ）：将来の意図やスケジュールされたタスク。

このうちの2つは、本当の意味でのメモリではありません。RAGは単なるデリバリーメカニズムです。それは配管（plumbing）であって、水そのものではありません。データをストレージからワーキングメモリへと移動させるだけです。ベクトルデータベースだけを使っているなら、あなたはパイプを作っただけで、中身の液体を忘れているのです。

本当に学習するエージェントを構築するには、「統合ループ（consolidation loop）」が必要です。これは、エピソードメモリを意味メモリへと変換することを意味します。

プロセスは以下の通りです：

  1. エージェントがある出来事を経験する（Episodic）。
  2. エージェントが同じパターンを何度も繰り返すのを目にする。
  3. エージェントがそのパターンを永続的なルールへと抽象化する（Semantic）。

これにより、エージェントは12個の例から推論する必要がなくなります。単に1つの事実を適用するだけで済むのです。

構築の優先順位の付け方：

  • ワーキングメモリを予算として管理する。これは最もコストがかかる部分です。早い段階で要約や破棄（eviction）を活用してください。
  • ストレージを分離する。事実、出来事、ルールはそれぞれ異なる場所に保管してください。
  • 展望メモリにはスケジューラを使用する。特定の日時に実行する必要があるものにベクトルストアを使用しないでください。
  • パラメトリックメモリには明確な境界線を引く。推論にはモデルを使用しますが、金利や製品ルールのような変動しやすいデータには独自のストレージを使用してください。

今日のエージェントの多くは、単なるコンテキストウィンドウとベクトルDBの組み合わせに過ぎません。勝利するエージェントとは、昨日の失敗を明日のルールに変えることができるエージェントなのです。

Source: https://dev.to/shudiptotrafder/agent-memory-7-types-and-2-of-them-arent-memory-6oi

Optional learning community: https://t.me/GyaanSetuAi