Na het fine-tunen hebt u een nieuw model. De benchmark op de trainingstaak is gestegen. Het team is tevreden. Maar zodra u het model in productie brengt, beginnen klanten vreemde antwoorden te melden in gevallen die voor de training foutloos werkten. Wat is er gebeurd? Er is iets gebeurd wat we keer op keer zien: het model werd alleen geëvalueerd op wat we het hadden geleerd, niet op wat we het per ongeluk hadden afgeleerd.
Evaluatie van een fine-getuned model is een andere discipline dan evaluatie van een productie-LLM-systeem. U vergelijkt niet of uw RAG-pipeline de juiste chunks teruggeeft — u vergelijkt wat een specifieke gewichtswijziging met het model als geheel heeft gedaan. Dit artikel laat zien hoe u dit systematisch aanpakt: van een task-specifieke eval set via vergelijking van base versus fine-tuned tot het detecteren van regressies in algemene vaardigheden.
Waarom "de loss is gedaald" niet volstaat
De training loss vertelt u hoe goed het model zich heeft aangepast aan de trainingsdata. Het vertelt u niets over of het gedrag van het model in de praktijk is verbeterd. En het vertelt u al helemaal niets over wat er met het model is gebeurd buiten het domein waarop u hebt getraind.
In de praktijk zien we drie veelvoorkomende fouten:
- Alleen evalueren op trainingsdata — het model heeft patronen gememoriseerd in plaats van generalisatie geleerd
- Alleen de doeltaak testen — algemene vaardigheden die fine-tuning mogelijk heeft beschadigd worden genegeerd
- Niet vergelijken met het base model — u weet niet wat de meerwaarde van fine-tuning is en wat al een eigenschap van het base model was
Catastrofisch vergeten (catastrophic forgetting) is een reëel verschijnsel, empirisch gedocumenteerd voor meerdere modelfamilies. Fine-tuning op smalle data kan vaardigheden degraderen die het model tijdens pretraining heeft opgedaan — logisch redeneren, opmaak, het opvolgen van instructies, kennis buiten het domein. PEFT-methoden zoals LoRA beperken dit risico, maar elimineren het niet.
Drie lagen van het eval-framework
Een solide evaluatie van een fine-getuned model rust op drie lagen. Elke laag vangt een ander risico op.
1. Task-specifieke eval set
Dit is uw primaire signaal. Het meet of het model de taak beheerst waarvoor u het hebt getraind.
Kernprincipe: held-out test set. Een deel van de gelabelde data die het model nooit heeft gezien tijdens training, moet uitsluitend worden bewaard voor de definitieve evaluatie. Als u dezelfde data gebruikt voor training én evaluatie, is de meting waardeloos — het model kan hebben gememoriseerd in plaats van geleerd.
Praktische werkwijze: 1. Verdeel de dataset vóór de training in training / validatie / test (bijv. 80 / 10 / 10) 2. De validatieset dient voor monitoring tijdens het trainen (early stopping, hyperparameter tuning) 3. De testset wordt eenmalig gebruikt, pas als het trainen klaar is — niet herhaaldelijk voor afstelling
Voor de meting zelf hebt u evaluatie met een gedefinieerd correct antwoord nodig voor uw taak. De formaten variëren per taaktype:
- Classificatie / routing — nauwkeurigheid (accuracy), F1-score, confusion matrix
- Entiteitsextractie / gestructureerde output — token-level F1, exact match, of een eigen parser
- Generatieve taken — dit wordt ingewikkelder: BLEU/ROUGE heeft een lage correlatie met menselijke kwaliteitsbeoordeling voor LLM's; beter zijn LLM-as-judge (een frontier-model beoordeelt het antwoord) of eigen rubrics
Voor de meeste B2B-domeinuse cases adviseren we 100–500 vragen met referentie-antwoorden handmatig samen te stellen en te laten valideren door een domeinexpert. Dit is uw gouden standaard. De hoeveelheid doet er minder toe — wat telt is de dekking van gevaltypes en edge cases die in de praktijk het meest relevant zijn.
2. Vergelijking base versus fine-tuned
Evalueer het fine-getuned model altijd in vergelijking met het base model, niet alleen in absolute termen. De reden: u moet weten wat fine-tuning werkelijk heeft toegevoegd ten opzichte van wat u gratis had gekregen.
Een typische resultaattabel moet bevatten:
- Base model (zonder fine-tuning) op uw task-specifieke test
- Fine-getuned model op dezelfde test
- Delta (verbetering of verslechtering)
Als het fine-getuned model het base model met slechts 2–3 % overtreft, overweeg dan kritisch of het de onderhoudskosten waard is. Als de delta negatief is, hebt u een probleem — ofwel met de datakwaliteit, ofwel met de trainingsinstelling.
De vergelijking onthult ook wanneer fine-tuning geen oplossing is. We hebben gevallen gezien waarbij het base model met een goed afgestelde prompt (systeemprompt, few-shot-voorbeelden) 90 % behaalde van wat het fine-getuned model haalde — zonder trainingskosten en zonder regressierisico. Voor deze gevallen adviseerden we klanten RAG vs. fine-tuning — wanneer welke aanpak als eerste stap vóór het trainen.
3. Regressie in algemene vaardigheden
Dit is de laag die de meeste teams overslaan — en precies hier schuilen de problemen die zich pas in productie manifesteren.
Fine-tuning op een smal domein kan het volgende beschadigen:
- Instructieopvolging — het model begint delen van de prompt te negeren of het antwoordformaat te wijzigen
- Weigering om out-of-domain-vragen te beantwoorden — het model probeert ook vragen domeinspecifiek te beantwoorden waarvoor het eigenlijk "weet ik niet" zou moeten zeggen
- Logisch redeneren — scores op redeneerttaken kunnen dalen
- Taalvaardigheden — als u op één taal hebt getraind, kunnen andere talen degraderen
Voor het detecteren van regressies gebruiken we een combinatie van benaderingen:
a) Standaardbenchmarks als sanity check
lm-evaluation-harness van EleutherAI maakt het mogelijk het model op standaardbenchmarks te draaien (MMLU en vergelijkbare). Verwacht niet dat het fine-getuned model beter scoort op MMLU dan het base model — dat is niet het doel. U controleert of de score niet significant is gedaald (meer dan enkele punten is reden voor nader onderzoek).
b) Behavioral regression set
Stel een eigen set voorbeelden samen die vaardigheden dekt die belangrijk zijn voor uw applicatie, maar niet direct verband houden met het trainingsdomein. Bijvoorbeeld: - Outputopmaak (JSON, Markdown, tabellen) - Weigering van onzinnige vragen - Instructieopvolging (het opvolgen van meerdere voorwaarden in een prompt) - Feitelijke nauwkeurigheid in gebieden buiten het domein
Deze set kunt u eenmalig samenstellen en bij elke volgende ronde fine-tuning hergebruiken. De investering betaalt zich terug bij de derde en vierde ronde, wanneer u zonder deze set het overzicht kwijtraakt.
c) Vergelijking van de antwoorddistributie
Een pragmatische aanpak: neem 200–500 echte invoeren uit productie (of staging), draai ze door zowel het base- als het fine-getuned model en vergelijk de distributie van de antwoordlengte, de frequentie van weigeringen en — als u LLM-as-judge hebt ingesteld — de distributie van beoordelingen. Statistische afwijkingen signaleren een probleem voordat gebruikers het melden.
De held-out test set goed opzetten: wat fout gaat
Een held-out test set klinkt eenvoudig, maar in de praktijk gaat het op meerdere punten mis.
Distributiebesmetting: Als u trainingsdata synthetisch hebt gegenereerd (via een teacher-model) en de test set ook via hetzelfde proces hebt aangemaakt, meet u alleen hoe goed het model de teacher nabootst — niet hoe goed het de echte taak oplost. De test set moet afkomstig zijn van echte gevallen of gevalideerd zijn door een domeinexpert.
Temporele scheiding: Voor productiesystemen met regelmatige fine-tuning is het cruciaal dat de test set temporeel gescheiden is van de trainingsset. Als u traint op data uit Q1 en test op Q1-data (zelfs een aparte set), kunt u de distributieverschuiving missen die in Q2 optreedt. Idealiter is de test set afkomstig uit een ander tijdvenster dan de training.
Omvang en representativiteit: Een test set van 50 voorbeelden is te klein voor statistisch betrouwbare conclusies voor de meeste taken. Voor binaire classificatie hebt u in de orde van 300–500 voorbeelden nodig om het 95%-betrouwbaarheidsinterval smal genoeg te houden voor besluitvorming. Voor generatieve taken met LLM-as-judge zijn kleinere sets bruikbaar, maar interpreteer met voorzichtigheid.
Lekkage via augmentatie: Als u voor de augmentatie van trainingsdata parafrasen of variaties van echte voorbeelden hebt gebruikt, controleer dan dat geen enkele variatie in de test set is terechtgekomen.
Praktische eval-pipeline stap voor stap
Voor teams die fine-tuning voor het eerst doen of slechts incidenteel, adviseren we deze minimalistische aanpak:
- 1.Vóór de training: Reserveer de test set (minimaal 10 % van de data, gebruik deze nooit bij training), leg de baselinescores van het base model vast op zowel de task-specifieke eval als de behavioral regression set.
- 1.Tijdens het trainen: Monitor de validatieloss (val loss) — die moet samen met de trainingsloss dalen. Als de val loss stagneert of stijgt terwijl de train loss daalt, overfit u het model. Stop het trainen en probeer minder epochs of een hogere
rankvan de adapter.
- 1.Na het trainen: Draai het model op de task-specifieke test set. Vergelijk met het base model. Draai de behavioral regression set. Vergelijk met het base model.
- 1.Vóór uitrol: LLM-as-judge op een steekproef van echte invoeren (indien beschikbaar). Handmatige review van ten minste 20–30 concrete gevallen — cijfers liegen, het lezen van antwoorden onthult patronen die metrics niet zien.
De volledige pipeline kunt u inkaderen met tools als lm-evaluation-harness, een eigen Python-script bovenop vLLM of Ollama, of cloud-evalplatforms. Voor de meeste op maat gemaakte B2B-projecten volstaat een eigen script — overschat de infrastructuur niet wanneer u alleen een betrouwbaar antwoord nodig hebt op de vraag "is het model beter".
Wanneer is een regressie te groot om te accepteren
Er bestaat geen universele grens. Het hangt af van de use case. Enkele richtlijnen:
De task-specifieke verbetering moet de regressie in algemene vaardigheden overtreffen. Als fine-tuning de domeinnauwkeurigheid met 15 punten heeft verbeterd maar de instructieopvolging met 20 % is gedaald, is het resultaat negatief — het onjuiste antwoordformaat maakt het model minder bruikbaar, ook in precies het domein waar u het heeft verbeterd.
Nul verbetering op de task-specifieke test is reden om te stoppen. Als het base model met een few-shot-prompt dezelfde resultaten behaalt als het fine-getuned model, was fine-tuning niet nodig. We zien dit bij klanten vaker dan verwacht — ze onderschatten wat een goede prompt kan bereiken.
Significante regressie in het weigeren van out-of-domain-vragen is een ernstig probleem. Een model dat getraind is om technische vragen over een specifiek product te beantwoorden, mag niet via hallucinaties ook vragen gaan beantwoorden waarvoor het juiste antwoord "dat weet ik niet" zou zijn. Deze regressie is een direct veiligheidsrisico in gereguleerde sectoren. Dit hangt samen met het onderwerp guardrails voor AI-agenten, waarbij het weigeringsmechanisme de eerste verdedigingslinie is.
Continue evaluatie: als u fine-tuning herhaalt
Domeinmodellen worden niet eenmalig getuned — als u het goed doet, brengt elke nieuwe batch data een nieuwe fine-tuningronde mee. In dat geval is systematische evaluatie nog belangrijker, omdat u de trend over iteraties heen moet volgen, niet alleen absolute cijfers.
We adviseren een eenvoudige registratie bij te houden van elke ronde: - Datum van training en modelversie (base + fine-tuned) - Omvang van de trainingsset en databron - Task-specifieke score (base / fine-tuned / delta) - Behavioral regression score - Notities over anomalieën of handmatige review
Deze registratie is een investering die zich terugbetaalt bij het debuggen van regressies in een productiesysteem. Zonder haar komt het team erachter dat "er iets is veranderd na de laatste training" — maar niet wat, wanneer, of waarom.
Voor teams die regelmatige fine-tuning plannen met een cyclus van minder dan een maand, loont het om na te denken over een geautomatiseerde eval-pipeline — elke commit van een nieuw model triggert automatisch de task-specifieke eval en de regression set, en de resultaten worden gelogd. Dit investeringsniveau is zinvol bij productiesystemen waar het model direct in de klanteninteracties zit.
Veelgestelde vragen
Hoeveel voorbeelden heb ik nodig in de test set?
Voor de meeste B2B-domeinttaken adviseren we minimaal 100–300 handmatig gevalideerde voorbeelden. Onder de 100 is de statistische betrouwbaarheid laag — een kleine dataset maakt het moeilijk om echte verbetering te onderscheiden van willekeurige spreiding. Voor binaire classificatie is 300–500 een redelijke ondergrens voor een 95%-betrouwbaarheidsinterval. Voor generatieve taken met LLM-as-judge kunt u met een kleinere set werken, maar interpreteer met meer voorzichtigheid.
Wat is LLM-as-judge en wanneer gebruikt u het?
LLM-as-judge is een techniek waarbij een frontier-model (bijv. uit de Claude Sonnet- of GPT-familie) de antwoorden van het fine-getuned model beoordeelt op basis van gedefinieerde criteria — nauwkeurigheid, relevantie, opmaak, toon. Het is nuttig voor generatieve taken waar geen eenduidig "correct antwoord" bestaat. Nadelen: het voegt kosten toe (API-aanroepen), en de judge kan zijn eigen biases hebben (voorkeur voor langere antwoorden, formele stijl). Voor domein-specifieke B2B-applicaties adviseren we een combinatie: LLM-as-judge voor de algehele kwaliteit + deterministische metrics (exact match, parser) voor kritieke velden.
Hoe detecteert u catastrofisch vergeten zonder een uitgebreide benchmarkset?
Een pragmatische aanpak: neem 50–100 echte prompts die het model vóór fine-tuning correct afhandelde, en controleer of het dat ook na het trainen nog doet. Als u toegang hebt tot de logs van het productiesysteem, bekijk dan voorbeelden met hoge gebruikersbeoordeling — dit zijn goede bronnen voor de behavioral regression set. Een combinatie met een snelle handmatige doorlichting van 20–30 antwoorden onthult de meeste problemen voordat ze bij de klant terechtkomen.
Waarom daalt de val loss, maar verbetert de antwoordkwaliteit niet?
Een klassiek geval van overfitting of een distributiemismatch tussen training en werkelijk gebruik. De validatieloss daalt wanneer het model de validatieset beter fit — maar als de validatieset de werkelijke invoeren niet weerspiegelt, is die loss een slechte proxy voor de werkelijke kwaliteit. Een andere oorzaak: een te lage learning rate of rank van de adapter, waardoor het model alleen oppervlakkige patronen heeft geleerd. Probeer de rank te verhogen (bijv. van 8 naar 16 of 32) en controleer of de validatieset representatief is. Verwante onderwerp: waarom fine-tuning mislukt.
Wanneer is het zinvol om fine-tuning te herhalen in plaats van RAG?
Herhaal fine-tuning als het domein gestabiliseerd is en u een consistente aanvoer van nieuwe gelabelde voorbeelden uit productie hebt. Als de domeinkennis snel verandert (nieuwe producten, gewijzigde regelgeving), is RAG flexibeler — u schrijft de wijziging in de kennisbank, niet in de modelgewichten. Voor een beslissing over de combinatie van beide benaderingen, zie dataset voor fine-tuning — hoeveel en welke kwaliteit.
*Overweegt u uw eigen model te fine-tunen en weet u niet hoe u het evalproces moet opzetten? Dan kijken wij graag mee naar uw specifieke use case. Bij MP Industrial Solutions helpen we bedrijven de volledige pipeline te ontwerpen — van data via training tot evaluatie — zodat u vóór uitrol naar productie weet wat het model werkelijk aankan.*