Een AI-chatbot op je eigen data (RAG): een praktisch stappenplan

Een chatbot die 'alles weet over jouw bedrijf' klinkt geweldig, totdat hij doodleuk een leverdatum verzint die nergens op slaat. Het verschil tussen die twee uitkomsten heeft een naam: RAG, oftewel Retrieval-Augmented Generation. Het is de techniek waarmee je een AI-model laat antwoorden op basis van jouw eigen documenten, in plaats van op basis van wat het toevallig ooit van het internet heeft geleerd.

Deze gids is voor de ondernemer of het team dat verder wil dan losse ChatGPT-prompts en een assistent op de eigen kennisbank wil zetten: handleidingen, productinformatie, contracten, oude supporttickets. Ik leg in gewone taal uit wat RAG is, wat je nodig hebt, in welke stappen je het bouwt, waar het misgaat, en wanneer een kant-en-klare dienst volstaat en wanneer maatwerk loont. Het technische patroon is in 2026 uitgekristalliseerd, dus ik kan concreet worden zonder je te bedelven onder jargon.

Wat RAG eigenlijk is, in gewone taal

Een taalmodel zoals de modellen achter ChatGPT of Claude is in de kern een enorme tekstvoorspeller. Het is getraind op heel veel tekst en daardoor goed in vloeiend antwoorden. Maar het weet niets van jouw prijslijst, jouw handleidingen of jouw interne afspraken. Vraag je iets wat het niet weet, dan vult het de gaten op met iets dat plausibel klinkt. Dat is het beroemde 'hallucineren'.

RAG lost dat op met een truc die in de naam verstopt zit. Het bestaat uit twee stappen:

1. Retrieval (ophalen). Voordat het model antwoordt, zoekt het systeem eerst in jouw bronnen naar de stukjes tekst die relevant zijn voor de vraag. Vraagt iemand 'wat is de levertijd van product X', dan haalt het systeem de paar alinea's uit jouw documentatie waar dat in staat.
2. Generation (genereren). Die gevonden stukjes gaan samen met de vraag naar het model, met de instructie: beantwoord de vraag op basis van deze tekst. Het model schrijft dan een net antwoord, gebaseerd op jouw informatie in plaats van op een gok.

Vergelijk het met een nieuwe medewerker. Een gewoon taalmodel is een welbespraakte stagiair die op alles een vlot antwoord heeft, ook als hij het niet weet. RAG is dezelfde stagiair, maar nu met jouw handboek opengeslagen en de opdracht alleen daaruit te antwoorden.

Wat je nodig hebt

RAG klinkt magisch, maar het is opgebouwd uit vier nuchtere onderdelen. Het helpt om te weten welke dat zijn, ook als je het niet zelf gaat bouwen, want bij elk onderdeel zitten keuzes die de kwaliteit bepalen.

1. Bronnen

Dit is je eigen kennis: handleidingen, productinformatie, veelgestelde vragen, procedures, contracten, oude supporttickets. Dit is meteen het belangrijkste onderdeel. De korte versie: rommel erin betekent rommel eruit. Het opschonen ervan is een vak apart, en ik werk dat los uit in mijn gids over verspreide bestanden uit Drive, mail en spreadsheets opschonen tot AI-klare input.

2. Embeddings

Een computer 'begrijpt' niet vanzelf dat 'levertijd' en 'wanneer komt mijn bestelling' hetzelfde betekenen. Een embedding lost dat op: het vertaalt een stuk tekst naar een rij getallen die de betekenis vastlegt. Teksten die over hetzelfde gaan, krijgen rijtjes die dicht bij elkaar liggen. Zo kan het systeem zoeken op betekenis in plaats van op exacte woorden. Je hoeft niet te snappen hoe die getallen werken, alleen dat dit de stap is die 'zoeken op begrip' mogelijk maakt.

3. Een vectordatabase

Al die rijtjes getallen moeten ergens opgeslagen worden, zo dat je razendsnel vindt welke stukken het dichtst bij een vraag liggen. Dat is wat een vectordatabase doet. Je hoeft hier niet voor naar een exotische dienst: PostgreSQL met de pgvector-uitbreiding doet dit prima, en dat is meteen een database die je voor de rest van je toepassing kunt gebruiken. Ik bouw dit graag op Supabase, dat Postgres met pgvector standaard aan boord heeft en dat ik ook self-hosted kan draaien.

4. Een taalmodel

Tot slot het model dat het uiteindelijke antwoord schrijft. Hier heb je keuze: een commercieel model via een API, of een open model dat je zelf draait. Voor gevoelige data is dat tweede vaak het overwegen waard, daarover zo meer.

In stappen: van losse documenten naar een werkende chatbot

Je bouwt een RAG-chatbot in zes stappen: je bronnen opschonen, ze knippen in behapbare stukken, die omzetten naar embeddings en indexeren, bij elke vraag de juiste stukken ophalen (hybride en met reranking), het model een antwoord met bronvermelding laten schrijven, en het geheel toetsen met een eigen vragenset. De eerste drie doe je eenmalig, de laatste drie gebeuren bij elke vraag of doorlopend.

Werk ze in deze volgorde af.

Stap 1: Bronnen verzamelen en opschonen

Kies eerst een afgebakende use case (bijvoorbeeld: een supportbot op je openbare handleidingen) en verzamel alleen de bronnen die daarbij horen. Gooi dubbele en verouderde versies eruit voordat je iets indexeert. Dit is geen bijzaak: het bepaalt het resultaat meer dan welke techniek dan ook.

Stap 2: Knippen in stukken (chunking)

Een heel document in één keer indexeren werkt slecht: het zoeken wordt grof en je propt te veel irrelevante tekst in het model. Daarom hak je je bronnen in 'chunks' van doorgaans een paar honderd tokens. Voor feitelijke vragen werkt een stuk van 256 tot 512 tokens vaak goed, voor analyses een groter stuk. Knip op een logische grens (een kop, een alinea), niet halverwege een zin, en laat stukken een beetje overlappen zodat context niet wegvalt.

Stap 3: Embeddings maken en indexeren

Van elk stuk maak je een embedding en die zet je in de vectordatabase. Dat doe je één keer, en daarna telkens als er documentatie bijkomt of verandert. Bewaar bij elk stuk waar het vandaan komt (het bronbestand, de titel), want die herkomst heb je straks nodig voor de bronvermelding.

Stap 4: Ophalen, hybride en met reranking

Hier zit de grootste kwaliteitswinst, en het is precies waar veel zelfgebouwde opzetten tekortschieten. Zoeken op betekenis alleen (de embeddings) mist exacte termen: een artikelnummer, een foutcode als 'TS-999', een productnaam. Daarom combineer je het met klassiek trefwoordzoeken (BM25), dat juist die letterlijke treffers vindt. Die twee ranglijsten voeg je samen. Dat heet hybride retrieval.

Daarna voeg je een rerankstap toe: je haalt ruim op (zeg honderd tot honderdvijftig kandidaat-stukken) en laat een apart model de beste twintig naar boven schiften. Dat scheelt aantoonbaar. In benchmarks van Anthropic verlaagde de combinatie van slim ophalen plus reranking het aantal misgrepen retrievals met 67%, van 5,7% naar 1,9%, terwijl hybride zoeken zonder reranking op een daling van 49% bleef steken. Het verschil tussen 'soms het juiste stuk' en 'bijna altijd het juiste stuk' zit dus in deze stap.

Stap 5: Antwoord schrijven, met bronvermelding

De gevonden stukken gaan samen met de vraag naar het model. Instrueer het expliciet om alleen op basis van die stukken te antwoorden en om 'dat staat niet in onze documentatie' te zeggen als het antwoord er niet in staat. Toon er altijd bij uit welk document het antwoord komt, zodat een medewerker of klant het kan controleren. Die bronvermelding is geen luxe, het is je belangrijkste verdediging tegen blind vertrouwen.

Stap 6: Evalueren met een eigen vragenset

Dit is de stap die het vaakst wordt overgeslagen, en zonder deze stap weet je niet of je iets bouwt dat werkt. Maak een lijst van echte vragen met de juiste antwoorden, en meet hoe je systeem het doet. Een framework als RAGAS meet dit met concrete maatstaven: faithfulness (komt het antwoord echt uit de bron), context recall en context precision. Zo zie je of de fout in het ophalen zit of in het schrijven, en kun je gericht bijsturen in plaats van blind aan instellingen draaien.

Waar het misgaat

Nu het eerlijke deel, waar glanzende demo's botsen met de werkelijkheid. RAG faalt zelden op de techniek. Het faalt op de details eromheen.

Slechte bronkwaliteit

Dit is veruit de grootste valkuil. RAG is zo goed als de documenten die je erin stopt. Heb je drie versies van dezelfde handleiding, waarvan twee verouderd? Dan citeert de chatbot vrolijk de verkeerde. Het saaie werk van je bronnen opschonen, ontdubbelen en actueel houden bepaalt het succes meer dan welke fancy techniek dan ook. Wie denkt dat AI een rommelige kennisbank vanzelf goedmaakt, komt bedrogen uit.

Hallucinaties, ook met RAG

RAG vermindert hallucinaties flink, maar bant ze niet helemaal uit. Vindt het systeem geen goed passend stuk, dan kan het model alsnog gaan gokken, of het mengt twee bronnen tot een antwoord dat half klopt. De oplossingen zijn nuchter: instrueer het model om 'ik weet het niet' te zeggen als de bronnen geen antwoord geven, toon altijd de bron, en test met echte vragen (stap 6) voordat je het loslaat op klanten. Een chatbot die soms eerlijk 'dat staat niet in onze documentatie' zegt, is veel meer waard dan een die altijd iets verzint.

Verkeerd knippen en mager zoeken

Twee stille killers die in demo's onzichtbaar blijven. Knip je te grof, dan haalt het systeem hele lappen op waarin het antwoord verdrinkt; knip je te fijn, dan valt de context weg. En wie alleen op betekenis zoekt zonder trefwoordzoeken erbij, mist stelselmatig de vragen om een exact artikelnummer of een foutcode. Beide problemen zie je pas als je meet (stap 6), niet als je een paar keer zelf wat intypt.

Rechten en privacy

Dit onderdeel wordt het vaakst over het hoofd gezien, en het is in Nederland geen detail. Twee dingen om scherp te hebben.

Ten eerste toegangsrechten. Als je alle bedrijfsdocumenten in één bak gooit, kan de chatbot in theorie salarisgegevens of vertrouwelijke contracten naar de verkeerde persoon lekken. Wie wat mag zien, moet meegebouwd worden in het systeem, niet achteraf bedacht.

Ten tweede waar je data heen gaat. Bij een commercieel model via een API stuur je stukjes van je bronnen en de vragen van je medewerkers naar een externe partij, vaak buiten de EU. Voor klantgegevens, medische informatie of gevoelige bedrijfsdata is dat een AVG-vraagstuk dat je niet kunt negeren, en zoals ik eerder uitwerkte, zit het AVG-risico zelden in het model en bijna altijd in je data. Hier komt de self-hosted hoek kijken: je kunt het hele systeem, inclusief een open taalmodel en de vectordatabase, op je eigen server draaien. Dan verlaat geen enkel document je infrastructuur. Dat kost wat meer inrichting, maar voor een administratiekantoor, een zorgpraktijk of ieder bedrijf met gevoelige data is het vaak het verschil tussen wel en niet kunnen.

Realistische verwachtingen voor het MKB

Tijd om de hype te temperen met nuchterheid. RAG is uitstekend voor vragen waar het antwoord ergens in jouw documenten staat: een interne assistent die je team door procedures helpt, een supportchatbot die veelgestelde vragen afvangt, of een zoekfunctie die eindelijk vindt wat je bedoelt in plaats van wat je letterlijk typt. Dat scheelt echt tijd.

Wat het niet is: een orakel. RAG redeneert niet, het haalt op en herformuleert. Het neemt geen beslissingen en is niet slimmer dan je documentatie. Verwacht een snelle, behulpzame collega die goed kan opzoeken, geen alwetende adviseur. En over de moeite: het echte werk zit niet in de techniek, dat patroon ligt vast. Het zit in jouw bronnen op orde brengen, de toegangsrechten goed regelen, en het geheel testen tot het betrouwbaar genoeg is. Met slim werken, loont hard werken: een avond investeren in het opschonen van je kennisbank levert meer op dan een maand sleutelen aan het model.

Wanneer kant-en-klaar genoeg is, en wanneer maatwerk loont

Er bestaan kant-en-klare diensten waar je documenten uploadt en een chatbot uitrolt. Beheerde RAG-platforms regelen inmiddels de hele pijplijn voor je: een jaar geleden moest je nog zelf een vectordatabase kiezen, een embeddingmodel uitzoeken en een rerankstap bouwen, terwijl je dat nu bij een dienst als AWS Bedrock met ingebouwde connectoren, agentische retrieval en EU-regio's in één keer aanzet. Voor een simpele, niet-gevoelige toepassing kan dat prima volstaan. Begin daar gerust mee als de inzet laag is.

De keerzijde van kant-en-klaar is afhankelijkheid: je data, je indexering en je retrieval-logica leven dan in het platform van de leverancier, en eruit migreren is zelden een knop omzetten. Maatwerk loont zodra het serieus wordt. De afweging op een rij:

De echte vraag is niet of RAG technisch werkt, dat doet het. De vraag is of jij bereid bent te investeren in de saai-klinkende randvoorwaarden: je bronnen op orde, je privacy geregeld, je verwachtingen realistisch, en een vragenset om te meten of het klopt. Doe je dat, dan heb je een systeem dat maanden later nog steeds z'n werk doet, in plaats van een demo die indruk maakt en daarna in een la belandt.