RAG eller finjustering? Hva virkelige kundeprosjekter lærte oss om å velge

Nesten hver samtale jeg har om KI i næringslivet, når det samme veiskillet i løpet av den første timen. Kunden har en stor språkmodell som gjør et imponerende inntrykk i en demonstrasjon, men som ikke kjenner produktene, retningslinjene eller skrivestilen deres. Noen i rommet spør: Bør vi finjustere modellen på dataene våre, eller bør vi bygge generering med utvidet informasjonsinnhenting (RAG) rundt den?

Det ærlige svaret er at spørsmålet som regel er feil stilt. RAG og finjustering løser ulike problemer. Team som behandler dem som konkurrerende alternativer, bruker gjerne måneder og store GPU-budsjetter på å løse feil problem. Slik avgjør vi hva vi skal gjøre i praksis, og dette har vi sett fungere – og ikke fungere.

Ta utgangspunkt i hva modellen mangler

Når en modell gir et dårlig svar på en forretningsoppgave, mangler den én av to ting.

Den mangler kunnskap. Den kjenner ikke den nyeste prisliste, klausulen i leverandørkontrakten fra 2025 eller feilsøkingstrinnene for et produkt som ble lansert forrige måned. Dette er et faktaproblem.

Den mangler riktig atferd. Den vet nok, men svarer ikke slik du trenger. Den ignorerer ønsket utdataformat, skriver i feil tone, tolker de interne kodene dine feil eller klarer ikke å utføre en avgrenset, gjentakende oppgave, for eksempel å klassifisere saker i de 40 kategoriene deres. Dette er et ferdighetsproblem.

RAG er verktøyet for det første problemet. Finjustering er verktøyet for det andre. Mesteparten av forvirringen jeg ser, skyldes at folk prøver å bruke finjustering til å lære modellen fakta.

Derfor er finjustering en dårlig måte å tilføre kunnskap på

Det er fristende å tro at en modell vil «kjenne» dokumentene dine hvis du trener den på dem. I praksis lærer den stilen i dokumentene langt mer pålitelig enn faktaene de inneholder. Forskere hos Microsoft sammenlignet de to tilnærmingene direkte på spørsmål som krevde mye kunnskap, og fant at RAG konsekvent ga bedre resultater enn uovervåket finjustering, både for fakta modellen hadde sett under trening, og for helt nye fakta.

Det finnes også praktiske problemer. Fakta endrer seg. Hver gang retningslinjene eller katalogen din endres, blir en finjustert modell utdatert helt til du trener den på nytt. Du mister også sporbarheten: Når en finjustert modell oppgir et tall, kan du ikke vise til dokumentet det kom fra. For kunder i regulerte bransjer som forsikring og helsevesen er det alene som regel nok til å avslutte diskusjonen.

RAG, som først ble beskrevet i artikkelen fra 2020 av Lewis et al., holder kunnskapen utenfor modellen. Når et spørsmål stilles, henter du inn relevante tekstutdrag og gir dem til modellen som kontekst. For å oppdatere kunnskapen trenger du bare å oppdatere en indeks, ikke trene modellen på nytt. Dessuten kan hvert svar vise til kilden sin.

En logistikkunde av oss er et godt eksempel. Kundene deres ønsket umiddelbare svar på hvor forsendelsene deres befant seg, og hvilke dokumenter som manglet. Denne informasjonen endrer seg med få minutters mellomrom. Ingen mengde trening ville ha holdt modellen oppdatert, så assistenten vi bygde, svarer ut fra sanntidsdata for sporing og IoT når spørsmålet stilles, i stedet for å basere seg på hukommelsen. Informasjonsinnhenting var den eneste løsningen som kunne fungere.

Når finjustering er nyttig

Finjustering er ikke avleggs. Den har bare et snevrere bruksområde enn mange tror. Vi bruker den i tre situasjoner:

• Strenge, gjentakende utdataformater. Når en modell må produsere samme strukturerte utdata tusenvis av ganger om dagen, for eksempel hente ut felter fra fakturaer i et fast JSON-skjema, er en finjustert liten modell ofte mer pålitelig og langt billigere enn å gi instruksjoner til en stor modell.
• Fagspråk. Enkelte fagområder bruker forkortelser som grunnmodellen tolker feil. Vanlige eksempler er statuskoder i logistikk, kliniske forkortelser og interne produktkoder. En moderat finjustering kan løse dette.
• Kostnader og responstid i stor skala. Når en oppgave er tydelig definert, kan en finjustert liten modell erstatte en stor generell modell. Metoder som LoRA gjør dette rimelig, fordi du trener et lite sett med ekstra vekter i stedet for hele modellen.

Legg merke til at ingen av disse bruksområdene handler om fakta. De handler om å lære en modell hvordan den skal utføre en oppgave du allerede forstår godt.

De fleste RAG-feil skyldes problemer med informasjonsinnhentingen

Når et team sier til meg «vi prøvde RAG, men det fungerte ikke», er det sjelden modellen som er problemet. Det er trinnet der informasjonen hentes inn. Modellen kan ikke gi bedre svar enn tekstutdragene den får.

Løsningene er lite spektakulære, men effektive:

• Del opp etter mening, ikke etter antall tegn. Hvis du deler en kontrakt opp for hver 500. tegn, blir klausulene kuttet i to. Oppdeling etter avsnitt og overskrifter bevarer sammenhengen.
• Legg til kontekst i hvert tekstutdrag. Et utdrag som sier «grensen er 30 dager», er ubrukelig uten at man vet hvilken forsikring det gjelder. Anthropic rapporterte at det å legge til kort dokumentkontekst i hvert tekstutdrag før indeksering – en tilnærming de kaller kontekstuell informasjonsinnhenting – reduserte antallet mislykkede søk med 49 %, og med 67 % når det ble kombinert med omrangering.
• Kombiner søk etter nøkkelord med vektorsøk. Vektorsøk er godt til å finne innhold ut fra mening, men mindre egnet til å finne nøyaktige termer som delenummer. Hybridsøk dekker begge deler.
• Test gjenfinningen separat. Sett sammen et utvalg reelle spørsmål med kjente, riktige kildetekster, og mål om riktig tekst dukker opp blant de øverste resultatene før du vurderer de endelige svarene.

Når du bør bruke begge deler

I produksjon kombinerer de beste systemene ofte begge deler. RAG leverer faktaene. En lett finjustert modell håndterer format, tone og fagspråk. Forskningen beveger seg i samme retning: RAFT-tilnærmingen fra UC Berkeley finjusterer en modell spesifikt for at den skal bli bedre til å bruke hentede dokumenter og ignorere irrelevante dokumenter.

Men rekkefølgen er viktig. Vi bygger nesten alltid RAG først, måler hvor det kommer til kort, og vurderer først deretter om finjustering er verdt det. Begynner man med finjustering, betaler man for trening før man vet hva den egentlige mangelen er.

En enkel sjekkliste for valg

1. Avhenger oppgaven av fakta som endres oftere enn én gang i kvartalet? Bruk RAG.
2. Trenger brukere eller revisorer å se hvor et svar kommer fra? Bruk RAG.
3. Handler problemet om formatet, tonen eller ordforrådet i svarene, ikke om faktaene? Vurder finjustering.
4. Er det en avgrenset oppgave som utføres i stort omfang, der kostnad eller hastighet er viktig? Vurder å finjustere en mindre modell.
5. Har du målt kvaliteten på gjenfinningen separat? Hvis ikke, gjør det før noe annet.

Hovedpoenget

RAG og finjustering er ikke rivaler. Den ene gir modellen riktig informasjon, den andre former hvordan den oppfører seg. Finn ut hvilket problem du faktisk har, forbedre gjenfinningen før du gir modellen skylden, og se på finjustering som en optimalisering du først gjør deg fortjent til når systemet fungerer – ikke som en snarvei til å få det til å fungere.