Module 7 12 min

Why RAG Exists

The knowledge cutoff problem and the retrieval solution.

Ask a language model about your company's refund policy, last week's incident report, or a contract signed yesterday, and it will do one of two things: admit it doesn't know, or — worse — make something up with total confidence. Retrieval-Augmented Generation (RAG) is the standard fix, and it's the backbone of almost every "chat with your docs" product you've ever seen.

Why does this exist?

LLMs are frozen in time and blind to your data. Training ends at a cutoff date, and your private documents were never in the training set at all. RAG exists because retraining a model for every new document is absurdly expensive, while pasting the right documents into the prompt at question time is cheap, fast, and surprisingly effective.

The problem: a brilliant intern with amnesia

Think of an LLM as a brilliant intern who read most of the public internet — up to some cutoff date — and then was locked in a room with no phone. Three failure modes follow directly:

  • Knowledge cutoff. Anything that happened after training simply isn't in there. "Who won yesterday's match?" is unanswerable.
  • Private data blindness. Your wiki, your tickets, your database — the model has never seen any of it.
  • Hallucination. When the model doesn't know, it doesn't return an error. It predicts plausible-sounding tokens, which is how you get confidently invented policy clauses and fake citations.

You met hallucinations back in the LLM module. RAG is the most widely deployed mitigation, because it changes the model's job from recall to reading comprehension.

The idea: open-book exams

A closed-book exam tests what you memorized. An open-book exam tests whether you can find the right page and reason about it. RAG turns every question into an open-book exam:

  1. 1. User asks a question"How long do refunds take to process?" — something the model was never trained on.
  2. 2. Retrieve relevant text
  3. 3. Augment the prompt
  4. 4. Generate the answer

That's the whole trick. "Retrieval-Augmented Generation" is a fancy name for search first, then ask the model to answer using the search results.

Why not just paste in all the documents?

If context windows are big, why retrieve at all — why not stuff the entire knowledge base into every prompt?

  • Cost. You pay per token, every single request. A 500-page handbook in every prompt burns money.
  • Context limits. Even large context windows can't hold a real document corpus (think gigabytes of wiki pages and PDFs).
  • Accuracy. Models get measurably worse at using information buried in the middle of huge contexts — the "lost in the middle" problem. A few relevant passages beat a mountain of noise.

Retrieval is a relevance filter: spend your context budget only on text that actually matters for this question.

Why not fine-tune instead?

Fine-tuning (covered in a later module) adjusts the model's weights on your data. It's great for teaching style, format, and behavior — but it's a poor way to teach facts:

  • It's slow and costly to re-run every time a document changes.
  • Facts learned via fine-tuning can still be hallucinated or blended incorrectly.
  • You can't cite sources — there's no way to point at where an answer came from.

RAG updates instantly (add a document, it's searchable), keeps data access controllable per user, and lets you show citations. Most production systems that need current or private knowledge choose RAG first, fine-tuning later if ever.

What a minimal RAG call looks like

Even before we build a real pipeline, the shape is worth seeing. Retrieval aside, the "augmented generation" part is just prompt assembly:

question = "How long do refunds take to process?"

# Pretend retrieval found these (next lessons: how it actually finds them)
retrieved_chunks = [
    "Refunds are processed to the original payment method within 5-7 business days.",
    "Customers may request a full refund within 30 days of purchase.",
]

prompt = f"""Answer the question using ONLY the context below.
If the context doesn't contain the answer, say "I don't know."

Context:
{chr(10).join('- ' + c for c in retrieved_chunks)}

Question: {question}"""

Two details matter here. First, the instruction to use only the context — that's your anti-hallucination guardrail. Second, the explicit permission to say "I don't know" — without it, models feel obligated to answer anyway.

Build it yourself

Take any LLM chat interface you have access to and run this experiment:

  1. Ask a question about a private document (e.g. "What's the guest Wi-Fi password in our office handbook?"). Note the failure — refusal or hallucination.
  2. Now paste two or three relevant paragraphs from that document into the prompt above the question. Ask again.
  3. Finally, paste irrelevant paragraphs and ask. Watch what the model does when the context doesn't contain the answer — this is why the "say I don't know" instruction earns its keep.

You've just performed RAG manually. Everything in the next three lessons automates step 2.

Summary

  • LLM knowledge is frozen at the training cutoff and never included your private data; when models don't know, they often hallucinate.
  • RAG = retrieve relevant text, paste it into the prompt, ask the model to answer from that context.
  • It beats "paste everything" on cost, context limits, and accuracy — and beats fine-tuning for facts that change and answers that need citations.
  • The prompt-side guardrails: "use only the context" and "say I don't know if it's not there."
  • Next up: the first real engineering decision in any RAG system — how to split documents into chunks.