Kennisgraaf- en GraphRAG-databases voor enterprise-AI

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini)

Status: Categorieën en database-architecturen gecontroleerd op 2026-08-23. Deze analyse valt binnen de pijler Bouwstenen & infrastructuur.

Klassieke vector-retrieval loopt binnen enterprise-omgevingen geregeld tegen structurele grenzen aan zodra vragen context over meerdere entiteiten en relaties vereisen. Waar traditionele zoeksystemen documentfragmenten isoleren op basis van semantische nabijheid, bundelt GraphRAG gestructureerde entiteitenrelaties met ongestructureerde vectoren. Wie het complete landschap van infrastructurele componenten wil overzien, kan het AI-ecosysteem in kaart gebracht bestuderen om te zien waar graafsystemen exact aansluiten op aangrenzende lagen.

In dit dossier analyseren we hoe gespecialiseerde graafdatabases, Property Graph-engines en RDF-triplestores functioneren binnen moderne LLM-pipelines. We kijken naar de mechanismen waarmee entiteiten en relaties worden opgebouwd, welke opslagmodellen operationeel rendabel zijn, en op welke punten GraphRAG-systemen falen wanneer queries meerstaps redeneringen vereisen over dynamische bedrijfsdata.

De fundamenten van GraphRAG versus standaard vector-retrieval

Bij een reguliere semantische zoekopdracht splitst een pipeline bronteksten op in tekstbrokken (chunks), waarna een embeddingmodel deze omzet in vectoren. Dit werkt uitstekend voor directe feitelijke vragen, maar introduceert fundamentele blinde vlekken bij globale overzichtsvragen zoals: Wat zijn de drie grootste knelpunten in onze supply chain volgens alle kwartaalverslagen?

Vectorzoekers halen fragmenten op die tekstueel lijken op de vraag, maar missen het netwerk van onderlinge verbanden. GraphRAG lost dit op door entiteiten (zoals leveranciers, contracten, componenten) en gerichte relaties (zoals levert_aan, is_afhankelijk_van) expliciet te modelleren in een kennisgraaf. Hierdoor kan het ophaalmechanisme via graaftraversals paden bewandelen die over honderden verschillende documenten verspreid liggen.

Om te bepalen wanneer een overstap van pure vectoropslag naar een hybride model noodzakelijk is, helpt het om de vergelijking te maken met conventionele systemen; zie het overzicht waarin we vector-databases vergelijken op prestaties en indexering. Waar een vectordatabase rekent met afstanden in een hoogdimensionale ruimte, traverseert een graafdatabase pointers tussen expliciet gedefinieerde nodes en edges.

Eigenschap	Standaard Vector RAG	GraphRAG (Property Graphs)	Hybride Vector + Graaf
Retrieval-eenheid	Tekstbrok (Chunk)	Subgraaf (Nodes, Edges, Eigenschappen)	Tekstbrok gekoppeld aan Entiteit-node
Globale synthese	Zwak (beperkt door top-k fragmenten)	Sterk via community detection algoritmes	Zeer sterk over meerdere bronnen
Indexeerkosten	Laag (enkele embedding-call per chunk)	Zeer hoog (LLM-extractie van entiteiten)	Gemiddeld tot hoog
Query-latentie	10ms – 50ms	50ms – 300ms (afhankelijk van hop-diepte)	40ms – 200ms
Geschikt voor	Lokale feitenvragen in statische documenten	Relatie-analyses, multi-hop redeneringen	Complexe enterprise documentcollecties

Database-architecturen: Labeled Property Graphs versus RDF-Triplestores

Binnen enterprise-implementaties onderscheiden we twee dominante architecturen voor graafopslag: Labeled Property Graphs (LPG) en Resource Description Framework (RDF) triplestores. Beide benaderingen leggen andere accenten op flexibiliteit, formele semantiek en verwerkingssnelheid.

1. Labeled Property Graphs (LPG)

In een LPG-model bevatten zowel knooppunten (nodes) als verbindingen (edges) willekeurige sleutel-waarde-paren en labels. Dit formaat sluit direct aan bij de manier waarop software-engineers objectmodellen ontwerpen. Voorbeelden van databases in deze categorie zijn Neo4j, Memgraph en AWS Neptune (in LPG-modus). LPG-engines blinken uit in snelle, diepe traversals en ondersteunen querytalen zoals Cypher en openCypher. Ze zijn bijzonder intuïtief wanneer een LLM prompts moet vertalen naar formele graafqueries (Text-to-Cypher).

2. RDF-Triplestores en OWL-Ontologieën

RDF-databases baseren zich op het W3C-standaardmodel van subject-predicaat-object-triples. Bekende systemen zijn Ontotext GraphDB, Stardog en Apache Jena. Waar LPG gericht is op traversalsnelheid, focust RDF op formele logica, inferentieregels en enterprise-ontologieën via SPARQL. In gereguleerde sectoren zoals farmacie, verzekeringen en financiële markten maken RDF-stores het mogelijk om afleidingsregels (reasoning) te draaien: als entiteit A een dochteronderneming is van B, en B valt onder een sanctielijst, leidt de triplestore automatisch af dat A ook gesanctioneerd is, zonder dat dit expliciet in de ruwe tekst hoefde te staan.

// Voorbeeld: Cypher query voor GraphRAG multi-hop retrieval
MATCH (c:Component {status: 'Kritiek'})-[:ONDERDEEL_VAN]->(p:Product)
MATCH (p)<-[:LEVERT_AAN]-(s:Leverancier)
WHERE s.land IN ['DE', 'NL']
RETURN p.naam AS Product, s.naam AS Leverancier, c.type AS FoutType
LIMIT 25;

GraphRAG extractie- en constructiepipelines

Het opbouwen van een betrouwbare kennisgraaf uit ongestructureerde bedrijfsdocumenten is computationeel zwaar. De meest gangbare methode volgt een gestructureerde pipeline:

Eerst worden documenten opgedeeld in homogene tekstsegmenten. Een taalmodel scant vervolgens elk segment met de opdracht om alle entiteiten (personen, organisaties, concepten, producten) en de onderlinge relaties te identificeren. Dit proces resulteert in een verzameling ruwe triples.

Vervolgens vindt entiteitsresolutie (entity disambiguation) plaats. Als in document A de term "ASML N.V." staat en in document B "ASML te Veldhoven", moet het systeem herkennen dat beide naar hetzelfde graafknooppunt verwijzen. Zonder rigoureuze deduplicatie fragmenteert de graaf in duizenden losse eilanden, waardoor traversals vastlopen.

Wie deze orchestratie en extractiestappen in software wil onderbrengen, kan RAG-frameworks en orchestration-tools vergelijken om te zien hoe libraries zoals LlamaIndex, LangChain en gespecialiseerde GraphRAG-pijplijnen deze entiteitsextractie automatiseren.

Toonaangevende graafdatabases voor AI-toepassingen

Verschillende platformen positioneren zich nadrukkelijk op het snijvlak van graafstructuren en taalmodellen. De keuze voor een platform hangt sterk af van de verhouding tussen vectorzoekopdrachten en complexe graafanalyses.

Neo4j

Neo4j is de meest gebruikte Property Graph-database en biedt native ondersteuning voor vectorindexen naast traditionele graafindices. Hierdoor kan één databaseknooppunt zowel tekstembeddings als gerichte relaties bevatten. Met ingebouwde APOC-procedures en native integraties voor gangbare LLM-frameworks is het de facto de standaard voor wie Text-to-Cypher wil combineren met semantische zoekopdrachten. Een belangrijk aandachtspunt is het geheugengebruik: bij grafen met honderden miljoenen edges stijgt de RAM-behoefte aanzienlijk.

Memgraph

Memgraph is een in-memory graafplatform geschreven in C++, gericht op extreem lage latenties en realtime gegevensstromen. Het platform ondersteunt de Cypher-querytaal volledig en leent zich uitstekend voor scenario's waarin de kennisgraaf continu verandert door binnenkomende events (zoals fraudedetectie in transactiestromen of telemetriedata).

Stardog

Stardog combineert een RDF-kennisgraaf met een semantische virtualisatielaag. Het platform stelt organisaties in staat om bestaande SQL-databases, data warehouses en documentopslagen te bevragen via een uniforme semantische laag zonder alle brondata fysiek te dupliceren. Dit is waardevol voor enterprises die al zwaar geïnvesteerd hebben in data lakes en daar een semantisch GraphRAG-model overheen willen leggen.

Ontotext GraphDB

GraphDB is een robuuste RDF-triplestore die zwaar inzet op semantische annotatie en tekstontsluiting. Het beschikt over ingebouwde connectoren naar Elasticsearch en OpenSearch, waardoor grootschalige full-text search naadloos samengaat met formele OWL/RDFS-inferentie. Dit maakt het systeem geliefd bij uitgeverijen, wetgevende instanties en academische instellingen.

Hybride architecturen: Koppeling tussen vector-indices en subgrafen

In geavanceerde enterprise-architecturen kiezen teams zelden voor puur vectorzoeken of een pure graafdatabase. De meest robuuste resultaten ontstaan wanneer beide paradigmata worden samengevoegd in een tweetraps retrieval-patroon.

Wanneer een gebruiker een vraag stelt, voert het systeem eerst een vectorzoekopdracht uit over tekstsegmenten of entiteitsknooppunten. Dit levert de startpunten (seed nodes) in de graaf op. Vanaf deze seed nodes voert de graafengine een traverse uit van 1 tot 3 stappen diep (k-hop expansie) om gerelateerde feiten, attributen en documentcontext te verzamelen.

Deze geëxpandeerde context, bestaande uit zowel originele tekstelementen als gestructureerde relaties, wordt vervolgens samengevoegd in de context-prompt van het generatieve taalmodel. Voor dynamische bedrijfsomgevingen waar documenten continu wijzigen, is het cruciaal om te begrijpen hoe deze indices gesynchroniseerd blijven; zie de analyse over retrieval-strategieën voor dynamische en veranderende databases om te voorkomen dat graafrelaties verouderen ten opzichte van de onderliggende brondata.

# Conceptueel Python-voorbeeld: Hybride Vector-to-Graph Expansie
def hybrid_graph_retrieval(query_text, vector_index, graph_db, max_hops=2):
    # Stap 1: Vind start-nodes via vector-similarity
    seed_nodes = vector_index.similarity_search(query_text, top_k=3)
    
    context_chunks = []
    graph_triples = []
    
    # Stap 2: Expandeer netwerk via graph traversal
    for node in seed_nodes:
        context_chunks.append(node.page_content)
        subgraph = graph_db.traverse_neighbors(
            start_node_id=node.metadata['entity_id'],
            hops=max_hops,
            edge_types=['BEÏNVLOEDT', 'ONDERDEEL_VAN', 'GERELATEERD_AAN']
        )
        graph_triples.extend(subgraph.to_triples())
        
    return {
        "text_context": context_chunks,
        "structured_facts": list(set(graph_triples))
    }

Community Detection en hiërarchische samenvattingen

Een uniek concept binnen GraphRAG (zoals gepionierd door Microsoft Research) is het gebruik van grafische clustering-algoritmes, met name het Leiden-algoritme, om hiërarchische gemeenschappen (communities) binnen de data te identificeren.

In plaats van te wachten op een gebruikersvraag, analyseert de indexeerpijplijn de dichtheid van verbindingen in de graaf. Knooppunten die intensief met elkaar verbonden zijn, worden gegroepeerd in een cluster. Een LLM genereert vervolgens een diepgaande samenvatting van elk cluster op verschillende abstractieniveaus (van fijnmazige sub-communities tot overkoepelende hoofdonderwerpen).

Wanneer een gebruiker een brede samenvattingsvraag stelt, hoeft de retrieval-engine niet door miljoenen losse documenten te zoeken. Het systeem selecteert simpelweg de vooraf gegenereerde community-samenvattingen op het juiste abstractieniveau. Dit verlaagt het aantal benodigde tokens drastisch en voorkomt dat cruciale overkoepelende thema's worden gemist.

Valkuilen, bottleneck-factoren en operationele kosten

Hoewel GraphRAG aanzienlijke voordelen biedt voor antwoordkwaliteit en traceerbaarheid, brengt de implementatie stevige operationele compromissen met zich mee waar organisaties rekening mee moeten houden.

1. Hoge extractiekosten tijdens indexatie

Het extraheren van entiteiten en relaties met behulp van taalmodellen vereist een veelvoud aan LLM-aanroepen ten opzichte van traditionele chunking. Voor een dataset van 50.000 complexe PDF-documenten kunnen de indexeringskosten oplopen tot duizenden euro's aan model-tokens, nog los van de benodigde compute voor entiteitsresolutie.

2. Graafdrift en datakwaliteit

Als brondocumenten tegenstrijdige informatie bevatten (bijvoorbeeld een verouderd beleidsdocument uit 2022 en een update uit 2026), ontstaan er conflicterende edges in de graaf. Zonder strikt versiebeheer, tijdsgebonden annotaties (temporal graphs) of geautomatiseerde opschoonroutines kan de graaf 'vervuild' raken, wat leidt tot inconsistente antwoorden van het LLM.

3. Query-latentie en het 'Supernode'-probleem

In bedrijfsdata ontstaan snel zogenaamde supernodes: knooppunten met tienduizenden inkomende of uitgaande verbindingen (zoals een centrale productcategorie of een algemene afdelingsnaam). Zodra een traversal-algoritme zo'n supernode passeert zonder strikte filtering, explodeert het aantal te evalueren paden. Dit leidt tot onvoorspelbare query-latenties en timeouts in productieomgevingen.

Selectiecriteria voor enterprise-inzet

Bij het kiezen van een graafdatabase voor AI-architecturen spelen specifieke technische en organisatorische vereisten een rol. De onderstaande criteria helpen bij het selectietraject:

Query-mechanismen en LLM-compatibiliteit: Ondersteunt het platform deklaratieve talen zoals Cypher of SPARQL waarvoor open-source en commerciële LLM's direct betrouwbare code kunnen genereren via Text-to-Query prompts?
Hybride indexering: Kan de database vectoren rechtstreeks op nodes en relaties opslaan en doorzoeken, of is een externe vectordatabase noodzakelijk voor de eerste ophaalstap?
Schaalbaarheid en geheugenmodel: Moet de volledige graafstructuur in het RAM-geheugen passen voor aanvaardbare prestaties, of beschikt de engine over efficiënte disk-backed opslagmechanismen voor grafen met miljarden verbindingen?
Ontologie-ondersteuning en datavalidatie: Biedt de software formele validatieschema's (zoals SHACL voor RDF of schema constraints voor LPG) om te voorkomen dat extractiepijplijnen ongeldige relatietypes toevoegen?
Hosting en compliance: Is er een self-hosted variant beschikbaar voor implementatie in een eigen private cloud of on-premise datacenter ter bescherming van bedrijfsgeheimen en naleving van de AVG?

Conclusie

Kennisgraaf- en GraphRAG-databases vormen een essentiële evolutie binnen enterprise-AI-architecturen. Waar pure vectoroplossingen tekortschieten bij complexe, relationele vraagstukken, brengt de combinatie van semantische vectoren en expliciete graafstructuren de nodige diepgang, feitelijke controleerbaarheid en contextuele synthese. Door de aanzienlijke indexeringskosten en operationele complexiteit is een zorgvuldige afweging per use-case vereist: standaard vector-retrieval voor eenvoudige zoekvragen, en GraphRAG voor missiekritieke kennisnetwerken waarin relaties tussen entiteiten het werkelijke inzicht bepalen.