エージェントのメモリは、実はIR（情報検索）の問題だ。清華大学のQingyao Ai氏による、そんな問題提起のパースペクティブ論文です。 タイトル: Agentic Memory Management Is the Next Frontier of Information Retrieval URL: 🧠 概要 IRは「検索結果を読むのは人間」という前提で発展してきました。しかしエージェントは検索した情報を自分の内部状態として使います。この論文は、エージェントのメモリ管理をAMMとして整理します。 ❓ 解決する課題 エージェントメモリの研究は場当たり的で、人間の心理学から借りた用語が一貫せず、評価も弱いままです。 🧩 提案する枠組み ・constants：事実（内容でマッチ） ・functions：スキルやワークフロー（適用可能性でマッチ） ・operators：好みやスタイル（スコープでマッチ） 追加・更新・削除・検索・利用の5操作を、学習・忘却・利用にまとめます。RAG、MemGPT、Mem0なども分類し、再利用可能なスキルや原理的な忘却が手薄だと指摘しています。 🔭 今後の課題 ・3層を網羅し忘却も測るベンチマーク ・下流タスクの成果で診断できる「観測可能性の反転」 ・メモリポイズニングなど人間による制御とセキュリティ 実験はなく、枠組みと推測を示す論文です。 #AgentMemory# #情報検索#

エージェントの「記憶」は、どう設計すればいいのでしょうか。Anthropicは、人間の睡眠中の記憶固定になぞらえた「ドリーミング」という考え方を示しました🧠 The components of agent memory ❓ メモリはどんな層でできているの？ 💡 下から、全記録のトランスクリプト、作業中に書くメモリノート、wikiなどの構造化された表現、毎セッション自動で読み込まれる小さな注入コンテキストです。注入層は誤りも毎回持ち込むため、インデックス程度に小さく保ちます。 ❓ ドリーミングって何？ 💡 セッション間にオフラインで下位層を読み、上位層を更新する統合処理です。トランスクリプトと照合してノートの誤りを直し、重複を統合し、重要なものを昇格させます。Pokémon RedのMt. Moonでは、誤ったノートを直した後でCerulean Cityに到達しました。 ❓ 本当に効くの？ 💡 ・CL-Benchで、Opus 5は0.564から0.828に向上 ・Stainlessの約35万ファイルでは、wiki単体の正答率がドリーミング2回の13%から128回の48%に上昇 ・wikiと検索の併用で、1問あたり約20,000トークンを節約 ただし多くは単一実行の結果で、効果量は目安として読むべきです。 ❓ 何を書かせるのがいい？ 💡 画面やツールから毎回分かる情報ではなく、戦略や検証済みルールを残させます。「失敗だけ記録せよ」のような固定ルールは、強いモデルほど利得を減らしました。 #AIエージェント# #エージェントメモリ#

エージェントのメモリは、検索を足すより「根拠までたどれる構造」を作るほうが効くのかもしれません🧠 Building Evidence-Grounded Agent Memory with OpenWiki and Graphs LangChainのブログでは、文書をコンパイルしたWiki(OpenWiki)と、その引用から作るエビデンスグラフを組み合わせ、複数文書にまたがる質問への精度を上げています。 注目ポイントは3つです。 📚 原文にハッシュで紐づくWiki Wikiの各記述は根拠となる原文の行とそのハッシュに結びつきます。原文が変わるとモデルを呼ばずに該当クレームにフラグが立ち、そこだけをモデルが見直すため、メモリが自己修正できます。 🔗 引用から作る型付きエッジ cite、supersede、refers_toなどのエッジを、既存の引用や文書内の参照から追加のモデル呼び出しなしで作ります。agentはlocateで起点を見つけ、expandでたどるだけです。グラフの構築は1秒未満でした。 📊 連結質問で精度が約5倍 保険文書111本の合成コーパスで、連結質問の精度は検索の0.10からWikiの0.52へ上がりました。エビデンスグラフを足すと精度は27%向上し、コストは58%下がりました。一方、単純な参照では検索と差がありませんでした。 メモリは、複数ソースにまたがる質問を繰り返す場面で効く、という整理が参考になります。 #AIエージェント# #エージェントメモリ#

🧠 エージェントのメモリは、本当にRAGより「得」なのでしょうか？ タイトル: Memory Tax: Dissecting the Net Value of Agent Memory URL: ❓ 「メモリの純価値」とは？ 💡 素朴なRAGと比べて、メモリが新たに解けたクエリが「benefit」、RAGなら解けたのにメモリが落としたクエリが「tax」です。この差し引きを純価値として分解して測ります。 ❓ 結果はどうだったのでしょう？ 💡 10のメモリシステムを3つのベンチマークで比べると、tax が benefit を上回るものが多くありました。LongMemEval-sでRAGが90.0のとき、MemoryOSは80.0、MAGMAは76.0、OpenVikingは63.0でした。 ❓ なぜ tax が生まれるのですか？ 💡 理由は3つあります。 ・構築中に事実が落ちる（OpenVikingでは38.0%の事実に対応するメモリ単位がありません） ・構築後にクエリと証拠の類似度がずれ、取り出しにくくなる ・構築と回答でバックボーンを替えると、RAGより性能が大きく揺れる ❓ では、どう設計すればよいですか？ 💡 メモリだけに頼らず、生の履歴からも検索して一緒にリランクする設計が提案されています。過去のクエリと検索経路を再帰的にメモリ化する案もあります。 #AIエージェント# #RAG#

エージェントの記憶は、アプリのコードを複雑にするのではなく設定を詰めることで効くようになる。Weaviateの実践ガイドです。 タイトル: Agent Memory with Engram: A Practical Guide URL: 会話データを投げて検索するだけの状態から、記憶の質とトークンコストを同時に最適化するところまで引き上げる手順が解説されています。 注目ポイントは3つあります。 📝 トピックの記述は「除外」で書く 記憶のカテゴリごとに書く説明文が、そのまま抽出プロンプトとして働きます。記憶してほしい例を列挙するより「イベントや一時的な状態は記録しない」といった除外ルールを1つ置くほうが、想定外のケースにもうまく汎化したと報告されています。出力の形を原子的な事実にするか散文にするかも、ここで明示します。 🔒 単数の事実はboundedで固定する boundedを設定すると1スコープあたり記憶が最大1件に制限され、累積ではなく更新されます。新規ユーザー5人での検証では、boundedなUserProfileが5回すべてでちょうど1件を保った一方、boundedでないUserKnowledgeは毎回2〜4件に揺れました。 💰 記憶の置き場所が課金額を決める 検索結果は毎ターン変わるため、システムプロンプトに貼るとキャッシュが毎回壊れて全体が課金されます。常時必要な記憶はセッション開始時に一度取得してシステムプロンプト直後へ、検索結果はユーザーメッセージの後ろへ置くのが正解です。25ターンの検証では、最終リクエスト約3,500トークンのうちキャッシュ未ヒットは約100トークンだけに収まりました。 記憶レイヤーを自前で書くか委ねるかを検討しているなら、判断材料としても読み応えがあります。 #AIエージェント# #メモリ管理#

AIエージェントの「記憶」機能、過去の作業履歴だけを見て学習させると、間違った知識を覚え込んでしまうことがあります。それを防ぐ賢い工夫を紹介します。 タイトル: Grounding Agent Memory: Environment-Probing Curation for Enterprise Agents URL: ❓ 従来のエージェント記憶の何が問題だったの? 💡 完了した作業履歴だけを見て記憶を作ると、1回のたまたまの観察から間違った一般化をしたり、データベースのスキーマが変わった途端に記憶が使えなくなったりしていました。 ❓ この論文はどう解決するの? 💡 記憶を保存する前に、エージェントに読み取り専用で実際の環境を「プロービング（探査）」させ、保存しようとしている知識が本当に正しいかを検証してからコミットする仕組みを提案しています。 ❓ 効果はどれくらいあるの? 💡 データベース探索タスクでは合格率が39%から73%に向上し、報酬は約2.6倍に。しかもツール呼び出し回数は47%減、コストも約50%削減できています。 ❓ 実運用でも使えそう? 💡 モデルの再学習が不要で、タスク実行時のインターフェースも変えずに導入できるため、企業で長期運用するエージェントにそのまま組み込みやすい設計になっています。 #AIエージェント# #エージェントメモリ#