Slik finjusterer du en LLM [og når du bør bruke RAG eller prompting i stedet]

Finjustering av en stor språkmodell (LLM) betyr å trene en forhåndstrent LLM videre på et lite, oppgavespesifikt datasett, slik at den gir resultater du ikke kan oppnå med prompting alene.

Finjustering innebærer å samle inn eksempelpar med input og output som viser atferden du ønsker, kjøre treningsrunder som flytter modellens vekter i retning av dem, og sammenligne resultatet med utdataene fra den opprinnelige modellen. Parametereffektive metoder som LoRA gjør dette så rimelig at det kan kjøres på én enkelt GPU.

Hvis du ikke er fornøyd med utdataene fra LLM-en, bør du først forbedre promptene og RAG-oppsettet (retrieval-augmented generation). Finjustering endrer hvordan LLM-en oppfører seg. Når du trenger at den bruker fersk eller proprietær informasjon, er prompting og RAG vanligvis et bedre valg.

Her ser du hvordan du finjusterer en LLM trinn for trinn, hvilke finjusteringsmetoder som er de viktigste (LoRA og QLoRA), og hvilke utfordringer og feil som kan ødelegge prosessen.

Hva LLM-finjustering er, og hvordan det skiller seg fra forhåndstrening av LLM-er

Forhåndstrening av en LLM bygger opp modellens generelle språkevner fra bunnen av på et enormt tekstkorpus, mens finjustering tilpasser en forhåndstrent modell på et lite datasett for én bestemt oppgave.

Forhåndstrening av en LLM er den ressurskrevende fasen som produserer en basismodell. Modellen lærer av et bredt tekstkorpus, noe som gir den generell grammatikk, faktakunnskap og resonneringsevne, men ingen spesialisering for din oppgave.

Finjustering av en LLM viderefører treningen av basismodellen på et lite, kuratert datasett, slik at den gir de ønskede resultatene for en bestemt oppgave eller et bestemt bruksområde. Tenk for eksempel på et konsekvent format, en merkevarestemme eller tone, domenespesifikke mønstre eller pålitelige verktøy- og funksjonskall.

Når du bør finjustere LLM-er, og når du heller bør bruke prompting eller RAG

For å forbedre ytelsen til en LLM bør du jobbe deg oppover stigen: prompting -> RAG -> finjustering.

Forbedre promptene med mer detaljerte instruksjoner, og bruk RAG for å gi modellen oppdatert informasjon. Bruk finjustering bare når forbedringer av prompter og gjenfinning ikke gir ønsket effekt.

Når bedre prompter slår finjustering, og når de ikke er nok

Prompting er det raskeste og billigste virkemiddelet. I mange tilfeller gir mer presise og detaljerte prompter de ønskede endringene i atferd.

Men lengre prompter gjør arbeidet tregere og dyrere, og de kan ikke overvinne eksisterende begrensninger i modellen.

Tegn på at prompting kan ha nådd grensene sine:

• Nye grensetilfeller ødelegger stadig utdataene: Modellen returnerer for eksempel løpende tekst når du trenger JSON, eller bommer på tonen, og du lapper prompten for hvert nye tilfelle.
• Systemprompten vokser stadig: Prompten er på hundrevis eller tusenvis av linjer og er vanskelig å håndtere.
• Du betaler for det i hvert kall: Prompten sendes og behandles på nytt ved hver forespørsel, så tokenkostnaden og forsinkelsen øker.
• Endringer gjør ikke lenger noen forskjell: Nye instruksjoner forbedrer ikke utdataene.

Selv da bør du prøve de billigere løsningene på promptnivå først. Bruk few-shot-eksempler for å vise modellen mønsteret (par med input og output), promptkjeding for å dele opp vanskelige oppgaver i mindre trinn, eller funksjonskall for å overlate nøyaktige oppslag eller beregninger til andre verktøy.

Når RAG gir mer mening enn å finjustere modellen

RAG endrer hva LLM-en vet, mens finjustering endrer hvordan den oppfører seg. Hvis gapet handler om kunnskap, særlig kunnskap som endres ofte eller finnes i dine egne dokumenter, er RAG svaret. Hvis gapet handler om atferd, bør du finjustere.

Finjustering påvirker også hva en modell vet, men fakta den tar opp, fryses på treningstidspunktet og blir fort utdaterte i felt i rask utvikling. I tillegg blir informasjonen bakt inn i modellens vekter, så det finnes ingen oversikt over hvor den kommer fra.

Å oppdatere kildedokumentene som et gjenfinningslag bruker, er raskere og billigere, og gjenfinningslaget kan vise til nøyaktig hvilke kilder det brukte. Det gjør RAG til et bedre valg når du trenger etterprøvbar, oppdatert informasjon.

Ulempen med RAG? Det er et ekstra lag som må bygges og vedlikeholdes, og det gir økt forsinkelse.

I praksis trenger du ofte begge deler. Produksjonssystemer kombinerer finjusterte modeller med RAG og bruker det ene for konsekvent atferd og det andre for oppdaterte fakta.

Vanlige fallgruver, risikoer og utfordringer ved finjustering

Selv når finjustering er det riktige verktøyet, medfører det kostnader og risikoer:

• Kostnader og tid: Det er dyrt både å sette sammen rene, representative treningsdata og å betale for regnekraften til treningen.
• Katastrofal glemsel: Når en modell trenes på et smalt datasett, kan den miste generelle ferdigheter og få nye feilmønstre, noe som fører til feil som basismodellen ikke gjorde.
• Overtilpasning: Med for lite eller for repetitive data pugger modellen treningseksemplene i stedet for å lære mønstre, så den presterer godt på treningsdataene, men dårlig på reelle input.
• Utdatert kunnskap: Kunnskap som er bakt inn i vektene, blir fort utdatert, så du må trene modellen på nytt med nye data.
• Foreldelse: Når en sterkere modell lanseres, slår den ofte den finjusterte modellen din uten noen tilpasning, og du må gjøre arbeidet på nytt.
• Utfordringer med evaluering og reproduserbarhet: Det er vanskelig å bevise at den finjusterte modellen yter bedre enn basismodellen. To treningskjøringer på GPU med de samme innstillingene kan dessuten gi litt forskjellige modeller.
• Datastyring: Trening på proprietære eller sensitive data reiser spørsmål om personvern og lisensiering; en modell kan senere gjengi fragmenter av det den ble trent på.

De viktigste finjusteringsmetodene

De viktigste typene LLM-finjustering skiller seg fra hverandre i hvor mye av modellen de endrer: Full finjustering trener hele modellen på nytt, mens metoder for parametereffektiv finjustering (PEFT), som LoRA og QLoRA, bare oppdaterer noen av vektene. PEFT-metoder bruker bare en brøkdel av minnet som full finjustering krever, og med de riktige innstillingene kan de gi like gode resultater.

Full finjustering oppdaterer alle vektene i modellen. Det er den dyreste metoden og gir størst risiko for katastrofal glemsel. Reserver den for store atferdsendringer når du har dataene og regnekraften som trengs.

Alternativet er parametereffektiv finjustering, eller PEFT. Det er en samlebetegnelse for metoder som fryser det meste av modellen og bare trener et lite sett med parametere. Det krever langt mindre minne og er mindre utsatt for glemsel, siden basismodellen forblir intakt.

Ved lave ranger lærer PEFT mindre enn full finjustering, men hvis du øker rangen og justerer læringsraten, lukkes det meste av gapet på oppgaver med instruksjonstilpasning.

PEFT-metodene omfatter:

• LoRA (Low-Rank Adaptation): Det vanlige utgangspunktet. Metoden fryser de opprinnelige vektene og trener et lite sett med ekstra adapterparametere, ofte under 1 % av totalen, slik at den kan kjøres på én enkelt forbruker-GPU.
• QLoRA (Quantized Low-Rank Adaptation): Metoden komprimerer basismodellen til 4-biters presisjon før LoRA brukes, slik at du kan finjustere en stor modell på én enkelt GPU.

I tillegg bruker vi metoder for instruksjonstilpasning og preferansetilpasning, fra RLHF (Reinforcement Learning from Human Feedback) til lettere alternativer som Direct Preference Optimization (DPO) og Odds Ratio Preference Optimization (ORPO), for å forme hvordan en modell følger instruksjoner og samsvarer med menneskelige preferanser.

Slik finjusterer du en LLM trinn for trinn

Når du har bestemt deg for at finjustering av en LLM er riktig valg, ser arbeidsflyten slik ut.

Forstørr

Trinn 1: Definer oppgaven og hvordan du skal måle suksess

Bestem hvilken atferd du vil ha fra LLM-en, og hvordan du skal vite at du har oppnådd den.

Angi den konkrete oppgaven du vil at den finjusterte modellen skal utføre, for eksempel å klassifisere supportsaker, oppsummere kontrakter i et fast format eller generere kode i deres interne kodestil.

Definer deretter hva suksess er. Vanlige alternativer er blant annet:

• Gyldige utdata: Kan resultatet for eksempel tolkes som gyldig JSON, eller samsvarer det med Markdown-strukturen du trenger?
• Automatiske poengsummer: Bruk måltall som BLEU eller ROUGE, som sammenligner generert tekst med referansesvar, eller oppgavenøyaktighet på et merket datasett.
• Menneskelige vurderinger: En vurderingsmal med poeng eller bestått/ikke bestått for egenskaper som et skript vurderer dårlig, for eksempel tone eller hjelpsomhet.
• Pålitelighet ved vanskelige input: Håndterer modellen de uvanlige inputene som basismodellen slet med?

Trinn 2: Klargjør datasettet

Datakvaliteten avgjør om finjusteringen lykkes, så legg ned innsats i å samle inn det riktige datasettet for finjustering.

Formater dataene som instruksjons-/svarpar i JSONL, der hver linje inneholder input (pluss eventuell kontekst) og nøyaktig det svaret du vil ha tilbake.

Ta for eksempel en titt på offentlige datasett som det generelle instruksjonsdatasettet Alpaca-cleaned eller Databricks' Dolly, eller det oppgavespesifikke banking77, som inneholder over 13 000 ekte supporthenvendelser merket med 77 intensjoner.

For en avgrenset oppgave kan noen hundre til noen tusen rene, varierte eksempler være nok til å endre atferden, så lenge eksemplene speiler reelle input fra produksjon, inkludert grensetilfellene, og er konsekvent formatert.

Har du ingen input/output-par ennå? Bygg settet fra dataene du allerede har, for eksempel supportsaker og de beste svarene på dem, eller dokumenter og sammendragene av dem.

Hvis du bare har utdataene, kan du bruke en sterkere modell til å generere en plausibel input for hver av dem, eller skrive et lite startsett for hånd og utvide det med en større «lærermodell». Behold deretter de beste parene.

Avslutt med å dele dataene inn i trenings-, validerings- og testsett, slik at du kan måle på eksempler modellen ikke har sett.

Trinn 3: Velg en basismodell og en metode

Start med en liten modell med åpen kildekode på 3 til 7 milliarder parametere og en parametereffektiv finjusteringsmetode som LoRA eller QLoRA.

Åpne modellfamilier som Llama, Mistral og Qwen gir deg et sterkt utgangspunkt du kan drifte selv, og PEFT-metodene holder maskinvarekravene lave: QLoRA kvantiserer basismodellen til 4 bit, så finjustering av en 7B-modell krever bare et forbrukergrafikkort med 16–24 GB. Full finjustering av den samme modellen krever mange ganger så mye minne.

Trinn 4: Angi hyperparametere for treningen

Her er de viktigste parameterne for LLM-finjustering og foreslåtte startverdier:

• Læringsraten styrer hvor stor hver oppdatering av vektene er. En studie fra 2024 av Biderman et al. fant at de beste læringsratene for LoRA lå omtrent ti ganger høyere enn for full finjustering, typisk 5e-5 til 5e-4 mot 1e-5 til 5e-5. Studien anbefaler å teste verdier fra 1e-5 til 5e-4 og bruke den høyeste verdien som gir stabil trening.
• Batchstørrelse er hvor mange eksempler modellen lærer av før hver vektoppdatering. På én enkelt GPU bør du bruke en liten batch på 1 til 8 per enhet og gradientakkumulering for å nå en effektiv batch på omtrent 16 til 64.
• Antall epoker er hvor mange ganger modellen ser hele datasettet. Når du trener modellen til å utføre bestemte oppgaver, er 1–3 en god tommelfingerregel, men LoRA-kjøringer trenger ofte flere.
• LoRA-rang (r) bestemmer adapterens kapasitet, altså hvor mye den kan lære. Start med 8 til 32 for enklere oppgaver, og øk den for vanskeligere oppgaver: I LoRA-studien til Biderman et al. som er omtalt ovenfor, trengte instruksjonsjustering av en 7B-modell på kode rang 256 for å matche full finjustering, mens rang 64 var nesten like god på matematikk.
• Maksimal sekvenslengde er den lengste inndatasekvensen kjøringen behandler. Sett den slik at den dekker de lengste eksemplene dine, opp til modellens kontekstvindu, ettersom alt som er lengre, blir avkortet.
• Oppvarming og læringsrateplan styrer hvordan læringsraten trappes opp og endres gjennom kjøringen. En kort oppvarming og en cosinusbasert nedtrapping er de vanlige standardvalgene. Småmodellstudien til Pareja et al. fant imidlertid at det å sløyfe oppvarmingen ikke svekket de endelige resultatene.

Se på disse som utgangspunkt for et parametersøk, ikke som faste innstillinger.

Trinn 5: Tren og overvåk tapet

Mens treningen pågår, bør du følge med på tapskurvene for trening og validering for å se om det fungerer.

Tapet måler hvor langt modellens utdata ligger fra eksemplene dine, og det bør synke jevnt etter hvert som kjøringen skrider frem. Treningstapet gjelder dataene modellen lærer av. Valideringstapet måles på de tilbakeholdte eksemplene.

Hvis treningstapet og valideringstapet synker sammen, lærer modellen å generalisere. Hvis treningstapet fortsetter å synke mens valideringstapet flater ut eller stiger, pugger modellen treningssettet i stedet for å lære mønsteret (overtilpasning).

Forstørr

Trinn 6: Evaluer først, og distribuer deretter

Et lavt treningstap garanterer ikke riktige utdata, så vurder den finjusterte modellen ut fra kriteriene du satte i trinn 1.

Når den består, har du to måter å distribuere den på:

• Kjør adapteren oppå basismodellen, og last inn begge ved kjøretid; da forblir adapteren utskiftbar.
• Slå sammen adapteren med basisvektene for å få én frittstående modell som er enklere å drifte.

Bruk Perplexity til å gi LLM-en din tilgang til oppdatert informasjon

Finjustering er det riktige valget når du vil tilpasse modellens atferd til dine behov.

Hvis modellen din trenger aktuell informasjon, særlig informasjon som endrer seg raskt, trenger du RAG eller et pålitelig søkeverktøy fra en tredjepart.

En egendefinert gjenfinningsstakk fungerer best for proprietære datasett, for eksempel den interne wikien din, kundestøttehistorikk, kontrakter eller produktdokumentasjon.

Når kunnskapen du vil bruke, er offentlig, er det ikke nødvendig å bygge et skreddersydd gjenfinningslag. Perplexity er en svarmotor som gir svar med klikkbare kildehenvisninger i teksten, hentet fra en løpende oppdatert nettindeks. Agent API fra Perplexity leverer slike nettforankrede svar med kildehenvisninger i ett enkelt kall, slik at appen din kan bygge på oppdaterte kilder.

Vanlige spørsmål om finjustering av LLM-er

Kan du finjustere en LLM gratis?

Ja, du kan finjustere en liten åpen LLM gratis. Gratisnivået i Google Colab gir deg for eksempel nok GPU-kapasitet til å kjøre QLoRA på en modell på 3B til 8B, noe som er mer enn nok for en avgrenset oppgave. Du begynner å betale når du trenger mer minne, lengre kjøringer eller en større basismodell enn gratisnivået har plass til.

Trenger du din egen GPU, eller kan du finjustere i skyen?

Du trenger ikke å eie en GPU for å finjustere LLM-er. Administrerte tjenester og leverandører av GPU-skytjenester leier ut maskinvaren per time, så én leid GPU holder til en QLoRA-kjøring med en liten modell. Det lønner seg bare å kjøpe en GPU hvis du finjusterer ofte eller må ha alle dataene dine på egne maskiner.

Hvor lang tid tar det å finjustere LLM-er?

For en liten LLM kan en kjøring ta alt fra noen minutter til noen timer, avhengig av datasettets størrelse og maskinvaren. Oumi gjennomførte for eksempel full finjustering av en 0,8B-modell på litt over én time på sin egen hostede plattform.

Større modeller eller titusenvis av eksempler trekker tiden opp mot et døgn eller mer: LoRA-kjøringene til Emburse på en 7B-modell tok 8 timer for 5 000 eksempler og rundt 30 timer for 50 000 på én enkelt GPU med 40 GB.

Kan du fortsette å oppdatere en finjustert modell etter hvert som dataene dine endrer seg?

Du kan finjustere på nytt med ferske data, men hver runde koster regnekraft og gir risiko for katastrofal glemming. For kunnskap som endres ofte, er RAG som regel den bedre løsningen, siden du oppdaterer kildedokumentene i stedet for å trene modellen på nytt.