RAG isn't a separate architecture from agents — inside an agent, retrieval is just one more tool the reasoning loop can decide to call.
1RAG as a Tool, Not a Separate Pipeline
A standalone RAG chatbot always retrieves before every answer. An agent's search_docs tool is different: the reasoning loop decides whether retrieval is even needed for the current step, and can call it zero, one, or several times depending on what the task actually requires — retrieval becomes one option among the agent's tool belt, not a mandatory first step.
2Keyword Overlap Is a Real, Cheaper Trade-Off
Scoring shared exact words is fast, requires no external API call, and works well when queries and documents share vocabulary — exactly what just happened with 'ethernet cable.' It fails when a query and a relevant chunk describe the same idea with different words entirely, which real embedding-based retrieval (covered in depth in this platform's RAG Masterclass) handles far better by comparing meaning, not literal text.
3Step-by-Step Breakdown
search_docs Stops Being a Placeholder. Since Module 1, search_docs has just echoed back its query as fake text. Real retrieval means actually scoring the chunks from Module 2's chunking lesson against the query and returning the one that's genuinely most relevant — this is the exact RAG mechanism from this platform's RAG Masterclass, now wired into an agent's own tool instead of a standalone chatbot.
Wire Up Real Retrieval. score() is done — it counts real shared words between the query and a chunk. search_docs loops through every real chunk but never actually keeps track of which one scored best. Finish it so it does.
This keyword-overlap search picked the ethernet-cable chunk correctly, but it's a much simpler technique than real embeddings. What's a real weakness of scoring by exact shared words alone?
- →It only matches literal shared words, so a query and a relevant chunk that describe the same thing with different vocabulary (synonyms, rephrasing) score zero overlap even though they're semantically related.
- →It's a real weakness because keyword scoring runs too fast to be useful.
Module 2 Complete: A Grounded, Remembering Agent. TriageAgent now retrieves real relevant chunks and manages its own bounded memory. What it still can't do is specialize — right now every decision runs through the same general-purpose model and the same hand-written prompts. Next module: when and how fine-tuning changes that.
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)
1Surface Which Chunk Was Retrieved, Not Just the Final Answer
An agent trace UI showing search_docs was called should display which chunk it actually returned, so a user can judge whether the retrieval itself was relevant, independent of the final answer's quality.
<span>Retrieved: "the ethernet cable firmly..."</span>SEO Implications
- 1
Target 'retrieval as an agent tool' and 'keyword search vs embedding search' separately
Developers designing an agent's retrieval tool search for the agent-integration pattern and the underlying technique comparison independently.
Best Practices
Start With the Simplest Retrieval That Could Work, Then Upgrade
Keyword overlap is trivial to implement and debug — validating the rest of the agent's loop against it first, before adding embedding-based retrieval's extra cost and API dependency, isolates bugs faster.
Frequent Bugs
Forgetting to update best_score inside the comparison, only updating best_chunk.
Without updating best_score too, every subsequent chunk is compared against the stale initial value (-1), so any positive score after the first replaces best_chunk regardless of whether it's actually higher.
Real-World Examples
Hybrid Retrieval
Production systems often combine keyword-based and embedding-based scoring, since keyword matching catches exact terms (product names, error codes) that embeddings can sometimes under-weight relative to overall semantic similarity.
final_score = 0.3 * keyword_score + 0.7 * embedding_score