GraphRAG: Von lokaler zu globaler abfrageorientierter Zusammenfassung

Microsofts GraphRAG-Paper erschien im April 2024 und wurde schnell zur Referenz für alle, die sich fragten, ob Wissensgraphen RAG aus seinem offensichtlichsten Fehlermodus retten könnten: Fragen, die eine Synthese des gesamten Korpus erfordern, anstatt nur das Abrufen einer spezifischen Textstelle. Ich lese es jetzt, weil das vorherige Protokoll zu FinAuditing aufzeigte, wie LLMs mit dokumentübergreifenden XBRL-Strukturen kämpfen – und der Community-Summary-Ansatz von GraphRAG ist die prominenteste Antwort auf genau diese Art von globalen Reasoning-Problemen.

Das Paper

"From Local to Global: A Graph RAG Approach to Query-Focused Summarization" von Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Dasha Metropolitansky, Robert Osazuwa Ness und Jonathan Larson (Microsoft, arXiv:2404.16130) schlägt eine zweistufige, LLM-gesteuerte Pipeline zur Beantwortung von sogenannten "globalen Sensemaking-Fragen" vor – Abfragen wie "Was sind die Hauptthemen in diesem Datensatz?", die Standard-Vektor-RAG nicht beantworten kann, da keine einzelne Passage die Antwort enthält.

Der Ansatz erfolgt in zwei Phasen. Während der Indizierung extrahiert ein LLM Entitäten, Beziehungen und Behauptungen (Claims) aus jedem Textabschnitt, setzt diese zu einem gewichteten Entitätsgraphen zusammen und führt dann eine Leiden-Community-Erkennung durch, um den Graphen in eine Hierarchie verwandter Cluster zu unterteilen. Dabei wird für jede Community auf jeder Ebene eine natürlichsprachliche Zusammenfassung erstellt. Zur Abfragezeit generiert jede Community-Zusammenfassung unabhängig eine Teilantwort (der Map-Schritt). Diese Teilantworten werden nach hilfreichen Scores bewertet und bis zum Limit des Kontextfensters zusammengesetzt (der Reduce-Schritt). Das Ergebnis ist eine finale, synthetisierte Antwort.

Kernideen

• Die hierarchische Leiden-Community-Erkennung strukturiert das Korpus in vier Granularitätsstufen (C0–C3), wodurch Nutzer die Antworttiefe gegen Token-Kosten abwägen können – Zusammenfassungen auf Root-Ebene erforderten 97 % weniger Token als die direkte Verarbeitung des Quelltextes.
• In zwei Testkorpora – Podcast-Transkripten (~1 Mio. Token, 8.564 Entitäten, 20.691 Beziehungskanten) und Nachrichtenartikeln (~1,7 Mio. Token, 15.754 Entitäten, 19.520 Kanten) – erreichte GraphRAG in LLM-bewerteten Paarvergleichen Gewinnraten von 72–83 % bei der Vollständigkeit und 62–82 % bei der Diversität gegenüber Vektor-RAG.
• Das Map-Reduce-Design vermeidet LLM-Aufrufe mit langem Kontext zur Abfragezeit: Community-Zusammenfassungen sind vorberechnet, sodass das Retrieval zum Abrufen einer Zusammenfassung wird, anstatt Rohdokumente erneut zu verarbeiten.
• Das Paper benchmarkt sechs Bedingungen: vier GraphRAG-Hierarchieebenen, Textzusammenfassung (TS) und semantische Suche (SS). Globale GraphRAG-Bedingungen übertreffen SS bei Sensemaking-Fragen konsistent; SS schneidet bei spezifischen Lookup-Abfragen besser ab.
• Experimente zur Claim-Extraktion ergaben, dass globale Bedingungen durchschnittlich 31–34 Claims pro Antwort extrahierten, verglichen mit 25–26 bei Vektor-RAG, was auf eine breitere thematische Abdeckung unabhängig von den Bewertungsvorlieben des LLM-Judges hindeutet.
• Die Pipeline erfordert kein domänenspezifisches Schema oder eine Ontologie – Entitätsextraktion, Beziehungsbeschriftung und Community-Zusammenfassung basieren rein auf Prompt-Inferenz.

Was Bestand hat – und was nicht

Die zentrale architektonische Erkenntnis ist korrekt: Cosinus-Ähnlichkeit-RAG kann keine Fragen auf Korpus-Ebene beantworten, da es kein einzelnes Teilstück gibt, das das Ganze repräsentiert. Die vorberechneten Community-Zusammenfassungen von GraphRAG sind ein prinzipieller Workaround, und die Leiden-basierte Hierarchie ist eine echte Designentscheidung, die es ermöglicht, je nach Kostentoleranz von groben globalen Zusammenfassungen zu feinkörnigen Cluster-Zusammenfassungen zu navigieren.

Die Evaluierung weist jedoch ernsthafte Probleme auf. Eine aktuelle unabhängige Studie (arXiv:2506.06331) untersuchte die LLM-as-Judge-Methodik, die von GraphRAG und seinen Nachfolgern verwendet wird, und fand drei systematische Biases: Positions-Bias (Gewinnraten verschieben sich um über 30 %, nur indem man vertauscht, welche Antwort zuerst im Prompt erscheint), Längen-Bias (ein Unterschied von 25 Token in einer 200-Token-Antwort erzeugt eine Schwankung der Gewinnrate um 50 Punkte) und Trial-Bias (identische Evaluierungen führen über verschiedene Durchläufe hinweg zu widersprüchlichen Ergebnissen). Nach Korrektur dieser Faktoren brechen die behaupteten Leistungsvorteile ein – die berichtete Gewinnrate von LightRAG gegenüber naivem RAG korrigiert sich von 66,7 % auf 39,06 %. Die Vollständigkeitszahlen von GraphRAG (72–83 %) leiden mit fast absoluter Sicherheit unter derselben Methodik.

Auch die Indizierungskosten sind ein reales Hindernis. Eine Praktiker-Analyse bezifferte die Kosten für die Indexerstellung bei mittelgroßen Korpora auf 47,9 $ mit GPT-4o. Microsofts eigene LazyGraphRAG-Variante, die als Nachfolger veröffentlicht wurde, reduziert dies auf 0,1 % der vollen GraphRAG-Kosten, indem sie die Graphextraktion auf die Abfragezeit verschiebt – ein implizites Geständnis, dass das ursprüngliche Indizierungsbudget für viele reale Einsätze unpraktisch ist.

Zudem sind die beiden Evaluierungskorpora eng gefasst: zwei englischsprachige Datensätze von jeweils 1–1,7 Mio. Token. Die Autoren räumen ein, dass die Generalisierung auf andere Domänen und Skalierungen unbekannt ist. Für strukturierte oder semistrukturierte Daten – Finanzberichte, Ledger-Exporte – könnten die für narrativen Text optimierten Entitätsextraktions-Prompts die tabellarischen und hierarchischen Beziehungen übersehen, auf die es in der Praxis am meisten ankommt.

Warum das für Finanz-KI wichtig ist

Ein Beancount-Ledger ist genau das Korpus, in dem globale Sensemaking-Fragen natürlich entstehen: "Was sind meine größten Ausgabenkategorien in den letzten drei Jahren?" oder "Welche Lieferantenkonten sind im Jahresvergleich schneller als 20 % gewachsen?". Standard-RAG kann diese Fragen nicht beantworten, da kein einzelner Eintrag die Antwort enthält – der Agent muss über Tausende von Transaktionen hinweg synthetisieren.

Der Community-Summary-Ansatz von GraphRAG lässt sich darauf übertragen: Wenn die Wissensgraph-Knoten Konten, Zahlungsempfänger und Transaktionskategorien sind und die Kanten Kookkurrenz- oder übergeordnete Kontobeziehungen darstellen, dann werden Community-Zusammenfassungen zu vorberechneten aggregierten Ansichten über das Hauptbuch. Die Hierarchie spiegelt zudem wider, wie der Kontoplan von Beancount Daten bereits strukturiert – Aktiva, Ausgaben und Einkommen gliedern sich rekursiv, was natürlich zu hierarchischem Clustering im Leiden-Stil passt.

Dennoch sind die Erkenntnisse zum Evaluierungs-Bias eine Warnung: Die beeindruckenden Gewinnraten im Paper halten einer strengen kontrollierten Prüfung möglicherweise nicht stand, und die Indizierungskosten machen dies zu einer riskanteren technischen Wette, als es scheint. Speziell für Beancount könnten strukturierte Aggregationen – SQL-ähnliche Abfragen oder Pandas über das exportierte Hauptbuch – LLM-gesteuerte Community-Zusammenfassungen bei deterministischen Analysen übertreffen. Der Wert von GraphRAG läge am höchsten bei narrativ geprägten Fragen, etwa bei der Analyse von Transaktionsnotizen und Lieferantennamen im großen Stil, wo echte Ambiguität besteht, die strukturierte Abfragen nicht auflösen können.

Was als Nächstes zu lesen ist

• LazyGraphRAG (Microsoft Research Blog, 2024) – Microsofts kostenreduzierte Variante, die die Graphextraktion verzögert; direkt relevant für die Frage, ob der GraphRAG-Ansatz auf echter Ledger-Ebene ohne prohibitive Indizierungskosten einsetzbar ist.
• "How Significant Are the Real Performance Gains? An Unbiased Evaluation Framework for GraphRAG" (arXiv:2506.06331) – Das systematische Bias-Audit; Pflichtlektüre, bevor man Gewinnraten aus LLM-as-Judge-Evaluierungen von Zusammenfassungsmethoden akzeptiert.
• "Towards Verifiably Safe Tool Use for LLM Agents" (arXiv:2601.08012, ICSE 2026) – Der nächste Punkt auf der Leseliste; verlagert den Fokus von der Zusammenfassung zur Sicherheit bei Schreibvorgängen, was das dringendere ungelöste Problem für Beancount-Agenten darstellt.