RAG vs finjustering: när du ska välja vad (med riktiga siffror)

RAG vs finjustering: när du ska välja vad (med riktiga siffror)

Det mesta som skrivs om rag vs finjustering hoppar över det enda experiment som faktiskt mätte båda på samma uppgift. Balaguer et al. körde i arXiv:2401.08406 (citerad 162 gånger) ett QA-dataset om jordbruk genom båda metoderna: finjustering gav över 6 procentenheters noggrannhet, och RAG lade ytterligare 5 på det. Deras tabell 18 sätter GPT-4 på 75 % rått, 81 % finjusterat, 86 % finjusterat med retrieval. Så varför rekommenderar vi ändå de flesta team att börja med RAG? Därför att aktualitet, källhänvisningar och kostnadsmatematiken nedan avgör fler projekt än vad en enda procents noggrannhetsskillnad gör.

Det viktigaste

• RAG är standardvalet när kunskapen ändras ofta eller när svaren måste ange källor; finjustering vinner på konsekvent format och latens.
• Finjusteringskostnaden kommer först (träning); RAG-kostnaden kommer per fråga (embeddingar plus extra input-tokens).
• Publicerad evidens från samma uppgift: finjustering lade till 6 procentenheter, RAG ytterligare 5 på det, och hybridlösningen slog båda enskilt.
• Kör de fem testerna (dataaktualitet, märkta exempel, latens, källhänvisningar, teamets kompetens) innan du skriver en enda rad träningskod.

När ska du använda RAG respektive finjustering? (Snabbdom)

Välj RAG om din kunskap ändras ofta eller om svaren måste bära källhänvisningar. Välj finjustering om du behöver konsekvent outputformat och låg latens, och om du har hundratals märkta exempel. Använd båda när en produktionssättning mognat. RAG redigerar kontexten modellen läser; finjustering redigerar själva modellen. De flesta team behöver det första, inte det andra.

En rad att ta med sig: RAG ändrar vad modellen läser; finjustering ändrar vad modellen är. Välj utifrån vad din uppgift faktiskt kräver.

NVIDIAs RAG-ordlista definierar retrieval-sidan snyggt om du vill ha läroboksversionen. Definitioner väljer dock inte din arkitektur. Det gör evidensen, så börja där.

Vad visar evidensen? En uppgift, båda metoderna, uppmätta

Den enda uppmätta jämförelsen på samma uppgift som rankar i Googles topp fem för denna sökning är Balaguer et al. 2024, en Microsoft Research-studie citerad 162 gånger. Teamet körde en QA-uppgift om jordbruk genom en RAG-pipeline, en finjusterad modell och en hybrid av de två, och lät sedan GPT-4 betygsätta svaren. I deras uppställning slog finjustering ensamt RAG ensamt med knapp marginal, och att stapla de två slog endera med bredare marginal.

Jordbruksfallstudien (arXiv:2401.08406)

Studien, inskickad i januari 2024 av Angels Balaguer och 15 medförfattare, undersöker vad som krävs för att ge jordbrukare platsspecifika insikter. Deras pipeline extraherar information från PDF:er, genererar fråge-svar-par från dem och utvärderar Llama2-13B, GPT-3.5 och GPT-4 med och utan retrieval.

Balaguer et al. rapporterar en noggrannhetsökning på över 6 procentenheter från finjustering, kumulativ med RAG, som lade till ytterligare 5 procentenheter på det. Hybridpipelinen slog endera metoden ensam. Deras tabell 18 visar ordningen för GPT-4: 75 % utan hjälp, 80 % med RAG, 81 % finjusterad, 86 % finjusterad plus RAG. Lägg märke till hur nära 80 % och 81 % ligger; gapet mellan RAG ensamt och finjustering ensamt är en procentenhet, medan hybriden ligger fem före båda. I ett experiment drog den finjusterade modellen kunskap från andra geografier för att svara på regionsspecifika frågor, och lyfte svarssimilariteten från 47 % till 72 %.

Kostnadsevidensen

Snorkel AI:s publicerade studie (november 2022) täcker kostnadssidan. På ett 100-vägs juridiskt klassificeringsbenchmark (LEDGAR, 80 000 avtalsklausuler) matchade en finjusterad RoBERTa-modell en finjusterad GPT-3, medan den var 1 400× mindre, använde under 1 % av facit-etiketterna och körde för 0,1 % av produktionsinferenskostnaden för den finjusterade GPT-3-modellen, ungefär en tusendel. Total byggkostnad: 1 915 $ med programmatisk märkning mot 7 418 $ för manuell annotering plus GPT-3-finjustering. En brasklapp: det är klassificering, inte generativ QA, så behandla kvoterna som riktningsskapande.

Vår läsning

Vår tolkning: deras uppställning är det vänligaste fall finjustering någonsin får, och den vann ändå bara med en procentenhet. Balaguer et al. tränade på ett fast PDF-korpus och utvärderade mot samma frusna korpus, så inget av det viktarna lärde sig hade en chans att bli inaktuellt mitt i experimentet. De flesta kunskapsbaser i produktion står inte stilla så. En supportbot som svarar på frågor om förra veckans release tjänar tillbaka de 6 procentenheterna i varje omträningscykel, medan indexet som matar RAG uppdateras samma eftermiddag. Det är därför vi läser en noggrannhetsfördel på 1 procentenhet som det svagaste inputvärdet i detta beslut, och aktualitet som det starkaste. Där evidensen inte generaliserar: Snorkels resultat är ett klassificeringsbenchmark, och ingen av studierna testar ton- eller formatkontroll, vilket förblir finjusteringens starkaste fall.

Finjustering är rätt svar mer sällan än team tror; de flesta projekt som säger "finjustera" menar i själva verket "hämta".

Hur fungerar RAG, och när vinner det?

RAG (retrieval-augmented generation) svarar från dokument du kontrollerar, i stället för vad modellen än memorerade under träningen. Först föreslagen av Lewis et al. 2020 blev den standardvalet för kunskapsarbete, eftersom kunskapen lever utanför modellen: uppdatera indexet så ändras alla svar i morgon utan omträning.

Pipelinen är fyra steg:

1. Inläsning. Parsa dina dokument (PDF:er, wikier, ärenden) till ett korpus.
2. Chunka och embedda. Dela upp i chunkar på några hundra tokens och omvandla varje chunk till en vektor med en embeddingmodell.
3. Hämta. Vid frågetillfället, hitta de topp-K mest liknande chunkarna, plus nyckelordsträffar för exakta strängar som SKU:er och felkoder.
4. Berika och generera. Stoppa in chunkarna i prompten och låt LLM:en svara med bifogade källor.

RAG vinner på tre axlar: aktualitet (indexera om i stället för att träna om), källhänvisningar (varje svar pekar på chunken det kom från) och datakontroll (kunddata hamnar aldrig i en träningskörning). Om du vill ha hela genomgången av bygget, så här bygger du en RAG-applikation steg för steg.

En varning för retrieval-kvaliteten: pipelinen är bara så bra som sin mix av embedding och retrieval. Anthropics Contextual Retrieval mätte en felkvote på 5,7 % i topp-20-hämtningen på enkla uppställningar, som sjönk till 2,9 % med kontextuella embeddingar plus BM25, och till 1,9 % när en reranker lades till. Om exakta matchningsfrågor fortsätter att misslyckas är hybrid sökning (BM25 vs vektor) lösningen.

När vinner finjustering? (Och vad är PEFT?)

Finjustering vinner när problemet är hur modellen svarar, inte vad den vet: konsekvent outputformat, varumärkestil eller en hård latensbudget utan en retrieval-tur-och-retur. Den är också hävstången för småmodellsekonomi. Snorkels resultat ovan, GPT-3-kvalitet för 0,1 % av kostnaden, existerar bara för att någon finjusterade en liten modell i stället för att servera en stor.

Full finjustering vs PEFT (LoRA / QLoRA)

Full finjustering uppdaterar varje vikt i modellen. Det är dyrt, långsamt och ovanligt utanför stora labb. Nästan alla skeppar PEFT (parameter-efficient fine-tuning) i stället. LoRA (Hu et al. 2021) fryser basvikterna och tränar en liten lågrangadapter, typiskt 0,1–1 % av parameterantalet. QLoRA lägger till 4-bitars kvantisering ovanpå, så att en 13B-modell får plats på ett konsument-GPU. En besläktad term värd att känna till: kontinuerlig förträning, där en modell fortsätter förträna på ett rått domänkorpus (osuperviserat) innan den övervakade finjusteringen på märkta exempel.

En minimal LoRA-konfiguration, enligt Hugging Face PEFT-dokumentationen:

from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=16,                          # low-rank dimension; 8-64 typical
    lora_alpha=32,                 # scaling factor, commonly 2x r
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: ~13M || all params: 6.7B || trainable%: 0.19

För datasetförberedelse, antal epoker och utvärdering, se vår steg-för-steg-guide om finjustering.

Riskerna är verkliga: överanpassning på små dataset (några hundra exempel kan memorera i stället för att lära), inaktualitet (viktarna fryser din kunskap vid träningsavgränsningen) och inga källattribueringar (en finjusterad modell kan inte visa sina kvitton). Om någon av de tre är en dealbreaker har du just pratat tillbaka dig själv till RAG.

RAG vs finjustering vs promptteknik: var passar de andra?

De tre är en stege, inte rivaler. Promptteknik ändrar instruktionerna, RAG ändrar kontexten modellen läser och finjustering ändrar viktarna. OpenAI:s egen finjusteringsguide placerar finjustering sist i loopen: utvärderingar först, prompter tvåa, träning först när promptande inte längre räcker. Två nyare alternativ kompletterar verktygslådan.

En förvirring värd att namnge: MCP-servrar och agentramverk är orkestrering, inte anpassning. De bestämmer vilka verktyg och källor modellen kan nå; de ändrar inte hur modellen svarar. Du kan köra en RAG-pipeline inuti en agent och finjustera modellen under den, och många produktionssystem gör båda. Autokompletteringskrigen ("vs mcp", "vs agenter") är kategorifel.

Är RAG billigare än finjustering? Den riktiga kostnadsmodellen

Kort svar: vid realistiska frågevolym, ja. Finjusteringens nota landar i förskott (märkt data plus träning), medan RAG:s nota anländer per fråga (embeddingar plus extra input-tokens). OpenAI:s finjusteringsdokumentation tar betalt per token för träning, men tokenavgifterna är småpengar bredvid den mänskliga kostnaden för märkta exempel. Här är matematiken på publika listpriser.

Break-even-frågan: hur många frågor krävs innan RAG:s kumulativa frågeskatt motsvarar finjusteringsinvesteringen?

break_even = training_cost / per_query_retrieval_delta
           = $1,915 / $0.0003
           ≈ 6.4 million queries

Med 50 000 frågor i månaden är det mer än tio år. För de flesta produkter betalar sig finjusteringsinvesteringen aldrig tillbaka enbart via tokenbesparingar; du finjusterar för format och latens, inte för att slå RAG på kostnad. Matematiken vänder vid miljoner frågor i månaden eller med mycket stora hämtade kontexter. Och notera asymmetrin: finjusteringsnotan förnyas varje gång datadrift tvingar fram en omträning, medan RAG skalar linjärt med volym gånger chunkstorlek. Om kostnaden per fråga är den riktiga oron, börja med att sänka LLM-kostnaden per fråga först; om du ändå går träningsvägen, jämför finjusteringsverktyg innan du skriver checken.

En aktualitetsnotering: per juli 2026 anger OpenAI:s finjusteringsdokumentation att den hostade plattformen avvecklas för nya användare, och att befintliga användare behåller träningsåtkomst under de kommande månaderna. Det är ytterligare en anledning till att team lutar åt PEFT på öppna modeller eller vanlig RAG.

Fem tester innan du väljer

Kör de fem ja-eller-nej-testerna innan du skriver någon träningskod; mönstret i svaren pekar mot RAG, finjustering eller hybrid mer tillförlitligt än något benchmark gör. Svara ärligt och räkna sedan.

1. Ändras kunskapen snabbare än du kan träna om? Ja → RAG. En omträning per dokumentuppdatering är ingen driftsplan.
2. Har du några hundra märkta exempel? Nej → RAG eller promptteknik. Finjustering på 40 exempel memorerar; det lär sig inte.
3. Finns det en hård latensbudget? Trång → finjustering lutar. Att hoppa över retrieval-tur-och-returen sparar 50–200 ms.
4. Måste svaren bära källhänvisningar eller en spårbar kedja? Ja → RAG. Finjusterade modeller kan inte peka på källchunken.
5. Har teamet ML-kompetens plus GPU- eller API-budget för träning? Nej → RAG. Ett index du kan bygga om slår vikter du inte kan träna om.

Mest ja på 1, 4, 5 → RAG. Mest ja på 2 och 3 med en stabil domän → finjustering. Delade svar, eller en mogen produkt med riktig trafik → hybrid (nästa avsnitt). Poängen med checklistan är att bestämma sig med evidens, inte med den teknik som trendar i ditt flöde den här månaden.

Kan du använda RAG och finjustering tillsammans?

Ja, och för mogna produktionssättningar är hybridmönstret normen, inte undantaget. Finjustera för domänflyt och outputformat (hur), hämta fakta vid inferenstillfället (vad). Balaguer et al. rapporterar exakt detta på sin jordbruksuppgift: hybridpipelinen slog endera metoden ensam, med RAG:s 5-procentenetersvinst staplad ovanpå finjusteringens 6.

Mognadsvägen vi rekommenderar: börja med promptteknik, lägg till RAG i samma ögonblick som svaren behöver privat eller färsk data, och lägg till finjustering först när formatinkonsistenser eller latens börjar göra ont i produktion. Hoppa rakt till finjustering så betalar du träningsskatten innan du vet om retrieval redan löste problemet.

Hybridmönstret är ingen kompromiss; för mogna produktionssättningar är det standardvalet, finjustera för format, hämta för fakta.

Hur utvärderar du din vinnare?

Välj vinnaren som du skulle välja en databas: mät på din arbetslast, inte på magkänsla. Receptet får plats i ett stycke och täcker de fyra tal som faktiskt avgör.

• Undanhållen frågemängd. 100–300 riktiga användarfrågor. Inte syntetiska, aldrig något som setts under träning eller indexering.
• Trohet och svarskorrekthet. Trohet (faithfulness) frågar om svaret är grundat i den hämtade kontexten; svarskorrekthet frågar om det faktiskt är rätt. Paret, populariserat av RAGAS, fångar både hallucinationer och retrieval-missar.
• Latens vid p95, inte medelvärdet. Retrieval lägger till en tur-och-retur; mät svansen.
• Kostnad per 1 000 frågor, tokens plus infrastruktur, uppmätt i stället för gissad.
• Kör om vid drift. Nya dokument, ny modellögonblicksbild, nytt kvartal: kör mängden igen.

Hela metrikkgenomgången, inklusive verktyg, finns i vår guide om LLM-utvärdering.

Vanliga frågor

Kan man använda RAG och finjustering tillsammans?

Ja. Finjustera för outputformat och domänflyt, och behåll retrieval för fakta vid inferenstillfället. Balaguer et al. mätte denna hybrid på en QA-uppgift om jordbruk och fann att den slog endera metoden ensam, med noggrannhetsvinsterna staplade. De flesta mogna produktionssystem hamnar här: vikterna för hur, retrieval för vad.

När ska man inte använda finjustering?

Hoppa över finjustering när din kunskap ändras snabbare än du kan träna om, när du har färre än några hundra märkta exempel, när svaren måste bära källhänvisningar eller spårbara kedjor, eller när det inte finns budget att träna om när datan driver. De fyra villkoren beskriver de flesta tidiga produkter, vilket är varför RAG oftast är rätt första drag.

Är finjustering motbevisat?

Nej, men dess revir har krympt. Långa kontextfönster och billig RAG absorberade användningsfall som krävde finjustering 2023. Det som återstår är verkligt: strikt outputformat, varumärkestil, latensbudgetar utan en retrieval-tur-och-retur och småmodellsekonomi. Om ditt problem är hur modellen svarar snarare än vad den vet är finjustering fortfarande verktyget.

När använder man RAG respektive finjustering?

Använd RAG när svaren beror på privat eller ofta uppdaterad kunskap, eller när du behöver källhänvisningar. Använd finjustering när du behöver konsekvent format, ton eller latens och du har tillräckligt med märkta exempel. Använd båda när produkten mognat. Om du är osäker, börja med RAG: det är billigare att ångra än en träningskörning.

Är RAG billigare än finjustering?

I förskott, ja. RAG:s kostnad är per fråga (embeddingar plus extra input-tokens), medan finjustering tar betalt en gång för träning och märkt data, sedan förnyas vid varje omträning. På publika listpriser landar break-even runt 6,4 miljoner frågor i vårt uträknade exempel, så vid typiska volymer förblir RAG billigare under produktens hela livstid.

Är RAG bättre än finjustering mot hallucinationer?

Oftast, men inte gratis. RAG grundar svar i hämtade chunkar, så att du kan ange källor och granska fel. Dålig retrieval förgiftar dock svaret: Anthropic mätte en felkvote på 5,7 % i topp-20-hämtningen på enkla uppställningar, sänkt till 1,9 % med kontextuell retrieval plus reranking. Finjustering kan under tiden baka in fel i viktarna utan något sätt att spåra dem.

RAG vs finjustering vs promptteknik: vad är skillnaden?

Promptteknik ändrar instruktionerna du skickar. RAG ändrar kontexten modellen läser vid frågetillfället. Finjustering ändrar modellens vikter. Varje steg är ett större ingrepp än det föregående: prova prompter först, lägg till retrieval när kunskapen är flaskhalsen och träna bara när format, ton eller latens fortfarande gör ont.

Hur utvärderar man prestanda för RAG vs finjustering?

Bygg en undanhållen mängd av 100–300 riktiga användarfrågor och betygsätt båda metoderna på den: trohet (är det grundat?), svarskorrekthet (är det rätt?), p95-latens och kostnad per 1 000 frågor. Kör om mängden när dina dokument eller din modellögonblicksbild ändras. Syntetiska frågor smickrar båda systemen; riktiga skiljer dem åt.

Finjustering vs RAG för flerstegsfrågor om ny kunskap?

RAG, med bättre retrieval. Mekanismen avgör den här: en finjusterad modell kan bara resonera över vad viktarna absorberat, så kunskap den aldrig sett är onåbar oavsett hur väl den tränats. Retrieval räcker den de saknade bitarna vid frågetillfället. Haken är att ett enda retrievalpass sällan samlar in varje steg, så planera för frågedekomposition eller iterativ retrieval plus en reranker, inte ett enda topp-K-uppslag.

Sammanfattning

Rekapituleringen, utan krusiduller:

• RAG är standardvalet för ändrad kunskap och källbelagda svar. Finjustering är specialisten för format, ton och latens.
• Evidensen från samma uppgift (Balaguer et al.) ger finjustering +6 p.p. och RAG ytterligare +5 p.p. på det, med hybriden bäst av de tre. Vårt råd att börja med RAG vilar på aktualitet, källhänvisningar och kostnad, inte på den resultattavlan.
• Kostnadsmatematiken landar i RAG:s favör vid realistiska volymer: break-even låg runt 6,4 miljoner frågor i vårt uträknade exempel.
• Bestäm dig med de fem testerna, inte med vana.

Valde RAG? Se vår rankade lista över RAG-verktyg för stacken runt pipelinen.