Advanced Techniques: RAG, ReAct & Agents
Module 08 — Advanced Techniques: RAG, ReAct & Agents
Goal: Connect everything so far into the three big advanced patterns that power real AI products: RAG (give the model your knowledge), ReAct (reason + act with tools), and agents (autonomous multi-step systems). Plus a tour of other advanced prompting methods worth knowing.
8.1 RAG — Retrieval-Augmented Generation
The problem
The model doesn’t know your private data (company docs, product manuals, your notes) and its training knowledge is frozen at a cutoff and can be wrong on specifics. Stuffing all your documents into every prompt is impossible (context limits) and expensive.
The idea
RAG = retrieve the few most relevant chunks of your knowledge and put them in the prompt, then ask the model to answer using them. The model becomes an open-book test-taker: it reasons with language skill but answers from the documents you supply.
User question ──► [Retriever finds top relevant chunks] ──► put chunks in prompt ──► Model answers using them
How retrieval works (embeddings + vector search, in plain terms)
- Chunk your documents into small passages (e.g., a few paragraphs each).
- Embed each chunk: an embedding model turns text into a list of numbers (a “vector”) that captures meaning. Similar meanings → nearby vectors.
- Store these vectors in a vector database.
- At query time, embed the user’s question the same way, and find the chunks whose vectors are closest (most semantically similar). Those are the relevant passages.
- Insert the retrieved chunks into the prompt and ask the model to answer from them.
You don’t need to build embeddings by hand to understand prompting for RAG — just know retrieval finds passages by meaning, not just keywords.
The RAG prompt (this is the prompt-engineering part)
Answer the question using ONLY the context below. If the answer is not in the
context, say "I don't have that information." Cite the source numbers you used.
Context:
[1] {retrieved chunk 1}
[2] {retrieved chunk 2}
[3] {retrieved chunk 3}
Question: {user question}
Key prompt techniques (all from earlier modules):
- “Use ONLY the context” + escape hatch (“say you don’t have it”) → cuts hallucination (Module 04).
- Number the chunks and ask for citations → traceability and trust.
- Clear delimiters between context and question (Module 02).
Why RAG is so popular
- Answers grounded in your up-to-date, private data.
- No expensive retraining — update the documents, not the model.
- Citations let users verify, building trust.
- Cheaper and more current than fine-tuning for factual knowledge.
RAG quality tips
- Chunking matters: too big = noisy/irrelevant; too small = lost context. Tune chunk size and overlap.
- Retrieve enough but not too much: top 3–8 chunks is common; more dilutes focus and costs tokens.
- Improve retrieval: hybrid search (keywords + vectors), re-ranking retrieved results, query rewriting (have the model rephrase the question for better retrieval).
- Garbage in, garbage out: if retrieval pulls the wrong passages, the answer is wrong. Most RAG failures are retrieval failures, not generation failures — evaluate retrieval separately (Module 09).
- Handle “not found” gracefully rather than forcing an answer.
8.2 ReAct — Reasoning + Acting
ReAct interleaves reasoning (Chain-of-Thought, Module 04) with acting (tool calls, Module 06) in a loop. The model thinks about what to do, takes an action, observes the result, thinks again — until it can answer.
The loop, conceptually:
Thought: I need the current population of Canada, then multiply by 0.1.
Action: search("current population of Canada")
Observation: ~41 million
Thought: 10% of 41 million is 4.1 million.
Action: calculator("41000000 * 0.1")
Observation: 4100000
Thought: I now have the answer.
Answer: About 4.1 million.
Why it’s powerful: pure reasoning can’t fetch facts; pure tool use lacks planning. ReAct combines them, so the model plans, gathers real information, adjusts based on what it finds, and avoids hallucinating (it looks things up). This pattern underlies most “AI assistant that uses tools” experiences and is the engine inside agents.
You can prompt ReAct explicitly (show the Thought/Action/Observation format as a few-shot example), but most modern tool-calling APIs implement this loop for you: the model emits a tool call (the “Action”), your code returns the result (the “Observation”), and it continues. Either way, the mental model is the same.
8.3 Agents — autonomous multi-step systems
An agent is an LLM-driven system that, given a goal, decides on its own what steps and tools to use, executes them in a loop, observes results, and continues until the goal is met — rather than following a fixed script.
Core components of an agent:
- A goal (from the user).
- An LLM “brain” that plans and decides next actions (often via ReAct-style reasoning).
- Tools it can call (search, code, APIs, databases — Module 06).
- Memory (short-term: the working context; long-term: notes/files/vector store it can read and write).
- A loop that runs: decide → act → observe → repeat, until done or a limit is hit.
Goal ─► [LLM plans next step] ─► [calls a tool] ─► [observes result] ─► back to plan ... ─► Done
Fixed chain vs. agent (important judgment call)
- A chain (Module 07) has steps you designed in advance — predictable, testable.
- An agent decides steps dynamically — flexible, handles open-ended tasks, but less predictable, harder to debug, can loop or go off the rails, and costs more.
Expert default: don’t reach for an autonomous agent when a fixed chain will do. Agents are appropriate when the task genuinely can’t be pre-scripted (the needed steps depend on what’s discovered along the way). Even then, constrain them.
Keeping agents under control
- Cap iterations / tool calls and set budgets (time, money, tokens).
- Restrict the toolset to what’s needed; gate dangerous tools behind confirmation (Module 06/10).
- Require a clear “done” condition.
- Log every thought, action, and observation for debugging and evals.
- Add human-in-the-loop checkpoints for high-stakes actions.
- Watch for loops (the agent repeating the same failing action) and add detection/early-stop.
Multi-agent systems (brief)
Sometimes multiple specialized agents collaborate (e.g., a “researcher” agent and a “writer” agent coordinated by an “orchestrator”). This can help on big tasks but multiplies cost and complexity and adds new failure modes (miscommunication, compounding errors). Start single-agent (or chained) and only go multi-agent when there’s a clear need.
8.4 Other advanced prompting techniques worth knowing
- Tree of Thoughts (ToT): instead of one reasoning chain, the model explores a branching tree of possibilities, evaluates them, and backtracks — like searching for a solution. Useful for puzzles/planning; expensive. Self-consistency (Module 04) is a lighter cousin.
- Least-to-most prompting: solve the easiest sub-problem first, then use its answer to tackle harder ones — a structured decomposition for problems that build on themselves.
- Step-back prompting: ask the model to first state the general principle/concept, then apply it to the specific question. Improves reasoning by grounding in fundamentals.
- Reflexion / self-reflection: the agent reflects on past failures (“that approach didn’t work because…”) and stores the lesson to do better next attempt.
- Generated knowledge: ask the model to first write out relevant facts/knowledge about the topic, then answer using that — helps on knowledge-heavy questions (but verify the generated “facts”).
- Prompt ensembling: run several different prompts (or phrasings) for the same task and aggregate — improves robustness at higher cost.
- Multimodal prompting: modern models accept images (and audio/video). Prompting principles carry over: be specific about what to look at and what output you want (“Describe the chart’s trend and output the data as a table”).
- Automatic prompt optimization: tools/methods (e.g., DSPy, APE-style approaches) that search for better prompts automatically against an eval set — the frontier where prompt engineering meets optimization (connects to Module 09).
You don’t need all of these daily, but recognizing them lets you reach for the right one and read the literature fluently.
8.5 How it all fits together
A capable real-world system often layers everything you’ve learned:
System prompt (Mod 3: persona + rules + guardrails)
+ RAG (Mod 8: retrieve your data)
+ Tools / ReAct (Mod 6 & 8: live data and actions)
+ Chaining/agent loop (Mod 7 & 8: orchestrate steps)
+ Structured output (Mod 5: machine-readable hand-offs)
+ Core techniques (Mod 4: few-shot, CoT, escape hatches throughout)
+ Evals + safety (Mod 9 & 10: make sure it actually works and is safe)
That stack — grounded in your data, able to act, reasoning step by step, orchestrated reliably, measured, and safeguarded — is what “expert-level applied prompt engineering” looks like.
Exercises
- RAG prompt. Paste 3 short “documents” (make them up) and a question. Write a RAG prompt that answers using only those docs, cites which doc, and says “I don’t have that information” when the answer isn’t present. Test with one answerable and one unanswerable question.
- Spot the retrieval failure. In #1, swap in 3 irrelevant documents. Confirm a well-written prompt now says it doesn’t have the info (instead of hallucinating). This proves most RAG errors are retrieval errors.
- ReAct by hand. Pick a question needing a lookup + a calculation. Write out the Thought/Action/Observation trace you’d want an agent to follow.
- Chain or agent? For each task, decide chain vs. agent and justify: (a) “Summarize each PDF in this folder,” (b) “Research the best laptop under $1000 for me and explain why,” (c) “Translate this document.”
- Constrain an agent. List 5 specific guardrails you’d add to a “book me a flight” agent before letting it run.
Key takeaways
- RAG grounds answers in your data by retrieving relevant chunks (by meaning) and prompting the model to answer from them — with “use only the context” + citations to cut hallucination. Most RAG failures are retrieval failures.
- ReAct interleaves reasoning and tool use in a think→act→observe loop; it’s the engine behind tool-using assistants.
- Agents autonomously plan and execute multi-step tasks with tools and memory — powerful but less predictable; prefer fixed chains unless the task truly needs dynamism, and always constrain agents.
- Many other techniques (ToT, step-back, reflexion, multimodal, auto-optimization) extend your toolkit.
- Real systems layer system prompts + RAG + tools + chaining + structured output + evals + safety.