RAG-architectuur: 5 patronen voor enterprise AI

Wat is RAG (Retrieval-Augmented Generation)?

RAG (Retrieval-Augmented Generation) is een AI-architectuur waarbij een taalmodel tijdens het beantwoorden van een vraag relevante informatie uit externe databronnen ophaalt en als context gebruikt voor het genereren van een antwoord.

Een taalmodel heeft uit zichzelf geen toegang tot interne documenten of actuele bedrijfscijfers. Zonder aanvullende context genereert het antwoorden op basis van zijn trainingsdata, met hallucinatie als risico.

Een eenvoudige RAG-pipeline bestaat uit drie stappen:

• Retrieval – de query wordt omgezet naar een embedding-vector. Een similarity search haalt vervolgens de top-k dichtstbijzijnde chunks op uit een vector-index.
• Augmentation – de opgehaalde chunks worden samen met de originele query en systeeminstructies samengevoegd tot één prompt.
• Generation – het LLM genereert een antwoord op basis van de samengestelde context, eventueel met een verwijzing naar de chunks waarop het antwoord is gebaseerd.

Dat is de kern. De complexiteit van een production-ready RAG-architectuur zit vooral in alles eromheen: hoe je de index bouwt en synchroon houdt, hoe retrieval wordt getriggerd, waar sessiestatus leeft en hoe je embeddings versioned wanneer je van model wisselt.

RAG-architectuur versus een traditioneel dataplatform

Een traditioneel dataplatform is geoptimaliseerd voor aggregatie: geef me bijvoorbeeld de som van alle sales, gebruikmakend van batch-ETL en een lakehouse of warehouse als bron van waarheid.

GenAI-workloads optimaliseren voor iets anders. Daar wil je specifieke, relevante informatie snel terugvinden, met semantische in plaats van alleen SQL-gebaseerde toegang en met een lage latency.

Dat vraagt niet om vervanging van je warehouse. Het vraagt om een aanvullende laag ernaast: de AI execution plane.

Beide lagen kunnen dezelfde onderliggende data gebruiken, maar benaderen die anders. Vector-indexen komen naast tabellen te staan, semantic search naast SQL-queries. De bestaande data-infrastructuur blijft daarmee de fundering, terwijl de AI execution plane data op een andere manier beschikbaar maakt voor LLM’s en AI-applicaties.

5 RAG-architectuurpatronen voor enterprise AI

RAG is geen eenheidsworst. Afhankelijk van hoe snel een antwoord beschikbaar moet zijn, of een gesprek geheugen nodig heeft en of het systeem zelfstandig acties moet uitvoeren, kom je uit bij verschillende architectuurpatronen.

De vijf patronen bouwen deels op elkaar voort. Onder de realtime patronen ligt dezelf

Welk RAG-patroon heb je nodig?

De keuze voor een RAG-architectuur wordt vooral bepaald door de benodigde snelheid, state en autonomie.

RAG-patroon	Realtime	Geheugen	Toolgebruik	Typische toepassing
Ephemeral RAG	Nee	Nee	Nee	Batchverrijking
Persistent Index Building	n.v.t.	Nee	Nee	Actuele vector-index
Online RAG	Ja	Nee	Nee	Enterprise search
Conversational RAG	Ja	Ja	Nee	Chatbots en assistants
Agentic RAG	Ja	Ja	Ja	Agentic workflows

Online RAG past bij losse realtime vragen. Conversational RAG is logischer wanneer gesprekshistorie onderdeel is van de usecase. Agentic RAG wordt relevant wanneer het systeem zelfstandig meerdere bronnen of tools moet kunnen raadplegen.

Voor ieder realtime patroon – Online, Conversational en Agentic RAG – geldt Persistent Index Building als fundering. Zonder een actuele, doorzoekbare index is er immers niets om betrouwbaar op te bevragen.

Het meest geavanceerde patroon is daarbij niet automatisch het beste. De juiste architectuur is de eenvoudigste architectuur die de benodigde capability betrouwbaar kan leveren.

Embedding-versionering binnen een RAG-architectuur

Vroeg of laat loop je hier tegenaan: je hebt tienduizenden documenten geïndexeerd met een bepaald embedding-model en een half jaar later is er een model dat merkbaar beter presteert.

De verleiding is om gewoon over te schakelen. Het probleem is dat oude en nieuwe embeddings niet automatisch in dezelfde vectorruimte liggen. Daardoor kan de retrieval-kwaliteit ongemerkt inconsistent worden.

Een robuuste oplossing is een blue/green deployment. Je bouwt een volledig nieuwe index met het nieuwe embedding-model, test deze parallel en schakelt pas over wanneer de nieuwe index minstens zo goed presteert. De oude index blijft tijdelijk beschikbaar voor een rollback.

Is dat te kostbaar, dan kun je geleidelijk migreren: documenten batchgewijs opnieuw embedden en tijdelijk beide indexen bevragen.

Een derde mogelijkheid is de technical debt bewust accepteren: het oude model blijven gebruiken voor bestaande data en het nieuwe model alleen voor nieuwe content. Dat is een compromis, maar soms wel een bewuste architectuurkeuze.

Wat in alle gevallen helpt: tag embeddings vanaf dag één met de naam en versie van het embedding-model. Die ene regel metadata maakt een toekomstige migratie aanzienlijk beter beheersbaar.

RAG monitoring: wat moet je loggen?

Voor debugging en evaluatie is het niet genoeg om te weten dát een RAG-systeem een antwoord heeft gegeven. Je wilt kunnen reconstrueren waaróm het dat antwoord gaf.

Leg daarom per request minimaal vast:

• de query, gebruiker en sessie;
• welke documenten of chunks retrieval teruggaf;
• welke uiteindelijke prompt naar het model ging;
• welk antwoord het model genereerde;
• de latency van embedding, search en generation;
• het tokengebruik en de kosten.

Voor agentic systemen komt daar de volledige trace bovenop: welke tools zijn aangeroepen, in welke volgorde en met welke resultaten.

Zonder zo’n trace is een falende agent moeilijk te debuggen. Tools als LangSmith en MLflow Tracing zijn ontworpen om deze beslisboom inzichtelijk te maken.

RAG-monitoring speelt daarmee op drie niveaus tegelijk:

• Systeemkwaliteit: uptime, latency en errors.
• AI-kwaliteit: haalt retrieval relevante informatie op en levert het model bruikbare, onderbouwde antwoorden?
• Kosten: wat kost een query per gebruiker, sessie en usecase?

Alle drie zijn nodig om te bepalen of een RAG-systeem niet alleen technisch werkt, maar ook betrouwbaar en efficiënt in productie draait.

Guardrails voor agentic RAG

Agentic RAG vraagt om explicietere grenzen dan een traditionele RAG-pipeline. Het model bepaalt immers zelf welke tools het gebruikt en hoeveel tussenstappen het uitvoert.

Zonder grenzen kan een sessie te lang blijven doorredeneren, kunnen kosten oplopen of kan een agent systemen benaderen die buiten zijn taak vallen.

In een productieomgeving betekent dit dat je onder andere moet nadenken over:

• een maximum aantal LLM-calls per sessie;
• een harde timeout;
• menselijke goedkeuring bij gevoelige acties;
• tool-toegang per agent;
• output-validatie voordat een resultaat de gebruiker bereikt.

Zodra een agent niet alleen tekst genereert, maar ook echte acties kan uitvoeren, worden deze guardrails onderdeel van de architectuur.

Security en governance binnen enterprise RAG

Toegangscontrole hoort bij retrieval plaats te vinden, niet pas als filter achteraf.

Als een gebruiker geen rechten heeft op een document, moet dat document buiten de opgehaalde context blijven. Een model zou de informatie dan überhaupt niet moeten ontvangen.

Daarmee wordt governance ook een architectuurvraag. Wie is bijvoorbeeld eigenaar van de vector store?

Wanneer het dataplatform-team alles beheert, ontstaat centrale governance, maar mogelijk ook een bottleneck voor het AI-team. Wanneer het AI-team zelfstandig infrastructuur beheert, kan het sneller bewegen, maar neemt het risico op datasilo’s en dubbele opslag toe.

Een mogelijke verdeling is daarom:

• het dataplatform-team blijft eigenaar van brondata en catalogus;
• het AI-team bouwt en beheert vector stores die vanuit deze bronnen synchroniseren;
• beide teams gebruiken dezelfde catalogus voor lineage en toegangsbeheer.

Zo blijft de governance centraal georganiseerd, terwijl AI-teams ruimte houden om hun eigen applicaties en retrieval-laag te ontwikkelen.

Van RAG-pilot naar production-ready RAG

Geen van de vijf RAG-patronen is inherent beter.

Agentic RAG is niet het eindpunt waar iedere usecase naartoe moet groeien. En Ephemeral RAG is niet te simpel om serieus te nemen voor batchverrijking.

Ieder patroon ruilt complexiteit in voor een specifieke capability: realtime respons, gespreksgeheugen of toolgebruik. De juiste keuze – en vaak de juiste combinatie van patronen – hangt af van wat de usecase daadwerkelijk vraagt, niet van welk patroon het meest geavanceerd klinkt.

Wat het verschil maakt tussen een RAG-pilot die nooit het lab uitkomt en een RAG-platform dat betrouwbaar in productie draait, is zelden een groter model.

Het verschil zit in de architectuur eromheen: orchestratie, storage-sync, embedding-versionering, monitoring, security en toegangsbeheer moeten aansluiten op de werkelijke vorm van het probleem. Niet pas worden toegevoegd nadat er iets misgaat.

Een RAG-oplossing production-ready maken vraagt daarom niet alleen kennis van LLM’s, maar ook van data-architectuur, orchestratie, security en monitoring. Precies daar komen GenAI en data engineering samen.

Bij Blenddata ontwerpen en bouwen we die infrastructuur als onderdeel van onze GenAI-platformtrajecten.