Advanced RAG is everything you add around plain "embed the question, grab the top-k chunks" to make retrieval actually reliable. GraphRAG is the boldest of those moves: it pre-builds a knowledge graph so the model can reason across the whole corpus, not just the nearest few snippets.
Where you meet it
- A chatbot over your docs that nails single facts but flubs "summarize the main themes across all of this".
- Questions whose answer is scattered over many chunks, or needs several hops to connect.
- Production RAG stacks: hybrid search, query rewriting, and rerankers bolted onto a vector store.
What it does
It closes the gaps naive RAG leaves. A single semantic lookup is fast but blind to global structure: it can't see how facts relate, and it can't aggregate. Advanced RAG adds stages before retrieval (rewrite the query), during (search smarter), and after (re-score what came back) — so vague, multi-hop, and whole-corpus questions still land good context.
More machinery isn't more answers — measure first. If naive RAG already lands, extra stages only buy you latency and bugs.
How it works
The cards walk the pipeline; here's the mechanism underneath each piece.
- Hybrid search — run dense (embedding) and sparse (
BM25keyword) retrieval together and fuse the rankings. Embeddings catch meaning; keywords catch exact names and rare terms embeddings blur. - Query rewriting / HyDE — an LLM reshapes the question before search: paraphrase it, split it into sub-questions, or have it draft a hypothetical answer and embed that (HyDE) — answers sit closer to real documents than questions do.
- Reranking — over-fetch ~50 cheap candidates, then a cross-encoder reads each
(query, doc)pair jointly and re-scores, surfacing the true top 5. - GraphRAG — for the questions all of the above still miss. An LLM extracts entities + relations into a knowledge graph, clusters it into communities, and summarizes each. A global query then reasons over those summaries; a local one walks the graph from an entity outward — both impossible for flat vector RAG.
Watch out
- The graph is expensive to build. Entity + relation extraction means an LLM pass over your whole corpus — real indexing cost and time, re-paid on every refresh.
- More machinery ≠ better answers. Measure first. If naive RAG already answers your questions, the extra stages just add latency and bugs.
- Quality rides on entity extraction. A messy graph yields messy communities yields messy global answers — garbage in, garbage graph.
- Latency stacks. Rewrite + multi-query + rerank each adds a model call; budget the round-trips before you ship.
Go deeper
Advanced RAG ist alles, was du rund um das schlichte „Frage embedden, top-k Chunks greifen" baust, damit Retrieval wirklich verlässlich wird. GraphRAG ist der mutigste dieser Schritte: Es baut vorab einen Knowledge Graph, damit das Modell über den ganzen Corpus schließen kann — nicht nur über die nächsten paar Snippets.
Wo es vorkommt
- Ein Doku-Chatbot, der Einzelfakten trifft, aber an „fasse die Hauptthemen über alles zusammen" scheitert.
- Fragen, deren Antwort über viele Chunks streut oder mehrere Hops zum Verbinden braucht.
- Produktiv-RAG-Stacks: hybride Suche, Query-Rewriting und Reranker auf einem Vector Store.
Was es tut
Es schließt die Lücken, die naives RAG lässt. Ein einzelner semantischer Lookup ist schnell, aber blind für die globale Struktur: Er sieht nicht, wie Fakten zusammenhängen, und kann nicht aggregieren. Advanced RAG ergänzt Stufen vor dem Retrieval (Query umschreiben), währenddessen (klüger suchen) und danach (Treffer neu bewerten) — so bekommen auch vage, mehrstufige und Gesamt-Corpus-Fragen guten Kontext.
Mehr Maschinerie heißt nicht mehr Antworten — erst messen. Reicht naives RAG, kaufen Extra-Stufen nur Latenz und Bugs.
Wie es funktioniert
Die Karten laufen die Pipeline ab; hier der Mechanismus unter jedem Baustein.
- Hybride Suche — dense (Embedding) und sparse (
BM25-Keyword) parallel suchen und die Rankings fusionieren. Embeddings fangen Bedeutung; Keywords fangen exakte Namen und seltene Begriffe, die Embeddings verwischen. - Query-Rewriting / HyDE — ein LLM formt die Frage vor der Suche um: paraphrasieren, in Teilfragen splitten, oder eine hypothetische Antwort entwerfen und die embedden (HyDE) — Antworten liegen näher an echten Dokumenten als Fragen.
- Reranking — ~50 billige Kandidaten über-holen, dann liest ein Cross-Encoder jedes
(Query, Doc)-Paar gemeinsam und bewertet neu, bis die echten Top 5 oben stehen. - GraphRAG — für die Fragen, die all das noch verfehlt. Ein LLM extrahiert Entitäten + Relationen zu einem Knowledge Graph, clustert ihn in Communities und fasst jede zusammen. Eine globale Frage schließt dann über diese Summaries; eine lokale läuft vom Entity nach außen durch den Graph — beides unmöglich für flaches Vektor-RAG.
Worauf achten
- Der Graph-Aufbau ist teuer. Entitäts- + Relationsextraktion heißt ein LLM-Durchlauf über den ganzen Corpus — echte Indexing-Kosten und -Zeit, fällig bei jedem Refresh.
- Mehr Maschinerie ≠ bessere Antworten. Erst messen. Reicht naives RAG für deine Fragen, bringen die Extra-Stufen nur Latenz und Bugs.
- Die Qualität hängt an der Entitätsextraktion. Ein schludriger Graph ergibt schludrige Communities ergibt schludrige globale Antworten.
- Latenz summiert sich. Rewrite + Multi-Query + Rerank kosten je einen Modell-Call; kalkuliere die Round-Trips, bevor du ausrollst.



