Wat is RAG? Antwoorden uit je eigen documenten

Je denkt waarschijnlijk dat je een AI opnieuw moet trainen om hem jouw documenten te laten kennen. Of net het omgekeerde: dat de bot bij elke vraag je hele kennisbank van voor naar achter doorleest. Geen van beide klopt. Wat er echt gebeurt is simpeler en veel bruikbaarder: het systeem zoekt vlak voor je vraag de paar relevante bladzijden op, legt die naast je vraag, en het model antwoordt daaruit. De gewichten van het model veranderen niet, en het leest nooit alles.

Neem een concreet geval. Je vraagt de bedrijfsbot: "Wat is ons beleid voor ouderschapsverlof?" Het onderliggende model, GPT of Claude, kent jouw interne HR-map niet. Zonder hulp weet het het niet, of het verzint een plausibel klinkend antwoord. Nu met de opzoek-stap erbij: het systeem pakt uit je HR-documenten de paar stukken die het dichtst bij je vraag liggen, vindt de verlof-paragraaf, plakt die in de prompt, en het model antwoordt uit je echte beleidstekst, met een verwijzing naar het bronbestand. Zelfde model, nu gegrond in jouw kennis.

Voor je hier een naam op plakt: kies zelf. Je wilt dat die bot betrouwbaar antwoordt uit je actuele HR-documenten, en morgen uit de bijgewerkte versie. Welke aanpak werkt?

De middelste optie, opzoeken en meegeven, is de enige die met "actueel" en "morgen bijgewerkt" overweg kan. Dat is RAG. Kijk wat er stap voor stap gebeurt zodra je vraag binnenkomt.

RAG staat voor Retrieval-Augmented Generation. Het is een techniek waarbij een taalmodel zijn antwoord baseert op tekst die er vlak voor je vraag bij wordt gezocht. Bij je vraag haalt het systeem de meest relevante stukken uit een externe bron, jouw documenten, en plakt die in de prompt; het model genereert het antwoord uit die aangereikte tekst. De gewichten van het model veranderen niet. De naam en het idee komen uit een paper van Lewis en collega's uit 2020, die een taalmodel koppelden aan een doorzoekbare index.

De pijplijn heeft drie stappen, en je ziet ze terug in het diagram. Retrieve: je vraag wordt omgezet in een vector en het systeem zoekt de dichtstbijzijnde stukken. Augment: die stukken worden in de prompt geplakt als extra context. Generate: het model voorspelt daaruit zijn antwoord.

Waarom knipt zo'n systeem je documenten eerst in stukjes?

Een model kan niet je hele archief in één prompt proppen, en dat zou het ook niet moeten willen. Daarom worden je documenten vooraf in stukken geknipt, chunks, en wordt elk stuk apart omgezet in een vector die betekenis vastlegt als een plek in een ruimte. Die vectoren gaan in een vector-database. Bij je vraag wordt alleen jouw vraag geëmbed, en het systeem zoekt de dichtstbijzijnde buren: nearest-neighbor-zoeken over al die opgeslagen stukken. Niet je hele kennisbank doorlezen dus, maar razendsnel de paar dichtstbijzijnde stukken vinden.

Die gevonden stukken zijn daarna gewoon tekst die in het contextvenster van het model meegaat, als tokens vóór je vraag. Hoe je knipt doet er wel toe. Knip je te grof, dan sleep je ruis en overbodige tokens mee; knip je te fijn, dan mist een stuk de context om te snappen waar het over gaat. Dat afstellen is het echte werk als je zoiets zelf bouwt, en het is precies waar de praktische keuzes bij een RAG-chatbot op je eigen data over gaan.

Dit is ook meteen waarom RAG vaak het juiste gereedschap is en fine-tunen niet. Fine-tunen stuurt vooral hoe een model klinkt en zich gedraagt, terwijl RAG externe data in de werkstroom van het model brengt. Voor stijl, toon en vorm past fine-tunen; voor feiten die veranderen en die je wilt kunnen bijwerken en onderbouwen, past RAG. Geen absolute wet, en serieuze systemen combineren de twee gerust, maar dat is de kern van het onderscheid.

Waarom zit een bot met RAG er soms alsnog naast?

Omdat grounding hallucinaties terugdringt, niet wegneemt. Door het model de echte brontekst te geven kan het citeren in plaats van gokken, en je kunt de bron tonen zodat de lezer controleert. In een test op het genereren van workflows liep het aandeel verzonnen stappen en tabellen op tot 21 procent zonder retrieval, en zakte het met RAG naar onder de 7,5 procent voor stappen. Fors minder, maar niet nul: die rest blijft staan.

Want het model heeft geen onafhankelijke lijn naar de waarheid; het werkt met wat je meegeeft. Haalt de retrieval het verkeerde stuk op, of staat het antwoord simpelweg niet in je documenten, dan kan het model alsnog een plausibele fout produceren, precies het mechanisme achter een hallucinatie. En zelfs als het juiste stuk wél is opgehaald, is het nog niet gered: taalmodellen gebruiken informatie in het midden van een lange prompt aantoonbaar slechter dan aan het begin of het eind. Slechte of ontbrekende bronnen geven slechte antwoorden; goede retrieval over schone documenten geeft goede.

Haal het even terug voor je verder gaat.

Dat is de hele truc: je maakt het model niet slimmer en je stopt er niet je halve bedrijf in. Je zet er een goede opzoek-stap voor, zodat het op het moment van de vraag de juiste bladzijde in handen heeft. Zodra je RAG zo bekijkt, snap je meteen waarom zo'n bot soms feilloos jouw beleid citeert met bron erbij, en soms zelfverzekerd het verkeerde stuk navertelt.