Glossary
What is Retrieval-Augmented Generation (RAG)?
Definition
Retrieval-augmented generation is the pattern where a system searches a set of documents first, then hands what it found to a model to write the answer. Grounding is the outcome RAG is built to produce: statements tied to a retrieved source rather than to training memory. Every AI search product runs on this pattern.
At a glance
- CategoriesTechnical
- Related fieldsAI Search, Technical
- DifficultyAdvanced
At a glance
- RAG splits the job in two: retrieval finds the text, a model writes from it.
- The documents can be the open web, internal files or a product catalog.
- Nothing is added to the model. Retrieved text sits in the prompt for one answer, then goes.
- A RAG answer is only as good as what retrieval returned.
Fetch first, write second
Four steps, in order, every time.
The question becomes one or more searches, run against an index of chunked documents and matching on meaning rather than exact words. The best passages come back, get packed into the prompt with the question, and the model writes from that package.
The idea was named in a 2020 paper, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, and the shape has barely changed. Google’s grounding documentation describes the same pipeline in product terms.
The handover is what matters for a brand. The model never goes looking for your page. It writes from what was placed in front of it, so everything deciding your visibility happened in the retrieval step.
Why your live pages are back in the loop
For a while it looked as though AI would freeze the web into a training snapshot and stop reading it. RAG is why that did not happen.
Retrieval runs at question time, so the text a model quotes can be a page you published this morning. The knowledge cutoff stops mattering for anything the system looks up, and your site is live inventory again.
The hard part is that selection is invisible. No query, no ranking report, no signal about which chunk was dropped. A page can be crawled, retrieved, then cut from the prompt without anything reaching your analytics.
So treat retrieval as the contest and the model as a formatter. Agonising over how an assistant phrases things is optimizing the wrong half.
Prepare content for a retrieval step you cannot see
You are writing for the chunk, not the page.
- Make every section a complete answer. It gets pulled out alone, and one that only works in sequence will not survive the trip into a prompt.
- Keep one subject per section. A chunk covering three things matches weakly on all three, and retrieval takes the sharper competitor.
- Put specifics in text, not images. A spec table rendered as a picture is invisible to retrieval, as is a price that needs a script to appear.
- Write the exact terms alongside the plain-language version. Retrieval is usually a hybrid search, so the model number and the description both earn their place.
- Check what is actually served. Fetch your own page as a crawler does, JavaScript off. Most retrieval failures are content that was never there.
RAG and fine-tuning solve different problems
| RAG | Fine-tuning | |
|---|---|---|
| What it changes | The text put in front of the model | The model’s own behavior |
| Best for | Facts that change, and sources you must cite | Tone, format, consistent task behavior |
| Updating it | Republish the document | Retrain |
| Can it cite a source | Yes, the retrieved document | No |
| Typical failure | The right passage was never retrieved | Sounds right, is wrong |
Frequently asked questions
-
Is RAG the same as grounding?
Closely linked, not the same. RAG is the architecture: search, then generate. Grounding is the property you want from it, each claim tracing back to a retrieved document. A badly built RAG system retrieves poor sources and produces answers that are not grounded.
-
Do I need to build a RAG system for my brand?
Almost certainly not, and this is where money gets spent for nothing. You build one to run your own assistant over your own documents. To be cited by ChatGPT or Perplexity you are feeding somebody else’s RAG system, and that work is publishing, not engineering.
-
Does RAG stop a model making things up?
It reduces it and does not eliminate it. Give a model a good source and it usually sticks to it. Give it a partial one and it fills the gap, which is where a hallucination about your pricing comes from. Retrieval quality sets the ceiling.
-
How do I know whether my content is being retrieved?
Indirectly. Server logs show AI crawlers fetching pages, which proves access and says nothing about selection. The usable test is asking assistants real buyer questions and reading what they quote. Wording lifted from your page is the clearest evidence there is.
-
Will bigger context windows make RAG unnecessary?
No, though the mix keeps shifting. Larger windows mean more retrieved material fits, not that a model holds the web. Cost, latency and accuracy all worsen as a prompt grows, so the selection step stays and so does the competition to be selected.