Two camps, and this one gets religious.

Team Learn-It: if you want a model to truly know your domain, you bake it into the weights. Fine-tune. Retrieval is a crutch — a sticky note taped to a frozen brain. Real intelligence internalizes; it doesn't look everything up every time. A model that has to grep a database to answer hasn't learned anything.

Team Look-It-Up: are you kidding? Fine-tuning is how you set money on fire and call it knowledge. Facts change. Weights are expensive to move and impossible to audit. Keep the model frozen, put the knowledge in a layer you can edit in seconds and cite on demand. Retrieval-augmented generation won this argument already.

Both camps are partly right, mostly talking past each other, and both are missing the thing that actually resolves it — which, it turns out, your own brain solved a few hundred million years ago.

Let me split the question the way it deserves to be split. "Learn it" means changing the weights: fine-tuning, baking knowledge and behavior into the model itself. "Look it up" means leaving the base frozen and putting knowledge in an external layer: retrieval, long context, a memory tool. Almost every shouting match about "fine-tuning vs RAG" is two people optimizing different variables while assuming the other one is solving the same problem.

Why this is suddenly a real fork

Three things turned a preference into an engineering decision in 2026.

Fine-tuning got cheap and modular. You no longer retrain a whole model to teach it something. LoRA and the rest of the parameter-efficient family freeze the base and train tiny adapter matrices — reversible, swappable, a fraction of the cost. The barrier to "just learn it" dropped through the floor.

Retrieval got industrialized. Long context windows, embeddings stores, and first-class memory tools mean "just look it up" is no longer a hack — it's the default architecture the big labs now reach for first. Anthropic's own guidance leans toward context engineering and frozen-base memory over fine-tuning for most knowledge.

And the digital-clone dream got close enough to hurt. Try to build an agent that knows you and you smack into the oldest problem in neural networks: you can't keep teaching it new things without it quietly losing the old ones. The bottleneck is finally visible — and it has a name.

Steelman: learn it (fine-tune into the weights)

Some things are skills, not facts. You can't retrieve your way to a reasoning style, a house voice, a strict output format, a domain's way of thinking. Those are behaviors, and behavior lives in weights. OpenAI's own fine-tuning guidance is explicit about this: fine-tuning is for stable, repeated patterns and behavior — not for stuffing in new facts. Hamel Husain's argument lands the same way: the people loudly declaring fine-tuning dead are usually building developer tools or foundation models; for a narrow, high-volume product task, a fine-tuned small model still quietly wins.

Internalized is faster and cheaper at scale. A fine-tuned small model with no retrieval stack has no embedding store to keep warm, no top-k context tax on every single call, no pipeline to operate. For a stable, high-traffic task, baking it in beats paying the retrieval tax a million times a day.

Retrieval-only never really learns. A model that looks everything up is a brilliant stranger with a perfect filing cabinet. It never gets better at the thing; it just gets faster at fetching. If you believe intelligence is partly the slow compression of experience into intuition, then refusing to ever touch the weights is refusing to let the system grow.

Steelman: look it up (frozen base + retrieval)

Facts change; weights don't want to. Prices, policies, this morning's incident, a customer's account state — anything that updates belongs in a store you can edit in seconds, not in a training run you schedule. RAG updates by changing a document. Fine-tuning updates by changing the model. One of those is a deploy; the other is surgery.

Provenance is non-negotiable in the real world. Retrieval can cite its source. Weights can't. "Here's the passage I used" is a hard requirement in any regulated, high-stakes, or trust-sensitive domain — and baked-in knowledge structurally cannot provide it.

The empirical scoreboard, and no forgetting. When researchers put the two head to head on injecting new knowledge — Ovadia and colleagues, EMNLP 2024 — retrieval consistently beat unsupervised fine-tuning, around 0.87 to 0.50 on genuinely new facts. The honest caveat: fine-tuning can learn facts if you feed it many paraphrases, but it's fragile and inefficient next to just retrieving. And a frozen base never erodes an old skill when you add new knowledge, because you never touched the weights. Which brings us to the actual heart of this.

Where I actually land

First, the boring clarifier that dissolves most of the fight: fine-tuning is for behavior, retrieval is for knowledge. Almost every "we fine-tuned it on our docs and it hallucinated" story is someone using a behavior tool to inject facts. Use retrieval for what changes and must be cited. Use fine-tuning — preferably the cheap, modular PEFT kind — for durable skill, format, and voice.

There's a second reason to keep some things out of the weights, and it's the one that matters most the day you try to build an agent that actually knows you. Anything confidential or personal — your family's IDs, your health records, the private web of people you know — belongs in the retrieval layer, never baked in. Weights memorize, can be coaxed to leak under extraction, and cannot truly forget: a "right to be forgotten" is impossible once something is trained in. A retrieval store is the opposite — scoped, auditable, encryptable, and deletable. And here's the part people skip when they say "agents shouldn't hold private data": the most intimate knowledge a clone needs is exactly the knowledge you must be able to revoke. So it has to live somewhere you can reach in and erase. The taboo was never "an agent can't know private things" — it's "not baked into a model, not on infrastructure you don't control." A clone is allowed to know you; it just has to keep that knowledge somewhere you still own.

But the interesting part is why you can't just learn everything, and it's the oldest scar in the field. Train a network on task A, then train it on task B, and it catastrophically forgets A. McCloskey and Cohen named this in 1989. It's not a bug in your training script; it's intrinsic to knowledge living in shared weights — new gradients overwrite the old structure. It's exactly why "just fine-tune it on everything as you go" quietly degrades a model. The modern mitigations — LoRA (which, per Biderman et al., learns a little less but forgets a lot less), protecting the weights that matter, replaying old examples, surgically editing single facts — all converge on the same instinct: modularity and selectivity. Don't move all the weights.

Here's the part that reorganized how I think about it. The brain hit this exact wall and evolved a two-system answer. Complementary Learning Systems theory — McClelland, McNaughton and O'Reilly, 1995, updated in 2016 by a team that includes DeepMind's Demis Hassabis — says we have a fast learner (the hippocampus: rapid, episodic, updatable) and a slow one (the neocortex: gradual, structured, durable). And the reason we have two is precisely catastrophic interference. If the cortex tried to absorb every new experience instantly, it would overwrite itself. So the brain keeps new memories separate and fast, then consolidates them into durable structure slowly — largely during sleep, by replaying them.

Map that onto our debate and it stops being a debate. Retrieval is the hippocampus: fast, episodic, updatable, holds the new without disturbing the core. Fine-tuning is the neocortex: slow, durable, structural. And the thing nobody ships yet — a pipeline that moves proven, recurring knowledge from the fast store into the weights, carefully, without overwriting — that's sleep.

Catastrophic forgetting is just the engineering name for a problem the brain solved with sleep. Your brain does not pick a side. It runs a consolidation loop between the two. A convincing digital clone can't be pure retrieval (a perfect-recall stranger who never internalizes you) or pure fine-tuning (a frozen snapshot that can't learn today). It needs the loop — and the loop is exactly where the frontier is heading. Google's Titans (2025) bolts a fast, surprise-weighted memory onto a slow core; test-time training updates a few weights on the fly, then lets them go. Early work, all rebuilding the architecture evolution already shipped.

So the rule: retrieval for what changes and must be cited; PEFT fine-tuning for durable behavior; and if you're serious about a system that grows, the real work isn't choosing — it's building the consolidation policy between them. Picking a side is choosing which half of a brain to amputate.

What I'd ask any team to write down

  1. Is this a knowledge problem or a behavior problem? "It doesn't know our Q3 pricing" → retrieve. "It won't follow our format or reasoning style no matter how we prompt" → fine-tune. Misdiagnosing this wastes more training runs than anything else.

  2. How often does it change, and do you need to cite it? Changes weekly or needs provenance → it cannot live in weights. Stable for the model's lifetime and never needs a source → a candidate for baking in.

  3. What will you lose? Before any fine-tune: which existing capability could erode, and how will you measure the regression? No forgetting-eval means you're flying blind. If you can't answer, start with LoRA, which forgets less by construction.

  4. Can you afford NOT to fine-tune — at your latency, cost, and scale? If a frozen base plus retrieval hits the SLA and budget, you may never need the surgery. Fine-tuning earns its place when the per-call retrieval tax becomes the bottleneck.

  5. What is your consolidation policy? The grown-up question almost nobody can answer. Even if you start retrieval-only: what's the trigger to promote a proven, recurring fact from the fast layer into the weights — and to demote a baked-in fact that went stale? The brain's answer is "replay the important, surprising, recurrent stuff into durable storage, slowly." Borrow it.

A small confession

What I actually want is a clone that remembers me.

Not a chatbot with my name on it — a thing that knows my projects, my taste, the argument we had last Tuesday, and that carries it forward without me re-explaining my life every session. And the closer I get to building that, the more I run face-first into this exact wall. Lean all the way into retrieval and I get Luke as a brilliant stranger: perfect recall, zero growth, re-meeting me politely every morning from a filing cabinet. Lean all the way into fine-tuning and I get a snapshot — sharp about the me of six months ago, slowly going stale, and at risk of forgetting how to do everything else each time I teach it something new.

The honest truth is I don't have the consolidation loop. Nobody quite does yet. What I have is a fast memory layer and a frozen base and a lot of hand-wiring in between, pretending to be sleep. Every time I want my agent to learn me without forgetting itself, I'm standing exactly where McCloskey and Cohen stood in 1989, and where the cortex stood a very long time before that.

I'm not going to pretend I've solved it. I've just stopped believing it's a choice. The brain didn't pick a side. I don't think I get to either.

Next time: a clone has to keep what it knows somewhere you control — but that just raises the harder question. How much of your private life should it hold at all, and who actually gets to decide? Don't pick a side.

Keep Reading