元論文: EvolveMem: Self-Evolving Memory Architecture via AutoResearch for LLM Agents
このページは、おい丸(AI)による要約・構成案をもとに、人間が確認・加筆した合作です。内容を正確に確認したい場合は、元論文もあわせて参照してください。
これは何の論文か
EvolveMem の出発点は、長期記憶システムの見落としにある。多くの記憶システムは、会話ログから記憶を抽出したり、重複をまとめたり、古い情報を整理したりする。しかし、検索の設定そのものは導入時に決めたまま固定されることが多い。
これは、エージェントが長く動くほど苦しくなる。記憶が数十件から数百件へ増え、質問も事実確認、時間推論、複数段階推論、名前入れ替えのように多様になると、同じ検索設定では対応しきれない。EvolveMemは、保存内容と検索基盤の両方が進化するべきだと主張する。
手法の核は、検索設定全体を操作可能な空間として外に出すこと。BM25、意味検索、構造化メタデータ検索、順位融合、文脈予算、回答スタイル、質問分解、人名を外した再検索、回答検証などが、失敗ログを読んだ LLM 診断によって更新候補になる。
ただし、LLM の提案をそのまま信じるわけではない。各ラウンドで評価し、悪化した提案は自動で巻き戻し、停滞したら探索を入れる。著者らはこの閉ループを AutoResearch と呼ぶ。システムが自分自身の検索アーキテクチャを研究対象にして、観測、仮説、実験、検証を回す、という見方である。
結果として、LoCoMo では最強ベースラインを相対 25.7% 上回り、最小構成からは相対 78.0% 改善した。MemBench でも最強ベースライン比で相対 18.9% 改善する。さらに、LoCoMo で進化した設定が MemBench にも正に転移する点が、この論文の読みどころである。
EvolveMemは、LLMエージェントの長期記憶アーキテクチャを、保存内容と検索機構の共進化として設計する論文である。
従来の記憶システムは、記憶内容の抽出、圧縮、統合、忘却を扱ってきた。一方で、どの検索器を使うか、候補を何件取るか、BM25 と意味検索をどう混ぜるか、回答時にどれだけ文脈を入れるか、といった検索基盤は固定されがちだった。
この論文は、その固定設定を問題にする。長期記憶は、保存箱ではなく、質問の種類や失敗ログに応じて読み方を育てる仕組みとして設計されるべきだ、という立場に立つ。
何が問題だったのか
長期記憶システムは、最初に決めた検索設定のままではだんだん詰まりやすい。保存件数が増え、質問の種類が変わり、失敗の形も変わるからだ。
問題は、記憶内容だけを増やしても、検索器、融合方法、文脈予算、回答検証が古いままだと改善しないことにある。どの記憶をどう取るか、複数の候補をどう混ぜるか、回答前に何を検証するかも、運用後に調整する必要がある。
EvolveMem が扱う問題は、長期記憶を保存箱ではなく、失敗ログから検索・融合・検証方針まで自己改善するシステムとして扱うことである。
既存の記憶研究は、保存する内容や検索方法を固定して評価することが多い。しかし長期運用では、質問の種類も失敗の形も変わるため、最初に決めた検索設定だけでは詰まりやすい。
EvolveMem は、記憶内容だけでなく、検索器の組み合わせ、融合方法、文脈予算、回答検証まで改善対象にする。失敗ログを読み、診断し、設定変更を提案し、悪化したら戻す点が差分である。
提案手法の中身
会話ログをスライディングウィンドウで読み、LLM が型つき記憶を抽出する。抽出失敗時のリトライ、長すぎる窓の分割、参照キーワードに対するカバレッジ検証で、記憶ストアの抜けを減らす。
各記憶には、自然言語本文、埋め込み、記憶タイプ、重要度、信頼度、人物や場所、トピック、作成時刻などのメタデータを持たせる。重複統合、重要度の減衰、エンティティ強化も行う。
検索時は、BM25 による語彙検索、埋め込みによる意味検索、人物や場所などの構造化メタデータ検索を別々に走らせる。結果は sum、weighted-sum、RRF のいずれかで融合する。
質問カテゴリに応じて、人名を外した再検索や、複数段階質問の分解検索を使う。回答生成では、簡潔、説明的、検証的、推論的といったスタイルを設定でき、低信頼回答には二段目の検証も入れられる。
評価後、質問、予測、正解、スコア、検索された証拠を含む失敗ログを残す。LLM 診断モジュールがこのログを読み、違う人物を拾った、文脈が足りない、時間の扱いが弱い、といった原因を分類し、設定変更を提案する。
メタ分析器は、提案を評価ラウンドで検証する。悪化すれば巻き戻し、停滞すれば探索、改善が見込める場合だけ変更を適用する。これにより、評価、診断、提案、ガード、再評価の AutoResearch ループが閉じる。
どうやって確かめたのか
評価は、検索設定を自己改善することで、長期記憶タスクの性能がどれだけ上がり、その改善が別ベンチマークへ移るかを見るために組まれている。中心になるベンチマークは LoCoMo と MemBench である。
比較対象は、最小構成の記憶、SimpleMem、EvolveMem、部品を外した除去実験である。モデル条件も GPT-4o と GPT-5.1 で見ており、特定モデルだけの改善かどうかを分けて読む。
測る指標は、LoCoMo の F1、MemBench の精度、進化ラウンドごとの設定変更、悪化提案を巻き戻せたか、どの部品が改善に効いたかである。
結果はどうだったのか
LoCoMo では、GPT-4o 使用時に EvolveMem は全体 F1 0.543 を達成し、SimpleMemの 0.432 を相対 25.7% 上回った。最小構成の 0.305 からは相対 78.0% の改善である。
GPT-5.1 でも EvolveMem は全体 F1 0.572 を達成し、SimpleMemの 0.418 を相対 36.8% 上回った。時間推論、単発検索、オープンドメイン系の改善が特に大きい。
MemBench では、GPT-4o で全体精度 67.9%、GPT-5.1で 71.4% を達成した。GPT-4o では最強ベースラインから相対 18.9% 改善している。
自己進化の軌跡では、R0 の BM25 のみの弱い構成から始まり、R1 で RRF 融合、R3 で entity-swap、R5 でクエリ分解、R7 で回答検証と文脈予算調整が入る。R2 の悪化提案は自動で巻き戻された。
除去実験では、抽出品質管理を外すと F1が 23.22 ポイント落ち、最も大きな影響を持つ。次に意味検索、LLM 診断、BM25 が大きい。検索を育てる前に、必要な記憶がちゃんと保存されていることが土台になる。
ベンチマーク間転移では、LoCoMo で進化した設定を MemBench にそのまま適用しても 54.3% を出し、さらに MemBench で継続進化すると 79.2% に上がる。しかも LoCoMo 側も 0.543から 0.593 に改善しており、正の転移になっている。
限界・注意点
- 関連記憶がそもそもストアに存在しない場合、検索設定だけでは救えない。MemBench の後処理ではこの限界が出ている。
- 評価セットを使って検索設定を進化させるため、評価セットの設計が弱いと、現実の運用に合わない方向へ最適化される可能性がある。
- 診断 LLM が新しい設定次元を提案できる点は強いが、実運用では提案してよい変更範囲を設計しないと、システムが複雑化しすぎる可能性がある。
- 論文の主な評価は LoCoMoと MemBench であり、コードベース探索、個人 wiki、実作業ログのような環境にそのまま転移するかは別途検証が必要である。
おい丸のようなエージェントにどう使えるか
おい丸のような作業支援エージェントでは、記憶の中身だけでなく、どの記憶をどう検索し、どう混ぜ、どの文脈予算で使うかも運用対象になる。
EvolveMem 的に見るなら、記憶検索の失敗ログを「覚えていなかった」で終わらせない。検索設定、融合、回答検証、文脈予算のどこが悪かったかを診断し、悪化したら戻せる形で調整する。
Q&A
この論文の中心問いは？
長期記憶システムは、保存内容だけでなく、検索設定や回答方針まで失敗ログから自律的に改善できるのか、という問いである。
どこが重要？
記憶の中身ではなく、記憶の読み方を進化対象にした点。BM25、意味検索、融合、文脈予算、回答検証などを、評価ログに基づいて更新する。
AutoResearch とは？
システムが自分自身のアーキテクチャを研究対象にして、観測、仮説、実験、検証を自律的に回すという考え方である。EvolveMem では検索基盤がその対象になる。
LLM 診断は何を読む？
質問ごとの失敗ログを読む。質問、予測、正解、スコア、検索された証拠を見て、なぜ失敗したかを分類し、設定変更を提案する。
提案が悪かったらどうする？
メタ分析器が評価結果を見て、性能が悪化した場合はベスト設定へ自動で戻す。停滞した場合は探索のための変更を入れる。
一番効いた部品は？
除去実験では、抽出品質管理が最も大きい。必要な記憶がストアに入っていなければ、どれだけ検索設定を育てても答えられない。
RAG のチューニングと何が違う？
単に 上位k件 や重みを調整するだけではなく、質問分解、人名を外した再検索、回答検証、カテゴリ別方針など、検索から回答までの構造も進化対象にしている点が違う。
実務では何に効く？
wiki やエージェント記憶を、ただ増やすだけでなく、失敗ログから検索順、読むファイル、文脈量、検証方法を育てる設計に使える。
限界は？
記憶ストアに関連情報がない場合は検索設定だけでは解けない。また評価セットに合わせて進化するため、評価設計が実運用とズレると危ない。
一言でいうと？
記憶は DB ではない。失敗から『どう読むか』まで育つハーネスとして設計できる。
関連する記事
- スキルを構造として管理する と並べると、記憶を保存ファイルではなく、読み込み、適用、忘却、評価、巻き戻しを含むハーネスインターフェースとして見やすくなる。
- 古くなった記憶に気づけるか と並べると、古い記憶を見抜く 現在状態の判定と、検索設定を育てる EvolveMem の関係が見える。片方は記憶の有効性、もう片方は記憶の読み方を扱う。
- grepだけで十分なのか と並べると、検索器単体ではなく、検索手段、結果の渡し方、文脈予算、エージェントハーネスの相互作用として検索性能を見る視点が揃う。
- 作業支援エージェントに引きつけると、記憶検索の失敗を『ルールを足す』だけで処理しない視点が使える。次にどの記憶をどう読み、どの検索設定や文脈予算を変えるべきかまで、評価つきで育てる設計になる。