GraphRAG-gids: wanneer kennisgrafen vector RAG verslaan (en wanneer niet)

GraphRAG-gids: wanneer kennisgrafen vector RAG verslaan (en wanneer niet)

GraphRAG is niet dood, maar het is ook niet de standaard. microsoft/graphrag scheepte op 2026-07-18 v3.1.1 uit met 35.088 GitHub-sterren, en drie benchmarkpapers uit 2026 melden nu hardop dat het vaak verliest van gewone vector retrieval. Dus beantwoordt deze GraphRAG-gids de enige vraag die overblijft: is een kennisgraaf de indexeerfactuur waard?

Moet je GraphRAG gebruiken? Het korte antwoord

Gebruik GraphRAG als je vragen entiteiten overstijgen of het hele corpus beslaan, zoals "aan welke leveranciers verkoopt onze grootste klant ook?" Blijf bij vanilla of hybride RAG voor single-hop feitenzoekwerk, snel veranderende documenten en strakke latency-budgetten. De graf verdient zichzelf terug op multi-hop-vragen en kost overal elders geld.

GraphRAG is niet dood en niet de standaard. Hij verdient zijn indexeerfactuur als je vragen multi-hop of corpus-breed zijn, en verliest geld als ze dat niet zijn.

De korte versie:

• GraphRAG wint op multi-hop en corpus-brede vragen; vanilla RAG wint op single-hop zoekopdrachten.
• De 2026-benchmarks zijn gemengd: graven helpen bij aggregatie maar kunnen fijngmazige samenvattingen schaden.
• De kosten vallen bij het indexeren, in LLM-extractiecalls, niet bij de query.
• Draai Basic Search als controle op je eigen corpus voordat je iets bouwt.

Als je al een werkende vector-RAG-pijplijn draait, is de enige beslissing of een graf erbovenop zichzelf terugverdient. De tabel hieronder is het hele argument in zes rijen, en waar hij zegt dat je bij vanilla moet blijven, is dat het eerlijke antwoord, vaker dan vendors toegeven. Hybride BM25 plus vector retrieval dekt de meeste van deze gevallen helemaal zonder graf.

Wat GraphRAG eigenlijk is: van chunks naar communities

GraphRAG is retrieval-augmented generation over een kennisgraaf in plaats van over losse chunks. Bij het indexeren extraheert een LLM entiteiten en relaties uit je documenten, het Leiden-algoritme groepeert die entiteiten in communities, en elke community krijgt een samenvatting. Bij de query beantwoorden de graf plus die samenvattingen vragen die een top_k-venster over chunks structureel niet kan.

De pijplijn, van begin tot eind:

Documents
  |
  v
Chunks --> LLM entity + relationship extraction
  |
  v
Knowledge graph (entities = nodes, relations = edges)
  |
  v
Leiden community detection --> community summaries
  |
  v
Vector index over entity + community descriptions

Twee fasen doen het werk. De indexeerfase is de dure: elke chunk kost een LLM-call om entiteiten en relaties eruit te halen, en de community-samenvattingen kosten daarbovenop nog meer calls. De queryfase is waar de winst zichtbaar wordt. Omdat de graf relaties expliciet opslaat, wordt een vraag als "aan welke leveranciers verkoopt onze grootste klant ook?" een traversal in plaats van de hoop dat de juiste twee chunks in hetzelfde top_k-venster landen.

De samenvattingen doen ertoe omdat Global Search ze daadwerkelijk leest: corpus-brede vragen worden beantwoord vanuit vooraf geschreven community-proza, niet vanuit ruwe chunks. En elke edge is een oordeel van het LLM, opgeslagen als triple die je in Cypher zou kunnen bevragen op een echte grafdatabase. Dat ontwerp is ook waarom indexeren de kosten domineert, wat de cijfers hieronder concreet maken.

De framing die zijn plek verdient: vanilla RAG haalt passages op, en GraphRAG haalt structuur op. Je keuze van embeddingmodel doet er nog steeds toe voor de vectorlaag, en je vectordatabase slaat nog steeds de beschrijvingen op, maar de graf is het nieuwe dragende onderdeel. De officiële Index Overview-documentatie beschrijft elke fase volledig.

Wat zijn de vier GraphRAG-querymethoden?

De GraphRAG-query-engine scheept vier methoden uit: Local Search, Global Search, DRIFT Search en Basic Search. Local Search redeneert vanuit specifieke entiteiten naar buiten, Global Search aggregeert community-samenvattingen over het hele corpus, DRIFT Search mengt de twee recursief, en Basic Search is een gewone vector-baseline. Een vijfde functie, Question Generation, zit bovenop de engine in plaats van ernaast.

We controleerden de live documentatie op microsoft.github.io/graphrag/query/overview/ op 2026-07-30, en het aantal is vier. De meeste ranking-gidsen noemen er twee of drie. Dezelfde check vond het woord "lazy" nul keer op zowel de Index- als de Query-overviewpagina's, wat ertoe doet voor de kostensectie hieronder.

De rij die je aandacht verdient is de laatste. Basic Search is de ingebouwde vanilla-vector-baseline, en hij bestaat zodat je de graf tegen gewone retrieval kunt A/B-testen op je eigen corpus en kunt ontdekken of de graf zijn factuur verdient. Dat is geen trivia; het is de hele beslissingsprocedure van deze gids in één functie. Draai eerst Basic Search. Als Local, Global of DRIFT Search hem niet verslaat op de vragen die je daadwerkelijk krijgt, is de graf een kostenpost, geen upgrade.

Wat vonden de 2026-benchmarks eigenlijk?

Drie benchmarkpapers uit 2026 concluderen dat GraphRAG helpt bij multi-hop- en multi-fact-aggregatietaken maar elders vaak onderdoet voor vanilla RAG. Een ervan bouwde specifiek een benchmark om te vinden waar graven verliezen. Alle drie zijn ze het erover eens dat de winst afhangt van het vraagtype, niet van de corpusgrootte. Het bewijs zegt dat GraphRAG situationeel is, niet standaard.

Een vierde inspanning, GraphRAG-Bench (repository), evalueert negen GraphRAG-methoden over 16 disciplines en 20 leerboeken, en komt vanuit een bredere hoek tot dezelfde conclusie.

Alle drie de papers convergeren op één punt: de graf verdient zijn kosten bij multi-hop-aggregatie en verliest ze bij fijngmazige recall.

Onze lezing: de hype cycle heeft de schade aangericht, en deze papers zijn de correctie. Geen ervan zegt dat graven nutteloos zijn. Wat ze consequent zeggen, is dat de aggregatiestap die GraphRAG goed maakt in corpus-brede thema's dezelfde stap is die fijngmazig detail vervaagt. WildGraphBench is het duidelijkste voorbeeld: graven hielpen multi-fact-aggregatie uit een gematigd aantal bronnen, en schaadden de precisie van samenvattingen in dezelfde evaluatie. Dat is geen contradictie; het is één mechanisme dat twee keer opduikt.

Het praktische gevolg is dat je dit niet alleen uit de literatuur kunt beslissen. De papers vertellen je welke vraagtypes je moet testen, niet of jouw corpus er een van is. Daarvoor is precies de Basic Search-controle uit de methodensectie hierboven bedoeld.

Hoeveel kost GraphRAG? (En de LazyGraphRAG-kanttekening die iedereen verkeerd herhaalt)

De kosten van GraphRAG zijn een factuur bij indexeertijd, niet bij querytijd, en precies daarom verrassen ze mensen. De LLM-calls die entiteiten en relaties uit elke chunk extraheren, plus de community-samenvattingsronde, zijn wat het duur maakt. Je betaalt vooraf, voordat er één query draait. Querytijd is goedkoper maar niet gratis: Global Search waaiert uit over community-samenvattingen met een LLM-call per community, daarom staat hij in de methodentabel hierboven als hoog gemarkeerd.

De enige harde openbare cijfers komen van Microsoft Research. Op 2024-11-25 rapporteerde het team dat de indexeerkosten van LazyGraphRAG identiek waren aan vector RAG en 0,1% van de kosten van volledige GraphRAG, en dat hij met 4% van de querykosten van GraphRAG global search de geteste concurrerende methoden overtrof, op zowel lokale als globale querytypes (Microsoft Research). Dat zijn de cijfers van Microsoft, uit de blog van Microsoft, en zo rapporteren we ze; we hebben zelf geen geprijsde indexering gedraaid.

Hier is de correctie die de meeste write-ups missen. LazyGraphRAG is geen pip install-optie. Volgens Microsofts eigen redactienota van 2025-06-06 scheepte hij uit in Microsoft Discovery en Azure Local, niet in het open-source pakket. We controleerden de officiële Index Overview- en Query Overview-pagina's op 2026-07-30: het woord "lazy" komt op beide nul keer voor. Dus als een gids LazyGraphRAG noemt als een variant die je vanmiddag nog kunt opzetten, herhaalt hij een bewering die in de open-source wereld niet meer waar is.

Wat je vandaag kunt doen: het extractiemodel lokaal draaien. De indexeerstap via Ollama op een lokaal model richten haalt per-token API-kosten uit de duurste fase, en het koppelen aan een zelf-gehoste vector store houdt de rest van de factuur bijna op nul.

Welke GraphRAG-library wordt echt onderhouden?

Twee van de zes meest geciteerde GraphRAG-libraries hebben al zes en negen maanden geen push gehad. We haalden deze cijfers op 2026-07-30 uit de GitHub API, en de telling hieronder is de check die oudere round-ups overslaan, met het commando om hem opnieuw te draaien voordat je voor een library kiest. LightRAG en microsoft/graphrag zijn de actieve; nano-graphrag en fast-graphrag drijven richting abandonware.

for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; done

Onze lezing: sterren zijn een vanity metric; de pushdatum is het getal dat ertoe doet. LightRAG en microsoft/graphrag worden beide actief onderhouden, met Graphiti vlak erachter op een temporele-grafhoek. nano-graphrag en fast-graphrag zijn de twee die oudere posts nog op reputatie alleen aanbevelen, en geen van beide heeft in een half jaar iets uitgebracht.

Hoe kiezen: kies microsoft/graphrag als je de referentie-implementatie met de vier officiële querymethoden wilt, LightRAG als je het meest actieve project en een lichtere voetafdruk wilt, en een door vendor onderhouden library zoals neo4j-graphrag-python als je de database van die vendor al draait. Vermijd alles waarvan de laatste push een half jaar ouder is dan je project.

Graphiti verdient één afgebakende notitie: zijn temporele-grafontwerp is gebouwd voor retrieval over tijdbewuste data, en het overlapt met agentgeheugen, wat we apart behandelen in onze gids over Graphiti en temporeel grafgeheugen. Voor het bredere veld, zie het bredere RAG-toolinglandschap.

Wat breekt na dag 200: grafdrift en re-extractie

Grafdrift is de belasting die je na de launch betaalt, en het is met reden het nummer-één-bezwaar van practitioners. Elke tutorial behandelt de graf als iets dat je één keer bouwt. Echte teams lopen vast op dag 200.

Drie dingen takelen af. Ten eerste, herindexeren bij documentupdates. Als 40 documenten veranderen, kun je ze niet simpelweg her-embedden; je moet LLM-extractie opnieuw draaien op de veranderde chunks, de nieuwe entiteiten afstemmen tegen de oude graf, en de getroffen communities en hun samenvattingen herberekenen. Eén Medium-gids noemt incrementele updates makkelijk. De practitioners op r/Rag zijn het er niet mee eens. De OP van een thread van 2026-04-25 die BM25 plus BGE-M3 draait op ongeveer 600 documenten zei het zonder omhaal: "LLM-gebaseerde entiteit-/relatie-extractie is luidruchtig, en herindexeren bij documentupdates ziet er pijnlijk uit."

Ten tweede, entity-resolutie-verval. "Acme Corp", "Acme" en "ACME Corporation" arriveren maanden uit elkaar in verschillende documenten en splitsen in drie nodes die er één zouden moeten zijn. Niets voegt ze automatisch samen.

Ten derde, relaties die waar waren bij extractie en stilzwijgend niet meer waar werden. Niemand krijgt een alert wanneer een reports_to-edge veroudert.

def on_documents_changed(changed_docs):
    stale = find_affected_nodes(changed_docs)
    re_extract(changed_docs)
    reconcile_entities(stale)
    recompute_communities(affected_only=True)
    re_summarize(affected_communities)

Een codebase is het worst case, en het interessantste. Autocomplete suggereert nu "graphrag for codebase", "graphrag claude code" en "graphrag mcp server", en een codebase is een graf die per uur verandert: elke commit herschrijft call-edges, verplaatst symbolen en verwijdert functies. Dat is grafdrift op een schema dat geen enkele nightly herindexering volledig kan bijhouden. Het is ook waarom de serieuze code-graaftools op deterministische parsers zoals tree-sitter en LSP leunen voor de edges en het LLM reserveren voor het proza eromheen: docstrings, commitberichten, reviewthreads. Als je een repo vergraft, vergraf dan de langzaam bewegende laag met het LLM en de snel bewegende met een parser.

Wat zeggen developers eigenlijk over GraphRAG?

Werkende developers zijn verdeeld, en Google lijkt het te weten: een Reddit-thread staat op positie twee voor "graphrag vs rag", wat de zoekmachine je vertelt dat dit onderwerp peer-mening wil, geen vendor-copy.

De scepsis is echt. Op de r/Rag-thread uit 2024 "Would you always recommend (knowledge) graph RAG over normal RAG?" (10 punten, 86% upvotes) schreef u/EncartaIt: "Alle tutorials die ik vind zijn te simplistisch en maken geen sterke case voor het kennisgraafpatroon." u/Prestigious_Run_4049 was botter: "Ik vind graph rag gewoon hype. Mensen praten er graag over en het klinkt cool maar niemand gebruikt het echt in echte use cases." Niet iedereen is het eens. u/pytheryx, argumenterend vanuit productie, merkte op dat graf-retrieval wint bij lijsttype-vragen die context nodig hebben uit meer chunks dan top_k teruggeeft; zijn whitepaper-corpus heeft ongeveer 50 chunks nodig voor een volledig antwoord.

De thread uit 2026 is afgemeterder. u/Popular_Sand2773: "De meeste graph rag-setups valsspelen gewoon op schaal. Je draait een standaard vector- of metadata-zoekopdracht om seed-nodes te vinden en dan loop je eromheen." u/ggone20, die een systeem van ruwweg 300 miljoen artefacten draait: "Op schaal kun je letterlijk niet zonder ze om echte vragen te beantwoorden."

Onze lezing sluit aan bij het scherpste argument in beide threads: het omslagpunt is de complexiteit van je vragen, niet de grootte van je corpus. Dat is ook wat de benchmarks hierboven vonden, daarom scharen we ons bij de practitioners die de tool afbakenen voor multi-hop-werk in plaats van bij degenen die hem dood noemen.

Hoe Techsy dit aanpakt

Hier is de volgorde die we gebruiken bij klantprojecten, en hij is bewust saai.

Ten eerste, bewijs het plafond van hybride retrieval. De meeste "we hebben een graf nodig"-verzoeken die we horen zijn eigenlijk een chunking- of een reranking-probleem in vermomming. Een BM25-plus-vector-pijplijn met een fatsoenlijke reranker beantwoordt meer dan teams verwachten.

Ten tweede, draai Basic Search als controle op je eigen corpus voordat je iets bouwt. Dat is precies waar de vierde querymethode voor bedoeld is: een gewone-vector-baseline waarmee je de graf kunt A/B-testen, op jouw data, met jouw vragen.

Ten derde, bouw de graf pas wanneer een gemeten klasse vragen die controle niet haalt. Als multi-hop of corpus-brede query's missen, heb je een echte case. Als ze dat niet doen, heb je jezelf net een indexeerfactuur en een driftprobleem bespaard.

Wil je een tweede paar ogen op je retrieval-stack? Plan een gratis adviesgesprek.

Veelgestelde vragen

Hoe werkt GraphRAG?

GraphRAG indexeert je documenten in een kennisgraaf. Een LLM extraheert entiteiten en relaties uit elke chunk, het Leiden-algoritme clustert die entiteiten in communities, en elke community krijgt een samenvatting. Bij de query doorzoekt de engine de graf en die samenvattingen, zodat hij feiten kan verbinden die in verschillende chunks zitten.

Hoe verschilt GraphRAG van RAG?

Standaard RAG haalt de top-k meest vergelijkbare chunks op en voert ze aan het model. GraphRAG haalt structuur op: entiteiten, de relaties ertussen, en vooraf geschreven community-samenvattingen. Die extra structuur is wat hem multi-hop- en corpus-brede vragen laat beantwoorden, en het is ook wat indexeren trager en duurder maakt.

Wanneer moet ik GraphRAG gebruiken?

Gebruik het wanneer je vragen entiteiten overstijgen of het hele corpus beslaan, zoals leveranciers-overlapvragen of terugkerende-thema-analyse over duizenden documenten. Sla het over voor single-hop feitenzoekwerk, snel veranderende corpora, en strakke latency- of kostenbudgetten. Als een gewone hybride pijplijn een vraagklasse al beantwoordt, voegt de graf kosten toe zonder waarde toe te voegen.

Is GraphRAG dood?

Nee, maar hij is ook niet de standaard. De 2026-benchmarks tonen dat hij bij alledaagse taken vaak onderdoet voor vanilla RAG, wat de hype doodde, terwijl hij nog steeds wint bij multi-hop- en aggregatievragen. De eerlijke framing is situationeel: GraphRAG verdient zijn kosten voor de juiste vraagtypes en verliest geld voor de rest.

Wat zijn de GraphRAG-querymethoden?

De officiële query-engine scheept er vier uit: Local Search voor entiteitsgerichte vragen, Global Search voor corpus-brede aggregatie, DRIFT Search voor een recursieve mengvorm van beide, en Basic Search voor gewone vector retrieval. Een vijfde functie, Question Generation, zit erbovenop. Basic Search doet er het meest toe: het is de controle waarmee je de graf A/B-test.

Hoeveel kost GraphRAG-indexering?

De kosten vallen bij het indexeren, in de LLM-calls die entiteiten en relaties uit elke chunk extraheren plus community-samenvatting. Microsoft Research rapporteerde LazyGraphRAG-indexering op 0,1% van de kosten van volledige GraphRAG en identiek aan vector RAG, maar die variant scheepte uit in Microsoft-producten, niet in de open-source library. We hebben zelf geen geprijsde indexering gedraaid.

Kan ik GraphRAG lokaal draaien met Ollama?

Ja. De microsoft/graphrag-library laat je indexering en query's richten op een lokaal model dat door Ollama wordt geserveerd, wat per-token API-kosten uit de extractiestap haalt. Je ruilt snelheid en kwaliteit voor kosten: lokale modellen zijn zwakker in entiteitsextractie, dus verwacht luidruchtiger graven en langere indexeer-runs op bescheiden hardware.

Is LightRAG of Microsoft GraphRAG beter?

Ze optimaliseren voor verschillende dingen. LightRAG (38.353 sterren, gepusht 2026-07-30) is het meest actief en lichter om te draaien; microsoft/graphrag (35.088 sterren, v3.1.1) is de referentie-implementatie met de vier officiële querymethoden. Kies LightRAG voor een efficiënte productiegraf, die van Microsoft voor spec-getrouw gedrag en de Basic Search-controle.

Wie heeft GraphRAG gemaakt en wanneer?

Microsoft Research maakte GraphRAG. Het team publiceerde de paper in 2024 en onderhoudt de open-source microsoft/graphrag-repository onder de MIT-licentie, met documentatie op microsoft.github.io/graphrag. De referentie-library bereikte v3.1.1 op 2026-07-18, en een actief ecosysteem van third-party implementaties, waaronder LightRAG en Graphiti, is eromheen gegroeid.

Het oordeel: wanneer een graf zijn kosten verdient

Het bewijs wijst in één richting, dus hier is het standpunt.

• GraphRAG is niet dood. Hij is situationeel, en de 2026-benchmarks zeggen het hardop.
• Hij verdient zijn indexeerfactuur bij multi-hop-entiteitsvragen en corpus-brede aggregatie. Hij verliest geld bij single-hop zoekopdrachten.
• De kosten zijn een factuur bij indexeertijd, en de goedkope variant die iedereen citeert, LazyGraphRAG, bereikte nooit de open-source library.
• De graf takelt af na de launch: entity-resolutie drijft weg en relaties verouderen, dus begroot herindexering.
• Draai Basic Search als controle op je eigen corpus voordat je iets bouwt.

Eén zin: een kennisgraaf verdient zijn kosten wanneer je vragen multi-hop of corpus-breed zijn, en niet eerder. Als je een second opinion wilt over je retrieval-stack, plan dan een gratis adviesgesprek.