RAG laat een AI antwoorden op basis van jouw eigen documenten in plaats van een gok. In gewone taal: hoe het werkt, wat je nodig hebt, waar het misgaat en wat je er als MKB realistisch van mag verwachten.
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. In deze gids leg ik in gewone taal uit wat RAG is, wat je ervoor nodig hebt, waar het misgaat, en wat je er als MKB realistisch van mag verwachten.
Wat RAG eigenlijk is, in gewone taal
Een taalmodel zoals de modellen achter ChatGPT is in de kern een enorme tekstvoorspeller. Het is getraind op heel veel tekst en is daardoor goed in vloeiend antwoorden. Maar het weet niets van jouw prijslijst, jouw handleidingen of jouw interne afspraken. En als je het iets vraagt 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 simpele truc die in de naam verstopt zit. Het bestaat uit twee stappen:
- 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.
- 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 ervoor 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. Wat je maar relevant vindt. Dit is meteen het belangrijkste onderdeel, en daar kom ik later op terug. De korte versie: rommel erin betekent rommel eruit.
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.
Hoe het in de praktijk werkt
In de voorbereiding hak je je bronnen in behapbare stukken ("chunks"), maak je van elk stuk een embedding en zet je die in de vectordatabase. Dat doe je één keer, en daarna telkens als er documentatie bijkomt of verandert. Daarna gebeurt bij elke vraag binnen een seconde of twee hetzelfde: de vraag wordt ook een embedding, het systeem zoekt de best passende stukken op, en die gaan samen met de vraag naar het model.
Goede systemen vermelden er ook 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.
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, dat bepaalt het succes meer dan welke fancy techniek dan ook. Ik zeg dit expres scherp: 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 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.
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. 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. Wat kun je redelijkerwijs verwachten?
RAG is uitstekend voor vragen waar het antwoord ergens in jouw documenten staat. Denk aan 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, en die tijd is meetbaar.
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: een fatsoenlijke RAG-opzet is geen weekendproject, maar ook geen jarenlang traject. Het echte werk zit niet in de techniek, dat patroon is inmiddels uitgekristalliseerd. 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. Voor een simpele, niet-gevoelige toepassing ("een FAQ-bot op onze openbare handleiding") kan dat prima volstaan. Begin daar gerust mee als de inzet laag is.
Maatwerk loont zodra het serieus wordt: als je data gevoelig is en de EU niet mag verlaten, als toegangsrechten per gebruiker moeten kloppen, als de chatbot moet samenwerken met je bestaande systemen, of als je gewoon eigenaar wilt zijn van wat je bouwt in plaats van afhankelijk van een leverancier die morgen de prijs verdubbelt. Dan wil je een opzet die op jouw infrastructuur draait en meegroeit met je bedrijf.
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. 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.
