Key takeaways

What this course actually claimed

Every advanced RAG technique exists to fix one specific failure. Learn the failure first and the technique becomes obvious; learn the technique first and you rebuild your pipeline around a graph database to solve what was a bad chunk boundary. The failure map in lesson 1 and the decision table in lesson 39 are the same artefact, opened and closed.

Most RAG failure is structural, not semantic. Four of the five queries that broke the naive baseline failed because the pipeline destroyed something at ingest — a table's geometry, a cross-reference, a link between records, a visual channel. No query-time cleverness restores information that was discarded before the index was built. Not one of the five was fixed by a better embedding model.

The stage you observe is never the stage that failed. Quality is visible at generation and caused anywhere across six stages. That asymmetry is why lesson 35 is about attribution rather than dashboards, and why the single most valuable thing to log is whether the answer's document was in the candidate set at all.

A reranker cannot fix a recall failure. It reorders what search already found. Against an answer that never became a candidate it is a no-op with 220 ms attached — and it is the most common first response to a retrieval problem.

Every retrieval loop is a harness. CRAG, Self-RAG, multi-hop and cross-reference resolution are one architecture with four different triggers: a grade from an external evaluator, tokens the model emits about itself, an entity the reasoning named, and a typed field saying the answer is incomplete. All four need a tool, a signal, a hard budget, and an honest exit.

Cross-reference resolution is not multi-hop RAG. Multi-hop plans the next hop from the question; signal-driven expansion reacts to a pointer in the retrieved text and resolves it by table lookup with no model call. Different triggers, different costs, different failure modes — and a corpus of well-drafted legal text needs the second far more often than teams expect.

Rank is the only currency your retrievers share. Reciprocal Rank Fusion beats score normalisation because a single outlier collapses min-max — one spam document at BM25 140 pushed the correct clause from first to fourth while RRF left the real documents in their exact order. That argument returns unchanged for multimodal and federated merging.

A single vector is a lossy summary, and the loss is specific. It cannot say "contains A and B and C". In the worked example the pooled vector picked the wrong document (0.357 vs 0.574) while MaxSim picked the right one (3.00 vs 1.00), because a maximum cannot be diluted by irrelevant tokens and a mean can.

Sometimes the right answer is to pay at index time, and sometimes it is to not retrieve at all. RAPTOR, IndexRAG, GraphRAG and bridging facts all trade an expensive index for a cheap query. CAG, an LLM wiki and vectorless navigation go further and delete the retriever. Corpus size, churn rate and whether you must explain the answer decide between them — three numbers per corpus segment, and that table settles more architecture than any evaluation you will run.

One organisation is usually in several regions of that table at once. Northwind's 40-document handbook, its 840 cross-referenced policies, its relational claim structure and its 11,000 hours of calls each want a different answer. The mistake is not picking the wrong technique — it is picking one technique for an organisation that needs four.

Route before you optimise anything else. If most traffic takes a cheap path and a little takes none, you have roughly halved average cost while making the hard minority better with the budget you freed. Nothing else in Part 7 comes close.

Build in this order: ask whether this corpus needs retrieval at all, then measure, then take the free wins, then fix ingest, then improve retrieval, and add loops last — because loops are very good at masking ingest bugs by papering over them at query time.