An Invisible Bug
You gave your AI assistant a memory system. It diligently stored thousands of memories—your preferences, schedules, project details, that bug you mentioned last time. Then one day you inspect the logs and discover something eerie: 54% of key memories, from the moment they were stored until they were forgotten, were never retrieved even once.
Not because they were unimportant. Not because the system judged them useless. But because the retriever—the component that picks relevant memories—never gave them a chance to appear.
It's like writing a 1,000-page autobiography but only indexing the first 500 pages. The second half isn't worthless; nobody has ever flipped to it.
Stranger still: no existing memory management system can detect this bug.
Why "Looks Like Measurement" Isn't Measurement
How does a memory system judge whether a memory is useful? The standard approach is A/B testing: add memory m, measure task performance; remove m, measure again. A big difference means m is useful; a small difference means it isn't.
The problem is the retriever. With thousands of memories, the retriever selects only the few most relevant (say, 6) to feed the LLM. If memory m is never selected:
- Adding m → retriever still doesn't pick it → context unchanged → same answer
- Removing m → retriever never picked it anyway → context unchanged → same answer
- Averaging: diluted (a useful-in-1-of-30-queries memory averages near zero)
- Taking the max: nearly every memory helps some query, so everything is kept
- Weighting by future query similarity: requires knowing future queries at decision time
- Cold-start in recommender systems: an item never recommended → no clicks → judged "unpopular" → never recommended. Isomorphic.
- Survivorship bias in A/B tests: only exposed variants get data; CMP's solution mirrors exploration strategies.
- Uncited papers in science: never found → no citations → low impact → even harder to find.
Both experiments produce identical results. You conclude: "m is useless, delete it." But m may be extremely important—it simply never got on stage.
In causal inference terms, this is a positivity violation: identifying a causal effect requires every unit to have nonzero probability of receiving each treatment. When retrieval is deterministic, a never-retrieved memory has zero treatment probability—its utility is not identifiable.
More insidiously: non-identifiability doesn't return "unknown"; it returns "near zero." Identical A/B results push the estimate toward zero, which is observationally indistinguishable from a genuinely useless memory. The system confidently makes wrong judgments.
What the Paper Does
Causal Memory Policy (CMP)'s core insight: since the problem is the retriever, randomize the retriever itself:
1. Each query has B context slots (e.g., 6) 2. B−k slots go to the normal relevance-ranked retriever 3. The remaining k slots (e.g., 2) are assigned to randomly selected memories 4. Each memory's causal utility is estimated with inverse propensity weighting (IPW)
The key: randomize the retrieval step, not the memory pool. Prior methods randomize the pool (randomly keep/delete memories), but if a randomized memory would never be retrieved anyway, the perturbation has no effect—52.2% of such perturbations produce identical retrieval results. CMP randomizes retrieval outcomes directly, so every memory has a known nonzero probability of entering the context. Positivity holds by construction.
An Elegant Design Choice
Naively drawing k memories independently each time has problems: over T=90 rounds with k=2 and a pool of 32, some memories would be sampled fewer than 5 times—or not at all.
CMP uses balanced allocation: T×k exposure slots are distributed as evenly as possible across all memories, each appearing exactly 5 or 6 times, with fixed, known propensity scores.
This makes the estimator remarkably simple: because n_m is fixed, IPW degenerates into a difference of two group means with exactly computable variance—no propensity estimation needed.
Good causal design makes estimation simpler, not more complex.
The Data
Validated on LongMemEval, LoCoMo, and Mem0:
| Metric | Value | |------|------| | Key memories never retrieved (LongMemEval) | 54% | | Key memories never retrieved (LoCoMo) | 67% | | Median rank of unretrieved evidence in Mem0 | 139/291 | | Pool randomizations producing identical retrievals | 52.2% | | Utility-based deletion vs random deletion | 0.97x (≈ random) |
CMP's results:
| Design | AUC | Key-memory deletions per 100 | |------|-----|------| | Pool randomization | 0.542 | 10.9 | | CMP (retrieval randomization) | 0.664 | 5.2 | | CMP + per-query estimation | 0.784 | — |
The most striking result: task accuracy stays around 0.2 until all required memories are retrieved, then jumps to 0.73. Partial retrieval is nearly useless—these tasks need all supporting memories working jointly.
An Honest "Failure"
The most respectable part: even with identified utility, that's insufficient to decide retention vs deletion.
Why? Memory utility is query-dependent. The same memory may be vital for query A and worthless for query B. CMP achieves 0.784 AUC on the query it estimates, but aggregating utility into a scalar for retention decisions fails:
On LoCoMo's disjoint half, no query-independent aggregation achieves correlation r>0.10, while ground truth itself only reaches r=0.286—a structural limit of the estimation target, not an accuracy problem.
The paper's conclusion is refreshingly honest: CMP is an identified measurement tool, not a retention policy. It tells you "this memory helps this query," but not "should this memory be kept."
Engineering Insights
1. Check your retrieval coverage. With 54% of key memories never retrieved on LongMemEval, your system may be worse. Simplest diagnostic: count retrieval frequency per memory. If many are never retrieved, your utility-based retention policy is blindly deleting useful memories.
2. Memory-pool randomization is ineffective. If you estimate utility by randomly deleting memories, 52.2% of experiments are wasted—the retriever doesn't change. You must randomize retrieval outcomes.
3. Irreversible operations need one-sided thresholds. The Bayes-optimal rule deletes only when estimated utility is sufficiently negative, not when |utility| is large. Forgetting is irreversible—the cost of wrongly keeping is far below the cost of wrongly deleting.
4. Estimate per query, not per memory. Utility varies enormously across queries. Retention policies based on "overall usefulness" will err on memories useful for only 1/30 of queries.
Cross-Domain Analogies
Closing Thoughts
AI systems' "invisible bugs" are often not implementation errors but cognitive blind spots at the design level. Engineers know retrievers are biased—but they miss that utility-based retention under retrieval bias systematically deletes useful memories, because "never retrieved" and "useless" are observationally indistinguishable.
CMP's approach—randomizing the gate itself—is a paradigm shift: don't improve the retriever or the estimator; insert a randomization layer between retrieval and estimation. This may generalize to all "mediator + evaluation" problems.
---
Paper: arxiv.org/abs/2610.02070 Code: anonymous.4open.science/r/cmp-release-D0C3/ Authors: Behnam, Wang, Binghui One-line summary: When a memory is never retrieved, its utility is unidentifiable—CMP restores identification by randomizing retrieval itself, but identified utility still cannot determine retention policy.