What Is RAG? How AI Looks Things Up Before Writing
What is RAG?
RAG (retrieval-augmented generation) is the architecture that lets an AI system look things up before it writes. Instead of answering purely from training memory, the system first retrieves relevant documents (usually via search), then generates the answer with those documents in front of it. Search first, write second.
It exists because a bare LLM has two hard limits: its knowledge froze at training time, and it hallucinates where its memory is thin. Retrieval patches both: fresh information comes in at question time, and the model writes against real text instead of guessing.
How RAG works, step by step
Retrieve: the question (often rewritten into several sub-queries) goes to a search backend, which returns candidate documents or passages. Augment: the best passages are packed into the model's context window alongside the question. Generate: the model writes the answer using that supplied material, ideally attaching citations to the passages that support each claim.
Every major assistant runs this pattern in its search-enabled modes: ChatGPT with browsing, Perplexity end to end, Gemini under the product name grounding, and Google's AI Overviews over the search index itself.
Why RAG matters for brand visibility
Because retrieval is the door your content walks through. A bare model can only repeat what it absorbed about you in training: old, and skewed toward big names. A RAG system re-decides every single time which pages to read, which means today's content, this month's reviews and a brand the model has never heard of can all enter today's answer. Practically all near-term AI visibility work is really about winning the retrieval step.
Being the document RAG retrieves
The chain has three links, and each one fails silently. Findable: the retrieval search has to surface your page for the rewritten queries (classic search visibility, still). Fetchable: the engine's crawler must be able to reach and parse the page; blocked bots and JavaScript-only content end the story early. Quotable: RAG systems lift passages, not pages. A self-contained paragraph that answers one question cleanly beats a beautiful page that never commits to a statement (chunk optimization).
RAG vs fine-tuning
The other way to teach a model new things is fine-tuning: additional training that changes the weights. It is expensive, slow to update, and cannot cite where a fact came from. RAG is the opposite trade: the model stays fixed, knowledge stays current, and answers can point at sources. For search products the choice was never close, which is why the assistant ecosystem converged on RAG.
The limits worth knowing
RAG inherits retrieval's failures: if search returns nothing useful, the model falls back to memory and hallucination risk returns. It can misread or over-trust a bad source. And context windows are finite, so only a handful of passages make it in front of the model. Being findable is not enough; you have to be among the best few passages for the question. That competition is what AI visibility measurement tracks from the outside.
RAG beyond the chatbots you see
The consumer assistants are the visible tip. The same architecture now runs inside products your buyers use without calling it anything: support widgets answering from a company's docs, enterprise copilots answering from intranets and the public web, shopping assistants retrieving product data mid-conversation. Each of these is another surface where retrieved text (sometimes yours) gets synthesized into an answer someone acts on.
The strategic read: content you publish is no longer consumed only by readers and rankers, but by retrieval systems you will never see traffic from. A spec sheet clean enough to be quoted, a comparison honest enough to be trusted, a policy page unambiguous enough to be excerpted: these now work in rooms you are not in. Which is one more reason writing for extraction has quietly become a core content skill.
Auditing your own retrievability
You can test the retrieval chain from outside, engine by engine. Ask a search-enabled assistant to find an exact distinctive passage from your page. If it can return the URL, the page is demonstrably in that engine's retrieval path; if it cannot, you have a short technical checklist: is the page in the sitemap and internally linked, is the bot allowed through, does the content exist without JavaScript, is the passage distinctive enough to retrieve? Your server logs tell the other half of the story. AI bot log analysis shows which crawlers actually fetch you and what they read.
Then close the loop at the answer level: retrievable is necessary, cited is the goal. Tracking whether engines actually cite your pages on your category's real questions is the difference between "we could appear" and "we do".