Fine-tuning vs RAG voor bedrijfssoftware

Fine-tuning past het AI-model zelf aan door het extra te trainen op jouw voorbeelden. RAG laat het model ongemoeid en geeft bij elke vraag de relevante informatie uit je eigen bronnen mee. Voor bedrijfssoftware die met actuele feiten werkt, zoals klanten, contracten, orders en facturen, is RAG of een directe databasekoppeling bijna altijd de juiste keuze. Fine-tuning is nuttig voor vorm en gedrag, niet voor kennis die verandert.

Wat fine-tuning is

Een taalmodel is getraind op een enorme hoeveelheid algemene tekst. Bij fine-tuning train je het nog een keer, op een veel kleinere set van je eigen voorbeelden. Het model past daarbij een deel van zijn gewichten aan. Daarna gedraagt het zich anders: het schrijft in een bepaalde stijl, volgt een vast format of herkent een specifiek soort document beter.

Wat fine-tuning goed doet:

• Een vaste vorm afdwingen. Een model dat altijd een bevinding teruggeeft in precies dezelfde structuur, met dezelfde velden.
• Vaktaal en indeling leren. Een model dat werkbonnen van jouw monteurs moet indelen in categorieën die jullie intern gebruiken.
• Een kleiner model laten presteren als een groter. Voor een smalle, herhaalde taak kan een klein fine-tuned model volstaan, wat inference goedkoper en sneller maakt. Zie Inference uitgelegd.

Wat fine-tuning slecht doet:

• Feiten onthouden die veranderen. Een model dat is getraind op je klantenlijst van januari, weet in juni niet dat er klanten zijn bijgekomen of vertrokken.
• Exact terughalen. Een model dat tijdens training een contract heeft gezien, kan het indexatiepercentage niet betrouwbaar citeren. Het heeft patronen geleerd, geen tabel opgeslagen.
• Laten zien waar iets vandaan komt. Een fine-tuned model kan niet naar een bron wijzen. Het antwoord komt uit zijn gewichten.

Wat RAG is

RAG staat voor retrieval-augmented generation. Het model blijft zoals het is. Bij elke vraag zoekt de software eerst de relevante informatie op en zet die in het context window, samen met de vraag. Het model schrijft zijn antwoord op basis van wat het net heeft gekregen.

Het zoeken kan op twee manieren. Bij tekst, zoals contracten en handleidingen, meestal met embeddings: de passages die qua betekenis het dichtst bij de vraag liggen. Hoe dat werkt, lees je in Embeddings uitgelegd voor business software. Bij gestructureerde data, zoals orders en facturen, beter met een gewone databasequery. Het verschil tussen die twee staat in RAG vs database queries voor bedrijfsdata.

Wat RAG goed doet:

• Actueel blijven. Wijzigt een contract, dan vindt de volgende vraag de nieuwe versie. Er hoeft niets opnieuw getraind te worden.
• Bronnen tonen. Het systeem weet welke passages het heeft meegegeven, dus het kan erbij zeggen waar een bewering vandaan komt.
• Rechten respecteren. Wat een gebruiker niet mag zien, wordt niet opgehaald. Bij fine-tuning zit alles in het model, voor iedereen die het gebruikt.

Wat RAG slecht doet:

• De verkeerde passage vinden. Als het zoeken misgaat, schrijft het model een overtuigend antwoord op basis van de verkeerde bron.
• Grote hoeveelheden verwerken. RAG geeft een selectie mee. Vragen over alles tegelijk, zoals een totaal over een jaar, horen niet via RAG maar via een query. Een model is geen rekenmachine voor duizenden regels.

Naast elkaar

Waarom bedrijfsdata niet in een model hoort

Er is een reden die zwaarder weegt dan techniek: controle over je data.

Als je klantgegevens, contractbedragen of persoonsgegevens gebruikt om een model te fine-tunen, zitten die op een diffuse manier in dat model. Je kunt niet aanwijzen waar. Je kunt ze er niet gericht uithalen als een klant vraagt om verwijdering. Het model kan fragmenten ervan terugschrijven aan iemand die ze niet had mogen zien. Voor persoonsgegevens onder de AVG is dat een lastige positie. Meer daarover in Hoe bescherm je persoonsgegevens in AI-systemen?.

Bij RAG en directe queries blijft de data in je eigen systemen. Het model ziet hem alleen op het moment van de vraag en alleen voor zover de rechten dat toelaten. Verwijder je een record in de bron, dan komt het niet meer terug.

Dat sluit aan bij een principe dat voor elke vorm van omzetcontrole geldt: je eigen systemen blijven de bron van waarheid. De AI leest, vergelijkt en legt uit. Hij wordt niet zelf de plek waar de cijfers staan. Hoe die rolverdeling in een compleet systeem uitpakt, staat in Hoe werkt AI binnen Revenue Intelligence?.

Wanneer fine-tuning wel zin heeft

Fine-tuning is geen slecht idee, het wordt alleen vaak voor het verkeerde doel ingezet. Het past bij taken waar het gedrag vast is en de feiten van buiten komen:

• Een model dat factuurregels uit pdf's van leveranciers in een vast format omzet. De vorm is steeds gelijk, de inhoud komt uit het document zelf.
• Een model dat vrije-tekstnotities indeelt in een vaste set categorieën, zoals opzegreden of soort meerwerk.
• Een model dat bevindingen altijd formuleert in de stijl en structuur die je organisatie gewend is.

Ook dan geldt: de feiten waarop het model werkt, komen via RAG of een query binnen. Fine-tuning en RAG sluiten elkaar niet uit. Een fine-tuned model kan prima werken met opgehaalde data.

Rekenvoorbeeld: wat er gebeurt als je prijzen in een model traint

Rekenvoorbeeld: stel, een bedrijf fine-tunet in januari een model op zijn prijsafspraken, zodat een assistent kan zeggen welke prijs een klant hoort te betalen. Er zijn 250 klanten met een eigen prijsafspraak.

• Op 1 april worden 90 contracten geïndexeerd.
• In mei komen er 15 klanten bij, en 8 vertrekken.
• In juni vraagt een medewerker aan de assistent welke prijs klant X hoort te betalen. Het model geeft de prijs van januari, met overtuiging.

Om dat te voorkomen moet het model na elke wijziging opnieuw getraind worden. Dat is duur, traag en geeft nog steeds geen garantie dat het exacte bedrag correct terugkomt. Met RAG of een query haalt de assistent de actuele prijs uit het systeem waar hij staat en noemt hij erbij waar die vandaan komt. Wie op verouderde prijzen factureert, heeft precies het lek dat beschreven staat in Revenue leakage door verkeerde prijzen.

Beslishulp

Stel jezelf deze vragen bij elke AI-toepassing op bedrijfsdata:

1. Verandert de informatie? Ja: RAG of query. Nee, en het gaat om vorm of gedrag: fine-tuning kan.
2. Moet de gebruiker de bron kunnen zien? Ja: RAG of query.
3. Mogen niet alle gebruikers alles zien? Dan hoort de data niet in het model.
4. Zitten er persoonsgegevens in? Dan hoort de data niet in het model.
5. Gaat het om aantallen, totalen of bedragen? Dan hoort het rekenwerk in een query, niet in een model.
6. Is de taak smal, herhaald en qua vorm vast? Dan kan fine-tuning helpen, vooral om kosten per aanroep te verlagen.

Veelgestelde vragen

Is RAG altijd beter dan fine-tuning?

Voor vragen over feiten die veranderen wel. Voor vaste vorm, stijl of een smalle indelingstaak kan fine-tuning beter zijn. In veel systemen worden ze gecombineerd.

Kan een leverancier mijn data gebruiken om zijn model te fine-tunen?

Alleen als het contract dat toestaat. Vraag het expliciet en laat het uitsluiten als je het niet wilt. Het gaat hier om training, niet om het gewone gebruik van het model bij een vraag.

Is een fine-tuned model veiliger omdat de data niet bij elke vraag wordt verstuurd?

Nee. De data zit dan in het model zelf, waar je hem niet gericht uit kunt halen en waar rechten per gebruiker niet werken. Dat is voor gevoelige bedrijfsdata juist minder beheersbaar.

Wat kost fine-tuning?

Dat hangt af van het model, de aanbieder en de hoeveelheid trainingsdata. Er is geen vast bedrag te noemen. Reken wel op herhaalde kosten als de taak verandert, want elke aanpassing vraagt een nieuwe trainingsronde.