Hopp til innhold
← Blogg

AI og produktutviklingHafsteinn Runarsson · AI Konsulent21 Oct 2026 · 12 min

Fine-tuning av LLM: når bør du finjustere en språkmodell?

Fine-tuning av en LLM betyr at du trener en forhåndstrent språkmodell videre på eksempler fra en bestemt oppgave eller et fagområde. Det kan gi mer stabilt format, språk og adferd enn prompting alene. Men hvis behovet først og fremst er oppdatert kunnskap fra egne dokumenter, er RAG vanligvis et bedre startpunkt.

Denne guiden forklarer når finjustering er riktig, hvordan prosessen ser ut, og hva som må måles før en modell settes i produksjon.

Hva er fine-tuning av en LLM?

Finjustering er videre trening av en modell som allerede har lært generelle språkmønstre. I stedet for å starte med tilfeldige modellvekter tar du utgangspunkt i en forhåndstrent modell og tilpasser den til et smalere mål. Både Hiberus og Nexla beskriver finjustering som trening av en eksisterende modell på data for en bestemt oppgave eller et domene.

Et treningssett består ofte av par med input og ønsket output. Eksemplene viser modellen hvordan et godt svar ser ut i den aktuelle situasjonen. Det kan være:

  • en kundemelding og riktig kategorisering
  • en tekst og ønsket strukturert datauttrekk
  • en instruksjon og et godkjent svar i riktig tone og format
  • en sak og riktig neste handling

Finjustering endrer modellens parametere. Det skiller metoden fra prompting, der instruksjonen bare ligger i den aktive konteksten, og fra RAG, der systemet henter relevant informasjon og legger den inn i konteksten før modellen svarer.

Hvis du vil ha grunnlaget først, kan du lese hva en LLM er og hvordan den fungerer.

Når bør du finjustere en LLM?

Finjustering er mest nyttig når dere har en tydelig, gjentakbar oppgave og mange gode eksempler på ønsket adferd. Metoden passer dårlig som et generelt forsøk på å gjøre modellen «smartere».

Vurder finjustering når dere trenger at modellen skal:

  • følge et bestemt format stabilt
  • klassifisere eller trekke ut informasjon etter faste regler
  • bruke en konsekvent tone eller terminologi
  • håndtere en smal oppgave som prompting ikke løser godt nok
  • utføre samme type oppgave med kortere instrukser ved høy bruk

Start med en evaluerbar feil, ikke med teknologien. «Modellen svarer ulikt på like saker» kan undersøkes. «Vi vil ha en modell som kjenner virksomheten» er for uklart til å bli et godt treningsmål.

Et godt finjusteringsprosjekt har også en tydelig baseline. Dere må vite hvordan grunnmodellen presterer med den beste realistiske prompten før dere kan avgjøre om ekstra trening gir en forbedring.

Når er prompting eller RAG bedre?

Prompting er førstevalget når gode instrukser og noen få eksempler i prompten gir stabil nok kvalitet. RAG er førstevalget når modellen må bruke oppdaterte, private eller sporbare kilder. Finjustering bør komme etter at de enklere alternativene er testet.

Forskjellene kan oppsummeres slik:

  • Prompting: endrer instruksjonen, men ikke modellen. Passer når oppgaven kan forklares tydelig i konteksten.
  • RAG: henter relevante dokumentutdrag ved hver forespørsel. Passer når svarene må bygge på informasjon som endres eller må kunne spores til en kilde.
  • Finjustering: endrer modellens parametere gjennom ekstra trening. Passer når ønsket adferd eller output ikke blir stabil nok med prompt og kontekst.
  • RAG og finjustering sammen: kombinerer kildebaserte svar med en modell som er tilpasset en bestemt oppgave eller svarform.

IBMs sammenligning av RAG og fine-tuning beskriver samme hovedskille: RAG kobler modellen til eksterne datakilder, mens finjustering tilpasser modellen til en bestemt oppgave.

Hvis en chatbot skal svare på gjeldende rutiner, priser eller produktdokumentasjon, bør informasjonen normalt hentes når spørsmålet stilles. Hvis modellen skal klassifisere henvendelser etter en stabil intern taksonomi, kan finjustering være mer relevant. Mange produksjonsløsninger trenger begge deler, men de løser ulike problemer.

Full finjustering, PEFT og LoRA

De fleste team bør vurdere parameter-effektiv finjustering før de trener alle modellens parametere. Full finjustering gir større frihet til å endre modellen, men stiller høyere krav til regnekraft, lagring og drift.

De vanligste tilnærmingene er:

  • Full finjustering: alle eller store deler av modellens parametere oppdateres. Metoden kan være aktuell når oppgaven avviker mye fra grunnmodellen og teamet har nok data og infrastruktur.
  • Parameter-efficient fine-tuning (PEFT): bare et lite antall ekstra eller utvalgte parametere trenes. Grunnmodellen beholdes i stor grad uendret.
  • LoRA: en PEFT-metode som legger til små trenbare matriser i modellen. Resultatet kan lagres som en adapter i stedet for en full kopi av alle modellvektene.
  • QLoRA: kombinerer LoRA med kvantisering for å redusere minnebehovet under trening.

Sebastian Raschkas gjennomgang av finjusteringsmetoder sammenligner blant annet trening av utvalgte lag, full finjustering og parameter-effektive metoder.

Metoden bør velges ut fra målet. En liten adapter er ikke automatisk god nok, og full finjustering er ikke automatisk bedre. Sammenlign variantene på samme testsett og ta med både kvalitet, responstid, treningskostnad og driftsbehov.

Slik lager du et godt treningsdatasett

Datakvaliteten setter taket for hva modellen kan lære. Treningssettet må ligne de virkelige forespørslene, inneholde konsistente fasitsvar og dekke feiltypene dere faktisk vil rette.

En praktisk prosess er:

  1. Samle representative input fra den virkelige arbeidsflyten.
  2. Fjern eller beskytt personopplysninger og annet innhold som ikke skal brukes til trening.
  3. Definer ett tydelig svarformat og kriterier for et godt resultat.
  4. La fagpersoner lage eller godkjenne fasitsvar.
  5. Ta med normale saker, vanskelige varianter og tilfeller modellen skal avvise.
  6. Fjern duplikater, motstridende eksempler og svar som lærer modellen uønsket adferd.
  7. Del data i separate trenings-, validerings- og testsett før treningen starter.

Et eksempel må vise hele situasjonen modellen møter i produksjon. Hvis modellen skal klassifisere en supporthenvendelse, bør eksemplet inneholde den samme typen kontekst og instruksjon som den får senere. Fasitsvaret må bruke nøyaktig den kategorien eller datastrukturen systemet forventer.

Nexlas guide fremhever datasettet, modellen og hyperparameterne som sentrale deler av finjusteringen, og peker på at datakvaliteten påvirker sluttresultatet.

En trygg prosess fra baseline til produksjon

Bygg evalueringsopplegget før dere starter treningen. Uten en fast test kan dere se at treningsjobben er ferdig, men ikke om modellen faktisk ble bedre.

  1. Definer oppgaven. Beskriv input, ønsket output, akseptkriterier og hvilke saker som ligger utenfor omfanget.
  2. Mål grunnmodellen. Test den beste prompten dere klarer å lage på et representativt testsett.
  3. Velg modell og metode. Avklar lisens, språkstøtte, kontekstvindu, drift og om full finjustering eller PEFT passer.
  4. Forbered data. Rens, merk, kvalitetssikre og del datasettet uten lekkasje mellom trening og test.
  5. Kjør et lite eksperiment. Start med en avgrenset treningsjobb og registrer datasettversjon, modell, kode og innstillinger.
  6. Evaluer mot baseline. Sammenlign grunnmodell og finjustert modell på nøyaktig de samme tilfellene.
  7. Test sikkerhet og avvisning. Ta med sensitive forespørsler, tvetydige instrukser og input modellen ikke skal behandle.
  8. Pilotér i arbeidsflyten. La brukere prøve modellen med logging og menneskelig kontroll før automatisering økes.
  9. Overvåk etter lansering. Følg kvalitet, feiltyper, kostnad, responstid og endringer i data over tid.

Prosessen bør kunne gjentas. Versjoner data, innstillinger og evalueringsresultater slik at teamet vet hva som faktisk ble endret mellom to modellvarianter.

Hvordan måler du om finjusteringen virker?

En finjustert modell er bare bedre hvis den løser den definerte oppgaven bedre enn baselinen. Treningskurver alene er ikke nok.

Velg målinger som passer oppgaven:

  • Klassifisering: andel riktige kategorier og hvilke kategorier modellen forveksler
  • Datauttrekk: korrekte felt, manglende felt og ugyldig struktur
  • Tekstgenerering: faglig korrekthet, instruksjonsfølge, tone og uønskede påstander
  • Verktøybruk: riktig verktøy, riktige argumenter og trygg håndtering av feil
  • Drift: responstid, kostnad per godkjent resultat og behov for menneskelig retting

Hold et låst testsett som aldri brukes i treningen. Legg også til nye regresjonstester når dere finner en produksjonsfeil. Da kan teamet kontrollere at neste datasett- eller modellversjon retter feilen uten å ødelegge noe som allerede fungerer.

Åpen tekst bør vurderes med tydelige kriterier, ikke bare med en generell magefølelse. La fagpersoner vurdere et representativt utvalg og sammenligne modellene uten å vite hvilken variant som laget hvert svar.

Vanlige feil ved fine-tuning av LLM-er

De dyreste feilene oppstår før treningen starter. Et uklart mål eller et inkonsistent datasett kan ikke repareres med flere epoker.

Unngå særlig disse feilene:

  • Bruke finjustering som kunnskapsdatabase. Modellen er ikke et pålitelig oppslagsverk for informasjon som endres. Bruk RAG eller andre datakilder.
  • Trene på modellgenererte svar uten kontroll. Feil og uønsket stil kan bli gjentatt i hele datasettet.
  • Teste på treningsdata. Resultatet sier lite om hvordan modellen håndterer nye saker.
  • Mangle baseline. Da vet dere ikke om forbedringen skyldes trening, en bedre prompt eller bare et enklere testsett.
  • Blande ulike svarstandarder. Motstridende fasitsvar lærer modellen at flere uforenlige mønstre er riktige.
  • Ignorere personvern og lisens. Avklar retten til å bruke både datasett og grunnmodell før trening.
  • Måle gjennomsnitt uten å se på feiltypene. En god totalscore kan skjule svake resultater i saker med høy konsekvens.
  • Sette modellen direkte i automatisert produksjon. Start med begrenset tilgang, observasjon og en tydelig vei til menneskelig godkjenning.

Finjustering kan også svekke egenskaper modellen hadde fra før. Test derfor både måloppgaven og relevante generelle ferdigheter som produksjonsløsningen fortsatt er avhengig av.

Hva koster fine-tuning av en LLM?

Kostnaden avhenger av modellstørrelse, metode, antall tokens, maskinvare og hvor mange eksperimenter dere må kjøre. Selve treningsjobben er bare én del av regnestykket.

Ta med:

  • innsamling, merking og kvalitetssikring av data
  • trening og lagring av modell eller adaptere
  • evalueringsarbeid og faglig kontroll
  • hosting, skalering og overvåking
  • nye treningsrunder når oppgaven eller datagrunnlaget endres
  • sikkerhet, tilgangsstyring og hendelseshåndtering

PEFT kan redusere behovet for regnekraft og lagring, men sparer ikke teamet for arbeidet med gode data og evaluering. En billig treningsjobb med svakt datasett kan bli dyr når feilene oppdages i produksjon.

Sjekkliste før dere finjusterer

Start treningen først når dere kan svare ja på disse punktene:

  • Oppgaven er smal, gjentakbar og målbar.
  • Prompting med gode eksempler er testet som baseline.
  • RAG er vurdert dersom behovet handler om kunnskap eller dokumenter.
  • Treningsdata er representative, konsistente og lovlige å bruke.
  • Testsettet er skilt fra treningsdata.
  • Akseptkriterier og stoppkriterier er skrevet ned.
  • Modell, lisens, drift og sikkerhetskrav er avklart.
  • En fagperson skal kontrollere resultatene før større automatisering.
  • Teamet har en plan for versjonering, overvåking og tilbakeføring.

Hvis flere svar er nei, er neste steg vanligvis bedre problemavgrensning eller et evalueringssett, ikke en større treningsjobb.

Er fine-tuning det samme som å trene en LLM fra bunnen?

Nei. Trening fra bunnen starter med uinnlærte parametere og krever store mengder data og regnekraft. Finjustering starter med en forhåndstrent modell og fortsetter treningen på et mindre datasett for en bestemt oppgave eller et fagområde.

Kan fine-tuning lære modellen nye fakta?

Finjustering kan påvirke hvilke mønstre og formuleringer modellen gjengir, men er ikke en god erstatning for et oppdatert og kontrollerbart kunnskapsgrunnlag. Bruk RAG når svar må bygge på gjeldende dokumenter eller når kilden må kunne vises.

Hvor mye data trenger man for å finjustere en LLM?

Det finnes ikke ett riktig antall. Behovet avhenger av oppgaven, variasjonen i input, kvaliteten på fasitsvarene og hvor godt grunnmodellen allerede presterer. Start med et lite, godt kontrollert datasett og mål om nye eksempler forbedrer resultatene på et separat testsett.

Hva er forskjellen på LoRA og full finjustering?

Full finjustering oppdaterer alle eller mange av modellens eksisterende parametere. LoRA trener små tilleggsmatriser og lar hovedvektene være urørt. LoRA krever derfor vanligvis mindre lagring og regnekraft, mens full finjustering kan gi større frihet til å endre modellen.

Kan man kombinere RAG og fine-tuning?

Ja. RAG kan hente oppdatert og sporbar kunnskap, mens finjustering kan tilpasse hvordan modellen tolker oppgaven eller formaterer svaret. Kombinasjonen bør bare brukes når testing viser at begge delene løser hvert sitt tydelige problem.

Hva er første steg?

Første steg er å lage et representativt evalueringssett og måle en grunnmodell med en god prompt. Hvis de samme feilene består og dere har konsistente eksempler på riktig adferd, har dere et konkret grunnlag for å teste finjustering.

Vil dere vurdere om en konkret arbeidsflyt trenger prompting, RAG eller finjustering? Start med å beskrive oppgaven, datagrunnlaget og hvordan et godt resultat skal måles.

Har du et system som må leveres?

Få et tilbud