Fine-tuning van LLM’s: mythen en realiteiten in 2026

De ruis rondom fine-tuning

Weinig AI-technieken hebben zoveel buitenproportionele verwachtingen opgebouwd als het fine-tunen van taalmodellen. Het wordt vaak gepresenteerd als een toverstaf die een generiek model omtovert tot een deskundige assistent door simpelweg een CSV met voorbeelden te uploaden. De realiteit is een stuk prozaïscher: fine-tuning is een chirurgisch instrument met een reële kostprijs, duidelijke beperkingen en, in veel gevallen, goedkopere alternatieven die beter werken.

Dit artikel is geen tutorial met commando’s, maar een contrast tussen wat er in forums wordt gezegd en wat er gebeurt wanneer het proces met echte data wordt uitgevoerd. Als je een onfeilbaar recept zoekt, zul je het hier niet vinden. Als je wilt weten wanneer het de moeite waard is en wanneer je geld weggooit, lees dan verder.

Mythe 1: ‘Met 100 voorbeelden heb je al een deskundig model’

Het is waarschijnlijk de meest herhaalde bewering in discussiethreads. De officiële documentatie van de belangrijkste aanbieders van aanpasbare modellen raadt doorgaans datasets aan van enkele honderden tot duizenden hoogwaardige voorbeelden, afhankelijk van de complexiteit van de taak. Honderd voorbeelden kunnen werken voor een zeer specifieke binaire classificatie, maar niet voor een assistent die moet redeneren over interne regelgeving.

Er is een detail dat bijna nooit wordt vermeld: kwaliteit weegt zwaarder dan kwantiteit, maar niet lineair. Een dataset van 500 voorbeelden die door een deskundig persoon zijn beoordeeld, kan beter zijn dan een van 5.000 die automatisch met het model zelf zijn gegenereerd. Het fenomeen staat bekend als model collapse wanneer iteratief wordt getraind met synthetische data zonder menselijke filtering.

Een concreet geval dat het probleem illustreert

In een project voor de classificatie van supporttickets genereerde een team 3.000 voorbeelden die met een groot model waren gelabeld en paste een klein model aan. De initiële nauwkeurigheid leek uitstekend in validatie, maar bij de implementatie in productie verslechterden de ambigue categorieën (klachten die facturering en technische support vermengden). De oorzaak: de automatische labeler erfde zijn eigen vooroordelen en het aangepaste model leerde die fouten met groot vertrouwen na te bootsen. De oplossing was niet meer data, maar het handmatig herzien van 200 ambigue gevallen en het toevoegen van expliciete regels aan de systeemprompt.

Mythe 2: ‘Fine-tuning vervangt RAG’

Deze verwarring duikt voortdurend op. Het zijn verschillende technieken die verschillende problemen oplossen:

• Fine-tuning: wijzigt het gedrag van het model (stijl, formaat, toon, beslissingscriteria). Het is nuttig wanneer je wilt dat het model altijd op een specifieke manier reageert.
• RAG (Retrieval-Augmented Generation): injecteert externe kennis op het moment van inferentie. Het is nuttig wanneer de informatie vaak verandert of te uitgebreid is om in de training te passen.

Als je probleem is dat het model je productcatalogus die wekelijks wordt bijgewerkt niet kent, is fine-tuning een slechte keuze: je zou elke keer opnieuw moeten trainen. Als je probleem is dat het model met een te informele toon reageert voor klantenservice, gaat RAG dat niet oplossen. Volgens officiële documentatie van platforms zoals OpenAI of Anthropic is de gebruikelijke aanbeveling om te beginnen met geavanceerde prompting, dan RAG, en pas daarna fine-tuning te overwegen.

Mythe 3: ‘Het is goedkoop en snel’

De zichtbare kosten van training zijn gedaald, maar de totale kosten niet. Er zijn drie posten die vaak worden genegeerd:

1. Datavoorbereiding: opschonen, dedupliceren, labels herzien en formatteren. In de praktijk kost dit meer tijd dan de training zelf.
2. Evaluatie: je hebt een onafhankelijke validatieset nodig en metrieken die het werkelijke gebruik weerspiegelen. Zonder dit vlieg je blind.
3. Onderhoud: elke keer dat het domein verandert (nieuwe regelgeving, nieuw product, nieuw beleid), kan het aangepaste model verouderd raken en moet de cyclus worden herhaald.

In veel gevallen biedt een goede prompt met voorbeelden (few-shot) en een lage temperatuur 80% van het voordeel met 5% van de inspanning. Fine-tuning is gerechtvaardigd wanneer die resterende 20% cruciaal is voor het bedrijf.

Realiteit: wanneer fine-tuning het verschil maakt

Er zijn scenario’s waarin fine-tuning duidelijk superieur is:

• Vermindering van latentie en kosten per token: een klein aangepast model kan een groot model vervangen bij zeer afgebakende taken, met lagere latentie en lagere inferentiekosten.
• Strikte formaten: wanneer de output een complex JSON-schema of een intern rapportformaat moet volgen, vermindert fine-tuning de noodzaak van latere validaties.
• Zeer specifiek domein met eigen jargon: bijvoorbeeld de classificatie van incidenten in een gereguleerde sector waar het vocabulaire niet in het algemene corpus voorkomt.
• Consistente merkstijl: wanneer de toon deel uitmaakt van het product en niet kan worden gedelegeerd aan instructies die het model soms negeert.

Buiten deze gevallen is het raadzaam je af te vragen of het probleem werkelijk het gedrag van het model betreft of de invoergegevens.

De stapsgewijze aanpak die er echt toe doet (en die meestal niet wordt verteld)

Verder dan het uitvoeren van een trainingsscript heeft het werkelijke proces fasen die het resultaat bepalen:

1. Het succes criterium definiëren voordat je data aanraakt

‘Goed reageren’ is niet hetzelfde als ‘het aantal escalaties naar een mens bij factureringstickets met 20% verminderen’. Zonder een operationele metriek is elke verbetering anekdotisch.

2. Een onafhankelijke evaluatieset opbouwen

Deze moet uit dezelfde distributie komen als de productiedata, maar nooit uit dezelfde trainingsbatch. Een veelgemaakte fout is evalueren met voorbeelden die het model al heeft gezien, wat de resultaten opblaast.

3. De data formatteren volgens de aanbieder

Elk platform verwacht een ander formaat (instructie-antwoordparen, gesprekken met rollen, enz.). Een onjuist formaat kan onopgemerkt blijven en een model opleveren dat de instructies negeert.

4. Trainen met een geschikt basismodel

Niet alle modellen ondersteunen fine-tuning, en degenen die het ondersteunen hebben limieten qua grootte en tokens. Een te klein model kiezen voor een complexe taak leidt tot een aanpassing die niet generaliseert.

5. Evalueren met metrieken en met menselijke beoordeling

Automatische metrieken (nauwkeurigheid, F1, BLEU) vangen nuances van bruikbaarheid niet. Een blinde beoordeling door iemand die niet bij het labelen betrokken was, detecteert problemen die de metrieken verbergen.

6. Implementeren met monitoring

Het aangepaste model kan verslechteren als de invoerdistributie verandert. Zonder driftmonitoring wordt het probleem pas ontdekt wanneer gebruikers klagen.

Beperkingen die je maar beter kunt accepteren

Fine-tuning elimineert hallucinaties niet. Een model dat met correcte data is aangepast, kan nog steeds informatie verzinnen wanneer het iets wordt gevraagd dat buiten zijn distributie valt. Het garandeert ook geen beleidsnaleving: als de dataset ambigue voorbeelden bevat, zal het model die ambiguïteit leren.

Een andere praktische beperking: catastrofaal vergeten. Bij het aanpassen van een model voor een specifieke taak kan het algemene capaciteiten verliezen die het voorheen had. Als je een veelzijdige assistent nodig hebt, kan agressieve fine-tuning de prestaties bij onvoorziene taken verslechteren.

En een transparantie-waarschuwing: er bestaat geen formule die garandeert dat fine-tuning jouw geval zal verbeteren. De beslissing moet gebaseerd zijn op een gecontroleerde test met duidelijke metrieken, niet op beloftes van derden.

Alternatieven die soms winnen

Voordat je gaat aanpassen, is het de moeite waard om te verkennen:

• Prompt engineering met dynamische voorbeelden: de meest relevante voorbeelden voor elke query selecteren op het moment van inferentie.
• RAG met goede embeddings: voor feitelijke en actuele kennis.
• Externe tools: berekeningen of queries delegeren aan API’s in plaats van te verwachten dat het model ze uit het hoofd doet.
• Modellen die al door de aanbieder zijn aangepast: in sommige gevallen dekt een commercieel beschikbaar gespecialiseerd model de behoefte zonder eigen training.

De combinatie van meerdere technieken levert vaak betere resultaten op dan alles op fine-tuning in te zetten.

Conclusie zonder beloftes

Fine-tuning van LLM’s is een krachtige techniek, maar geen snelkoppeling. Het werkt wanneer het probleem gedrag betreft en er voldoende kwaliteitsdata is om dat te definiëren. Het faalt wanneer het wordt gebruikt om veranderende kennis te injecteren, wanneer de data ruis bevat of wanneer wordt verwacht dat een klein model een groot model evenaart in complexe redeneringen. Het verschil tussen een succesvol project en een dat in de la blijft liggen, zit minder in de training en meer in de probleemdefinitie, de eerlijke evaluatie en de bereidheid om te accepteren dat het juiste antwoord soms is om niets aan te passen.