SKIM: Writing Conversations into the Weights of Frozen Language Models with Self-Keyed In-Parameter Memorization

Forum topic · ✨步子哥 · 2026-10-29

Summary

SKIM (Self-Keyed In-Parameter Memorization), presented in arXiv:2610.36948 by XinYu Piao et al. from Korea University, enables frozen language models to store dialogue history directly in their feed-forward network weights, eliminating external vector databases and KV caches. Extending the ROME/MEMIT knowledge-editing line of work, SKIM lets the model self-generate candidate questions as retrieval keys for each dialogue turn, then uses a closed-form update to jointly write all (key, dialogue) pairs into a single FFN layer. Recall uses self-probed selection to match user queries against parameter-embedded keys. Notably, streaming (turn-by-turn) writing achieves exactly the same recall as batch writing, avoiding catastrophic forgetting. Across five language models, SKIM reaches 63.1% average recall (75.0% for the best model) with no fine-tuning, no added parameters, and no external storage. Failure analysis shows the bottleneck is self-extraction rather than storage or addressing, and that mid-conversation content and multi-word answers are hardest to recall. The paper positions SKIM as a proof of concept for parameter-as-storage dialogue memory, with limitations in recall rate, model scale (tested up to 9B), and dialogue length (N=32 turns).

SKIM: Writing Conversations into the Synapses — Frozen Language Models That Remember via Their Parameters

Paper: arXiv:2610.36948 — *Self-Keyed In-Parameter Memorization for External Memory-Free Dialogue Recall in Frozen Language Models*, by XinYu Piao et al. (Korea University)

A Counterintuitive Question

How does an AI assistant remember a 30-turn conversation — from your work report to your weekend plans? Today's answer is almost universal: external storage. Every turn goes into a vector database; at query time, semantic search retrieves relevant snippets and stuffs them into the prompt. That database keeps growing — storage and retrieval costs scale linearly with the conversation.

The SKIM authors ask a counterintuitive question: what if the model's parameters themselves were the storage medium? What if conversations could be written directly into the weights, with no external store at all?

Background: From ROME

SKIM builds on ROME (Rank-One Model Editing, arXiv:2202.05262), which showed that Transformer feed-forward (FFN) layers store factual knowledge. Given a (subject, relation, object) triple, ROME computes a closed-form weight update ΔW that plants the fact into the parameters without retraining. MEMIT (arXiv:2210.07229) scaled this to mass edits. But these methods require knowing the exact question and answer at edit time — a constraint that doesn't fit open-ended dialogue.

SKIM's Core Innovation: The Model Generates Its Own Keys

Dialogue differs from structured facts: one narrative turn implies countless possible questions. SKIM's solution:

Step 1: Self-Keyed Construction

For each dialogue turn, the model generates a batch of plausible future questions (e.g., "Where did they go today?", "What did they buy?", "What happened on the road?"). These become the retrieval keys.

Step 2: Joint Edit in One Feed-Forward Layer

A closed-form solve writes all (question, dialogue content) pairs into a single FFN layer's weight matrix at once — like ROME/MEMIT, but with model-generated keys rather than human-specified ones.

Step 3: Recall and Self-Probed Selection

When the user later asks a question, the model matches it against parameter-embedded keys; a match triggers recall of the corresponding content, read directly from the parameters with no external storage.

Streaming = Batch Writing: No Forgetting

A striking result: streaming writing and batch writing achieve identical recall. The closed-form solution has a mathematical property: the cumulative effect of turn-by-turn writes equals one-shot batch writing. Recall curves fall exactly on the y=x diagonal. SKIM can therefore write conversations incrementally in real time without catastrophic forgetting — a trap that typically plagues continual learning.

Results: Is 63.1% Good Enough?

Experiments on five language models:

Average recall across 5 models: 63.1%
Best model: 75.0%

Context matters: 1. The model is frozen — no fine-tuning, no added parameters 2. No external storage — no vector database, no KV cache 3. Open-ended keys — generated by the model, not pre-defined

A recall-attribution experiment shows the bottleneck is not storage or addressing but self-extraction — the model's ability to read content back out of its parameters. Stronger models should naturally improve recall.

Failure Modes

By position: mid-conversation content is more forgettable than beginning or end
By answer type: proper nouns (names, places) are recalled better than descriptive phrases — consistent with ROME's finding that FFNs excel at entity knowledge
Multi-word answers are harder than single-word ones, since each generated token is an error opportunity

These are properties of the in-parameter storage paradigm itself, not bugs. SKIM suits short-term conversational recall, not long-term fact storage.

Why It Matters

1. A paradigm shift from external to parameter storage: RAG, vector databases, and KV caches all store information outside the model, bringing storage cost, retrieval latency, and privacy risk. SKIM fuses memory into the model itself — no external database to breach, zero retrieval latency, zero added storage cost. 2. Deep connection to knowledge editing: SKIM extends the ROME/MEMIT insight that "the FFN is a writable knowledge base" from structured facts to unstructured dialogue — with model-generated keys as the key innovation. 3. Engineering elegance: streaming = batch means SKIM can deploy in real-time dialogue without waiting for the conversation to end, and sidesteps catastrophic forgetting entirely.

Honest Limitations

63.1% recall is far from practical for remembering every detail of 100 turns
Tested only on small-to-mid models (largest 9B); larger-model behavior unknown
Dialogue length limited (N=32 turns); longer conversations unverified
No direct comparison against the strongest RAG systems, which may recall more

These limits don't diminish the core contribution: SKIM proves that writing conversations into parameters is feasible, and that streaming writes don't forget. It is a proof of concept, not a production system.

One-Line Summary

SKIM lets a frozen language model generate its own questions as keys and write dialogue directly into FFN weights via a closed-form solution — no external storage, no fine-tuning, and streaming writes equal batch writes. At 63.1% recall, "parameters as storage" is not science fiction; it's an emerging paradigm.

---

Paper: arXiv:2610.36948

Related work:

ROME: Rank-One Model Editing
MEMIT: Mass Editing Memory in a Transformer