Fine-tuning versus prompting: wanneer ga je trainen?

Bij het ontwikkelen van AI-gestuurde applicaties ontstaat al snel een fundamentele architectuurvraag: los je een taak op door instructies en voorbeelden in de prompt mee te sturen, of pas je de gewichten van het onderliggende taalmodel direct aan via fine-tuning? In de praktijk blijkt prompt engineering voor het overgrote deel van de use-cases het juiste vertrekpunt. Toch kent het meegeven van context in prompts harde fysieke en economische grenzen. Zodra consistentie, latency, strenge outputformaten of schaalgrootte de bottleneck worden, verschuift het zwaartepunt onvermijdelijk naar training.

In dit artikel bekijken we de technische, financiële en operationele factoren die bepalen wanneer je stopt met prompten en start met trainen. We analyseren het mechanische verschil tussen sturen in context en sturen in modelgewichten, vergelijken de totale eigendomskosten (TCO) en behandelen veelgemaakte fouten bij datakwaliteit en modeldegradatie.

1. Het mechanische verschil: werkgeheugen versus spiergeheugen

Om te bepalen welke strategie past, moeten we kijken naar wat er computationeel gebeurt tijdens inference. Wanneer je een model aanstuurt via prompting (inclusief zero-shot, few-shot en chain-of-thought), maak je uitsluitend gebruik van het zogeheten in-context learning vermogen. Alle sturende informatie, regels en voorbeeldinteracties bevinden zich in het contextvenster. De transformer-architectuur berekent via attention-mechanismen de relaties tussen deze tokens. De interne modelgewichten veranderen tijdens dit proces met geen enkele fractie. Je huurt als het ware tijdelijk computationeel werkgeheugen af bij elke API-call.

Bij fine-tuning daarentegen worden de gewichten in de neurale lagen via gradiëntdaling (backpropagation) daadwerkelijk geüpdatet op basis van een samengestelde dataset. Het model leert hierdoor statistische patronen, specifieke syntaxis, schrijfstijlen en domeinspecifieke jargonstructuren permanent herkennen en reproduceren. Waar prompting te vergelijken is met het overhandigen van een handleiding aan een uitzendkracht voor een eenmalige taak, is fine-tuning het structureel trainen van een vaste medewerker totdat de handelingen een automatisme vormen.

Dit onderscheid heeft directe gevolgen voor de betrouwbaarheid. Instructies in prompts kunnen concurreren met eerdere instructies in dezelfde prompt, onderhevig zijn aan het 'lost in the middle'-effect bij lange contexten, of genegeerd worden bij complexe logica. Een gefinetuned model heeft het gewenste gedrag verankerd in zijn parameters, waardoor de kans op afwijkingen van het gedefinieerde format drastisch afneemt.

2. Wanneer prompting superieur is

Prompting is de aangewezen route voor het testen van hypotheses, snelle iteraties en taken die een breed scala aan dynamische kennis vereisen. Zolang de taakomschrijving nog evolueert, is het trainen van een model contraproductief. Een prompt wijzigen en direct testen kost enkele seconden, terwijl het verzamelen van trainingsdata, formatteren, trainen en evalueren uren tot dagen in beslag neemt.

De belangrijkste situaties waarin prompting de beste keuze blijft:

• Veranderlijke feitenkennis: Een taalmodel is geen relationele database. Feiten die wekelijks of dagelijks wijzigen (zoals productprijzen, voorraadstanden of recente wetswijzigingen) horen thuis in een dynamische context via RAG of API-aanroepen, niet in bevroren gewichten.
• Lage tot gemiddelde callvolumes: Zolang een applicatie duizenden in plaats van miljoenen aanvragen per dag verwerkt, wegen de operationele kosten van trainingsinfrastructuur en gespecialiseerd modelbeheer zelden op tegen de eenvoud van een standaard commercieel foundation model.
• Generieke redeneertaken: Grote grensverleggende modellen (zoals Claude 3.5 Sonnet of GPT-4o) beschikken over een enorm pre-training corpus met algemene redeneervaardigheden die je met een kleine eigen trainingsset van 500 voorbeelden op een kleiner model niet eenvoudig evenaart.
• Snel experimenteren en valideren: Voor het systematisch vergelijken van verschillende instructiesets kun je gebruikmaken van rigoureuze testmethodes; raadpleeg de gids over A/B-testen van prompts om te ontdekken hoe je statistisch significante kwaliteitsverschillen meet voordat je overweegt te gaan trainen.

3. De harde triggers voor fine-tuning

Wanneer stuit prompting op zijn grenzen? In productieomgevingen zijn er vier concrete breekpunten die het trainen van een eigen model noodzakelijk of economisch rendabel maken.

A. Tokenverspilling en contextreductie

Als je bij elke API-aanroep 1.500 tokens aan systeemprompts, uitzonderingsregels en five-shot voorbeelden moet meesturen om een JSON-respons van 80 tokens te forceren, betaal je 95 procent van je operationele tokenkosten puur aan overhead. Door het model te trainen op die specifieke input-output relaties, reduceer je de systeemprompt tot enkele tokens (bijvoorbeeld enkel de taaknaam), waardoor de latency keldert en de verwerkingskosten per transactie met een factor tien tot twintig kunnen dalen.

B. Strikte formatering en syntactische deterministiciteit

Hoewel gestructureerde outputs (JSON Schema mode) bij grote API's veel problemen opvangen, falen generieke modellen regelmatig bij exotische DSL's (Domain Specific Languages), obscure XML-schema's of complexe SQL-dialecten. Fine-tuning programmeert de grammatica van de gewenste uitvoer direct in de tokenselectie van het netwerk, waardoor syntaxfouten nagenoeg verdwijnen zonder dat uitgebreide correctielussen nodig zijn.

C. Domeinspecifieke toon, stijl en jargon

In gereguleerde markten, zoals de Nederlandse medische verslaglegging of het notariaat, luistert formulering uiterst nauw. Een prompt als "schrijf in een formele juridische stijl" resulteert vaak in overdreven archaïsch of clichématig taalgebruik. Fine-tuning op tienduizenden geanonimiseerde authentieke documenten zorgt voor een natuurgetrouwe nabootsing van het gewenste register, zonder dat je elke stijlafspraak hoeft uit te sprijven in regels.

D. Privacy, soevereiniteit en lokale hardware

Wanneer data de eigen servers of Europese cloudzone niet mag verlaten wegens strikte AVG-normen, valt het gebruik van gesloten Amerikaanse cloud-API's af. Een compact open-source model (zoals een 8B of 14B model) presteert out-of-the-box vaak onvoldoende op gespecialiseerde taken. Door zo'n compact model gericht te fine-tunen, kan het op één specifieke taak de kwaliteit van een tien keer zo groot cloudmodel evenaren of overtreffen, terwijl het lokaal kan draaien op betaalbare hardware.

4. Vergelijkingsmatrix: prompting versus fine-tuning

De onderstaande tabel zet de twee benaderingen tegenover elkaar op de belangrijkste architectuurdimensies:

5. De economische omslag: rekenen aan de TCO

De keuze tussen beide technieken is in een productieomgeving vaak een nuchtere rekensom. Laten we kijken naar een realistisch scenario met een gespecialiseerde classificatie- en extractietaak:

Stel, een organisatie verwerkt dagelijks 100.000 klantinteracties. Bij een prompting-strategie op een groot commercieel model (zoals Claude 3.5 Sonnet of GPT-4o) bevat elke call een robuuste systeemprompt met edge-cases van 1.200 tokens en een output van 100 tokens. Bij actuele marktprijzen betaal je circa €3,- per miljoen inputtokens en €15,- per miljoen outputtokens. De dagelijkse kosten bedragen dan:

Input:  100.000 calls * 1.200 tokens = 120.000.000 tokens / 1M * €3,00 = €360,- per dag
Output: 100.000 calls *   100 tokens =  10.000.000 tokens / 1M * €15,00 = €150,- per dag
Totaal per dag: €510,-  -->  Jaarlijkse kosten: circa €186.150,-

Kiezen we daarentegen voor een gefinetuned 8B open-source model (zoals Llama 3 of Mistral), dan kan de invoerprompt worden teruggebracht tot enkel de kale brongerelateerde tekst (gemiddeld 200 tokens). De eenmalige trainingskosten bedragen enkele honderden euro's aan GPU-huur, plus de arbeid voor datacuratie. Het model draait vervolgens op twee gehuurde dedicated instances van circa €1,20 per uur:

Hosting: 2 servers * 24 uur * €1,20/uur = €57,60 per dag
Totaal per dag: circa €58,-  -->  Jaarlijkse kosten: circa €21.170,-

De besparing bedraagt in dit scenario meer dan €160.000,- op jaarbasis. Voor wie dieper in deze trade-offs wil duiken: bekijk het uitgebreide dossier op de vergelijkingspagina over kwaliteit versus kosten om te zien hoe latency, modelgrootte en tokenprijzen met elkaar interageren.

6. Trainingsmethoden: van Full Fine-Tuning naar PEFT

Wanneer de beslissing valt om te gaan trainen, hoef je zelden alle miljarden parameters van een model aan te passen. Full Fine-Tuning (waarbij alle gewichten worden bijgewerkt) vereist enorme hoeveelheden VRAM en brengt hoge risico's op overtraining met zich mee. In moderne AI-engineering is Parameter-Efficient Fine-Tuning (PEFT), en in het bijzonder LoRA (Low-Rank Adaptation), de industriestandaard geworden.

Bij LoRA worden de originele gewichtsmatrices van het basismodel bevroren. Er worden kleine, trainbare adapter-matrices parallel geplaatst aan de attention- en feed-forward-lagen. Hierdoor hoef je slechts 0,1% tot 1% van het totale aantal parameters te trainen. Lees voor de exacte wiskundige werking en geheugenberekeningen de diepgaande uitleg over LoRA en adapters.

Hieronder zien we hoe een typisch trainingsrecord voor supervised fine-tuning (SFT) eruitziet in het gangbare ChatML/JSONL-formaat:

{
  "messages": [
    {
      "role": "system",
      "content": "Je bent een gespecialiseerde parser voor Nederlandse notariële akten. Extraheer partijen en registergoed in compact JSON-formaat."
    },
    {
      "role": "user",
      "content": "Vandaag, vijftien augustus tweeduizend zesentwintig, verscheen voor mij, mr. J. de Vries, notaris te Alkmaar: de heer Pieter Bakker, geboren te Haarlem..."
    },
    {
      "role": "assistant",
      "content": "{\"notaris\":\"J. de Vries\",\"standplaats\":\"Alkmaar\",\"datum\":\"2026-08-15\",\"partijen\":[{\"naam\":\"Pieter Bakker\",\"geboorteplaats\":\"Haarlem\"}]}"
    }
  ]
}

Door het model te voeden met 1.000 tot 5.000 van dergelijke hoogwaardige voorbeelden leert het de extractielogica autonoom uit te voeren zonder dat er uitgebreide regeldefinities in de prompt nodig zijn.

7. De risico's: alignment-verlies en catastrofaal vergeten

Fine-tuning is geen risicoloze ingreep. Waar een slechte prompt hooguit resulteert in een eenmalige mislukte API-call, kan een verkeerd getraind model structureel beschadigd raken in zijn basale vaardigheden. Dit fenomeen staat bekend als catastrophic forgetting (catastrofaal vergeten).

Wanneer een model te intensief wordt getraind op een eenzijdige taak (bijvoorbeeld uitsluitend het samenvatten van juridische contracten), overschrijft het optimalisatie-algoritme neurale paden die verantwoordelijk zijn voor algemeen logisch redeneren, meertaligheid of elementaire rekenvaardigheden. Het model wordt een specialist, maar verliest zijn vermogen om contextuele nuances buiten die niche te interpreteren. Om te begrijpen hoe je dit neutraliseert met regularization en gemengde datasets, lees je het artikel over het voorkomen van catastrofaal vergeten bij fine-tuning.

Daarnaast kan fine-tuning de ingebouwde veiligheidsfilters (de safety alignment) van het basismodel onbedoeld verzwakken. Een model dat tijdens zijn pre-training en RLHF-fase zorgvuldig is afgericht om geen kwaadaardige code of gevoelige persoonsgegevens te genereren, kan deze restricties verliezen als de fine-tuning dataset niet zorgvuldig is gefilterd op conformiteit.

8. De hybride route: RAG gecombineerd met Fine-Tuning

In volwassen productiesystemen is de keuze zelden binair. De krachtigste architecturen combineren fine-tuning met Retrieval-Augmented Generation (RAG). Hierbij vervullen beide technieken een complementaire rol:

• De gefinetunede adapter fungeert als de vormgever en stijlexpert: het model weet exact hoe het moet redeneren binnen het domein, hoe het bronverwijzingen structureert en in welk format het antwoord moet worden aangeleverd.
• Het RAG-systeem injecteert de actuele, dynamische documenten in de context: het levert de feitelijke waarheid van de specifieke casus aan.

Een gefinetuned model kan bovendien specifiek worden getraind om beter om te gaan met RAG-contexten. Waar een standaard foundation model soms bezwijkt onder irrelevante zoekresultaten (ruis), kan een getraind model leren om conflicterende bronnen te negeren en uitsluitend te vertrouwen op geverifieerde contextfragmenten.

In moderne software-omgevingen zien we dat engineers deze technieken integreren in autonome agent-architecturen. Wil je weten hoe deze rollen in de markt evolueren, lees dan het dossier over hoe je AI-agent engineer wordt in 2026 voor inzicht in het volledige spectrum van prompt tot modelarchitectuur.

9. Beslisboom voor de praktijk

Om te bepalen welke aanpak op dit moment de juiste is voor een project, kan onderstaand stappenplan als leidraad dienen:

1. Start altijd met prompting: Bouw een prototype met een toonaangevend commercieel model (bijvoorbeeld via zero-shot of few-shot prompting). Valideer of de taak überhaupt computationeel haalbaar is voor een LLM.
2. Optimaliseer de prompt en context: Gebruik gestructureerde formats, chain-of-thought en voeg RAG toe als er specifieke domeinkennis ontbreekt. Meet de baselinekwaliteit met een vaste testset.
3. Analyseer de knelpunten:
   • Is de kwaliteit goed, maar zijn de kosten of latency bij hoge volumes te hoog? → Fine-tune een kleiner open-source model op de outputs van het grote model (distillatie).
   • Blijft het model ondanks uitgebreide prompts structureel falen op syntax of stijl? → Fine-tune op 500 tot 2.000 gecureerde voorbeelden.
   • Moet de data strikt on-premise blijven wegens wet- en regelgeving? → Fine-tune een lokaal open gewichtsmodel met LoRA.
4. Evalueer continu: Vergelijk het gefinetunede model altijd tegen de originele prompting-baseline op zowel taakprestatie als algemeen redeneervermogen om regressie uit te sluiten.