RAG systeem opzetten: Retrieval Augmented Generation

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, baseert zijn antwoorden op die handleidingen in plaats van 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'.

Wat een werkende MKB-RAG-chatbot kost, hangt af van scope en complexiteit en wordt altijd vooraf besproken. De operationele kosten hangen af van het volume aan LLM-calls en de vector-database. Een pilot vooraf 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. Helemaal zonder hallucinaties lukt nooit; 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.