RAG versus GraphRAG komt neer op één vraag: moet uw AI-agent vragen beantwoorden over specifieke feiten of over de structuur van uw hele dataset? Vector-RAG wint de eerste; GraphRAG wint de tweede. In 2026 daalden de indexeringskosten van GraphRAG van circa €33.000 naar bijna hetzelfde niveau als vector-RAG — maar die kostendaling betekent niet dat elke retrieval-pipeline ineens een kennisgraaf nodig heeft.
Wat RAG en GraphRAG werkelijk van elkaar onderscheidt
Vector-RAG hakt uw documenten in stukken, embedt ze en haalt de fragmenten op die semantisch het meest lijken op een vraag — een vorm van best-first search. Dat werkt uitstekend bij “wie, wat, wanneer, waar”-vragen waarvan het antwoord in één of twee passages staat. GraphRAG haalt in plaats daarvan entiteiten en relaties uit uw corpus tijdens het indexeren, clustert die in hiërarchische communities en laat een taalmodel elke community samenvatten. Die structuur maakt het mogelijk om “wat zijn de belangrijkste thema's” of “wat zijn de gevolgen van X voor de hele dataset” te beantwoorden — vragen die geen los fragment kan beantwoorden, omdat het antwoord over het hele corpus verspreid is. Microsoft Research, dat de techniek populair maakte, noemt dit het onderscheid tussen local en global search — nog altijd de scherpste manier om te bepalen welke architectuur een bepaalde vraag nodig heeft.
De kostenval die niet meer bestaat
Vroege GraphRAG-implementaties kregen de reputatie onbetaalbaar te zijn: een corpus indexeren met Microsofts oorspronkelijke pipeline kon oplopen tot €33.000 aan LLM-aanroepen, omdat elke entiteit en relatie een door een taalmodel gegenereerde samenvatting nodig had voordat u één vraag kon stellen. Dat cijfer is de reden dat de meeste “RAG vs GraphRAG”-artikelen uit 2024–2025 concluderen dat GraphRAG een luxe voor grote ondernemingen is. Dat advies is verouderd. Microsofts LazyGraphRAG, geïntroduceerd eind 2024 en sinds 2025 onderdeel van Microsoft Discovery, stelt het samenvatten door het taalmodel uit tot het moment van bevragen: de indexeringskosten zijn per definitie gelijk aan gewone vector-RAG, en bij vergelijkbare bevragingskosten evenaart of verslaat het de kwaliteit van volledige GraphRAG global search tegen meer dan 700 keer lagere bevragingskosten. Open-source alternatieven bewogen even snel mee — LightRAG (HKUDS, EMNLP 2025) gebruikt een index met twee lagen — graaf plus vectoren — die incrementeel bijwerkt in plaats van een volledige herindexering te vereisen, tegen ongeveer dezelfde kosten als alleen de tekst embedden. Onafhankelijke analyses spreken inmiddels van een daling van drie ordes van grootte over de periode 2024–2026. Vertaald naar mkb-schaal: wat een middelgroot contractenarchief onder de GraphRAG van 2024 zou hebben gekost om te indexeren, kost bij LazyGraphRAG of LightRAG ongeveer evenveel als datzelfde corpus embedden voor vector-RAG — die verhouding geldt ongeacht de omvang van het corpus, omdat de indexeringskosten van LazyGraphRAG per definitie relatief zijn aan vector-RAG, niet aan een vast bedrag. Kosten zijn niet langer een reden om GraphRAG te vermijden. Het is ook geen reden om het standaard te kiezen.
Hybrid retrieval blijft de standaard in productie
Voordat u naar een kennisgraaf grijpt, moet u eerst hybrid retrieval uitputten: sleutelwoordzoeken (BM25) combineren met dense vector search en beide gerangschikte lijsten samenvoegen, doorgaans met Reciprocal Rank Fusion. Praktijkbenchmarks uit 2026 laten consistent zien dat hybrid retrieval elke losse methode met 15–30% recall verslaat, en sommige enterprise-pipelines melden een recall die stijgt van circa 0,72 met alleen BM25 naar boven de 0,9 met een afgestelde hybrid-plus-reranker-opzet. Voor evaluatie blijft het vierledige metriekenpanel van het RAGAS-framework — faithfulness, answer relevancy, context precision, context recall — het referentiepunt, inmiddels aangevuld in productie door tools als DeepEval voor CI/CD-gates en Langfuse voor tracing. Haalt hybrid retrieval met een reranker uw doelen voor faithfulness en recall, dan heeft u vrijwel nooit een graaf erbovenop nodig. Zitten uw fouten vooral in “het model ziet het grotere geheel niet” in plaats van “het model haalde de verkeerde passage op”, dan is dat het signaal om naar GraphRAG te kijken.
Het beslissingskader
Drie vragen bepalen de keuze, in deze volgorde.

- Vraagpatroon: als de meeste echte gebruikersvragen opzoekvragen zijn (“wat is de deadline in contract X”), wint hybrid vector-RAG op kosten en eenvoud. Bestaat een substantiële groep uit synthesevragen (“wat zijn de risico's over al onze leverancierscontracten”, “vat alles samen wat we weten over klant Y”), dan verdient de multi-hop-structuur van GraphRAG zichzelf terug.
- Structuur van uw corpus: contracten, complianceregisters, incidentrapporten en technische documentatie zitten vol entiteiten en onderlinge relaties — personen, bedrijven, clausules en verplichtingen die naar elkaar verwijzen. Een platte FAQ-kennisbank of productcatalogus meestal niet; een graaf voegt dan indexeringsoverhead toe zonder retrieval-winst.
- Wijzigingssnelheid: LazyGraphRAG en LightRAG verkleinen dit verschil deels, maar de communitysamenvattingen van volledige GraphRAG moeten nog altijd periodiek opnieuw geïndexeerd worden na flinke wijzigingen in het corpus, terwijl de incrementele updates van LightRAG en de embedding per document van vector-RAG dagelijks veranderende content beter verdragen.
Scoort u op alle drie richting graafstructuur, dan verdient een kennisgraaf-laag zichzelf terug. Scoort u richting eenvoudige, snel veranderende, opzoekgerichte data — wat de meeste mkb-kennisbanken beschrijft — dan is hybrid vector-RAG niet alleen goedkoper, maar ook nauwkeuriger voor de vragen die daadwerkelijk gesteld worden.
Een uitgewerkt voorbeeld maakt de afweging concreet. Neem een accountantskantoor met 30 medewerkers en tien jaar aan klantdossiers: opdrachtbevestigingen, correspondentie, risicomemo's en jaarrekeningen, elk met verwijzingen naar klanten, entiteiten, boekjaren en specifieke risicosignalen. Een opzoekvraag — “wat was de deadline in de opdrachtbevestiging van Jansen BV” — wordt perfect beantwoord door hybrid vector-RAG: één document, één passage, in milliseconden. Een synthesevraag — “bij welke klanten waarbij we de afgelopen drie jaar continuïteitsrisico signaleerden, is ook van accountant gewisseld” — vraagt om de graaf, omdat het antwoord vereist dat u relaties tussen klanten, risicosignalen en personeelswisselingen doorloopt die geen los fragment bevat. Bij de meeste kantoren domineert het eerste type de daadwerkelijke vraaglogs; het tweede type komt voor, maar zelden. Die verhouding, meer dan welk architectuurdiagram dan ook, hoort de bouwbeslissing te sturen — en is meetbaar uit een week aan vraaglogs, nog voordat u één regel retrieval-code schrijft.
Waar retrieval past in de agent-stack van 2026
In de agent-architecturen van 2026 worden RAG en GraphRAG zelden rechtstreeks door een taalmodel aangeroepen — ze zitten achter een tool of een MCP-server die de agent aanroept zodra hij onderbouwde feiten nodig heeft, hetzelfde patroon dat we in kaart brachten in MCP vs RAG vs AI-agents vs A2A: de 2026-stack. Dat is relevant voor de bouwbeslissing: als u een vectorstore al als MCP-tool aanbiedt, is overstappen op een GraphRAG-tool een wijziging in de retrieval-laag, geen herontwerp van de agent — de redeneerlus, het geheugen en de orkestratie van de agent blijven hetzelfde. Het betekent ook dat deze beslissing later zonder herbouw herzien kan worden: begin met hybrid vector-RAG achter de tool-interface en wissel de implementatie pas als uw evaluaties later laten zien dat synthesevragen misgaan.
Wat dit betekent voor een Nederlands mkb-bedrijf met een AI-agent
De meeste Nederlandse mkb-bedrijven die retrieval overwegen voor een klantenservice- of interne kennis-agent hebben in 2026 geen GraphRAG nodig, en leveranciers die een kennisgraaf als standaardupgrade verkopen, lossen meestal een probleem op dat de koper niet heeft. Waar de rekensom omslaat: een accountantskantoor dat een agent bouwt over jaren aan klantdossiers en correspondentie, waar “vat alle risicosignalen samen die we sinds 2022 bij deze klant hebben afgegeven” een reële, terugkerende vraag is; het complianceregister van een installatiebedrijf dat AI Act-verplichtingen koppelt aan specifieke systemen en leveranciers; of een groothandel die leverancierscontracten afstemt op wijzigende ERP-gegevens, waar de entiteiten — leverancier, contract, artikel, voorwaarde — daadwerkelijk naar elkaar verwijzen. Dat laatste geval sluit direct aan op de integratiepatronen die we behandelen in Zo koppelt u AI aan Exact Online, AFAS en e-Boekhouden — de retrieval-laag komt dan bovenop precies het soort onderling verbonden, ERP-nabije data waar GraphRAG voor gebouwd is. Voor een eenvoudige WhatsApp- of e-mail-serviceagent die “wat zijn uw openingstijden” en “waar blijft mijn bestelling” beantwoordt, blijft hybrid vector-RAG met een degelijke reranker de juiste, saaie, goedkope standaardkeuze — en saai is een voordeel als een team van 20–50 fte het moet onderhouden.
Zo test u het voordat u kiest
Beslis dit niet op papier. Verzamel 20–30 echte vragen die uw gebruikers daadwerkelijk stellen (of zouden stellen), draai die door een hybrid-plus-reranker-basislijn en beoordeel faithfulness en context recall met RAGAS. Draai vervolgens de synthesevragen — de “vat alles samen”-vragen — door een LazyGraphRAG- of LightRAG-pilot op hetzelfde corpus; beide indexeren nu tegen ongeveer vector-RAG-kosten, dus de pilot zelf is goedkoop. Verslaat de graaf-pilot de hybrid-basislijn niet aantoonbaar op de vragen waar hij voor bedoeld is, dan weegt de extra architectuur en onderhoudslast niet op tegen de winst. Dit sluit aan bij de les over duurzame uitvoering uit ons artikel over AI-agents in productie: bouw het eenvoudigste dat uw evaluatienorm haalt, en voeg complexiteit alleen toe waar de evaluaties aantonen dat het nodig is.
Waar begint u?
Specificeert u dit kwartaal de retrieval voor een AI-agent, begin dan met hybrid vector-RAG en RAGAS-evaluaties als standaard, en behandel GraphRAG als een upgrade die u test — niet als iets dat u aanneemt. Lees hoe wij agent- en retrieval-architectuur voor Nederlandse mkb-bedrijven scopen op onze pagina over AI-agent-ontwikkeling, en hoe wij agents van pilot naar duurzame productie brengen op onze pagina over productie-AI.
Veelgestelde vragen
Is GraphRAG in 2026 nog te duur voor een klein bedrijf?
Nee. LazyGraphRAG en LightRAG indexeren een corpus nu voor ongeveer dezelfde kosten als gewone vector-RAG, tegenover de circa €33.000 die vroege GraphRAG-projecten onhaalbaar maakte. Kosten zijn niet langer de belemmering; of uw vraagpatroon en datastructuur echt graph-retrieval nodig hebben, is de echte vraag.
Heeft elke AI-agent GraphRAG nodig?
Nee. De meeste mkb-toepassingen — klantenservice-agents, FAQ-bots, orderstatus opzoeken — worden beter en goedkoper beantwoord met hybrid vector-RAG (BM25 plus dense search). GraphRAG verdient zijn kosten terug bij vragen die synthese over veel onderling verbonden documenten vragen, niet bij losse feiten.
Wat is het verschil tussen local en global search in RAG?
Local search haalt de specifieke passages op die het meest lijken op een vraag — sterk bij “wie, wat, wanneer”-vragen. Global search vat de structuur van een heel corpus samen — sterk bij “wat zijn de belangrijkste thema's of risico's”-vragen. Vector-RAG doet local search goed; GraphRAG voegt global search toe.
Kan ik later GraphRAG toevoegen zonder mijn AI-agent te herbouwen?
Ja, als retrieval achter een tool-interface zit (bijvoorbeeld een MCP-server) in plaats van hard-coded in de redeneerlus van de agent. De retrieval-implementatie wisselen verandert dan één onderdeel, niet de hele architectuur.
Hoe test ik of GraphRAG echt iets oplevert?
Draai dezelfde echte vragen door een hybrid vector-RAG-basislijn en een GraphRAG-pilot, beoordeel beide met RAGAS-metrieken (faithfulness, context precision, context recall), en houd de graaglaag alleen aan als die aantoonbaar beter scoort op de synthese-vragen waarvoor hij bedoeld is.