05.07.2024 AI Engineering4 Minuten Lesezeit

GraphRAG: Globale Fragen mit Wissensgraphen beantworten

Microsofts GraphRAG extrahiert per LLM einen Entitätsgraphen aus Text, partitioniert ihn mit dem Leiden-Algorithmus und fasst jede Community vorab zusammen. Wir zeigen, warum dieser Index globale Fragen beantworten kann, an denen Vektor-RAG scheitert, wie belastbar die Evaluation ist und weshalb die Indexierungskosten den zentralen Trade-off bilden.

Fragen an den gesamten Korpus

Retrieval-Augmented Generation ist in seiner üblichen Form eine Vektor-Pipeline: Dokumente werden in Chunks zerlegt und eingebettet, zur Anfragezeit wandern die top-k ähnlichsten Chunks ins Kontextfenster. Für lokale Fragen ist das wirksam, weil die Antwort in wenigen Passagen steht und semantische Ähnlichkeit genau diese finden kann.

Bei globalen Fragen stößt das Verfahren an seine Grenzen. Für "Was sind die Hauptthemen dieses Datensatzes?" gibt es keinen einzelnen Antwort-Chunk. Top-k-Retrieval liefert Passagen, die der Frage nur oberflächlich ähneln, und erzeugt daraus 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.

Inzwischen ist die Implementierung öffentlich zugänglich: Das Repository microsoft/graphrag liegt unter MIT-Lizenz auf GitHub und enthält Dokumentation, eine Indexierungs-Engine sowie die Abfragemodi Global und Local Search. Ein eigener Ankündigungsbeitrag fehlt bislang; der Code ist schlicht verfügbar. Entscheidend für die Einordnung: GraphRAG ersetzt keine Vektordatenbank, sondern ergänzt sie um einen aufwendigeren 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 nutzt Global Search Map-Reduce. In der Map-Phase werden die Community-Reports einer gewählten Ebene auf Kontextfenster verteilt und in Teilantworten mit Nützlichkeits-Scores überführt; die Reduce-Phase verdichtet die bestbewerteten Beiträge zur finalen Antwort. Local Search verfolgt den komplementären Weg: Es löst Entitäten aus der Frage auf und kombiniert ihre Graph-Nachbarschaft mit dem zugehörigen Rohtext.

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 die Negativabgrenzung. Einfache Faktenfragen werden nicht besser; naives RAG beantwortet sie direkter und wesentlich günstiger. Die veröffentlichte Pipeline unterstützt keine inkrementellen Updates, sodass Korpusänderungen eine Neu-Indexierung erfordern, und Extraktionsfehler gelangen unbemerkt in den Graphen. Hinzu kommt eine schmale Evidenzbasis: ein LLM-Richter, zwei Datensätze und eine einzige 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 ist daher klar: Der Graph bleibt ein abgeleiteter Index und wird nie zur zweiten Quelle der Wahrheit. Lokale Fragen gehören weiterhin in die Vektorsuche; ein Graph-Index amortisiert sich erst bei wiederkehrenden globalen Fragen an einen stabilen Korpus. Ob sich das Einsatzfeld erweitert, hängt vor allem von inkrementeller Indexierung und belastbareren Evaluationsstandards ab.