Wanneer een bedrijf voor het eerst een eigen taalmodel gaat fine-tunen, ligt de focus doorgaans op de technische kant: welk model, welk framework, welke GPU. De dataset wordt later geregeld — en precies daar gaat het het vaakst mis. Wij hebben projecten gezien waarbij meerdere dagen GPU-tijd werd geïnvesteerd, terwijl het resulterende model uiteindelijk in een la verdween. Niet omdat de methode verkeerd was, maar omdat de data niet met voldoende zorgvuldigheid was voorbereid.
Dit artikel gaat concreet over de voorbereiding van de dataset: hoeveel voorbeelden u in de praktijk nodig heeft, hoe u kwaliteit meet, wat u doet met duplicaten, hoe u de trainings- en evaluatiesplit instelt, en waarom er zoiets bestaat als een data-sufficiency gate vóórdat u überhaupt begint met trainen.
Waarom de dataset belangrijker is dan de methode
Fine-tuning is in de kern eenvoudig: laat het model zien hoe het in een specifieke context moet reageren, vaak genoeg om het te onthouden. Het probleem ontstaat wanneer wat u het model laat zien niet is wat u eigenlijk wilt — of wanneer u het te weinig laat zien, of te vaak hetzelfde.
Onderzoek naar het trainen van taalmodellen heeft herhaaldelijk aangetoond dat kwaliteit zwaarder weegt dan kwantiteit. Een set van 1.000 zorgvuldig voorbereide, gevarieerde en correcte voorbeelden kan een beter model opleveren dan 50.000 haastig samengestelde voorbeelden met structurele fouten. Dat is contra-intuïtief — de meeste technische teams grijpen instinctief naar een groter volume.
Erger dan onvoldoende data is echter slechte kwaliteit bij voldoende volume. Een model getraind op foutieve, vertekende of tegenstrijdige voorbeelden fixeert die als waarheid. En omdat fine-tuning het vertrouwen van het model in aangeleerde patronen vergroot, is het resultaat een model dat zelfverzekerd antwoord geeft op vragen waarbij het zou moeten aarzelen of "ik weet het niet" zou moeten zeggen. In domeinen als recht, geneeskunde of financieel advies is dat een ernstig probleem.
Richtgetallen: SFT, DPO en GRPO
Niet elke fine-tuning is gelijk. De drie belangrijkste benaderingen hebben elk andere data-eisen:
SFT (Supervised Fine-Tuning) is de basismethode: het model krijgt invoer-uitvoerparen en leert deze na te bootsen. Functionele resultaten zijn haalbaar vanaf ongeveer 1.000 hoogwaardige voorbeelden, maar voor productiesystemen wordt doorgaans gewerkt met 10.000 tot 100.000 paren. Belangrijk is dat deze de belangrijkste scenario's van het domein afdekken — niet alleen de meest voorkomende.
DPO (Direct Preference Optimization) vereist preferentieparen: bij elke invoer heeft u een "betere" en een "slechtere" respons. Het model leert wat uw voorkeur heeft. Dit vereist ofwel annotatie door echte mensen, ofwel betrouwbare geautomatiseerde beoordeling. Het aanbevolen minimum ligt op ongeveer 2.000 door mensen geverifieerde preferentieparen. Onder deze grens bestaat het risico dat het model artefacten van het annotatieproces leert in plaats van werkelijke voorkeuren.
GRPO en geverifieerde beloningen zijn geschikt voor taken met controleerbare correcte antwoorden — wiskunde, code, logica, formaten met een gedefinieerd schema. Het minimum ligt hier op ongeveer 1.000 beoordeelde trajecten, maar de cruciale voorwaarde is dat de beloning werkelijk objectief en automatisch verifieerbaar is. Definieert u de beloning handmatig en subjectief, dan krijgt u dezelfde problemen als bij een slechte DPO-dataset.
Deze getallen zijn minima voor basisfunctionaliteit, geen kwaliteitsgaranties. Voor productie-inzet in gereguleerde sectoren (recht, geneeskunde, farmacie) gelden strengere normen: volledige dekking van alle beoogde scenario's en jurisdicties, niet alleen een representatief sample.
Wat een kwalitatief goed voorbeeld is
Vóórdat we het over volume hebben, moet u definiëren wat u precies van een individueel voorbeeld verwacht.
Een kwalitatief goed SFT-voorbeeld heeft de volgende eigenschappen:
- Correctheid: de uitvoer is feitelijk juist en past bij de context van de invoer
- Consistentie: dezelfde invoer (of een equivalente formulering) krijgt dezelfde categorie van antwoord
- Representativiteit: het voorbeeld dekt een werkelijk scenario, geen kunstmatige testcase
- Helderheid: het model begrijpt uit het voorbeeld ondubbelzinnig wat er van hem verwacht wordt — geen ambiguïteit
- Proportionele lengte: niet onnodig kort (lege patronen) en niet onnodig lang (het model raakt de draad kwijt)
Typische problemen die wij in de praktijk zien:
- Uitvoer gekopieerd uit bestaande documenten zonder bewerking — met daarin fouten uit de originele bron
- Voorbeelden gegenereerd door een LLM zonder menselijke controle — het model leert de hallucinaties van een ander model
- Inconsistente opmaak — afwisselend JSON, Markdown en vrije tekst voor hetzelfde type taak
- Overlappende invoeren met verschillende uitvoeren — het model ontvangt tegenstrijdige signalen
Datasetformaat en bestandsstructuur
De meeste moderne frameworks (Unsloth, Axolotl, LLaMA-Factory, TRL) accepteren standaardformaten. De meest gebruikte zijn:
Alpaca-formaat voor instructietaken: elk voorbeeld heeft de velden instruction, input (optioneel) en output. Eenvoudig en breed ondersteund.
ShareGPT / conversatieformaat voor chatmodellen: voorbeelden zijn gesprekken met een lijst van berichten, waarbij elk bericht een rol heeft (system, user, assistant). Beter geschikt voor multi-turn scenario's.
JSONL (één JSON-object per regel) is het geprefereerde bestandsformaat voor de meeste tools — het maakt gestreamd laden van grote datasets mogelijk zonder het volledige bestand in het geheugen te laden.
Bij de voorbereiding van een DPO-dataset komt er één veld bij: doorgaans chosen en rejected (of equivalente namen volgens het framework) bij elke invoerprompt.
Deduplicatie — de onderschatte stap
Dubbele of bijna-dubbele voorbeelden zijn een van de meest voorkomende problemen in datasets die automatisch of vanuit bedrijfsdocumentatie zijn samengesteld. Het effect is tweeledig: het model leert onevenredig de patronen die in de duplicaten voorkomen (overfit op een subset van de data) en de evaluatie vertekent wanneer duplicaten in zowel de trainings- als de testset terechtkomen.
Basisdeduplicatie werkt op exacte overeenkomst (hash van de invoertekst). Meer geavanceerde benaderingen gebruiken MinHash of embedding-gelijkenis voor de detectie van semantische duplicaten — voorbeelden die qua formulering verschillen maar inhoudelijk gelijk zijn.
Voor domeinspecifieke datasets bevelen wij minimaal de volgende stappen aan:
- 1.Exacte deduplicatie op basis van een hash van de uitvoer
- 2.Controle of verschillende formuleringen van dezelfde invoer leiden tot consistente uitvoeren
- 3.Verwijdering van voorbeelden waarbij zowel invoer als uitvoer korter zijn dan een zinvolle ondergrens (bijv. te korte antwoorden)
Tools zoals de datasets-bibliotheek van Hugging Face of datasketch (MinHash-implementatie) dekken deze stappen zonder dat u eigen code hoeft te schrijven.
Train/eval-split: getallen en redenering
Het opsplitsen van de dataset in een trainings- en evaluatieset is een basisstap, maar in de praktijk worden er onnodig fouten gemaakt.
De standaardsplitsing van 80% training / 20% evaluatie werkt, maar voor kleine datasets (onder ~5.000 voorbeelden) kunt u beter 90/10 gebruiken en de evaluatieset aanvullen met meervoudige kruisvalidatie of een aparte hold-out testset.
De cruciale regel: geen enkel voorbeeld uit de evaluatieset mag in de trainingsset zitten — zelfs geen semantisch duplicaat. Voert u deduplicatie uit, doe dat dan vóór de split, niet erna.
Voor domeinspecifieke fine-tuningdatasets bevelen wij aan de evaluatieset zo samen te stellen dat deze bevat: - Een representatief sample van de belangrijkste scenario's (zelfde verdeling als de training) - Enkele bewuste edge cases en randgevallen - Voorbeelden waarbij het juiste antwoord "ik weet het niet" of "onvoldoende informatie" is — als u dat van het model verwacht
De evaluatieset dient twee doelen: het meten van prestaties tijdens het trainen (validation loss) en de onafhankelijke beoordeling na het trainen. Voor productbeslissingen is de tweede functie waardevoller — de evaluatieset moet daarom door mensen zijn geverifieerd en niet automatisch zijn gegenereerd.
Gerelateerd artikel over het meten van resultaten na het trainen: Hoe meet u of fine-tuning geholpen heeft.
Synthetische data: voordelen en risico's
Voor de meeste domeinprojecten is het volume bestaande door mensen gecreëerde data onvoldoende. De oplossing is uitbreiding van de dataset met synthetische data — data gegenereerd door een sterker (frontier) model op basis van door mensen geschreven seed-voorbeelden.
Een typisch recept: 150–200 door mensen geschreven en geverifieerde seed-voorbeelden → genereer 10 tot 100× zoveel via een teacher-model (Claude Opus, GPT-4o of een vergelijkbaar frontiermodel) → menselijke review van een steekproef (minimaal 10–20%) → filteren op kwaliteit.
Risico's van synthetische data:
- Model collapse: bestaat de trainingsset uitsluitend uit door één teacher-model synthetisch gegenereerde data, dan kopieert het fine-tuned model de zwakheden en eigenaardigheden van dat teacher-model. De lange staart van werkelijke scenario's blijft ongedekt.
- Hallucinaties van het teacher-model: het teacher-model is niet onfeilbaar — het genereert feitelijke fouten die zonder menselijke controle in de training terechtkomen.
- Stijlbias: een sterk teacher-model heeft een uitgesproken antwoordstijl. Is dat niet de gewenste stijl voor uw use case, dan moet u dit expliciet corrigeren in de prompt én bij de controle.
Werken met synthetische data vereist méér discipline in kwaliteitscontrole, niet minder. Meer over dit onderwerp: Synthetische data voor fine-tuning.
Data-sufficiency gate: start het trainen pas als de data klaar is
Een fout die wij keer op keer zien, is het starten van het trainen met een dataset waarvan u van tevoren weet dat die onvolledig is — met de gedachte "dat vullen we later aan". Het probleem is dat onvolledige fine-tuning actief schadelijk kan zijn.
Een model getraind op een dataset die slechts een deel van het domein dekt, leert ook vragen uit het niet-gedekte deel met grote zekerheid te beantwoorden. Het heeft geen mechanisme om te herkennen dat het iets "niet weet" — het kent alleen wat het heeft geleerd. Het resultaat is slechter dan een basismodel dat tenminste weet dat het niet in het domein is gespecialiseerd.
Vóór het starten van het trainen bevelen wij aan het volgende te verifiëren:
- 1.Dekking van de belangrijkste scenario's: heeft u voorbeelden voor elk essentieel type taak dat het model zal uitvoeren?
- 2.Minimaal volume: voldoet u aan de richtgetallen voor de gekozen methode (SFT, DPO, GRPO)?
- 3.Kwalitatieve evaluatieset: heeft u een door mensen geverifieerde evaluatieset die gescheiden is van de trainingsdata?
- 4.Voor gereguleerde sectoren: dekt u alle beoogde jurisdicties en scenario's — niet alleen een representatief sample?
Deze checklist is geen bureaucratie — het is een beveiliging tegen een investering in training die eindigt in een problematisch model. Meer over het kiezen tussen methoden: SFT, DPO, GRPO — welke methode wanneer.
Catastrophic forgetting: wat fine-tuning kapot kan maken
Fine-tuning op een smalle dataset heeft een neveneffect: het model kan gedeeltelijk vergeten wat het vóór het trainen kon. Dit fenomeen — aangeduid als catastrophic forgetting (catastrofaal vergeten) — is wetenschappelijk aangetoond en treedt in de praktijk op.
LoRA en QLoRA beperken dit probleem, omdat de oorspronkelijke gewichten van het model bevroren blijven en de adapters relatief klein zijn. Maar zelfs PEFT-methoden elimineren het probleem niet volledig — bij te agressief trainen (hoge learning rate, grote dataset met smalle verdeling) treedt degradatie van algemene vaardigheden op.
Praktische gevolgen:
- Test niet alleen op de domeinspecifieke evaluatieset, maar ook op algemene benchmarks (minimaal informatief)
- Als het model na fine-tuning faalt op taken waarbij het voorheen goed presteerde, is dat een signaal om de trainingsverdeling of de parameters aan te passen
- Vergelijk het fine-tuned model voor productie-inzet altijd met het basismodel op dezelfde set taken — niet alleen op de domeinset
Checklist vóór de eerste training
Doorloop deze checklist vóórdat u begint met trainen:
- 1.Dataset staat in een standaardformaat (Alpaca of ShareGPT JSONL)
- 2.Exacte deduplicatie is uitgevoerd op de volledige dataset
- 3.Train/eval-split is gedaan vóór enige andere verwerking
- 4.De evaluatieset bevat geen semantische duplicaten uit de trainingsset
- 5.Minimaal 10% van de dataset heeft een menselijke kwaliteitscontrole doorlopen
- 6.De scenariodekking is geverifieerd — geen belangrijke categorieën zijn leeg
- 7.Synthetisch gegenereerde data is gemarkeerd en hun aandeel in de dataset is bewust gekozen
- 8.Voor DPO: elk preferentiepaar heeft een gedefinieerde reden waarom "chosen" beter is dan "rejected"
Deze lijst is niet uitputtend, maar dekt de meest voorkomende oorzaken van problemen die wij zien bij klanten die voor het eerst fine-tunen.
Veelgestelde vragen
Hoeveel voorbeelden heb ik minimaal nodig voor SFT?
Functionele resultaten zijn haalbaar vanaf ongeveer 1.000 hoogwaardige voorbeelden — dit getal is gebaseerd op onderzoek waaruit bleek dat zorgvuldig geselecteerde voorbeelden een groter maar minder kwalitatief dataset kunnen overtreffen. Voor productiesystemen bevelen wij minimaal 10.000 voorbeelden aan met verificatie van de dekking van de belangrijkste scenario's. Voor gereguleerde sectoren gelden strengere criteria.
Kan ik de dataset volledig genereren met een LLM?
Een synthetisch gegenereerde dataset kan het grootste deel van het volume vormen, maar niet de volledige dataset. U heeft door mensen geschreven en geverifieerde seed-voorbeelden nodig (doorgaans 150–200 als minimum) en menselijke review van een steekproef van de synthetisch gegenereerde voorbeelden. Een model dat uitsluitend is getraind op de uitvoer van één teacher-LLM kopieert de fouten en zwakheden van dat model zonder correctie.
Hoe deel ik de dataset op in een trainings- en testset?
De standaardsplitsing is 80% training / 20% evaluatie; voor kleine datasets onder 5.000 voorbeelden liever 90/10. De cruciale regel: voer deduplicatie uit vóór de split, niet erna. De evaluatieset mag geen semantische duplicaten uit de trainingsset bevatten — anders meet u "het vermogen om te onthouden" en niet "het vermogen om te generaliseren".
Wat als ik weinig domeindata heb en die niet synthetisch kan aanvullen?
Overweeg in dat geval RAG in plaats van fine-tuning — RAG (Retrieval-Augmented Generation) vereist geen trainingsdata en werkt goed voor scenario's waarbij u toegang tot kennis nodig heeft, niet een verandering in stijl of antwoordformaat. Fine-tuning is beter geschikt wanneer u het gedrag van het model wijzigt, niet zijn kennis.
Waarom geeft het model na fine-tuning slechtere antwoorden dan ervoor?
De meest voorkomende oorzaken: slechte datasetkwaliteit (fouten in voorbeelden, inconsistente opmaak), onvoldoende scenariodekking (het model heeft "slechts" een deel van het domein geleerd en extrapoleerdt verkeerd naar de rest), of catastrophic forgetting bij te agressief trainen. Meer detail: 7 redenen waarom fine-tuning mislukt.
*De voorbereiding van de dataset is waar het succes van de gehele fine-tuning wordt bepaald — niet pas bij de keuze van de methode of de GPU. Als u zich opmaakt voor uw eerste fine-tuning of niet tevreden bent met de resultaten van een eerdere poging, helpen wij bij MP Industrial Solutions u graag bij het beoordelen van de kwaliteit en structuur van uw data vóórdat u begint met trainen.*