Wat is RAG en waarom heb je het nodig?
Een taalmodel weet niets van jouw organisatie. Het kent geen contracten, geen werkinstructies, geen productcatalogus. Vraag je er toch naar, dan verzint het een plausibel antwoord, want dat is wat het is getraind te doen.
RAG lost dat op door de volgorde om te draaien. In plaats van het model te vragen iets te weten, zoek je eerst de relevante passages in je eigen documenten op en geef je die mee bij de vraag. Het model redeneert dan over materiaal dat feitelijk klopt.
Het voordeel is dat je documenten kunt bijwerken zonder het model aan te raken. Een gewijzigde werkinstructie is morgen actief. Het nadeel is dat de kwaliteit van het antwoord staat of valt met wat de zoekstap oplevert, en dat is een dataprobleem, geen modelprobleem.
Dat verklaart waarom RAG-projecten zelden op het model stranden en vrijwel altijd op de voorbewerking.
Waarom niet gewoon een model finetunen?
Finetunen betekent een model verder trainen op jouw materiaal, zodat de kennis in de gewichten terechtkomt. Dat klinkt eleganter en is het voor de meeste zakelijke toepassingen niet.
Bij finetunen kun je niet zien waar een antwoord vandaan komt. Er is geen bronverwijzing, dus je kunt een uitkomst niet controleren en bij een fout niet herleiden waar hij is ontstaan. Voor alles wat richting compliance of klantcommunicatie gaat, is dat een blokkade.
Bijwerken is bovendien duur. Een gewijzigd contract betekent opnieuw trainen, terwijl je bij RAG één document vervangt.
Finetunen is wel de juiste keuze wanneer je een vaste toon, een specifiek uitvoerformaat of een gespecialiseerde taak wilt vastleggen die met instructies alleen niet stabiel wordt. In de praktijk zie je vaak beide: RAG voor de kennis, lichte finetuning voor de vorm.
De vier lagen onder een werkende agent
Wij tekenen dit als een piramide, omdat elke laag op de vorige rust. Wie een laag overslaat, krijgt een agent die overtuigend antwoordt op verouderde of halve informatie.
1. Ontsluiten. Data uit systemen en documenten beschikbaar maken. PDF's, Word, HTML, databases, API's, e-mail. Dit is het saaiste en meest tijdrovende deel, en het bepaalt de bovengrens van alles wat erna komt.
2. Structureren. Opschonen, ontdubbelen, ordenen. Verouderde versies eruit, koppen en metadata behouden, tabellen intact laten.
3. Vectoriseren. De opgeschoonde tekst omzetten naar embeddings en opslaan in een doorzoekbare index, bijvoorbeeld pgvector.
4. Modellen voeden. Bij elke vraag de juiste passages ophalen en meegeven, met de bron erbij.
De verdeling van de inspanning is opvallend: het bouwen van laag vier is meestal een fractie van het werk. De eerste twee lagen kosten het leeuwendeel.
Waarom chunking het verschil maakt
Documenten gaan in stukken de index in. Hoe je knipt bepaalt wat de zoekstap kan vinden, en dit is de meest onderschatte keuze in het hele traject.
Knip je te klein, dan verlies je context. Een passage die zegt "dit geldt niet voor categorie B" is zonder de voorgaande alinea betekenisloos, en kan een antwoord actief fout maken.
Knip je te groot, dan wordt de match onscherp. Een stuk van drie pagina's over vijf onderwerpen matcht matig op elk van die vijf.
Werkbare uitgangspunten: knip op semantische grenzen zoals koppen en paragrafen in plaats van op een vast aantal tekens, laat stukken licht overlappen zodat een zin op de grens niet verdwijnt, en bewaar per stuk de metadata die je nodig hebt om te filteren en te verwijzen: brondocument, kop, datum, versie, en wie het mag zien.
Dat laatste is geen detail. Zonder rechten in de metadata beantwoordt je systeem vragen met documenten die de vrager niet had mogen zien.
Hoe weet je of het werkt?
Dit is de stap die vrijwel altijd wordt overgeslagen, met als gevolg dat niemand kan zeggen of een wijziging verbetering is.
Bouw een testset van veertig tot honderd echte vragen uit de organisatie, met per vraag het verwachte antwoord en het brondocument. Meet twee dingen apart.
Haalt de zoekstap het juiste document op? Als het antwoord niet in de opgehaalde passages zit, kan het model het onmogelijk goed doen. Dit is de meest voorkomende faalmodus en hij is eenvoudig te meten.
Klopt het antwoord? Pas relevant als de eerste vraag goed scoort.
Deze scheiding is belangrijk omdat de oplossingen verschillen. Een slechte retrieval los je op met chunking, metadata of een ander embeddingmodel. Een slecht antwoord bij goede retrieval los je op met instructies of een ander model.
Draai de testset opnieuw na elke wijziging. Zonder die meting is doorontwikkelen gokken.
De vier manieren waarop het misgaat
Verouderde data. De index is een momentopname. Zonder periodieke herinname beantwoordt je systeem over een half jaar vragen met vorig jaar. Plan de herinname als terugkerende taak, niet als handmatige actie.
Geen bronvermelding. Een antwoord zonder verwijzing kan niemand controleren, en dan wordt het systeem niet vertrouwd en niet gebruikt. Toon altijd waar het vandaan komt.
Rechten die niet meereizen. Zie hierboven. Dit is de meest kostbare fout omdat je hem pas ontdekt als het misgaat.
Alles in één index. Contracten, werkinstructies en marketingteksten in dezelfde bak levert ruis. Scheid per domein, of filter hard op metadata.
Wat kun je ermee bouwen?
Drie patronen komen het vaakst voor.
Interne kennisvraagbaak. Medewerkers stellen vragen over procedures, producten of regelingen en krijgen antwoord met bronverwijzing. Levert het meeste op bij organisaties waar veel kennis in documenten en in hoofden zit.
Klantenservice-ondersteuning. Inkomende vragen worden beantwoord of voorbereid op basis van de eigen kennisbank. Bij Drimble, een nieuwsplatform met dagelijks honderden klantvragen, handelt een agent een groot deel van de tickets direct af.
Signaalmonitoring. Grote hoeveelheden bronnen doorlopend scannen en er relevante veranderingen uithalen. Bij Fintool scant een systeem dagelijks honderden financiële bronnen en levert een gestructureerd overzicht op, in plaats van dat het team handmatig zoekt.
Alle drie draaien op hetzelfde fundament. De vier lagen bouw je één keer.
Waar RAG geen oplossing voor is
RAG haalt op wat er staat. Het maakt niets waar dat niet in je documenten zit.
Is je documentatie verouderd, tegenstrijdig of onvindbaar, dan legt RAG dat pijnlijk bloot in plaats van het op te lossen. Dat is op zichzelf waardevol, maar het is geen kortere weg langs het opschonen.
RAG rekent ook niet. Voor berekeningen, aggregaties en vragen over grote hoeveelheden gestructureerde data is een databasequery de juiste aanpak, eventueel door het model gegenereerd. Vraag een RAG-systeem hoeveel offertes er vorig kwartaal uitgingen en het gokt.
En RAG neemt geen beslissingen. Het levert onderbouwing; de afweging blijft een menselijke.