Microsoft GraphRAG: ein Wissensgraph-RAG mit Vorabrechnung

GraphRAG ist die unter MIT lizenzierte Pipeline von Microsoft Research, die ein Korpus in einen Wissensgraphen verwandelt, ihn mit dem Leiden-Algorithmus clustert und für jede Community eine Zusammenfassung durch ein Sprachmodell schreiben lässt, bevor die erste Frage gestellt wird. Die Position hier ist, dass es nach wie vor der am besten dokumentierte Graph-RAG-Ansatz ist, und dass der interessante Teil nicht mehr die Konstruktion ist: Das Repository steht im Wartungsmodus, und was ein Team tatsächlich beantworten muss, ist, ob sich die Indexrechnung gegenüber der Vektorsuche rechnet.

Es konkurriert mit der schlichten Vektorsuche, mit leichteren Graph-Pipelines wie LightRAG und mit der Graph-Abfrage in LlamaIndex- und Neo4j-Werkzeugen. Der Unterschied ist wichtig, denn GraphRAG ist kein Dienst: Es ist ein Python-Paket, das die Token des Lesers für den Aufbau eines Index ausgibt und danach vier Abfragemoden als Bibliotheksfunktionen bereitstellt. Bei Microsoft wird nichts abgerechnet und nichts betrieben, und das README sagt, dass der Code eine Demonstration ist und kein offiziell unterstütztes Microsoft-Angebot.

Was es ist

Das Design ist bewusst nach vorn geladen. Dokumente werden in TextUnits zerlegt, ein Sprachmodell extrahiert aus jeder Einheit Entitäten und Beziehungen, doppelte Beschreibungen werden zusammengeführt und zusammengefasst, das Leiden-Clustering verteilt den Graphen auf eine Hierarchie von Communities, und ein weiterer Modell-Durchlauf schreibt für jede Community auf jeder Ebene einen Bericht. Erst dann läuft eine Frage, und bis dahin ist die teure Arbeit bereits bezahlt.

• Lizenz MIT, veröffentlicht als graphrag auf PyPI, aktuelle Version 3.2.0 vom 23. September 2026, Python 3.11 bis 3.13.
• Etwa 36.200 Stars, 3.800 Forks und 495 Commits auf GitHub, dazu 49 offene Issues und Pull Requests.
• TextUnits sind standardmäßig 1.200 Token groß: größere Chunks indexieren schneller und extrahieren weniger präzise.
• Die Community-Erkennung nutzt das hierarchische Leiden-Verfahren und kostet keine Modellaufrufe; das Zusammenfassen jeder Community kostet welche.
• Vier Abfragemoden liegen im Paket — global, local, DRIFT und basic — dazu die dynamische Community-Auswahl für die globale Suche.
• Die CLI nennt vier Indexierungsmethoden: standard, fast, standard-update und fast-update, dazu ein eigener update-Befehl für geänderte Dokumente.
• Jeder Aufruf geht an den eigenen Endpunkt des Lesers — Azure OpenAI, OpenAI oder einen kompatiblen Dienst —, die Kosten hängen also vom Modellpreis und der Korpusgröße ab.

Daraus folgen zwei Dinge. Der Index wird zum Asset und nicht zum Nebenprodukt: Entitätsbeschreibungen und Community-Berichte sind lesbare Artefakte, die sich wie jedes andere Ergebnis prüfen, teilen und versionieren lassen. Und der Graph ist nur so gut wie der Extraktionsdurchlauf, also muss ein Korpus, dessen Entitätstypen zählen, vor dem ersten vollständigen Lauf abgestimmt werden und nicht danach.

So funktioniert es

Die Indexierung ist eine feste Folge: zerlegen, extrahieren, zusammenführen, clustern, zusammenfassen, einbetten. Jede Stufe kostet entweder einen Modellaufruf pro Texteinheit oder nichts, und genau diese Grenze erzeugt die Rechnung — ein Extraktionsaufruf pro TextUnit, ein Zusammenfassungsaufruf pro zusammengeführter Entität oder Beziehung und ein Berichtsaufruf pro Community auf jeder Ebene der Hierarchie.

Die vier Modi sind die Produktfläche. Die globale Suche führt Map-Reduce über die Community-Berichte aus und ist der Modus, den die Vektorsuche nicht nachbilden kann, weil kein Chunk eine Antwort über den ganzen Korpus enthält. Die lokale Suche läuft um benannte Entitäten im Graphen und kostet in etwa so viel wie Vektorabrufe plus Traversierung. DRIFT beginnt bei den relevantesten Berichten, stellt Folgefragen und beantwortet jede davon lokal. Die Basicsuche ist die eigene Vektorsuche des Pakets, damit ein Team messen kann, was der Graph auf seinen eigenen Daten bringt.

Erste Schritte

Der Einstiegspunkt ist ein Verzeichnis, ein init-Befehl und zwei Dateien. Die Folge unten legt einen Arbeitsbereich an, richtet ihn auf ein brauchbares Modell, indexiert einen kleinen input-Ordner und stellt eine globale Frage; in settings.yaml wird die Rechnung festgelegt, ein erster Lauf sollte also bei einem kleinen Korpus und einem günstigen Modell bleiben, bis die Prompts abgestimmt sind.

python -m venv .venv && source .venv/bin/activate
python -m pip install graphrag

mkdir ragtest && cd ragtest
graphrag init -r . -m gpt-4.1 -e text-embedding-3-large
# write GRAPHRAG_API_KEY into the .env that init created
# drop a few .txt or .md files into ./input, then index:
graphrag index -r . -m standard

# global is the default; this prunes reports before the map-reduce step
graphrag query "What are the top themes across these documents?" -r . \
  --dynamic-community-selection

graphrag query "Who is the main character?" -r . -m local
graphrag update -r . -m standard-update

Zwei Gewohnheiten halten die erste Rechnung klein. Ein Sample statt des gesamten Korpus indexieren, denn die Pipeline ruft das Modell einmal pro TextUnit und einmal pro Community-Ebene auf, unabhängig vom Modellpreis; und vor dem Hochfahren prompt-tune ausführen, denn die Dokumentation sagt, dass fertige Prompts selten die besten Ergebnisse liefern.

Was das Indexieren kostet

Es gibt keine Lizenzgebühr und keinen betriebenen Dienst, die gesamten Kosten sind also Modellaufrufe. Die Extraktion läuft einmal pro TextUnit, die Berichterstattung einmal pro Community auf jeder Ebene; die Rechnung wächst also mit der Korpusgröße und mit der Zahl der Communities, die die Leiden-Hierarchie erzeugt. Die Zahlen unten stammen aus einem unabhängigen Vergleich vom März 2026 bei GPT-4-Preisen, nicht aus einer Microsoft-Preisliste:

Die Gegenzahl, die Microsoft Research veröffentlicht hat, ist LazyGraphRAG: Es ersetzt die Modell-Extraktion durch Nominalphrase-Extraktion und verschiebt jeden Modellaufruf auf die Abfragezeit. Die Indexkosten werden mit denen der Vektorsuche und mit 0,1 % des vollen GraphRAG angegeben, und dieselbe Auswertung nennt eine Qualität der globalen Suche auf mehr als 700-fach niedrigeren Abfragekosten beziehungsweise eine bessere Qualität bei 4 % dieser Kosten. Die Implementierung liegt in Microsoft Discovery und Azure Local und nicht im MIT-Paket, ein Team mit der Open-Source-Pipeline kann sie also nicht installieren: Die Zahl beschreibt eine Richtung, keine Option im Regal.

Was Abfragen kosten

Die Abfragekosten sind der Ort, an dem sich die Modi unterscheiden und an dem der Index das bereits investierte Geld entweder zurückverdient oder nicht. Die globale Suche ist der teure Modus, weil sie Community-Berichte in Batches liest und dann zusammenführt; die anderen drei lesen einen Bruchteil des Graphen:

Die dynamische Community-Auswahl ist die veröffentlichte Antwort auf die erste Zeile: Ein günstigeres Modell bewertet jeden Bericht an der Wurzel und schneidet irrelevante Zweige ab, bevor Map-Reduce läuft. Microsoft Research maß im Mittel 77 % weniger Token-Kosten gegenüber der statischen Suche auf Ebene 1 über 50 globale Fragen, wobei etwa 1.500 Berichte auf 470 sanken, ohne statistisch signifikanten Qualitätsunterschied; läuft die Bewertung bis Ebene 3, kostete das im Mittel 34 % mehr und gewann 58,8 % bei Comprehensiveness und 60,0 % bei Empowerment. Das sind Herstellerzahlen aus einem Datensatz, aber die Richtung ist nicht umstritten — aufhören, Berichte zu bezahlen, die die Frage nicht beantworten können.

Wo es schwächelt

Die Schwächen sind betrieblich, nicht algorithmisch. Das Repository steht im Wartungsmodus, Promptformate, Modellverhalten und Abhängigkeitsdrift sind also Sache des Lesers, und das README nennt den Code eine Demonstration. Das Aktualisieren ist ein eigener Befehl und kein Hintergrundjob: Dokumente ändern sich, Entitäten verschmelzen, Communities verschieben sich, und die Update-Methoden extrahieren geänderten Text weiter zu Modellpreisen. Der Graph trägt außerdem die Ontologie, denn Entitäts- und Beziehungstypen stammen aus offener Extraktion, ein lauter Korpus erzeugt also einen lauten Graphen. Vor allem wird der Index bezahlt, ob Fragen kommen oder nicht — das Gegenteil des Bezahlprofils der Vektorsuche.

Man liest diese Tabelle als Aussage über die Frage, für die jedes System gebaut ist. GraphRAG beantwortet korpusweite und mehrsprünige Fragen, die kein einzelner Chunk enthält; die Vektorsuche beantwortet Nachschlagefragen schneller und billiger, und deshalb liefert GraphRAG einen eigenen Basic-Modus mit, statt so zu tun, als gewinne der Graph überall. LightRAG ist der vernünftige Standard, wenn ein flacher Graph den größten Teil des Werts zu einem Bruchteil der Kosten bringt, und Graphiti löst Agenten-Gedächtnis statt Dokumentabfrage. Die Position hier ist, dass die meisten Teams zur vollen Pipeline greifen, weil deren Benchmark beeindruckend ist, obwohl ihre Anfragemischung von Nachschlagfragen bestimmt wird — und der billigste erste Schritt ist, diese Mischung zu messen, bevor irgendetwas indexiert wird.

Fazit

GraphRAG ist das richtige Werkzeug für einen Korpus, dessen Fragen wirklich global sind, und der falsche Standard für eine Suchmaske. Es ist der am besten dokumentierte Graph-RAG, es ist MIT, und sein Index ist ein wiederverwendbares Artefakt mit Berichten, die Menschen lesen können; gleichzeitig steht es im Wartungsmodus, wird im Voraus bezahlt und langsamer aktualisiert als der Korpus, den es indexiert. Übernehme es mit gemessener Anfragemischung und einem kleinen ersten Korpus, oder übernehme es nicht.

1. Wähle es, wenn ein erheblicher Teil der Fragen Synthese über den ganzen Korpus verlangt: Themen, Trends, Vergleiche über alles.
2. Wähle es, wenn Antworten von Sprüngen zwischen Entitäten abhängen, die nie im selben Chunk stehen.
3. Wähle es, wenn der Index selbst einen Wert hat — Berichte, die Menschen lesen, teilen und prüfen —, denn das kauft man für die Vorabkosten.
4. Wähle es nicht für eine Suchmaske voller Nachschlagfragen: Die Vektorsuche ist pro Abfrage billiger, und der eigene Basic-Modus von GraphRAG ist genau diese Suche.
5. Behandle es nicht als gepflegte Abhängigkeit; das Repository nennt Wartungsmodus und keine neuen Features.
6. Vor dem vollständigen Lauf die Anfragemischung messen und ein Sample mit dynamischer Community-Auswahl indexieren.

Ein weiterer Punkt ist, wo der Index lebt. Er ist ein Batch-Artefakt und gehört dorthin, wo Batch-Artefakte hingehören: von einer Pipeline gebaut, versioniert, geprüft und ersetzt, statt aus einem Request-Handler heraus neu gebaut zu werden. Die Mechanik dessen, was der Graph enthält — Entitäten, TextUnits, Communities — steht in einem früheren Beitrag über Wissensgraph-RAG; dieser Test gilt der Implementierung, ihren Modi und ihrer Rechnung.

GraphRAG indexing can be an expensive operation, please read all of the documentation to understand the process and costs involved, and start small.

Quellen

1. GraphRAG on GitHub
2. GraphRAG documentation
3. From Local to Global: A Graph RAG Approach to Query-Focused Summarization
4. GraphRAG: Improving global search via dynamic community selection
5. LazyGraphRAG: Setting a new standard for quality and cost
6. Graph RAG in 2026: What Actually Works in Production