Build a RAG Pipeline
Wire it all together: index your docs once, then for each question retrieve, augment the prompt, and generate a grounded answer.
You’ve done the hard parts: your docs are embedded (L13) and indexed in pgvector (L14). But your support bot still invents refund policies. The missing piece isn’t storage — it’s the last mile: actually pulling the right chunk out and putting it into the prompt with an instruction to use it. This lesson connects every piece into one working pipeline, and you’ll assemble the grounded prompt yourself.
Two phases: index once, query every time
A RAG pipeline splits cleanly in two. Indexing happens ahead of time, once per document: split the doc into chunks, embed each chunk (L13), and store the vectors in your database (L14). Querying happens on every request: embed the question, retrieve the top-k nearest chunks, augment the prompt with them, and generate the answer. Indexing builds the searchable library; querying reads from it. Keeping the two phases straight is most of understanding RAG.
Retrieve → augment → generate (the step everyone forgets)
Beginners stop at “I stored the vectors” and wonder why the bot still hallucinates. Retrieval only hands you text; the model can only use what’s in its prompt. So you must take the retrieved chunks and build a grounded prompt: the context, the question, and an explicit instruction — answer using only this context, and if the answer isn’t here, say you don’t know. That instruction is what converts a fluent guesser into a grounded answerer and gives it permission to admit ignorance instead of inventing.
The assembled prompt for the refund question: Context: """ Refunds are available within 30 days of the original purchase date. """ Question: What is our refund window? Instruction: Answer using ONLY the context above. If it isn’t there, say you don’t know. → Model: “30 days.” Grounded in your text, with a built-in escape hatch when the docs don’t cover it.
Generate, cite — and remember: garbage in, garbage out
The model now answers from the context, and because you know which chunks you inserted, you can show them as citations — letting users verify the source. One honest caveat sets up the next lesson: the answer is only as good as what you retrieved. If retrieval returns the wrong chunk, even a great model will answer from the wrong text. RAG doesn’t make a model omniscient — it makes it grounded in whatever you fed it. Getting retrieval right is the focus of L16.
It’s an open-book exam. Indexing is the prep the night before: you split your notes into sections and add labeled tabs so you can find anything fast. The exam (a query) gives you a question; you flip to the right tabbed page (retrieve), read it, and write your answer from that page (augment + generate). If the page doesn’t cover the question, you write “not covered” instead of bluffing — that’s your grounding instruction.
End-to-end, one request to a support bot: 1. (Indexed earlier) Help docs were chunked, embedded, and stored in pgvector. 2. User asks: “How long do I have to return something?” 3. Embed the question → query vector q. 4. Retrieve top-3 nearest chunks → the top hit is the “Refunds within 30 days” paragraph. 5. Augment: build the prompt with that chunk as Context, the question, and “answer only from the context.” 6. Generate: the model replies “You have 30 days,” and you display the source chunk as a citation. No shared keywords needed, no hallucinated policy — the answer came from your real document.
This is the reading. The interactive version — active-recall quiz, a hands-on experiment you run in your own AI, and an earned mastery check — is free in the app.
Start this lesson free →