PaperlayerView exact revision on arXiv

Source-linked AI summary

EvolveMem:Self-Evolving Memory Architecture via AutoResearch for LLM Agents

Jiaqi Liu, Xinyu Ye, Peng Xia, Zeyu Zheng, Cihang Xie, Mingyu Ding, Huaxiu Yao

arXiv:2605.13941v1cs.LGcs.AI

TL;DR

Existing memory systems keep retrieval infrastructure fixed even as stored knowledge and query types change. EvolveMem uses LLM-driven closed-loop diagnosis to evolve retrieval configurations, outperforming the strongest baselines by 25.7% on LoCoMo and 18.9% on MemBench.

  • Problem

    Existing memory systems keep retrieval configurations fixed despite changing memory stores and question types requiring different retrieval strategies.

  • Method

    EvolveMem autonomously evolves a structured retrieval action space through LLM-driven failure diagnosis, targeted changes, empirical validation, and guarded reversion.

  • Results

    25.7% relative improvement over the strongest published baseline on LoCoMo and 18.9% relative improvement over the strongest baseline on MemBench, with positive cross-benchmark transfer.

  • Takeaways & Limitations

    EvolveMem’s self-evolution discovers effective retrieval strategies from a minimal starting point without manual tuning and can introduce new configuration dimensions.

  • Takeaways & Limitations

    Robustness remains the weakest MemBench dimension because some relevant memories are absent from the store, a coverage limitation retrieval adjustments cannot resolve.

Abstract

from arXiv · show

Long-term memory is essential for LLM agents that operate across multiple sessions, yet existing memory systems treat retrieval infrastructure as fixed: stored content evolves while scoring functions, fusion strategies, and answer-generation policies remain frozen at deployment. We argue that truly adaptive memory requires co-evolution at two levels: the stored knowledge and the retrieval mechanism that queries it. We present EvolveMem, a self-evolving memory architecture that exposes its full retrieval configuration as a structured action space optimized by an LLM-powered diagnosis module. In each evolution round, the module reads per-question failure logs, identifies root causes, and proposes targeted configuration adjustments; a guarded meta-analyzer applies them with automatic revert-on-regression and explore-on-stagnation safeguards. This closed-loop self-evolution realizes an AutoResearch process: the system autonomously conducts iterative research cycles on its own architecture, replacing manual configuration tuning. Starting from a minimal baseline, the process converges autonomously, discovering effective retrieval strategies including entirely new configuration dimensions not present in the original action space. On LoCoMo, EvolveMem outperforms the strongest baseline by 25.7% relative and achieves a 78.0% relative improvement over the minimal baseline. On MemBench, EvolveMem exceeds the strongest baseline by 18.9% relative. Evolved configurations transfer across benchmarks with positive rather than catastrophic transfer, indicating that the self-evolution process captures universal retrieval principles rather than benchmark-specific heuristics. Code is available at https://github.com/aiming-lab/SimpleMem.

1 Introduction

EvolveMem addresses the mismatch between evolving memory contents and frozen retrieval infrastructure by autonomously optimizing retrieval through LLM-driven diagnosis. Its self-evolution improves performance substantially and transfers positively across LoCoMo and MemBench.

  • Motivation: Persistent memory supports long-running agents, but existing systems generally let stored content evolve while keeping retrieval infrastructure fixed.The fixed infrastructure includes retrieval policies and related configuration components that can become mismatched with expanding, heterogeneous memory stores.
  • Motivation: As memories grow and question categories diverge, a retrieval policy calibrated for a small store becomes suboptimal, motivating co-evolution of stored knowledge and retrieval infrastructure.The paper identifies two required adaptation levels: maintaining and consolidating stored knowledge, while also self-adapting retrieval.
  • Method: EvolveMem exposes complete retrieval configuration as a structured action space and uses LLM diagnosis of per-question failure logs to propose targeted adjustments.Its architecture combines a typed knowledge store with lexical, semantic, and structured-metadata retrieval views, while a guarded loop evaluates and applies proposals.
  • Method: EvolveMem replaces manual configuration tuning with an AutoResearch process that autonomously evolves retrieval infrastructure through closed-loop diagnosis.The evolution loop evaluates failures, diagnoses root causes, proposes changes, and guards against harmful updates through automatic reversion.
  • Results: 25.7% relative improvement over the strongest published baseline on LoCoMo and 18.9% relative improvement over the strongest baseline on MemBench demonstrate EvolveMem’s gains.On LoCoMo, the reported improvement is 78.0% relative over the minimal baseline; evolved configurations also transfer positively across benchmarks.

2 Related Work

Prior memory systems evolve stored content while keeping retrieval infrastructure fixed, whereas adaptive retrieval and self-improving-agent research separately demonstrate configurable retrieval and iterative optimization. EvolveMem is presented as the first system to combine content evolution with self-evolving retrieval infrastructure through AutoResearch.

  • Memory systems for LLM agents: Persistent-memory systems span episodic buffers, tiered memory, forgetting mechanisms, entity-aware summaries, knowledge graphs, memory networks, and reusable memory skills.Examples include Reflexion, Generative Agents, MemGPT, MemoryBank, SCM, Mem0, A-MEM, and MemSkill.
  • Memory systems for LLM agents: SimpleMem, SeCom, and RMM improve retrieval quality through semantic compression, topic-level segmentation, and reflective refinement, respectively.LongMem and MemoryLLM instead embed long-term knowledge directly into model parameters.
  • Memory systems for LLM agents: Existing memory systems evolve stored content but keep retrieval infrastructure frozen.This is the central limitation that motivates EvolveMem.
  • Adaptive retrieval: Adaptive-RAG methods adjust retrieval timing, content, quality checking, confidence triggers, or query routing, while database tuning and index optimization show automatic parameter optimization from workload statistics.The cited approaches include Self-RAG, CRAG, FLARE, Adaptive-RAG, LLM-powered database tuning, and reinforcement-learning-based index optimization.
  • Adaptive retrieval: EvolveMem is presented as the first to combine content evolution with self-evolving retrieval infrastructure via AutoResearch.The comparison distinguishes content evolution, policy/parameter evolution, typed memory, consolidation, and offline evaluation.
  • Self-improving agents and AutoResearch: Self-improving-agent research has explored self-play, iterative refinement, evolutionary optimization, expanding skill libraries, reusable trajectory insights, and experience-driven evolution loops.Related work also includes SkillRL, MemRL, and Memory-R1 for skill augmentation or reinforcement learning applied to memory operations.

3 EVOLVEMEM

EvolveMem treats retrieval infrastructure as a first-class, evolving optimization target alongside the memory store. Its architecture combines structured memory construction, multi-view retrieval, configurable answer generation, and an LLM-driven feedback loop that diagnoses failures and validates adjustments.

  • AutoResearch principle: EvolveMem automates research over retrieval configurations by observing behavior, diagnosing failures, proposing architectural changes, and empirically validating them.This replaces hand-tuned parameters frozen at deployment with a self-evolution process.
  • Memory layer: The memory layer builds a structured knowledge base supporting multi-view retrieval through typed representations, conversation extraction, and store-quality maintenance.Memory units include content, embeddings, six-category types, and auxiliary metadata; extraction uses sliding windows and retry mechanisms for failed LLM calls.
  • Retrieval configuration: Three retrieval views independently generate candidates: BM25 for lexical matching, dense-embedding cosine similarity for semantic matching, and metadata filtering by entities, locations, and persons.Candidates are fused using SUM, WEIGHTED-SUM, or RRF, then ranked with importance, recency, and entity-reinforcement signals.
  • Retrieval configuration: Optional entity-swap and query-decomposition mechanisms extend retrieval, while answer generation supports configurable styles, verification, and per-category parameter overrides.Entity-swap re-searches by topic after removing detected person names, whereas decomposition splits multi-hop questions into single-hop sub-queries merged by RRF.
  • Self-evolution loop: The evolution loop uses failure logs and LLM diagnosis to update configurations, reverts regressions to the best-so-far setting, and perturbs stagnant configurations to explore new regions.Parameter updates are clamped to valid ranges; regression recovery is triggered by performance drops exceeding τrev, while stagnation across two rounds triggers random exploration.

4 Experiments

Experiments on LoCoMo and MemBench show that EVOLVEMEM’s autonomous retrieval self-evolution substantially improves performance over baselines across backbones. Trajectory, transfer, and ablation analyses indicate that diagnosis-driven, multi-component retrieval changes provide complementary and generalizable gains.

  • LoCoMo results: 25.7% relative: EVOLVEMEM reaches 0.543 overall F1 on LoCoMo GPT-4o versus SimpleMem’s 0.432.On GPT-5.1, EVOLVEMEM leads across all columns with a 36.8% relative gain over SimpleMem.
  • MemBench results: 18.9% relative: EVOLVEMEM exceeds the strongest MemBench baseline on GPT-4o, while the GPT-5.1 relative gain is 11.0%.Overall accuracy is 67.9% on GPT-4o and 71.4% on GPT-5.1; gains include +40.0% in Recall and +33.4% in Reasoning on GPT-4o.
  • Self-evolution trajectory: Every evolution round autonomously analyzes per-question failure logs and proposes validated configuration changes, progressively activating semantic retrieval, entity-swap, and query decomposition.The diagnosis module also tunes fusion modes, view weights, and other retrieval settings.
  • Cross-benchmark transfer: 54.3%: A LoCoMo-evolved configuration achieves this MemBench score zero-shot without MemBench-specific tuning, supporting transfer of generalizable retrieval principles.The transfer study continues evolution on MemBench and compares against a configuration evolved there from scratch.
  • Ablation analysis: −23.22 F1: removing extraction guards is the most damaging ablation, while removing semantic search, BM25, or structured metadata causes drops of −10.32, −6.87, and −2.33.Replacing diagnosis with random perturbations costs −9.63 F1, and discovered dimensions jointly contribute −7.77 F1.

5 Conclusion · A Detailed Formulations · B Complete Algorithm Pseudocode

EvolveMem autonomously evolves retrieval infrastructure through LLM-driven diagnosis, achieving substantial relative gains on LoCoMo and MemBench from a minimal starting point. The appendices formalize its memory, retrieval, and self-evolution components, including adaptive retrieval paths, verification, extraction repair, and convergence controls.

  • 5 Conclusion: 25.7% relative improvement over the strongest published baseline on LoCoMo, including 78.0% over the minimal baseline.On MemBench, EvolveMem exceeds the strongest baseline by 18.9% relative.
  • 5 Conclusion: The self-evolution process autonomously discovers effective retrieval strategies from a minimal starting point without manual tuning.It uses LLM-driven closed-loop diagnosis to evolve the retrieval infrastructure.
  • A Detailed Formulations: The appendix formally specifies EvolveMem’s memory store, retrieval layer, and self-evolution engine.These formulations follow the organization of the main paper and expand its prose descriptions mathematically.
  • A Detailed Formulations: Hierarchical scope identifiers support multi-user and multi-workspace deployment, while base scopes enable cross-session retrieval within a user-workspace context.The base scope strips the session component so memories from different sessions remain jointly retrievable.
  • A Detailed Formulations: Coverage-gap-triggered re-extraction closes the feedback loop by augmenting the memory store when diagnosis identifies missing keywords.The mechanism addresses failures caused by missing memories rather than retrieval configuration alone.
  • A Detailed Formulations: The retrieval formulation includes keyword, semantic, and structured views, plus optional entity-swap and query-decomposition paths.Entity swapping handles misleading person names, while decomposition creates up to Nsub sub-queries for multi-hop questions; both capabilities are configurable.
  • A Detailed Formulations: Answer generation can use configurable styles and an optional verification pass that reviews low-confidence or Unknown predictions.Verification is controlled by enable_answer_verification and a self-reported confidence threshold τver.
  • A Detailed Formulations: The evolution loop terminates using ϵ = 0.005 (0.5 pp) by default and returns θ⋆= arg max0≤r≤R fr.The convergence criterion selects the best configuration observed across evolution rounds.

C Extended Experimental Results · C.1 Case Study: Iterative Refinement on an Open-Domain Aggregation Question

The case study traces EvolveMem improving an open-domain aggregation answer through four distinct retrieval and answer-generation refinements. Across broader Cat. 4 evaluations, these iterative changes reduce failures and raise performance.

  • C.1 Case Study: Iterative Refinement on an Open-Domain Aggregation Question: The probe asks what Melanie and her family did while camping, requiring retrieval of the correct episode and enumeration of all relevant activities.The reference answer is “explored nature, roasted marshmallows, and went on a hike.”
  • C.1 Case Study: Iterative Refinement on an Open-Domain Aggregation Question: 0.00 → 0.44 → 1.00 → 0.94 → 1.00: F1 changes across four configuration updates without saturating after the first jump.The trace assigns successive mechanisms to recall, precision, safety, and polish.
  • C.1 Case Study: Iterative Refinement on an Open-Domain Aggregation Question: The diagnosis module identified the exact camping-trip-versus-Perseid-meteor-shower failure from the per-question log alone, without benchmark-specific cues.This demonstrates targeted diagnosis of the case’s retrieval error.
  • C.1 Case Study: Iterative Refinement on an Open-Domain Aggregation Question: The revert guard restored the best-so-far configuration after R3’s wording-only regression, where a missing connector cost 0.06 F1 rather than reflecting a content failure.The subsequent Cat. 4 answer-style override mandated explicit list connectors and restored the connector.
  • C.1 Case Study: Iterative Refinement on an Open-Domain Aggregation Question: 26 → 12 → 11 → 16 → 9 zero-F1 cases: across 70 Cat. 4 probes, iterative changes raised per-sample F1 from 0.350 at R0 to 0.520 at R4.The R3 increase reflects the revert artefact illustrated in the case trace.
  • C.1 Case Study: Iterative Refinement on an Open-Domain Aggregation Question: 41.0% → 49.6% Cat. 4 performance: across the full 10-sample evaluation, aggregate performance increased by +8.6 percentage points through the evolved trajectory.The population-level trajectory extends the iterative-refinement pattern beyond the single probe.

D Implementation Details · D.1 SQLite Schema · D.2 Embedding Models

The implementation uses a version-6 SQLite memory store with FTS5 indexing, WAL-mode operation, and an append-only mutation audit log. It supports deterministic hashing and BAAI/bge-base-en-v1.5 sentence-transformer embeddings, with all experiments using the latter.

  • D.1 SQLite Schema: SQLite 3.35+ with FTS5 support underpins the version-6 memory store schema.
  • D.1 SQLite Schema: The primary memories table stores identifiers, scoped content, metadata, embeddings, lifecycle fields, and supersession information.
  • D.1 SQLite Schema: The memories_fts virtual table indexes content, summary, entities, and topics for efficient full-text search.
  • D.1 SQLite Schema: An append-only memory_events log records all mutations, while the database runs in WAL mode with normal sync and foreign keys enabled.
  • D.2 Embedding Models: HashingEmbedder deterministically produces d=64 ℓ2-normalized vectors via SHA-256 token hashing without external dependencies.
  • D.2 Embedding Models: SentenceTransformerEmbedder uses BAAI/bge-base-en-v1.5 to produce 768-dim vectors, with batch encoding size 32 for efficient hybrid retrieval.
  • D.2 Embedding Models: All experiments use SentenceTransformerEmbedder rather than HashingEmbedder.

D.3 Efficiency Analysis

EvolveMem’s retrieval is interactive at inference time, while its seven-round self-evolution requires 25–35 minutes per LoCoMo sample, primarily for QA evaluation. Storage overhead remains low, with reproducibility supported by persistent configuration and result artifacts.

  • Self-evolution overhead: 25–35 min is required for a full seven-round evolution on one LoCoMo sample, dominated by QA evaluation LLM calls.Each round includes approximately 5 seconds of index building, 15–20 minutes of QA evaluation, and 15 seconds of diagnosis; convergence detection stops at metric plateaus.
  • Retrieval latency: 15 ms is the average per-query retrieval latency across semantic, BM25, structured, and entity-swap retrieval views.Building indices over approximately 900 memories takes approximately 5 seconds.
  • Answer verification: 2–3 s is added per question when answer verification is enabled because it requires one extra LLM call.
  • Storage and reproducibility: Under 5 MB of SQLite storage is added per 1,000 memory units, while extracted memory caches average 150 KB per LoCoMo sample.Runs persist per-round configurations, raw question-level results, summaries, and the best-so-far configuration snapshot alongside versioned code.

E Reproducibility · F Prompt Catalog

The paper provides a lightweight, reproducible implementation and documents every prompt used for extraction, retrieval expansion, answer generation, verification, and self-evolution. The catalog specifies conditional invocation, task-specific output constraints, and a discovered six-subtype LoCoMo inference adapter.

  • E Reproducibility: The implementation requires only Python’s standard library and SQLite, with sentence-transformers and an LLM API available as optional dependencies.The code is distributed as a Python package.
  • E Reproducibility: Experiments ran on a single Apple M-series CPU machine; GPT-5.1 handled extraction and diagnosis, GPT-4o generated answers, and self-evolution remained CPU-only.The memory system itself required no GPU.
  • E Reproducibility: Default evolvable hyperparameters were selected using a held-out validation set of 2 LoCoMo samples and fixed for all reported results.Valid ranges are listed in Table 7.
  • F.1 Extraction: Sliding-Window Memory Extraction: Extraction runs once per sliding window S(j) of W=40 turns, using the previous window’s extraction tail as context to avoid duplication.The extraction prompt requires complete, disambiguated, lossless, detail-preserving structured entries.
  • F.2 Retrieval Expansion: Query Decomposition: Query decomposition is conditional on enable_query_decomposition and splits a question into 1–{max_n} single-hop sub-questions, while preserving already single-hop questions.{max_n} is bound to decomposition_max_subqs.
  • F.3 Answer Generation: LoCoMo: LoCoMo answer generation includes shared grounding instructions, category-specific branches, strict answer formatting, and a discovered nuanced-inferential adapter with six subtypes.The adapter is gated by locomo_cat3_inferential_nuanced and routes questions using a regex classifier.
  • F.4 Answer Generation: MemBench (MCQ): MemBench prompts require selecting exactly one letter from A/B/C/D based on memory context and returning JSON.If context is incomplete, the prompt still requires the most plausible option.
  • F.5 Answer Verification (Second Pass): Answer verification is conditional on enable_answer_verification and can replace unknown responses, normalize formatting, or compare 2-3 candidate answers.The strict verifier keeps answers concise, while the multi-candidate variant selects the best candidate.

F.6 Diagnosis: LLM-Powered Failure Analysis

The diagnosis engine runs once per evolution round, reading per-question raw logs and structured evaluation summaries to convert failures into a concrete next-round configuration proposal. It uses failure patterns, category weaknesses, and disabled-lever symptoms to prioritize targeted retrieval or extraction adjustments.

  • Diagnosis workflow: Once per evolution round, the diagnosis engine reads the per-question raw log and returns a structured next-round proposal.The proposal is generated from evaluation failures in the self-evolving memory system.
  • Diagnosis inputs: The prompt supplies benchmark statistics, the current JSON configuration, failure summaries, category breakdowns, worst-case examples, and disabled-lever checklists.Inputs include overall F1, zero-score count, sample failures, and levers still OFF in the incumbent configuration.
  • Action selection: The decision rubric maps failure patterns to targeted actions, such as widening retrieval for abstentions, reducing context for wrong answers, or enabling temporal decay for temporal weaknesses.The checklist dynamically lists disabled levers whose symptoms appear in current failure data and recommends selecting one item per round until the list is empty.
  • Structured proposal: The structured output records root causes, missing topics, parameter and extraction suggestions, per-category proposals, and prioritized actions.Example suggestions include RRF fusion, semantic_top_k 15, window_size 30, and enabling entity swap for category 5.
Loading 2605.13941v1…