Skip to content

RAG Explained Simply: The Name Nobody Loved

RAG explained simply: inventors hated the name, yet it fixed LLM hallucinations. Story of how retrieval works, 3 pitfalls, vs long context.

6 min readBeginner

Patrick Lewis, the guy who coined the term, later apologized for it. “We always planned to have a nicer sounding name, but when it came time to write the paper, no one had a better idea.” That line – from an NVIDIA interview – is what hooked me on RAG explained simply. The 2020 NeurIPS paper (arXiv:2005.11401) that launched Retrieval-Augmented Generation didn’t even like its own acronym. The technique stuck anyway, because it fixed the LLM failure I kept slamming into.

I was wiring a helper over a messy pack of HR PDFs – three “current” versions, none labeled cleanly. Plain chat calls invented rules that never existed and quoted clauses from a 2022 draft. Fine-tuning felt like bringing a forklift to move a desk. I stuck a retriever in front of the model instead. First answer that came back with a real page cite and matched the live file, I laughed out loud at my desk. That jolt is why this piece exists.

The Core Idea Behind RAG Explained Simply

Weights are great at language patterns. They’re shaky on your private facts and anything newer than the training cut. RAG adds a non-parametric memory: a searchable pile of your documents. At query time it fetches the relevant bits and stuffs them into the prompt so the model grounds the reply. Lewis et al. paired a seq2seq generator with a dense retriever over Wikipedia; you do the same with your own files. Per IBM’s overview, the model weights stay unchanged – you update knowledge by re-indexing the external store, not by retraining.

A Conceptual Walkthrough of the Pipeline

Here’s the flow I only internalized after a few broken prototypes.

  1. Prepare once: split docs into chunks, embed each chunk, store vectors plus original text and metadata in a vector database.
  2. User asks. Embed that question with the same embedding model.
  3. Similarity search (usually cosine) pulls top-k closest chunks.
  4. Glue those chunks into a prompt with the question – “Use only the following context…”
  5. LLM generates. Often you get citations back – not guaranteed.

Embedding turns words into numbers machines can rank; the generator then weaves retrieved text with language skill. The NVIDIA how-it-works writeup frames it as two systems talking, not magic.

// Mental model, not runnable code
query_vec = embed(user_question)
chunks = vector_db.similarity_search(query_vec, k=5)
prompt = f"Context:n{join(chunks)}nnQuestion: {user_question}nAnswer based only on context:"
answer = llm.generate(prompt)

I burned a weekend once because indexing used one embedding model and queries used another. Everything “looked similar.” Nothing relevant ranked high. Same model, same version – lock it.

Common Pitfalls That Tutorials Skip

Scatter shows up hard on comparison questions. “How do notification rules differ across these three policy versions?” Vector search loves the single most similar chunk. It rarely surfaces the full set of related pieces spread across 8-10 docs. Production legal-domain reports describe the same pattern: two or three decent hits, the rest missing, answer half-blind.

Negative knowledge is sneakier. Ask “Do we have any guidance on employee monitoring?” When the true answer is none, the retriever still returns the least-bad matches and the model synthesizes something plausible. It hates admitting absence.

Pro tip: Put an explicit “If the context does not contain the answer, say so clearly” line in every prompt, and log retrieval scores. A low max similarity score is your early warning that the system is guessing.

Chunking is the quiet accuracy killer. Naive fixed-size splits (think raw 512-character windows) routinely cut sentences, table rows, or clauses mid-thought. The embedding then represents garbage; retrieval “succeeds” on the wrong fragment; residual hallucination creeps back even though the right PDF was indexed. As of 2025-2026 community chunking guides, a practical start is recursive/structure-aware splitting around ~512 tokens with 10-20% overlap; parent-child setups beat flat fixed-size once you’re past the demo.

How RAG Stacks Up Against the Alternatives

Fine-tuning rewrites weights for tone, format, domain mannerisms. RAG leaves weights alone and injects facts at runtime. Facts change weekly? RAG. You need a house voice burned in? Fine-tune. Citations as a product requirement? RAG almost by default.

Factor RAG Long Context Fine-Tuning
Knowledge updates Re-index anytime Reload full prompt Retrain
Cost at scale Low (top-k only) High (full tokens) Upfront high, then cheap
Citations Native Manual None
Best for Large/changing corpora Small static sets that fit the window Behavior/style

Long context won on accuracy in one 2026 manufacturing safety training study – 73.1% correctness versus 65.4% for semantic RAG – but burned roughly 26× the tokens per query (arXiv:2606.20898). For anything bigger than a handful of static docs, that tax compounds fast. Most teams I watch land on a hybrid: retrieve a tight set, then reason inside a moderate window.

One open question still nags me: how much of the leftover error is pure retrieval miss versus the generator stubbornly ignoring good context it already has? Papers keep chipping at it. The gap hasn’t closed.

FAQ

Does RAG completely stop hallucinations?

No. Incomplete or ambiguous chunks still leave room to invent. For anything high-stakes, read the cited passage yourself.

When should I pick long context instead of building RAG?

Entire knowledge base fits the window, stays mostly static, and query volume is low – just paste it. I prototyped a ~100-page policy pack this way in an afternoon; standing up a vector store would have been slower. Corpus grows, changes daily, or you need per-user access control and citations? Move to retrieval. Run both on your questions before you trust a slide deck.

What’s the smallest useful RAG I can try today?

Five to ten of your own Markdown or PDF files. Recursive chunker ~512 tokens, light overlap. Free local store (Chroma is fine). Embed a few questions you already know the base model botches, retrieve top-3, strict “answer only from context” system prompt into any LLM API. Under an hour you should feel the difference – and if ranks look random, check you didn’t mix embedding models (see the weekend I wasted above). That first correct citation teaches faster than another diagram.

Pick one document the base model always mangles. Run a tiny local retrieve-then-generate loop on it before you read another explainer. Watch what comes back.