Fine-tuning is een van de meest gebezigde begrippen in elk AI-roadmapdocument. "We trainen een eigen model dat onze domein begrijpt." In theorie elegant. In de praktijk zagen we hetzelfde project op zeven verschillende punten uiteenvallen — en elke keer om een andere reden. Dit artikel gaat niet over hoe u fine-tuning uitvoert — het gaat over waarom het merendeel van de pogingen de productie niet haalt, en hoe u deze valkuilen vermijdt voordat u tijd en budget verspeelt.
Als u nog afweegt of u überhaupt naar fine-tuning moet grijpen of liever naar RAG, lees dan eerst RAG vs. fine-tuning — wanneer welke aanpak. De oorzaken van mislukking die we hieronder beschrijven beginnen namelijk precies daar.
---
1. Te weinig data — of data van slechte kwaliteit
Dit is de meest voorkomende oorzaak van mislukking. Het team verzamelt wat voorhanden is — een paar honderd interne documenten, een CRM-export, een handvol geëxporteerde e-mails — en start de training. Het resultaat is een model dat met grote zekerheid verkeerde antwoorden geeft: slechter dan het basismodel, dat minstens "ik weet het niet" kan zeggen.
Onderzoek heeft aangetoond (LIMA en andere publicaties) dat een relatief klein aantal hoogwaardige voorbeelden — in de orde van duizend — een beter model kan opleveren dan tienduizenden kwalitatief zwakke. Kwantiteit zonder kwaliteit is in dit geval actief schadelijk.
Een praktische maatstaf:
- SFT (supervised fine-tuning): minimaal ~1.000 kwalitatief hoogwaardige vraag-antwoord- of taakvoltooiingsparen, met dekking van de voornaamste onderwerpen in uw domein. Productiesystemen zitten doorgaans op 10.000–100.000 voorbeelden.
- DPO (preference tuning): ~2.000 voorkeursparen met een door mensen geverifieerde winnaar/verliezer.
- GRPO (RL-based tuning): ~1.000 gescoorde trajectories met verifieerbare beloningen.
Naast de hoeveelheid telt dekking — als uw KB (kennisbank) onvoldoende voorbeelden bevat voor een bepaald subdomein, zal het model in dat gebied hallucineren. Wij adviseren dan ook om vóór de training een topic-coverageaudit uit te voeren: stel de voornaamste vraagcategorieën op die het model moet verwerken, en controleer of u voor elk daarvan voldoende voorbeelden hebt.
---
2. Overfitting — het model kent alleen wat het heeft gezien
Wanneer de dataset te klein of te smal is en het model er te lang op getraind wordt, treedt overfitting op. Het model presteert uitstekend op de trainingsvoorbeelden, maar faalt of hallucineerd bij de geringste afwijking — een iets anders geformuleerde vraag, een andere context, ongewone invoer.
Tekenen van overfitting in de praktijk:
- Het model citeert letterlijk trainingsvoorbeelden in plaats van te generaliseren.
- Hoge score op trainingsdata, beduidend lagere score op nieuwe voorbeelden.
- Het model weigert vragen buiten de distributie van de trainingsdata te beantwoorden, in plaats van onzekerheid toe te geven.
Technische maatregelen: monitor de validation loss tijdens de training en stop wanneer die begint te stijgen (early stopping). Volg de eval-metrics op een hold-out set, niet alleen op de trainingsdata. Voor kleine datasets zijn regularisatie en een lagere rank bij LoRA-adapters (bijv. rank=8 in plaats van rank=64) betere instellingen.
---
3. Catastrophic forgetting — het model vergeet wat het wist
Fine-tuning op smalle domeindata kan de algemene capaciteiten van het model degraderen — het vermogen om te analyseren, samen te vatten, te redeneren in het Engels of andere talen, en de basislogica. Dit verschijnsel heet catastrophic forgetting (catastrofaal vergeten) en is goed gedocumenteerd.
In de praktijk ziet het er zo uit: door fine-tuning op interne technische documenten bereikt u dat het model uitstekend antwoord geeft op vragen uit uw vakgebied — maar het houdt op te werken bij algemene taken die het voorheen moeiteloos afhandelde. Klanten die dit verschijnsel niet kennen, interpreteren het als "het model is kapot".
Wat het probleem vermindert, maar niet wegneemt:
- LoRA / QLoRA — adapters passen slechts een klein aantal parameters aan; de oorspronkelijke gewichten blijven bevroren. Dit is de meest effectieve praktische maatregel om forgetting te beperken.
- Merging — het fine-tuned model wordt met het basismodel samengevoegd via tools als
mergekit(SLERP, TIES). Het resultaat balanceert domeinkennis en algemene capaciteiten. - Diversificatie van de dataset — opname van general-purpose voorbeelden in de trainingsdata naast de domeinspecifieke.
Voor gereguleerde sectoren (geneeskunde, recht, farmacie) is forgetting bijzonder kritisch — een model dat zijn logica en veiligheidspatronen is vergeten, kan inhoudelijk overtuigende maar feitelijk onjuiste uitvoer produceren.
---
4. Verkeerde methodetkeuze — full fine-tuning waar LoRA volstaat, of omgekeerd
Teams die beginnen met fine-tuning neigen naar een van beide extremen: volledig fine-tuning dat enorme GPU-resources vereist, of andersom de zuinigste variant kiezen zonder de trade-offs te overwegen.
Een indicatief overzicht van VRAM-vereisten voor een 7B-model:
- Volledig fine-tuning (BF16): ~70–120 GB — vereist een multi-GPU-server
- LoRA (16-bit): ~15 GB — A100 of één RTX 4090 (24 GB VRAM)
- QLoRA (4-bit): ~5 GB — past op een RTX 3090 met 24 GB VRAM
LoRA bereikt doorgaans ~90–95% van de kwaliteit van volledig fine-tuning bij een 10–20× lagere geheugenbehoefte. Voor de meeste domeinspecifieke use-cases is dit voldoende — kiezen voor volledig fine-tuning zonder duidelijke motivatie is verspilling van resources.
Aan de andere kant zijn er gevallen waar LoRA tekortschiet: wanneer de tokenizer wordt gewijzigd, bij talen met een sterk afwijkende morfologie ten opzichte van de trainingsdata, of bij diepgaand "continued pretraining" (het opbouwen van domeinkennis vanuit ongelabelde teksten). De methodekeuze moet voortkomen uit het concrete doel, niet uit wat toevallig als eerste werd gestart. Een uitgebreider overzicht vindt u in het artikel LoRA vs QLoRA vs full fine-tuning.
---
5. Fine-tuning in plaats van RAG — het verkeerde gereedschap voor de verkeerde taak
Dit is wellicht de duurste vergissing die we tegenkomen. Het team wil dat het model "kennis heeft" over hun producten, documenten en interne processen. Fine-tuning lijkt het logische antwoord. Ze starten het op, gieten de data in de training, en ontdekken weken later dat het model feiten blijft hallucineren — want fine-tuning voegt op onbetrouwbare wijze feiten toe aan het model.
Fine-tuning is het juiste gereedschap voor:
- Het veranderen van formaat en antwoordstijl (bijv. altijd JSON teruggeven met een specifiek schema).
- Het veranderen van gedrag (bijv. het model weigert altijd bepaalde typen verzoeken, of hanteert een specifieke communicatietoon).
- Het aanpassen aan een gespecialiseerd domein waar het basismodel onvoldoende trainingsdata heeft (bijv. smal industrieel jargon, proprietaire formaten).
RAG (Retrieval-Augmented Generation — door retrieval verrijkte generatie) is het juiste gereedschap voor:
- Toegang tot actuele of veranderende informatie.
- Beantwoording van vragen op basis van specifieke documenten.
- Traceerbaarheid van het antwoord naar de bron (citaat, grounding).
In de praktijk: als uw doel is "het model moet vragen kunnen beantwoorden uit onze productcatalogus" — dat is een RAG-use-case, geen fine-tuning. Fine-tuning zet u in als u wilt dat het model uw specifieke antwoordformaat of de terminologie van uw sector hanteert.
---
6. Geen evaluatie — we weten niet of we gewonnen of verloren hebben
Een verrassend veel voorkomend scenario: het team voert fine-tuning uit, het model wordt getraind, lijkt "beter" op een paar handmatig geteste voorbeelden, en gaat live. Een maand later komen er klachten over regressie — het model werkt niet meer voor gevallen die het eerder moeiteloos afhandelde.
Zonder systematische evaluatie (beoordeling van de modelkwaliteit) weten we niet:
- 1.Of fine-tuning überhaupt geholpen heeft — vergelijking met het basismodel.
- 2.Of we geen regressie hebben veroorzaakt — prestatie op eerder werkende gevallen.
- 3.Waar het model precies faalt — in welke vraagcategorieën.
Een minimaal eval-framework vóór livegang bevat:
- Hold-out testset — ~10–20% van de data die niet in de trainings- of validatieset zat. Hierop meet u na de training.
- Baselinevergelijking — dezelfde vragen aan zowel het basismodel als de fine-tuned versie. Regressie = als het fine-tuned model lager scoort op gevallen waar het basismodel goed functioneerde.
- Taakspecifieke metrics — niet alleen perplexity (een technische machine-learning-metric), maar metrics die relevant zijn voor uw use-case: nauwkeurigheid van extracties, correctheid van het formaat, kwaliteitsbeoordeling door een domeinexpert.
Meer over het opzetten van evaluatie: Hoe meet u of fine-tuning heeft geholpen.
---
7. Onrealistische verwachtingen — fine-tuning is geen wondermiddel
De laatste, maar in veel opzichten belangrijkste oorzaak. Fine-tuning wordt in interne presentaties vaak verkocht als de oplossing die van een generiek LLM een expert in uw vakgebied maakt. In de praktijk is het genuanceerder:
- Een fine-tuned 4B–8B-model kan een generiek 70B+-model verslaan op een nauw gedefinieerde taak — maar alleen als die taak werkelijk nauw gedefinieerd is, de data kwalitatief hoogwaardig zijn en de evaluatie dat bevestigt.
- Fine-tuning verbetert geen redeneervaardigheden — als het basismodel een bepaald type logische taken niet kan oplossen, verandert fine-tuning op domeindata dat niet. Voor redeneren zijn methoden als GRPO met verifieerbare beloningen geschikter. Meer hierover in het artikel SFT, DPO, GRPO — welke methode wanneer.
- Fine-tuning is geen eenmalig project — data veranderen, het model veroudert, regressies stapelen zich op. Zonder infrastructuur voor herhaalbare trainings-eval-deploy-cycli valt het project geleidelijk uit elkaar.
- Hallucinaties blijven bestaan — fine-tuning kan ze in een specifiek domein verminderen, maar elimineert ze niet. Guardrails, RAG-grounding en human-in-the-loop blijven noodzakelijk waar correctheid telt.
Teams die deze beperkingen kennen vóórdat ze beginnen, eindigen met bruikbare modellen. Teams die de beperkingen na zes maanden ontwikkeling ontdekken, stoppen het project doorgaans.
---
Samenvatting: checklist vóór projectstart
Voordat u besluit een fine-tuning-project te starten, adviseren wij de volgende zeven vragen te doorlopen:
- 1.Hebt u een voldoende dataset? — aantal voorbeelden, onderwerpsdekking, geverifieerde kwaliteit.
- 2.Is fine-tuning het juiste gereedschap? — of zou RAG of prompt engineering voldoende zijn?
- 3.Hebt u evaluatie ingericht? — hold-out set, baseline, taakspecifieke metrics.
- 4.Beschikt u over GPU-infrastructuur? — of een realistisch plan voor cloudtraining met een kostenraming.
- 5.Bent u voorbereid op iteratie? — één fine-tuning-run is onvoldoende; de pipeline moet herhaalbaar zijn.
- 6.Hebt u een domeinexpert in de loop? — wie verifieert dat het model correct antwoordt, niet alleen vloeiend.
- 7.Hebt u een plan voor forgetting en regressies? — monitoring, rollback, evaluatie na elke nieuwe trainingsrun.
Als een van deze vragen geen duidelijk antwoord heeft, is het project niet klaar voor de start — alleen voor voorbereiding.
---
Veelgestelde vragen
Waarom antwoordt mijn fine-tuned model slechter dan het basismodel?
De meest voorkomende oorzaak is overfitting op een kleine of kwalitatief zwakke dataset. Het model leert "patronen" uit de trainingsdata, maar de generalisatie naar nieuwe invoer mislukt. Oplossing: de datakwaliteit verbeteren, early stopping toepassen, de rank van de LoRA-adapter verlagen, of het hele project heroverwegen vanuit het perspectief RAG vs. fine-tuning.
Hoeveel voorbeelden heb ik echt nodig voor fine-tuning?
Voor SFT is een bruikbaar resultaat mogelijk vanaf ~1.000 hoogwaardige voorbeelden, maar productiesystemen zitten doorgaans op 10.000–100.000. Belangrijker dan kwantiteit is dekking — als er onvoldoende voorbeelden zijn in de sleutelcategorieën, zal het model in die gebieden onbetrouwbaar zijn, ongeacht het totale aantal voorbeelden.
Is fine-tuning geschikt om de kennis van het model bij te werken (nieuwe producten, prijzen, records)?
Nee. Fine-tuning slaat feiten op onbetrouwbare wijze op — het model kan informatie uit de training suggereren, maar mengt die ook met hallucinaties. Voor kennis die verandert of verifieerbaar moet zijn, is RAG met een actuele documentendatabase het juiste gereedschap.
Kan een klein fine-tuned model een groot generiek model verslaan?
Ja — onder bepaalde voorwaarden. Een fine-tuned 4B–8B-model kan op een nauw gedefinieerde taak een generiek 70B+-model verslaan, mits de taak goed afgebakend is, de dataset kwalitatief hoogwaardig is en de evaluatie dat bevestigt. Op brede, algemene taken wint het grotere model doorgaans.
Wat is catastrophic forgetting en hoe voorkom ik het?
Catastrophic forgetting is het verschijnsel waarbij fine-tuning op smalle data de algemene capaciteiten van het model degradeert — talen, logica, redeneren. De meest effectieve maatregel is LoRA of QLoRA, die slechts een klein aantal parameters aanpassen en de oorspronkelijke gewichten bewaren. Aanvullend helpt het mergen van het fine-tuned model met het basismodel via het tool mergekit.
---
*MP Industrial Solutions helpt bedrijven onderscheid te maken wanneer fine-tuning werkelijk zinvol is en wanneer er een eenvoudiger en goedkoper pad beschikbaar is. Overweegt u domeinadaptatie van een LLM, dan beoordelen wij graag uw use-case — van dataset tot infrastructuur en evaluatie.*