Generatieve AI is in korte tijd uitgegroeid tot een vaste waarde in tal van bedrijven. Maar wat als je AI niet de juiste info kan aanreiken? Katy Fokou en Bert Vanhalst van Smals Research geven uitleg in een webinar.
Chatbots, interne assistenten en automatische documentanalyse zijn al even geen toekomstmuziek meer. Toch botsen veel teams snel op een probleem: grote taalmodellen (LLM’s) beschikken niet over de actuele of bedrijfsspecifieke data die nodig zijn om echt waardevolle antwoorden te genereren.
Hier komt Retrieval-Augmented Generation, of RAG, in beeld. AI-specialisten van Smals bespraken onlangs tijdens een webinar wat RAG is, waarom het zo populair is geworden, welke keuzes cruciaal zijn bij de implementatie, waar de grootste valkuilen liggen en welke praktische lessen je kan meenemen.
Wat is RAG en waarom is het zo populair?
RAG staat voor Retrieval-Augmented Generation. Het is een architectuur waarbij een taalmodel niet alleen vertrouwt op zijn vooraf getrainde kennis, maar ook relevante informatie ophaalt uit externe databronnen. Die opgehaalde info wordt toegevoegd aan de prompt, zodat het model een antwoord kan genereren dat gebaseerd is op actuele en bedrijfsspecifieke data.
In de praktijk verloopt het proces in drie stappen: data-input, retrieval en generatie. Eerst worden documenten, webpagina’s, transcripten of databases via data-ingestie verzameld en vervolgens opgeschoond en opgesplitst in kleinere tekstfragmenten of chunks. Dat is nodig om de kosten laag te houden. Die chunks worden omgezet naar vectoren en opgeslagen in een vectorstore. Daarna zoekt het systeem bij elke gebruikersvraag naar de meest relevante stukken informatie, met behulp van vector search. Tot slot gebruikt het taalmodel deze context om een correct antwoord te genereren.
De populariteit van RAG is eenvoudig te verklaren. De belangrijkste reden om een RAG te implementeren is om betrouwbare en gecontroleerde bronnen te gebruiken om een vraag te beantwoorden. Toch kunnen gegevens zelfs met een RAG naar een extern model verstuurd worden. Als er gevoelige gegevens zijn, wordt RAG uitgevoerd met een model dat lokaal draait en niet in de cloud. Met RAG kunnen ze hun bestaande kennis hergebruiken, antwoorden up-to-date houden en tegelijk transparantie creëren door bronnen mee te geven.
Met Retrieval Augmented Generation kan een taalmodel antwoorden genereren die gebaseerd zijn op actuele en bedrijfsspecifieke data.
Belangrijke ontwerpkeuzes: prompts en modellen
Hoewel het lijkt op een gemakkelijk concept, vraagt een goede RAG de juiste technische en inhoudelijke keuzes.
- Belang van goede prompts
De prompt is de stap tussen retrieval en generatie. Het is niet voldoende om enkel een vraag en een paar tekstfragmenten door te geven. Een goede prompt bevat duidelijke instructies over wat het model wel en niet mag doen. Zo kan je zeggen of het model zich moet beperken tot de aangeleverde info, aangeven wanneer informatie ontbreekt, een bepaalde schrijfstijl hanteren en het antwoord op een vaste manier structureren.
Ook het specificeren van het outputformaat is belangrijk. Moet het antwoord in één alinea staan? Moeten bronnen expliciet vermeld worden? Is er een tabel nodig? Hoe meer details, hoe beter controleerbaar en consistenter de output zal zijn.
- De juiste LLM kiezen
Niet elk taalmodel presteert even goed in een RAG-context. In het webinar van Smals Research werden verschillende modellen zoals GPT-4o, GPT-5, Mistral Large, Claude Sonnet 3.7 en Gemini 2.5 Flash geëvalueerd op criteria zoals nauwkeurigheid, latency, kostprijs en antwoordkwaliteit. Gemini en Claude scoren beter op complexe vragen, maar zijn ook duurder en trager. Kleinere of snellere modellen zijn vaak voldoende voor eenvoudige FAQ-toepassingen.
Daarnaast speelt privacy een rol. Open-source modellen bieden meer controle over data, maar hebben een eigen infrastructuur en extra beveiligingsmaatregelen nodig. Commerciële modellen zijn eenvoudiger te integreren, maar brengen afhankelijkheid en kosten met zich mee. De “beste” keuze hangt dus sterk af van de use case.
Retrieval: onderschatte succesfactor
Een veelgemaakte fout is om te focussen op het taalmodel, terwijl retrieval minstens even belangrijk is. Als de juiste informatie niet wordt opgehaald, kan het model ook geen correct antwoord genereren.
- Keyword search, semantisch of hybride?
Er bestaan verschillende zoekstrategieën. Klassieke keyword search werkt goed voor exacte termen, maar niet bij synoniemen of variaties. Semantisch zoeken maakt gebruik van vector embeddings om betekenis te vergelijken. In de praktijk levert een hybride aanpak, dus een combinatie van de twee, vaak de beste resultaten op.
- Precision of recall?
Bij retrieval draait het om de balans tussen precision (hoeveel opgehaalde stukken relevant zijn) en recall (hoeveel relevante stukken daadwerkelijk gevonden worden). Voor RAG is recall meestal belangrijker: ontbrekende cruciale informatie geeft een minder correct antwoord en meer extra irrelevante tekst, die het taalmodel vaak kan negeren.
- Reranking en filtering
Om de kwaliteit verder te verhogen, kunnen resultaten opnieuw gerangschikt worden met gespecialiseerde rerankingmodellen. Ook metadatafilters, drempelwaarden en queryherformulering zorgen voor betere resultaten. Dit vraagt wel extra rekenkracht en engineeringwerk.
lees ook
RAG in de praktijk: van belofte tot realiteit
Valkuilen: waar gaat het vaak mis?
Uiteraard zijn er ook vaakvoorkomende valkuilen bij het gebruik van RAG.
- Evaluatie is complex
Het evalueren van een RAG-systeem blijkt moeilijker dan verwacht. Antwoorden zijn niet-deterministisch: er kunnen verschillende juiste antwoorden zijn op dezelfde vraag en dan is de kwaliteit subjectief. Is een antwoord goed omdat het volledig is, of omdat het beknopt is?
Om te evalueren worden er twee categorieën van metrics gebruikt: metrieken met referentie – waarbij de gegenereerde output wordt vergeleken met een vooraf bepaalde referentie-output of referentiecontext – en metrieken zonder dergelijke referentie. Daarin wordt gekeken of het LLM gehallucineerd heeft en hoe accuraat het antwoord is op basis van de gegeven info.
Automatische evaluatiesystemen, waarbij een taalmodel de gegenereerde output beoordeelt (“LLM-as-judge”), geven schaalbaarheid, maar komen niet altijd overeen met menselijke beoordelingen. Daarom blijft menselijke evaluatie onmisbaar, zeker bij kritieke toepassingen.
- Guardrails zijn noodzakelijk, maar niet waterdicht
Guardrails moeten voorkomen dat een systeem ongewenste of schadelijke output produceert. Denk aan privacy-inbreuken, hallucinaties, ongepaste taal of off-topic vragen. Deze beveiligingslagen kunnen op verschillende niveaus worden toegepast: bij input, in de prompt (instructies), via regelgebaseerde filters of met aparte AI-classifiers. Toch geven guardrails geen volledige garantie. Prompt-injecties, creatieve omzeilingen en nieuwe aanvalspatronen blijven een risico. Continue monitoring en iteratieve verbetering zijn daarom essentieel.
- RAG is geen one-size-fits-all oplossing
Een van de belangrijkste lessen uit het webinar is dat RAG altijd afgestemd moet worden op jouw noden. Een interne zoekassistent heeft andere vereisten dan een publieke chatbot. Ook sectoren met hoge nauwkeurigheidseisen, zoals medische of juridische toepassingen, vragen extra voorzichtigheid, gespecialiseerde modellen en een menselijke tussenkomst.
lees ook
AI-adoptie neemt sneller toe dan bewustzijn over veiligheid
Praktische takeaways: zo begin je zelf met RAG
Wie met RAG aan de slag wil, kan een aantal concrete richtlijnen volgen.
- Begin bij de data
De kwaliteit van je data bepaalt rechtstreeks de kwaliteit van de output. Het is belangrijk dat je weet welke data je gebruikt om inzicht te krijgen in structuur, volledigheid en consistentie. Besteed aandacht aan opschoning, deduplicatie en het verwijderen van gevoelige informatie. “Garbage in, garbage out” blijft waar.
- Optimaliseer iteratief
Een RAG-systeem bouw je niet in één keer perfect. Optimalisatie is een iteratief proces waarbij je retrieval, chunks, prompts en evaluatie continu aanpast. Kleine aanpassingen kunnen een groot effect hebben op de eindkwaliteit.
- Stem nauwkeurigheid af op de use case
Niet elke toepassing moet even betrouwbaar zijn. Voor een interne researchtool kan een conceptueel correct antwoord volstaan, terwijl een chatbot bijna foutloos moet zijn. Bepaal op voorhand wat de impact is van een fout antwoord en pas je architectuur daarop aan.
- Combineer mens en machine
Automatische evaluatie en guardrails zijn nuttig, maar menselijke controle blijft cruciaal. Zeker bij gevoelige toepassingen is een hybride aanpak met menselijke feedback en supervisie sterk aan te raden.
Conclusie
RAG is nuttig om generatieve AI te gebruiken met eigen data en zo relevantere antwoorden te genereren, maar toch is het geen magische oplossing. Succes hangt af van datakwaliteit, goede retrievalstrategieën, doordacht promptontwerp en realistische verwachtingen.
Bedrijven die met RAG willen starten, kunnen best klein beginnen, experimenteren met beperkte gebruikersgroepen en het systeem stap voor stap verfijnen.