Close the loop from Lesson 1: the exact same question, this time answered correctly because it's grounded in real retrieved data.
1What Actually Changed Since Lesson 1
The model itself is unchanged — same weights, same underlying capabilities. What changed is what's sitting in the prompt: the real, retrieved policy text is now physically present in the context window, with an explicit instruction to use only that text. The most statistically probable continuation of this prompt is now 'repeat the real number from the context' rather than 'invent a plausible one'.
2The Full Chain, Assembled
Embed the question (Module 1), retrieve and format the relevant chunks (Module 2), inject them into a strict grounding prompt and generate (this lesson) — that's a complete, working RAG pipeline. Everything from here forward is about making it more robust: handling questions the context doesn't cover, and hardening it for production use.
3Step-by-Step Breakdown
The Moment This Masterclass Pays Off. This is the exact question from Lesson 1 — the one a raw model confidently invented an answer to. This time, the real output of your retrieve() function goes into the prompt first, with a strict instruction to answer only from it. Run it and compare the answer to what you saw in Lesson 1.
Answer the Lesson 1 Question — Correctly. The context below is the real output of retrieve() from the last lesson: the two chunks a real embedding search would surface for this exact question. Run it and confirm the model reports the actual policy (5 days) instead of inventing one, the way it did back in Lesson 1.
In Lesson 1, a raw model invented a plausible-sounding PTO number. What single change made this lesson's answer correct instead?
- →The real policy text was retrieved and injected into the prompt as context, so the model had actual data to read instead of having to guess.
- →A more powerful, smarter model was used this time.
Grounded — But Not Yet Safe. Grounding fixes hallucination when the answer IS in your context. But what happens when a user asks something your retrieved chunks don't cover at all? Next lesson tests exactly that failure mode.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Distinguish Grounded Answers From Ungrounded Ones in the UI
A production RAG chatbot UI should visibly indicate when an answer is grounded in retrieved sources versus a general response, communicated through real text (not color alone) so screen reader users get the same signal.
<span>Grounded in 2 retrieved sources</span>SEO Implications
- 1
Target 'RAG system prompt example' as a distinct, high-intent search
Developers actively search for working grounding system prompt examples once they understand the retrieval half of RAG.
Best Practices
Always Pair Retrieved Context With an Explicit Grounding Instruction
Injecting context alone isn't enough — without an explicit 'use only this context, don't guess' instruction, the model may still blend in outside knowledge, undermining the entire point of retrieval.
Frequent Bugs
Injecting retrieved context without a system-level instruction to use it exclusively, so the model quietly mixes in pretrained knowledge.
Always pair injected context with an explicit constraint in the system prompt (like this lesson's), not just the raw data — the instruction is what forces the model to prioritize context over its own training.
Real-World Examples
HR Chatbot, Fixed
The same Nexora HR chatbot from Lesson 1 now answers the PTO rollover question correctly by retrieving and injecting the real policy text before generating — the exact fix a real engineering team would ship.
answer = llm.generate(system=STRICT_GROUNDING, context=retrieve(query), question=q)