I årevis var finjustering den AI-kapacitet, som lå lige uden for rækkevidde for de fleste teams. Man havde brug for GPU-klynger, ML-ingeniører og flere ugers arbejde. For applikationsteams kunne økonomien sjældent retfærdiggøre det.
I 2026, modsat tidligere, er det ikke længere tilfældet. LoRA, QLoRA og administrerede finjusteringstjenester har gjort teknikken håndterbar for ethvert team med rimelige tekniske kompetencer. Du kan køre en reel LoRA-finjustering på en enkelt GPU til forbrugere. Du kan gøre det via en hostet tjeneste for under €100 i beregningsomkostninger. Du kan have en produktionsklar, finjusteret model efter to ugers fokuseret arbejde.
Det ændrer regnestykket. Tilfælde, hvor finjustering ikke gav mening i 2024 (for dyrt, for komplekst), gør det ofte i 2026. Og nogle af de tilfælde, hvor teams automatisk vælger RAG, burde i stedet bruge finjustering.
Denne artikel gennemgår, hvornår finjustering slår andre tilgange, den praktiske arbejdsgang for et lille team og de mønstre, der adskiller finjusteringer, som kommer i produktion, fra dem, der skuffer.
Hvornår finjustering vinder
Vi berørte det kort i den forrige artikel; her får du den længere forklaring.
1. Ensartet format og struktur
Hvis du konsekvent har brug for output i et meget bestemt format, slår finjustering prompting.
Eksempel: Hvert output skal bestå af præcis 5 punkter, som alle begynder med et verbum og har en bestemt tone. Med prompting kan du nå 95% af vejen. Med finjustering når du 99%+.
Finjusteringen lærer strukturen som standard; modellen »gør det bare«, uden at du skal angive den på ny i hver prompt.
2. Ensartet stil og tone
Virksomheder med stærke retningslinjer for tone oplever ofte, at prompting alene fører til afvigelser. Over tusindvis af interaktioner begynder tonen at skride.
Finjustering på 1000+ eksempler på »sådan lyder vi« giver en model, der internaliserer tonen. Den er ensartet, fordi den er en del af modellen og ikke blot en promptinstruktion, som modellen skal huske.
3. Specialiseret domæne eller DSL
Hvis dit domæne har usædvanlig terminologi, et brugerdefineret DSL eller særlige mønstre, som basismodellen ikke kender godt:
Eksempel: En virksomhed har sit eget interne forespørgselssprog til data. Basismodellen har aldrig set det. Prompting med eksempler hjælper, men er ikke nok — modellen bliver ved med at lave syntaksfejl.
Finjustering på 5,000 eksempler med korrekt kode i DSL’et giver en model, der skriver sproget flydende. Modellen »kender« DSL’et på samme måde, som den kender Python.
4. Mindre model, sammenlignelig kvalitet
En finjusteret 8B-model kan undertiden matche en generisk 70B-model på en bestemt opgave. Fordelene er:
- Billigere inferens (10-50x).
- Hurtigere inferens (3-10x).
- Kan hostes selv på beskeden hardware.
- Mere forudsigelig adfærd på den afgrænsede opgave.
Hvis du har store mængder afgrænsede arbejdsbelastninger, kan det spare betydelige beløb.
5. Adfærdsmæssig sikkerhed
Det er ofte mere robust at finjustere modellen til konsekvent at afvise bestemte ting eller tilføje specifikke sikkerhedsforanstaltninger end at bruge promptbaserede værn.
Eksempel: En kundevendt AI må aldrig oplyse priser (fordi priserne ændrer sig løbende). Prompting hjælper, men kan omgås; finjustering gør afvisningen robust.
6. Few-shot-mønstre i stor skala
Hvis du bruger 10-shot-eksempler i hver prompt, og eksemplerne optager en betydelig del af tokenbudgettet, er finjustering mere effektiv. »Eksemplerne« er indbygget i modellen, og prompten er kort.
Det er især relevant i brugsscenarier med høj volumen, hvor antallet af prompttokens løber op.
Hvornår finjustering taber
Lige så vigtigt: Hvornår du ikke bør finjustere.
1. Viden, der ændrer sig
Finjusterede modeller er øjebliksbilleder. Ny information kræver ny træning. For dynamisk viden (aktuelle begivenheder, kontospecifikke data, de seneste politikker) løser RAG opgaven; det gør finjustering ikke.
Hvis dit »jeg har brug for finjustering« betyder »modellen skal kende vores produkt«, er konklusionen forkert. RAG er det rigtige værktøj.
2. Du har ikke data nok
Effektiv finjustering kræver en betydelig mængde træningsdata. Minimum afhænger af opgaven:
- LoRA til en afgrænset opgave: 500-1000 eksempler.
- LoRA til moderat kompleksitet: 1000-5000.
- Mere generel adfærd: 5000+.
Med færre end 500 eksempler kan du som regel ikke finjustere meningsfuldt. Few-shot-prompting eller RAG virker ofte bedre.
3. Basismodellen forbedres hurtigere, end du kan følge med
Frontier-modeller udvikler sig hurtigt. En finjustering fra sidste år bliver ofte overgået af en aktuel frontier-model uden finjusteringen. Det er en løbende opgave i sig selv at vedligeholde finjusteringer i forhold til en baseline, der flytter sig.
Hvis du ikke har en klar vedligeholdelsesplan, bliver finjustering til teknisk gæld.
4. Du har ikke gjort arbejdet med prompting og RAG
Et overraskende almindeligt mønster er, at teams springer direkte til finjustering uden for alvor at have prøvet prompting eller RAG. Finjusteringen kommer i drift, og kvaliteten er udmærket, men en uges iteration på prompts ville have givet det samme resultat til 1% af prisen.
Prøv først prompting og RAG seriøst, inden du finjusterer.
5. Du har ingen evalueringer
Finjustering uden evalueringer er hasardspil. Du kan ikke se, om finjusteringen hjalp, skadede eller slet ikke ændrede noget. Mange »vellykkede« finjusteringer er placebo-gevinster eller ligefrem regressioner.
Byg evalueringerne først. Finjuster derefter.
Landskabet for finjustering i 2026
Et hurtigt overblik over mulighederne:
Hostede tjenester
Den letteste vej var tidligere at uploade data til en proprietær leverandør og få et finjusteret endpoint retur. Den mulighed indsnævres hurtigt (status bekræftet 2026-07-07):
- OpenAI afvikler gradvist finjustering. Platformen er lukket for nye brugere; eksisterende kunder kan fortsat køre træningsjobs i en begrænset periode, og allerede finjusterede modeller fortsætter, indtil deres basismodeller udfases. Forstærkningsbaseret finjustering på aktuelle modeller kræver invitation. Planlæg ikke nye produkter omkring den.
- Anthropic. Ingen selvbetjent finjustering; historisk har der været en snæver, partnerstyret adgang (Claude 3 Haiku via AWS Bedrock) til udvalgte enterprise-tilfælde. Betragt den som utilgængelig, medmindre din cloud-repræsentant siger andet.
- Google Vertex AI-tuning. Tilbyder fortsat tuning til Gemini-familien.
- Together AI, Fireworks. Finjusterer open-weight-modeller på deres infrastruktur — i stigende grad den praktiske hostede vej.
Retningen er tydelig: Finjustering af proprietære modeller trækker sig sammen, mens finjustering af open-weight-modeller er den varige investering. Derfor bruger eksemplet nedenfor open-weight-vejen.
Omkostninger: typisk €10-200 for en moderat finjustering (5K-50K eksempler) plus et tillæg pr. inferens i forhold til basismodellen.
Hvornår du bør vælge det: for de fleste teams. Bekvemmeligheden opvejer den (beskedne) merpris.
Selvhostet finjustering
Du leverer GPU’erne, koden og infrastrukturen.
- Open source-modeller: Llama 4, Qwen 3, Mistral, DeepSeek, Phi, Gemma. De er alle udgivet med licenser, der er tilstrækkeligt lempelige til finjustering.
- Værktøjer: Hugging Face TRL, Axolotl, Unsloth, LLaMA-Factory. De er alle modne.
- Beregning: Kan udføres på en enkelt H100 for modeller af moderat størrelse. Eller lejes hos RunPod, Lambda, Vast.ai eller Modal for $1-3/hour.
Omkostninger: €50-500 i beregningskraft for en typisk LoRA-finjustering. Dertil kommer jeres arbejdstid.
Hvornår du bør vælge det: når du har brug for fuld kontrol (bestemte modeller, brugerdefineret databehandling, lokal installation), eller når du laver mange finjusteringer (prisen pr. finjustering hos hostede tjenester løber op).
Letvægtsmuligheder
Til meget små finjusteringer:
- Unsloth på en GPU til forbrugere. Finjuster små modeller (7B) på en RTX 4090 i løbet af en eftermiddag.
- MLX på Apple Silicon. Finjuster små modeller på en Mac Studio.
- LoRA i Google Colab. Gratis eller Colab Pro for €10-50/month.
De fungerer til eksperimenter, små modeller og proof-of-concept-finjusteringer.
Den praktiske arbejdsgang
For et team, der bygger en finjustering til produktion, ser arbejdsgangen sådan ud:
Trin 1: Bekræft behovet (1-2 dage)
Inden dataarbejdet begynder, skal du bekræfte følgende:
- Har I prøvet stærk prompting i en uge eller mere?
- Har I prøvet RAG, hvis opgaven involverer viden?
- Har I evalueringer, som viser, at den nuværende tilgang ikke er tilstrækkelig?
- Kan I formulere præcist, hvad finjusteringen skal gøre bedre?
Hvis du ikke kan svare ja til dem alle, skal du ikke finjustere endnu.
Trin 2: Byg evalueringer (1 uge)
Uden evalueringer er finjustering hasardspil.
- Konstruér et evalueringssæt (100-500 eksempler), der dækker den ønskede adfærd.
- Definér målepunkter: Hvordan ser succes ud? Overholdelse af format, overensstemmelse med tone, nøjagtighed osv.
- Baseline: Kør evalueringen på basismodellen. Registrér den aktuelle score.
Du får brug for dette for at afgøre, om finjusteringen hjalp.
Trin 3: Dataklargøring (1-3 uger)
Det meste af arbejdet ligger her. Træningsdataenes kvalitet bestemmer finjusteringens kvalitet.
Kilder:
- Eksisterende output af høj kvalitet fra jeres team.
- Kuraterede, tidligere kundeinteraktioner.
- Genererede eksempler (brug en stærk model + omhyggelig prompting).
- Kundespecifikke data (hvor det er passende; respekter tilladelser og PII).
Format:
Et typisk format til finjustering af chat:
{
"messages": [
{"role": "system", "content": "..."},
{"role": "user", "content": "..."},
{"role": "assistant", "content": "..."}
]
}
Ét eksempel pr. linje i JSONL.
Mængde:
- LoRA til en afgrænset opgave: 500-2000 eksempler.
- LoRA til en moderat opgave: 2000-10000.
- Generel adfærd: 10000+.
Mere er som regel bedre indtil et vist punkt. Efter ~50K eksempler aftager udbyttet.
Kvalitet > kvantitet.
500 ensartede eksempler af høj kvalitet slår 5000 middelmådige. Det er bedre at bruge mere tid på at kuratere færre eksempler end at hælde en masse middelmådige eksempler i datasættet.
Variation.
Datasættet skal spænde over hele spektret af input, du vil møde. Træner du kun på lette tilfælde, fejler modellen på de svære. Træner du kun på særtilfælde, overkorrigerer du.
Data om sikkerhed og afvisning.
Medtag eksempler på passende afvisninger. Ellers bliver finjusterede modeller ofte mere føjelige (de vil gøre hvad som helst) — en regression i sikkerheden.
Opdeling i træning og evaluering.
Hold 5-10% tilbage til evaluering. Træn aldrig på disse data; brug dem kun til at måle kvaliteten.
Trin 4: Kør træningen (1 dag til 1 uge)
For hostede tjenester:
# OpenAI example. First upload the files; the API expects file IDs,
# not local paths, for training_file / validation_file.
train = client.files.create(file=open("training.jsonl", "rb"), purpose="fine-tune")
val = client.files.create(file=open("validation.jsonl", "rb"), purpose="fine-tune")
client.fine_tuning.jobs.create(
training_file=train.id,
validation_file=val.id,
model="gpt-4o-mini",
hyperparameters={
"n_epochs": 3,
"batch_size": 8,
"learning_rate_multiplier": 1.0,
},
)
Vent på, at træningen bliver færdig. Det tager fra timer til dage afhængigt af datasættets størrelse og tjenestens belastning.
For selvhostet træning (med Axolotl):
base_model: Qwen/Qwen3-8B
load_in_4bit: true
adapter: lora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_modules:
- q_proj
- v_proj
- k_proj
- o_proj
datasets:
- path: ./data/train.jsonl
type: chat_template
num_epochs: 3
micro_batch_size: 2
gradient_accumulation_steps: 4
learning_rate: 0.0002
warmup_steps: 100
output_dir: ./output
Kør: accelerate launch -m axolotl.cli.train config.yaml
Træningen tager nogle timer på en enkelt GPU.
Hyperparametre, der betyder noget:
- Epoker: 1-5 typisk. Flere kan føre til overtilpasning. Hold øje med valideringstabet.
- Læringsrate: 1e-5 til 5e-4 afhængigt af tilgangen. LoRA tåler højere rater end fuld finjustering.
- LoRA-rang (r): 8-64. Højere = større kapacitet og større risiko for overtilpasning.
- Batchstørrelse: så stor, som hukommelsen tillader.
Ved de første finjusteringer bør du bruge standardværdierne fra en velkendt opskrift. Optimér kun hyperparametrene, hvis du har evalueringer til at styre arbejdet.
Trin 5: Evaluér (3-5 dage)
Kør hele evalueringspakken på den finjusterede model.
- Blev scoren bedre end basismodellens?
- Hvor meget bedre?
- Opstod der regressioner (generelle evner, sikkerhed, særtilfælde)?
Almindelige mønstre:
- Stor forbedring på målopgaven og mindre regression andetsteds: acceptabelt til en afgrænset anvendelse.
- Stor forbedring på målet og betydelig regression andetsteds: overtrænet. Reducér antallet af epoker eller LoRA-rangen.
- Marginal forbedring: Dataene kan være utilstrækkelige eller af lav kvalitet. Iterér på data, ikke hyperparametre.
- Ingen forbedring: Noget er galt. Kontrollér dataformat, træningslogfiler og evalueringsmetode.
Trin 6: Test i produktion (1-2 uger)
Inden fuld udrulning skal du A/B-teste:
- 5-10% af produktionstrafikken bruger finjusteringen.
- 90-95% bruger basismodellen.
- Sammenlign målepunkter: kvalitetsscorer, brugerfeedback og efterfølgende signaler.
Efter 1-2 ugers data kan du beslutte: fuld udrulning, yderligere iteration eller tilbagerulning.
Trin 7: Udrulning (1-2 dage)
For hostede tjenester: Peg blot på den finjusterede models ID. Det er enkelt.
For selvhostede løsninger: Opsæt en inferensserver (vLLM er standarden). Indlæs LoRA-adapteren. Dirigér trafikken.
Trin 8: Overvågning (løbende)
Finjusteringen er i produktion. Overvåg:
- Kvalitetsmålepunkter (onlineevalueringer, brugerfeedback).
- Drift over tid.
- Om forbedringer af basismodellen har lukket forskellen (evaluér jævnligt i forhold til den seneste basismodel).
Trin 9: Vedligeholdelse (hver 3-6 måned)
En finjustering er ikke noget, man »udgiver én gang og glemmer«.
- Basismodellen opdateres: Finjuster med jævne mellemrum igen på den nye base.
- Data ændrer sig: Opdatér træningsdataene, så de afspejler de aktuelle mønstre.
- Evalueringspakken udvides: Validér igen, efterhånden som nye testtilfælde opstår.
Et almindeligt mønster er en kvartalsvis cyklus med ny træning. Opdatér data, kør træningen, evaluér, og udrul, hvis resultatet er bedre.
Et gennemarbejdet eksempel
Et modelleret scenarie — vi kalder det bevidst det, og opskriften kan du selv køre med Axolotl-konfigurationen tidligere i artiklen: finjustering til en kundesupporttone.
Problemet: En SaaS-virksomhed har en stærk, venlig og ligefrem tone i sin supportkommunikation. Prompts rammer den kun inkonsekvent. Teamet ønsker et pålideligt tonematch på tværs af al AI-assisteret kommunikation.
Dataene: ~3,500 historiske supportsager, hvor svaret er vurderet som værende af høj kvalitet af erfarne supportmedarbejdere. Alle er renset for PII og standardiseret til ét format. Det er her, det meste af arbejdet ligger.
Tilgangen: LoRA på en open-weight-model med 8B parametre (Axolotl-konfigurationen ovenfor, en base i Qwen/Qwen3-8B-klassen), rank=16, 3 epoker og standardlæringsrate. Den kører på en enkelt lejet GPU med 24-80 GB i løbet af få timer; beregningsomkostningen er nogle få snese dollar. Den finjusterede model leveres via vLLM eller en administreret open-weight-host.
Sådan vurderer du den (beslut dette før træningen): Hold en del af supportsagerne tilbage, lad den samme erfarne bedømmer blindvurdere tonematchet i udkast fra basismodellen og den finjusterede model, og fastsæt tærsklen på forhånd. En vellykket kørsel af denne opskrift giver et tydeligt løft i blindvurderingen; kan bedømmeren ikke se forskel, var dataene ikke karakteristiske nok, og mere kuratering er bedre end flere epoker.
Vedligeholdelse: Træn igen hvert kvartal, efterhånden som nye supportsager af høj kvalitet samler sig — én dags arbejde pr. cyklus, når pipelinen først findes.
Vi angiver bevidst ikke præcise før/efter-procenter her: De ville være tal fra vores scenarie, ikke dit, og scorer for tonematch kan ikke overføres mellem datasæt. Når vi offentliggør vores egen målte kørsel, følger evalueringssættet og bedømmelsesprotokollen med.
Sådan ser en vellykket finjustering til produktion ud. Ikke magi, men disciplineret dataarbejde, beskeden beregningskraft og en evaluering, du definerede før træningen.
Almindelige fejlmønstre
Nogle typiske mønstre:
Fejl 1: Overtilpasning på små datamængder. 500 eksempler, 10 epoker. Modellen husker træningssættet og fejler på virkelige input. Løsning: flere data eller færre epoker.
Fejl 2: Katastrofal glemsel. Omfattende træning på afgrænsede opgaver forringer de generelle evner. Modellen bliver god til din opgave og dårligere til andre ting. Løsning: lavere læringsrate, færre epoker eller forskellige data uden for opgaven.
Fejl 3: Uoverensstemmende dataformater. Træningsdataene er formateret anderledes end den måde, modellen bruges på i produktion. Finjusteringen lærer den forkerte fordeling. Løsning: Sørg for, at formaterne til træning og inferens stemmer præcist overens.
Fejl 4: Utilstrækkelig evalueringsdækning. Evalueringssættet er let; produktionen er svær. Finjusteringen scorer godt i evalueringerne, men fejler hos rigtige brugere. Løsning: Medtag svære tilfælde i evalueringerne.
Fejl 5: Hyperparameterkaos. Hyperparametre justeres uden en metode. Nogle gange bedre, andre gange dårligere, og ingen lærer noget. Løsning: Skift én ting ad gangen, evaluér, og lær.
Fejl 6: Manglende vedligeholdelse. Finjusteringen kommer i drift, teamet går videre, og modellen bliver forældet. Seks måneder senere har forbedringer af basismodellen gjort den overflødig. Løsning: Planlæg ny træning.
Fejl 7: Utilstrækkelig opmærksomhed på sikkerhed. Finjustering svækker ofte standardafvisningerne. Uden sikkerhedseksempler kan den finjusterede model efterkomme ting, som basismodellen ville afvise. Løsning: Medtag eksempler på afvisning i træningsdataene.
Fejl 8: Tuning efter det forkerte målepunkt. Træningen presser modellen til at optimere efter et bestemt målepunkt, men den reelle brugerværdi er noget andet. Løsning: Vælg målepunkter, der stemmer overens med brugerværdien, og ikke blot stedfortrædere, der er nemme at måle.
Konkrete opskrifter, der virker
Her er nogle holdningsprægede opskrifter:
Opskrift 1: Struktureret output med strengt format
Mål: Pålideligt JSON-output i et bestemt skema.
Data: 2,000 eksempler på (input, gyldigt JSON-output).
Opskrift: LoRA, rank=8, 3 epoker på en lille model (8B). Kombinér med begrænset generering under inferens.
Resultat: 99%+ overholdelse af skemaet og meget høj hastighed.
Opskrift 2: Tonematch
Mål: Ensartet brandtone i kundevendt indhold.
Data: 3,000+ eksempler på (promptkontekst, output med korrekt tone). Kurateret af mennesker, der kan vurdere tonematchet.
Opskrift: LoRA, rank=16, 2-3 epoker på en mellemstor model (8-70B). Lavere læringsrate (1e-4) for stabilitet.
Resultat: En konsekvent tone, som prompting alene ikke kunne matche.
Opskrift 3: Specialiseret DSL eller domæne
Mål: Generér kode i et brugerdefineret DSL.
Data: 5,000-20,000 eksempler på (beskrivelse, gyldig kode).
Opskrift: LoRA på en kodespecialiseret model (Code Llama, DeepSeek Coder), rank=32, 3-5 epoker. En højere læringsrate (2e-4) fungerer ofte fint til kode.
Resultat: Flydende generering af DSL.
Opskrift 4: Mindre model, sammenlignelig kvalitet
Mål: Erstat en større model med en mindre, finjusteret model for at reducere pris og latenstid.
Data: 10K-50K eksempler, som den større model har genereret på virkelige input (syntetiske data).
Opskrift: LoRA på en lille model (8B), rank=16, 2-3 epoker. Inferens med vLLM for høj kapacitet.
Resultat: 5-10x lavere omkostninger og sammenlignelig kvalitet på den afgrænsede opgave.
Opskrift 5: Finjustering af sikkerhed og afvisning
Mål: Robust afvisning af bestemte problematiske kategorier.
Data: 1,000-3,000 eksempler på (problematisk anmodning, passende afvisning) plus 1,000+ eksempler på normale interaktioner (så modellen ikke afviser for meget).
Opskrift: LoRA, rank=8, 2 epoker og lav læringsrate (5e-5) til diskrete adfærdsændringer.
Resultat: Pålidelig afvisning af målkategorierne, samtidig med at modellen forbliver hjælpsom ved legitime anmodninger.
Det strategiske spørgsmål
Ud over mekanikken er finjustering et strategisk spørgsmål:
- Vil vi investere langsigtet i denne kapacitet eller bruge frontier-modeller til alt?
- Er vi villige til at vedligeholde en finjustering på ubestemt tid?
- Er kvalitetsgevinsten den løbende kompleksitet værd?
For de fleste teams er svaret: Finjuster selektivt til bestemte brugsscenarier med høj volumen eller stor strategisk værdi, og brug frontier-modeller til alt andet. Det er driftsmæssigt dyrt at vedligeholde mange finjusteringer.
De teams, der får mest ud af finjustering, vælger deres kampe. Én eller to velholdte finjusteringer med tydelig ROI. Ikke en flåde af halvt vedligeholdte finjusteringer.
Konklusionen
Finjustering er i 2026 tilgængelig på en måde, den ikke var for nylig. LoRA, hostede tjenester og billig beregningskraft betyder, at et lille team kan sætte en finjustering i produktion på 2-4 uger for under €500 i beregningsomkostninger.
Når det er sagt, er finjustering stadig det forkerte svar på de fleste problemer af typen »AI er ikke god nok«. Arbejd grundigt med prompting. Prøv RAG. Få evalueringer på plads. Vælg først derefter finjustering, og kun når du præcist kan formulere det hul, den skal lukke.
Når hullet er det rigtige — strengt format, ensartet tone, specialiseret domæne, omkostningsoptimering til opgaver med høj volumen — giver finjustering reelle, varige gevinster. Arbejd blot disciplineret med data, evalueringer og vedligeholdelse.
Til de rigtige problemer er finjustering forskellen på »AI, der virker det meste af tiden« og »AI, der bare virker«. Det er værd at gøre ordentligt.
