EvoMem: Memory-Augmented Evolution for Code Optimization

EvoMem is a persistent memory architecture for LLM-based evolutionary program search that captures and reuses candidate mutation knowledge across runs and tasks. It operates in two phases: after each run, it extracts and stores promising ideas with provenance, and during subsequent evolution, it retrieves a small set of relevant instructions based on the current task and program context to guide mutation. The system is implemented as an extension to GigaEvo, an open-source AlphaEvolve-style optimization pipeline.

The write phase runs after an evolution job finishes, extracts generalizable ideas from produced programs, and stores them in a memory store. The read phase runs before each new mutation, retrieves a small set of relevant memory cards, and injects them into the mutation prompt. The design separates expensive operations like clustering, deduplication, and optional LLM-based enrichment to the offline post-run phase, while mutation-time retrieval remains a small bounded step.

The write phase begins from mutation records attached to evolved programs, collecting completed programs, filtering out root programs and invalid outputs, and converting remaining candidates into normalized records containing fitness, generation, parentage, task context, mutation strategy, code, and improvement descriptions. There are two analysis modes: the default mode compares new improvements against a working collection of previously extracted ideas using an LLM to decide whether improvements correspond to genuinely new ideas, revisions, or reformulations; the fast analyzer groups semantically related candidates using DBSCAN over embedding space and asks an LLM to refine ambiguous clusters.

The write pipeline stores two kinds of entries: abstract idea cards describing reusable tactics with provenance and usage statistics, and program cards representing high-performing programs with code and fitness values. A conservative promotion rule favors ideas with identifiable introduction points, improvement over strongest available parents, rare production of worse descendants, and support from additional signals like recurrence across nearby programs or spread into later elite lineages. Deduplication compares incoming ideas against multiple textual views of existing cards using weighted scores, with an LLM decision policy choosing whether to store, discard, or merge new ideas.

During retrieval, EvoMem performs task-scope filtering where an LLM selects potentially relevant source tasks from memory, then ranks memory cards using lexical and embedding-based similarity over several semantic views including mechanism description, task context, and explanations. The retrieval returns a concise advice block inserted into the mutation prompt as a dedicated memory section, plus identities of selected cards recorded for usage tracking. The system limits retrieval to at most 3 cards per mutation with fixed iteration budgets.

The evaluation used Gemini 3 Flash as the LLM backbone and Qwen3-8B for prompt-evolution experiments. The memory-generation set included Circle Packing, Heilbronn-style point placement, Kissing Number (11D), HotpotQA, HoVer, GSM8K, selected AlgoTune tasks, and selected KernelBench kernels. The evaluation set contained related but separate tasks including Circle Packing (26 and 32), Hexagon Packing, Kissing Number (12D), HoVer, HotpotQA, AlgoTune Power Control and Kalman, and KernelBench kernels. When evaluating a benchmark, all memories from that benchmark were excluded from the memory bank, so memory-enabled runs could only retrieve memories from other benchmarks.

Results across benchmarks showed positive average improvements in target metrics or search speed for most evaluated settings. The average gain across benchmarks was 6.40%, with minimum 1.64% and maximum 16.37%. The average speedup was 5.93, with minimum 1.65 and maximum 11.99. Specific results included Circle Packing (32) with 5.21% average gain and 9.26 average speedup, Circle Packing (26) with 5.88% gain and 5.06 speedup, Heilbronn with 3.86% gain and 6.01 speedup, Kissing Number (12D) with 0.00% gain but 6.78 speedup, Hexagon Packing with 3.69% gain and 5.75 speedup, HoVer with 2.42% gain and 2.71 speedup, AlgoTune with 7.90% gain and 8.58 speedup, KernelBench with 16.89% gain and 3.44 speedup, and HotpotQA with 11.79% gain and 5.75 speedup. Kissing Number illustrated an acceleration-only case where final quality was unchanged but memory-enabled runs reached the baseline best score earlier.

Examples of retrieved memory reuse showed that stored memories often expressed transferable execution strategies rather than narrow task-specific tricks. For instance, Circle Packing used force-directed motion and adaptive radius expansion from Heilbronn-style point placement, Hexagon Packing used annealed force-directed repulsion and low-discrepancy initialization, HotpotQA used claim-relevant fact extraction and query-refinement continuity, HoVer used explicit reasoning questions and missing-fact lists, KernelBench used F.conv3d for Conv3D and kept Triton only for fused bias/ReLU, Power Control precomputed scaled coefficients and reused buffers, and Battery Scheduling cached horizon templates and used CSR matrices.

Memory utilization audits showed substantial variation in bank coverage across benchmarks. HoVer had full coverage, Heilbronn retrieved 81.3%, Circle Packing (26) retrieved 69.9%, Hexagon Packing retrieved 64.4%, HotpotQA retrieved 33.3%, KernelBench covered 5.4%, and Kissing Number (12D) showed lowest coverage at 3.3%. An acceptance audit comparing default relevance-based retrieval with random memory selection found that default retrieval achieved a 4.05% acceptance rate versus 0.25% for random memory, meaning a retrieved idea was 16.2 times as likely to be incorporated into the child program. At the program level, at least one retrieved idea was accepted in 9.43% of audited programs under default retrieval versus 0.69% under random memory.

An ablation study on Circle Packing (32) compared full EvoMem with no memory, random memory, generic advice, memory without task filtering, and retrieval-only memory. Full EvoMem attained a mean fitness of 2.9338 ± 0.0044 and closed 97.4% ± 3.6% of the target gap, while no memory closed 0%, random memory closed 5.6%, generic advice closed 53.7%, no task filtering closed 46.2%, and retrieval-only memory closed 18.7% with the largest variance. Even the worst full EvoMem run exceeded the no-memory baseline mean.

Lineage dynamics analysis showed that direct memory-use mutations were more likely to produce valid candidates and had more reproductive output than mutations without retrieved memory. Programs in memory-descended lineages had higher average objective rank, and the strongest memory-descended lineages reached higher average best objective ranks than the strongest non-memory lineages.

The paper concludes that EvoMem provides evidence that persistent memory can reduce some redundant exploration and improve the reuse and adaptation of successful strategies in LLM-driven evolutionary search. The results suggest that some useful mutation knowledge is more general than the single program in which it first appeared, and that strategies discovered in one run can help guide exploration in related and sometimes substantially different domains. The authors suggest that memory should be treated as a first-class component of evolutionary coding systems, capturing reusable design decisions, optimization heuristics, and failure-avoidance patterns.

Limitations include variability across runs due to high-temperature LLM sampling, sensitivity to memory pipeline quality, a relatively small memory bank, fixed memory influence during mutation, and a simple code-evolution setting. Future work should scale memory across more runs and domains, adapt memory reliance to task and population state, study whether persistent memory can reduce the cost of repeated LLM calls and execution, and explore repository-scale evolution where memories may capture project conventions, interface constraints, recurring bug patterns, and cross-file optimization strategies.

Improvements to AI Systems Based on EvoMem:

1. Cross-Task Knowledge Transfer Module – Add a persistent memory layer to any LLM-based optimizer or code generator. After each task, the system extracts reusable tactics (e.g., use force-directed repulsion for packing problems) and stores them with provenance. During new tasks, it retrieves 1–3 relevant tactics via embedding similarity and injects them into the prompt. This improves solution quality by 1.6–16.4% and speeds up search 1.6–12x on related but unseen problems.

2. Adaptive Mutation Guidance for Evolutionary Algorithms – Enhance evolutionary program search with a retrieval-augmented mutation operator. Instead of random mutations, the system queries memory for successful strategies from prior runs (e.g., precompute scaled coefficients or use CSR matrices for sparse data). This increases the acceptance rate of mutations by 16.2x compared to random memory and produces more valid, higher-fitness offspring.

3. Offline Knowledge Distillation Pipeline – Implement a two-phase system: after each run, an LLM clusters, deduplicates, and abstracts successful ideas into idea cards and program cards. During evolution, only a lightweight retrieval step runs at mutation time. This separates expensive LLM calls (clustering, refinement) from the real-time loop, enabling scalable memory growth without slowing down search.

4. Task-Scope Filtering for Relevant Memory – Before retrieving memory, use an LLM to select which source tasks are relevant to the current problem (e.g., this is a packing problem, so retrieve from Heilbronn and Circle Packing). This prevents irrelevant memories from polluting the prompt, improving performance by 46% over no filtering and 18% over retrieval-only systems.

5. Conservative Idea Promotion with Provenance Tracking – Store only ideas that show clear improvement over the strongest parent, rarely produce worse descendants, and appear across multiple lineages. This prevents storing noise or overfit tricks. The system tracks usage statistics (how often an idea is retrieved and accepted) to refine future retrieval ranking.

6. Acceleration-Only Mode for Hard Problems – For tasks where final quality plateaus (e.g., Kissing Number 12D), memory retrieval can be used to reach the baseline best score faster (6.78x speedup) even if it doesn't improve the final optimum. This is useful for time-budgeted runs where early convergence is critical.

7. Memory-Guided Prompt Engineering – The system automatically generates a memory section in the mutation prompt containing concise, actionable advice (e.g., use annealed force-directed repulsion or keep Triton only for fused bias/ReLU). This acts as a dynamic few-shot example bank, improving the LLM's ability to generate domain-specific code without manual prompt tuning.

8. Lineage-Aware Fitness Evaluation – Track which programs descend from memory-influenced mutations. These lineages show higher average objective rank and produce more valid candidates. The system can prioritize these lineages during selection, focusing compute on promising branches.

9. Cross-Domain Strategy Reuse – The memory bank enables transfer of abstract strategies (e.g., adaptive radius expansion from point placement to circle packing, or claim-relevant fact extraction from HotpotQA to HoVer). This allows an AI system to solve new tasks by adapting high-level heuristics rather than starting from scratch.

10. Self-Improving Memory Bank – Over multiple runs, the system accumulates a growing library of proven tactics. With each new task, it refines existing cards (merging, revising, or discarding) via an LLM decision policy. This creates a compounding knowledge base that improves with use, reducing redundant exploration across projects.

Successful mutation strategies in evolutionary code search may contain reusable knowledge that is useful beyond a single run, and in some cases may transfer across related tasks and domains. However, existing LLM-driven evolutionary frameworks largely discard such knowledge, repeatedly rediscovering similar ideas and limiting opportunities for cross-run and cross-task learning. We introduce EvoMem, a persistent memory architecture for LLM-based evolutionary program search that captures and reuses candidate mutation knowledge. EvoMem converts successful mutation events into structured, task-aware advice for future runs. It operates in two phases: after each run, it extracts and stores promising ideas with provenance, and during subsequent evolution, it retrieves a small set of relevant instructions based on the current task and program context to guide mutation. Across geometric optimization, multi-hop question answering, GPU kernel optimization, and related benchmarks, our experiments show positive average improvements in target metrics or search speed for most evaluated settings, while also revealing variability across tasks. Overall, EvoMem provides evidence that persistent memory can reduce some redundant exploration and improve the reuse and adaptation of successful strategies in LLM-driven evolutionary search.