05.07.2024 AI Engineering 4 Minuten Lesezeit

GraphRAG: Globale Fragen mit Wissensgraphen beantworten

Microsoft hat GraphRAG veröffentlicht: eine Indexierungs-Pipeline, die per LLM einen Entitätsgraphen aus Text extrahiert, ihn mit dem Leiden-Algorithmus partitioniert und jede Community vorab zusammenfasst. Wir erklären, wie das globale Fragen beantwortet, an denen Vektor-RAG scheitert, was das Paper tatsächlich misst und warum die Indexierungskosten der eigentliche Trade-off sind.

Fragen an den gesamten Korpus

Retrieval-Augmented Generation ist in der üblichen Ausprägung eine Vektor-Pipeline. Dokumente werden in Chunks zerlegt, Chunks werden eingebettet, und zur Anfragezeit landen die top-k ähnlichsten Chunks im Kontextfenster. Für lokale Fragen funktioniert das gut: Die Antwort steht in wenigen Passagen, und semantische Ähnlichkeit findet sie.

An globalen Fragen scheitert das Verfahren. "Was sind die Hauptthemen dieses Datensatzes?" hat keinen Antwort-Chunk. Top-k-Retrieval liefert Passagen, die der Frage nur oberflächlich ähneln, und erzeugt eine trügerisch selbstbewusste Zusammenfassung einer Stichprobe. Das GraphRAG-Paper ordnet solche Fragen als Query-Focused Summarization ein, nicht als Retrieval — und bisherige Summarization-Verfahren skalieren nicht auf Korpora in RAG-Größe.

Entitäten und Relationen werden aus jedem Dokument extrahiert. 1/4

Was Microsoft veröffentlicht hat

Microsoft Research stellte GraphRAG am 13. Februar 2024 in einem Blogbeitrag vor, demonstriert an Tausenden russischen und ukrainischen Nachrichtenartikeln vom Juni 2023. Am 24. April 2024 folgte das Paper des Teams um Darren Edge und Jonathan Larson (arXiv:2404.16130), das eine Open-Source-Implementierung in Python ankündigte.

Diese Implementierung ist inzwischen öffentlich zugänglich: Das Repository microsoft/graphrag liegt unter MIT-Lizenz auf GitHub, mit Dokumentation, einer Indexierungs-Engine und zwei Abfragemodi — Global und Local Search. Bemerkenswert: Einen Ankündigungsbeitrag gibt es bisher nicht; der Code ist einfach da. GraphRAG ersetzt keine Vektordatenbank. Es ist ein zusätzlicher, teurerer Index.

Ein LLM extrahiert den Entitätsgraphen

Die Indexierung beginnt konventionell: Quelltexte werden in Chunks von rund 600 Token zerlegt. Jeder Chunk durchläuft dann einen mehrteiligen Extraktions-Prompt, der Entitäten, Beziehungen zwischen ihnen und kurze natürlichsprachliche Beschreibungen beider zurückgibt. Weil ein einzelner Durchlauf Elemente übersieht, fährt die Pipeline zusätzliche "Gleaning"-Runden und fragt das Modell bis zu einem konfigurierten Maximum, ob Entitäten fehlen.

Die Chunk-Größe ist nicht kosmetisch. Das Paper berichtet, dass 600-Token-Chunks auf demselben Korpus fast doppelt so viele Entitätsreferenzen lieferten wie 2400-Token-Chunks. Mehrfache Beschreibungen desselben Elements werden zu einer zusammengefasst. Das Ergebnis ist ein gewichteter, beschriebener Entitätsgraph — ohne vordefinierte Ontologie erstellt und damit domänenunabhängig.

Leiden-Communities als Indexstruktur

GraphRAG partitioniert diesen Graphen mit dem Leiden-Algorithmus (Traag et al., 2019), einer Weiterentwicklung von Louvain, die gut verbundene Communities garantiert. Die Partition ist hierarchisch und rekursiv: grobe Wurzel-Communities auf Ebene C0, zunehmend feinere Sub-Communities auf C1 bis C3. Jeder Knoten gehört pro Ebene zu genau einer Community.

Genau hier liegt der strukturelle Unterschied zur Vektorsuche. Eine Community-Partition überdeckt alle Knoten; jeder Eingabetext hat den Index also beeinflusst. Top-k-Retrieval zieht eine Stichprobe aus dem Korpus; die Community-Hierarchie beschreibt ihn vollständig, in mehreren Auflösungen.

Community-Zusammenfassungen und Map-Reduce

Während der Indexierung schreibt das LLM für jede Community einen Report — auf Blattebene aus den Element-Zusammenfassungen, weiter oben aus den Reports der Sub-Communities. Diese Reports existieren, bevor irgendeine Frage gestellt wird. Sie bilden eine vorberechnete, hierarchische Zusammenfassung des Korpus.

Zur Anfragezeit arbeitet Global Search per Map-Reduce. Map: Die Community-Reports einer gewählten Ebene werden in Kontextfenster gepackt, das Modell erzeugt Teilantworten mit Nützlichkeits-Scores. Reduce: Die bestbewerteten Teilantworten werden zu einer finalen Antwort verdichtet. Local Search geht den anderen Weg — es löst Entitäten in der Frage auf und stellt deren Graph-Nachbarschaft plus Rohtext zusammen.

Was das Paper misst

Die Evaluation nutzte zwei Korpora im Bereich von einer Million Token: Podcast-Transkripte (rund 1 Million Token) und Nachrichtenartikel (rund 1,7 Millionen Token), mit je 125 GPT-4-generierten Sensemaking-Fragen pro Datensatz und einem LLM-Richter, der Comprehensiveness, Diversity, Empowerment und Directness im Paarvergleich bewertete.

GraphRAG gewann etwa 70–80 % der Vergleiche gegen naives Vektor-RAG bei Comprehensiveness und Diversity. Naives RAG gewann bei Directness — seine Antworten sind knapper. Gegen direkte Quelltext-Summarization waren Wurzel-Community-Zusammenfassungen qualitativ konkurrenzfähig und benötigten dabei über 97 % weniger Kontext-Token pro Anfrage.

Ansatz	Globale Fragen	Token pro Anfrage	Indexaufbau
Vektor-RAG (top-k)	scheitert	niedrig	nur Embeddings — günstig
Quelltext-Summarization	gute Antworten	gesamter Korpus — sehr hoch	keiner
GraphRAG (Wurzelebene C0)	konkurrenzfähige Qualität	>97 % unter Summarization	LLM-Extraktion — teuer

Die Rechnung kommt beim Indexieren

Der Trade-off steht unverblümt im Repository selbst: Vor der Indexierung wird als teurer Operation gewarnt. Mechanisch durchläuft jeder 600-Token-Chunk das LLM mindestens einmal, Gleaning-Runden vervielfachen das, Element-Beschreibungen werden zusammengefasst, und für jede Community auf jeder Hierarchieebene entsteht ein Report. Für einen Millionen-Token-Korpus bedeutet das Tausende LLM-Aufrufe — Größenordnungen über den Kosten, denselben Text nur einzubetten.

Ebenso wichtig ist, was GraphRAG nicht leistet. Einfache Faktenfragen verbessert es nicht; naives RAG beantwortet sie direkter und deutlich günstiger. Die veröffentlichte Pipeline kennt keine inkrementellen Updates — ein geänderter Korpus heißt Neu-Indexierung. Extraktionsfehler wandern unbemerkt in den Graphen. Und die Evaluation stützt sich auf einen LLM-Richter, zwei Datensätze und eine Frageklasse.

Ausblick im Juni 2024

Wir erwarten, dass die Indexierungskosten schneller fallen, als die Skepsis vermuten lässt. Microsoft arbeitet bereits an automatischem Tuning der Extraktions-Prompts, und kleinere, auf Extraktion spezialisierte Modelle sind der naheliegende nächste Schritt. Portierungen in die LangChain- und LlamaIndex-Ökosysteme sowie verwaltete Graph-RAG-Angebote halten wir binnen Monaten für wahrscheinlich. Die hierarchische Community-Zusammenfassung selbst — ein Korpus, der sein eigenes Inhaltsverzeichnis schreibt — ist ein Muster, das diese konkrete Implementierung überdauern dürfte.

Unsere Arbeitsposition bei Blue IT Systems: Behandeln Sie den Graphen als abgeleiteten Index, nie als zweite Quelle der Wahrheit. Für lokale Fragen bleibt Vektorsuche das richtige Werkzeug. Der Graph-Index rechnet sich dort, wo globale Fragen wiederholt an einen stabilen Korpus gestellt werden. Inkrementelle Indexierung und belastbare Evaluationsstandards sind die offenen Probleme, die wir beobachten werden.