AI fine-tuning service: domeinmodellen die uw data echt begrijpen

Generieke LLM's zijn krachtig, maar leveren zelden uitkomsten die qua tone-of-voice, vakjargon of structured-output kloppen voor uw organisatie. Wij fine-tunen open-source modellen (Llama, Mistral, Qwen, Gemma) en gehoste modellen op uw eigen instructie-data, zodat een kleiner, goedkoper model in productie het wint van een dure general-purpose API. Van dataset-curatie en supervised fine-tuning tot DPO, evaluatie en deployment op vLLM of Inferentia.

Supervised fine-tuning LoRA / QLoRA DPO Continued pretraining Evaluatie & guardrails vLLM deployment
Bespreek uw fine-tuning case Wel of niet fine-tunen?
Base model Llama-3.1-8B + instructie-data SFT / LoRA + preferenties DPO / RLHF Fine-tuned model eval pass@1 87% cost / 1k tok -72% vLLM TGI GGUF

Wanneer fine-tunen, wanneer RAG, wanneer alleen prompting

De grootste fout in AI-projecten van 2024 en 2025: fine-tunen omdat het kan, terwijl een betere prompt of een retrieval-augmented setup meer oplevert. Fine-tuning is duur, vereist hercurated data en moet bij elke base-model-update opnieuw. Daarom starten wij elk traject met een nuchtere beslisboom.

Fine-tuning is de juiste keuze wanneer u patronen wilt overdragen die niet in een prompt passen — een schrijfstijl, een specifieke output-structuur, vakjargon, of een redeneerketen die het basismodel niet uit zichzelf produceert. Voorbeeld: een uitgever die wil dat samenvattingen exact in de huisstijl staan, of een juridisch team dat memo's volgens een vaste structuur opgesteld wil hebben. Daar werkt prompting eindeloos brittle, terwijl een paar duizend gecureerde voorbeelden in een SFT-set het probleem permanent oplossen.

RAG (retrieval-augmented generation) is de juiste keuze wanneer u kennis wilt toevoegen die regelmatig verandert: productcatalogi, documentatie, beleidsteksten, klantdossiers. Een fine-tuned model dat feiten heeft "geleerd" wordt verouderd; een RAG-pipeline die dezelfde feiten ophaalt uit uw eigen kennisbank blijft actueel. In de praktijk combineren we beide: een model dat fine-tuned is op uw schrijfstijl en outputformaat, gevoed door RAG voor de actuele content. Dat patroon ziet u terug bij custom LLM-integraties en in AI-documentverwerking.

SituatieAanpakWaarom
Vaste output-structuur of JSON-schemaSupervised fine-tuning (SFT)Een paar honderd golden samples leveren strakkere structured-output dan welke prompt dan ook.
Vakjargon en domein-redenerenContinued pretraining + SFTEerst onbegeleid trainen op domein-corpus, daarna instructie-tunen voor taakgedrag.
Tone-of-voice of huisstijlSFT met paired examplesStijl is patroon, geen feiten — fine-tuning brandt het in.
Voorkeursgedrag tussen twee goede antwoordenDPO (Direct Preference Optimization)Goedkoper en stabieler dan klassieke RLHF, geen reward-model nodig.
Actuele feiten of frequent wisselende contentRAG (geen fine-tuning)Fine-tuned feiten verouderen; retrieval blijft live.
Eenmalige taak, <100 voorbeeldenFew-shot promptingFine-tuning loont pas vanaf ~500-1000 kwalitatieve samples.

Methoden die wij toepassen

Fine-tuning is geen monoliet. Welke techniek past, hangt af van uw budget, dataset-grootte, hosting-eisen en het soort gedrag dat u wilt overdragen.

SFT

Supervised fine-tuning

De werkpaard-techniek. We trainen het model op gepaarde input-output-voorbeelden — uw instructie-data. Geschikt voor structured output, taakuitvoering, format-conformiteit en stijloverdracht. Werkt op vrijwel elke modelschaal van 1B tot 70B parameters.

LoRA

LoRA en QLoRA

Parameter-efficient fine-tuning waarbij we kleine adapter-matrices trainen in plaats van het hele model. QLoRA voegt 4-bit quantisatie toe waardoor we 70B-modellen op één H100 of zelfs een 24GB-consumer-GPU kunnen tunen. Dramatisch goedkoper dan full fine-tuning, en de adapters zijn klein genoeg om per klant of taak apart op te slaan.

DPO

Direct Preference Optimization

Een alignment-techniek voor situaties waar twee correcte antwoorden bestaan en u het ene boven het andere wilt. We gebruiken DPO als opvolger van klassieke RLHF — geen apart reward-model, geen instabiele PPO-runs, wel directe voorkeursdata. Geschikt voor toon, beleefdheid, weigerings-gedrag en hallucinatie-onderdrukking.

CPT

Continued pretraining

Voor extreem domein-specifieke taal — medische literatuur, juridische jurisprudentie, technische normen — trainen we het model door op een ongelabelde corpus voordat we instructie-tunen. Hiermee bouwen we een base model dat het vocabulaire en de redeneerstijl van uw domein begrijpt. Vereist meer GPU-tijd maar levert een fundamenteel competenter startpunt.

PEFT

Adapters en PEFT-varianten

Naast LoRA bestaan adapters, prefix-tuning, IA3 en prompt-tuning. We kiezen de PEFT-methode op basis van model-architectuur, hoeveelheid trainingsdata en deployment-eisen. Voor multi-tenant deployments zijn adapters bijzonder krachtig: één basis-model in geheugen, per klant een eigen adapter ingeladen on-the-fly.

RLHF

RLHF wanneer nodig

Reinforcement learning from human feedback blijft relevant voor projecten waar continue feedback van eindgebruikers het modelgedrag moet sturen. We zetten dit selectief in — meestal pas in fase 3 van een traject, na SFT en DPO — omdat de kosten en complexiteit aanzienlijk zijn. Voor de meeste use cases is DPO een betere kosten-batenkeuze.

Dataset-preparatie: waar 80% van het werk zit

Een fine-tuned model is zo goed als zijn trainingsdata. Wij besteden in elk traject het grootste deel van de tijd aan het samenstellen, opschonen en valideren van de instructie-set. Een paar duizend zorgvuldig gecureerde voorbeelden leveren consequent beter resultaat dan tienduizenden ruwe records.

We werken met het concept van "golden samples": een kerncollectie van enkele honderden voorbeelden die exact het gewenste gedrag demonstreren. Daaromheen bouwen we synthetische uitbreidingen via paraphrasering, back-translation en model-assisted generation, met steekproefcontrole door domein-experts. Voor instruction-tuning gebruiken we Alpaca-, ShareGPT- of OpenAssistant-stijl JSONL-formaten, afhankelijk van de doelarchitectuur.

Catastrophic forgetting is een reëel risico: een model dat te eenzijdig wordt getuned, verliest algemene capaciteiten. We mitigeren dat door tijdens SFT een fractie generieke data (bijvoorbeeld 5-10% Tulu of FLAN-mix) mee te trainen, en door tussentijds te evalueren op een held-out general-purpose benchmark. Voor preference-data (DPO) gebruiken we paired samples waarbij menselijke annotatoren of een sterker referentiemodel kiezen tussen twee kandidaat-antwoorden.

Voor klanten met gevoelige data zetten we de volledige dataset-pipeline in een gecontroleerde omgeving — uw cloud, ons VPC, of on-premise. Geen data verlaat het afgesproken perimeter, geen training-runs op gedeelde infrastructuur. Dat is geen optionele feature, dat is een randvoorwaarde voor projecten in zorg, finance en overheid. Lees meer in AI voor banken en finance en AI in de zorgsector.

Onze fine-tuning workflow

Van dataset-assessment tot productie-deployment in vier fasen. Elke fase levert een toetsbaar tussenresultaat — geen black-box-traject van maanden.

Data-assessment en doelbepaling

We inventariseren uw data, bepalen of fine-tuning het juiste instrument is en stellen samen met u de evaluatie-criteria vast: pass@k, BLEU, ROUGE, taakspecifieke metrics, hallucinatie-rate.

Dataset-curatie

Golden samples opbouwen, instructie-formaat kiezen, synthetische uitbreiding via een sterker model, kwaliteitscontrole door domein-experts. Output: een train/validation/test-split die voldoet aan uw doelmetrics.

Training en evaluatie

Base-model selecteren, hyperparameters tunen, runs draaien (LoRA/QLoRA/full FT), tracking via MLflow of Weights & Biases. Iteratief evalueren op held-out set tot het model de doelmetrics haalt.

Deployment en monitoring

Model exporteren naar vLLM, TGI, llama.cpp GGUF of een managed endpoint (Inferentia, Replicate). Drift-monitoring, latency-tracking, A/B-evaluatie tegenover het oude model en een retrain-cadence.

Use cases die zich consistent terugverdienen

Niet elk AI-probleem hoort fine-tuned te worden, maar waar het past, levert het meetbaar voordeel op qua kosten, latency en kwaliteit. Een aantal terugkerende patronen.

Domein-specifieke generatie (juridisch, medisch, financieel)

Een advocatenkantoor dat memo's volgens een vaste structuur en met de juiste juridische terminologie wil opstellen, of een medisch team dat triage-samenvattingen genereert die voldoen aan een specifiek protocol. Een fine-tuned model van 7B-13B is hier doorgaans accurater én voorspelbaarder dan een generieke API, en — kritisch — kan on-premise draaien.

Tone-of-voice voor klantservice en publicaties

Een uitgever die kopij in een specifieke huisstijl genereert, of een klantenservice-team dat consequent volgens hun communicatie-handboek wil reageren. Stijloverdracht is een patroon dat fine-tuning permanent oplost; prompts blijven instabiel zodra de input verandert. Vaak gecombineerd met AI-klantenservice-automatisering.

Structured output en function-calling

Voor pipelines die JSON, XML of een eigen DSL moeten produceren — bijvoorbeeld bij document-extractie, ticket-routing of agent-tooling — geeft fine-tuning sterkere garanties dan schema-prompting. Een model dat 100k voorbeelden van uw schema heeft gezien, schendt het niet meer.

Cost reduction: kleiner finetuned model in plaats van GPT-4

Een veelgehoord scenario: een team draait een hoog-volume taak op GPT-4 of Claude en ziet de API-rekening exploderen. Een gerichte SFT op een Llama-3.1-8B of Mistral-7B haalt vaak 90-95% van de kwaliteit voor een fractie van de kosten en latency, gehost op vLLM in uw eigen VPC.

Nog niet zeker over een groot traject?

Test je idee eerst — werkend prototype in 1 dag

Met OneDayBuild maken we je idee in één dag tastbaar voor €950, zodat je weet of verdere ontwikkeling de investering waard is. Besluit je door te gaan met de volledige bouw? Dan verrekenen we de kosten volledig.

Bekijk OneDayBuild →

Onze trainings- en deployment-stack

We zijn doelbewust framework-agnostisch: de juiste tool hangt af van model-architectuur, dataset-grootte, beschikbare GPU's en deployment-eisen. Wat hieronder staat is wat we feitelijk gebruiken, niet wat trending is op X.

Voor training werken we afhankelijk van de situatie met de Hugging Face Trainer en TRL-library voor SFT en DPO, met Axolotl voor configureerbare YAML-driven runs op grotere modellen, en met Llama-Factory voor brede multi-architectuur ondersteuning. Voor extreem efficient tuning op consumer-GPU's gebruiken we Unsloth — een aantal optimalisaties die LoRA-runs op 7B-modellen tot 2x sneller maken. Tracking en experiment-management gaat via MLflow of Weights & Biases, afhankelijk van uw bestaande MLOps-stack.

Voor compute werken we waar mogelijk in uw eigen cloud (AWS, Azure, GCP). Wanneer u geen GPU-quota wilt opbouwen, zetten we Modal, Replicate of RunPod in voor incidentele training-runs. Voor productie-inference draaien we vLLM of Hugging Face Text Generation Inference (TGI) op uw eigen infrastructuur, of we converteren naar GGUF voor llama.cpp wanneer CPU- of edge-deployment passend is. AWS Inferentia en Trainium komen in beeld bij hoge volumes waar de unit economics anders niet kloppen.

PyTorch Hugging Face Transformers TRL PEFT Axolotl Llama-Factory Unsloth DeepSpeed vLLM TGI llama.cpp / GGUF MLflow Weights & Biases Modal RunPod AWS Inferentia Llama 3.1 / Mistral / Qwen / Gemma

Evaluatie, eval-frameworks en guardrails

Een fine-tuned model dat goed scoort op uw eval-set is een product. Een fine-tuned model zonder eval-set is een gok. Wij investeren bewust in evaluatie-infrastructuur voordat we serieus gaan trainen.

Taakspecifieke metrics

Naast generieke perplexity gebruiken we metrics die bij uw taak horen: BLEU en ROUGE voor samenvatten, pass@k voor code, exact-match en F1 voor extractie, en LLM-as-judge voor open-ended generatie. We bouwen elke eval-suite reproduceerbaar — dezelfde test-set, dezelfde prompts, dezelfde decoding-parameters — zodat verbetering tussen runs aantoonbaar is.

Hallucinatie- en safety-evaluatie

Voor productie-modellen meten we hallucinatie-rate via een gecureerde set met bekende correcte antwoorden, en doen we een safety-eval (jailbreak-resistance, refusal-gedrag, toxiciteit). Resultaten worden vastgelegd per model-versie, zodat regressies meteen zichtbaar zijn.

A/B-evaluatie tegen baseline

Elke fine-tuned versie wordt vergeleken met een duidelijke baseline: het base-model met few-shot prompts, of het oude productie-model. Zonder die vergelijking weet u niet of de fine-tuning rendement opleverde of dat een betere prompt hetzelfde had bereikt.

Productie-monitoring en drift-detectie

Na deployment loggen we input-output-paren (geanonimiseerd), monitoren latency-percentielen, en draaien periodieke regressie-evals tegen onze gefixte testset. Modellen worden herhetraind wanneer de output-distributie verschuift of wanneer een nieuwer base-model significant beter scoort.

Waarom Appfront voor fine-tuning

Eerlijke beslisboom voor we beginnen

We zeggen "geen fine-tuning" wanneer een betere prompt of een RAG-pipeline het probleem oplost. Dat scheelt u maanden werk en aanzienlijke compute-kosten. Een traject dat niet had gehoeven, willen we niet aan u verkopen.

Volledige pipeline-verantwoordelijkheid

Van dataset-curatie via training en evaluatie tot productie-deployment en doorlopend onderhoud. Geen overdracht aan een MLOps-team dat u nog moet zoeken; één team dat het model van conceptie tot pensioen begeleidt.

Privacy en hosting in uw perimeter

Trainen in uw cloud of VPC, deployment op uw infrastructuur, geen data via US-API's tenzij u daar bewust voor kiest. Voor zorg, finance en overheid is dat geen luxe maar een AVG- en sectorvereiste.

Veelgestelde vragen over AI-fine-tuning

Wanneer is fine-tuning beter dan RAG?
Wanneer u patronen wilt overdragen — schrijfstijl, output-structuur, redeneerketens of vakjargon — die niet stabiel in een prompt passen. RAG is beter wanneer u feiten of frequent wisselende content wilt toevoegen. In de praktijk combineren we beide: fine-tuning voor het hoe, RAG voor het wat.
Hoeveel data heb ik nodig voor een fine-tuning-traject?
Voor SFT op een open-source model zien we doorgaans bruikbare resultaten vanaf 500-1000 zorgvuldig gecureerde instructie-paren. Voor LoRA op specifieke stijl-overdracht volstaat soms 200-500. Voor continued pretraining of grootschalige domain-adaptatie praat u over miljoenen tokens aan ongelabelde corpus.
Wat is het verschil tussen LoRA en QLoRA?
LoRA traint kleine adapter-matrices in plaats van het volledige model en bespaart daarmee veel geheugen en rekentijd. QLoRA combineert dat met 4-bit quantisatie van het base-model, waardoor u zelfs een 70B-parametermodel op een enkele H100 of een 24GB-consumer-GPU kunt fine-tunen. QLoRA is het standaard-startpunt geworden voor de meeste moderne projecten.
Wanneer kies ik DPO boven RLHF?
In bijna alle gevallen. DPO is goedkoper, stabieler en vereist geen apart reward-model of PPO-loop. RLHF blijft relevant voor projecten waar continue feedback van eindgebruikers het modelgedrag moet sturen, maar voor de meeste bedrijfsmatige fine-tuning levert DPO een betere kosten-batenverhouding op.
Welk base-model raden jullie aan?
Dat hangt af van licentie-eisen, taal en deployment-context. Voor Engels en Nederlands werken Llama 3.1 (8B/70B), Mistral, Qwen 2.5 en Gemma goed. Voor strikt commerciële licenties zonder restricties kijken we naar de Apache-2.0-modellen in die families. Voor extreem klein en CPU-deployable zit Phi-3 of Gemma-2 vaak in de mix.
Verliest een fine-tuned model algemene kennis (catastrophic forgetting)?
Het kán, vooral bij eenzijdige datasets en te hoge learning rates. We mitigeren door een fractie generieke instructie-data mee te trainen, learning rates conservatief in te stellen en periodiek te evalueren op een algemeen benchmark. Voor strikte domain-only modellen is enige verlies acceptabel — voor algemene assistenten niet.
Kunnen we het fine-tuned model on-premise hosten?
Ja. We deployen op vLLM of TGI in uw eigen Kubernetes-cluster, op AWS Inferentia/Trainium voor unit-cost-optimalisatie, of we converteren naar GGUF voor llama.cpp op CPU- of edge-hardware. Geen verplicht gebruik van externe API's, geen data die uw perimeter verlaat.
Hoe meten we of de fine-tuning gewerkt heeft?
Voor we beginnen leggen we vast welke metrics succes definiëren — pass@k, BLEU/ROUGE, taakspecifieke F1, hallucinatie-rate, latency, kosten per 1000 tokens. We meten elke run reproduceerbaar tegen dezelfde held-out set en vergelijken expliciet met de baseline (base-model met few-shot prompts of het bestaande productie-model).
Wat gebeurt er als er een nieuwer base-model uitkomt?
Dat is een terugkerend ritme. We onderhouden uw eval-set en draaien een baseline-run op het nieuwe base-model. Als de winst significant is, herhaal we de fine-tuning op de nieuwe basis. Omdat dataset-curatie het zwaarste werk is en die hergebruikt kan worden, is een base-model-update doorgaans een kwestie van weken, niet maanden.

Een fine-tuned model voor uw domein?

Bespreek uw use case, dataset en doelmetrics met ons. We geven een eerlijk antwoord op de vraag of fine-tuning het juiste instrument is — en zo ja, hoe we tot een productiemodel komen.

Plan een gesprek

Edit Content