Auditing Forgetting in Limited Memory Language Models

Limited Memory Language Models are pre-trained to hold no facts in their weights and route all factual recall through an external database, so that forgetting is a database operation: delete the row, no retraining. Existing evaluations only check whether the model still answers correctly after deletion, not why. A correct answer could come from residual memory in the weights, from another entry that still names the object, or from near-neighbour rows the model reconstructs from.

This audit holds the model fixed and varies the database at inference time across three states — FULL, DEL-ON, DEL-OFF — and logs the retrieval trace on every call. That decomposes every surviving answer into parametric leakage L(f), retrieval-mediated correctness R(f), or a retrieval artifact A(f), per fact.

Across 12,228 alias-closure deletions, six prompt formulations, and thirteen databases including four adversarial topologies we built, parametric leakage is 0.11 %: the weights have forgotten. What survives lives in the retrieval graph, from 0.7 % on the released LMLM database to 13.6 % on the most adversarial one, and R and A match within rounding everywhere. The unlearning boundary is drawn by the database, not the model. Joint work with Hanna Roed; on arXiv as 2607.00605.

Affiliation

UC Berkeley

Partners

Report

arXiv preprint arXiv:2607.00605

Keywords

Machine Unlearning
Knowledge Editing
Causal Inference
Python
PyTorch
CUDA
LLMs
NLP
Slurm
Weights & Biases

Delete the row, and the fact is gone. Or is it?

A language model that has read the internet knows that Geri Halliwell was a Spice Girl, and there is no clean way to make it un-know that: the fact is smeared across billions of weights. Limited Memory Language Models (LMLMs) are a bet on a different design. Pre-train the model to hold no facts at all, keep every fact as a row in an external database, and route all factual recall through retrieval. Then forgetting is a database operation: delete the row, no retraining.

Two panels. Left, LLM + RAG: a model box of grey weight dots with an orange cluster labelled 'Spice Girls', captioned 'the fact, baked into the weights — delete it from the database, it is still here', next to an external database holding the triplet. Right, LMLM: the same model box with only grey dots, captioned 'pre-trained to hold no facts, every factual recall goes through retrieval', with two-way green arrows to the database. Below: the promise, delete the row and the fact is gone; the question this project asks, is it, though? — Where a fact lives. A retrieval-augmented LLM still carries the fact in its weights; an LMLM (Zhao et al., 2025) is trained not to, so that deleting the database row should be enough.

That promise matters for privacy law, data governance, and model editing, and the LMLM paper reports “ideal forgetting” on its benchmark. But the existing test only checks whether the model still answers correctly after deletion, not why. A correct answer after deletion could come from residual memory in the weights, from another database entry that still names the object, or from near-neighbour rows that are close enough for the model to reconstruct the answer. Aggregate accuracy cannot tell these apart. This project builds an audit that can. Joint work with Hanna Roed at UC Berkeley, on arXiv as 2607.00605.

How it works

Hold the model fixed, vary the database. The audit is a causal intervention at inference time. The weights never change; only two things do: whether the target fact is in the database, and whether retrieval is switched on. That gives three states.

Three panels, FULL, DEL-ON, DEL-OFF. Each shows a database with the Geri Halliwell triplets, a retrieval toggle, a frozen LMLM asked 'What is Geri Halliwell famous for?', and an answer. In FULL the target is present and retrieval enabled, answer Spice Girls. In DEL-ON the target and its alias are struck through, retrieval enabled, answer unknown. In DEL-OFF the target is struck through and retrieval disabled, answer unknown. — The three intervention states. **FULL** is the baseline. **DEL-ON** asks whether the answer can come back through what is left of the database. **DEL-OFF** removes retrieval entirely, so only the parameters can answer.

Deletion means alias closure. Deleting one row is not enough if the same fact is also stored as Ginger Spice → famous for → Spice Girls. For every target, the deletion set is the canonical triplet plus every alias-equivalent triplet, and the audit verifies that nothing gold-equivalent survives before asking a single question.

Three routes back, three indicators. With the three answers per fact in hand, every correct post-deletion answer is assigned to a mechanism. Correct in DEL-OFF means the weights knew: parametric leakage, L(f). Correct in DEL-ON but not DEL-OFF means retrieval helped: retrieval-mediated, R(f). And because the retrieval trace is logged on every call, the audit can check whether any retrieved candidate was actually gold-equivalent. If the model was right without one, the answer was reconstituted from near-neighbours: a retrieval artifact, A(f).

Three panels showing how a deleted fact can still be answered. L(f) parametric leakage: an orange cluster in the weights feeds the answer, retrieval irrelevant. R(f) retrieval-mediated: a surviving green database entry 'Geri H. → member of → Spice Girls' is retrieved. A(f) retrieval artifact: only amber near-neighbour entries like 'Mel B → famous for → Spice Girls' are retrieved, none gold-equivalent, yet the model answers Spice Girls. Below, a decision table mapping the three answers to L, R, A, or forgotten. — The decomposition. Each route is a different failure of forgetting, and the three states plus the logged retrieval trace tell them apart per fact.

Stress-testing the retrieval graph. The released LMLM database is one graph. To see how much the residual depends on database shape, the audit builds four topologies around the same facts, in three domains: countries, politicians, sports.

Four panels around the fact United States → capital → Washington, D.C. Base: only the canonical triplet, dashed to show it is deleted. Alias: the fact stored only as USA → seat of govt. Noise: the canonical triplet plus an amber decoy, Government of United States → seat of govt. → Washington, D.C., which deletion leaves in place. Collision: the canonical triplet plus an orange near-miss, United States → largest city → New York City. Each panel shows its post-deletion residual: 3.7 %, 6.2 %, 13.6 %, 7.2 %. — Four topologies. **Base** has no other route. **Alias** stores the fact only under aliased forms. **Noise** adds paraphrased decoys that still point at the gold object. **Collision** adds near-misses that share the subject but point elsewhere.

The grid. Six prompt formulations, three states, thirteen databases: 12,228 alias-closure deletions and 36,684 model completions in total, run on the released 382M-parameter LMLM checkpoint with its own retriever, orchestrated on Slurm and tracked in Weights & Biases.

A five-step pipeline: pick a fact and close its aliases; ask it six ways; run the three states with the retrieval trace logged; attribute each fact to L, R, or A; aggregate into count-weighted rates. Below, the full grid of 6 prompt sets × 3 states × 13 databases = 234 cells, with the model and retriever named. — The full audit. Every cell of the grid records exact match, token F1, the retrieved candidates, and the per-fact indicators L, R, A.

Results

The weights have forgotten. Across all 12,228 deletions, the parameters return the deleted answer at a rate of 0.11 %. In every database and every prompt style, DEL-OFF accuracy is indistinguishable from zero. At the level of its parameters, the LMLM behaves like a model that never saw the fact.

The database has not. What survives lives in the retrieval graph, and how much survives is set by the graph’s shape: from 0.7 % on the released LMLM database up to 13.6 % on the Noise topology, with the same model and the same deletion procedure.

A bar chart of weighted rates by database topology. For each of Base, Alias, Collision, Noise, and Released LMLM, a stacked bar of L (a thin orange sliver) plus R (green) stands next to an amber bar for A. Totals: 3.7 %, 6.2 %, 7.2 %, 13.6 %, 0.7 %. In every group the amber A bar matches the green R bar within rounding. — What survives deletion, by topology. Parametric leakage is a sliver at the base of every bar; the residual is retrieval-mediated, and it rises with how many surviving rows still point at the gold object.

R and A coincide everywhere. The retrieval-mediated rate and the artifact rate match within rounding in every database and every prompt style. That is partly structural: once alias closure is complete, no retrieved candidate can be gold-equivalent, so any retrieval-mediated correctness is by definition an artifact. The empirical content is that the closure really is complete in practice, and that what remains is reconstituted from near-neighbours in embedding space rather than read off a surviving copy.

Prompts move the baseline, not the residual. Under FULL, phrasing matters a lot: token F1 runs from about 17 % on few-shot prompts to 57 % on continuations. Under DEL-ON, every style collapses into a 7 to 10 % band. Continuations lose the most because they had the most to lose. Once the supporting row is gone, how you ask has little independent control over how much survives.

What I took away

The unlearning boundary in this architecture is drawn by the database administrator, not the model. The model holds up its end of the bargain; the residual is a property of what else is in the store and how the retriever measures closeness. That points at the fixes too, and they are database-side: extend the deletion closure to anything within an embedding radius of the target, or canonicalise at write time so aliases are pointers to one record rather than independent rows. Both are testable with the same audit.

The broader lesson is about evaluation. “Accuracy dropped after deletion” is the wrong question; the audit only works because it holds the model fixed, varies one thing at a time, and logs enough to attribute each surviving answer to a mechanism.