Why Advanced RAG Is Not a List of Tricks

The situation this course is written for

You shipped a RAG system. It demoed well. Now it is in front of real users and it is wrong often enough that someone has started keeping a spreadsheet of the bad answers, and you have been asked what you are going to do about it.

So you go looking, and the internet hands you a pile of acronyms. CRAG, Self-RAG, RAPTOR, GraphRAG, ColBERT, RAG-Fusion, CAG, PageIndex, IndexRAG. Every one of them has a blog post claiming it is the upgrade you need. None of them tells you which of your bad answers it would have fixed, and several of them would have fixed none.

That is the actual problem with "advanced RAG" as a subject: it is taught as a catalogue. A catalogue is the wrong shape, because you do not have a catalogue-shaped problem. You have five specific wrong answers and a budget.

The organising claim

Every technique in this course exists because someone had a specific failure and built a specific fix. Learn the failure first and the technique becomes obvious. Learn the technique first and you end up rebuilding your pipeline around a graph database to solve a problem that was a bad chunk boundary.

So the spine of this course is a diagnostic tree, not a taxonomy. You start at the symptom you can actually observe, and it routes you to a family.

Read that map as a claim you are allowed to test. By lesson 39 you should be able to look at a wrong answer from your own system, place it on one of those seven rows, and name two techniques that would plausibly fix it and one that definitely would not.

Why the symptom is not where the cause is

There is a reason diagnosis is hard here, and it is structural rather than incidental.

A RAG pipeline has roughly six stages. You observe quality at the last one. Every stage before it can be the culprit, and by the time the failure is visible, the evidence of where it happened has been thrown away.

A table flattened at stage 1 cannot be un-flattened at stage 5. A distinction averaged away at stage 2 cannot be recovered by a better reranker at stage 4, because reranking only reorders what search already found — it can never add a document that stage 3 missed. This is worth saying twice, because "add a reranker" is the most common first response to a retrieval problem and it is a no-op against a recall failure.

That asymmetry drives a lot of the design decisions ahead. It is why several of the most effective techniques in this course do their work at index time rather than query time, and it is why lesson 35 is about attributing a bad answer to the stage that caused it rather than about dashboards.

What this course assumes you already have

This is not an introduction to RAG. It assumes you have built one and it assumes the vocabulary: embeddings, cosine similarity, top-k, ANN indexes, hybrid search, reranking, context assembly.

If any of that is unfamiliar, the honest path is to read Building RAG Systems first — it covers all of it in 23 lessons and it is free. This course begins where that one's last five lessons gesture, and it assumes you have made those gestures yourself at least once.

Three other courses own topics this one deliberately does not re-teach:

Chunking Strategies for RAG owns chunking — every strategy, late chunking, contextual retrieval, the production lifecycle. This course covers not chunking at all, in Part 6, and links back rather than repeating.

Vector Databases and ANN Search owns HNSW, IVF, product quantisation and the internals of similarity search. Part 4 here discusses graph stores as an architectural choice, not as data structures.

Loop Engineering and Agent Harnesses owns agent loops, budgets, circuit breakers and state. Part 3 is built directly on it: a corrective retrieval loop is a harness whose tool happens to be a retriever, and treating it as anything else is how people end up with a system that retrieves forever.

How the parts fit together

Parts 1 and 2 improve what comes back. Part 1 changes the query, Part 2 changes what is indexed and what is handed over. These are the cheapest interventions and you should exhaust them before anything else, because neither one changes your architecture.

Part 3 adds loops — the system checks its own evidence and goes again. This buys accuracy and costs latency, and the budget is the design.

Part 4 adds graphs, for the class of question where the answer exists but no single chunk holds it.

Part 5 leaves prose. Tables, code, audio, video — each one breaks a different assumption that text chunking quietly relies on.

Part 6 is the counter-argument to Parts 3 and 4, and it is the part most courses omit. Sometimes the right move is to precompute the structure, or to stop retrieving entirely.

Part 7 is production: latency, cost, observability, the pitfalls, and security. Part 8 is one capstone that puts a decision table in your hands.

On measuring any of this

Every lesson from here ends with a line on what to measure to tell whether the technique helped. Those are pointers, not a metrics curriculum — retrieval and generation metrics, judge calibration and golden sets are a subject of their own, and LLM Evaluation and Testing is where they live today.

The reason to say this explicitly rather than quietly: almost every number you will read in a RAG blog post is a single benchmark on a single corpus, and the effect sizes do not transfer. The techniques in this course are real and the papers behind them are real. Whether any of them helps your corpus is an empirical question that only you can answer, and the discipline of answering it — change one thing, measure, keep or revert — matters more than any individual technique here.

What to measure: before you change anything, get a baseline you trust. Twenty real questions with known correct answers, run today, scored by hand. Everything after this is a comparison against that.