GraphRAG / RAG-architectuur

De kloof tussen "semantisch vergelijkbare chunks" en "correcte, volledige antwoorden" is waar de meeste enterprise RAG-implementaties spaak lopen. Stanford AI Lab ontdekte dat 40% van de RAG-antwoorden hallucineert, zelfs wanneer de juiste documenten worden opgehaald. De retrieval werkte. De grounding niet.

Waarom RAG documenten ophaalt, geen antwoorden

Dit gebeurt doordat standaard vectorovereenkomst geen onderscheid kan maken tussen een passage die thematisch relevant is en een passage die daadwerkelijk de vraag beantwoordt. Wanneer uw complianceteam vraagt "wat zijn de meldingsvereisten voor een datalek dat EU-inwoners onder de 16 treft?" en uw systeem retourneert drie chunks over AVG-datalekmeldingen zonder de leeftijdsspecifieke bepalingen, lijkt het antwoord juist, maar is het gevaarlijk onvolledig.

Onze aanpak is om retrievalsystemen te bouwen die zijn ontworpen om deze kloof te dichten. De architectuur die we kiezen is afhankelijk van uw documenten, uw zoekopdrachten en uw tolerantie voor foutieve antwoorden. Soms is dat hybride BM25 + dense retrieval met een cross-encoder-reranker. Soms is het een volledige GraphRAG-pipeline met entiteitsextractie en community-samenvattingen. Soms is het een agentic retrieval-loop die complexe vragen opsplitst, iteratief informatie ophaalt en zichzelf corrigeert alvorens te genereren. We kiezen niet standaard voor de meest complexe optie — we kiezen voor de oplossing die uw retrievalprobleem oplost tegen kosten die houdbaar zijn.

Drie retrieval-architecturen, gekozen op basis van uw querypatronen

Wij stemmen de architectuur af op uw querypatronen in plaats van standaard voor complexiteit te kiezen. De drie onderstaande patronen dekken de meeste productiebehoeften.

Hybride retrieval met reranking

Dit is waar de meeste productiewaardige RAG-systemen zouden moeten beginnen. BM25 verzorgt de exacte trefwoordherkenning (foutcodes, product-SKU's, nummers van regelgevende citaten), terwijl dense embeddings de semantische intentie vastleggen. Reciprocal rank fusion (RRF, k=60) voegt de twee resultatensets samen zonder de problemen met scorenormalisatie die aangeleerde fusiebenaderingen parten spelen.

Bovenop draait een cross-encoder-reranker: BGE-reranker-v2-m3 op een GPU levert 50–100 ms latentie zonder doorlopende API-kosten, of Cohere Rerank voor teams die een beheerde infrastructuur wensen. Productiebenchmarks tonen aan dat deze tweetrapspipeline beter presteert dan alle enkeltrapsmethoden. Anthropic's contextuele retrieval wordt hier als techniek bovenop geplaatst, wat retrievalfouten met 49% (67% met reranking) vermindert door context op documentniveau vooraf aan elke chunk toe te voegen vóór het embedden.

Graaf-verrijkte retrieval (GraphRAG)

Wanneer uw vragen het synthetiseren van informatie uit meerdere documenten vereisen of het redeneren over relaties tussen entiteiten, volstaat vectorovereenkomst alleen niet. Een juridisch team dat vraagt "welke dochterondernemingen van AcquiringCo hebben lopende toezichtsmaatregelen in jurisdicties waarin TargetCo actief is?" heeft entiteitsresolutie, traversering van relaties en multi-hop redeneren nodig.

Wij bouwen kennisgrafen uit uw documenten met behulp van dependency-gebaseerde extractie die 94% van de prestaties op basis van LLM's behaalt tegen een fractie van de tokenkosten (nader toegelicht in ons onderzoek naar GraphRAG met afgedwongen citaten). Microsoft's GraphRAG -benadering (Leiden-clustering + community-samenvattingen) werkt voor betekenisgevingsquery's op corpusniveau, maar de indexeringskosten zijn 4–8x zo hoog als bij standaard RAG. We zetten dit selectief in:

• Community-samenvattingen voor globale query's.
• Traversering van property graphs voor entiteit-relatievragen.
• Standaard vector-retrieval voor al het overige.

Voor de onderliggende graafopslag, FalkorDB verwerkt leesintensieve RAG-workloads met 6.693 QPS en submilliseconde cold starts, terwijl Neo4j de juiste keuze blijft wanneer u volwassen RBAC, clustering en complexe aggregatie nodig heeft.

Agentic retrieval

Het krachtigste patroon in 2026, en het meest kostbaar om goed te implementeren. Een agentic retrieval-loop ontleedt complexe query's in subquery's, routeert deze elk naar de geschikte retrievalstrategie (vector, graaf of gestructureerde database), evalueert of de resultaten toereikend zijn en itereert totdat betrouwbaarheidsdrempels zijn bereikt.

Wij implementeren dit op LangGraph, waar de state-machine-abstractie u voorziet van voorwaardelijke vertakkingen, human-in-the-loop interrupt-nodes en deterministische auditeerbaarheid. Corrective RAG-lagen voegen 100–800 ms latentie per query toe, maar vangen retrievalfouten af voordat ze het LLM bereiken. Dit patroon is productierijp bij Morgan Stanley, PwC en ServiceNow. Het is niet geschikt voor teams zonder toegewijde ML-ops-capaciteit om de retrieval-loops te monitoren en af te stemmen.

Wat er gebeurt vóór het embedden: chunking goed aanpakken

Chunking is waar RAG-systemen geruisloos falen. Naïeve chunking met vaste afmetingen levert faithfulness-scores op van 0,47–0,51. Semantische chunking bereikt 0,79–0,82, maar vereist het embedden van elke zin in uw corpus. De juiste strategie hangt af van uw documenten:

• Gestructureerde wettelijke deponeringen — lay-outbewuste parsing behoudt de sectiehiërarchie.
• PDF's met gemengde inhoud met tabellen en grafieken — vision-gestuurde chunking (waarbij elke pagina als een afbeelding wordt behandeld voor lay-outdetectie, waarna tekstgebieden worden geëxtraheerd) verbetert de retrievalprecisie met 8–15% ten opzichte van parsing op basis van alleen tekst.
• Lange narratieve documenten — late chunking leidt eerst het volledige document door de transformer zodat elke token-embedding bidirectionele context weerspiegelt, en past vervolgens na de forward pass chunk-grenzen toe.

Wij testen drie tot vier chunkingstrategieën op uw daadwerkelijke set zoekopdrachten voordat we er een kiezen. Het evaluatiekader (RAGAS-faithfulness + contextprecisiemetrieken, domeinspecifieke relevantiebeoordelingen) wordt meegeleverd als onderdeel van de pipeline, niet als bijzaak. 60% van de nieuwe RAG-implementaties omvat nu vanaf dag één systematische evaluatie, vergeleken met minder dan 30% begin 2025. Wij integreren de evaluatie in uw CI/CD, zodat retrievalkwaliteit bij elke deployment wordt gemeten en niet pas aan het licht komt wanneer gebruikers klagen.

Wat kost het draaien van een enterprise RAG-systeem?

Een productiebedrijf besteedde $ 400.000 aan het implementeren van een RAG-systeem, en ontdekte vervolgens dat de doorlopende operationele kosten uitkwamen op $ 18.000/maand — meer dan het dubbele van hun prognose. Het kostenmodel dat ze over het hoofd zagen: reranking. Embedding-API's kosten $ 20–120 per miljard tokens. Vector-DB-hosting bij 10M vectoren kost 1,5–3x meer bij beheerde diensten (Pinecone, Weaviate Cloud) vergeleken met self-hosted (Qdrant, pgvector). Maar reranking bij productiequeryvolumes is waar budgetten exploderen: Cohere Rerank kost $ 2 per 1.000 query's, terwijl een self-hosted BGE-reranker-v2-m3 op een enkele GPU die latentie evenaart tegen nul kosten per query — al betaalt u wel voor de GPU-instantie.

GraphRAG voegt een extra kostenlaag toe. De opbouw van een kennisgraaf verbruikt 4–8x meer tokens dan de brontekst voor entiteitsextractie en community-samenvattingen. Onderhoud verbruikt 40–60% van het engineeringbudget in het eerste jaar doordat entiteitsresolutie, deduplicatie en ontologie-updates continu werk zijn, geen eenmalige configuratie. Dependency-gebaseerde extractie (klassieke NLP in plaats van LLM-aanroepen) verlaagt de constructiekosten met circa 90% met behoud van 94% van de extractiekwaliteit. Wij bakenen elk traject af met expliciete maandelijkse run-rate-prognoses voor embedding, opslag, retrieval, reranking en graafonderhoud.

Wanneer GraphRAG de moeite waard is (en wanneer niet)

U heeft graaf-verrijkte retrieval nodig wanneer uw zoekopdrachten multi-hop redeneren over entiteiten en relaties vereisen:

• M&A-due-diligence die honderden deponeringen van dochterondernemingen omvat.
• Synthese van klinisch bewijs over interactiedatabanken van geneesmiddelen heen.
• Toeleveringsketenrisico-analyse die leveranciersnetwerken koppelt aan regelgevende maatregelen.

GraphRAG levert in benchmarks zijn hoogste zoekprecisie bij complexe, meerlaagse bedrijfsvragen (zie een werkende demo van juridische retrieval met geverifieerde citaten). U heeft het niet nodig wanneer uw query's bestaan uit opzoekingen in afzonderlijke documenten, FAQ-achtige antwoorden of trefwoordgestuurde zoekopdrachten — hybride BM25 + dense retrieval met een reranker verwerkt deze tegen een fractie van de kosten en complexiteit. Als uw corpus minder telt dan 5 miljoen vectoren en uw vragen de documentgrenzen niet overschrijden, is pgvector met HNSW-indexering oprecht toereikend. We beoordelen dit voordat we een architectuur aanbevelen, en we vertellen het u eerlijk wanneer de eenvoudigere optie de juiste is.

De vraag "hebben we überhaupt wel RAG nodig?" is eveneens relevant. Nu contextvensters 1M+ tokens bereiken (Gemini 3 Pro op 10M), overwegen sommige teams om volledige corpora in de prompt te proppen. Het probleem: een enkele query van 1M tokens kost $ 2–10, wat onhoudbaar is bij queryvolumes op ondernemingsniveau. De contextkwaliteit verslechtert voorbij bepaalde drempels, zelfs binnen de geadverteerde limieten. RAG blijft de juiste architectuur voor elk systeem dat herhaalde query's verwerkt op grote, veranderende documentverzamelingen.

Wat is het aanvalsoppervlak van een RAG-pipeline?

Onderzoek naar PoisonedRAG (USENIX Security 2025) toonde aan dat vijf zorgvuldig gemanipuleerde documenten, geïnjecteerd in een corpus van een miljoen documenten, AI-antwoorden met meer dan 90% succes kunnen manipuleren. Uw retrieval-pipeline is een innamekanaal voor kwaadwillige content. OWASP erkent inmiddels formeel vector- en embedding-kwetsbaarheden (LLM08:2025) en promptinjectie via opgehaalde documenten (LLM01:2025) als voorname LLM-beveiligingsrisico's.

Wij bouwen het traceren van documentherkomst, anomaliedetectie op embedding-niveau en lagen voor invoersanering in de retrieval-pipeline in. Elke opgehaalde passage bevat bronmetadata en vertrouwensscores. De generatielaag is verplicht specifieke passages te citeren, en beweringen die niet kunnen worden verankerd in opgehaalde content worden gemarkeerd in plaats van doorgelaten. Dit is geen optionele functionaliteit voor RAG-systemen die in gereguleerde omgevingen draaien, zoals nader beschreven in ons onderzoek naar het beveiligen van private enterprise LLM's.

Wat wij opleveren

Elk traject levert op:

• Een retrieval-architectuur gekozen voor uw specifieke querypatronen en documenttypen.
• Een chunking- en embeddingstrategie die gebenchmarkt is tegen uw daadwerkelijke zoekopdrachten.
• Een evaluatiekader van productiekwaliteit met RAGAS-metrieken en domeinspecifieke testcases.
• Expliciete kostenprognoses voor embedding, opslag, retrieval, reranking en eventueel graafonderhoud.
• Beveiligingsharding tegen op retrieval gebaseerde aanvallen.
• Een monitoringstack die kwaliteitsverlies bij retrieval opmerkt voordat gebruikers dat doen.

We vertellen het u ook wanneer uw huidige configuratie toereikend is en de investering in complexere retrieval zich niet zal terugbetalen.