Herkent u de situatie: uw RAG-systeem retourneert relevante fragmenten, maar het antwoord klopt nog steeds niet? U vraagt wie contract nr. 2024-0034 heeft goedgekeurd, het systeem vindt een document over goedkeuringsprocessen én een document met het contractnummer — maar legt de link niet dat de goedkeurder een specifieke persoon is die in een derde document wordt genoemd. Elke stap heeft ergens een antwoord. Het probleem zit niet in het zoeken, maar in de ontbrekende relaties.
Precies voor dit type vragen is GraphRAG ontwikkeld — een uitbreiding van klassieke retrieval-augmented generation met een kennisgraaf (knowledge graph). Het is geen drop-in upgrade die u simpelweg inschakelt. Het is een architectuurkeuze met reële kosten en tastbare voordelen — maar alleen voor een bepaalde klasse problemen. In dit artikel bekijken we wat GraphRAG oplost, hoe het technisch werkt, wat de werkelijke kosten zijn en voor welke gevallen het daadwerkelijk de moeite waard is.
Wat klassieke RAG niet kan
Een standaard RAG-pipeline werkt goed wanneer het antwoord op een vraag in één of twee nabijgelegen tekstfragmenten staat. U neemt de vraag, converteert die naar een embedding, zoekt de k-dichtstbijzijnde chunks in de vectordatabase, geeft die aan het model en krijgt een antwoord.
Deze aanpak heeft een blinde vlek: relaties tussen entiteiten over documenten heen. Klassieke RAG heeft er geen weet van dat de persoon in document A dezelfde is als in document C, dat de gebeurtenis in het ene rapport de oorzaak is van het probleem dat in een ander rapport wordt geanalyseerd, of dat de leverancier op de factuur eigendomsmatig verbonden is met het bedrijf in de klacht. Vectorgelijkenis matcht tekst, geen semantische verbanden.
Precies hier komt GraphRAG in beeld. In plaats van geïsoleerde fragmenten werkt het met een graaf — knooppunten (entiteiten: personen, bedrijven, producten, processen, locaties) en kanten (relaties: heeft goedgekeurd, levert, verantwoordelijk voor, heeft veroorzaakt, behoort tot). Retrieval is dan niet meer alleen "vind vergelijkbare tekst", maar "vind een pad of deelgraaf die relevant is voor deze vraag".
Hoe GraphRAG technisch werkt
De originele implementatie van Microsoft, die deze term heeft gepopulariseerd, bestaat uit twee fasen: indexering en bevraging.
Indexeringsfase
Dit is de duurste stap. Voor elk document in het corpus wordt een LLM (of een reeks LLM-aanroepen) ingezet die entiteiten en relaties extraheert. Uit zinnen als *"Ingenieur Novák heeft de vervanging van pomp P-12 op lijn 3 op 14 januari goedgekeurd"* worden knooppunten Novák (persoon), P-12 (apparaat), Lijn 3 (locatie) en kanten heeft goedgekeurd → vervanging, bevindt zich op → Lijn 3 geëxtraheerd.
Op de aldus opgebouwde graaf wordt vervolgens communitydectie toegepast (algoritmen als Leiden of Louvain), die gerelateerde entiteiten groepeert in communities — bijvoorbeeld alle entiteiten die betrekking hebben op lijn 3, of alle transacties met een specifieke leverancier. Voor elke community wordt een samenvattende beschrijving gegenereerd (het zogenaamde community report), dat dient als high-level context bij het beantwoorden van globale vragen.
Bevragingsfase
Bij binnenkomst van een vraag wordt gekozen tussen twee strategieën:
Local search — de vraag betreft specifieke entiteiten of lokale relaties. Het systeem vindt relevante knooppunten en doorloopt de deelgraaf in hun omgeving. Geschikt voor vragen als "wie heeft deze bestelling goedgekeurd?" of "welke apparaten zijn gekoppeld aan deze storing?".
Global search — de vraag vereist het synthetiseren van informatie over het gehele corpus. Het systeem werkt met community reports in plaats van ruwe documenten. Geschikt voor vragen als "wat zijn de voornaamste storingspatronen op de lijnen van het afgelopen jaar?" of "identificeer leveranciers met herhaaldelijk te late levering".
Ten opzichte van klassieke RAG voegt GraphRAG dus een volledige laag semantische structuur toe — maar deze laag is niet gratis.
De werkelijke kosten van indexering
Hier worden veel geïnteresseerden in GraphRAG door de realiteit verrast. Microsoft rapporteerde in zijn onderzoek dat de indexering van grote datasets met de oorspronkelijke implementatie in de orde van tienduizenden USD kostte — afhankelijk van de omvang van het corpus en het gekozen model. De reden: elk document (of elke chunk) vereist een LLM-aanroep voor entiteitsextractie. Bij honderdduizenden documenten loopt het aantal tokens snel op tot astronomische getallen.
Dit heeft een concrete consequentie: indexering is niet eenmalig. Wanneer een document wijzigt of er een nieuw document bijkomt, moet de graaf worden bijgewerkt. Anders dan bij een vectordatabase, waar het volstaat om nieuwe chunks opnieuw te embedden, kan een graafupdate vereisen dat de omgeving van het gewijzigde knooppunt opnieuw wordt doorlopen.
Dit is de fundamentele reden waarom GraphRAG niet geschikt is voor dynamische corpora met een hoge updatefrequentie.
LazyGraphRAG en open-source alternatieven
Microsoft was zich bewust van het kostenvraagstuk en bracht LazyGraphRAG uit — een variant die de LLM-extractie van entiteiten en relaties uitstelt. In plaats van entiteiten voor elk document tijdens indexering te extraheren, bouwt het een basisgraaf met goedkopere methoden (NLP-extractie, keyword-extractie) en voert LLM-aanroepen pas uit tijdens bevraging, alleen voor de relevante deelverzameling. Het resultaat: aanzienlijk lagere indexeringskosten bij vergelijkbare antwoordkwaliteit voor veel soorten vragen.
De community heeft inmiddels meerdere alternatieve implementaties gecreëerd met verschillende afwegingen:
- LightRAG — nadruk op efficiëntie, minder LLM-aanroepen bij indexering, goede resultaten op technische documenten
- HippoRAG — geïnspireerd op hippocampaal geheugen, interessant voor long-term knowledge retention
- Fast-GraphRAG — gericht op snelheid met behoud van de graafstructuur
Geen van deze alternatieven is een allesomvattende winnaar — elk maakt andere afwegingen tussen indexeringskosten, graafkwaliteit en bevragingssnelheid. Voor productiedeployment raden we aan het specifieke alternatief te testen op uw eigen corpus in plaats van op benchmarkdatasets.
Wanneer GraphRAG de moeite waard is
Dit is de cruciale vraag die u zichzelf moet stellen vóór elke adoptebeslissing.
GraphRAG heeft een reëel voordeel bij:
- Multi-hop vragen — het antwoord vereist het koppelen van informatie uit drie of meer documenten langs een keten van relaties. "Welke technoloog is verantwoordelijk voor het apparaat dat de storing op de lijn met de hoogste OEE heeft veroorzaakt?" — drie entiteiten, twee kanten, drie documenten.
- Impact-analyse — "welke processen worden beïnvloed als we leverancier X vervangen?" — vereist het doorlopen van de afhankelijkheidsgraaf.
- Samenvatting over entiteiten — "geef een overzicht van alle incidenten gerelateerd aan product Y van de afgelopen twee jaar" — communities in de graaf presteren hier beter dan chunks uit een vectordatabase.
- Patroondetectie — "identificeer terugkerende patronen in klachten per leverancier en apparaatcategorie" — global search via community reports.
- Compliance en audit trails — "toon de goedkeuringsketen voor contract Z" — een directe taak voor graaftraversal.
U heeft GraphRAG waarschijnlijk niet nodig als:
- Uw vragen overwegend feitelijk zijn en het antwoord in één fragment staat ("wat is de maximale temperatuur voor pomp P-12?").
- Uw corpus dagelijks of meerdere keren per dag wijzigt — de kosten van re-indexering zullen prohibitief zijn.
- U minder dan enkele duizenden documenten heeft — klassieke hybrid search met reranking handelt de meeste gevallen af voor een fractie van de kosten en complexiteit.
- U geen duidelijk gedefinieerde ontologie van entiteiten en relaties heeft — een graaf die zonder domeincontext uit ongestructureerde tekst is geëxtraheerd, zal veel ruis bevatten.
Het door Microsoft gerapporteerde getal — GraphRAG bereikt circa 80% correcte antwoorden op multi-hop vragen versus circa 50% voor naïeve RAG — is indicatief en geldt voor een specifiek type synthetische benchmarkvragen. De werkelijke verbetering op uw corpus kan anders zijn. Meet altijd op uw eigen data.
Integratie met een bestaande RAG-stack
GraphRAG is geen vervanging van een vectordatabase — het is een aanvulling. Moderne productiesystemen die het adopteren, draaien doorgaans een hybride architectuur:
- 1.Vectordatabase (bijv.
Qdrant) voor dense retrieval — snel, goedkoop, geschikt voor feitelijke vragen. - 2.Graaflaag (neo4j, Amazon Neptune, of een in-memory graaf voor kleinere corpora) voor relatiegerichte bevragingen.
- 3.Router/orchestrator — classificeert de binnenkomende vraag en bepaalt welke laag te gebruiken (of beide te combineren).
De orkestratie van zo'n systeem is complexer. LangGraph (framework voor stateful agent-grafen) is voor dit patroon een natuurlijke keuze — het maakt het mogelijk om beslissingsknooppunten te definiëren die dynamisch bepalen of een bevraging via de vectordatabase, de graaflaag of beide verloopt. Voor het evalueren van resultaten loont het de moeite naar RAGAS-metrics te kijken — zie hoe RAG evalueren.
Belangrijke noot over tooling: LlamaIndex heeft in huidige versies native ondersteuning voor GraphRAG-indexering, wat de implementatiedrempel aanzienlijk verlaagt ten opzichte van het handmatig opzetten van de pipeline.
Waar wij GraphRAG zien in de industriële praktijk
Op basis van deployments die we bij klanten in de maak- en ingenieurssector uitvoeren, blijken GraphRAG of hybride graafbenaderingen gerechtvaardigd in de volgende scenario's:
Beheer van technische documentatie — grote bedrijven met duizenden technische handleidingen, SOP's, servicerapporten en revisieprotocollen. De vraag "wat is de procedure bij een storing van een pomp type X in ATEX-zone II?" vereist het koppelen van de apparaathandleiding, het ATEX-protocol van de zone, de veiligheids-SOP en de servicegeschiedenis. Klassieke RAG biedt hiervoor geen betrouwbare oplossing.
Compliance en regelgevende audit trails — in gereguleerde sectoren (farmacie, energie, voedingsindustrie) moet de verantwoordelijkheids- en goedkeuringsketen aantoonbaar zijn. Een graaf is de natuurlijke datastructuur voor "wie heeft goedgekeurd, wanneer, op basis waarvan, met verwijzing naar welk voorschrift".
Analyse van de toeleveringsketen — verbanden tussen leveranciers, componenten, klachten en storingen. "Hoeveel kritieke componenten zijn afkomstig van leveranciers die het afgelopen jaar meer dan 10 dagen vertraging hadden?" — multi-hop over vier typen entiteiten.
Omgekeerd is GraphRAG onnodige complexiteit voor interne chatbots op FAQ-documentatie of zoeken in een productcatalogus. Zie ook agentic RAG-architecturen, waar de graaflaag op een natuurlijke manier wordt gecombineerd met agent-controlled retrieval.
Praktische aanpak: hoe te beginnen
Als u besloten heeft GraphRAG uit te proberen, raden we een incrementele aanpak aan:
- 1.Definieer de ontologie — bepaal vóór enige implementatie expliciet welke typen entiteiten en relaties u in de graaf wilt. Zonder deze stap krijgt u een ruis-graaf vol irrelevante knooppunten.
- 2.Begin met een klein corpus — 1.000–5.000 documenten zijn voldoende om te verifiëren of de graafstructuur aansluit bij uw vragen. Indexering is beheersbaar, ook met LazyGraphRAG.
- 3.Vergelijk met een baseline — meet voor elk vraagtype (feitelijk, multi-hop, samenvatting) de nauwkeurigheid van GraphRAG versus hybrid search. Als GraphRAG op uw echte vragen geen >15% winst oplevert, overweeg dan of de complexiteit gerechtvaardigd is.
- 4.Plan de updatecyclus — besluit hoe u de graaf actueel houdt. Batch-re-indexering één keer per week? Incrementele update bij het toevoegen van documenten? Deze keuze beïnvloedt de totale architectuur.
- 5.Vergeet de fallback niet — zorg in een productiesysteem altijd voor klassieke vector retrieval als back-up voor gevallen waarin de graafbevraging onvoldoende betrouwbare resultaten oplevert.
Veelgestelde vragen
Is GraphRAG beter dan klassieke RAG?
Dat hangt af van het type vragen. Voor multi-hop vragen waarbij entiteiten over documenten heen gekoppeld moeten worden — ja, aanzienlijk. Voor eenvoudige feitelijke vragen waarvan het antwoord in één fragment staat, is GraphRAG onnodig duur en trager. Meet altijd op uw specifieke use case.
Hoe duur is GraphRAG-indexering in de praktijk?
De originele Microsoft-implementatie rapporteert kosten in de orde van tienduizenden USD voor grote corpora. LazyGraphRAG en open-source alternatieven (LightRAG, Fast-GraphRAG) verlagen deze kosten aanzienlijk. De exacte prijs hangt af van de corpusomvang, de gekozen LLM en de granulariteit van entiteitsextractie.
Heb ik een speciale graafsdatabase nodig?
Niet per se. Voor kleinere grafen (tot de orde van miljoenen knooppunten) volstaat een in-memory representatie of bibliotheken als networkx. Voor grotere productiedeployments zijn Neo4j, Amazon Neptune of TigerGraph gangbare keuzes. Sommige implementaties (bijv. LlamaIndex GraphRAG) abstraheren de opslaglaag en maken de keuze van backend mogelijk.
Werkt GraphRAG voor Nederlandstalige documenten?
Entiteitsextractie hangt af van de kwaliteit van de LLM die dit uitvoert. Frontier-modellen (Claude, GPT, Gemini) verwerken het Nederlands uitstekend. Bij gebruik van kleinere lokale modellen moet de extractiekwaliteit op een steekproef van Nederlandstalige tekst worden geverifieerd vóór deployment. De graafstructuur zelf is taalagnostisch.
Wanneer besluit u GraphRAG niet te gebruiken?
Als uw corpus dagelijks wijzigt, als u minder dan enkele duizenden documenten heeft, als uw vragen overwegend single-hop zijn, of als u niet de capaciteit heeft om een entiteitsontologie te definiëren en te onderhouden. In die gevallen geeft klassieke hybrid search met reranking u 90% van het resultaat voor 10% van de kosten en complexiteit.
*GraphRAG is niet voor elk project geschikt — maar voor projecten waarbij relaties tussen entiteiten bepalend zijn voor de correctheid van het antwoord, is het een instrument zonder alternatief. Bij MP Industrial Solutions helpen we bedrijven beoordelen of hun specifieke use case een GraphRAG-kandidaat is, de ontologie te ontwerpen en de werkelijke indexeringskosten in te schatten — nog vóór enige verplichting. Als u complexe documentatie- of compliance-vraagstukken oplost, begin dan met een beoordeling.*