Een LLM fine-tunen [en wanneer je beter RAG of prompting kunt gebruiken]

Bij het fine-tunen van een groot taalmodel (LLM) verfijn je een vooraf getraind LLM op een kleine, taakspecifieke dataset, zodat het output levert die je met alleen prompting niet krijgt.

Fine-tuning houdt in dat je voorbeeldparen van input en output verzamelt die het gewenste gedrag laten zien, trainingsrondes uitvoert die de gewichten van het model daarnaartoe verschuiven, en het resultaat vergelijkt met de output van het oorspronkelijke model. Parameter-efficiënte methoden zoals LoRA maken dit zo goedkoop dat het op één GPU kan draaien.

Ben je niet tevreden over de output van het LLM, verfijn dan eerst je prompts en retrieval-augmented generation (RAG). Fine-tuning verandert hoe het LLM zich gedraagt. Als het actuele of bedrijfseigen informatie moet gebruiken, zijn prompting en RAG meestal een betere keuze.

Hier lees je stap voor stap hoe je een LLM fine-tunet, wat de belangrijkste fine-tuningmethoden zijn (LoRA en QLoRA) en welke uitdagingen en fouten het proces kunnen verstoren.

Wat LLM-fine-tuning is en hoe het verschilt van LLM-pre-training

LLM-pre-training bouwt de algemene taalvaardigheid van een model vanaf nul op met een enorm corpus, terwijl LLM-fine-tuning een vooraf getraind model met een kleine dataset bijstelt voor één specifieke taak.

LLM-pre-training is de resource-intensieve fase die een basismodel oplevert. Het model leert van een breed tekstcorpus en verwerft zo algemene kennis van grammatica, feiten en redeneren, maar geen specialisatie voor jouw taak.

LLM-fine-tuning zet de training van het basismodel voort op een kleine, zorgvuldig samengestelde dataset, zodat het de gewenste output levert voor een specifieke taak of use case. Denk aan een consistent formaat, een merkstem of toon, domeinspecifieke patronen of betrouwbare tool- en functieaanroepen.

Wanneer je LLM's fine-tunet en wanneer je beter kunt prompten of RAG kunt gebruiken

Wil je de prestaties van een LLM verbeteren, werk dan stap voor stap omhoog: prompting -> RAG -> fine-tuning.

Verfijn je prompts met gedetailleerdere instructies en gebruik RAG om het model actuele informatie te geven. Gebruik fine-tuning pas als verbeteringen aan prompts en retrieval niet het gewenste resultaat opleveren.

Wanneer betere prompts beter werken dan fine-tuning en wanneer ze niet volstaan

Prompting is de snelste en goedkoopste hefboom. In veel gevallen bereik je met nauwkeurigere en gedetailleerdere prompts de gewenste gedragsveranderingen.

Maar langere prompts vertragen het werk, maken het duurder en kunnen bestaande beperkingen van het model niet overwinnen.

Tekenen dat prompting misschien zijn grenzen heeft bereikt:

• Nieuwe randgevallen blijven de output verstoren: Het model geeft bijvoorbeeld lopende tekst terug terwijl je JSON nodig hebt, of slaat de verkeerde toon aan, en je past de prompt voor elk nieuw geval aan.
• De systeemprompt blijft groeien: De prompt beslaat honderden of duizenden regels en is lastig te beheren.
• Je betaalt er bij elke aanroep voor: De prompt wordt bij elk verzoek opnieuw verzonden en verwerkt, waardoor tokenkosten en latentie toenemen.
• Wijzigingen maken geen verschil meer: Nieuwe instructies verbeteren de output niet.

Probeer zelfs dan eerst de goedkopere oplossingen op promptniveau. Gebruik few-shot-voorbeelden om het model het patroon te laten zien (input/output-paren), prompt chaining om lastige taken op te splitsen in kleinere stappen, of hooks voor functieaanroepen om exacte opzoekacties of berekeningen uit te besteden.

Wanneer RAG zinvoller is dan het model fine-tunen

RAG verandert wat het LLM weet, terwijl LLM-fine-tuning verandert hoe het zich gedraagt. Zit het gat in kennis, vooral kennis die vaak verandert of in je eigen documenten staat, dan is RAG het antwoord. Zit het gat in gedrag, kies dan voor fine-tuning.

Fine-tuning verandert ook wat een model weet, maar alle feiten die het opneemt, liggen vast op het moment van training en raken in snel veranderende vakgebieden snel verouderd. Bovendien wordt de informatie in de gewichten van het model ingebakken, zodat er geen spoor van de bron overblijft.

De brondocumenten bijwerken die een retrievallaag gebruikt, is sneller en goedkoper, en die laag kan precies de bronnen citeren die ze heeft gebruikt. Daardoor is het een betere keuze als je verantwoordbare, actuele informatie nodig hebt.

Het nadeel van RAG? Het is een extra laag die je moet bouwen en onderhouden, en het verhoogt de latentie.

In de praktijk heb je vaak allebei nodig. Productiesystemen combineren gefinetunede modellen met RAG: het ene voor consistent gedrag, het andere voor actuele feiten.

Veelvoorkomende valkuilen, risico's en uitdagingen bij fine-tuning

Zelfs als fine-tuning het juiste instrument is, brengt het kosten en risico's met zich mee:

• Kosten en tijd: Het verzamelen van schone, representatieve trainingsdata en de rekenkracht voor de training zijn duur.
• Catastrofaal vergeten: Een model dat op een smalle dataset is getraind, kan algemene vaardigheden verliezen en nieuwe faalpatronen ontwikkelen, met fouten die het basismodel niet maakte.
• Overfitting: Met te weinig of te repetitieve data onthoudt het model je trainingsvoorbeelden in plaats van patronen te leren, waardoor het goed presteert op de trainingsvoorbeelden, maar slecht op echte input.
• Verouderde kennis: Kennis die in de gewichten is ingebakken, raakt snel verouderd, dus je moet opnieuw trainen op nieuwe data.
• Veroudering van het model: Wanneer er een sterker model uitkomt, presteert dat vaak direct al beter dan je fine-tune en moet je het werk opnieuw doen.
• Uitdagingen bij evaluatie en reproductie: Aantonen dat het gefinetunede model beter presteert dan het basismodel is lastig. Twee GPU-trainingsruns met dezelfde instellingen kunnen bovendien licht verschillende modellen opleveren.
• Datagovernance: Trainen op bedrijfseigen of gevoelige data roept vragen op over privacy en licenties; een model kan later fragmenten prijsgeven van de data waarop het is getraind.

De belangrijkste fine-tuningmethoden

De belangrijkste soorten LLM-fine-tuning verschillen in hoeveel van het model ze aanpassen: volledige fine-tuning traint het hele model opnieuw, terwijl methoden voor parameter-efficiënte fine-tuning (PEFT), zoals LoRA en QLoRA, slechts een deel van de gewichten bijwerken. PEFT-methoden kosten maar een fractie van het geheugen van volledige fine-tuning en kunnen met de juiste instellingen dezelfde resultaten halen.

Volledige fine-tuning werkt elk gewicht van het model bij. Het is de duurste methode en brengt het grootste risico op catastrofaal vergeten met zich mee. Gebruik het alleen voor ingrijpende gedragsveranderingen en als je over de data en rekenkracht beschikt om dat te ondersteunen.

Het alternatief is parameter-efficiënte fine-tuning, of PEFT. Dat is een overkoepelende term voor methoden die het grootste deel van het model bevriezen en slechts een kleine set parameters trainen. Het gebruikt veel minder geheugen en is minder vatbaar voor vergeten, omdat het basismodel intact blijft.

Bij lage ranks leert PEFT minder dan een volledige fine-tune, maar door de rank te verhogen en de leersnelheid af te stemmen, dicht je bij instruction-tuningtaken het grootste deel van het verschil.

Tot de PEFT-methoden behoren:

• LoRA (Low-Rank Adaptation): Het gebruikelijke startpunt. LoRA bevriest de oorspronkelijke gewichten en traint een kleine set toegevoegde adapterparameters, vaak minder dan 1% van het totaal, zodat het op één consumenten-GPU draait.
• QLoRA (Quantized Low-Rank Adaptation): Comprimeert het basismodel naar 4-bits precisie voordat LoRA wordt toegepast, zodat je een groot model op één GPU kunt fine-tunen.

Daarnaast gebruiken we methoden voor instruction-tuning en preference-tuning, van RLHF (Reinforcement Learning from Human Feedback) tot lichtere alternatieven zoals Direct Preference Optimization (DPO) en Odds Ratio Preference Optimization (ORPO), om te bepalen hoe een model instructies opvolgt en aansluit bij menselijke voorkeuren.

Zo fine-tune je een LLM, stap voor stap

Heb je besloten dat fine-tuning van een LLM de juiste keuze is? Dan ziet de workflow er zo uit.

Vergroten

Stap 1: Definieer de taak en hoe je succes meet

Bepaal welk gedrag je van het LLM wilt en hoe je weet dat je dat hebt bereikt.

Benoem de specifieke taak die het gefinetunede model moet uitvoeren, bijvoorbeeld supporttickets classificeren, contracten samenvatten in een vast formaat of code genereren in je eigen huisstijl.

Definieer vervolgens wat succes is. Veelgebruikte opties zijn:

• Geldigheid van de output: Wordt het resultaat bijvoorbeeld correct geparsed als geldige JSON, of komt het overeen met de Markdown-structuur die je nodig hebt?
• Geautomatiseerde scores: Gebruik metrics zoals BLEU of ROUGE die gegenereerde tekst vergelijken met referentieantwoorden, of de taaknauwkeurigheid op een gelabelde set.
• Menselijke beoordelingen: Een beoordelingsschema met scores of geslaagd/niet geslaagd voor kwaliteiten die een script slecht kan beoordelen, zoals toon of behulpzaamheid.
• Betrouwbaarheid bij lastige input: Kan het model overweg met de ongebruikelijke input waarop het basismodel struikelde?

Stap 2: Bereid je dataset voor

De kwaliteit van de data bepaalt het succes van de fine-tune, dus steek moeite in het verzamelen van de juiste dataset voor fine-tuning.

Formatteer je data als instructie/respons-paren in JSONL, waarbij elke regel de input (plus eventuele context) bevat en de exacte output die je terug wilt krijgen.

Bekijk bijvoorbeeld openbare datasets zoals de algemene instructiedataset Alpaca-cleaned of Dolly van Databricks, of de taakspecifieke dataset banking77, die meer dan 13.000 echte supportvragen bevat, verdeeld over 77 gelabelde intenties.

Voor een gerichte taak kunnen een paar honderd tot een paar duizend schone, gevarieerde voorbeelden het gedrag al veranderen. Voorwaarde is wel dat de voorbeelden echte productie-input weerspiegelen, inclusief de randgevallen, en consistent zijn geformatteerd.

Nog geen input/output-paren? Stel de set samen uit data die je al hebt, zoals supporttickets met de beste antwoorden erop, of documenten met hun samenvattingen.

Heb je alleen de output, gebruik dan een sterker model om bij elke output een plausibele input te genereren, of schrijf zelf een kleine startset en breid die uit met een groter “leraar”-model, en bewaar daarna de beste paren.

Splits de data tot slot op in trainings-, validatie- en testsets, zodat je kunt meten op voorbeelden die het model nog niet heeft gezien.

Stap 3: Kies een basismodel en methode

Begin met een klein opensourcemodel van 3 tot 7 miljard parameters en een methode voor parameter-efficiënte fine-tuning zoals LoRA of QLoRA.

Open modelfamilies zoals Llama, Mistral en Qwen bieden een sterke basis die je zelf kunt hosten, en de PEFT-methoden houden de hardwaredrempel laag: QLoRA kwantiseert het basismodel naar 4-bit, zodat je voor het fine-tunen van een 7B-model maar een consumentenkaart van 16-24 GB nodig hebt. Volledige fine-tuning van hetzelfde model vergt vele malen zoveel geheugen.

Stap 4: Stel je trainingshyperparameters in

Dit zijn de belangrijkste parameters voor LLM-fine-tuning, met voorgestelde beginwaarden:

• Leersnelheid bepaalt hoe groot elke update van de gewichten is. Een studie uit 2024 van Biderman et al. wees uit dat de beste leersnelheden voor LoRA ongeveer tien keer hoger lagen dan die voor volledige fine-tuning, doorgaans 5e-5 tot 5e-4 tegenover 1e-5 tot 5e-5. De studie raadt aan waarden van 1e-5 tot 5e-4 te testen en de hoogste waarde te gebruiken waarmee de training stabiel verloopt.
• Batchgrootte is het aantal voorbeelden waarvan het model leert vóór elke gewichtsupdate. Gebruik op één GPU een kleine batch per apparaat van 1 tot 8 en gradiëntaccumulatie om een effectieve batch van ongeveer 16 tot 64 te bereiken.
• Aantal epochs is hoe vaak het model de volledige dataset ziet. Als je het model traint voor specifieke taken, is 1 tot 3 een goede vuistregel, maar LoRA-runs hebben er vaak meer nodig.
• LoRA-rang (r) bepaalt de capaciteit van de adapter, oftewel hoeveel die kan leren. Begin met 8 tot 32 bij eenvoudigere taken en verhoog de rang bij moeilijkere taken: in de eerder aangehaalde LoRA-studie van Biderman et al. was bij instruction-tuning van een 7B-model op code rang 256 nodig om volledige fine-tuning te evenaren, terwijl rang 64 bij wiskunde in de buurt kwam.
• Maximale sequentielengte is de langste invoer die de run verwerkt. Stel deze zo in dat je langste voorbeelden erin passen, tot aan het contextvenster van het model, want alles wat langer is, wordt afgekapt.
• Warm-up en schema bepalen hoe de leersnelheid tijdens de run oploopt en verandert. Een korte warm-up en een cosine decay zijn de gebruikelijke standaardinstellingen. De studie van Pareja et al. naar kleine modellen wees echter uit dat het weglaten van de warm-up de eindscores niet verslechterde.

Beschouw deze waarden als uitgangspunt voor een sweep, niet als vaste instellingen.

Stap 5: trainen en de loss monitoren

Houd tijdens de training de loss-curves voor training en validatie in de gaten om te zien of het werkt.

Loss meet hoe ver de uitvoer van het model afwijkt van je voorbeelden en hoort gelijkmatig te dalen naarmate de run vordert. De trainingsloss heeft betrekking op de data waarvan het model leert. De validatieloss wordt gemeten op de achtergehouden voorbeelden.

Als de trainingsloss en de validatieloss samen dalen, leert het model te generaliseren. Als de trainingsloss blijft dalen, maar de validatieloss afvlakt of stijgt, leert het model de trainingsset uit het hoofd in plaats van het patroon te leren (overfitting).

Vergroten

Stap 6: evalueren en daarna implementeren

Een lage trainingsloss garandeert geen correcte uitvoer, dus beoordeel het gefinetunede model op de criteria die je in stap 1 hebt vastgesteld.

Als het model slaagt, heb je twee manieren om het te implementeren:

• Draai de adapter bovenop het basismodel en laad beide tijdens runtime; zo blijft de adapter uitwisselbaar.
• Voeg de adapter samen met de basisgewichten tot één zelfstandig model dat eenvoudiger te hosten is.

Gebruik Perplexity om je LLM toegang te geven tot actuele informatie

Fine-tuning is de juiste keuze als je het gedrag van een model wilt afstemmen op je behoeften.

Als je model actuele informatie nodig heeft, vooral informatie die snel verandert, heb je RAG of een betrouwbare zoektool van derden nodig.

Een eigen retrievalstack werkt het best voor bedrijfseigen datasets, zoals je interne wiki, klantenservicegeschiedenis, contracten of productdocumentatie.

Als de kennis die je wilt gebruiken openbaar is, hoef je geen eigen retrievallaag te bouwen. Perplexity is een antwoordmachine die antwoorden geeft met inline, klikbare bronvermeldingen uit een live webindex. De Agent API levert die op het web gebaseerde antwoorden met bronvermeldingen in één aanroep, zodat je app actuele bronnen kan gebruiken.

Veelgestelde vragen over het fine-tunen van LLM's

Kun je een LLM gratis fine-tunen?

Ja, je kunt een klein open LLM gratis fine-tunen. De gratis versie van Google Colab biedt bijvoorbeeld genoeg GPU-capaciteit om QLoRA uit te voeren op een model van 3B tot 8B, wat ruim voldoende is voor een gerichte taak. Je gaat pas betalen als je meer geheugen, langere runs of een groter basismodel nodig hebt dan de gratis versie aankan.

Heb je een eigen GPU nodig, of kun je in de cloud fine-tunen?

Je hoeft geen eigen GPU te hebben om LLM's te fine-tunen. Beheerde diensten en GPU-cloudproviders verhuren de hardware per uur, dus met één gehuurde GPU kun je een QLoRA-run op een klein model uitvoeren. Een GPU kopen loont alleen als je vaak fine-tunet of al je data op je eigen machines moet houden.

Hoe lang duurt het fine-tunen van LLM's?

Bij een klein LLM kan een run binnen enkele minuten tot een paar uur klaar zijn, afhankelijk van de omvang van de dataset en de hardware. Oumi heeft bijvoorbeeld een model van 0,8B in iets meer dan een uur volledig gefinetuned op zijn gehoste platform.

Grotere modellen of tienduizenden voorbeelden rekken dat op tot een dag of langer: de LoRA-runs van Emburse op een 7B-model duurden 8 uur voor 5.000 voorbeelden en ongeveer 30 uur voor 50.000 voorbeelden op één GPU van 40 GB.

Kun je een gefinetuned model blijven bijwerken als je data verandert?

Je kunt opnieuw fine-tunen op nieuwe data, maar elke ronde kost rekenkracht en brengt het risico op catastrofaal vergeten (catastrophic forgetting) met zich mee. Voor kennis die vaak verandert, is RAG meestal de betere oplossing, omdat je dan de brondocumenten bijwerkt in plaats van opnieuw te trainen.