RAG of fine-tuning: bedrijfskennis in een taalmodel
Een taalmodel kent niet vanzelf de actuele regels, producten en werkwijzen van jouw organisatie. Na dit artikel weet je hoe RAG en fine-tuning bedrijfskennis aan een model koppelen, waar hun belangrijkste verschillen zitten en welke gevolgen ze hebben voor onderhoud en actualiteit.
RAG en fine-tuning geven bedrijfskennis op verschillende manieren aan een taalmodel
Een taalmodel leert tijdens training patronen uit grote hoeveelheden tekst. Daardoor kan het taal begrijpen en antwoorden formuleren, maar het weet niet automatisch wat er gisteren in een interne procedure is gewijzigd. RAG en fine-tuning zijn twee manieren om een model beter te laten aansluiten op een specifieke toepassing. Ze lossen echter verschillende problemen op. RAG haalt informatie op het moment van de vraag uit geselecteerde bronnen en geeft die tekst mee als context. Fine-tuning traint het model verder op voorbeelden, zodat het bepaalde patronen, taken of antwoordstijlen beter leert uitvoeren.
Dat onderscheid is praktisch belangrijk. Als een medewerker vraagt hoeveel dagen retourtermijn een product heeft, wil je waarschijnlijk een actueel antwoord uit de product- of beleidsinformatie. Als het model steeds in een vaste toon moet schrijven of een specifieke classificatie moet toepassen, kan training op voorbeelden geschikter zijn. RAG verandert doorgaans niet de gewichten van het basismodel; fine-tuning doet dat wel. Geen van beide maakt een model vanzelf foutloos. Een slecht vindbare bron blijft bij RAG buiten beeld, terwijl fine-tuning verouderde voorbeelden kan vastleggen. De keuze begint daarom niet bij de techniek, maar bij de vraag of je kennis wilt ophalen of gedrag wilt aanpassen.
Zo haalt RAG relevante bedrijfsinformatie op voor een antwoord
RAG staat voor retrieval augmented generation: generatie met ondersteuning van opgehaalde informatie. Eerst worden documenten verzameld, opgeschoond en in kleinere tekstfragmenten verdeeld. Die fragmenten worden omgezet in vectorrepresentaties, ook wel embeddings genoemd, en opgeslagen in een doorzoekbare index. Wanneer iemand een vraag stelt, zet het systeem die vraag op vergelijkbare wijze om. Vervolgens zoekt het naar fragmenten die inhoudelijk bij de vraag passen en geeft die mee aan het taalmodel. Het model maakt met die context een antwoord, eventueel met verwijzingen naar de gevonden bronnen.
De details van deze keten bepalen de kwaliteit. Een procedure van twintig pagina’s als één fragment opslaan maakt het lastig om precies het relevante onderdeel terug te vinden. Fragmenten die te klein zijn, verliezen juist context, bijvoorbeeld een uitzondering die in de volgende alinea staat. Ook metadata helpt: documenttype, datum, afdeling en productcategorie kunnen zoekresultaten verfijnen. Een hybride zoekmethode combineert vaak semantisch zoeken met zoekwoorden, zodat zowel begrippen als exacte artikelnummers gevonden worden. RAG is dus niet simpelweg documenten uploaden. Het vraagt om een doordachte ingestiepijplijn, een goede zoekindex en instructies die het model leren om ontbrekende informatie niet zelf aan te vullen.
Documentkwaliteit en toegangsrechten bepalen of RAG bruikbaar is
Een RAG-systeem kan alleen antwoorden op basis van informatie die het kan verwerken en terugvinden. In veel organisaties staan relevante gegevens verspreid over pdf’s, intranetten, ticketsystemen, productcatalogi en gedeelde mappen. Die bronnen kunnen dubbele versies, scans zonder tekstlaag, verouderde bestanden of tegenstrijdige instructies bevatten. Voor de indexering is daarom een inventaris nodig: welke bron is leidend, wie is eigenaar en hoe wordt duidelijk dat een document vervallen is? OCR kan scans leesbaar maken, maar fouten in tabellen, voetnoten of kolommen kunnen de betekenis veranderen.
Toegangsbeheer hoort eveneens bij de broninrichting. Als een gebruiker een document niet mag openen, mag RAG de inhoud daarvan ook niet alsnog in een antwoord prijsgeven. Dat vraagt om rechten die tijdens het ophalen worden gecontroleerd, niet alleen om een algemene belofte dat het model vertrouwelijk werkt. Metadata over afdelingen of gebruikersgroepen kan zoekresultaten filteren, maar moet synchroon blijven met de bronrechten. Een veelvoorkomende misser is een index opbouwen met een brede serviceaccount en vervolgens alle gevonden tekst aan iedere gebruiker tonen. Ook ontbrekende documenteigenaren veroorzaken beheerproblemen: niemand merkt dat een procedure verouderd is. RAG begint daarom met informatiebeheer; de AI-laag maakt bestaande bronproblemen zichtbaar, maar repareert ze niet vanzelf.
Retrieval testen voorkomt overtuigende antwoorden uit de verkeerde bron
Een taalmodel kan een vloeiend antwoord geven terwijl de opgehaalde passage niet relevant is. Daarom moet je RAG afzonderlijk testen op zoekkwaliteit en antwoordkwaliteit. Begin met echte vragen uit het werk, waaronder korte zoekopdrachten, synoniemen, typefouten en vragen die meerdere documenten combineren. Controleer per vraag of de juiste bronfragmenten in de eerste resultaten staan. Pas daarna beoordeel je of het model de informatie correct gebruikt, uitzonderingen noemt en geen details verzint. Een antwoord kan inhoudelijk plausibel zijn, maar toch een oude retourregeling of een verkeerd producttype beschrijven.
Bronverwijzingen helpen gebruikers controleren waar een antwoord vandaan komt, maar zijn geen bewijs van juistheid als ze naar een algemene pagina leiden. Meet daarom onder meer of de juiste passage wordt opgehaald, of het antwoord door die passage wordt ondersteund en hoe vaak het systeem terecht aangeeft onvoldoende informatie te hebben. Stel ook grenzen in: bij lage zoekzekerheid kan het systeem een verduidelijkende vraag stellen of de gebruiker naar een medewerker verwijzen. Een veelgemaakte fout is alleen een demonstratie met makkelijke vragen testen. In productie komen samengestelde vragen, ontbrekende gegevens en tegenstrijdige versies voor. Log daarom geanonimiseerde zoekopdrachten en fouten, en gebruik die om de fragmentindeling, filters en bronselectie gericht te verbeteren.
Fine-tuning leert antwoordgedrag, maar is geen actuele kennisbank
Bij fine-tuning krijgt een bestaand model extra training op voorbeelden van invoer en gewenste uitvoer. Die voorbeelden kunnen laten zien hoe een taak moet worden uitgevoerd, welke structuur het antwoord moet hebben of welke toon passend is. Denk aan het classificeren van klantvragen volgens een eigen categorie-indeling of het omzetten van productkenmerken naar een consistent tekstformat. Het model past daarbij interne parameters aan. De informatie zit niet opgeslagen als een doorzoekbaar document met een duidelijke bronverwijzing. Je kunt dus niet eenvoudig vragen welk trainingsvoorbeeld een specifiek antwoord heeft veroorzaakt.
Fine-tuning is minder geschikt als methode om een snel veranderende catalogus of personeelsregeling in het model te stoppen. Nieuwe feiten toevoegen vereist doorgaans een nieuwe trainingsrun en evaluatie, en zelfs dan is niet gegarandeerd dat het model die feiten betrouwbaar reproduceert. Veel trainingsvoorbeelden zijn nodig om gewenst gedrag consistent aan te leren; kleine of scheve datasets kunnen juist ongewenste patronen versterken. Kwaliteitscontrole vraagt om representatieve voorbeelden, heldere labels en een aparte testset die niet tijdens training is gebruikt. Ook privacy en gebruiksrechten van trainingsdata verdienen aandacht. Fine-tuning kan bovendien een model zelfverzekerder laten klinken zonder de feitelijke juistheid te verbeteren. Gebruik het daarom voor terugkerende gedragspatronen, niet als vervanging voor een actuele, controleerbare bron.
Kies RAG voor veranderlijke feiten en fine-tuning voor terugkerend gedrag
Een bruikbare keuze begint met het soort fout dat je wilt voorkomen. Moet het antwoord afhangen van prijzen, voorraad, beleid, productspecificaties of procedures die regelmatig wijzigen? Dan is informatie ophalen uit een beheerde bron meestal logischer. Een bron kan worden bijgewerkt zonder het taalmodel opnieuw te trainen, en het systeem kan tonen waar een antwoord op gebaseerd is. Moet het model juist telkens dezelfde taak op dezelfde manier uitvoeren, zoals velden extraheren, labels toekennen of tekst volgens vaste conventies herschrijven? Dan kan fine-tuning helpen, mits je genoeg goede voorbeelden hebt en gedrag ook met prompts of reguliere software niet eenvoudiger kunt sturen.
De praktische vergelijking omvat meer dan nauwkeurigheid. RAG vereist documentintegraties, indexbeheer, toegangsfilters en periodieke evaluatie van zoekresultaten. Fine-tuning vraagt om trainingsdata, modelversies, hertraining en tests op regressies. Voor een kleine, stabiele taak kan fine-tuning beheersbaar zijn; voor duizenden vaak gewijzigde feiten wordt het lastig om alle kennis actueel te houden. Andersom is RAG niet automatisch de goedkoopste of eenvoudigste route wanneer bronnen versnipperd zijn en slecht onderhouden worden. Maak een proef met echte gebruiksvragen en vergelijk niet alleen voorbeeldantwoorden, maar ook fouttypen, beheerlast en gevolgen van een fout. Een chatbot voor beleid heeft andere eisen dan een systeem dat productteksten genereert. De tolerantie voor veroudering, controleerbaarheid en foutieve uitvoer moet expliciet meewegen.
Actualiteit en onderhoud vragen bij beide methoden om versiebeheer
RAG lijkt actueel zodra documenten worden aangepast, maar de wijziging moet nog door de hele keten lopen. Een bron wordt bijvoorbeeld bijgewerkt, daarna moet de synchronisatie de nieuwe versie ophalen, oude fragmenten verwijderen of vervangen en de zoekindex opnieuw opbouwen. Als dat proces faalt, kan het systeem oude én nieuwe passages vinden. Leg daarom vast hoe vaak iedere bron wordt bijgewerkt, hoe verwijderingen worden verwerkt en hoe je controleert dat de index overeenkomt met het bronsysteem. Een documentdatum alleen is niet genoeg: de index kan achterlopen of een verouderde kopie bevatten.
Bij fine-tuning is onderhoud anders georganiseerd. Een nieuw trainingsbestand leidt niet vanzelf tot nieuwe modelkennis; er is een hertrainingsbesluit, een nieuwe modelversie en evaluatie nodig. Als je vaak kleine wijzigingen doorvoert, kan de versiehistorie snel ingewikkeld worden. Bewaar daarom welke dataset, instellingen en modelversie bij een release horen, en test of verbeteringen geen eerdere taken verslechteren. Ook prompts, retrieval-instellingen en bronfilters verdienen versiebeheer, want aanpassingen daaraan kunnen antwoorden veranderen zonder dat het model zelf verandert. Een realistisch beheerplan benoemt eigenaarschap, updatefrequentie, foutmeldingen en terugvalmogelijkheden. Zo kan een team bij problemen teruggaan naar een bekende versie in plaats van ongericht documenten of trainingsvoorbeelden te wijzigen.
Een hybride AI-oplossing scheidt actuele feiten van vaste uitvoerregels
RAG en fine-tuning sluiten elkaar niet uit. Een systeem kan opgehaalde informatie gebruiken voor actuele feiten en daarnaast een model bevatten dat op een bepaalde taak of uitvoerstijl is afgestemd. Een productassistent kan bijvoorbeeld productkenmerken en voorraad uit actuele bronnen ophalen, terwijl fine-tuning helpt om kenmerken consequent om te zetten naar korte, toegankelijke antwoorden. De verdeling moet helder zijn: bedrijfsbronnen leveren feiten, terwijl de modelinstructies en eventuele fine-tuning bepalen hoe die feiten worden verwerkt. Als die rollen door elkaar lopen, kan het model een verouderd trainingspatroon laten prevaleren boven een actuele bron.
Hybride architecturen voegen ook meer onderdelen toe om te testen en te beheren. Je moet controleren of de retrieval passende informatie aanlevert, of het aangepaste gedrag die informatie niet verdraait en of het antwoord binnen de toegangsrechten blijft. Test bijvoorbeeld een gewijzigde beleidsregel, een vraag waarvoor geen bron bestaat en een bron die elkaar tegenspreekt. Bepaal vooraf welke bron voorrang krijgt en wanneer het systeem moet weigeren of doorverwijzen. Bij risicovolle processen kan een medewerker het antwoord goedkeuren voordat een actie wordt uitgevoerd. Houd bovendien rekening met de kosten en vertraging van zoekstappen, modelaanroepen en evaluatie. Een hybride aanpak is zinvol wanneer die aantoonbaar gedrag verbetert, niet omdat het combineren van technieken op zichzelf een doel is.
Veelgestelde vragen
Wanneer is prompt engineering voldoende en is fine-tuning niet nodig?
Prompt engineering is vaak voldoende wanneer je het gewenste gedrag met duidelijke instructies en enkele voorbeelden betrouwbaar kunt sturen. Begin met een representatieve set echte taken en test verschillende prompts op dezelfde gevallen. Let daarbij op consistentie, uitzonderingen en ongewenste antwoorden, niet alleen op een paar geslaagde voorbeelden.
Fine-tuning kan pas het overwegen waard zijn als instructies onvoldoende consistent werken en je genoeg kwalitatieve voorbeelden hebt om het gedrag gericht te verbeteren. Houd ook rekening met onderhoud: een prompt aanpassen is doorgaans eenvoudiger dan trainingsdata voorbereiden, een modelversie maken en opnieuw evalueren.
Kan RAG actuele prijzen en voorraad uit een bedrijfsdatabase ophalen?
Ja, RAG kan actuele prijzen en voorraad ophalen als het systeem veilig verbinding maakt met een database of API die deze gegevens aanbiedt. Voor informatie die vaak verandert, is het meestal verstandig de gegevens tijdens de vraag op te halen in plaats van te vertrouwen op een periodiek bijgewerkte documentindex.
De koppeling moet onder meer bepalen welke velden mogen worden opgevraagd, hoe gebruikersrechten worden toegepast en wat er gebeurt als de bron niet bereikbaar is. Laat het antwoord bij voorkeur de relevante productvariant en het moment van ophalen vermelden. Zo wordt duidelijk dat voorraad of prijs kan veranderen en voorkom je dat een oud resultaat als actueel wordt gepresenteerd.
Hoe voorkom je prompt injection via documenten in een RAG-systeem?
Je beperkt prompt injection door opgehaalde documenten als onbetrouwbare gegevens te behandelen, niet als instructies die het model moet volgen. Een document kan bijvoorbeeld tekst bevatten die het model probeert aan te zetten om regels te negeren of vertrouwelijke informatie te delen. Instrueer het model daarom expliciet om broninhoud alleen te gebruiken als informatie voor het antwoord.
Beperk daarnaast welke bronnen mogen worden geïndexeerd, controleer verdachte inhoud en geef het model geen onnodige bevoegdheden om acties uit te voeren. Test met documenten die zulke instructies bevatten en controleer of het systeem ze niet opvolgt. Voor acties met gevolgen, zoals gegevens wijzigen of berichten versturen, hoort een aparte controle of menselijke bevestiging erbij.
Kan een RAG-systeem vragen in meerdere talen beantwoorden?
Ja, een RAG-systeem kan meerdere talen ondersteunen, maar het moet zowel de vraag als de bedrijfsbronnen in die talen goed kunnen verwerken. De zoekkwaliteit hangt onder meer af van het embeddingmodel en de zoekmethode: sommige systemen vinden verwante passages ook wanneer de vraag en bron een andere taal gebruiken, maar dat moet je voor jouw talencombinatie testen.
Neem in de testset vragen en documenten op in alle talen die gebruikers daadwerkelijk gebruiken, inclusief vaktermen en lokale schrijfwijzen. Controleer ook of het antwoord de taal van de gebruiker volgt en of vertaalde passages de betekenis en uitzonderingen behouden. Als officiële termen niet vertaald mogen worden, leg dan vast hoe het systeem daarmee omgaat.
Hoe start je een veilige pilot met een bedrijfsassistent op basis van RAG?
Start een veilige pilot met één afgebakende toepassing, een beperkte groep gebruikers en bronnen die een duidelijke eigenaar hebben. Kies een onderwerp waarbij fouten beheersbare gevolgen hebben en spreek vooraf af welke informatie de assistent wel en niet mag gebruiken. Controleer dat toegangsrechten van gebruikers ook tijdens het ophalen van bronnen worden toegepast.
Maak vóór de start een testset met normale vragen, lastige uitzonderingen en gevallen waarvoor geen antwoord beschikbaar is. Laat gebruikers antwoorden controleren en maak het eenvoudig om fouten of ontbrekende informatie te melden. Houd de pilot klein genoeg om problemen snel te onderzoeken; breid pas uit nadat zoekkwaliteit, bronrechten en werkwijze voor updates aantoonbaar goed functioneren.