RAG vs finjustering: Når bør du bruke hva? (Med ekte tall)

RAG vs finjustering: Når bør du bruke hva? (Med ekte tall)

De fleste råd om rag vs finjustering hopper over det ene eksperimentet som målte begge på samme oppgave. Balaguer et al. i arXiv:2401.08406 (sitert 162 ganger) kjørte et landbruks-QA-sett gjennom begge: finjustering ga over 6 nøyaktighetspoeng, og RAG la ytterligere 5 på topp. Tabell 18 deres plasserer GPT-4 på 75 % rå, 81 % finjustert, 86 % finjustert med gjenfinning. Så hvorfor anbefaler vi fortsatt de fleste team å starte med RAG? Fordi ferskhet, kildehenvisninger og kostnadsregnestykket nedenfor avgjør flere prosjekter enn et nøyaktighetsgap på 1 poeng.

Nøkkelpoenger

• RAG er standardvalget når kunnskapen endrer seg ofte eller svarene må ha kildehenvisninger. Finjustering vinner på konsistent format og lav ventetid.
• Finjusteringskostnadene kommer først (trening). RAG-kostnadene kommer per spørring (embeddinger pluss ekstra input-tokens).
• Publiserte bevis fra samme oppgave: finjustering la til 6 nøyaktighetspoeng, RAG ytterligere 5 på topp, og hybriden slo begge alene.
• Kjør de fem sjekkene (dataferskhet, merkede eksempler, ventetid, kildehenvisninger, teamkompetanse) før du skriver treningskode.

Når bør du bruke RAG vs finjustering? (Rask dom)

Velg RAG hvis kunnskapen endrer seg ofte eller svarene må ha kildehenvisninger. Velg finjustering hvis du trenger konsistent outputformat og lav ventetid, og du har hundrevis av merkede eksempler. Bruk begge når en utrulling modnes. RAG redigerer konteksten modellen leser. Finjustering redigerer selve modellen. De fleste team trenger det første, ikke det andre.

Én setning å ta med seg: RAG endrer hva modellen leser. Finjustering endrer hva modellen er. Velg ut fra hvilken av delene oppgaven din faktisk trenger.

NVIDIAs RAG-ordliste definerer gjenfinningssiden ryddig hvis du vil ha lærebokversjonen. Definisjoner velger ikke arkitekturen din, derimot. Det gjør bevis, så start der.

Hva viser bevisene? Én oppgave, begge tilnærminger, målt

Den eneste målte sammenligningen på samme oppgave som rangerer i Googles topp fem for dette søket, er Balaguer et al. 2024, en Microsoft Research-studie sitert 162 ganger. Teamet kjørte én landbruks-QA-oppgave gjennom en RAG-pipeline, en finjustert modell og en hybrid av de to, og lot deretter GPT-4 score svarene. I deres oppsett slo finjustering alene så vidt RAG alene, og å stable de to slo hver av dem med enda bedre margin.

Landbrukskasusstudien (arXiv:2401.08406)

Studien, innsendt januar 2024 av Angels Balaguer og 15 medforfattere, spør hva som skal til for å gi bønder stedsspesifikk innsikt. Pipelinen deres trekker ut informasjon fra PDF-er, genererer spørsmål-svar-par fra dem og evaluerer Llama2-13B, GPT-3.5 og GPT-4 med og uten gjenfinning.

Balaguer et al. rapporterer en nøyaktighetsøkning på over 6 prosentpoeng fra finjustering, kumulativ med RAG, som la ytterligere 5 poeng på topp. Hybridpipelinen slo begge tilnærmingene alene. Tabell 18 deres viser rekkefølgen for GPT-4: 75 % uten hjelp, 80 % med RAG, 81 % finjustert, 86 % finjustert pluss RAG. Legg merke til hvor nært 80 % og 81 % ligger. Gapet mellom RAG alene og finjustering alene er ett poeng, mens hybriden er fem poeng foran begge. I ett eksperiment trakk den finjusterte modellen på kunnskap fra andre geografier for å svare på regionsspesifikke spørsmål, og løftet svarlikheten fra 47 % til 72 %.

Økonomibevisene

Snorkel AIs publiserte studie (november 2022) dekker kostnadssiden. På et 100-veis juridisk klassifiseringsbenchmark (LEDGAR, 80 000 kontraktsbestemmelser) matchet en finjustert RoBERTa-modell en finjustert GPT-3, mens den var 1 400× mindre, brukte under 1 % av fasit-etikettene og kjørte til 0,1 % av produksjonsinferenskostnaden til den finjusterte GPT-3-modellen, omtrent en tusendel. Total byggekostnad: 1 915 dollar med programmatisk etikettering mot 7 418 dollar for manuell annotering pluss GPT-3-finjustering. Étt forbehold: dette er klassifisering, ikke generativ QA, så behandle forholdstallene som retningsgivende.

Vår lesning

Vår tolkning: oppsettet deres er det vennligste tilfellet finjustering noen gang får, og den vant fortsatt bare med ett poeng. Balaguer et al. trente på et fast PDF-korpus og evaluerte mot det samme frosne korpuset, så ingenting av det vektene lærte, hadde noen sjanse til å bli foreldet midt i eksperimentet. De fleste kunnskapsbaser i produksjon står ikke så stille. En støttebot som svarer på spørsmål om forrige ukes lansering, tjener tilbake de 6 poengene hver omtreningssyklus, mens indeksen som mater RAG, oppdateres samme ettermiddag. Derfor leser vi en nøyaktighetsfordel på 1 poeng som det svakeste inputet til denne beslutningen, og ferskhet som det sterkeste. Der bevisene ikke generaliserer: Snorkels resultat er et klassifiseringsbenchmark, og ingen av studiene tester tone eller formatkontroll, som fortsatt er finjusterings sterkeste sak.

Finjustering er det riktige svaret sjeldnere enn team tror. De fleste prosjekter som sier «finjuster», mener egentlig «gjenfinn».

Hvordan fungerer RAG, og når vinner det?

RAG (retrieval-augmented generation) svarer fra dokumenter du kontrollerer, i stedet for det modellen tilfeldigvis husket fra treningen. Først foreslått av Lewis et al. i 2020, og ble standarden for kunnskapsarbeid fordi kunnskapen lever utenfor modellen: oppdater indeksen, og alle svar endres i morgen uten omtrening.

Pipelinen er fire steg:

1. Inntak. Pars dokumentene dine (PDF-er, wiki-er, saker) til et korpus.
2. Chunk og embed. Del opp i biter på noen hundre tokens og konverter hver til en vektor med en embeddingmodell.
3. Gjenfinn. På spørringstid, finn de topp-K mest like bitene, pluss nøkkelordtreff for nøyaktige strenger som SKU-er og feilkoder.
4. Utvid og generer. Stapp bitene inn i prompten og la LLM-en svare med kilder vedlagt.

RAG vinner på tre akser: ferskhet (reindekser i stedet for å omtrene), kildehenvisninger (hvert svar peker på biten det kom fra) og datakontroll (kundedata havner aldri i en treningskjøring). Hvis du vil ha hele gjennomgangen, her er hvordan du bygger en RAG-applikasjon steg for steg.

Én advarsel om gjenfinningskvalitet: pipelinen er bare så god som embedding- og gjenfinningsmiksen sin. Anthropics Contextual Retrieval målte en 5,7 % feilrate for topp-20-gjenfinning på enkle oppsett, som falt til 2,9 % med kontekstuelle embeddinger pluss BM25, og til 1,9 % når en reranker ble lagt til. Hvis spørringer som krever nøyaktige treff fortsetter å feile, er hybridsøk (BM25 vs vektor) løsningen.

Når vinner finjustering? (Og hva er PEFT?)

Finjustering vinner når problemet er hvordan modellen svarer, ikke hva den vet: konsistent outputformat, merkevaretone eller et hardt ventetidsbudsjett uten en gjenfinnings-rundtur. Det er også spaken for småmodelløkonomi. Snorkels GPT-3-kvalitet-til-0,1 %-av-kostnaden-resultat ovenfor finnes bare fordi noen finjusterte en liten modell i stedet for å servere en stor.

Full finjustering vs PEFT (LoRA / QLoRA)

Full finjustering oppdaterer hver vekt i modellen. Det er dyrt, tregt og sjeldent utenfor store laber. Nesten alle skipper PEFT (parameter-efficient fine-tuning) i stedet. LoRA (Hu et al. 2021) fryser basisvektene og trener en liten lav-rang-adapter, typisk 0,1–1 % av antall parametere. QLoRA legger 4-bit kvantisering på toppen, slik at en 13B-modell får plass på ett forbruker-GPU. Én beslektet term verdt å kjenne: kontinuerlig forhåndstrening, der en modell fortsetter forhåndstreningen på et rått domenekorpus (uovervåket) før overvåket finjustering på merkede eksempler.

En minimal LoRA-konfig, ifølge Hugging Face PEFT-dokumentasjonen:

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

For dataforberedelse, epokeantall og evaluering, se vår steg-for-steg finjusteringsguide.

Risikoen er reell: overtilpasning på små datasett (noen hundre eksempler kan memorere i stedet for å lære), foreldelse (vektene fryser kunnskapen din ved treningsterskelen) og ingen kildehenvisning (en finjustert modell kan ikke vise kvitteringene sine). Hvis noen av disse tre er en dealbreaker, har du nettopp argumentert deg tilbake til RAG.

RAG vs finjustering vs promptdesign: Hvor passer de andre?

De tre er en stige, ikke rivaler. Promptdesign endrer instruksjonene, RAG endrer konteksten modellen leser, og finjustering endrer vektene. OpenAIs egen finjusteringsguide plasserer finjustering sist i løkken: evalueringer først, prompter nummer to, trening bare når prompting slutter å være nok. To nyere alternativer runder av verktøykassen.

Én forvirring verdt å navngi: MCP-servere og agentrammeverk er orkestrering, ikke tilpasning. De bestemmer hvilke verktøy og kilder modellen kan nå. De endrer ikke hvordan modellen svarer. Du kan kjøre en RAG-pipeline inne i en agent og finjustere modellen under den, og mange produksjonssystemer gjør begge deler. Autokomplett-krigene («vs mcp», «vs agenter») er kategorifeil.

Er RAG billigere enn finjustering? Den ekte kostnadsmodellen

Kort svar: ved realistiske spørringsvolumer, ja. Finjusteringsregningen lander på forskudd (merkede data pluss trening), mens RAG-regningen ankommer per spørring (embeddinger pluss ekstra input-tokens). OpenAIs finjusteringsdokumentasjon tar betalt per token for trening, men tokenavgiftene er småpenger ved siden av den menneskelige kostnaden ved merkede eksempler. Her er regnestykket med offentlige listepriser.

Break-even-spørsmålet: hvor mange spørringer før RAGs kumulative skatt per spørring tilsvarer finjusteringsinvesteringen?

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

Med 50 000 spørringer i måneden er det mer enn ti år. For de fleste produkter betaler finjusteringsinvesteringen seg aldri tilbake gjennom tokenbesparelser alene. Du finjusterer for format og ventetid, ikke for å slå RAG på kostnad. Regnestykket snur forbi millioner av spørringer per måned eller med svært store gjenfunnede kontekster. Og merk asymmetrien: finjusteringsregningen fornyes hver gang datadrift tvinger en omtrening, mens RAG skalerer lineært med volum ganger bitstørrelse. Hvis kostnad per spørring er den virkelige bekymringen, start med å kutte LLM-kostnader per spørring først. Hvis du likevel går treningsveien, sammenlign finjusteringsverktøy før du skriver sjekken.

Én ferskhetsmerknad: per juli 2026 sier OpenAIs finjusteringsdokumentasjon at den hostede plattformen trappes ned for nye brukere, mens eksisterende brukere beholder treningstilgang i de kommende månedene. Det er én grunn til at team lener seg mot åpen-modell-PEFT eller ren RAG.

5 sjekker før du velger

Kjør disse fem ja-eller-nei-sjekkene før du skriver treningskode. Mønsteret i svarene peker mot RAG, finjustering eller hybrid mer pålitelig enn noe benchmark. Svar ærlig, og tell deretter.

1. Endrer kunnskapen seg raskere enn du kan omtrene? Ja → RAG. En omtrening per dokumentoppdatering er ikke en driftsplan.
2. Har du noen hundre merkede eksempler? Nei → RAG eller promptdesign. Finjustering på 40 eksempler memorerer. Den lærer ikke.
3. Finnes det et hardt ventetidsbudsjett? Stramt → finjustering heller. Å hoppe over gjenfinnings-rundturen sparer 50–200 ms.
4. Må svarene ha kildehenvisninger eller et revisjonsspor? Ja → RAG. Finjusterte modeller kan ikke peke på kildebiten.
5. Har teamet ML-kompetanse pluss GPU- eller API-budsjett til trening? Nei → RAG. En indeks du kan bygge på nytt, slår vekter du ikke kan omtrene.

Stort sett ja på 1, 4, 5 → RAG. Stort sett ja på 2 og 3 med et stabilt domene → finjustering. Delte svar, eller et modent produkt med reell trafikk → hybrid (neste seksjon). Poenget med sjekklisten er å bestemme med bevis, ikke med hvilken teknikk som trender i feeden din denne måneden.

Kan du bruke RAG og finjustering sammen?

Ja, og for modne utrullinger er hybrid-mønsteret normen, ikke unntaket. Finjuster for domeneflyt og outputformat (hvordan), gjenfinn for fakta på inferenstid (hva). Balaguer et al. rapporterer nøyaktig dette på landbruksoppgaven sin: hybridpipelinen slo begge tilnærmingene alene, med RAGs 5-poengs gevinst stablet på toppen av finjusteringens 6.

Modenhetsstien vi anbefaler: start med promptdesign, legg til RAG i det øyeblikket svarene trenger private eller ferske data, og legg til finjustering først når formatinkonsistens eller ventetid begynner å gjøre vondt i produksjon. Hopp rett til finjustering, og du betaler treningsskatten før du vet om gjenfinning allerede løste problemet.

Hybridmønsteret er ikke et kompromiss. For modne utrullinger er det standarden: finjuster for format, gjenfinn for fakta.

Hvordan evaluerer du vinneren din?

Velg vinneren slik du ville valgt en database: mål på arbeidsmengden din, ikke på magefølelse. Oppskriften får plass i ett avsnitt og dekker de fire tallene som faktisk avgjør.

• Separat spørsmålssett. 100–300 ekte brukerspørsmål. Ikke syntetiske, aldri noe sett under trening eller indeksering.
• Troskap og svarkorrekthet. Troskap spør om svaret er forankret i den gjenfunnede konteksten. Svarkorrekthet spør om det faktisk er riktig. Paret, popularisert av RAGAS, fanger både hallusinasjon og gjenfinningsbommer.
• Ventetid på p95, ikke gjennomsnittet. Gjenfinning legger til en rundtur. Mål halen.
• Kostnad per 1 000 spørringer, tokens pluss infrastruktur, målt i stedet for gjettet.
• Kjør på nytt ved drift. Nye dokumenter, nytt modelløyeblikksbilde, nytt kvartal: kjør settet på nytt.

Hele metrikknedbrytningen, inkludert verktøy, finner du i vår LLM-evalueringsguide.

Ofte stilte spørsmål

Kan du bruke RAG og finjustering sammen?

Ja. Finjuster for outputformat og domeneflyt, og behold gjenfinning for fakta på inferenstid. Balaguer et al. målte denne hybriden på en landbruks-QA-oppgave og fant at den slo begge tilnærmingene alene, med nøyaktighetsgevinstene stablet. De fleste modne produksjonssystemer ender her: vekter for hvordan, gjenfinning for hva.

Når bør du ikke bruke finjustering?

Hopp over finjustering når kunnskapen endrer seg raskere enn du kan omtrene, når du har færre enn noen hundre merkede eksempler, når svarene må ha kildehenvisninger eller revisjonsspor, eller når det ikke finnes budsjett til å omtrene når data driver. Disse fire forholdene beskriver de fleste tidligfaseprodukter, og det er grunnen til at RAG vanligvis er det riktige første trekket.

Er finjustering avkreftet?

Nei, men territoriet krympet. Lange kontekstvinduer og billig RAG absorberte brukstilfeller som krevde finjustering i 2023. Det som gjenstår, er reelt: strengt outputformat, merkevaretone, ventetidsbudsjetter uten en gjenfinnings-rundtur og småmodelløkonomi. Hvis problemet ditt er hvordan modellen svarer, snarere enn hva den vet, er finjustering fortsatt verktøyet.

Når ville du brukt RAG vs finjustering?

Bruk RAG når svarene avhenger av privat eller hyppig oppdatert kunnskap, eller når du trenger kildehenvisninger. Bruk finjustering når du trenger konsistent format, tone eller ventetid og du har nok merkede eksempler. Bruk begge når produktet modnes. Hvis du er usikker, start med RAG: det er billigere å angre enn en treningskjøring.

Er RAG billigere enn finjustering?

På forskudd, ja. RAGs kostnad er per spørring (embeddinger pluss ekstra input-tokens), mens finjustering tar betalt én gang for trening og merkede data, og deretter fornyes ved hver omtrening. Med offentlige listepriser lander break-even rundt 6,4 millioner spørringer i vårt utregnede eksempel, så ved typiske volumer forblir RAG billigere i produktets levetid.

Er RAG bedre enn finjustering for hallusinasjoner?

Vanligvis, men ikke gratis. RAG forankrer svar i gjenfunnede biter, slik at du kan henvise til kilder og revidere feil. Dårlig gjenfinning forgifter derimot svaret: Anthropic målte en 5,7 % feilrate for topp-20-gjenfinning på enkle oppsett, kuttet til 1,9 % med kontekstuell gjenfinning pluss reranking. Finjustering kan på sin side bake feil inn i vektene uten noen måte å spore dem på.

RAG vs finjustering vs promptdesign: hva er forskjellen?

Promptdesign endrer instruksjonene du sender. RAG endrer konteksten modellen leser på spørringstid. Finjustering endrer modellens vekter. Hver er et større inngrep enn den forrige: prøv prompter først, legg til gjenfinning når kunnskap er flaskehalsen, og tren bare når format, tone eller ventetid fortsatt gjør vondt.

Hvordan evaluerer du RAG vs finjustering-ytelse?

Bygg et separat sett med 100–300 ekte brukerspørsmål og score begge tilnærmingene på det: troskap (er det forankret?), svarkorrekthet (er det riktig?), p95-ventetid og kostnad per 1 000 spørringer. Kjør settet på nytt hver gang dokumentene eller modelløyeblikksbildet ditt endres. Syntetiske spørsmål smigrer begge systemene. Ekte spørsmål skiller dem.

Finjustering vs RAG for flerstegsspørsmål på ny kunnskap?

RAG, med bedre gjenfinning. Mekanismen avgjør dette: en finjustert modell kan bare resonnere over det vektene absorberte, så kunnskap den aldri så, er utilgjengelig uansett hvor godt den ble trent. Gjenfinning gir den de manglende brikkene på spørringstid. Haken er at én gjenfinningsrunde sjelden samler hvert steg, så planlegg for spørringsdekompisering eller iterativ gjenfinning pluss en reranker, ikke et enkelt topp-K-oppslag.

Konklusjon

Oppsummeringen, minus forbeholdene:

• RAG er standarden for skiftende kunnskap og siterte svar. Finjustering er spesialisten for format, tone og ventetid.
• Bevisene fra samme oppgave (Balaguer et al.) gir finjustering +6 p.p. og RAG ytterligere +5 p.p. på toppen, med hybriden best av de tre. Vårt start-med-RAG-råd hviler på ferskhet, kildehenvisninger og kostnad, ikke på den resultattavlen.
• Kostnadsregnestykket lander i RAGs favør ved realistiske volumer: break-even lå rundt 6,4 millioner spørringer i vårt utregnede eksempel.
• Bestem med de fem sjekkene, ikke med vane.

Valgt RAG? Se vår rangerte RAG-verktøyliste for stacken rundt pipelinen.