RAG systeem

RAG systeem opzetten: Retrieval Augmented Generation

Een RAG-systeem geeft een taalmodel bij elke vraag toegang tot je eigen documenten zonder hertraining. Daarmee is het de standaard geworden voor bedrijfs-chatbots: antwoorden blijven actueel en zijn met citaten te herleiden tot de bron. Bouwen kost in het MKB 15.000 tot 45.000 euro en een werkende MVP staat er in vier tot acht weken. Deze technische gids behandelt de architectuur, de tools en de uitvoering.

Door Prometheus21 AI-team
9 min leestijd
4-8 weken voor werkende MVP
15-45k euro investering MKB
Actuele kennis zonder hertraining
Traceerbare bronnen per antwoord
Retrieval augmented generation nederlands

Waarom RAG de standaard is geworden voor bedrijfs-AI

Een rag systeem (Retrieval Augmented Generation) combineert de taalvaardigheid van een groot taalmodel met de actuele, specifieke kennis van jouw organisatie. In plaats van een model te trainen op je eigen data (fine-tuning), geef je het model bij elke vraag eerst toegang tot relevante documenten uit je kennisbank. Het model antwoordt dan op basis van die context. Deze architectuur is in enkele jaren de standaard geworden voor bedrijfs-chatbots omdat hij drie grote problemen van vanilla-LLM's oplost: verouderde kennis, hallucinaties, en gebrek aan traceerbaarheid.

Voor het MKB is RAG vooral aantrekkelijk omdat je geen machine-learning-team nodig hebt. Een RAG-systeem bouw je met gevestigde bouwstenen: een embedding-model, een vector database, een LLM-API en een retrieval-laag. Alles commercieel beschikbaar of open-source. De uitdaging zit niet in de techniek maar in de kwaliteit van de brondocumenten en de zorgvuldigheid van de pipeline. Een RAG-chatbot is net zo goed als de kennisbank eronder; vieze data geven vieze antwoorden. Daarom koppelen we RAG altijd aan onze data kwaliteit-aanpak.

Typische MKB-use-cases: interne helpdesk-chatbot op HR- en IT-documenten, klantenservice-bot op productdocumentatie en FAQ's, sales-ondersteuning op offerte-templates en case-studies, medewerker-onboarding op policies en procedures. Elk van deze werkt goed met een RAG-backbone. Grote voordeel: bronnen bijwerken is trivial (nieuw document toevoegen, embedding regenereren, werkt direct), geen hertraining nodig. Voor organisaties met veel veranderende kennis is RAG structureel de betere keuze dan fine-tuning.

Belangrijk: RAG is niet de oplossing voor ieder AI-probleem. Voor taken waar je een specifieke stijl of vast output-formaat nodig hebt (bijvoorbeeld altijd volgens een template schrijven) kan fine-tuning beter werken. RAG excelleert als je actuele feiten en traceerbare antwoorden nodig hebt.

Rag architectuur

Drie componenten van een werkend RAG-systeem

De architectuur lijkt simpel. De kwaliteit zit in de details: chunking-strategie, embedding-keuze en prompt-engineering.

01
Ingest
Documenten chunken en embedden
Documenten worden opgeknipt in chunks van 300-800 tokens. Te klein en context gaat verloren, te groot en retrieval wordt vager. Per chunk wordt een vector berekend met een embedding-model. Deze vectors samen met de originele tekst en metadata gaan in een vector database. Chunking-strategie is een van de belangrijkste knoppen: sectie-gewijs opdelen werkt vaak beter dan pagina-gewijs. Overlap tussen chunks (50-100 tokens) voorkomt dat context op de grens verloren gaat.
300-800 tokens
Overlap 50-100
Sectiegewijs
4stappen
Ingest, retrieve, augment, generate
De standaardpijplijn van elk RAG-systeem.
02
Retrieve
Vector search op vraag
Bij elke vraag wordt een query-vector gegenereerd met hetzelfde embedding-model. Vector search vindt de top 3-10 meest relevante chunks. Optioneel volgt re-ranking door een apart model (Cohere rerank, voyage-rerank) dat de relevantie verfijnt.
Top-k retrieval
Re-ranking
03
Generate
LLM genereert op chunks
De opgehaalde chunks worden samen met de vraag in een prompt-template aan het LLM gegeven. Het model antwoordt uit de context. Prompt-engineering bepaalt hoe strict het model bij de bron blijft.
GPT-4/Claude/Gemini
Citaten verplicht

Hoe werkt het

Documenten worden opgedeeld in chunks die elk op zichzelf begrijpelijk zijn. Drie hoofdstrategieen. Fixed-size: elke chunk precies N tokens (simpel, maar breekt soms mid-zin). Recursive: splits op natuurlijke grenzen (paragrafen, zinnen) met target-grootte. Document-aware: sectie- of hoofdstuk-gewijs, met metadata per chunk.

Voor MKB-kennisbanken werkt recursive met overlap meestal het beste. Overlap van 50-100 tokens zorgt dat context op chunk-grenzen behouden blijft. Voor sterk gestructureerde documenten (handleidingen, FAQ's) kan document-aware chunking de kwaliteit significant verbeteren omdat je per sectie een coherente chunk krijgt.

Waar moet je op letten

  • Te kleine chunks (onder 200 tokens) verliezen context en geven vage antwoorden
  • Te grote chunks (boven 1000 tokens) maken retrieval onnauwkeurig
  • Metadata (titel, datum, bron) opslaan per chunk voor citaten en filtering
  • Tabellen en lijsten vragen aparte chunking-behandeling

Hoe werkt het

Een embedding-model zet tekst om in een vector van doorgaans 768 tot 3072 dimensies. Populaire keuzes in 2026: OpenAI text-embedding-3-large (sterk in Nederlands, 3072 dim), voyage-2 (uitstekende retrieval-kwaliteit, duurder), bge-large-en (open-source, gratis, Engels-dominant), multilingual-e5-large (open-source, meertalig). Dezelfde embedding-model gebruik je zowel bij indexeren van documenten als bij queries.

Voor Nederlandstalige MKB-RAG zijn OpenAI text-embedding-3-large en multilingual-e5 in eigen hosting de twee standaardkeuzes. Kies op basis van gewenste privacy: OpenAI betekent data naar VS, open-source zelf hosten houdt data in eigen omgeving. Voor gevoelige content is zelf-hosting vaak de keuze; voor low-stakes-content is OpenAI praktischer.

Waar moet je op letten

  • Test meerdere modellen op eigen content; niet elk model scoort op jouw domein
  • Embedding-model wisselen vereist herindexering van alle documenten
  • Dimensies hoger is niet altijd beter; 1024 dim is vaak genoeg
  • Zelf hosten van open-source embeddings vraagt GPU-capaciteit of speciale services

Hoe werkt het

De prompt bevat drie delen. Systeem-instructie: wat de bot wel en niet mag doen (alleen uit bron, antwoorden met citaten, zeggen 'ik weet het niet' als niets relevant). Opgehaalde chunks: de top 3-10 chunks met hun metadata. Vraag: de originele gebruikersvraag. Goede prompt-engineering verschilt tussen standaardantwoorden en uitstekende antwoorden.

Best practices: expliciet instrueren dat het model alleen uit de chunks mag antwoorden; vragen om citaat per feit; formaat afdwingen (bijvoorbeeld paragraaf plus citaat-lijst); edge-cases benoemen (geen relevante chunk, tegenstrijdige chunks). Test deze prompts op een testset voor productie; kleine aanpassingen kunnen dramatisch verschil maken.

Waar moet je op letten

  • Model instrueren om 'ik weet het niet' te zeggen voorkomt de meeste hallucinaties
  • Citaat-verplichting maakt antwoorden verifieerbaar door gebruikers
  • Prompts versioneren zoals code; wijziging kan regressies geven
  • Testset van 20-50 vragen met verwachte antwoorden maakt kwaliteit meetbaar
Rag vs fine-tuning

RAG versus fine-tuning voor bedrijfskennis

Wanneer welke techniek? Voor de meeste MKB-gebruiken is RAG de betere keuze, maar niet voor alles.

Kenmerk RAG Fine-tuning
Bronnen bijwerkenMinuten (nieuw doc toevoegen)Dagen (hertraining)
TraceerbaarheidHoog (citaten mogelijk)Laag (kennis zit in gewichten)
Initiele kosten15-45k euro30-80k euro
Operationele kostenPer query (LLM-call + vector-db)Per query (eigen model hosten)
Sterk inActuele feiten, Q-and-ASpecifieke stijl, vast formaat
Zwak inZeer lange context-syntheseKennis die vaak verandert
MKB-adviesDefault keuzeAlleen voor specifieke stijl
Aan de slag

Zo bouw je een RAG-systeem

De vier fases voor een werkende MVP. Elke fase heeft concrete deliverables en checkpoints.

Documenten
Selecteer, schoon op, wijs eigenaren aan per bron.
Pipeline
Chunking, embedding, vector-db, retriever bouwen.
Prompt en eval
Prompt engineeren, testset maken, itereren op kwaliteit.
UI en live
Interface, auth, monitoring, feedback-loop inregelen.

Veelgestelde vragen over RAG

Meer over de bouwstenen? Zie onze vector database-gids en databronnen-integratie-gids.

RAG staat voor Retrieval Augmented Generation en is een techniek die grote taalmodellen (LLMs) combineert met actuele eigen kennis. De LLM wordt bij elke vraag eerst 'gevoed' met relevante documenten uit een eigen kennisbank voordat hij antwoordt. Zo combineer je de taalvaardigheid van het model met de actuele, specifieke kennis van jouw organisatie. Een RAG-chatbot die op je interne handleidingen werkt geeft antwoorden gebaseerd op die handleidingen, niet op wat het model eerder geleerd heeft. Dit is waarom RAG de standaard is voor bedrijfs-chatbots geworden in plaats van vanilla-ChatGPT of fine-tuning.
Gebruik RAG als je kennis verandert of uitgebreid is. Fine-tuning past het model aan op een specifieke stijl of taak; RAG geeft het model toegang tot actuele feiten. Voor MKB-toepassingen is RAG bijna altijd de betere keuze. Voordelen: bronnen zijn bijwerkbaar zonder hertrainen (nieuw document toevoegen en het werkt direct), antwoorden zijn traceerbaar naar brondocumenten (citaten mogelijk), kosten liggen lager (geen training-cycle). Fine-tuning overweeg je alleen voor zeer specifieke taken waar stijl of formaat kritiek is en de kennis stabiel, bijvoorbeeld een model dat altijd in een bepaald template genereert.
Een RAG-systeem bestaat uit vier componenten. Ten eerste: documentenbron (kennisbank, handleidingen, policies). Ten tweede: embedding-pipeline die documenten in chunks splitst en per chunk een vector-representatie berekent met een embedding-model. Ten derde: vector database die de vectors opslaat en waar snel op gezocht kan worden (pgvector, Pinecone, Qdrant, Weaviate). Ten vierde: retrieval plus generation waar bij elke vraag relevante chunks worden opgezocht en een LLM antwoord genereert op basis daarvan. Deze vier componenten kun je grotendeels open-source bouwen, of combineren met SaaS-diensten. De architectuur is conceptueel eenvoudig maar de uitvoering vraagt zorgvuldigheid.
Een embedding model zet tekst om in een numerieke vector (typisch 768 tot 3072 dimensies) die de semantische betekenis representeert. Twee teksten met vergelijkbare betekenis hebben vectors die wiskundig dicht bij elkaar liggen, ook als de woorden verschillen. Populaire embedding-modellen zijn text-embedding-3 van OpenAI, voyage-2 van Voyage AI, en open-source modellen zoals bge-large. Voor Nederlandse tekst werken OpenAI en meertalige modellen goed; puur Engelse modellen presteren minder. Keuze van embedding-model beinvloedt de retrieval-kwaliteit sterk; test in jouw eigen domein voordat je commit.
Vector search is het opzoeken van de meest vergelijkbare vectors in een database gegeven een query-vector. Het is de kern van retrieval bij RAG: een vraag wordt omgezet naar een vector, die vector wordt vergeleken met alle document-chunk-vectors, en de dichtstbijzijnde chunks worden opgehaald als basis voor het antwoord. Vector search is snel zelfs op miljoenen documenten dankzij specifieke index-algoritmes (HNSW, IVF). Vergelijking met klassieke zoektechnieken: keyword-search matcht op exacte woorden, vector-search op betekenis. Een query 'hoe regel ik verlof' vindt zo ook een document getiteld 'vakantieaanvragen'.
Voor een MKB-RAG-chatbot reken je op 15.000-45.000 euro voor een werkende versie, afhankelijk van scope en complexiteit. Basis-implementatie (1.000-3.000 documenten, standaard chatinterface): 15.000-25.000 euro. Uitgebreid met authenticatie, meerdere bronnen en integraties: 25.000-45.000 euro. Operationele kosten: 200-600 euro per maand voor LLM-calls en vector-database bij typisch MKB-volume. Een pilot vooraf (5.000-8.000 euro) om de architectuur te valideren is vaak verstandig. Kosten dalen als je je beperkt tot een welomschreven gebruik en schalen op met aantal gebruikers en query-volume.
De keuze hangt af van je stack. Als je al PostgreSQL draait (wat veel Nederlandse MKB-stacks doen via Laravel, Rails, Supabase), dan is pgvector zeer aantrekkelijk: geen extra service, query's combineren met relationele data, prima prestaties tot miljoenen vectors. Voor dedicated vector-workloads zijn Pinecone (SaaS, eenvoudig), Qdrant (open-source, sterk in hybrid search) en Weaviate (open-source, feature-rijk) populair. Voor MKB-RAG tot circa 500.000 chunks is pgvector bijna altijd voldoende en goedkoopst. Voor grotere schaal of zeer specifieke features kies je een gespecialiseerde vector database. Meer over de keuze in onze gids Vector database kiezen.
Hallucinaties zijn onjuiste antwoorden die toch zelfverzekerd klinken. Vijf technieken helpen. Ten eerste: prompt-instrueer het model expliciet om alleen uit de gegeven chunks te antwoorden en te zeggen 'ik weet het niet' als het er niet staat. Ten tweede: vereiste citaten naar brondocumenten in elke antwoord. Ten derde: retrieval-kwaliteit verbeteren met betere chunking en re-ranking. Ten vierde: output-validatie op onmogelijke claims. Ten vijfde: feedback-loop zodat gebruikers verkeerde antwoorden kunnen flaggen. Perfecte hallucinatie-vrijheid is onbereikbaar; het doel is een acceptabel niveau voor jouw use case, meetbaar via een testset.
Voor een werkende MVP-RAG-chatbot: vier tot acht weken. Week 1-2 scope, documentselectie en eerste embedding-pipeline. Week 3-4 vector database, retrieval en eerste chat-interface. Week 5-6 prompt-engineering en eval op testset. Week 7-8 UI-afwerking, auth, deployment. Voor productie-waardig (met monitoring, alerting, schaal) rek je op 10-14 weken. De snelheid wordt bepaald door documentkwaliteit: een schone, goed-gestructureerde kennisbank levert sneller een goede bot dan een archief vol verouderde en tegenstrijdige bestanden. Documenten opschonen is vaak de langste stap.

Opgesteld met AI-ondersteuning door de redactie van Prometheus21, laatst bijgewerkt op 7 september 2026. Hoe wij content maken

RAG chatbot laten bouwen

In een gratis kennismaking bespreken we welke kennisbronnen geschikt zijn en of RAG de juiste keuze is voor jouw use case. Binnen weken een werkende MVP, met documenten op orde en architectuur op maat.