AI-afkortingen voor gevorderden: RAG, fine-tuning en meer — Sean Vermond

Je hebt de basis. Je weet wat een LLM is, je snapt het verschil tussen AI en machine learning, en als iemand "prompt" zegt denk je niet meer aan een theatervoorstelling. Goed bezig. Maar dan zit je op LinkedIn en iemand post: "Onze RAG-pipeline met fine-tuned embeddings en RLHF-guardrails is live." En je denkt: ik was net zo lekker bezig.

Herkenbaar? Dan is dit voor jou. In het vorige deel van deze serie behandelden we vijftien AI-termen die iedereen moet kennen. Vandaag gaan we een laag dieper. De termen die worden gebruikt door teams die daadwerkelijk AI-systemen bouwen en implementeren. En ik kan je vertellen: als iemand die dagelijks dit soort systemen ontwerpt, zijn dit de concepten waar ik het vaakst mee werk.

En het toevallige aan de timing: vandaag, 1 augustus 2024, treedt de EU AI Act officieel in werking. De eerste alomvattende AI-wetgeving ter wereld. Meta heeft net Llama 3.1 uitgebracht — een open-source model dat concurreert met de beste gesloten modellen. De AI-wereld professionaliseert in rap tempo. En daarmee wordt de taal die erbij hoort steeds relevanter.

Geen paniek. Ik ga je door elk concept heen loodsen met uitleg die je echt snapt. Met metaforen. Met voorbeelden. Alsof we aan de bar zitten en ik het je uitleg op een bierviltje.

RAG: Retrieval Augmented Generation

Laten we beginnen met de term die je het vaakst tegenkomt en het minst begrijpt: RAG. Het staat voor Retrieval Augmented Generation — ophalen-versterkte generatie, als je het zou vertalen (maar dat doet niemand).

RAG is voor mij de meest praktische AI-architectuur die er op dit moment bestaat. Ik gebruik het dagelijks in mijn werk als digital architect, en ik zal je uitleggen waarom.

Het probleem dat RAG oplost

Een LLM weet veel, maar niet alles. En wat het weet, is bevroren in de tijd. GPT-4 is getraind op data tot een bepaald moment. Het weet niet wat er gisteren in je bedrijf is gebeurd. Het kent je interne documenten niet. Het heeft je productcatalogus niet gelezen.

Stel: je wilt een AI-assistent bouwen voor je klantenservice. Die moet vragen beantwoorden over jouw producten, jouw prijzen, jouw retourbeleid. Een standaard LLM kan dat niet — het kent je bedrijf niet. Je zou het model kunnen fine-tunen (daarover zo meer), maar dat is duur, traag en inflexibel. Elke keer dat je een product toevoegt, zou je opnieuw moeten trainen.

RAG lost dit eleganter op.

Hoe RAG werkt

Bij RAG geef je het model toegang tot een externe kennisbank. Wanneer iemand een vraag stelt, gebeuren er drie dingen:

Retrieval (ophalen): Het systeem doorzoekt je kennisbank en haalt de meest relevante documenten op.
Augmentation (versterken): Die documenten worden meegegeven aan het LLM als context.
Generation (genereren): Het LLM genereert een antwoord op basis van zowel zijn eigen kennis als de opgehaalde documenten.

De metafoor: het open-boek examen. Een LLM zonder RAG is een student die een examen maakt uit zijn hoofd. Alles wat hij weet, moet al in zijn brein zitten. Een LLM met RAG is een student die een open-boek examen maakt. Hij heeft nog steeds kennis nodig om de vraag te begrijpen en een goed antwoord te formuleren — maar hij mag zijn boeken erbij pakken voor de details.

Het mooie aan RAG is dat je de kennisbank kunt updaten zonder het model opnieuw te trainen. Nieuw product? Voeg het document toe. Gewijzigd beleid? Update het bestand. Het model pikt het automatisch op bij de volgende vraag.

Waarom RAG mijn favoriete architectuur is

RAG is de afgelopen maanden geexplodeerd in populariteit. En terecht. Vanuit mijn perspectief als architect is RAG om drie redenen briljant:

Het is modulair. Je kunt de kennisbank updaten zonder het model aan te raken. Je kunt het model vervangen zonder je kennisbank opnieuw te bouwen. Elk onderdeel is onafhankelijk. Als je ooit een systeem hebt gebouwd dat zo in elkaar zit dat je niks kunt aanpassen zonder dat alles breekt — dan snap je waarom dit zo waardevol is.

Het is controleerbaar. Bij RAG kun je precies zien welke documenten het model heeft geraadpleegd voor zijn antwoord. Dat maakt debugging mogelijk. Als het model onzin uitkraamt, kun je traceren waarom. Bij een fine-tuned model zit de kennis opgesloten in de gewichten — een black box. Bij RAG kun je de bronnen controleren.

Het is betaalbaar. Fine-tuning kost duizenden euro's en weken aan GPU-tijd. Een RAG-pipeline kun je in een middag opzetten met een vector database en een paar API-calls. Voor het MKB is dat het verschil tussen "misschien volgend jaar" en "laten we het vandaag proberen."

Vrijwel elk AI-project dat ik tegenkom — van interne kennisbanken tot klantenservice-bots tot documentanalyse — gebruikt een vorm van RAG. Het is niet perfect. De kwaliteit hangt af van hoe goed je documenten zijn gestructureerd en hoe relevant de ophaalresultaten zijn. Maar als basisarchitectuur is het de gouden standaard.

Fine-tuning: de specialisatie-opleiding

We hadden het in het vorige artikel kort over fine-tuning. Tijd om dieper te gaan.

Wat fine-tuning echt is

Fine-tuning is het proces waarbij je een bestaand, voorgetraind model verder traint op jouw specifieke data. Je neemt een generalist — een LLM dat overal een beetje van weet — en maakt er een specialist van.

Het verschil met RAG is fundamenteel. Bij RAG geef je het model extra informatie op het moment dat het een vraag beantwoordt. Bij fine-tuning verander je het model zelf. Je past de gewichten aan — de miljoenen parameters die bepalen hoe het model reageert.

De metafoor: de specialisatie-opleiding. RAG is alsof een huisarts tijdens een consult even in een handboek kijkt. Fine-tuning is alsof die huisarts drie jaar cardiologie gaat studeren. Na de opleiding hoeft hij niet meer in het boek te kijken — de kennis zit in zijn hoofd. Maar de opleiding kost tijd, geld en moeite.

Wanneer fine-tuning zinvol is

Fine-tuning is niet altijd de juiste keuze. Het is duur (je hebt rekenkracht nodig), het kost tijd, en je hebt een goede dataset nodig. Maar er zijn situaties waarin het de beste optie is:

Stijl en toon: Als je wilt dat het model consistent in een bepaalde stijl communiceert. Denk: een model dat altijd in jouw merkstem schrijft.
Domeinkennis: Als het model diepgaande expertise nodig heeft in een specifiek vakgebied. Medische AI, juridische AI, financiele AI.
Gedrag: Als je wilt dat het model zich op een bepaalde manier gedraagt — bepaalde dingen wel doet en andere niet.

In de praktijk zie je vaak een combinatie: een fine-tuned model dat ook RAG gebruikt. De specialist die nog steeds af en toe in het handboek kijkt. Dat is geen zwakte — dat is hoe de beste systemen werken.

Embeddings: de geheime taal van AI

Nu wordt het even abstract, maar hou vol — dit is een van de meest fundamentele concepten in moderne AI.

Wat embeddings zijn

Een embedding is een numerieke representatie van tekst (of een afbeelding, of geluid) in een hoog-dimensionale ruimte. Oké, dat klinkt als wiskundig gebrabbel. Laat me het anders zeggen.

Computers begrijpen geen woorden. Ze begrijpen getallen. Een embedding zet een woord, zin of document om in een reeks getallen — een vector — die de betekenis vastlegt. Het mooie is dat woorden met vergelijkbare betekenissen dicht bij elkaar komen te staan in die getallenruimte.

"Kat" en "poes" staan dicht bij elkaar. "Kat" en "financieel kwartaalrapport" staan ver uit elkaar. "Koning" min "man" plus "vrouw" geeft iets dat dicht bij "koningin" ligt. De wiskundige verhoudingen vangen semantische verhoudingen.

De metafoor: Stel je een enorme bibliotheek voor waar boeken niet op alfabet staan, maar op inhoud. Boeken over koken staan bij elkaar. Boeken over de Tweede Wereldoorlog staan bij elkaar. Een boek over de voedselrantsoenen in de Tweede Wereldoorlog staat ergens tussen die twee groepen in. Embeddings organiseren informatie op een vergelijkbare manier — niet op basis van welke letters er staan, maar op basis van wat het betekent.

Waarom embeddings belangrijk zijn

Embeddings zijn de stille motor achter RAG. Wanneer je een vraag stelt aan een RAG-systeem, wordt je vraag omgezet in een embedding. Vervolgens worden de documenten in je kennisbank vergeleken — niet op woorden, maar op betekenis. Dat is waarom een RAG-systeem "Wat is jullie teruggavebeleid?" kan matchen met een document getiteld "Retourprocedure en voorwaarden" — ook al komt het woord "teruggave" er niet in voor.

Zonder embeddings zou RAG niet werken. En zonder RAG zou de helft van de huidige AI-toepassingen niet bestaan. Ze zijn de onzichtbare lijm.

Hallucination: meer dan een termpje

We noemden hallucinaties in het vorige artikel, maar het verdient meer aandacht. Want naarmate je meer met AI werkt, wordt dit het concept waar je het vaakst mee te maken krijgt. Geloof me — ik heb genoeg situaties meegemaakt waarin een model met rotsvast vertrouwen compleet verzonnen informatie presenteerde.

Waarom modellen hallucineren

LLM's zijn gebouwd om de meest waarschijnlijke volgende reeks woorden te produceren. Niet de meest correcte — de meest waarschijnlijke. Dat verschil is cruciaal. Als je vraagt "Wie schreef Romeo en Julia?" is het meest waarschijnlijke antwoord ook het correcte antwoord: Shakespeare. Maar als je vraagt naar iets minder bekend, kan het model met evenveel zelfvertrouwen iets verzinnen.

Het model weet niet dat het iets niet weet. Het heeft geen twijfelknop. Het produceert altijd een antwoord, want dat is waarvoor het is ontworpen.

Hoe je ermee omgaat

Er zijn meerdere strategieen om hallucinaties te beperken:

RAG: Door het model toegang te geven tot bronnen, kan het feiten verifieren.
Temperature verlagen: De "temperature" parameter bepaalt hoe creatief een model is. Lager = conservatiever = minder hallucinaties (maar ook minder creatief).
Prompt engineering: Door expliciet te vragen "als je het niet weet, zeg dat dan" kun je hallucinaties verminderen.
Menselijke verificatie: Bij kritische toepassingen altijd een mens laten meekijken.

Hallucinaties zullen nooit helemaal verdwijnen. Het is een eigenschap van hoe deze modellen werken, geen bug die je kunt fixen. Maar je kunt er wel mee leren omgaan. Mijn vuistregel: hoe hoger de stakes, hoe strenger je controleert. Een AI die brainstormideeën genereert? Prima, hallucineer er op los. Een AI die juridisch advies geeft? Dan wil je elke bewering kunnen verifieren.

Guardrails: de vangrails van AI

Wat guardrails zijn

Guardrails zijn de regels en beperkingen die je aan een AI-systeem oplegt om ongewenst gedrag te voorkomen. Ze bepalen wat een model wel en niet mag doen, zeggen of genereren.

Denk aan: een klantenservice-bot die geen medisch advies mag geven. Een schrijfassistent die geen haatdragende content mag produceren. Een financieel model dat geen beleggingsadvies mag uitdelen zonder disclaimer.

De metafoor: Guardrails zijn letterlijk vangrails op een snelweg. Ze zijn er niet om je te remmen, maar om te voorkomen dat je van de weg raakt. De auto (het AI-model) heeft vrijheid om te rijden, maar binnen veilige grenzen.

Waarom guardrails nu zo belangrijk zijn

Met de EU AI Act die vandaag ingaat, worden guardrails niet langer optioneel. De wet eist dat AI-systemen in bepaalde categorieen aantoonbare veiligheidsmaatregelen hebben. Hoe hoger het risico van de toepassing, hoe strenger de eisen.

Dit is niet alleen een juridische kwestie. Het is ook een praktische. Een AI-systeem zonder guardrails in een bedrijfsomgeving is als een stagiair zonder begeleiding: meestal gaat het goed, maar als het misgaat, gaat het spectaculair mis. Ik heb het van dichtbij gezien — een chatbot die plotseling kortingen begon te beloven die niet bestonden. Guardrails hadden dat voorkomen.

RLHF: Reinforcement Learning from Human Feedback

De laatste afkorting, en misschien de meest fascinerende.

Wat RLHF is

RLHF staat voor Reinforcement Learning from Human Feedback. Het is de techniek die ervoor zorgt dat LLM's nuttige, veilige en behulpzame antwoorden geven in plaats van alleen maar statistisch waarschijnlijke tekst.

Het werkt zo: na de initiele training krijgt het model twee mogelijke antwoorden op dezelfde vraag. Menselijke beoordelaars geven aan welk antwoord beter is. Op basis van duizenden van dit soort vergelijkingen leert het model wat mensen "goed" en "behulpzaam" vinden.

De metafoor: RLHF is als een mentor die over je schouder meekijkt. Je schrijft twee versies van een email. De mentor zegt: "Die tweede is beter — directer, vriendelijker." Na honderd van dit soort feedbackmomenten weet je vanzelf hoe een goede email eruitziet. RLHF doet hetzelfde voor AI-modellen.

Waarom RLHF ertoe doet

Zonder RLHF zou een LLM je vragen beantwoorden op de manier die het meest lijkt op de tekst waarop het is getraind. Dat kan giftig zijn, onbehulpzaam, of ronduit gevaarlijk. RLHF is de reden dat modellen als Claude en ChatGPT beleefd zijn, gevaarlijke verzoeken weigeren, en proberen echt behulpzaam te zijn. Het is de opvoeding van het model.

Vector database: de opslagplek voor embeddings

Een term die ik niet kan overslaan omdat hij hand in hand gaat met RAG en embeddings.

Wat een vector database is

Een vector database is een database die specifiek is ontworpen om embeddings op te slaan en er snel in te zoeken. Traditionele databases zoeken op exacte waarden: "Geef me alle klanten uit Amsterdam." Een vector database zoekt op gelijkenis: "Geef me alle documenten die qua betekenis lijken op deze vraag."

Bekende vector databases die je tegenkomt: Pinecone, Weaviate, Chroma, Qdrant. Ze zijn de ruggengraat van vrijwel elk RAG-systeem.

De metafoor: Een traditionele database is een archiefkast met gelabelde mappen. Je zoekt op het label. Een vector database is een bibliothecaris die je vraag hoort, nadenkt over wat je bedoelt, en dan de drie meest relevante boeken voor je ophaalt — ook al gebruikte je andere woorden dan de titel.

Hoe dit alles samenhangt

Laat me het hele plaatje schetsen met een voorbeeld.

Stel: je bouwt een AI-assistent voor een verzekeringsmaatschappij. Dit is hoe al deze concepten samenkomen:

Je begint met een LLM als basis — bijvoorbeeld Claude of Llama 3.1.
Je fine-tunet het model op verzekeringstaal en polisvoorwaarden, zodat het de toon en terminologie van de sector kent.
Je zet een RAG-systeem op: alle polissen, FAQ's en interne documenten worden omgezet in embeddings en opgeslagen in een vector database.
Wanneer een klant een vraag stelt, wordt die omgezet in een embedding, worden de relevantste documenten opgehaald, en genereert het model een antwoord.
Guardrails zorgen ervoor dat het model geen juridisch bindende beloftes doet of medisch advies geeft.
RLHF heeft ervoor gezorgd dat het model beleefd, behulpzaam en veilig communiceert.
En jij monitort op hallucinaties — want ook met al deze maatregelen kan het model nog steeds iets verzinnen.

Dat is de moderne AI-stack in actie. Niet een technologie, maar een samenspel van concepten die elkaar versterken. En als ik eerlijk ben: het is precies dit samenspel dat mijn werk als architect zo fascinerend maakt. Elk project is een puzzel waar deze stukken op een andere manier in elkaar vallen.

Wat je hiermee kunt

Je hoeft dit niet allemaal zelf te bouwen. Maar je moet het wel begrijpen. Want of je nu een AI-leverancier evalueert, een projectvoorstel beoordeelt, of gewoon wilt snappen wat er in de wereld om je heen gebeurt — deze termen zijn je kompas.

De AI-wereld beweegt snel. De EU AI Act verandert de spelregels. Open-source modellen als Llama 3.1 maken AI toegankelijker. RAG wordt standaard. En de bedrijven die het beste presteren, zijn niet per se de meest technische — het zijn de bedrijven die de juiste vragen stellen en de juiste architectuurbeslissingen nemen.

En dat begint met de taal spreken.

In het volgende deel van deze serie gaan we nog een laag dieper: de volledige AI tech stack uitgelegd. Van vector databases tot orchestration frameworks. Van data-infrastructuur tot de interface die je gebruiker ziet. Want als je eenmaal de termen kent, wil je weten hoe het in elkaar zit.

Dit is deel 7 van de serie "Reis door AI". Lees ook deel 6: 15 AI-termen die iedereen moet kennen als je de basis nog wilt opfrissen.