GraphRAG-Leitfaden: Wann Wissensgraphen Vector RAG schlagen (und wann nicht)

GraphRAG-Leitfaden: Wann Wissensgraphen Vector RAG schlagen (und wann nicht)

GraphRAG ist nicht tot, aber auch nicht der Standard. microsoft/graphrag hat am 18.07.2026 Version 3.1.1 veröffentlicht, bei 35.088 GitHub-Stars, und drei Benchmark-Paper aus 2026 berichten inzwischen offen, dass es häufig gegen schlichtes Vector Retrieval verliert. Deshalb beantwortet dieser GraphRAG-Leitfaden die einzig verbliebene Frage: Ist ein Wissensgraph seine Indexierungskosten wert?

GraphRAG einsetzen? Die kurze Antwort

Setzen Sie GraphRAG ein, wenn Ihre Fragen Entitäten übergreifen oder den gesamten Korpus umspannen, etwa „Welchen Lieferanten verkauft auch unser größter Kunde?" Bei Single-Hop-Faktenabfragen, schnelllebigen Dokumenten und engen Latenzbudgets bleiben Sie bei Vanilla- oder Hybrid-RAG. Der Graph amortisiert sich bei Multi-Hop-Fragen und kostet überall sonst Geld.

GraphRAG ist nicht tot und nicht der Standard. Es verdient seine Indexierungskosten, wenn Ihre Fragen Multi-Hop oder korpusweit sind, und verliert Geld, wenn sie es nicht sind.

Die Kurzversion:

• GraphRAG gewinnt bei Multi-Hop- und korpusweiten Fragen; Vanilla RAG gewinnt bei Single-Hop-Abfragen.
• Die Benchmarks von 2026 sind gemischt: Graphen helfen bei Aggregation, können aber feingranulare Zusammenfassungen verschlechtern.
• Die Kosten fallen bei der Indexierung an, in LLM-Extraktionsaufrufen, nicht zur Abfragezeit.
• Führen Sie Basic Search als Kontrolle auf Ihrem eigenen Korpus aus, bevor Sie etwas bauen.

Wenn Sie bereits eine funktionierende Vector-RAG-Pipeline betreiben, ist die einzige Entscheidung, ob sich ein Graph obendrauf lohnt. Die Tabelle unten ist das gesamte Argument in sechs Zeilen, und wo sie sagt, bleiben Sie bei Vanilla, ist das die ehrliche Antwort, öfter als die Anbieter zugeben. Hybrides Retrieval mit BM25 plus Vektoren deckt die meisten dieser Fälle ganz ohne Graph ab.

Was GraphRAG wirklich ist: Von Chunks zu Communities

GraphRAG ist Retrieval-Augmented Generation über einem Wissensgraphen statt über unverbundenen Chunks. Zur Indexierungszeit extrahiert ein LLM Entitäten und Beziehungen aus Ihren Dokumenten, der Leiden-Algorithmus gruppiert diese Entitäten zu Communities, und jede Community erhält eine Zusammenfassung. Zur Abfragezeit beantworten der Graph plus diese Zusammenfassungen Fragen, die ein top_k-Fenster über Chunks strukturell nicht beantworten kann.

Die Pipeline, Ende zu Ende:

Documents
  |
  v
Chunks --> LLM entity + relationship extraction
  |
  v
Knowledge graph (entities = nodes, relations = edges)
  |
  v
Leiden community detection --> community summaries
  |
  v
Vector index over entity + community descriptions

Zwei Phasen machen die Arbeit. Die Indexierungsphase ist die teure: Jeder Chunk kostet einen LLM-Aufruf, um Entitäten und Beziehungen zu extrahieren, und die Community-Zusammenfassungen kosten darüber hinaus weitere Aufrufe. Die Abfragephase ist der Ort, an dem sich das auszahlt. Weil der Graph Beziehungen explizit speichert, wird eine Frage wie „Welchen Lieferanten verkauft auch unser größter Kunde?" zu einer Traversierung statt zu einem Hoffnungsspiel, dass die richtigen zwei Chunks im selben top_k-Fenster landen.

Die Zusammenfassungen zählen, weil Global Search genau sie liest: korpusweite Fragen werden aus vorab geschriebenen Community-Texten beantwortet, nicht aus Roh-Chunks. Und jede Kante ist ein LLM-Urteil, gespeichert als Triple, das Sie in einer echten Graphdatenbank per Cypher abfragen könnten. Dieses Design ist auch der Grund, warum die Indexierung die Kosten dominiert, was die Zahlen unten konkret machen.

Die tragfähige Einordnung: Vanilla RAG ruft Textpassagen ab, GraphRAG ruft Struktur ab. Ihre Wahl des Embedding-Modells zählt weiterhin für die Vektorschicht, und Ihre Vektordatenbank speichert weiterhin die Beschreibungen, aber der Graph ist das neue tragende Element. Die offiziellen Index-Overview-Docs beschreiben jede Stufe vollständig.

Was sind die vier GraphRAG-Abfragemethoden?

Die GraphRAG-Query-Engine bringt vier Methoden mit: Local Search, Global Search, DRIFT Search und Basic Search. Local Search argumentiert von konkreten Entitäten aus nach außen, Global Search aggregiert Community-Zusammenfassungen über den gesamten Korpus, DRIFT Search verbindet beide rekursiv, und Basic Search ist eine schlichte Vector-Baseline. Ein fünftes Feature, Question Generation, sitzt über der Engine, nicht neben ihr.

Wir haben am 30.07.2026 die Live-Docs unter microsoft.github.io/graphrag/query/overview/ geprüft, und die Zahl ist vier. Die meisten Ranking-Guides nennen zwei oder drei. Dieselbe Prüfung fand das Wort „lazy" null Mal auf beiden Übersichtsseiten, Index und Query, was für den Kostenabschnitt unten zählt.

Die Zeile, die Ihre Aufmerksamkeit verdient, ist die letzte. Basic Search ist die eingebaute Vanilla-Vector-Baseline, und sie existiert, damit Sie den Graphen gegen schlichtes Retrieval auf Ihrem eigenen Korpus A/B-testen und herausfinden können, ob der Graph seine Kosten wert ist. Das ist keine Nebensache; es ist das gesamte Entscheidungsverfahren dieses Leitfadens in einem Feature. Führen Sie zuerst Basic Search aus. Wenn Local, Global oder DRIFT sie bei den Fragen, die Sie tatsächlich gestellt bekommen, nicht schlägt, ist der Graph ein Kostenfaktor, kein Upgrade.

Was haben die Benchmarks von 2026 tatsächlich gefunden?

Drei Benchmark-Paper aus 2026 stellen fest, dass GraphRAG bei Multi-Hop- und Multi-Fact-Aggregationsaufgaben hilft, aber andernorts häufig hinter Vanilla RAG zurückbleibt. Eines davon baut einen Benchmark eigens dafür, zu finden, wo Graphen verlieren. Alle drei sind sich einig, dass der Gewinn vom Fragetyp abhängt, nicht von der Korpusgröße. Die Evidenz sagt: GraphRAG ist situativ, nicht Standard.

Eine vierte Arbeit, GraphRAG-Bench (Repository), evaluiert neun GraphRAG-Methoden über 16 Disziplinen und 20 Lehrbücher und kommt aus einem breiteren Winkel zum selben Schluss.

Alle drei Paper konvergieren auf einen Punkt: Der Graph verdient seine Kosten bei Multi-Hop-Aggregation und verliert sie bei feingranularem Recall.

Unsere Lesart: Der Hype-Zyklus hat den Schaden angerichtet, und diese Paper sind die Korrektur. Keines von ihnen sagt, Graphen seien nutzlos. Was sie konsistent sagen: Der Aggregationsschritt, der GraphRAG gut bei korpusweiten Themen macht, ist derselbe Schritt, der feingranulare Details verwischt. WildGraphBench ist das klarste Beispiel: Graphen halfen bei Multi-Fact-Aggregation aus einer moderaten Zahl von Quellen und schadeten der Zusammenfassungspräzision in derselben Evaluation. Das ist kein Widerspruch; es ist ein Mechanismus, der sich zweimal zeigt.

Die praktische Konsequenz: Sie können das nicht allein aus der Literatur entscheiden. Die Paper sagen Ihnen, welche Fragetypen Sie testen sollten, nicht, ob Ihr Korpus einer davon ist. Genau dafür ist die Basic-Search-Kontrolle aus dem Methodenabschnitt oben da.

Was kostet GraphRAG? (Und der LazyGraphRAG-Vorbehalt, den alle falsch wiederholen)

Die Kosten von GraphRAG sind eine Rechnung zur Indexierungszeit, nicht zur Abfragezeit, genau deshalb überraschen sie so viele. Die LLM-Aufrufe, die Entitäten und Beziehungen aus jedem Chunk extrahieren, plus der Community-Zusammenfassungsdurchlauf, sind es, was sie teuer macht. Sie zahlen im Voraus, bevor eine einzige Abfrage läuft. Die Abfragezeit ist günstiger, aber nicht kostenlos: Global Search fächert über Community-Zusammenfassungen auf, mit einem LLM-Aufruf pro Community, weshalb die Methodentabelle oben sie als hoch markiert.

Die einzigen harten öffentlichen Zahlen kommen von Microsoft Research. Am 25.11.2024 berichtete das Team, dass die Indexierungskosten von LazyGraphRAG identisch mit Vector RAG und 0,1 % der Kosten von vollem GraphRAG seien, und dass es bei 4 % der Abfragekosten von GraphRAG Global Search die getesteten Konkurrenzmethoden schlug, bei lokalen wie globalen Abfragetypen (Microsoft Research). Das sind Microsofts Zahlen, aus Microsofts Blog, und wir geben sie als solche wieder; wir haben keine eigene preisbewertete Indexierung durchgeführt.

Hier ist die Korrektur, die die meisten Artikel verpassen. LazyGraphRAG ist keine Pip-Install-Option. Laut Microsofts eigener Editor's Note vom 06.06.2025 wurde es in Microsoft Discovery und Azure Local ausgeliefert, nicht in das Open-Source-Paket. Wir haben am 30.07.2026 die offiziellen Seiten Index Overview und Query Overview geprüft: Das Wort „lazy" erscheint null Mal auf beiden. Wenn also ein Guide LazyGraphRAG als Variante aufführt, die Sie heute Nachmittag aufsetzen können, wiederholt er eine Behauptung, die in der Open-Source-Welt nicht mehr stimmt.

Was Sie heute tun können: das Extraktionsmodell lokal ausführen. Den Indexierungsschritt über Ollama auf ein lokales Modell zu richten, entfernt die Pro-Token-API-Gebühren aus der teuersten Phase, und die Kombination mit einem selbst gehosteten Vektor-Store hält den Rest der Rechnung nahe null.

Welche GraphRAG-Bibliothek wird wirklich gepflegt?

Zwei der sechs meistzitierten GraphRAG-Bibliotheken haben seit sechs beziehungsweise neun Monaten keinen Push mehr gehabt. Wir haben diese Zahlen am 30.07.2026 über die GitHub-API gezogen, und der Bestand unten ist die Prüfung, die ältere Übersichten auslassen, samt dem Befehl, um sie selbst nachzuvollziehen, bevor Sie sich festlegen. LightRAG und microsoft/graphrag sind die aktiven; nano-graphrag und fast-graphrag driften in Richtung Abandonware.

for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; done

Unsere Lesart: Stars sind eine Eitelkeitsmetrik; das Push-Datum ist die Zahl, die zählt. LightRAG und microsoft/graphrag werden beide aktiv gepflegt, Graphiti dicht dahinter mit einem Temporal-Graph-Ansatz. nano-graphrag und fast-graphrag sind die beiden, die ältere Artikel noch allein aufgrund ihres Rufs empfehlen, und keine von beiden hat seit einem halben Jahr etwas ausgeliefert.

Die Wahl: Nehmen Sie microsoft/graphrag, wenn Sie die Referenzimplementierung mit den vier offiziellen Abfragemethoden wollen, LightRAG, wenn Sie das aktivste Projekt und einen leichteren Footprint wollen, und eine anbietergepflegte Bibliothek wie neo4j-graphrag-python, wenn Sie bereits die Datenbank dieses Anbieters betreiben. Meiden Sie alles, dessen letzter Push ein halbes Jahr vor Ihrem Projekt liegt.

Graphiti verdient eine eingegrenzte Notiz: Sein Temporal-Graph-Design ist für Retrieval über zeitbewussten Daten gebaut, und es überschneidet sich mit Agent Memory, was wir separat in unserem Leitfaden zu Graphiti und temporalem Graph-Gedächtnis behandeln. Für das breitere Feld, siehe die breitere RAG-Tool-Landschaft.

Was nach Tag 200 kaputtgeht: Graph Drift und Re-Extraktion

Graph Drift ist die Steuer, die Sie nach dem Launch zahlen, und sie ist aus gutem Grund der Haupteinwand von Praktikern. Jedes Tutorial behandelt den Graphen als etwas, das man einmal baut. Echte Teams bleiben an Tag 200 stecken.

Drei Dinge verfallen. Erstens: Neu-Indexierung bei Dokumenten-Updates. Wenn sich 40 Dokumente ändern, können Sie sie nicht einfach neu einbetten; Sie müssen die LLM-Extraktion auf den geänderten Chunks neu laufen lassen, die neuen Entitäten gegen den alten Graphen abgleichen und die betroffenen Communities samt ihrer Zusammenfassungen neu berechnen. Ein Medium-Guide nennt inkrementelle Updates einfach. Die Praktiker auf r/Rag widersprechen. Der Autor eines Threads vom 25.04.2026, der BM25 plus BGE-M3 über etwa 600 Dokumente betreibt, sagte es geradeheraus: „LLM-basierte Entitäts-/Relationsextraktion ist verrauscht, und Neu-Indexierung bei Dokument-Updates sieht schmerzhaft aus."

Zweitens: Zerfall der Entitätsauflösung. „Acme Corp", „Acme" und „ACME Corporation" kommen in verschiedenen Dokumenten an, Monate auseinander, und spalten sich in drei Knoten auf, die einer sein sollten. Nichts führt sie automatisch zusammen.

Drittens: Beziehungen, die zur Extraktionszeit wahr waren und still aufhörten, wahr zu sein. Niemand bekommt eine Warnung, wenn eine reports_to-Kante veraltet.

def on_documents_changed(changed_docs):
    stale = find_affected_nodes(changed_docs)
    re_extract(changed_docs)
    reconcile_entities(stale)
    recompute_communities(affected_only=True)
    re_summarize(affected_communities)

Eine Codebase ist der schlimmste Fall und zugleich der interessanteste. Die Autovervollständigung schlägt inzwischen „graphrag for codebase", „graphrag claude code" und „graphrag mcp server" vor, und eine Codebase ist ein Graph, der sich stündlich ändert: Jeder Commit schreibt Aufrufkanten um, verschiebt Symbole und löscht Funktionen. Das ist Graph Drift nach einem Zeitplan, dem kein nächtliches Re-Indexing vollständig folgen kann. Es ist auch der Grund, warum die ernsthaften Code-Graph-Tools auf deterministische Parser wie tree-sitter und LSP für die Kanten setzen und das LLM für den Text darum herum reservieren: Docstrings, Commit-Nachrichten, Review-Threads. Wenn Sie ein Repo als Graph abbilden, dann erfassen Sie die langsamlebige Schicht mit dem LLM und die schnellebige mit einem Parser.

Was sagen Entwickler wirklich über GraphRAG?

Praktizierende Entwickler sind gespalten, und Google scheint es zu wissen: Ein Reddit-Thread rankt auf Position zwei für „graphrag vs rag", was Ihnen die Suchmaschine damit sagt, dass dieses Thema Peer-Meinung will, keinen Anbieter-Text.

Die Skepsis ist real. Auf r/Rags Thread von 2024 „Would you always recommend (knowledge) graph RAG over normal RAG?" (10 Punkte, 86 % Upvotes) schrieb u/EncartaIt: „Alle Tutorials, die ich gefunden habe, sind übermäßig simpel und machen keinen wirklich starken Fall für das Wissensgraph-Muster." u/Prestigious_Run_4049 war direkter: „Ich denke, Graph RAG ist nur Hype. Leute reden gern darüber und es klingt cool, aber niemand nutzt es wirklich in echten Use Cases." Nicht alle stimmen zu. u/pytheryx, der aus der Produktion argumentierte, merkte an, dass Graph Retrieval bei Listenfragen gewinnt, die Kontext aus mehr Chunks brauchen, als top_k zurückgibt; sein Whitepaper-Korpus braucht etwa 50 Chunks für eine vollständige Antwort.

Der Thread von 2026 ist maßvoller. u/Popular_Sand2773: „Die meisten Graph-RAG-Setups schummeln einfach im großen Maßstab. Man fährt eine Standard-Vektor- oder Metadatensuche, um Seed-Knoten zu finden, und hangelt sich dann durch." u/ggone20, der ein System mit rund 300 Millionen Artefakten betreibt: „Im großen Maßstab kann man buchstäblich nicht ohne sie leben, um echte Fragen zu beantworten."

Unsere Lesart deckt sich mit dem schärfsten Argument in beiden Threads: Der Wendepunkt ist die Komplexität Ihrer Fragen, nicht die Größe Ihres Korpus. Das ist auch, was die Benchmarks oben gefunden haben, weshalb wir uns auf die Seite der Praktiker stellen, die das Tool auf Multi-Hop-Arbeit eingrenzen, statt auf die, die es für tot erklären.

Wie Techsy das angeht

Hier ist die Reihenfolge, die wir bei Kundenprojekten verwenden, und sie ist bewusst langweilig.

Erstens: Beweisen Sie die Decke von Hybrid Retrieval. Die meisten „Wir brauchen einen Graphen"-Anfragen, die wir hören, sind in Wahrheit ein Chunking- oder ein Reranking-Problem in Verkleidung. Eine BM25-plus-Vektor-Pipeline mit einem ordentlichen Reranker beantwortet mehr, als Teams erwarten.

Zweitens: Führen Sie Basic Search als Kontrolle auf Ihrem eigenen Korpus aus, bevor Sie etwas bauen. Genau dafür ist die vierte Abfragemethode da: eine schlichte Vector-Baseline, gegen die Sie den Graphen A/B-testen können, auf Ihren Daten, mit Ihren Fragen.

Drittens: Bauen Sie den Graphen erst, wenn eine gemessene Klasse von Fragen an dieser Kontrolle scheitert. Wenn Multi-Hop- oder korpusweite Abfragen danebenliegen, haben Sie einen echten Fall. Wenn nicht, haben Sie sich gerade eine Indexierungsrechnung und ein Drift-Problem gespart.

Sie wollen einen zweiten Blick auf Ihren Retrieval-Stack? Kostenlose Beratung anfragen.

Häufig gestellte Fragen

Wie funktioniert GraphRAG?

GraphRAG indexiert Ihre Dokumente in einen Wissensgraphen. Ein LLM extrahiert Entitäten und Beziehungen aus jedem Chunk, der Leiden-Algorithmus clustert diese Entitäten zu Communities, und jede Community erhält eine Zusammenfassung. Zur Abfragezeit durchsucht die Engine den Graphen und diese Zusammenfassungen, sodass sie Fakten verbinden kann, die in verschiedenen Chunks liegen.

Wie unterscheidet sich GraphRAG von RAG?

Standard-RAG ruft die top-k ähnlichsten Chunks ab und übergibt sie an das Modell. GraphRAG ruft Struktur ab: Entitäten, die Beziehungen zwischen ihnen und vorab geschriebene Community-Zusammenfassungen. Diese zusätzliche Struktur ist es, was Multi-Hop- und korpusweite Fragen beantwortbar macht, und sie ist auch, was die Indexierung langsamer und teurer macht.

Wann sollte ich GraphRAG einsetzen?

Setzen Sie es ein, wenn Ihre Fragen Entitäten übergreifen oder den gesamten Korpus umspannen, wie Lieferanten-Überschneidungen oder wiederkehrende Themen über Tausende von Dokumenten. Überspringen Sie es bei Single-Hop-Faktenabfragen, schnelllebigen Korpora und engen Latenz- oder Kostenbudgets. Wenn eine schlichte Hybrid-Pipeline eine Frageklasse bereits beantwortet, fügt der Graph Kosten hinzu, ohne Mehrwert zu schaffen.

Ist GraphRAG tot?

Nein, aber auch nicht der Standard. Die Benchmarks von 2026 zeigen, dass es bei Alltagsaufgaben häufig schlechter als Vanilla RAG abschneidet, was den Hype beendet hat, während es bei Multi-Hop- und Aggregationsfragen weiterhin gewinnt. Die ehrliche Einordnung ist situativ: GraphRAG verdient seine Kosten für die richtigen Fragetypen und verliert Geld bei den restlichen.

Was sind die GraphRAG-Abfragemethoden?

Die offizielle Query-Engine bringt vier mit: Local Search für entitätszentrierte Fragen, Global Search für korpusweite Aggregation, DRIFT Search für eine rekursive Mischung aus beidem und Basic Search für schlichtes Vector Retrieval. Ein fünftes Feature, Question Generation, sitzt obendrauf. Basic Search zählt am meisten: Es ist die Kontrolle, gegen die Sie den Graphen A/B-testen.

Was kostet die GraphRAG-Indexierung?

Die Kosten fallen zur Indexierungszeit an, in den LLM-Aufrufen, die Entitäten und Beziehungen aus jedem Chunk extrahieren, plus Community-Zusammenfassung. Microsoft Research berichtete, dass LazyGraphRAG-Indexierung bei 0,1 % der Kosten von vollem GraphRAG lag und identisch mit Vector RAG war, aber diese Variante wurde in Microsoft-Produkte ausgeliefert, nicht in die Open-Source-Bibliothek. Wir haben selbst keine preisbewertete Indexierung durchgeführt.

Kann ich GraphRAG lokal mit Ollama betreiben?

Ja. Die Bibliothek microsoft/graphrag erlaubt es, Indexierung und Abfrage auf ein lokales Modell zu richten, das von Ollama bereitgestellt wird, was die Pro-Token-API-Gebühren aus dem Extraktionsschritt entfernt. Sie tauschen Geschwindigkeit und Qualität gegen Kosten: Lokale Modelle sind bei der Entitätsextraktion schwächer, erwarten Sie also verrauschtere Graphen und längere Indexierungsläufe auf bescheidener Hardware.

Ist LightRAG oder Microsoft GraphRAG besser?

Sie optimieren für verschiedene Dinge. LightRAG (38.353 Stars, Push am 30.07.2026) ist am aktivsten und leichter zu betreiben; microsoft/graphrag (35.088 Stars, v3.1.1) ist die Referenzimplementierung mit den vier offiziellen Abfragemethoden. Nehmen Sie LightRAG für einen effizienten Produktions-Graphen, Microsofts für spezifikationstreues Verhalten und die Basic-Search-Kontrolle.

Wer hat GraphRAG wann erstellt?

Microsoft Research hat GraphRAG erstellt. Das Team veröffentlichte das Paper 2024 und pflegt das Open-Source-Repository microsoft/graphrag unter der MIT-Lizenz, mit Dokumentation unter microsoft.github.io/graphrag. Die Referenzbibliothek erreichte v3.1.1 am 18.07.2026, und ein aktives Ökosystem aus Drittanbieter-Implementierungen, einschließlich LightRAG und Graphiti, ist darum herum gewachsen.

Das Fazit: Wann ein Graph seine Kosten verdient

Die Evidenz zeigt in eine Richtung, also hier ist die Position.

• GraphRAG ist nicht tot. Es ist situativ, und die Benchmarks von 2026 sagen das laut.
• Es verdient seine Indexierungskosten bei Multi-Hop-Entitätsfragen und korpusweiter Aggregation. Es verliert Geld bei Single-Hop-Abfragen.
• Die Kosten sind eine Indexierungsrechnung, und die günstige Variante, die alle zitieren, LazyGraphRAG, hat die Open-Source-Bibliothek nie erreicht.
• Der Graph verfällt nach dem Launch: Entitätsauflösung driftet und Beziehungen veralten, also planen Sie Budget für Neu-Indexierung ein.
• Führen Sie Basic Search als Kontrolle auf Ihrem eigenen Korpus aus, bevor Sie etwas bauen.

Ein Satz: Ein Wissensgraph verdient seine Kosten, wenn Ihre Fragen Multi-Hop oder korpusweit sind, und nicht vorher. Wenn Sie eine zweite Meinung zu Ihrem Retrieval-Stack wollen, Kostenlose Beratung anfragen.