3 min read

The Video Game Metaphor That Explains RAG

You sit down to play an old RPG. You load your save file. The game knows where you are, what items you carry, which quests you have completed, and who you have spoken to. It does not rebuild the entire world from scratch. It loads a small piece of context from storage and applies it to the running game engine. That is RAG.

Retrieval-Augmented Generation sounds technical, but the concept is older than AI. Every game that uses save files has been doing a version of it for decades.

The Pieces of the Analogy

The game engine is the LLM. It is the thing that does the work. It knows the rules of physics, the combat system, the dialogue trees. It was trained once. It does not change when you load a save file, and it does not learn from your playthrough. It is a fixed piece of software with general capability.

The save file is the vector database. It holds specific information about your current session: your position, your inventory, your quest progress. When the game needs to answer a question like “Can I enter this door?”, it checks the save file. The save file was not part of the game when it shipped. You created it by playing.

Your next button press is the prompt. You press A to open a chest. The game checks the save file to see if that chest is still there, then checks the engine to decide what happens. The result is a response that combines both sources.

Why This Matters

RAG exists because large language models have a hard limit. They know what they were trained on and nothing else. Ask a model about your company’s internal documentation, and it will guess. Sometimes the guess is right. Often it is not.

Retrieval solves this by giving the model a save file. Before the model answers your question, a separate system searches a database for relevant information and tucks it into the prompt. The model does not need to know your documentation. It just needs to read what you gave it and answer based on that.

This is the same reason game developers do not ship every possible save state on the cartridge. The cartridge holds the engine. The save file is written later, by the player, for the player.

What RAG Is Not

RAG is not retraining. You do not need to fine-tune a model to get it to answer questions about your data. You do not need to collect a thousand examples of customer support tickets and run them through a training pipeline. You build a database, you write a retrieval step, and you are done.

RAG is not a replacement for the model. The model still does the reasoning. RAG just gives it something to reason about.

And RAG is not magic. If the database has bad data, the answer will be bad. If the retrieval step misses the relevant document, the model will guess. The system is only as good as the save file.

The Takeaway

Next time someone explains RAG with architecture diagrams and terms like embedding and chunk size, think about a game. The engine runs. The save file loads. The player acts. That is the whole pattern.

Everything else is implementation detail.