You now know how to find a trustworthy source, store records in Postgres, ask precise questions with SQL, and retrieve passages by meaning with embeddings. That leaves the final assembly problem: how does a model actually use that retrieved material when it answers?

This lesson gives you the complete definition of retrieval-augmented generation — RAG — and shows where it helps, where it fails, and how to scope a first RAG feature.

What RAG means in plain English

Retrieval-augmented generation is an ordinary idea with an imposing name. Before answering, the system retrieves relevant source material and hands it to the model as context. The model then answers from what it was given, not from what it happens to remember.

Say it in one sentence: retrieve, then supply, then answer with links.

The full workflow looks like this:

Question → retrieve relevant source material → model reads supplied context → answer + source links

Notice what is separated. The data store holds your documents. Retrieval selects a small set of passages. The model reads only those passages plus the question. The answer carries links back to the originals. The model is not the database, and the database is not the model.

That separation is the whole point. A model trained months ago cannot have memorized your company handbook revision from last Tuesday. It does not need to. Retrieval fetches Tuesday's revision, the model reads it, and the reader can open it.

What RAG solves

A model on its own is good at patterns: explaining a concept, summarizing clearly, drafting, comparing, structuring an answer. It is weak at three things your product almost certainly needs:

• Current facts. Prices, filings, weather, policy versions, and inventory change after training ends.
• Private facts. Your handbook, tickets, contracts, and internal notes were never in the training data — and should not have been.
• Domain-specific facts. SEC filing structure, your product's error codes, or a hospital's discharge procedure need exact local detail, not a plausible approximation.

RAG solves this without any pretense that the model memorized your world. It turns the model from an oracle into a reader: a strong reader working from material you chose, with the sources still attached.

That is why RAG pairs naturally with everything you built in Part VI. Class 19 chose the sources. Class 20 stored them durably. Class 21 queries what is structured. Class 22 retrieves what is textual. Class 23 assembles the answer.

What RAG does not solve

Beginners treat RAG as a memory button: point it at a folder and expect truth. It does not work that way. RAG inherits every weakness upstream of the model:

• Bad sources. If the handbook is wrong, the grounded answer is confidently wrong with a citation attached.
• Missing sources. If no document covers the question, retrieval returns noise and the model improvises.
• Access errors. If permissions are ignored, the system can surface material the reader should never see.
• Irrelevant retrieval. If the query retrieves the wrong chunks, even a perfect model answers the wrong question.
• Ambiguous questions. "What is our refund policy?" means nothing until you know which product, region, and date apply.
• A model that ignores instructions. A model told to "use only the supplied context" can still drift beyond it if nobody checks.

Put simply: retrieval decides what the model gets to read. If retrieval is careless, generation cannot rescue it. Lesson 23.2 makes retrieval inspectable; Lesson 23.3 teaches you to evaluate it.

Two contrasting examples

A company-handbook assistant. The corpus is small and controlled: the current handbook, benefits guide, and IT policy, each with an owner, version date, and allowed audience. A question like "How many remote days per month can I take?" retrieves the two relevant policy sections, and the answer quotes the current version with a link to the exact page. When the policy changes, one document is replaced, the old version is retired, and the answer changes because the source changed — not because the model was retrained.

A Sonariq research assistant. The corpus is larger and interpretive: SEC EDGAR filings, FRED macro series, and the project's own Markdown research notes. A question like "What drove this company's margin change last year?" retrieves filing facts, the relevant XBRL concepts with period and unit preserved, and the analyst's prior interpretation — kept clearly labeled as interpretation, not source fact. The model synthesizes, but every number traces to a filing URL and every judgment traces to a dated research note.

Same workflow, different stakes. The handbook needs currency and permission control. Sonariq needs provenance across facts, series definitions, and human judgment. Both need visible evidence.

Filled example: what a one-paragraph brief looks like

Keep your RAG-BRIEF.md to this density — one paragraph a colleague can enforce:

>

Note the shape both follow: named question, named sources, one chunk type, answer format, exact-link rule. Copy the shape, not the content.

From a single workflow to an agent capability

It is tempting to jump from here to an autonomous research agent that browses, retrieves, and writes on its own. Resist that jump for one lesson.

Part VIII will teach agents properly: tools, boundaries, and multi-step work. An agent that calls a RAG feature is only as dependable as the underlying retrieval-and-answer workflow. So the discipline is: first make one question, one corpus, and one answer format work reliably with visible sources. Then let an agent call that tested workflow as a capability.

That is also the honest product story. The winning RAG feature is rarely "chat with everything." It is one useful question, one trusted source set, one retrieval policy, and one audience — working well enough that readers trust the links.

Practical exercise: scope one RAG feature

Write a one-paragraph RAG feature brief in a file called RAG-BRIEF.md. Include:

• The user question it answers.
• The allowed sources (named documents or source set, not "the internet").
• The retrieval unit (policy section, manual chunk, filing plus note — one chunk type).
• The answer format (short answer plus quoted evidence plus links, or a small report shape).
• How the user opens the source (exact page or section link, not a homepage).

Finish line: one paragraph in RAG-BRIEF.md a colleague could read and know exactly what the system may and may not answer from.

Verify: cover the sources line and re-read the question. Can a stranger name which documents the system may read and how the user opens each one? If not, the brief is still a wish.

Common failure mode: scoping the brief as "chat with everything" — an unbounded corpus with no named sources and homepage links instead of section links. One question, one named source set, one retrieval unit, links that open the exact passage.

Check your understanding

1. State the four-step RAG workflow without looking back. 2. Why does RAG remove the need to pretend the model memorized your data? 3. Name three failures RAG does not fix on its own. 4. Why should a dependable single workflow come before an agent capability?