Het fine-tunen van taalmodellen is allang geen laboratoriumritueel meer, maar een vast onderdeel van de productstack. Wat twee jaar geleden dedicated GPU’s en weken werk vereiste, lost men vandaag op met low-rank-technieken, synthetische data en beheerde API’s. Maar het landschap is zo sterk veranderd dat veel recepten die nog rondgaan, vastzitten in inmiddels achterhaalde praktijken. Deze terugblik richt zich op wat het veld op dit moment daadwerkelijk beweegt, zonder wonderen te beloven.
Wat er is veranderd in de fine-tuning-cyclus
De klassieke workflow — instructie-antwoordparen verzamelen, alle gewichten trainen en op het oog evalueren — is uiteengevallen. Teams die met open modellen werken, hebben varianten omarmd die kosten en risico’s verlagen:
- LoRA en zijn afgeleiden (QLoRA, DoRA): er wordt een minimale fractie van de parameters getraind en het basismodel blijft bevroren. De officiële documentatie van de belangrijkste trainingsbibliotheken presenteert ze al als de standaardoptie voor aanpassingen met minder dan een miljoen voorbeelden.
- Voorkeursafstemming: in plaats van antwoorden na te bootsen, optimaliseert men met voorkeursparen (DPO en varianten). Volgens sectorstudies vermindert deze aanpak het aantal benodigde voorbeelden ten opzichte van traditionele RLHF en voorkomt het dat er een apart beloningsmodel moet worden getraind.
- Destillatie vanuit grote modellen: data genereren met een groter model en een kleiner model aanpassen is gangbare praktijk geworden. De belangrijke nuance: de kwaliteit van de leraar bepaalt het plafond van de leerling, en synthetische data zonder filtering slepen vooroordelen en hallucinaties met zich mee.
Een realistische workflow, stap voor stap, met de valkuilen gemarkeerd
1. Het doelgedrag definiëren voordat je data aanraakt
De meest voorkomende fout die ik zie bij teams die beginnen: het starten van de training zonder een schriftelijke specificatie van wat het model moet doen en, vooral, wat het niet moet doen. Zonder dat contract is de latere evaluatie vrije interpretatie. Het loont om 10 tot 20 use cases op te stellen met voorbeelden van invoer en verwachte uitvoer, inclusief randgevallen (ambigue verzoeken, buiten het domein, manipulatiepogingen).
2. De dataset met meer rigor dan enthousiasme samenstellen
De gebruikelijke verhouding in projecten die werken ligt rond enkele honderden tot enkele duizenden goed gelabelde voorbeelden. Meer volume met ruis verslechtert het resultaat. Drie controles die vaak worden overgeslagen:
- Semantische deduplicatie: bijna identieke antwoorden met lichte variaties blazen de set op en vertekenen de aanpassing.
- Consistentie van formaat: als 80% van de antwoorden één stijl gebruikt en 20% een andere, leert het model beide en gaat het schommelen.
- Controle op annotatievooroordelen: wie labelt, laat sporen na. Twee verschillende annotatoren produceren verschillende distributies, zelfs als ze dezelfde richtlijn volgen.
3. Basis en methode kiezen op basis van het werkelijke budget
Niet alles vereist een model van 70B. Voor classificatietaken, entiteitsextractie of antwoorden met een vast formaat volstaat een model van 7-8B dat met QLoRA is aangepast meestal, en het draait op één GPU. Voor complexe redeneringen loont fine-tuning zelden ten opzichte van een groter model met goede prompting; daar overtreft de serveerkost het voordeel.
Een praktisch detail dat in de documentatie van verschillende platforms opduikt: als het doel is nieuwe kennis aan te leren (interne regelgeving, productcatalogus), is fine-tuning een middelmatig instrument. Daarvoor werkt retrieval-augmented generation beter. Fine-tuning schittert wanneer je de vorm van antwoorden wilt veranderen: toon, formaat, weigeringsbeleid, uitvoerstructuur.
4. Trainen met gescheiden validatie vanaf de eerste minuut
10% tot 20% van de data reserveren voor validatie is niet optioneel. Overfitting bij kleine modellen is snel en stil: de trainingsloss daalt terwijl de antwoorden star en repetitief worden. Om dat te detecteren moet je naar generatiemetrieken kijken, niet alleen naar de loss.
5. Evalueren met rubrieken, niet met indrukken
Hier stranden de meeste projecten. Een eerlijke evaluatie combineert:
- Automatische tests van formaat en beperkingen (respecteert het het JSON-schema? citeert het de bron? weigert het wat het moet weigeren?).
- Blinde menselijke evaluatie op een kleine steekproef, waarbij basismodel en aangepast model met dezelfde prompt worden vergeleken.
- Een regressieset die niet verandert tussen iteraties, om drift te meten.
Volgens de officiële documentatie van verschillende evaluatieleveranciers correleren automatische metrieken zoals BLEU of ROUGE slecht met de ervaren bruikbaarheid bij open taken. Ze dienen voor formaat, niet voor kwaliteit.
Het geval dat bijna niemand vertelt: de aanpassing die het product verslechterde
Een team paste een model van 8B aan zodat het op supportvragen zou antwoorden met een zeer gecontroleerde toon. De resultaten op de validatieset waren uitstekend. In productie begon het model legitieme vragen af te wijzen die oppervlakkig leken op de vragen die als buiten bereik waren gemarkeerd. Het probleem was niet de training: het was dat de dataset veel weigeringsvoorbeelden bevatte en zeer weinig ambigue vragen die wel beantwoord moesten worden. De les: de distributie van de dataset bepaalt het gedrag net zozeer als de inhoud. Een fine-tuning leert geen nuances aan die niet in de data zijn vertegenwoordigd.
Trends die het veld herdefiniëren
Gespecialiseerde kleine modellen versus monolithen
De kostencurve van inferentie duwt richting modellen van 3-8B die voor een specifieke taak zijn aangepast. Verschillende infrastructuuraanbieders bieden al low-rank-deployments met concurrerende latentie. De nuance: specialisatie heeft een plafond. Een klein model dat voor klantenservice is aangepast, wordt niet ineens een algemene assistent, hoe vaak je het ook traint.
Aanpassen met gefilterde synthetische data
Data genereren met een groter model en op kwaliteit filteren voordat je traint, is vandaag wijdverbreide praktijk. Het bekende risico: modellen die op ongeverifieerde synthetische data zijn getraind, neigen ernaar de fouten van de generator te versterken. De aanbeveling die opduikt in technische forums en bibliotheekdocumentatie is om echte data te mengen met synthetische en een handmatige audit op een steekproef te behouden.
Evaluatie als dienst en traceerbaarheid
Regelgevende druk in sommige sectoren heeft ertoe geleid dat het aanpassingsproces wordt gedocumenteerd: welke data, welke methode, welke evaluatie, welke bekende beperkingen. Dat is geen bureaucratie: het is wat het mogelijk maakt om te beslissen wanneer een aangepast model moet worden teruggetrokken omdat het gedrag is afgedreven.
Wat fine-tuning niet oplost
Het loont om het ronduit te zeggen. Fine-tuning lost geen dataprobleem op, vervangt geen goede prompt-engineering bij eenvoudige taken en garandeert niet dat het model stopt met hallucineren. Het is ook niet de weg om kennis actueel te houden: elke wijziging in het interne beleid zou hertraining vereisen, iets wat retrieval-augmented generation voorkomt. En bij zeer grote modellen kan de kost van het serveren van een eigen aanpassing hoger uitvallen dan die van een beheerde API met zorgvuldige prompting.
De verstandige beslissing begint met een voorafgaande vraag: moet ik veranderen hoe het model antwoordt, of moet ik dat het iets weet wat het niet weet? De eerste vraag rechtvaardigt de aanpassing. De tweede bijna nooit.