Four different techniques, four different problems they solve, one client conversation that conflates all of them every week. Here's how we decide which knob to turn.
The conversation goes the same way most weeks. A client says "the model doesn't know about our latest policy update - can we fine-tune it?" Usually the answer is no, they don't want fine-tuning, they want retrieval. Sometimes they want memory. Occasionally they actually do want fine-tuning. Once in a while they want something closer to continual learning. The four are routinely conflated, the costs and trade-offs are very different and picking the wrong one is expensive in ways that only show up months later.
This post is the decision framework we use internally, written down.
Retrieval (RAG) fetches relevant information at query time and puts it into the model's context. The model's weights don't change. The knowledge lives in an external store, gets indexed, gets retrieved per request.
Memory is per-user or per-session state that the system writes during one interaction and reads during a later one. The model's weights don't change. The memory lives in an external store but, unlike retrieval, it's specific to a conversational thread or an identity rather than to a corpus.
Fine-tuning updates the model's weights by training on a curated dataset. The change is permanent for that model version. Everyone using the model sees the same behaviour.
Continual learning updates the model's weights incrementally as new information arrives, ideally without losing what the model already knew. Same mechanism family as fine-tuning, different operational shape - it's a process running over time, not a discrete training run.
The right knob depends on three questions: where does the new information come from, how often does it change and who needs to see the change?
Use retrieval when the information is a corpus that changes and needs to be authoritative. Product documentation, policy documents, knowledge base articles, regulatory filings. Anything where the source of truth lives in a document store, where freshness matters and where you need to be able to cite the source. RAG is also the only one of the four that gives you straightforward update semantics - change the document, re-index, the new version is live.
If you're tempted to fine-tune to teach the model facts, you almost certainly want retrieval instead. Fine-tuning teaches behaviour. Retrieval supplies facts. Confusing the two is the single most common mistake we see.
Use memory when the information is about the user or the session. Their preferences, the goals they've stated in the current thread, decisions they've made earlier in a multi-turn task. Memory is specific by definition - the value of "user prefers metric units" is that it applies to one user, not the whole corpus. Memory implementations vary from a simple key-value store to a structured summary maintained per thread, but the defining property is the scope.
The trap with memory is over-storing. Every session generates plausibly-useful state. Stored without discipline, the memory store becomes a junk drawer that retrieval has to wade through. We force every memory write to declare a TTL and a scope.
Use fine-tuning when you want to change the model's behaviour, format or style. Output structure, domain-specific terminology, response tone, adherence to a specific schema, performance on a narrow task type. These are the things fine-tuning does well, because they're properties of how the model responds, not what it knows.
The signal that fine-tuning is the right call: you can write down what "good" looks like in a few hundred to a few thousand examples and the difference between current and desired behaviour is consistent across those examples. If you can't enumerate examples, you don't have a fine-tuning problem yet.
Use continual learning when you have a steady stream of new examples and the cost of full re-training is prohibitive. This is the newest and least mature of the four. Most enterprise teams shouldn't be doing it yet. The honest version of the advice: if you're not already running periodic fine-tuning at scale, you don't have the operational maturity to run continual learning safely. Catastrophic forgetting is real, eval drift is real and the failure mode is a model that quietly gets worse over weeks.
Where does the new info live?
──────────────────────────────
Corpus ──────────► Retrieval (RAG)
User/Thread ──────────► Memory
In examples ──────────► Fine-tuning
Continuous ──────────► Continual learning (advanced)
──────────────────────────────
These aren't alternatives, they're layers. A mature production system uses three of the four simultaneously. The fine-tuned model gives you the behaviour and the domain vocabulary. Retrieval gives you the current facts. Memory gives you the per-user continuity. Each layer handles a different question and the failure modes don't overlap.
The composition is also how you bound the cost of each individually. A model fine-tuned for your domain needs less context to be retrieved. A retrieval layer that finds the right document needs less memory to track what the user already asked. A memory layer with disciplined scope needs less re-summarisation per turn. Treat the four as a stack and the budget on each one drops.
A few signals we've learnt to trust.
You fine-tuned and the model still doesn't know the latest version of a document. You wanted retrieval.
You added retrieval and the model still gets the format wrong. You wanted fine-tuning.
Memory is growing unboundedly and retrieval over it is slow. You stored things in memory that should have been in the corpus or you didn't set TTLs.
You're re-fine-tuning weekly to keep up with new data. You're approaching continual learning without the safeguards. Either invest in the safeguards or move the new data into retrieval.
Retrieval supplies facts. Memory supplies continuity. Fine-tuning supplies behaviour. Continual learning supplies adaptation over time. The four are not interchangeable and they are not competing - they're layers, each one handling a different question. Most of the wasted spend we see on AI projects traces back to picking the wrong knob for the problem. Get the diagnosis right and the implementation is the easier half of the job.