The scenario

A company wants an internal assistant over three sources: a support-ticket archive (mostly short, self-contained text), an org chart and vendor-relationship database (structured, relationship-heavy data, who reports to whom, which vendors supply which products), and a library of recorded product-demo videos. Employees ask everything from "what is the escalation path for a billing complaint" (simple, single-source) to "which of our vendors are also used by the team that had the security incident last quarter" (multi-hop, cross-source) to "show me the part of the demo where we cover the pricing tiers" (video content, not text).

Working through the decision framework

Applying Lesson 21's sequence: the support-ticket archive alone would start at naive RAG, since it is clean and self-contained, likely upgraded to advanced RAG once real query patterns reveal noisy retrieval. The org chart and vendor data is exactly the relationship-heavy case Lesson 12 described, pointing at graph RAG rather than plain vector search, since "who reports to whom" and "which vendors supply which products" are relationships, not topics. The demo video library needs multimodal RAG (Lesson 19) to be searchable by content rather than only by filename or manual transcript.

The cross-source, multi-hop question ("vendors used by the team with the security incident") cannot be answered by any single one of these three retrieval strategies alone, it needs the org/vendor graph to identify the team and its vendors, then a lookup to confirm the incident. This is precisely the case for wrapping the whole system in modular RAG (Lesson 8), with a router sending each question to the right underlying strategy, or combination of strategies, and adaptive RAG (Lesson 20) to avoid running the simple billing-escalation questions through the same expensive multi-source reasoning the hard questions need.

tickets

org & vendors

demo videos

Employee Question

Adaptive Router

Which source?

Naive / Advanced RAG

Graph RAG

Multimodal RAG

Answer

Not one architecture: a modular system routing by source, wrapped in adaptive routing so simple questions never pay for the expensive path.

What this capstone is meant to leave you with

The right answer for this scenario is not one architecture, it is a modular system assembling naive/advanced RAG, graph RAG, and multimodal RAG behind an adaptive router, exactly the layered design the questions in Lesson 21 were built to arrive at. That is the actual outcome of this course: not memorizing nine names, but the ability to look at a real, messy set of data sources and questions, and name which architecture, or combination, each part of it actually needs.

Where to go from here

From here, the specialized courses on this site go hands-on with individual pieces of what this course mapped out: the pgvector course builds real vector indexing and similarity search, the docling course builds a real chunking-to-queryable-index pipeline, and future courses in this series will go deep on hybrid search, graph construction, and agentic retrieval loops individually, each with real, runnable code behind it.