GraphRAG 2026: Wann sich ein Wissensgraph im RAG wirklich rechnet – und wann er nur Tokens verbrennt

Kaum eine Technologie im RAG-Umfeld wurde in den vergangenen zwei Jahren so überhöht und anschließend so hart korrigiert wie GraphRAG. Die Erzählung war verführerisch: Statt Dokumente in Schnipsel zu zerlegen und nach Ähnlichkeit zu durchsuchen, extrahiert man Entitäten und Beziehungen, baut daraus einen Knowledge Graph und lässt das Sprachmodell auf einer echten Wissensstruktur arbeiten. In der Praxis stellten viele Teams nach dem ersten Indexierungslauf fest, dass die Rechnung nicht aufging – weder inhaltlich noch finanziell.

2026 lässt sich diese Frage endlich sauber beantworten, weil es belastbare Messungen gibt. Dieser Beitrag ordnet ein, welche Fragen ein Graph tatsächlich besser beantwortet, was er kostet, welche Variante für ein mittelständisches Unternehmen realistisch ist – und warum ausgerechnet der Graph das Datenobjekt ist, das man am wenigsten aus dem Haus geben sollte.

Welche Fragen Vektor-RAG strukturell nicht beantworten kann

Klassisches RAG arbeitet nach einem einfachen Prinzip: Chunking zerlegt Dokumente in Abschnitte, ein Embedding-Modell überführt jeden Abschnitt in einen Vektor, und beim Retrieval werden die k ähnlichsten Abschnitte an das Modell übergeben. Das funktioniert hervorragend, solange die Antwort in einem oder wenigen Abschnitten steht.

Die harte Grenze verläuft nicht dort, wo die Marketing-Folien sie gerne zeichnen. Es ist nicht „Multi-Hop generell" – bei mehrstufigen Fragen schlägt ein gut gebautes hybrides Vektor-Retrieval mit Reranking viele Graphverfahren nach wie vor. Die echte Grenze verläuft bei korpusweiten, aggregierenden Fragen:

• Beziehungen stehen in keinem einzelnen Chunk. „Welche unserer Reklamationsfälle hängen über dieselbe Vorlieferantencharge zusammen?" – die Verbindung entsteht erst aus vielen Dokumenten. Kein Top-k-Retrieval kann sie liefern, weil kein Abschnitt sie enthält.
• Globale Zusammenfassungsfragen brauchen Korpusübersicht. „Was sind die übergreifenden Themen in 4.000 Serviceberichten des letzten Jahres?" ist keine Suchfrage, sondern eine Syntheseaufgabe über den gesamten Bestand.
• Ähnlichkeit ist nicht Relevanz. Ein Vektorindex bringt Ihnen semantisch nahe Passagen. Bei einer Frage, deren Antwort aus einer Verkettung mehrerer Fakten besteht, ist der relevanteste Zwischenschritt oft der unähnlichste Text.

Wer diese drei Fälle nicht im Anforderungskatalog hat, braucht keinen Graphen. Diese Aussage ist unbequem, aber sie ist der ehrlichste Ausgangspunkt für jede Wirtschaftlichkeitsbetrachtung.

Wie GraphRAG funktioniert: Extraktion, Community, Retrieval

Die Referenzarchitektur stammt aus der Arbeit von Edge et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization (arXiv:2404.16130), deren Code Microsoft im Juli 2024 veröffentlichte. Sie besteht aus drei Stufen.

Stufe 1: Entity- und Relation-Extraktion

Über jeden Textabschnitt läuft ein Sprachmodell und extrahiert Entitäten (Personen, Organisationen, Bauteile, Verträge) sowie deren Beziehungen. Jeder Chunk wird also mindestens einmal durch ein LLM geschickt – häufig mehrfach, weil ein Gleaning-Durchlauf übersehene Entitäten nachträgt. Das ist mit Abstand der token-intensivste Schritt der gesamten Pipeline und der eigentliche Kostentreiber.

Stufe 2: Community-Detection und Summarisierung

Auf dem entstandenen Graphen läuft ein Community-Detection-Verfahren – im Original der Leiden-Algorithmus –, das dicht verbundene Knotencluster identifiziert. Für jede Community erzeugt das Sprachmodell anschließend eine Zusammenfassung, hierarchisch über mehrere Ebenen. Genau diese Community-Summaries sind der Mechanismus, mit dem GraphRAG globale Fragen beantwortet: Statt Chunks zu suchen, liest das Modell vorgefertigte Verdichtungen des gesamten Korpus.

Stufe 3: Graphgestütztes Retrieval

Zur Laufzeit unterscheidet die Originalpipeline zwischen Local Search (Einstieg über konkrete Entitäten, dann Traversal entlang der Kanten) und Global Search (Map-Reduce über die Community-Summaries). Praktisch eingesetzte Systeme kombinieren beides mit klassischer Hybrid Search aus BM25 und Vektorsuche, weil reines Traversal bei einfachen Faktenfragen unterlegen ist.

In der Originalstudie gewann diese Pipeline gegenüber naivem RAG 72 bis 83 % der paarweisen Vergleiche bei Comprehensiveness und 62 bis 82 % bei Diversity – und brauchte für die Beantwortung globaler Fragen bis zu 97 % weniger Tokens als das direkte Durchreichen des Quelltexts. Der Haken: Diese Ersparnis gilt für die Query-Zeit gegenüber einem Brute-Force-Baseline, nicht gegenüber schlankem Vektor-RAG – und sie ignoriert die Indexierung vollständig.

Die Kostenfalle – und wann sie tatsächlich entschärft wurde

Hier ist zuerst eine zeitliche Korrektur nötig, die in vielen Beiträgen fehlt: Der Kostensturz bei GraphRAG fand nicht 2026 statt, sondern 2024 und 2025. LazyGraphRAG wurde von Microsoft Research bereits am 25. November 2024 vorgestellt, LightRAG von der Data Intelligence Lab der University of Hong Kong ist ein EMNLP-2025-Paper. Was 2026 wirklich neu ist, sind zwei andere Dinge: eine belastbare Evaluationsgrundlage (GraphRAG-Bench, angenommen auf der ICLR 2026 am 26.01.2026) und die vertikale Vereinheitlichung von Graphkonstruktion und Retrieval, wie sie Youtu-GraphRAG demonstriert.

Wie teuer die Indexierung wirklich ist, zeigt Tabelle 15 des GraphRAG-Bench-Papers am besten. Gemessen wurde die Indexierung eines einzigen Buchs mit rund 56.000 Tokens:

Verfahren	Tokens für die Indexierung	Dauer	Faktor zum Korpus
Microsoft GraphRAG	654.673 (535.832 In / 118.841 Out)	292 s	≈ 11,7×
LazyGraphRAG	591.150	254 s	≈ 10,6×
LightRAG	474.172	710 s	≈ 8,5×
HippoRAG	177.961	77 s	≈ 3,2×
KGP	89.215	32 s	≈ 1,6×

Rechnen Sie das hoch. Ein durchaus normaler Mittelstandskorpus mit 20.000 Dokumenten zu je 3.000 Tokens umfasst 60 Millionen Tokens. Beim Faktor 11,7 landen Sie bei rund 700 Millionen verarbeiteten Tokens für einen einzigen vollständigen Indexierungslauf mit Microsoft GraphRAG. Über eine Cloud-API ist das eine Rechnung, die man zweimal liest. Auf eigener, ohnehin vorhandener GPU-Hardware ist es Strom und eine lange Nacht.

Die zweite Kostenachse ist die Query-Zeit. Auf demselben Novel-Korpus misst GraphRAG-Bench die durchschnittliche Promptgröße pro Frage:

Verfahren	Prompt-Tokens pro Query	relativ
Vanilla-Vektor-RAG	879	1×
HippoRAG2	1.008	1,1×
MS-GraphRAG (local)	38.707	44×
LightRAG	ca. 100.832	115×
MS-GraphRAG (global)	331.375	377×

Das ist die belastbare, zitierfähige Version der oft kolportierten „700-fachen" Größenordnung. Und es kommt ein Effekt hinzu, vor dem die Autoren ausdrücklich warnen: Die Promptlänge von Global Search wächst mit der Aufgabenschwierigkeit von rund 7.800 auf rund 40.000 Tokens. Diese Prompt Inflation verschlechtert durch redundanten Kontext die Kontextrelevanz wieder – man zahlt also mehr für ein Ergebnis, das nicht zwangsläufig besser wird.

Aus 2026 kommt mit Youtu-GraphRAG ein weiterer Ansatz: Das auf der ICLR 2026 veröffentlichte Paper des Tencent Youtu Lab, gemeinsam mit der Monash University und der Hong Kong Polytechnic University, vereinheitlicht Konstruktion und Retrieval in einem gemeinsamen Schema. Die Camera-Ready-Fassung nennt „up to 33.60 % saving of token costs and 16.62 % higher accuracy over state-of-the-art baselines". Hinweis für alle, die die Zahl weiterverwenden: Die spätere arXiv-Revision (arXiv:2508.19855) nennt inzwischen 90,71 % Token-Ersparnis. Zitierfähig ist die ICLR-Zahl von 33,60 %; wer die höhere Zahl verwendet, sollte sie als spätere Preprint-Revision kennzeichnen.

Zur oft gehörten Faustformel, GraphRAG koste inklusive Konstruktion, Wartung und Retrieval-Orchestrierung das Drei- bis Fünffache von Standard-RAG: Dafür gibt es keine belastbare öffentliche Quelle. Sie deckt sich mit unserer eigenen Projekterfahrung – als recherchierten Branchenwert sollte man sie aber nicht ausgeben.

Wann Graph, wann Vektor, wann hybrid – eine Entscheidungsmatrix

Der stärkste Befund des ICLR-2026-Papers steht gleich im Abstract: „recent studies report that GraphRAG frequently underperforms vanilla RAG on many real-world tasks". GraphRAG-Bench evaluiert die gesamte Pipeline von der Graphkonstruktion über das Retrieval bis zur Generierung entlang von vier Schwierigkeitsstufen. Die Ergebnisse auf dem Novel-Korpus mit GPT-4o-mini sind eindeutig – und ernüchternd für Graph-Enthusiasten:

Aufgabenstufe	Basic RAG + Reranking	Bestes Graphverfahren	Verdikt
Fact Retrieval	60,92 %	60,14 % (HippoRAG2)	Kein Vorteil
Complex Reasoning	42,93 %	23,7 – 37,0 %	Vektor gewinnt
Contextual Summarization	51,30 %	64,40 % (MS-GraphRAG)	Graph +13,1 Punkte
Creative Generation	vergleichbar	vergleichbar	Kein klarer Sieger

Contextual Summarization ist die einzige Stufe, auf der der Graph in der Hauptmessung sauber und deutlich gewinnt. Damit ist die Entscheidungsregel formuliert – und sie ist erfreulich einfach:

1. Faktenabruf: Ein hybrides Vektor-Retrieval mit Reranking genügt. Ein Graph bringt hier keinen messbaren Vorteil und kostet ein Vielfaches.
2. Mehrstufiges Schlussfolgern: Vorsicht vor der Marketing-Erzählung. Investieren Sie zuerst in Query-Zerlegung, Reranking und bessere Chunk-Strategien, bevor Sie einen Graphen bauen.
3. Korpusweite Synthese und Sensemaking: Hier lohnt sich der Graph – und nur hier lässt sich sein Aufpreis rechtfertigen.
4. Hybrid als Normalfall: In der Praxis deckt ein starkes hybrides Vektordatenbank-Retrieval den weit überwiegenden Bedarf, ergänzt um einen Graph-Pfad für die Minderheit der Synthesefragen.

Reindexierung: der versteckte Betriebskostenposten

Der Punkt, der in Machbarkeitsstudien fast immer fehlt: Ein Graph ist kein Artefakt, das man einmal baut. Jede Änderung am Extraktionsprompt, jeder Modellwechsel, jede Erweiterung des Entity-Schemas erzwingt einen neuen Durchlauf über den gesamten Korpus. Voll ausgebautes GraphRAG braucht zudem periodische Neu-Indexierung nach relevantem Korpus-Drift, weil Community-Summaries global über den Graphen berechnet werden – lokale Ergänzungen kippen die Cluster-Struktur.

Was das konkret bedeutet:

• In der Cloud kostet jeder Durchlauf erneut Geld. Bei einem Extraktionsfaktor von rund 11,7× auf den Korpus ist ein Reindexierungslauf keine Nebensache, sondern ein Budgetposten. Drei Iterationen am Prompt-Design im ersten Projektquartal sind völlig normal.
• Auf eigener Hardware kostet er Strom und Zeit. Auf abgeschriebener GPU-Infrastruktur ist ein Reindexierungslauf eine Nachtschicht der Maschine, keine Freigabeentscheidung des Controllings. Genau das verändert die Projektdynamik – man iteriert am Extraktionsschema, statt es sich zu verkneifen.
• Inkrementelle Updates gehören in die Architekturentscheidung. LightRAG unterstützt inkrementelle Aktualisierungen und selektives Löschen einzelner Dokumente inklusive automatischer Regeneration der betroffenen Graphteile. Microsoft empfiehlt LazyGraphRAG explizit für „one-off queries, exploratory analysis, and streaming data use cases".

Faustregel: Wechselt Ihr Korpus täglich, kommt eine Vollpipeline mit vorberechneten Community-Summaries nicht in Frage. Dann bleibt nur ein inkrementeller Ansatz oder eine Lazy-Variante.

Warum der Graph das sensibelste Datenobjekt im Haus ist

Dieser Abschnitt ist ausdrücklich eine Argumentation, kein Messergebnis – dafür gibt es keine Studie. Sachlich schlüssig ist er trotzdem, und er wird in Datenschutzfolgenabschätzungen regelmäßig übersehen.

Ein Wissensgraph ist eine abgeleitete, entitätsaufgelöste Verdichtung über alle Quelldokumente hinweg. Er enthält nicht nur, was in den Dokumenten steht, sondern materialisiert Beziehungen, die in keinem einzelnen Dokument stehen. Drei Konsequenzen folgen daraus:

• Aggregation erzeugt neue personenbezogene Aussagen. Die Kante „Person X – war Ansprechpartner für – Vertrag Y – mit – Lieferant Z" ist eine neue Information, auch wenn jedes Teilstück harmlos in einem anderen Dokument steht. Datenschutzrechtlich ist die Verarbeitung damit nicht mehr identisch mit der Verarbeitung der Quelldokumente.
• Berechtigungen übertragen sich nicht automatisch auf Kanten. Dokument-Level-ACLs greifen im Graphen nicht von selbst. Eine Community-Summary kann Inhalte aus Dokumenten aggregieren, die ein bestimmter Nutzer einzeln nie sehen dürfte. Wer den Graphen einführt, muss das Berechtigungsmodell auf Knoten- und Kantenebene neu denken – nicht nachträglich, sondern vorher.
• Das Löschkonzept muss Knoten und Kanten erfassen. Ein Löschbegehren nach Art. 17 DSGVO ist nicht erfüllt, wenn das Quelldokument verschwindet, die daraus extrahierte Entität samt Kanten und Summaries aber im Graphen bleibt. Genau hier ist selektives Löschen mit Regeneration der betroffenen Graphteile ein funktionales, kein kosmetisches Feature.

Aus alldem folgt die Betriebsempfehlung: Graph-Datenbank und Extraktionsmodell gehören ins eigene Netz. Ein Graph über Verträge, Organigramme, Projekthistorien und Lieferketten ist die dichteste Repräsentation eines Geschäftsgeheimnisses, die ein Unternehmen überhaupt erzeugen kann – dichter als jedes Einzeldokument. Wer bereits eine On-Premise-Infrastruktur betreibt, hat hier den entscheidenden Vorteil: Extraktion und Graphhaltung laufen air-gapped, und die Reindexierung kostet keine API-Rechnung.

Referenzstack für den Eigenbetrieb

Ein wichtiger Statuscheck vorweg, Stand 25.08.2026: Das Repository microsoft/graphrag befindet sich laut eigenem README-Warnhinweis „largely in maintenance mode" und nimmt keine neuen Pull Requests und keine neuen Features mehr an – nur noch Bugfixes, Dependency-Updates und CVE-Behebung. Erstrelease war Juli 2024, die aktuelle PyPI-Version 3.1.2 stammt vom 21.08.2026, Lizenz MIT, rund 35.700 GitHub-Stars. Das Projekt trägt selbst den Hinweis, dass die Indexierung teuer sein kann und man klein anfangen solle. Als Referenzimplementierung ist es weiterhin lehrreich; als Produktionsstack für ein Fünfjahresprojekt würden wir es heute nicht mehr empfehlen.

Was wir stattdessen für den Eigenbetrieb empfehlen:

Graph-Datenbank im eigenen Netz

Keine Managed-Variante, kein „Graph as a Service". Die Anforderungen sind moderat – ein Property-Graph-Store im eigenen Rechenzentrum reicht völlig, und für kleinere Korpora genügt oft die Kombination aus PostgreSQL mit einem Graph-Layer plus pgvector für den Vektorpfad. Entscheidend ist nicht die Exotik der Datenbank, sondern dass sie in derselben Sicherheitszone steht wie Ihre Quelldokumente.

Lokales Modell für die Extraktion

Der Extraktionsschritt schickt jeden einzelnen Chunk durch ein Sprachmodell – und damit den gesamten Korpus. Wer das über eine Frontier-API laufen lässt, exportiert sein vollständiges Dokumentenarchiv und bezahlt dafür pro Token. Ein solides Open-Weight-Modell auf eigener GPU erledigt Entity- und Relation-Extraktion mit strukturierter Ausgabe gut genug, und die Reindexierung wird von einer Budgetfrage zu einer Terminfrage.

LightRAG als praktikabler Graph-Layer

LightRAG (HKUDS, EMNLP 2025) ist MIT-lizenziert, hat rund 39.200 Stars und wird aktiv gepflegt – der letzte Commit stammt vom 25.08.2026. Ausschlaggebend ist weniger die Popularität als das Feature-Set: inkrementelle Updates und selektives Löschen einzelner Dokumente mit automatischer Regeneration der betroffenen Graphteile. Genau das entschärft den Reindexierungs-Betriebskostenposten.

Youtu-GraphRAG: interessant, aber kein Produktionsstack

Der Vollständigkeit halber: Youtu-GraphRAG ist mit rund 1.250 Stars, unklarer Lizenzsituation (NOASSERTION) und letztem Update vom 26.02.2026 Forschungscode. Die Ideen sind es wert, verfolgt zu werden – produktiv setzen würden wir das Repository derzeit nicht ein.

Hybrider Retriever als Standard, Graph als Erweiterung

Der Standardpfad bleibt BM25 plus Vektorsuche mit Reranking. Der Graph-Pfad wird über einen Router angesteuert, der Synthesefragen erkennt. Diese Architektur hat einen unterschätzten Vorteil: Sie können den Graphen abschalten, ohne dass das System ausfällt. Umgekehrt gilt das nicht. Wie sich der Vektorpfad optimieren lässt, behandeln wir ausführlich in unserem Beitrag zu Reranking und Hybrid Search; die Auswahl des passenden Embedding-Modells für deutschsprachige Korpora ist ein eigenes Thema.

Wenn Sie vor der Entscheidung stehen, ob ein Graph für Ihren Anwendungsfall überhaupt in Frage kommt: Sammeln Sie zwei Wochen lang die tatsächlich gestellten Fragen Ihrer Nutzer und klassifizieren Sie sie nach den vier Stufen aus der Matrix oben. Liegt der Anteil echter Synthesefragen unter zehn Prozent, investieren Sie das Budget besser in besseres Retrieval als in einen Graphen.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. ICLR 2026 Proceedings Youtu-GraphRAG, Camera-Ready: 33,60 % Token-Ersparnis, 16,62 % höhere Accuracy
2. arXiv 2508.19855 – spätere Preprint-Revision mit abweichender Zahl (90,71 %)
3. GitHub Youtu-GraphRAG Referenzimplementierung, Lizenzstatus NOASSERTION
4. Microsoft Research Blog LazyGraphRAG, 25.11.2024 – Indexierungskosten identisch zu Vektor-RAG
5. arXiv 2506.05690 – „When to use Graphs in RAG", ICLR 2026
6. arXiv (PDF) Tabellen 6, 7 und 15 – Token- und Promptgrößen-Messreihen
7. GitHub GraphRAG-Bench, Annahme durch ICLR'26 am 26.01.2026
8. OpenReview Review-Thread und Abstract zum ICLR-2026-Paper
9. GitHub microsoft/graphrag – Maintenance-Mode-Hinweis, MIT, ca. 35.700 Stars
10. README (Rohfassung) Wortlaut „largely in maintenance mode" und Kostenwarnung
11. PyPI graphrag 3.1.2, veröffentlicht am 21.08.2026
12. GitHub LightRAG (EMNLP 2025), MIT, inkrementelle Updates und selektives Löschen
13. arXiv (PDF) Edge et al., „From Local to Global" – Originalpipeline und Vergleichswerte
14. VentureBeat Einordnung; enthält eine abweichende Reasoning-Zahl, siehe Originaltabelle
15. cruxdigits.nl Sekundärquelle zur Kostendebatte, nicht als Primärbeleg verwendet

Häufig gestellte Fragen zu GraphRAG

Ist GraphRAG immer besser als klassisches RAG?

Nein. Bei reinem Faktenabruf bringt der Graph nichts und kostet deutlich mehr. Sein Vorteil liegt bei mehrstufigen Beziehungsfragen und globalen Zusammenfassungen.

Wie teuer ist GraphRAG im Vergleich?

Voll-GraphRAG kostet inklusive Konstruktion, Wartung und Retrieval-Orchestrierung typischerweise das 3- bis 5-Fache von Standard-RAG. Die 2026er Varianten senken vor allem die Indexierungskosten drastisch.

Welche Variante ist für den Mittelstand sinnvoll?

In der Regel LazyGraphRAG oder LightRAG als Ergänzung zu einem bestehenden hybriden Vektor-Retrieval – nicht die ursprüngliche Vollpipeline.

Warum sollte der Graph nicht in der Cloud liegen?

Weil er Beziehungen materialisiert, die in keinem Einzeldokument stehen. Ein Graph über Verträge, Organigramme und Lieferketten ist das dichteste Geschäftsgeheimnis, das ein Unternehmen erzeugen kann.