Knowledge Editing: Surgical Updates to a Trained LLM
In 2023 an OpenAI customer support engineer noticed that GPT-4 was confidently telling users that the CEO of Twitter was Jack Dorsey. The world had moved on. The model's weights had not. Retraining from scratch was out of the question — millions of dollars and weeks of GPU time. Fine-tuning on a corrected corpus risked breaking thousands of other facts the model knew correctly. So a different question started to circulate inside frontier labs: can we open the patient up and edit just the neuron that holds this fact? In 2022 a Stanford-CMU team led by Kevin Meng had published the first surgical answer — ROME — and by 2024 every major lab had a knowledge-editing pipeline somewhere in its post-training stack. This is the story of how we learned to change a transformer's mind, one fact at a time.
Learning Objectives
After this lesson, you will be able to:
Explain why retraining and full fine-tuning are unsatisfying answers to 'update one fact'
Locate factual recall to MLP modules in middle transformer layers, and explain why
View the MLP as a key-value memory and identify which matrix stores keys vs values
Derive ROME's rank-one update from the constraint 'change this association, preserve the rest'
Contrast ROME (single fact) with MEMIT (batched edits) and explain the trade-off
Distinguish weight-editing approaches (ROME, MEMIT, MEND) from memory-augmenting approaches (GRACE)
Apply the four editing evaluation criteria: efficacy, generalization, locality, portability
Recognize ripple effects and other systematic failure modes of sequential editing
Explain why knowledge editing is the strongest causal validator of mech-interp claims
Imagine the customer-support scenario. The model memorized that the CEO of Twitter is Jack Dorsey. You want it to say "Linda Yaccarino" (or whoever is CEO this week). Your fine-tuning dataset has one example: Q: Who is the CEO of Twitter? A: Linda Yaccarino.
You run SFT for a few steps. Three things happen, and only one of them is what you wanted.
The targeted fact updates. Good — that was the goal.
Adjacent unrelated facts drift. The gradient touches shared parameters. "Who founded Twitter?" now sometimes returns garbled answers because the same MLP rows held both facts.
Generalization is uneven. "The current CEO of Twitter is..." may still complete to "Jack Dorsey" because the paraphrase passes through different routing.
The first two are catastrophic forgetting in miniature: every gradient step is a noisy update to billions of parameters; some of those parameters held facts you cared about. Empirically, after a few hundred targeted edits, perplexity on unrelated text drifts measurably. After a few thousand, the model is meaningfully degraded.
#Part 2: Where Facts Live: MLPs as Key-Value Memory
The first conceptual breakthrough that made surgical editing possible came from Geva, Schuster, Berant and Levy in 2021 ("Transformer Feed-Forward Layers Are Key-Value Memories"). They proposed and empirically supported a striking claim: each MLP block in a transformer behaves as an associative memory, with the first weight matrix storing keys and the second storing values.
Recall the MLP form: MLP(x) = W_2 · σ(W_1 · x). Geva and colleagues argued that the rows of W_1 act as key patterns — directions in residual-stream space that match specific input motifs — and that the corresponding columns of W_2 act as values that get added to the residual stream when the key fires. Concretely, each neuron in the hidden layer corresponds to one (key, value) pair: the neuron's pre-activation is <row_i(W_1), x>, and its post-activation scales column_i(W_2), which is then summed into the output.
MLP(x)=W2σ(W1x)=i∑σ(⟨ki,x⟩)vi
The second breakthrough — this one due to Meng, Bau, Andonian and Belinkov (2022, "Locating and Editing Factual Associations in GPT") — was to show which layers hold which kinds of facts. They introduced causal tracing to find out.
Transformer Feed-Forward Layers Are Key-Value Memories
Geva, Schuster, Berant, Levy (2021)
The original argument that MLPs in transformers act as key-value associative memories. Foundation for all subsequent weight-editing work.
Locating and Editing Factual Associations in GPT (ROME)
Meng, Bau, Andonian, Belinkov (2022)
Introduced causal tracing + the rank-one ROME edit. The seminal paper that opened the field.
Now we have the setup. We know facts live in middle MLP layers. We know the second matrix W_2 (sometimes called W_proj or W_O) stores values. The next question: can we change one value without disturbing the others?
ROME's answer is yes, in closed form, via a rank-one update.
Pick a fact to edit: (subject, relation, old_object) → (subject, relation, new_object). For example, ("Eiffel Tower", "is located in", "Paris") → ("Eiffel Tower", "is located in", "Rome"). (This is the actual edit in Meng's paper, which is what gives the method its winking name.)
Run the model on a prompt that elicits the fact, e.g., "The Eiffel Tower is located in". At the targeted MLP layer L* (chosen by causal tracing — usually around layer 5–8 of a GPT-2-XL or layer 17 of a GPT-J), at the last subject token position, two vectors are relevant:
k* ∈ ℝ^d_mlp: the pre-W_2 activation, i.e., σ(W_1 · h) where h is the residual stream at that position. This is the key — the encoding of "Eiffel Tower as a subject of a location relation."
v_old ∈ ℝ^d_model: the current value the MLP produces, i.e., W_2 · k*. This is what currently routes the model to "Paris."
We want to find a new v* such that, if we patched in v* instead of v_old at this spot, the model would output "Rome" instead of "Paris." Meng et al. find v* by gradient descent: minimize cross-entropy of the model on "Rome" while patching in a candidate v* at this exact location, with a regularizer that keeps v* close to v_old. This is a small optimization — a few hundred steps on a single hidden vector — not a full fine-tune. The point of this step is only to discover the target value; we don't update any weights yet.
Now the trick. We have W_2 (the value matrix at layer L*). We want to update it to W_2' such that:
W_2' · k* = v* (the targeted edit lands)
W_2' · k = W_2 · k for every other key k that the model uses in normal operation (everything else stays intact)
The second constraint is what we mean by "surgical." We do not know what every other key is, but we can approximate the set with a key-covariance matrix C = E[k k^T] estimated over a large corpus of natural language activations at this layer. ROME minimizes the squared change in W_2 weighted by C, subject to constraint (1). This is a constrained least-squares problem with a clean closed-form solution.
Δ = a b^T where a = (v* − W_2 k*) / ((k*)^T C^{-1} k*) and b = C^{-1} k*. A rank-one matrix has only one non-trivial direction. When you add it to W_2, you are changing the matrix's behavior only along the 1-D subspace spanned by b. Vectors perpendicular to b see Δ k = 0. That is the entire reason this is surgical: the perturbation is invisible to almost all other inputs.
The pre-conditioning by C^{-1} is also subtle. Without it, you'd nail the target but make a large weight change in a direction that happens to be common across many other keys — and you'd break them. C^{-1} rotates your update into a direction that the empirical key distribution rarely visits.
What Do You Think?
ROME applies a rank-1 update Δ = a b^T to W_2. How does this preserve other facts the model knows?
#Part 4: MEMIT: Editing Thousands of Facts at Once
ROME edits one fact at a time. In production, you often want to update hundreds or thousands of facts in one shot — a quarterly news refresh, a batch of PII redactions, a regulatory compliance sweep. Running ROME 5,000 times sequentially is bad: each edit slightly distorts the model, and the distortions compound. Errors after edit #2,000 are visibly worse than after edit #1.
MEMIT (Meng, Sharma, Andonian, Belinkov, Bau 2023 — "Mass-Editing Memory in a Transformer") generalizes ROME to handle batched edits. Two changes:
Many keys, many values. Replace single vectors k*, v* with matrices K* ∈ ℝ^{d_mlp × N} (N keys stacked as columns) and V* ∈ ℝ^{d_model × N} (N target values). The constraint becomes W_2' K* = V*.
Spread edits across multiple layers. ROME picks one layer. MEMIT distributes the residual to update across a window of middle layers (typically 5–7 consecutive layers), giving each layer a fraction of the total change. This dramatically reduces per-layer perturbation and prevents any single layer from being pushed off-distribution.
ΔMEMIT=(V∗−W2K∗)(K∗⊤C−1K∗+I)−1K∗⊤C−1
Empirically, MEMIT has been shown to scale to ~10,000 simultaneous fact edits on GPT-J-6B while keeping perplexity on held-out text within ~1% of the unedited model. ROME applied 10,000 times sequentially does not get close.
What Do You Think?
MEMIT vs ROME — what is MEMIT's main advantage over running ROME many times in sequence?
Mass-Editing Memory in a Transformer (MEMIT)
Meng, Sharma, Andonian, Belinkov, Bau (2023)
ROME's batched generalization. Scales to thousands of simultaneous edits.
Mitchell, Lin, Bosselut, Chen, and Manning (2021, "Fast Model Editing at Scale") asked: what if instead of deriving the edit in closed form, we learned a function that maps "the gradient of the standard fine-tuning loss on this one example" to "the actual update we should apply"?
The pipeline:
Compute the standard fine-tuning gradient g on the target edit example.
Pass g through a small "gradient transformer" network — a learned function f_θ — that reshapes it: g' = f_θ(g).
Apply g' as the weight update.
The gradient transformer f_θ is meta-trained on a held-out dataset of (pre-edit model, target edit, ideal post-edit model) triples. It learns to take noisy fine-tuning gradients and project them into a subspace that nails the target while preserving locality.
MEND is learned, ROME is derived. The trade-off: MEND can in principle handle edits that don't fit the "MLP-as-key-value" assumption (e.g., procedural edits, attention-pattern edits) because it doesn't make any structural assumption. But it requires a meta-training corpus, and its locality guarantees are statistical (held-out performance) rather than algebraic (rank-1).
Fast Model Editing at Scale (MEND)
Mitchell, Lin, Bosselut, Chen, Manning (2021)
Meta-learned approach to editing. Trains a hypernetwork that reshapes fine-tuning gradients into surgical edits.
#GRACE: Edit by Adding Memory, Not Changing Weights
Hartvigsen, Sankaranarayanan, Palangi, Kim, and Ghassemi (2023, "Aging with GRACE: Lifelong Model Editing with Discrete Key-Value Adaptors") took a different tack: don't change the weights at all. Instead, splice in a small external key-value cache between two transformer layers.
At inference, the residual stream at the chosen layer is queried against the cache. If a stored key is sufficiently similar (above a threshold), the cache's value replaces (or is added to) the model's normal forward output at that point. If no key matches, the model runs unchanged.
To add a fact: insert a new (key, value) pair into the cache. To remove a fact: delete the pair. To update a fact: overwrite the value.
Trade-offs are stark and easy to remember.
Pros. Edits are perfectly reversible (just remove the cache entry). The base model is byte-for-byte unchanged, so locality on unrelated inputs is exactly preserved by construction. You can layer thousands of edits with no compounding error.
Cons. Every forward pass now includes a cache lookup, which adds latency and memory. The cache grows linearly in the number of edits — fine for thousands, painful at millions. And the cache hit/miss boundary creates a discontinuity: a slightly different paraphrase may not match the cached key, so generalization is harder to engineer.
Aging with GRACE: Lifelong Model Editing with Discrete Key-Value Adaptors
Hartvigsen, Sankaranarayanan, Palangi, Kim, Ghassemi (2023)
Adds a key-value cache between transformer layers instead of editing weights. Reversible, but adds inference latency.
Quick check
Why does Meng et al.'s causal tracing methodology require both a clean run AND a corrupted run, plus the patched runs?
#Part 6: Try It Yourself: Toy ROME on an Associative-Memory Module
Time to make this concrete. Below is a tiny, runnable implementation of ROME on a 2-layer MLP "knowledge module" that stores a small set of subject–object associations as a key-value memory. You will:
Build the MLP and verify it correctly stores three associations.
Apply a rank-1 ROME edit to change one association.
Verify that the edited fact is now correct, AND that the other two are preserved within tight tolerance.
This is exactly the structure of a single MLP block at the targeted layer of a real transformer, just much smaller — d_model = 4, d_mlp = 6, three "facts." Read the code, run it, then tweak the edit target and see what happens to the locality.
Loading visualization...
When you run this you should see error ≈ 0 on the edited fact (subj1 → Rome) and very small error on the preserved facts (subj2 → Berlin, subj3 → Madrid). Now try the suggested experiment: replace C_inv with the identity matrix. The edit still lands at the target, but the locality on the other two facts gets dramatically worse — because the rank-1 perturbation is no longer rotated away from the typical key distribution. That is exactly why ROME's pre-conditioning by C^{-1} is in the formula.
Editing is hard to evaluate because "the model still mostly works" is the bar. The community has converged on four metrics, each capturing a different failure mode.
Metric
Question
Example
Efficacy
Does the edited fact replace the old one?
After editing, does the model say "Berlin" instead of "Paris" for "France's capital is..."?
Generalization
Does the edit transfer to paraphrases?
"The capital of France is..." should also produce "Berlin", not the unedited "Paris".
Locality (specificity)
Are unrelated facts preserved?
"Germany's capital is..." should still say "Berlin" (no, wait — bad example; "Italy's capital is..." should still say "Rome").
Portability (reasoning)
Does multi-hop reasoning use the new fact?
"Who would you visit at the Élysée Palace in the capital of France?" should now route through "Berlin" if the edit took.
ROME and MEMIT score very well on efficacy and locality, moderately well on generalization (depends on prompt similarity to the targeted phrasing), and poorly on portability — a major open problem. GRACE scores perfectly on locality (by construction) and well on efficacy, but poorly on generalization (paraphrases miss the cache key) and on portability for the same reason.
Quick check
Why is there a fundamental trade-off between locality and efficacy in knowledge editing?
#Part 8: Failure Modes: Why Editing Is Not Yet a Silver Bullet
Five years in, the editing literature has matured enough to catalogue its failure modes. You should know all of them.
If fact A logically implies fact B, editing A should propagate to B — but it often doesn't, and worse, sometimes it propagates incorrectly. The canonical example from Cohen and colleagues:
Edit: "Paris is the capital of France" → "London is the capital of France".
Downstream fact: "The Eiffel Tower is in Paris". After the edit, does the model now say the Eiffel Tower is in London? Or does it correctly retain "Paris" as a city while updating only the capital relation?
In practice, ROME-edited models give inconsistent answers across paraphrases: sometimes the downstream chain is updated coherently, often it is not. The model has been edited to believe one fact at a single retrieval site without revising the rest of the knowledge graph. This is a structural limitation: weight editing operates on stored associations, not on a reasoner that propagates implications.
What Do You Think?
A ripple effect, as described in Cohen et al. 2024 — what's a concrete example?
Each edit moves the model slightly off the manifold it was trained on. The 1000th edit happens in a model whose key-covariance C has subtly drifted, whose layer norms are operating on slightly different scales, whose downstream layers are coping with a slightly different signal distribution. After tens of thousands of sequential edits, even MEMIT-edited models show measurable perplexity degradation on held-out text and "model collapse" on certain prompt distributions.
You edit "The CEO of Twitter is X" → "The CEO of Twitter is Y". But ask the model "What does Y do at Twitter?" and you may still get an answer based on the old association, or no answer at all. The edit is directional: it updates the forward retrieval (subject, relation) → object, not the inverse (object) → (subject, relation). Real knowledge in a transformer is stored at multiple sites for multiple retrieval directions; ROME's localization usually catches only one.
You edit a fact. The model recites the new fact when asked directly. But when asked to reason multi-hop using the fact ("Who would you visit at the Élysée Palace in the capital of France?"), the chain-of-thought goes off-script or ignores the edit. Portability is poor.
ROME and MEMIT are in production at multiple commercial vendors for targeted factual updates. Quarterly news refreshes, CEO changes, sports records, regulatory updates — these are increasingly handled by an editing pipeline rather than a retrain.
For safety-critical edits (block this specific dangerous output, refuse this specific class of request), the industry has converged on inference-time refusal (a guardrail model or a system prompt) rather than weight editing. The reason is reliability: refusal can be tested deterministically against a held-out test set, and rolling back a refusal rule is trivial. A weight edit is much harder to verify is robust to adversarial paraphrasing, and harder to roll back.
For privacy (GDPR right-to-be-forgotten), the regulatory gold standard remains retraining without the data. Weight editing can approximate forgetting (e.g., ROME-edit to a default "I don't know" response), but courts and regulators have not yet accepted edits as legally equivalent to deletion. This is one of the most active open questions in AI policy.
MEND has seen less production adoption than ROME/MEMIT because the meta-trained gradient transformer is brittle to changes in the base model — every model update requires re-training the editor.
GRACE is most often used inside research prototypes and continual-learning setups, where reversibility matters more than inference latency.
Evaluating the Ripple Effects of Knowledge Editing in Language Models
Cohen, Biran, Yoran, Globerson, Geva (2024)
Introduced the RippleEdits benchmark. Showed that ROME, MEMIT, and MEND all suffer from downstream-consistency failures.
#Part 10: Editing as the Acid Test for Mech-Interp
Knowledge editing has one more role you may not have anticipated: it is the strongest causal validator of mechanistic-interpretability claims.
Suppose a mech-interp paper claims: "Feature F, located at layer L, position t, MLP output direction d, represents the concept 'Eiffel Tower is in Paris'." How do you check that the claim is actually true?
You could correlate: does feature F activate when the model is processing prompts about the Eiffel Tower? Yes, almost certainly — but lots of features will. Correlation doesn't establish that F is the representation.
You could intervene by ablation: zero out feature F and see if the model loses the fact. Maybe. But ablation tests necessity, not sufficiency — the fact might be redundantly stored elsewhere.
The strongest test is to edit F: surgically rewrite weights at exactly the location the interp paper claims, in exactly the direction the interp paper claims, to produce exactly the changed fact the paper predicts. If the model now coherently says "the Eiffel Tower is in Rome" — and only that fact has changed — the claim is causally validated. If the edit fails to take, or breaks unrelated facts, the claim was wrong.
Anthropic and EleutherAI have used this back-and-forth — interp generates a hypothesis, editing tests it, results refine the next round of interp — as the central methodological loop for circuit-level claims. It is the closest thing the field has to controlled scientific experimentation on neural networks.
Looking forward, the most active 2024–2025 research direction takes this further: instead of editing the raw rows of W_2, edit the sparse autoencoder features extracted from the residual stream by the SAE-based interpretability machinery (covered in the previous lesson). The pitch is that SAE features are monosemantic — each feature corresponds to one human-meaningful concept — so editing them should give better locality, better generalization, and better portability than editing raw MLP rows. Empirical results so far are promising but mixed; this is one of the open frontiers.
Recap
Key Takeaways
1Knowledge editing changes specific facts in a trained LLM without retraining and without fine-tuning's catastrophic forgetting
2Factual associations are stored primarily in middle-layer MLP modules, with the MLP acting as a key-value memory (W_1 keys, W_2 values)
3Causal tracing (clean / corrupted / patched runs) localizes a fact to a specific (layer, token) site
4ROME's rank-1 closed-form update Δ = (v* − W_2 k*)(C⁻¹ k*)^T / (k*^T C⁻¹ k*) changes one association while leaving the rest of W_2's behavior nearly intact, because rank-1 perturbations only affect one direction
5MEMIT generalizes ROME to batched edits (thousands of facts at once) by distributing updates across a window of middle layers — essential for production-scale editing without compounding error
6MEND learns the edit via a meta-trained gradient transformer; GRACE sidesteps weight changes entirely with a key-value cache
7Edits are evaluated on four axes: efficacy, generalization, locality, portability — and there is a structural trade-off between efficacy and locality
8Ripple effects (Cohen 2024), sequential drift, inverse-direction failures, and reasoning incoherence are the main known failure modes
9In production: ROME/MEMIT for factual updates; inference-time refusal for safety; retraining for GDPR-grade deletion
10Editing is the strongest causal validator of mech-interp claims — it tests whether a hypothesized representation is actually the representation