GraphRAG: Van Lokale naar Globale Query-Gerichte Samenvatting

Het GraphRAG-paper van Microsoft verscheen in april 2024 en werd al snel de standaardreferentie voor iedereen die zich afvroeg of kennisgrafen RAG konden redden van zijn meest voor de hand liggende tekortkoming: vragen die synthese van een volledig corpus vereisen in plaats van het ophalen van een specifieke passage. Ik lees het nu omdat het eerdere verslag over FinAuditing blootlegde hoe LLM's worstelen met XBRL-structuren over meerdere documenten — en GraphRAG's aanpak met community-samenvattingen is het meest prominente bestaande antwoord op precies dat soort globale redeneerproblemen.

Het paper

"From Local to Global: A Graph RAG Approach to Query-Focused Summarization," door Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Dasha Metropolitansky, Robert Osazuwa Ness en Jonathan Larson (Microsoft, arXiv:2404.16130), stelt een tweetraps LLM-gestuurde pipeline voor voor het beantwoorden van wat de auteurs "globale zingevingsvragen" noemen — query's zoals "Wat zijn de belangrijkste thema's in deze dataset?" die standaard vector-RAG niet kan beantwoorden omdat geen enkele passage het antwoord bevat.

De aanpak verloopt in twee fasen. Tijdens het indexeren extraheert een LLM entiteiten, relaties en beweringen uit elk tekstblok, voegt deze samen in een gewogen entiteitsgraaf en voert vervolgens Leiden-community-detectie uit om de graaf te partitioneren in een hiërarchie van gerelateerde clusters, waarbij voor elke community op elk niveau een samenvatting in natuurlijke taal wordt gegenereerd. Op het moment van de query genereert elke community-samenvatting onafhankelijk een deelantwoord (de map-stap), deze deelantwoorden worden gerangschikt op behulpzaamheidsscore en samengevoegd tot de limiet van het contextvenster (de reduce-stap), en het resultaat is een uiteindelijke gesynthetiseerde reactie.

Belangrijkste ideeën

• Leiden hiërarchische community-detectie structureert het corpus in vier grofheidsniveaus (C0–C3), waardoor gebruikers de diepte van de reactie kunnen afwegen tegen tokenkosten — samenvattingen op root-niveau vereisten 97% minder tokens dan het direct verwerken van brontekst.
• Op twee testcorpora — transcripties van podcasts (~1M tokens, 8.564 entiteiten, 20.691 relatieranden) en nieuwsartikelen (~1,7M tokens, 15.754 entiteiten, 19.520 randen) — behaalde GraphRAG winstpercentages van 72–83% voor volledigheid en 62–82% voor diversiteit ten opzichte van vector-RAG in door LLM beoordeelde paarsgewijze vergelijkingen.
• Het map-reduce ontwerp vermijdt long-context LLM-aanroepen op query-tijd: community-samenvattingen worden vooraf berekend, dus het ophalen wordt het ophalen van een samenvatting in plaats van het opnieuw verwerken van onbewerkte documenten.
• Het paper benchmarkt zes condities: vier GraphRAG-hiërarchieniveaus, tekstsamenvatting (TS) en semantisch zoeken (SS). Globale GraphRAG-condities presteren consequent beter dan SS op zingevingsvragen; SS presteert beter op specifieke zoekquery's.
• Experimenten met extractie van beweringen toonden aan dat globale condities gemiddeld 31–34 beweringen per antwoord extraheerden, tegenover 25–26 voor vector-RAG, wat suggereert dat de dekking van onderwerpen breder is, onafhankelijk van de scorevoorkeuren van de LLM-beoordelaar.
• De pipeline vereist geen domeinspecifiek schema of ontologie — extractie van entiteiten, labelen van relaties en samenvatten van communities gebeurt uitsluitend via geprompteerde inferentie.

Wat standhoudt — en wat niet

Het architecturale kerninzicht is correct: cosine-similarity RAG kan geen vragen op corpusniveau beantwoorden omdat er geen enkel tekstblok is dat het geheel vertegenwoordigt. De vooraf berekende community-samenvattingen van GraphRAG zijn een principiële workaround, en de op Leiden gebaseerde hiërarchie is een reële ontwerpkeuze waarmee je kunt navigeren van grove globale samenvattingen naar fijnmazige cluster-samenvattingen, afhankelijk van de kostentolerantie.

Maar de evaluatie kent serieuze problemen. Een recente onafhankelijke studie (arXiv:2506.06331) controleerde de LLM-als-beoordelaar methodologie die door GraphRAG en zijn opvolgers wordt gebruikt en vond drie systematische biases: positiebias (winstpercentages verschuiven met meer dan 30% simpelweg door te wisselen welk antwoord als eerste in de prompt verschijnt), lengtebias (een verschil van 25 tokens in een antwoord van 200 tokens veroorzaakt een schommeling van 50 punten in het winstpercentage) en trial-bias (identieke evaluaties leveren tegenstrijdige resultaten op tussen verschillende runs). Na correctie hiervoor storten de geclaimde prestatievoordelen in — het gerapporteerde winstpercentage van 66,7% van LightRAG ten opzichte van naïeve RAG wordt gecorrigeerd naar 39,06%. De eigen cijfers van GraphRAG (72–83% volledigheid) lijden vrijwel zeker onder dezelfde methodologie.

De indexeringskosten zijn ook een reëel obstakel. Een analyse van een praktijkbeoefenaar noemde kosten voor indexconstructie die $47,9 bereikten met GPT-4o voor corpora van gemiddelde grootte. Microsofts eigen LazyGraphRAG-variant, uitgebracht als vervolg, brengt dit terug naar 0,1% van de volledige GraphRAG-kosten door de grafextractie uit te stellen tot het moment van de query — wat een impliciete erkenning is dat het oorspronkelijke indexeringsbudget onpraktisch is voor veel echte implementaties.

De twee evaluatiecorpora zijn ook beperkt: twee Engelstalige datasets van elk 1–1,7 miljoen tokens. De auteurs geven toe dat generalisatie naar andere domeinen en schalen onbekend is. Voor gestructureerde of semi-gestructureerde data — financiële deponeringen, export van grootboeken — kunnen de entiteitsextractie-prompts die zijn geoptimaliseerd voor narratieve tekst de tabelvormige en hiërarchische relaties missen die in de praktijk het belangrijkst zijn.

Waarom dit belangrijk is voor financiële AI

Een Beancount-grootboek is precies het corpus waar globale zingevingsvragen natuurlijk ontstaan: "Wat zijn mijn grootste uitgavencategorieën van de afgelopen drie jaar?" of "Welke leveranciersrekeningen zijn sneller gegroeid dan 20% op jaarbasis?" Standaard RAG kan deze niet beantwoorden omdat geen enkele invoer het antwoord bevat — de agent moet synthetiseren over duizenden transacties heen.

De aanpak van GraphRAG met community-samenvattingen sluit hierop aan: als de knooppunten in de kennisgraaf rekeningen, begunstigden en transactiecategorieën zijn, en de randen relaties van gezamenlijk voorkomen of bovenliggende rekeningen zijn, dan worden community-samenvattingen vooraf berekende geaggregeerde weergaven van het grootboek. De hiërarchie weerspiegelt ook hoe de rekeningenboom van Beancount gegevens al structureert — Assets, Expenses en Income worden recursief opgesplitst, wat een natuurlijke match is voor Leiden-achtige hiërarchische clustering.

Dat gezegd hebbende, zijn de bevindingen over evaluatiebias een waarschuwing: de indrukwekkende winstpercentages in het paper houden mogelijk geen stand onder rigoureuze gecontroleerde tests, en de indexeringskosten maken dit een zwaardere technische gok dan het lijkt. Specifiek voor Beancount kunnen gestructureerde aggregaties — SQL-achtige query's of pandas over het geëxporteerde grootboek — beter presteren dan LLM-gestuurde community-samenvattingen voor deterministische analyses. De waarde van GraphRAG zou het grootst zijn voor vragen met veel tekst, zoals het redeneren over transactienota's en namen van leveranciers op grote schaal, waar sprake is van echte ambiguïteit die gestructureerde query's niet kunnen oplossen.

Wat hierna te lezen

• LazyGraphRAG (Microsoft Research blog, 2024) — Microsofts kostenbesparende variant die de grafextractie uitstelt; direct relevant voor de vraag of de aanpak van GraphRAG inzetbaar is op de schaal van echte grootboeken zonder prohibitieve indexeringskosten.
• "How Significant Are the Real Performance Gains? An Unbiased Evaluation Framework for GraphRAG" (arXiv:2506.06331) — de systematische bias-audit; essentiële literatuur voordat men winstcijfers uit LLM-als-beoordelaar evaluaties van samenvattingsmethoden accepteert.
• "Towards Verifiably Safe Tool Use for LLM Agents" (arXiv:2601.08012, ICSE 2026) — het volgende item op de leeslijst; verschuift van samenvatting naar de veiligheid van terugschrijven (write-back), wat het meer prangende onopgeloste probleem is voor Beancount-agents.