Sådan finjusterer du en LLM [og hvornår du i stedet skal bruge RAG eller prompting]

At finjustere en stor sprogmodel (LLM) vil sige at videretræne en fortrænet LLM på et lille, opgavespecifikt datasæt, så den leverer output, som du ikke kan få med prompting alene.

Finjustering går ud på at indsamle eksempler på input/output-par, der viser den ønskede adfærd, køre træningsrunder, der flytter modellens vægte i retning af dem, og sammenligne resultatet med den oprindelige models output. Parametereffektive metoder som LoRA gør det så billigt, at det kan køres på en enkelt GPU.

Hvis du ikke er tilfreds med LLM'ens output, så forbedr først dine prompts og din retrieval-augmented generation (RAG). Finjustering ændrer, hvordan LLM'en opfører sig. Når den skal bruge nye eller proprietære oplysninger, er prompting og RAG som regel et bedre valg.

Her gennemgår vi, hvordan du finjusterer en LLM trin for trin, de vigtigste finjusteringsmetoder (LoRA og QLoRA) samt de udfordringer og fejl, der kan få processen til at gå galt.

Hvad er LLM-finjustering, og hvordan adskiller den sig fra LLM-fortræning

LLM-fortræning opbygger en models generelle sprogevner fra bunden på et enormt korpus, mens LLM-finjustering tilpasser en fortrænet model på et lille datasæt til én bestemt opgave.

LLM-fortræning er den ressourcetunge fase, der frembringer en basismodel. Modellen lærer af et bredt tekstkorpus, som giver den generel grammatik, faktaviden og ræsonneringsevne, men ingen specialisering i din opgave.

LLM-finjustering fortsætter træningen af basismodellen på et lille, kurateret datasæt, så den giver det ønskede output til en bestemt opgave eller et bestemt anvendelsesscenarie. Tænk på et ensartet format, en bestemt brandstemme eller tone, domænespecifikke mønstre eller pålidelige værktøjs- og funktionskald.

Hvornår du skal finjustere LLM'er, og hvornår du hellere skal bruge prompting eller RAG

Arbejd dig op ad stigen for at forbedre en LLM's ydeevne: prompting -> RAG -> finjustering.

Forbedr dine prompts med mere detaljerede instruktioner, og brug RAG til at give modellen opdaterede oplysninger. Brug kun finjustering, når forbedringer af prompts og retrieval ikke slår til.

Hvornår bedre prompts slår finjustering, og hvornår de ikke er nok

Prompting er det hurtigste og billigste greb. I mange tilfælde opnår du de ønskede adfærdsændringer med mere præcise og detaljerede prompts.

Men længere prompts gør arbejdet langsommere og dyrere og kan ikke overvinde modellens eksisterende begrænsninger.

Tegn på, at prompting måske har nået sin grænse:

• Nye grænsetilfælde bliver ved med at ødelægge outputtet: Modellen returnerer f.eks. prosatekst, når du har brug for JSON, eller rammer en forkert tone, og du lapper prompten for hvert nyt tilfælde.
• Systemprompten bliver ved med at vokse: Prompten fylder hundredvis eller tusindvis af linjer og er svær at håndtere.
• Du betaler for den ved hvert kald: Prompten sendes og behandles igen ved hver forespørgsel, så tokenomkostningerne og latensen vokser.
• Ændringer gør ikke længere nogen forskel: Nye instruktioner forbedrer ikke outputtet.

Selv da bør du først prøve de billigere løsninger på promptniveau. Brug few-shot-eksempler til at vise modellen mønsteret (input/output-par), prompt chaining til at opdele svære opgaver i mindre trin eller hooks til funktionskald for at uddelegere præcise opslag eller beregninger.

Hvornår RAG giver mere mening end at finjustere modellen

RAG ændrer, hvad LLM'en ved, mens LLM-finjustering ændrer, hvordan den opfører sig. Hvis manglen handler om viden, især viden, der ofte ændrer sig eller findes i dine egne dokumenter, er RAG svaret. Hvis manglen handler om adfærd, skal du finjustere.

Finjustering ændrer også, hvad en model ved, men de fakta, den optager, fryses på træningstidspunktet og bliver hurtigt forældede inden for områder i hurtig udvikling. Desuden bliver informationen indbygget i modellens vægte, så vægtene ikke rummer nogen oplysning om, hvor den stammer fra.

Det er hurtigere og billigere at opdatere de kildedokumenter, som et retrieval-lag bruger, og laget kan henvise til præcis de kilder, det har brugt. Det gør det til et bedre valg, når du har brug for opdaterede oplysninger, der kan dokumenteres.

Ulempen ved RAG? Det er et ekstra lag, der skal bygges og vedligeholdes, og det øger latensen.

I praksis får du ofte brug for begge dele. Produktionssystemer kombinerer finjusterede modeller med RAG og bruger den ene til ensartet adfærd og den anden til aktuelle fakta.

Almindelige faldgruber, risici og udfordringer ved finjustering

Selv når finjustering er det rette værktøj, medfører det omkostninger og risici:

• Omkostninger og tid: Det er dyrt at indsamle rene, repræsentative træningsdata, og det samme gælder regnekraften til træningen.
• Katastrofal glemsel: Når en model trænes på et snævert datasæt, kan den miste generelle færdigheder og udvikle nye fejlmønstre, hvilket fører til fejl, som basismodellen ikke lavede.
• Overfitting: Med for få eller for ensartede data lærer modellen dine træningseksempler udenad i stedet for at lære mønstre, så den klarer sig godt på sine træningseksempler, men dårligt på rigtige input.
• Forældet viden: Viden, der er indbygget i vægtene, bliver hurtigt uaktuel, så du er nødt til at gentræne på nye data.
• Forældelse: Når en stærkere model udkommer, slår den ofte din finjusterede model uden nogen tilpasning, og du må gøre arbejdet om.
• Udfordringer med evaluering og reproducerbarhed: Det er svært at bevise, at den finjusterede model klarer sig bedre end basismodellen. To træningskørsler på GPU med de samme indstillinger kan også give en smule forskellige modeller.
• Datastyring: Træning på proprietære eller følsomme data rejser spørgsmål om privatliv og licenser; en model kan senere gengive brudstykker af det, den er trænet på.

De vigtigste finjusteringsmetoder

De vigtigste typer LLM-finjustering adskiller sig ved, hvor meget af modellen de ændrer: Fuld finjustering gentræner hele modellen, mens metoder til parametereffektiv finjustering (PEFT) som LoRA og QLoRA kun opdaterer nogle af vægtene. PEFT-metoder kræver kun en brøkdel af den hukommelse, som fuld finjustering bruger, og kan med de rette indstillinger give tilsvarende resultater.

Fuld finjustering opdaterer alle modellens vægte. Det er den dyreste metode og har den højeste risiko for katastrofal glemsel. Reserver den til store adfærdsændringer, når du har data og regnekraft nok til det.

Alternativet er parametereffektiv finjustering, eller PEFT. Det er en samlebetegnelse for metoder, der fryser størstedelen af modellen og kun træner et lille sæt parametre. Det bruger langt mindre hukommelse og er mindre tilbøjeligt til glemsel, da basismodellen forbliver intakt.

Ved lave rangværdier lærer PEFT mindre end fuld finjustering, men ved at hæve rangen og justere læringsraten kan du lukke det meste af forskellen på opgaver med instruktionstuning.

PEFT-metoderne omfatter:

• LoRA (Low-Rank Adaptation): Det sædvanlige udgangspunkt. Metoden fryser de oprindelige vægte og træner et lille sæt tilføjede adapterparametre, ofte under 1 % af det samlede antal, så den kan køre på en enkelt forbruger-GPU.
• QLoRA (Quantized Low-Rank Adaptation): Komprimerer basismodellen til 4-bit-præcision, før LoRA anvendes, så du kan finjustere en stor model på en enkelt GPU.

Oven i disse bruger vi metoder til instruktionstuning og præferencetuning, fra RLHF (Reinforcement Learning from Human Feedback) til lettere alternativer som Direct Preference Optimization (DPO) og Odds Ratio Preference Optimization (ORPO), til at forme, hvordan en model følger instruktioner og matcher menneskelige præferencer.

Sådan finjusterer du en LLM trin for trin

Når du har besluttet, at finjustering af en LLM er det rigtige valg, ser arbejdsprocessen sådan her ud.

Udvid

Trin 1: Definer opgaven, og hvordan du vil måle succes

Beslut, hvilken adfærd du ønsker fra LLM'en, og hvordan du kan se, at du har opnået den.

Angiv den konkrete opgave, som den finjusterede model skal løse, f.eks. at klassificere supporthenvendelser, opsummere kontrakter i et fast format eller generere kode i jeres egen stil.

Definer derefter, hvad succes er. Almindelige muligheder omfatter:

• Gyldigt output: Kan resultatet f.eks. parses som gyldig JSON, eller matcher det den Markdown-struktur, du har brug for?
• Automatiske scorer: Brug metrikker som BLEU eller ROUGE, der sammenligner genereret tekst med referencesvar, eller opgavenøjagtighed på et annoteret datasæt.
• Menneskelige vurderinger: Et vurderingsskema med point eller bestået/ikke bestået for egenskaber, som et script har svært ved at vurdere, f.eks. tone eller hjælpsomhed.
• Pålidelighed ved svære input: Håndterer den de usædvanlige input, som basismodellen snublede over?

Trin 2: Forbered dit datasæt

Datakvaliteten afgør, om finjusteringen lykkes, så gør en indsats for at indsamle det rigtige datasæt til finjusteringen.

Formatér dine data som instruktions-/svarpar i JSONL, hvor hver linje indeholder inputtet (plus eventuel kontekst) og præcis det output, du ønsker at få tilbage.

Se f.eks. på offentlige datasæt som det generelle instruktionsdatasæt Alpaca-cleaned eller Databricks' Dolly eller det opgavespecifikke banking77, som indeholder over 13.000 rigtige supporthenvendelser annoteret med 77 forskellige intentioner.

Til en fokuseret opgave kan nogle hundrede til nogle tusinde rene, varierede eksempler ændre adfærden. Det forudsætter, at eksemplerne afspejler rigtige produktionsinput, inklusive grænsetilfældene, og er konsekvent formateret.

Har du endnu ingen input/output-par? Byg sættet ud fra de data, du allerede har, f.eks. supporthenvendelser og de bedste svar på dem eller dokumenter og deres resuméer.

Hvis du kun har outputtene, så brug en stærkere model til at generere et plausibelt input til hvert af dem, eller skriv et lille startsæt i hånden og udvid det med en større „lærer“-model. Behold derefter de bedste par.

Afslut med at opdele dataene i trænings-, validerings- og testsæt, så du kan måle på eksempler, som modellen ikke har set.

Trin 3: Vælg en basismodel og en metode

Start med en lille open source-model med 3 til 7 milliarder parametre og en metode til parametereffektiv finjustering som LoRA eller QLoRA.

Åbne modelfamilier som Llama, Mistral og Qwen giver dig en stærk base, som du selv kan hoste, og PEFT-metoderne holder hardwarekravene nede: QLoRA kvantiserer basismodellen til 4-bit, så finjustering af en 7B-model kun kræver et forbrugergrafikkort med 16-24 GB. Fuld finjustering af samme model kræver mange gange så meget hukommelse.

Trin 4: Indstil dine træningshyperparametre

Her er de vigtigste parametre for LLM-finjustering og foreslåede startintervaller:

• Læringsraten styrer, hvor stor hver opdatering af vægtene er. Et studie fra 2024 af Biderman et al. viste, at de bedste rater for LoRA lå omkring ti gange højere end ved fuld finjustering, typisk 5e-5 til 5e-4 mod 1e-5 til 5e-5. Studiet anbefaler at afsøge værdier fra 1e-5 til 5e-4 og bruge den højeste værdi, der giver stabil træning.
• Batchstørrelse er det antal eksempler, modellen lærer af før hver vægtopdatering. På en enkelt GPU bør du bruge en lille batchstørrelse pr. enhed på 1 til 8 og gradientakkumulering for at nå en effektiv batchstørrelse på omkring 16 til 64.
• Antal epoker er, hvor mange gange modellen ser hele datasættet. Når du træner modellen til at udføre specifikke opgaver, er 1-3 en god tommelfingerregel, men LoRA-kørsler kræver ofte flere.
• LoRA-rang (r) bestemmer adapterens kapacitet, altså hvor meget den kan lære. Start med 8 til 32 til enklere opgaver, og hæv den ved sværere opgaver: I det LoRA-studie af Biderman et al., der er nævnt ovenfor, krævede instruktionstuning af en 7B-model på kode rang 256 for at matche fuld finjustering, mens rang 64 kom tæt på i matematik.
• Maksimal sekvenslængde er det længste input, kørslen behandler. Indstil den, så den dækker dine længste eksempler, op til modellens kontekstvindue, da alt, der er længere, bliver afkortet.
• Opvarmning og læringsrateplan styrer, hvordan læringsraten øges og ændrer sig i løbet af kørslen. En kort opvarmning og et cosinusforfald er de sædvanlige standardvalg. Studiet af små modeller fra Pareja et al. viste dog, at det ikke gik ud over de endelige resultater at droppe opvarmningen.

Se disse værdier som udgangspunkter for en parametersøgning, ikke som faste indstillinger.

Trin 5: Træn modellen, og overvåg tabet

Mens træningen kører, skal du holde øje med kurverne for trænings- og valideringstab for at se, om det virker.

Tabet måler, hvor langt modellens output ligger fra dine eksempler, og det bør falde jævnt, efterhånden som kørslen skrider frem. Træningstabet dækker de data, modellen lærer af. Valideringstabet måles på de tilbageholdte eksempler.

Hvis træningstabet og valideringstabet falder samtidig, lærer modellen at generalisere. Hvis træningstabet bliver ved med at falde, mens valideringstabet flader ud eller stiger, lærer modellen træningssættet udenad i stedet for at lære mønsteret (overtilpasning).

Udvid

Trin 6: Evaluer modellen, og udrul den derefter

Et lavt træningstab er ingen garanti for korrekte output, så vurder den finjusterede model ud fra de kriterier, du fastlagde i trin 1.

Når modellen består, har du to muligheder for at udrulle den:

• Kør adapteren oven på basismodellen, og indlæs begge ved kørselstid; på den måde kan adapteren fortsat udskiftes.
• Flet adapteren ind i basisvægtene for at få én selvstændig model, der er enklere at hoste.

Brug Perplexity til at give din LLM adgang til opdaterede oplysninger

Finjustering er det rigtige valg, når du vil tilpasse modellens adfærd til dine behov.

Hvis din model har brug for aktuelle oplysninger, især oplysninger, der ændrer sig hurtigt, har du brug for RAG eller et pålideligt søgeværktøj fra en tredjepart.

En skræddersyet retrieval-stak fungerer bedst til proprietære datasæt, såsom din interne wiki, din kundesupporthistorik, kontrakter eller produktdokumentation.

Når den viden, du vil bruge, er offentlig, er der ingen grund til at bygge et skræddersyet retrieval-lag. Perplexity er en svarmaskine, der returnerer svar med indlejrede, klikbare kildehenvisninger fra et live webindeks. Dens Agent API leverer disse webforankrede svar med kildehenvisninger i et enkelt kald, så din app kan trække på aktuelle kilder.

Ofte stillede spørgsmål om finjustering af LLM'er

Kan man finjustere en LLM gratis?

Ja, du kan finjustere en lille åben LLM gratis. Gratisversionen af Google Colab giver dig for eksempel nok GPU-kraft til at køre QLoRA på en 3B- til 8B-model, hvilket er rigeligt til en afgrænset opgave. Du begynder først at betale, når du har brug for mere hukommelse, længere kørsler eller en større basismodel, end gratisversionen kan håndtere.

Skal du have din egen GPU, eller kan du finjustere i skyen?

Du behøver ikke at eje en GPU for at finjustere LLM'er. Administrerede tjenester og GPU-cloududbydere udlejer hardwaren pr. time, så en enkelt lejet GPU er nok til en QLoRA-kørsel med en lille model. Det kan kun betale sig at købe en GPU, hvis du finjusterer ofte eller skal holde alle dine data på dine egne maskiner.

Hvor lang tid tager det at finjustere LLM'er?

For en lille LLM kan en kørsel tage fra få minutter til et par timer, afhængigt af datasættets størrelse og hardwaren. Oumi finjusterede for eksempel en 0,8B-model fuldt ud på lidt over en time på sin hostede platform.

Større modeller eller titusindvis af eksempler trækker det op mod en dag eller mere: Emburses LoRA-kørsler på en 7B-model tog 8 timer for 5.000 eksempler og omkring 30 timer for 50.000 på en enkelt GPU med 40 GB.

Kan du blive ved med at opdatere en finjusteret model, efterhånden som dine data ændrer sig?

Du kan finjustere igen på nye data, men hver runde koster regnekraft og indebærer risiko for katastrofal glemsel. Til viden, der ofte ændrer sig, er RAG som regel den bedre løsning, da du opdaterer kildedokumenterne i stedet for at genoptræne.