← terug

10 juni 2026

RAG begrijpelijk uitgelegd

De vraag die ik het vaakst krijg klinkt ongeveer zo: "Kunnen we ChatGPT niet gewoon op onze eigen documenten aansluiten?" Een logische vraag. Het antwoord is ja, dat kan. De techniek erachter heet RAG, retrieval augmented generation. Maar tussen "dat kan" en "dat werkt betrouwbaar in productie" zit een wereld die de meeste organisaties pas zien als ze er middenin staan.

Daarom deze uitleg. Geen wiskunde, geen jargonmist. Gewoon wat er technisch gebeurt als een AI-assistent antwoorden geeft op basis van jouw bedrijfskennis, en waar je op moet letten voordat je dit loslaat op echte gebruikers.

Waarom het model je documenten niet kent

Een taalmodel is getraind op een enorme berg publieke tekst. Tijdens die training leert het patronen: hoe taal werkt, hoe redeneringen lopen, wat er over duizenden onderwerpen geschreven is. Maar jouw offertes, beleidsdocumenten, contracten en interne wiki zaten daar niet bij. Het model heeft ze nooit gezien.

En nee, je kunt ze er ook niet even "bij trainen". Een model bijtrainen op je eigen documenten is duur, traag, moeilijk te updaten en verrassend slecht in het onthouden van specifieke feiten. Als morgen je verlofregeling verandert, wil je niet een model opnieuw trainen. Je wilt dat het systeem het nieuwe document gebruikt.

Dat is precies wat RAG doet. In plaats van kennis in het model te stoppen, geef je het model de juiste stukken tekst op het moment dat de vraag binnenkomt. Vergelijk het met een tentamen: het model maakt geen tentamen uit het hoofd, het maakt een open boek tentamen. De kwaliteit van het antwoord hangt dan af van twee dingen: hoe goed het model is, en of de juiste pagina's op tafel liggen.

De vier stappen onder de motorkap

RAG bestaat uit een voorbereidende fase en een vraagfase. De voorbereiding gebeurt als je documenten toevoegt. De vraagfase gebeurt elke keer als iemand iets vraagt.

Stap 1: chunking. Je documenten worden in stukken geknipt, chunks. Een beleidsdocument van veertig pagina's is te groot om in een keer aan een model te voeren, en bovendien gaat een vraag meestal maar over een klein deel ervan. Dus knip je het op: per paragraaf, per kopje, of per blok van een paar honderd woorden. Hoe je knipt maakt enorm uit. Knip je een tabel doormidden, dan klopt de helft van de informatie nergens meer. Knip je te grof, dan haal je later veel ruis op.

Stap 2: embeddings. Elk stuk tekst krijgt een embedding, een lange reeks getallen die de betekenis van die tekst vastlegt. Een embedding is geen samenvatting. Het is eerder een plek op een betekeniskaart. Twee zinnen met totaal andere woorden, zoals "medewerker neemt vrij" en "verlofaanvraag indienen", komen op die kaart dicht bij elkaar te liggen. Daardoor kun je straks zoeken op betekenis in plaats van op exacte woorden.

Stap 3: de vector database. Al die embeddings worden opgeslagen in een vector database. Dat is een database die niet vraagt "welke rij heeft deze waarde?" maar "welke stukken tekst liggen het dichtst bij deze vraag?". Samen met elke embedding sla je metadata op: uit welk document komt deze chunk, wanneer is het geüpdatet, wie mag het zien. Die metadata lijkt een detail. In productie is het de helft van het werk.

Stap 4: retrieval en het antwoord. Stelt iemand een vraag, dan wordt die vraag ook omgezet naar een embedding. De vector database zoekt de chunks die er qua betekenis het dichtst bij liggen, bijvoorbeeld de beste vijf of tien. Die stukken tekst gaan samen met de vraag naar het taalmodel, met een instructie in de trant van: beantwoord deze vraag op basis van deze fragmenten. Het model schrijft het antwoord. De gebruiker ziet alleen dat antwoord. De organisatie moet de hele dataflow erachter begrijpen.

Een voorbeeld uit de praktijk

Stel, een zorginstelling bouwt een interne assistent voor medewerkers. Iemand typt: "Mag een stagiair medicatie aftekenen?" Het systeem zoekt in de embeddings van protocollen en handboeken, vindt drie relevante fragmenten uit het medicatiebeleid, en het model formuleert daar een antwoord uit, met bronvermelding naar het protocol.

Dat is de demo, en die demo is vaak binnen een paar dagen gebouwd. Indrukwekkend om te zien. Maar let op wat hier allemaal goed moet gaan: het juiste protocol moet in het systeem zitten, de juiste versie, goed geknipt, goed vindbaar, en de medewerker moet dat document überhaupt mogen inzien. Eén van die schakels stuk, en het antwoord klinkt nog steeds even zelfverzekerd. Het is alleen fout.

RAG is niet upload wat PDF's

Dit is de misvatting die ik het vaakst tegenkom. RAG wordt verkocht alsof je een map met PDF's uploadt en klaar bent. In werkelijkheid bouw je een zoeksysteem, en de kwaliteit van je antwoorden wordt begrensd door de kwaliteit van dat zoeksysteem. Het model kan nog zo goed zijn: als de retrieval het verkeerde fragment ophaalt, krijg je een mooi geformuleerd antwoord op basis van de verkeerde informatie.

In de praktijk betekent dat werk dat niemand in de demo laat zien. Documenten opschonen. Dubbele en verouderde versies eruit halen. Bepalen hoe je tabellen, scans en formulieren verwerkt. Testen of de juiste fragmenten boven komen drijven bij de vragen die mensen echt stellen, niet bij de drie nette voorbeeldvragen uit de presentatie.

Waar het in productie spannend wordt

De demo is makkelijk. Productie is waar AI serieus wordt. Vier punten waar het in mijn ervaring gaat schuren.

Rechten. In je documentsysteem mag niet iedereen alles zien. Een salaristabel, een reorganisatieplan, een dossier. Zodra je die documenten omzet naar embeddings in een vector database, gelden die rechten niet automatisch meer. Als je niet per chunk bijhoudt wie het mag zien, en dat afdwingt bij elke zoekopdracht, dan kan een medewerker via de assistent dingen lezen die in de bronsystemen keurig afgeschermd waren. Dit is geen randgeval. Dit is de eerste vraag die je moet stellen.

Verse data. Documenten veranderen. Wordt een protocol vandaag aangepast, dan staan de oude chunks nog gewoon in je vector database totdat je ze vervangt. Je hebt dus een proces nodig dat wijzigingen detecteert en de embeddings bijwerkt. Zonder dat proces geeft je assistent met volle overtuiging antwoorden op basis van beleid van vorig jaar.

Verwijderde documenten. De lastige spiegelvraag: wat gebeurt er als een document weg moet? Bijvoorbeeld omdat een bewaartermijn verloopt of omdat iemand zich op de AVG beroept. Het origineel verwijderen is niet genoeg. De chunks en embeddings die ervan zijn afgeleid staan ergens anders, en soms ook nog in caches en logs. Wie embeddings bewaart, bewaart afgeleide bedrijfskennis. Dat moet je kunnen terugvinden en opruimen.

Kwaliteit van retrieval. En dan de stille sloper van RAG-projecten: middelmatige zoekresultaten. Zoeken op betekenis werkt goed, maar niet altijd. Vraag je naar "artikel 7.2 van het huurcontract", dan wil je exact dat artikel, geen tekst die er qua sfeer op lijkt. Daarom combineren serieuze systemen betekeniszoeken met klassiek zoeken op trefwoorden, en wordt er gemeten: bij welke vragen halen we de juiste fragmenten op, en bij welke niet? Als je dat niet meet, weet je niet of je assistent goed is. Dan weet je alleen dat hij vlot formuleert.

De vragen die je morgen kunt stellen

Praat je deze week met een leverancier of je eigen team over een AI-assistent op bedrijfskennis, stel dan deze vragen:

Kan iemand die vragen niet beantwoorden, dan heb je geen kennissysteem maar een demo met een wachtwoord ervoor.

Tot slot

RAG is een goed idee. Het is op dit moment de meest praktische manier om een taalmodel te laten werken met kennis die het model zelf niet heeft, zonder dat je die kennis hoeft in te bakken. Maar het is geen knop die je aanzet. Het is een zoeksysteem plus een taalmodel plus een datapijplijn plus een rechtenmodel, en elk van die onderdelen kan de boel verpesten.

Wie dat snapt, stelt betere vragen, kiest betere leveranciers en bouwt assistenten waar mensen echt op kunnen vertrouwen. En dat is uiteindelijk het enige dat telt: niet of het antwoord goed klinkt, maar of het klopt, op basis van het juiste document, gezien door de juiste persoon. 

↘︎ ALLE ARTIKELEN