GraphRAG — wann sich Wissensgraphen lohnen
GraphRAG erschließt korpusweite Fragen mit einem LLM-extrahierten Wissensgraphen, Leiden-Communities und vorberechneten Zusammenfassungen. Wir prüfen die Evidenz — 70–80 % Gewinnrate bei Vollständigkeit, 0,1 % Indexierungskosten und 700-fach günstigere globale Abfragen mit LazyGraphRAG — und leiten fünf Regeln dafür ab, wann Hybrid-RAG dennoch günstiger, schneller und genauer bleibt.
Warum Vektorsuche an globalen Fragen scheitert
Vektor-RAG ruft die k Textabschnitte ab, deren Embeddings der Frage am ähnlichsten sind, und übergibt sie einem Sprachmodell. Für lokale Fragen wie "Wer hat Vertrag X unterschrieben?" genügt das, weil die Antwort in wenigen Abschnitten steht. Globale Fragen wie "Was sind die Hauptthemen in diesen 10.000 Dokumenten?" verlangen dagegen den gesamten Korpus. Sie sind Aufgaben der abfragefokussierten Zusammenfassung (Query-Focused Summarization), nicht des Retrievals; weder ein Reranker noch ein größeres Top-k behebt diesen strukturellen Unterschied.
Microsoft Research formalisierte dieses Problem in "From Local to Global" (Edge et al., arXiv:2404.16130, erstveröffentlicht April 2024). Die Diagnose lautet: Naives Top-k-Retrieval findet Abschnitte, die der Formulierung ähneln, nicht zwingend die Texte, die eine vollständige Antwort tragen, und erzeugt so plausible, aber irreführende Zusammenfassungen. GraphRAG setzt deshalb früher an und baut einmalig Struktur über den Korpus auf.
Was Microsoft GraphRAG tatsächlich aufbaut
Die Open-Source-Pipeline graphrag (auf GitHub seit dem 2. Juli 2024, Version 3.1.1 mit Stand Juli 2026) arbeitet in Stufen. Sie zerlegt Dokumente in TextUnits und lässt ein LLM aus jeder Einheit Entitäten, Beziehungen und Aussagen (Claims) extrahieren. Die Ergebnisse werden zu einem korpusweiten Wissensgraphen zusammengeführt, dessen Knoten und Kanten LLM-geschriebene Beschreibungen tragen.
Diesen Graphen partitioniert Leiden-Community-Detection (Traag et al. 2019), ein hierarchisches Clusterverfahren, das Gruppen dicht verbundener Entitäten findet. Für jede Community auf jeder Hierarchieebene schreibt ein LLM eine Zusammenfassung — von unten nach oben, Blatt-Zusammenfassungen fließen in Eltern-Zusammenfassungen ein. Das Ergebnis ist eine geschichtete, vorberechnete Beschreibung des Korpusinhalts, bevor jemand eine Frage gestellt hat.
Globale und lokale Abfragemodi
Zur Abfragezeit bietet graphrag vier Modi. Global Search beantwortet korpusweite Fragen per Map-Reduce: Community-Zusammenfassungen werden zu Kontextfenstern gruppiert, jede Gruppe liefert eine Teilantwort (Map), und die Teilantworten werden zu einer Endantwort verdichtet (Reduce). Local Search startet bei den in der Frage erkannten Entitäten und expandiert zu Nachbarn, Textstellen und Community-Reports — geeignet für Fragen zu konkreten Entitäten.
DRIFT Search verbindet lokale Expansion mit Community-Kontext. Basic Search hingegen ist schlichtes Top-k-Vektor-Retrieval. Dass die Bibliothek diesen Modus mitliefert, macht die Abgrenzung der Autoren deutlich: Viele Abfragen beantwortet Baseline-RAG am besten. Das sollten Sie bei der Bewertung des Frameworks ernst nehmen.
Was die Evaluationen messen
Die Original-Evaluation nutzte zwei Korpora von je rund einer Million Token (Podcast-Transkripte und Nachrichtenartikel) und einen LLM-Richter, der Antworten paarweise nach Vollständigkeit (Comprehensiveness), Diversität, Empowerment und Direktheit verglich. GraphRAGs Global Search schlug naives Vektor-RAG mit rund 70–80 % Gewinnrate bei Vollständigkeit und Diversität. Mit Zusammenfassungen der obersten Community-Ebene blieb es konkurrenzfähig zur vollständigen Map-Reduce-Zusammenfassung der Quelltexte — bei etwa 2–3 % der Token-Kosten pro Abfrage.
Die Ergebnisse brauchen zwei Einschränkungen. Die Gewinnraten stammen von einem LLM-Richter statt aus Ground-Truth-Genauigkeit, und bei Direktheit lag naives RAG vorn. Eine unabhängige systematische Evaluation (arXiv:2502.11371) zeigt auf klassischen QA-Benchmarks das Gegenbild: RAG war bei Single-Hop- und Detailfragen stärker, während GraphRAGs Global Search Details verlor und unbeantwortbare Fragen mit Halluzinationen statt mit "unzureichende Information" quittierte.
Die ehrliche Kostenrechnung
Volles GraphRAG-Indexieren schickt jeden Textabschnitt durch LLM-Extraktionsprompts; die Extraktion dominiert die Token-Rechnung. Microsofts eigene Kostenanalyse macht die Lücke konkret: Das Embedding des kompletten "Wizard of Oz" kostete 0,0056 US-Dollar, der Graphaufbau mit GPT-4o mini rund 0,011 US-Dollar pro 1.000 Wörter — etwa das 80-Fache der Embedding-Kosten — und mit GPT-4-Turbo, dem Modell des Original-Papers, ein Mehrfaches davon. Globale Abfragen dauerten 20–24 Sekunden.
Der Graph ist zudem ein abgeleitetes Artefakt, kein Speicher. Ändern sich Dokumente, muss die Extraktion erneut laufen oder inkrementell nachgeführt werden; vorberechnete Community-Zusammenfassungen veralten. Die Extraktion ist außerdem verlustbehaftet: Die genannte Evaluation maß, dass nur 65,8 % der Antwort-Entitäten für HotpotQA überhaupt im konstruierten Graphen vorhanden waren. Jede fehlende Entität ist eine Frage, die der Graph nicht beantworten kann — so elegant die Traversierung auch sein mag.
LazyGraphRAG verschiebt die Ökonomie
LazyGraphRAG (Microsoft Research, 25. November 2024) kehrt das Design um: Fast die gesamte LLM-Arbeit wird auf die Abfragezeit verschoben. Indexiert wird mit leichtgewichtigem NLP — Nominalphrasen-Extraktion und Kookkurrenz-Analyse statt LLM-Aufrufen. Die Indexierungskosten sind dadurch identisch mit Vektor-RAG und betragen 0,1 % der Kosten von vollem GraphRAG.
Zur Abfragezeit kombiniert das Verfahren Best-First- und Breadth-First-Suche, gesteuert über einen einzigen Parameter, das Relevance Test Budget. Microsoft berichtet vergleichbare Antwortqualität zu GraphRAG Global Search bei über 700-fach niedrigeren Abfragekosten; bei 4 % der Global-Search-Abfragekosten übertraf LazyGraphRAG alle acht getesteten Bedingungen signifikant — lokal wie global. Im Nachfolge-Benchmark BenchmarkQED (5. Juni 2025) gewann es alle 96 Vergleiche gegen Baselines mit demselben Modell, einschließlich Vektor-RAG mit einem Kontextfenster von einer Million Token.
| Ansatz | Indexkosten | Abfragekosten | Stark bei | Schwach bei |
|---|---|---|---|---|
| Hybrides Vektor-RAG | Nur Embeddings (minimal) | Niedrig | Single-Hop-Lookups und Details | Korpusweite Synthese |
| GraphRAG Local Search | Voller LLM-Graphaufbau | Moderat | Entitätszentrierte Multi-Hop-Fragen | Indexkosten und Veralterung |
| GraphRAG Global Search | Voller LLM-Graphaufbau plus Zusammenfassungen | Hoch (Map-Reduce über Communities) | Themen und globale Synthese | Details; unbeantwortbare Fragen |
| LazyGraphRAG | ~Vektor-RAG (0,1 % von vollem GraphRAG) | >700-fach unter Global Search bei gleicher Qualität | Lokale und globale Abfragen | LLM-Latenz zur Abfragezeit |
Wann Hybrid-RAG die bessere Wahl bleibt
Nichts davon hebt den Basisfall auf. Eine Analyse von 2025 (arXiv:2506.05690) trägt Befunde früherer Studien zusammen: GraphRAG erreichte auf Natural Questions 13,4 % niedrigere Genauigkeit als Standard-RAG, verursachte im Mittel rund 2,3-fache Latenz und gewann auf HotpotQA-Multi-Hop-Fragen nur 4,5 %. Dominieren Single-Hop-Lookups Ihr Abfrageprotokoll — "Wie lang ist die Kündigungsfrist in Vertrag X?" —, ist hybrides Retrieval (BM25 plus Vektoren plus Reranker) günstiger, schneller und oft genauer.
Die Verfahren sind daher komplementär. In der systematischen Evaluation verbesserte sowohl das Routing per Klassifikator zu RAG oder GraphRAG (Selection) als auch die gemeinsame Übergabe beider Kontexte an den Generator (Integration) die MultiHop-RAG-Genauigkeit um bis zu 6,4 Punkte gegenüber der besten Einzelmethode. Der Graph rechtfertigt sich damit für ein klar umrissenes Abfragesegment, ersetzt den Vektorindex aber nur selten.
Fünf Entscheidungsregeln
1. Beginnen Sie mit Hybrid-RAG und instrumentieren Sie es. Loggen und klassifizieren Sie Abfragen: lokaler Lookup, Multi-Hop-Schlussfolgerung, korpusweite Synthese. Entscheiden Sie auf Basis von Daten, nicht von Demos. 2. Bleiben Sie bei Hybrid-RAG, wenn weniger als rund 10 % der Abfragen dokumentübergreifendes Schließen oder Zusammenfassen benötigen — die Betriebskosten des Graphen amortisieren sich über den Rest nicht.
3. Testen Sie LazyGraphRAG vor vollem GraphRAG, wenn globale Fragen relevant sind. Die Indexierungskosten entsprechen Vektor-RAG, das Experiment ist also fast kostenlos; erhöhen Sie das Relevance Test Budget, bis die Antwortqualität sättigt. 4. Reservieren Sie volles GraphRAG mit vorberechneten Community-Zusammenfassungen für leseintensive, stabile Korpora mit vielen wiederkehrenden globalen Abfragen — dort amortisiert sich die Vorab-Zusammenfassung.
5. Behandeln Sie einen Produktionsgraphen als Datenprodukt. Er braucht einen Verantwortlichen, eine Aktualisierungs-Pipeline und Metriken für die Extraktionsqualität. Können Sie das nicht besetzen, bauen Sie ihn nicht — ein veralteter Graph antwortet aus einer Realität, die nicht mehr existiert, und tut das mit voller Überzeugung.
Wohin sich Graph-Retrieval entwickelt
Das Kostenargument gegen die Indexierung löst sich auf; der Engpass wandert zu Extraktionsqualität und Governance. Graph- und Vektor-Retrieval konvergieren zu einem Spektrum, das sich pro Abfrage über ein Budget einstellen lässt. Agentische Suche fügt zur Abfragezeit implizite Struktur hinzu: Eine Benchmark-Studie von 2026 (arXiv:2604.09666) zeigt, dass sie den Multi-Hop-Abstand zwischen dichtem RAG und GraphRAG verkleinert, aber nicht schließt.
Wir erwarten Retrieval-Stacks, die für jede Abfrage bestimmen, wie viel Struktur sie benötigen, sowie Wissensgraphen, die als gemeinsames und inspizierbares Gedächtnis für Multi-Agenten-Systeme dienen. Die Entscheidungsregeln bleiben dabei stabil: Struktur gehört nur dorthin, wo die Fragen ihren zusätzlichen Aufwand rechtfertigen.
Quellen
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Edge et al., arXiv:2404.16130)
- GraphRAG: New tool for complex data discovery now on GitHub — Microsoft Research Blog
- LazyGraphRAG: Setting a new standard for quality and cost — Microsoft Research Blog
- BenchmarkQED: Automated benchmarking of RAG systems — Microsoft Research Blog
- RAG vs. GraphRAG: A Systematic Evaluation and Key Insights (arXiv:2502.11371)
- When to use Graphs in RAG: A Comprehensive Analysis (arXiv:2506.05690)
- GraphRAG documentation — query modes and pipeline
- GraphRAG Costs Explained: What You Need to Know — Microsoft Tech Community
