RAG of fine-tuning voor AI met bedrijfsdata

RAG en fine-tuning kunnen een AI-model beter laten aansluiten op bedrijfsinformatie, maar pakken verschillende problemen aan. Lees hoe beide technieken werken en welke keuzes rond actuele data, uitvoerstijl, privacy en beheer bepalen wat bij een toepassing past.

Hoe RAG bedrijfsinformatie beschikbaar maakt voor een AI-model

Retrieval-augmented generation, meestal afgekort tot RAG, combineert een taalmodel met een doorzoekbare bron van bedrijfsinformatie. Wanneer iemand een vraag stelt, zoekt de applicatie eerst relevante passages op. Die informatie wordt samen met de vraag aan het model aangeboden, dat op basis daarvan een antwoord formuleert. Het model hoeft de documenten dus niet vooraf in zijn parameters te onthouden; de informatie wordt per vraag opgehaald.

Voor die zoekstap worden documenten doorgaans opgesplitst in kleinere stukken, voorzien van metadata en omgezet in numerieke representaties, embeddings. Een zoekcomponent haalt vervolgens passages op die inhoudelijk bij de vraag aansluiten. In productieomgevingen wordt vaak ook op trefwoorden gezocht. Die hybride aanpak kan bijvoorbeeld helpen bij exacte productcodes, namen of wetsartikelen, waarbij semantische gelijkenis alleen niet genoeg is.

De kwaliteit van RAG hangt sterk af van de bronverwerking. Slecht geëxtraheerde tabellen, verouderde versies en passages zonder context leiden tot onbruikbare resultaten, ook als het taalmodel goed is. De applicatie moet relevante bronnen selecteren, de context binnen de beschikbare modelruimte houden en waar nodig verwijzingen tonen. RAG maakt bedrijfskennis dus toegankelijker, maar vervangt geen beheer van documenten of zoekkwaliteit.

Wat fine-tuning verandert aan een taalmodel

Bij fine-tuning wordt een bestaand model verder getraind op voorbeelden die aansluiten bij een specifieke taak. De gewichten van het model veranderen daardoor. Een dataset kan bijvoorbeeld bestaan uit instructies met gewenste antwoorden, geclassificeerde berichten of voorbeelden van een vaste outputstructuur. Na de training kan het model patronen uit die voorbeelden consistenter toepassen, zoals een bepaalde toon, indeling of manier van labelen.

Fine-tuning is niet hetzelfde als documenten in het model laden. Een model kan stijl- en taakpatronen leren, maar is daardoor niet automatisch een betrouwbare database van actuele bedrijfsfeiten. Het kan een veelvoorkomende formulering of categorie beter hanteren, terwijl een recent gewijzigde procedure nog steeds ontbreekt. Voor feitelijke antwoorden die moeten overeenkomen met veranderende bronnen, blijft een mechanisme nodig dat die bronnen op het moment van de vraag raadpleegt.

De trainingsvoorbeelden bepalen in hoge mate wat het model leert. Inconsistente labels, tegenstrijdige antwoorden of een te smalle dataset kunnen ongewenst gedrag versterken. Ook moet de modelversie geschikt zijn voor fine-tuning en moeten trainingsdata zorgvuldig worden samengesteld en gecontroleerd. De aanpak is vooral relevant wanneer de gewenste verbetering betrekking heeft op herhaalbaar gedrag, niet wanneer het kernprobleem simpelweg is dat het model de juiste actuele informatie niet kan vinden.

Het verschil tussen RAG en fine-tuning in de praktijk

Het belangrijkste verschil zit in wat er wordt aangepast. RAG verandert het model niet, maar levert bij een vraag geselecteerde informatie aan. Fine-tuning verandert het model zelf, zodat het bepaalde patronen anders leert toepassen. Dat onderscheid maakt de keuze concreter: moet de AI specifieke feiten kunnen raadplegen, of moet zij een taak, stijl of uitvoerformaat consistenter uitvoeren?

Bij een wijziging in een handleiding kan een RAG-systeem doorgaans met de nieuwe documentversie werken zodra die is verwerkt en geïndexeerd. Een fine-tuned model wordt niet vanzelf bijgewerkt wanneer een document verandert. Omgekeerd hoeft een vaste classificatiestijl niet bij iedere aanvraag uit documenten te worden opgehaald; voorbeelden in een fine-tuningdataset kunnen daarvoor geschikter zijn. De technieken lossen dus verschillende onderdelen van een toepassing op.

Ook de foutsoorten verschillen. RAG kan de verkeerde passage ophalen, relevante informatie missen of tegenstrijdige bronnen samenvoegen. Fine-tuning kan een verkeerd aangeleerd patroon toepassen of een antwoordstructuur produceren die niet meer past. In beide gevallen kan het taalmodel overtuigend formuleren zonder dat de uitkomst correct is. Een keuze op basis van alleen modelkwaliteit of een demonstratie is daarom onvoldoende. Beoordeel de aard van de kennis, hoe vaak die verandert, de gewenste uitvoer en de gevolgen van een fout.

Wanneer actuele brondata RAG de logische keuze maakt

RAG ligt voor de hand wanneer antwoorden afhankelijk zijn van interne informatie die regelmatig verandert of te omvangrijk is om in vaste instructies te onderhouden. Denk aan beleidsdocumenten, productinformatie, technische handleidingen, contractrichtlijnen of interne kennisartikelen. De applicatie kan per vraag relevante passages ophalen, zodat het model niet uitsluitend op algemene trainingskennis hoeft te vertrouwen. Dat is vooral waardevol wanneer antwoorden herleidbaar moeten zijn tot een specifieke bron.

De brondata moet wel toegankelijk en voldoende gestructureerd zijn. PDF-bestanden met complexe tabellen, scans zonder tekstherkenning en documenten met onduidelijke versies vragen om extra verwerking. Bij het indexeren zijn metadata zoals eigenaar, datum, documenttype en toegangsrechten nuttig. Zonder die gegevens kan de zoeklaag een inhoudelijk verwante passage kiezen die niet voor de gebruiker geldt, bijvoorbeeld een oude procedure of informatie voor een andere afdeling.

RAG maakt informatie niet automatisch actueel op het moment dat een bron verandert. Er is een ingestieproces nodig dat wijzigingen detecteert, documenten opnieuw verwerkt en verwijderde of ingetrokken informatie uit de index haalt. De actualiteit hangt dus af van de synchronisatie en van de vindbaarheid, niet alleen van het taalmodel. Bij bronnen die sterk gestructureerd zijn, zoals voorraadstanden of klantstatussen, is een directe koppeling met een database of API soms betrouwbaarder dan het indexeren van tekstuele kopieën.

Wanneer fine-tuning de uitvoer van AI kan verbeteren

Fine-tuning is het overwegen waard wanneer een model een terugkerende taak op een specifieke manier moet uitvoeren. Dat kan gaan om het indelen van klantvragen volgens een intern schema, het omzetten van vrije tekst naar een vast JSON-formaat of het toepassen van een herkenbare schrijfstijl. Als goede voorbeelden beschikbaar zijn, kan het model die patronen leren zonder dat elke prompt steeds uitgebreider hoeft te worden. De winst zit dan in consistentie en taakgedrag, niet in het toevoegen van een actuele kennisbank.

Een bruikbare dataset bevat representatieve voorbeelden van de variatie die het systeem in de praktijk tegenkomt. Daarbij horen ook lastige gevallen, onvolledige input en situaties waarin het gewenste antwoord is om informatie op te vragen of een taak niet uit te voeren. Als alleen nette standaardgevallen worden opgenomen, kan het model bij afwijkende invoer onvoorspelbaar reageren. Voorbeelden moeten bovendien dezelfde definities en labels gebruiken; anders leert het model tegenstrijdige patronen.

Fine-tuning is minder geschikt als een paar goed ontworpen instructies of voorbeelden in de prompt het probleem al oplossen. Het voegt trainings- en versiebeheer toe en maakt het noodzakelijk om wijzigingen opnieuw te evalueren. Wanneer de inhoudelijke kennis vaak verandert, kan fine-tuning bovendien een omslachtige manier zijn om feiten bij te werken. Scheid daarom het gewenste gedrag van de feiten waarop dat gedrag moet worden toegepast: het eerste kan een fine-tuningvraag zijn, het tweede vraagt vaak om een externe bron.

RAG en fine-tuning combineren in één AI-toepassing

RAG en fine-tuning sluiten elkaar niet uit. Een combinatie kan passend zijn wanneer een toepassing zowel actuele bedrijfskennis moet raadplegen als een specifieke taak consequent moet uitvoeren. Een fine-tuned model kan bijvoorbeeld leren hoe het een interne categorie-indeling toepast, terwijl RAG bij iedere aanvraag de actuele beleidsregels ophaalt waarop de classificatie moet steunen. De technieken vervullen dan verschillende rollen in dezelfde verwerkingsketen.

Een mogelijke opzet begint met authenticatie en het bepalen van de toegestane gegevens. Daarna zoekt de applicatie relevante bronnen op, voegt die samen met de vraag en geeft het geheel aan het model. Het model kan vervolgens volgens aangeleerde instructies een antwoord of gestructureerd resultaat produceren. Validatie achteraf kan controleren of verplichte velden aanwezig zijn, of citaten overeenkomen met opgehaalde passages en of een antwoord buiten toegestane grenzen valt. Die controles zijn applicatielogica, geen eigenschap die fine-tuning vanzelf garandeert.

Een gecombineerde architectuur brengt ook meer onderdelen mee om te testen en te beheren. Een fout kan ontstaan bij retrieval, promptopbouw, modelgedrag of validatie. Daarom is het nuttig om per fase meetgegevens en testgevallen te hebben. Begin niet met beide technieken alleen omdat ze beschikbaar zijn. Als een RAG-oplossing de taak al betrouwbaar uitvoert, voegt fine-tuning mogelijk weinig toe. Als de taakuitvoer al stabiel is, lost een omvangrijke zoekarchitectuur geen probleem op dat er niet is.

Privacy en toegangsbeheer bij RAG en fine-tuning

Bedrijfsdata vraagt om controle over welke informatie een modeltoepassing verwerkt, waar die informatie terechtkomt en wie haar kan opvragen. Bij RAG blijft de bron doorgaans buiten de modelgewichten, maar documenten en opgehaalde passages worden wel naar de modeldienst gestuurd om een antwoord te genereren. Dat betekent dat de gegevensstroom, bewaartermijnen, logging en voorwaarden van de gekozen infrastructuur moeten worden beoordeeld. Alleen een vectorindex gebruiken maakt een toepassing niet automatisch privacyvriendelijk.

Toegangsrechten moeten ook tijdens het zoeken gelden. Als documenten per afdeling of rol afgeschermd zijn, moet de retrievallaag die grenzen toepassen voordat passages aan het model worden aangeboden. Een antwoordfilter achteraf is daarvoor geen gelijkwaardig alternatief: zodra vertrouwelijke tekst in de modelcontext zit, is de scheiding al doorbroken. Metadata, identiteitsbeheer en autorisatie moeten daarom onderdeel zijn van de zoekarchitectuur, niet een latere toevoeging.

Bij fine-tuning kunnen gevoelige gegevens in de trainingsset terechtkomen en invloed hebben op modelgedrag. Verwijder of minimaliseer persoonsgegevens waar dat kan, beperk de dataset tot het noodzakelijke en leg vast welke bronversies zijn gebruikt. Onderzoek ook hoe modellen, trainingsbestanden en evaluatielogs worden opgeslagen en beheerd. Voor beide benaderingen is een datastroomoverzicht nuttig: welke informatie wordt opgehaald of gebruikt, welke partij verwerkt die en hoe wordt toegang ingetrokken wanneer een gebruiker of document daarvoor niet langer in aanmerking komt?

Nauwkeurigheid meten en fouten in AI-antwoorden onderzoeken

Een overtuigend antwoord is geen bewijs van juistheid. Bij RAG moet de evaluatie daarom zowel de zoekstap als de gegenereerde tekst beoordelen. Haalt het systeem de relevante passage op? Staat het antwoord daadwerkelijk in die passage? Gebruikt het model de juiste versie en meldt het onzekerheid wanneer de bron onvoldoende informatie bevat? Door deze vragen apart te testen, wordt duidelijk of een fout ontstaat in de index, de zoekinstellingen, de contextopbouw of de generatie.

Maak een testset met echte, geanonimiseerde vraagtypen en gecontroleerde verwachte uitkomsten. Neem vragen op waarvan het antwoord wel in de bronnen staat, vragen met meerdere relevante documenten en vragen waarop de beschikbare informatie geen antwoord geeft. Test ook varianten in formulering en gevallen met conflicterende versies. Voor fine-tuning zijn andere metingen nodig, zoals labelnauwkeurigheid, naleving van het outputformaat en prestaties op voorbeelden die niet tijdens de training zijn gebruikt. Een model dat trainingsvoorbeelden goed reproduceert, kan alsnog tekortschieten op nieuwe gevallen.

Meet niet alleen een totaalscore. Fouten met grote gevolgen verdienen afzonderlijke aandacht, bijvoorbeeld verkeerde instructies of onterechte toegang tot informatie. Leg vast welke bronnen zijn opgehaald en welke modelversie het antwoord heeft geproduceerd, met passende privacybeperkingen voor logs. Menselijke beoordeling blijft relevant voor open antwoorden, maar beoordelaars hebben duidelijke criteria nodig. Zonder vaste tests kan een promptwijziging of nieuwe documentbatch de prestaties ongemerkt verslechteren.

Beheer van documenten, modellen en wijzigingen in productie

Een AI-toepassing met bedrijfsdata is geen eenmalig modelproject. Bij RAG veranderen documenten, rechten, metadata en zoekinstellingen. Een beheerproces moet bepalen welke bronnen gezaghebbend zijn, wie wijzigingen goedkeurt en hoe ingetrokken documenten uit de index verdwijnen. Als verschillende bestanden dezelfde procedure beschrijven, moet duidelijk zijn welk document leidend is. Anders kan retrieval meerdere passages met uiteenlopende instructies aanbieden en laat de toepassing het taalmodel impliciet kiezen.

Ook de index zelf vraagt aandacht. Splitsingsregels bepalen hoeveel context een opgehaalde passage bevat; te kleine stukken verliezen verband, te grote stukken bevatten ruis. Embeddings, filters en rangschikking kunnen worden aangepast, maar iedere wijziging kan de resultaten veranderen. Houd daarom testvragen en bekende relevante passages bij en voer regressietests uit na wijzigingen in de bronverwerking of zoekconfiguratie. Een nieuwe embeddingmethode kan een verbetering zijn, maar vraagt soms om het opnieuw opbouwen van de index.

Voor fine-tuning hoort versiebeheer bij de dataset, trainingsinstellingen, het model en de evaluatieresultaten. Daarmee is te reconstrueren waarom een model een bepaalde uitvoer produceerde en kan een eerdere versie worden vergeleken. Plan herbeoordeling wanneer labels, processen of modelversies veranderen; retrainen op nieuwe voorbeelden zonder selectie kan juist verouderde of afwijkende patronen versterken. In productie moeten fouten bovendien naar de juiste beheerlaag worden teruggekoppeld: broncorrectie, toegangsregel, retrievalinstelling, prompt of trainingsdata vragen elk om een andere ingreep.

Veelgestelde vragen

Hoe begin je met een pilot voor RAG of fine-tuning?

Begin met één afgebakende taak en een kleine, representatieve testset voordat je een AI-toepassing breed uitrolt. Beschrijf vooraf wat een goed resultaat is, welke fouten onacceptabel zijn en hoe je de uitkomst controleert. Kies daarna de eenvoudigste opzet die de taak kan testen: bijvoorbeeld een beperkte documentcollectie voor RAG of een vaste reeks invoer- en uitvoervoorbeelden voor een gedragstest.

• Test met echte, waar mogelijk geanonimiseerde gebruikersvragen.
• Laat relevante medewerkers antwoorden en fouten beoordelen.
• Vergelijk de AI-uitkomst met de bestaande werkwijze.
• Breid pas uit als de resultaten aan vooraf bepaalde criteria voldoen.

Wat bepaalt de kosten van RAG en fine-tuning?

De kosten hangen vooral af van de hoeveelheid data, het gebruiksvolume, de gekozen infrastructuur en het beheer dat nodig is om de toepassing betrouwbaar te houden. Bij RAG spelen onder meer documentverwerking, opslag, zoekopdrachten en modelaanroepen mee. Bij fine-tuning komen daar het samenstellen en controleren van trainingsdata, trainingsruns en versiebeheer bij. De goedkoopste optie op papier is niet altijd het voordeligst als veel herstelwerk nodig is.

• Neem ontwikkel- en testuren mee.
• Bereken kosten bij verwacht én piekgebruik.
• Reserveer tijd voor evaluatie, updates en incidenten.
• Vergelijk de totale kosten met de huidige manier van werken.

Hoe vaak moet je de documenten in een RAG-systeem bijwerken?

Werk documenten bij volgens de snelheid waarmee de informatie verandert en de gevolgen van een verouderd antwoord. Voor dagelijkse wijzigingen kan een automatische synchronisatie nodig zijn; voor stabiele kennisartikelen kan een periodieke verwerking volstaan. Leg per bron vast hoe wijzigingen worden ontdekt en hoe snel nieuwe, aangepaste of ingetrokken informatie beschikbaar moet zijn. Test ook of verwijderde versies niet langer door de zoeklaag worden aangeboden.

• Geef risicovolle of vaak veranderende bronnen voorrang.
• Leg eigenaarschap en updatefrequentie per bron vast.
• Controleer na verwerking of de nieuwe versie vindbaar is.
• Houd bij wanneer de index voor het laatst is bijgewerkt.

Wat moet een AI doen als er geen betrouwbare bron voor een antwoord is?

De AI moet duidelijk aangeven dat de beschikbare informatie onvoldoende is en geen feitelijk antwoord verzinnen. Bepaal vooraf hoe zo’n situatie eruitziet: bijvoorbeeld geen relevante passage, bronnen die elkaar tegenspreken of informatie die buiten de toegestane context valt. De applicatie kan dan om verduidelijking vragen, verwijzen naar een verantwoordelijke medewerker of aangeven welke informatie ontbreekt. Test deze gevallen net zo zorgvuldig als vragen met een bekend antwoord.

• Formuleer een herkenbare melding voor de gebruiker.
• Voorkom dat een onbevestigde gok als feit wordt gepresenteerd.
• Leg vast wanneer escalatie naar een medewerker nodig is.
• Controleer of de melding ook verschijnt bij tegenstrijdige bronnen.

Hoe monitor je een AI-toepassing met bedrijfsdata nadat die live is gegaan?

Monitor na ingebruikname zowel de technische werking als de kwaliteit van antwoorden, zodat problemen zichtbaar worden voordat ze structureel worden. Houd bijvoorbeeld bij hoe vaak bronnen worden gevonden, hoe vaak gebruikers een antwoord als onbruikbaar markeren en of fouten vaker voorkomen bij bepaalde documenttypen of vraagsoorten. Gebruik logging die nodig is voor onderzoek, maar beperk gevoelige gegevens en geef alleen bevoegde personen toegang.

• Herhaal periodiek tests met een vaste evaluatieset.
• Onderzoek meldingen en afwijkingen per fase van de verwerking.
• Controleer prestaties na wijzigingen aan modellen, prompts of bronnen.
• Wijs een eigenaar aan voor opvolging en herstel.