RAG vs finjustering: Hvornår skal du vælge hvad (med rigtige tal)

RAG vs finjustering: Hvornår skal du vælge hvad (med rigtige tal)

Det meste af det, der skrives om rag vs finjustering, springer over det ene eksperiment, der faktisk målte begge dele på samme opgave. Balaguer et al. kørte i arXiv:2401.08406 (citeret 162 gange) et QA-datasæt om landbrug gennem begge metoder: finjustering købte over 6 procentpoints nøjagtighed, og RAG lagde yderligere 5 ovenpå. Deres tabel 18 sætter GPT-4 til 75 % rå, 81 % finjusteret, 86 % finjusteret med retrieval. Så hvorfor anbefaler vi stadig de fleste teams at starte med RAG? Fordi aktualitet, kildehenvisninger og omkostningsregnskabet nedenfor afgør flere projekter, end en enkelt procents nøjagtighedsforskel gør.

Vigtigste pointer

• RAG er standardvalget, når viden ændrer sig ofte, eller svarene skal citere kilder; finjustering vinder på konsekvent format og latenstid.
• Finjusteringsomkostningerne lander forrest (træning); RAG-omkostningerne lander pr. forespørgsel (embeddinger plus ekstra input-tokens).
• Publiceret evidens fra samme opgave: finjustering lagde 6 procentpoint til, RAG yderligere 5 ovenpå, og hybridløsningen slog begge dele alene.
• Kør de fem checks (dataaktualitet, mærkede eksempler, latenstid, kildehenvisninger, teamets kompetencer), før du skriver nogen som helst træningskode.

Hvornår skal du bruge RAG vs finjustering? (Hurtig dom)

Vælg RAG, hvis din viden ændrer sig ofte, eller dine svar skal bære kildehenvisninger. Vælg finjustering, hvis du har brug for konsekvent outputformat og lav latenstid, og du har mærkede eksempler i hundredvis. Brug begge dele, når en produktionssætning er modnet. RAG redigerer den kontekst, modellen læser; finjustering redigerer selve modellen. De fleste teams har brug for det første, ikke det andet.

Én linje at beholde: RAG ændrer, hvad modellen læser; finjustering ændrer, hvad modellen er. Vælg ud fra, hvilken af delene din opgave faktisk kræver.

NVIDIAs RAG-ordliste definerer retrieval-siden pænt, hvis du vil have lærebogsversionen. Definitioner vælger dog ikke din arkitektur. Det gør evidens, så start dér.

Hvad viser evidensen? Én opgave, begge metoder, målt

Den eneste målte sammenligning på samme opgave, der ligger i Googles top fem på denne søgning, er Balaguer et al. 2024, en Microsoft Research-undersøgelse citeret 162 gange. Teamet kørte én landbrugs-QA-opgave gennem en RAG-pipeline, en finjusteret model og en hybrid af de to og lod derefter GPT-4 bedømme svarene. I deres opstilling slog finjustering alene RAG alene med en hårfin margen, og kombinationen af de to slog begge dele med endnu større afstand.

Landbrugscasestudiet (arXiv:2401.08406)

Undersøgelsen, indsendt i januar 2024 af Angels Balaguer og 15 medforfattere, spørger, hvad der skal til for at give landmænd stedsspecifik indsigter. Deres pipeline udtrækker information fra PDF'er, genererer spørgsmål-svar-par fra dem og evaluerer Llama2-13B, GPT-3.5 og GPT-4 med og uden retrieval.

Balaguer et al. rapporterer en nøjagtighedsstigning på over 6 procentpoint fra finjustering, kumulativ med RAG, som lagde yderligere 5 point ovenpå. Hybridpipelinen slog begge metoder alene. Deres tabel 18 viser rækkefølgen for GPT-4: 75 % uden hjælp, 80 % med RAG, 81 % finjusteret, 86 % finjusteret plus RAG. Bemærk, hvor tæt 80 % og 81 % ligger; afstanden mellem RAG alene og finjustering alene er ét point, mens hybridløsningen er fem point foran begge dele. I ét eksperiment trak den finjusterede model på viden fra andre geografiområder for at besvare regionsspecifikke spørgsmål og løftede svarlighed fra 47 % til 72 %.

Den økonomiske evidens

Snorkel AIs publicerede undersøgelse (november 2022) dækker omkostningssiden. På et juridisk klassificeringsbenchmark med 100 klasser (LEDGAR, 80.000 kontraktbestemmelser) matchede en finjusteret RoBERTa-model en finjusteret GPT-3, mens den var 1.400× mindre, brugte under 1 % af de sandhedslabels og kørte til 0,1 % af produktionsinferensomkostningerne for den finjusterede GPT-3-model, cirka en tusindedel. Samlet opbygning: $1.915 med programmatisk labeling mod $7.418 for manuel annotation plus GPT-3-finjustering. Én forbehold: det er klassificering, ikke generativ QA, så behandl forholdstallene som retningsgivende.

Vores læsning

Vores tolkning: deres opstilling er det venligste tilfælde, finjustering nogensinde får, og den vandt stadig kun med ét point. Balaguer et al. trænede på et fast PDF-korpus og evaluerede mod det samme frosne korpus, så intet af det, vægtene lærte, havde en chance for at blive forældet midt i eksperimentet. De fleste produktionsvidensbaser står ikke stille på den måde. En supportbot, der besvarer spørgsmål om sidste uges release, genvinder de 6 point hver genoptræningscyklus, mens indekset, der føder RAG, opdateres samme eftermiddag. Derfor læser vi en 1-points nøjagtighedsfordel som det svageste input til denne beslutning og aktualitet som det stærkeste. dér evidensen ikke generaliserer: Snorkels resultat er et klassificeringsbenchmark, og ingen af undersøgelserne tester tone eller formatkontrol, hvilket stadig er finjusterings stærkeste sag.

Finjustering er det rigtige svar sjældnere, end teams tror; de fleste projekter, der siger "finjuster", mener faktisk "hent".

Hvordan virker RAG, og hvornår vinder den?

RAG (retrieval-augmented generation) svarer fra dokumenter, du kontrollerer, i stedet for hvad modellen nu har memoriseret under træningen. Først foreslået af Lewis et al. i 2020 blev den standarden for vidensarbejde, fordi viden lever uden for modellen: opdater indekset, og alle svar ændrer sig i morgen uden genoptræning.

Pipelinen er fire trin:

1. Indtag. Pars dine dokumenter (PDF'er, wikier, tickets) til et korpus.
2. Opdel og embed. Opdel i chunks på nogle få hundrede tokens, og konverter hver til en vektor med en embeddingmodel.
3. Hent. Find ved forespørgselstidspunktet de top-K mest lignende chunks plus nøgleordsmatch for eksakte strenge som SKU'er og fejlkoder.
4. Berig og generér. Stop de chunks i prompten, og lad LLM'en svare med kilder vedhæftet.

RAG vinder på tre akser: aktualitet (genindeksering i stedet for genoptræning), kildehenvisninger (alle svar peger på den chunk, det kom fra) og datakontrol (kundedata kommer aldrig ind i en træningskørsel). Hvis du vil have den fulde gennemgang af opbygningen, er her sådan, du bygger en RAG-applikation trin for trin.

Én advarsel om retrieval-kvalitet: pipelinen er kun så god som sin blanding af embedding og retrieval. Anthropics Contextual Retrieval målte en fejlrate på 5,7 % i top-20-hentningen på simple opstillinger, faldende til 2,9 % med kontekstuelle embeddinger plus BM25 og til 1,9 %, når en reranker blev tilføjet. Hvis eksakte match-forespørgsler bliver ved med at fejle, er hybridsøgning (BM25 vs vektor) løsningen.

Hvornår vinder finjustering? (Og hvad er PEFT?)

Finjustering vinder, når problemet er, hvordan modellen svarer, ikke hvad den ved: konsekvent outputformat, brandtone eller et hårdt latensbudget uden en retrieval-rundtur. Den er også vægtstangen for små-model-økonomi. Snorkels resultat om GPT-3-kvalitet til 0,1 % af omkostningerne ovenfor eksisterer kun, fordi nogen finjusterede en lille model i stedet for at servere en stor.

Fuld finjustering vs PEFT (LoRA / QLoRA)

Fuld finjustering opdaterer alle vægte i modellen. Det er dyrt, langsomt og sjældent uden for store laboratorier. Næsten alle udruller PEFT (parameter-efficient fine-tuning) i stedet. LoRA (Hu et al. 2021) fryser basisvægtene og træner en lille low-rank-adapter, typisk 0,1-1 % af parametertallet. QLoRA tilføjer 4-bit kvantisering ovenpå, så en 13B-model kan være på ét forbruger-GPU. Ét beslægtet begreb, der er værd at kende: kontinuert pretraining, hvor en model fortsætter med at pretræne på et råt domænekorpus (ikke-overvåget) før overvåget finjustering på mærkede eksempler.

En minimal LoRA-konfiguration ifølge 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

Til datasetforberedelse, epoch-tal og evaluering, se vores trin-for-trin finjusteringsguide.

Risiciene er reelle: overfitting på små datasæt (nogle få hundrede eksempler kan memorisere i stedet for at lære), forældelse (vægte fryser din viden ved træningstidspunktet) og ingen kildetilknytning (en finjusteret model kan ikke vise sine kvitteringer). Hvis nogen af de tre er en dealbreaker, har du netop argumenteret dig selv tilbage til RAG.

RAG vs finjustering vs promptteknik: Hvor passer de andre ind?

De tre er en stige, ikke rivaler. Promptteknik ændrer instruktionerne, RAG ændrer den kontekst, modellen læser, og finjustering ændrer vægtene. OpenAIs egen finjusteringsguide placerer finjustering sidst i løkken: evals først, prompts derefter, træning kun når prompting ikke længere er nok. To nyere muligheder runder værktøjskassen af.

Én forvirring, der er værd at navngive: MCP-servere og agentframeworks er orkestrering, ikke tilpasning. De bestemmer, hvilke værktøjer og kilder modellen kan nå; de ændrer ikke, hvordan modellen svarer. Du kan køre en RAG-pipeline inde i en agent og finjustere modellen nedenunder den, og mange produktionssystemer gør begge dele. Autocomplete-krigene ("vs mcp", "vs agenter") er kategorifejl.

Er RAG billigere end finjustering? Den rigtige omkostningsmodel

Kort svar: ved realistiske forespørgselsvolumener, ja. Finjusteringens regning lander upfront (mærkede data plus træning), mens RAG's regning ankommer pr. forespørgsel (embeddinger plus ekstra input-tokens). OpenAIs finjusteringsdokumentation opkræver træning pr. token, men tokengebyrer er småpenge ved siden af de menneskelige omkostninger ved mærkede eksempler. Her er regnskabet på offentlige listepriser.

Break-even-spørgsmålet: hvor mange forespørgsler, før RAG's kumulative forespørgselsskat svarer til finjusteringsinvesteringen?

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

Med 50.000 forespørgsler om måneden er det mere end ti år. For de fleste produkter betaler finjusteringsinvesteringen sig aldrig tilbage via tokenbesparelser alene; du finjusterer for format og latenstid, ikke for at slå RAG på omkostninger. Regnskabet vender ved millioner af forespørgsler pr. måned eller med meget store hentede kontekster. Og bemærk asymmetrien: finjusteringsregningen fornyes, hver gang datadrift tvinger en genoptræning igennem, mens RAG skalerer lineært med volumen gange chunkstørrelse. Hvis omkostningen pr. forespørgsel er den reelle bekymring, så start med at skære omkostningerne pr. forespørgsel til LLM'er først; hvis du alligevel går træningsvejen, så sammenlign finjusteringsværktøjer, før du skriver checken.

Én aktualitetsnote: pr. juli 2026 angiver OpenAIs finjusteringsdokumentation, at den hostede platform afvikles for nye brugere, og at eksisterende brugere beholder træningsadgang i de kommende måneder. Det er endnu en grund til, at teams hælder mod PEFT på åbne modeller eller almindelig RAG.

5 checks, før du vælger

Kør disse fem ja-eller-nej-checks, før du skriver nogen træningskode; mønsteret i svarene peger mere pålideligt mod RAG, finjustering eller hybrid end noget benchmark gør. Svar ærligt, og tæl derefter.

1. Ændrer viden sig hurtigere, end du kan genoptræne? Ja → RAG. En genoptræning pr. dokumentopdatering er ikke en driftsplan.
2. Har du nogle få hundrede mærkede eksempler? Nej → RAG eller promptteknik. Finjustering på 40 eksempler memoriserer; det lærer ikke.
3. Er der et hårdt latensbudget? Stramt → hælder mod finjustering. At springe retrieval-rundturen over sparer 50-200 ms.
4. Skal svarene bære kildehenvisninger eller et revisionsspor? Ja → RAG. Finjusterede modeller kan ikke pege på kilde-chunken.
5. Har teamet ML-kompetence plus GPU- eller API-budget til træning? Nej → RAG. Et indeks, du kan genopbygge, slår vægte, du ikke kan genoptræne.

Overvejende ja på 1, 4, 5 → RAG. Overvejende ja på 2 og 3 med et stabilt domæne → finjustering. Delte svar eller et modent produkt med reel trafik → hybrid (næste afsnit). Pointen med tjeklisten er at beslutte ud fra evidens, ikke ud fra hvilken teknik der trendér i dit feed i denne måned.

Kan du bruge RAG og finjustering sammen?

Ja, og for modne produktionssætninger er hybrid-mønsteret normen, ikke undtagelsen. Finjuster for domæneflydende og outputformat (hvordan), hent for fakta ved inferenstidspunktet (hvad). Balaguer et al. rapporterer præcis dette på deres landbrugsopgave: hybridpipelinen slog begge metoder alene, med RAG's 5-points gevinst oven på finjusteringens 6.

Den modenhedsvej, vi anbefaler: start med promptteknik, tilføj RAG i det øjeblik svarene kræver private eller friske data, og tilføj finjustering først, når formatinkonsekvens eller latenstid begynder at gøre ondt i produktion. Spring direkte til finjustering, og du betaler træningsskatten, før du ved, om retrieval allerede har løst problemet.

Hybridmønsteret er ikke et kompromis; for modne produktionssætninger er det standarden: finjuster for format, hent for fakta.

Hvordan evaluerer du din vinder?

Vælg vinderen, som du ville vælge en database: mål på din arbejdsbyrde, ikke på mavefornemmelse. Opskriften fylder ét afsnit og dækker de fire tal, der faktisk afgør det.

• Tilbageholdt spørgsmålssæt. 100-300 rigtige brugerspørgsmål. Ikke syntetiske, aldrig noget set under træning eller indeksering.
• Trofasthed og svarkorrekthed. Trofasthed spørger, om svaret er funderet i den hentede kontekst; svarkorrekthed spørger, om det faktisk er rigtigt. Parret, populariseret af RAGAS, fanger både hallucination og retrieval-missere.
• Latenstid ved p95, ikke gennemsnittet. Retrieval tilføjer en rundtur; mål halen.
• Omkostning pr. 1.000 forespørgsler, tokens plus infrastruktur, målt i stedet for gættet.
• Genkør ved drift. Nye dokumenter, nyt modelsnapshot, nyt kvartal: genkør sættet.

Den fulde metrik-gennemgang, inklusive værktøjer, findes i vores LLM-evalueringsguide.

Ofte stillede spørgsmål

Kan man bruge RAG og finjustering sammen?

Ja. Finjuster for outputformat og domæneflydende, og behold retrieval for fakta ved inferenstidspunktet. Balaguer et al. målte denne hybrid på en landbrugs-QA-opgave og fandt, at den slog begge metoder alene, med nøjagtighedsgevinster, der lagde sig ovenpå. De fleste modne produktionssystemer ender her: vægte for hvordan, retrieval for hvad.

Hvornår skal man ikke bruge finjustering?

Spring finjustering over, når din viden ændrer sig hurtigere, end du kan genoptræne, når du har færre end nogle få hundrede mærkede eksempler, når svarene skal bære kildehenvisninger eller revisionsspor, eller når der ikke er budget til at genoptræne, når data driver. De fire betingelser beskriver de fleste tidlige produkter, og derfor er RAG som regel det rigtige første træk.

Er finjustering afkræftet?

Nej, men dens territorium er skrumpet. Lange kontekstvinduer og billig RAG opslugte use cases, der krævede finjustering i 2023. Det, der er tilbage, er reelt: strengt outputformat, brandtone, latensbudgetter uden en retrieval-rundtur og små-model-økonomi. Hvis dit problem er, hvordan modellen svarer, snarere end hvad den ved, er finjustering stadig værktøjet.

Hvornår ville du bruge RAG vs finjustering?

Brug RAG, når svarene afhænger af privat eller hyppigt opdateret viden, eller når du har brug for kildehenvisninger. Brug finjustering, når du har brug for konsekvent format, tone eller latenstid, og du har nok mærkede eksempler. Brug begge dele, når produktet modnes. Hvis du er i tvivl, så start med RAG: det er billigere at fortryde end en træningskørsel.

Er RAG billigere end finjustering?

Upfront, ja. RAG's omkostning er pr. forespørgsel (embeddinger plus ekstra input-tokens), mens finjustering opkræver én gang for træning og mærkede data og derefter fornyes ved hver genoptræning. På offentlige listepriser lander break-even omkring 6,4 millioner forespørgsler i vores regneeksempel, så ved typiske volumener forbliver RAG billigere i produktets levetid.

Er RAG bedre end finjustering mod hallucinationer?

Som regel, men ikke gratis. RAG funderer svar i hentede chunks, så du kan citere kilder og revidere fejl. Dårlig retrieval forgifter dog svaret: Anthropic målte en fejlrate på 5,7 % i top-20-hentningen på simple opstillinger, skåret til 1,9 % med kontekstuel retrieval plus reranking. Finjustering kan i mellemtiden bage fejl ind i vægtene uden nogen måde at spore dem på.

RAG vs finjustering vs promptteknik: hvad er forskellen?

Promptteknik ændrer de instruktioner, du sender. RAG ændrer den kontekst, modellen læser ved forespørgselstidspunktet. Finjustering ændrer modellens vægte. Hvert er et større indgreb end det foregående: prøv prompts først, tilføj retrieval, når viden er flaskehalsen, og træn kun, når format, tone eller latenstid stadig gør ondt.

Hvordan evaluerer man RAG vs finjustering-ydeevne?

Byg et tilbageholdt sæt med 100-300 rigtige brugerspørgsmål, og bedøm begge metoder på det: trofasthed (er det funderet?), svarkorrekthed (er det rigtigt?), p95-latenstid og omkostning pr. 1.000 forespørgsler. Genkør sættet, hver gang dine dokumenter eller dit modelsnapshot ændrer sig. Syntetiske spørgsmål smigrer begge systemer; rigtige adskiller dem.

Finjustering vs RAG til multi-hop-spørgsmål om ny viden?

RAG, med bedre retrieval. Mekanismen afgør denne: en finjusteret model kan kun ræsonnere over, hvad dens vægte absorberede, så viden, den aldrig så, er utilgængelig, uanset hvor godt den blev trænet. Retrieval rækker den de manglende brikker ved forespørgselstidspunktet. Hagen er, at én retrieval-passage sjældent samler alle hop, så planlæg efter forespørgselsdekomponering eller iterativ retrieval plus en reranker, ikke et enkelt top-K-opslag.

Konklusion

Opsummeringen uden forbehold:

• RAG er standardvalget for skiftende viden og citerede svar. Finjustering er specialisten for format, tone og latenstid.
• Evidensen fra samme opgave (Balaguer et al.) giver finjustering +6 p.p. og RAG yderligere +5 p.p. ovenpå, med hybridløsningen som bedst af de tre. Vores start-med-RAG-råd hviler på aktualitet, kildehenvisninger og omkostninger, ikke på den måltavle.
• Omkostningsregnskabet lander i RAG's favør ved realistiske volumener: break-even lå omkring 6,4 millioner forespørgsler i vores regneeksempel.
• Beslut med de fem checks, ikke med vane.

Valgte du RAG? Se vores rangerede RAG-værktøjsliste for stacken omkring pipelinen.