Så finjusterar du en LLM [och när du ska använda RAG eller promptning i stället]

Att finjustera en stor språkmodell (LLM) innebär att du vidaretränar en förtränad LLM på en liten, uppgiftsspecifik datamängd så att den ger utdata som du inte kan få enbart genom promptning.

Finjustering innebär att du samlar in exempel på in- och utdatapar som visar det beteende du vill ha, kör träningsomgångar som flyttar modellens vikter mot dem och jämför resultatet med den ursprungliga modellens utdata. Parametereffektiva metoder som LoRA gör detta så billigt att det kan köras på en enda GPU.

Om du inte är nöjd med språkmodellens utdata bör du först förbättra dina promptar och din hämtningsförstärkta generering (RAG). Finjustering ändrar hur språkmodellen beter sig. När du behöver att den använder färsk eller proprietär information är promptning och RAG oftast ett bättre val.

Här går vi steg för steg igenom hur du finjusterar en LLM, de viktigaste finjusteringsmetoderna (LoRA och QLoRA) samt de utmaningar och misstag som kan få processen att misslyckas.

Vad LLM-finjustering är och hur den skiljer sig från förträning av LLM:er

Förträning av en LLM bygger upp modellens allmänna språkförmåga från grunden på en enorm korpus, medan finjustering anpassar en förtränad modell på en liten datamängd för en enda uppgift.

Förträning av en LLM är den resurskrävande fas som ger en basmodell. Modellen lär sig från en bred textkorpus, vilket ger den allmän grammatik, faktakunskap och resonemangsförmåga men ingen specialisering för just din uppgift.

Vid LLM-finjustering fortsätter träningen av basmodellen på en liten, kurerad datamängd så att den ger önskade utdata för en specifik uppgift eller ett specifikt användningsfall. Det kan handla om ett konsekvent format, en varumärkesröst eller tonalitet, domänspecifika mönster eller tillförlitliga verktygs- och funktionsanrop.

När du bör finjustera LLM:er och när du hellre bör använda promptning eller RAG

För att förbättra en LLM:s prestanda arbetar du dig uppåt steg för steg: promptning -> RAG -> finjustering.

Förbättra dina promptar med mer detaljerade instruktioner och använd RAG för att ge modellen aktuell information. Använd finjustering först när förbättringar av promptar och hämtning inte räcker.

När bättre promptar slår finjustering och när de inte räcker

Promptning är det snabbaste och billigaste verktyget. I många fall räcker det med mer exakta och detaljerade promptar för att uppnå önskade beteendeförändringar.

Men längre promptar gör arbetet långsammare och dyrare, och de kan inte övervinna modellens befintliga begränsningar.

Tecken på att promptning kan ha nått sina gränser:

• Nya kantfall förstör hela tiden utdata: Modellen returnerar till exempel löptext när du behöver JSON eller tappar rätt ton, och du lappar prompten för varje nytt fall.
• Systemprompten fortsätter att växa: Prompten omfattar hundratals eller tusentals rader och är svår att hantera.
• Du betalar för den vid varje anrop: Prompten skickas och bearbetas på nytt vid varje förfrågan, så tokenkostnaden och latensen ökar.
• Ändringar gör inte längre någon skillnad: Nya instruktioner förbättrar inte utdata.

Även då bör du först prova de billigare lösningarna på promptnivå. Använd few-shot-exempel för att visa modellen mönstret (in- och utdatapar), promptkedjning för att dela upp svåra uppgifter i mindre steg eller funktionsanrop för att lägga ut exakta uppslag eller beräkningar.

När RAG är ett bättre val än att finjustera modellen

RAG ändrar vad språkmodellen vet, medan finjustering ändrar hur den beter sig. Om bristen gäller kunskap, särskilt kunskap som ändras ofta eller finns i dina egna dokument, är RAG svaret. Om bristen gäller beteendet bör du finjustera.

Finjustering påverkar också vad en modell vet, men alla fakta som den tar till sig fryses vid träningstillfället och blir snabbt inaktuella inom områden som utvecklas snabbt. Dessutom bakas informationen in i modellens vikter, så det finns inga uppgifter om var den kommer ifrån.

Att uppdatera källdokumenten som ett hämtningslager använder går snabbare och är billigare, och lagret kan hänvisa till exakt de källor det har använt. Det gör RAG till ett bättre val när du behöver försvarbar och aktuell information.

Nackdelen med RAG? Det är ytterligare ett lager att bygga och underhålla, och det ökar latensen.

I praktiken behöver du ofta båda. Produktionssystem kombinerar finjusterade modeller med RAG och använder det ena för konsekvent beteende och det andra för aktuella fakta.

Vanliga fallgropar, risker och utmaningar med finjustering

Även när finjustering är rätt verktyg medför det kostnader och risker:

• Kostnad och tid: Det är dyrt både att sammanställa ren, representativ träningsdata och att stå för beräkningskraften till träningen.
• Katastrofal glömska: När en modell tränas på en snäv datamängd kan den förlora allmänna färdigheter och utveckla nya felbeteenden, vilket leder till fel som basmodellen inte gjorde.
• Överanpassning: Med för lite eller för repetitiv data memorerar modellen dina träningsexempel i stället för att lära sig mönster, så den presterar bra på sina träningsexempel men dåligt på verkliga indata.
• Inaktuell kunskap: Kunskap som bakats in i vikterna blir snabbt föråldrad, så du måste träna om modellen på nya data.
• Föråldring: När en starkare modell lanseras slår den ofta din finjusterade modell redan utan anpassning, och du måste göra om arbetet.
• Utmaningar med utvärdering och reproducerbarhet: Det är svårt att bevisa att den finjusterade modellen presterar bättre än basmodellen. Två träningskörningar på GPU med samma inställningar kan dessutom ge något olika modeller.
• Datastyrning: Träning på proprietära eller känsliga data väcker frågor om integritet och licensiering; en modell kan senare återge fragment av det som den har tränats på.

De viktigaste finjusteringsmetoderna

De viktigaste typerna av LLM-finjustering skiljer sig åt i hur stor del av modellen de ändrar: fullständig finjustering tränar om hela modellen, medan metoder för parametereffektiv finjustering (PEFT) som LoRA och QLoRA bara uppdaterar en del av vikterna. PEFT-metoder kräver bara en bråkdel av det minne som fullständig finjustering kräver och kan med rätt inställningar ge lika goda resultat.

Fullständig finjustering uppdaterar alla modellens vikter. Det är den dyraste metoden och medför störst risk för katastrofal glömska. Reservera den för stora beteendeförändringar när du har tillräckligt med data och beräkningskraft.

Alternativet är parametereffektiv finjustering, eller PEFT. Det är ett samlingsbegrepp för metoder som fryser större delen av modellen och bara tränar en liten uppsättning parametrar. Det kräver mycket mindre minne och medför mindre risk för glömska, eftersom basmodellen förblir intakt.

Vid låg rang lär sig PEFT mindre än en fullständig finjustering, men om du höjer rangen och justerar inlärningshastigheten försvinner större delen av skillnaden för uppgifter med instruktionsträning.

PEFT-metoderna omfattar:

• LoRA (Low-Rank Adaptation): Den vanliga utgångspunkten. Metoden fryser de ursprungliga vikterna och tränar en liten uppsättning tillagda adapterparametrar, ofta under 1 % av totalen, så att den kan köras på en enda konsument-GPU.
• QLoRA (Quantized Low-Rank Adaptation): Metoden komprimerar basmodellen till 4-bitarsprecision innan LoRA tillämpas, vilket gör att du kan finjustera en stor modell på en enda GPU.

Utöver dessa använder vi metoder för instruktions- och preferensträning, från RLHF (Reinforcement Learning from Human Feedback) till lättare alternativ som Direct Preference Optimization (DPO) och Odds Ratio Preference Optimization (ORPO), för att forma hur en modell följer instruktioner och anpassar sig efter mänskliga preferenser.

Så finjusterar du en LLM steg för steg

När du har bestämt att finjustering av en LLM är rätt väg att gå ser arbetsflödet ut så här.

Förstora

Steg 1: Definiera uppgiften och hur du ska mäta framgång

Bestäm vilket beteende du vill ha från språkmodellen och hur du ska veta att du har uppnått det.

Ange den specifika uppgift som du vill att den finjusterade modellen ska utföra, till exempel att klassificera supportärenden, sammanfatta avtal i ett fast format eller generera kod enligt er egen kodstil.

Definiera sedan vad framgång innebär. Vanliga alternativ är:

• Giltiga utdata: Kan resultatet till exempel tolkas som giltig JSON, eller följer det den Markdown-struktur som du behöver?
• Automatiserade poäng: Använd mått som BLEU eller ROUGE som jämför genererad text med referenssvar, eller uppgiftsnoggrannhet på en märkt datamängd.
• Mänskliga bedömningar: En bedömningsmall med poäng eller godkänt/underkänt för egenskaper som ett skript har svårt att bedöma, till exempel tonalitet eller hjälpsamhet.
• Tillförlitlighet vid svåra indata: Hanterar modellen de ovanliga indata som fick basmodellen att snubbla?

Steg 2: Förbered din datamängd

Datakvaliteten avgör om finjusteringen lyckas, så lägg kraft på att samla in rätt datamängd för finjusteringen.

Formatera dina data som instruktions- och svarspar i JSONL, där varje rad innehåller indata (plus eventuell kontext) och exakt de utdata som du vill få tillbaka.

Titta till exempel på offentliga datamängder som den allmänna instruktionsdatamängden Alpaca-cleaned eller Databricks Dolly, eller den uppgiftsspecifika banking77, som innehåller över 13 000 verkliga supportförfrågningar märkta med 77 olika avsikter.

För en avgränsad uppgift kan några hundra till några tusen rena, varierade exempel räcka för att ändra beteendet, så länge exemplen speglar verkliga indata från produktion, inklusive kantfallen, och är konsekvent formaterade.

Har du inga in- och utdatapar ännu? Bygg upp datamängden från de data som du redan har, till exempel supportärenden och de bästa svaren på dem, eller dokument och deras sammanfattningar.

Om du bara har utdata kan du använda en starkare modell för att generera rimliga indata för vart och ett, eller skriva en liten startuppsättning för hand och utöka den med en större ”lärarmodell”, och sedan behålla de bästa paren.

Avsluta med att dela upp data i tränings-, validerings- och testmängder, så att du kan mäta på exempel som modellen inte har sett.

Steg 3: Välj basmodell och metod

Börja med en liten modell med öppen källkod på 3 till 7 miljarder parametrar och en metod för parametereffektiv finjustering som LoRA eller QLoRA.

Öppna modellfamiljer som Llama, Mistral och Qwen ger dig en stark bas som du kan drifta själv, och PEFT-metoderna håller hårdvarukraven låga: QLoRA kvantiserar basmodellen till 4 bitar, så för att finjustera en 7B-modell behöver du bara ett konsumentgrafikkort med 16–24 GB. Fullständig finjustering av samma modell kräver många gånger så mycket minne.

Steg 4: Ställ in dina hyperparametrar för träningen

Här är de viktigaste parametrarna för LLM-finjustering och föreslagna startintervall:

• Inlärningshastigheten styr hur stor varje uppdatering av vikterna är. En studie från 2024 av Biderman m.fl. visade att de bästa inlärningshastigheterna för LoRA låg ungefär tio gånger högre än för fullständig finjustering, vanligtvis 5e-5 till 5e-4 jämfört med 1e-5 till 5e-5. Studien rekommenderar att du testar värden från 1e-5 till 5e-4 och använder det högsta värde som ger stabil träning.
• Batchstorlek är hur många exempel modellen lär sig av före varje viktuppdatering. På en enda GPU använder du en liten batch på 1 till 8 per enhet och gradientackumulering för att nå en effektiv batch på ungefär 16 till 64.
• Antal epoker är hur många gånger modellen ser hela datamängden. När du tränar modellen att utföra specifika uppgifter är 1–3 en bra tumregel, men LoRA-körningar behöver ofta fler.
• LoRA-rang (r) anger adapterns kapacitet, alltså hur mycket den kan lära sig. Börja på 8 till 32 för enklare uppgifter och höj den för svårare: I LoRA-studien av Biderman et al. som nämndes ovan krävdes rang 256 för att instruktionsfinjustering av en 7B-modell på kod skulle matcha full finjustering, medan rang 64 kom nära för matematik.
• Maximal sekvenslängd är den längsta indatasekvens som körningen bearbetar. Ställ in den så att den täcker dina längsta exempel, upp till modellens kontextfönster, eftersom allt som är längre trunkeras.
• Uppvärmning och schema styr hur inlärningshastigheten trappas upp och förändras under körningen. En kort uppvärmning och en cosinusavklingning är de vanliga standardvalen. Men studien av Pareja et al. om små modeller visade att slutresultaten inte försämrades när uppvärmningen hoppades över.

Se dessa som utgångspunkter för en hyperparametersökning, inte som fasta inställningar.

Steg 5: Träna och övervaka förlusten

Medan träningen pågår bör du följa förlustkurvorna för träning och validering för att se om den fungerar.

Förlusten mäter hur långt modellens utdata ligger från dina exempel, och den bör sjunka jämnt allteftersom körningen fortskrider. Träningsförlusten gäller de data som modellen lär sig av. Valideringsförlusten mäts på de exempel som hållits utanför träningen.

Om träningsförlusten och valideringsförlusten sjunker tillsammans lär sig modellen att generalisera. Om träningsförlusten fortsätter att sjunka men valideringsförlusten planar ut eller stiger, memorerar modellen träningsmängden i stället för att lära sig mönstret (överanpassning).

Förstora

Steg 6: Utvärdera och driftsätt sedan

En låg träningsförlust garanterar inte korrekta utdata, så bedöm den finjusterade modellen utifrån de kriterier du satte upp i steg 1.

När modellen klarar utvärderingen har du två sätt att driftsätta den:

• Kör adaptern ovanpå basmodellen och läs in båda vid körtid; på så sätt förblir adaptern utbytbar.
• Slå samman adaptern med basvikterna för att få en enda fristående modell som är enklare att drifta.

Använd Perplexity för att ge din LLM tillgång till aktuell information

Finjustering är rätt val när du vill anpassa modellens beteende efter dina behov.

Om din modell behöver aktuell information, särskilt information som ändras snabbt, behöver du en RAG-lösning eller ett pålitligt sökverktyg från tredje part.

En anpassad hämtningsstack fungerar bäst för proprietära datamängder, till exempel din interna wiki, kundsupporthistorik, avtal eller produktdokumentation.

När kunskapen du vill använda är offentlig behöver du inte bygga ett skräddarsytt hämtningslager. Perplexity är en svarsmotor som returnerar svar med klickbara källhänvisningar direkt i texten från ett ständigt uppdaterat webbindex. Dess Agent API levererar dessa webbförankrade svar med källhänvisningar i ett enda anrop, så att din app kan hämta information från aktuella källor.

Vanliga frågor om finjustering av LLM:er

Kan man finjustera en LLM gratis?

Ja, du kan finjustera en liten öppen LLM gratis. Gratisnivån i Google Colab ger till exempel tillräckligt med GPU-kapacitet för att köra QLoRA på en modell med 3B till 8B parametrar, vilket räcker gott för en avgränsad uppgift. Du börjar betala när du behöver mer minne, längre körningar eller en större basmodell än vad gratisnivån klarar av.

Behöver du en egen GPU, eller kan du finjustera i molnet?

Du behöver inte äga en GPU för att finjustera LLM:er. Hanterade tjänster och GPU-molnleverantörer hyr ut hårdvaran per timme, så en enda hyrd GPU räcker för en QLoRA-körning med en liten modell. Att köpa en GPU lönar sig bara om du finjusterar ofta eller måste ha alla dina data på dina egna maskiner.

Hur lång tid tar det att finjustera LLM:er?

För en liten LLM kan en körning ta allt från några minuter till några timmar, beroende på datamängdens storlek och hårdvaran. Oumi genomförde till exempel en full finjustering av en modell med 0,8B parametrar på drygt en timme på sin molnbaserade plattform.

Större modeller eller tiotusentals exempel drar ut på det till ett dygn eller mer: Emburses LoRA-körningar på en 7B-modell tog 8 timmar för 5 000 exempel och cirka 30 timmar för 50 000 på en enda GPU med 40 GB.

Kan du fortsätta att uppdatera en finjusterad modell när dina data förändras?

Du kan finjustera om på nya data, men varje omgång kostar beräkningskraft och medför risk för katastrofal glömska. För kunskap som ändras ofta är RAG oftast en bättre lösning, eftersom du uppdaterar källdokumenten i stället för att träna om modellen.