Everything a model "knows" from training got baked into its weights on a specific day — like a long-term memory that can never be updated without retraining the whole brain. Retrieval-Augmented Generation (RAG) works around that: before answering, the model looks up a live, specific, or private document and reads it as part of the question — open-book, instead of relying on memory alone. See both styles answer the same question below.
A model is trained once on a huge snapshot of text, then "frozen" — its weights don't change again just because time keeps passing. Anything that happened, changed, or was written after that cutoff simply isn't in there.
The model's parameters — the billions of learned numbers that encode everything it picked up from training data — stop changing the moment training ends. Ask it anything within that snapshot and it answers from memory, instantly and fluently.
Last week's news, a price that changed yesterday, your company's private files, a teammate who started this morning — none of it existed when the model was trained. Memory alone can't know it, and worse, the model often won't tell you that.
Pick a question below, then run both models. The memory-only model answers straight from its frozen training — confidently, even when it's stale or wrong. The RAG-enabled model first fetches a relevant snippet, "reads" it, and only then answers, grounded in what it just retrieved.
Retrieval solves real problems that pure memory can't — but it introduces new ones of its own. Knowing both sides is what separates "we added RAG" from "we added RAG and it actually helped."
Five short questions. Pick an answer to see if you're right, then move to the next one.
Which documents get indexed, how they're chunked, how "relevant" is decided, and what happens when retrieval comes back empty or wrong — those design choices determine whether RAG actually fixes staleness or just adds latency to the same old guesses. That's the kind of architecture review we do with teams before they ship.