RAG eller finjustering? Hvad virkelige kundeprojekter har lært os om at vælge

Næsten alle samtaler om AI i virksomheder, jeg deltager i, når frem til det samme dilemma inden for den første time. Kunden har en stor sprogmodel, der gør et imponerende indtryk i en demo, men som ikke kender kundens produkter, politikker eller skrivestil. En i lokalet spørger: Skal vi finjustere modellen på vores data, eller skal vi bygge retrieval-augmenteret generering (RAG) omkring den?

Det ærlige svar er, at spørgsmålet som regel er stillet forkert. RAG og finjustering løser forskellige problemer. Teams, der betragter dem som konkurrerende muligheder, ender ofte med at bruge måneder og et stort GPU-budget på at løse det forkerte problem. Sådan træffer vi beslutningen i praksis, og her er, hvad vi har set lykkes og mislykkes.

Tag udgangspunkt i, hvad modellen mangler

Når en model giver et dårligt svar på en forretningsopgave, mangler den én af to ting.

Den mangler viden. Den kender ikke din seneste prisliste, klausulen i din leverandørkontrakt fra 2025 eller fejlfindingsvejledningen til et produkt, der blev lanceret i sidste måned. Det er et faktaproblem.

Den mangler de rette færdigheder. Den ved nok, men svarer ikke, som du har brug for. Den ser bort fra dit outputformat, skriver i den forkerte tone, misforstår dine interne koder eller kan ikke udføre en afgrænset, tilbagevendende opgave som at sortere sager i dine 40 kategorier. Det er et færdighedsproblem.

RAG er værktøjet til det første problem. Finjustering er værktøjet til det andet. Det meste af den forvirring, jeg oplever, skyldes forsøg på at bruge finjustering til at lære modellen fakta.

Hvorfor finjustering er en dårlig måde at tilføre viden på

Det er fristende at tro, at en model vil “kende” dine dokumenter, hvis du træner den på dem. I praksis lærer den dokumenternes stil langt mere pålideligt end de fakta, de indeholder. Forskere hos Microsoft sammenlignede de to metoder direkte på spørgsmål, der kræver omfattende viden, og fandt, at RAG konsekvent klarede sig bedre end uovervåget finjustering, både når det gjaldt fakta, modellen havde set under træningen, og helt nye fakta.

Der er også praktiske problemer. Fakta ændrer sig. Hver gang din politik eller dit katalog ændres, er en finjusteret model forældet, indtil du træner den igen. Du mister også sporbarheden: Når en finjusteret model angiver et tal, kan du ikke pege på det dokument, tallet stammer fra. For kunder i regulerede brancher som forsikring og sundhedsvæsen afslutter det som regel diskussionen.

RAG, der først blev beskrevet i artiklen fra 2020 af Lewis m.fl., holder viden uden for modellen. Når spørgsmålet stilles, henter man de relevante tekstpassager og giver modellen dem som kontekst. For at opdatere viden skal man opdatere et indeks, ikke træne modellen igen. Og hvert svar kan henvise til sin kilde.

En af vores kunder i logistikbranchen er et godt eksempel. Kundens kunder ønskede øjeblikkelige svar på, hvor deres forsendelser befandt sig, og hvilke dokumenter der manglede. De oplysninger ændrer sig med få minutters mellemrum. Ingen mængde træning kunne have holdt en model opdateret, så den assistent, vi byggede, besvarer spørgsmål på grundlag af aktuelle sporings- og IoT-data i stedet for sin hukommelse. Informationssøgning var den eneste løsning, der kunne fungere.

Her gør finjustering en forskel

Finjustering er ikke død. Den er bare mere afgrænset, end mange tror. Vi bruger den i tre situationer:

• Stramme, tilbagevendende outputformater. Når en model skal levere det samme strukturerede output tusindvis af gange om dagen, for eksempel ved at udtrække felter fra fakturaer til et fast JSON-skema, er en finjusteret lille model ofte mere pålidelig og langt billigere end at give en stor model instruktioner.
• Fagsprog. Nogle fagområder bruger forkortelser, som grundmodellen misforstår. Almindelige eksempler er statuskoder i logistik, kliniske forkortelser og interne produktkoder. En moderat finjustering kan løse problemet.
• Omkostninger og svartid i stor skala. Når en opgave er veldefineret, kan en finjusteret lille model erstatte en stor generel model. Metoder som LoRA gør det økonomisk overkommeligt, fordi man træner et lille sæt ekstra vægte i stedet for hele modellen.

Bemærk, at ingen af disse anvendelser handler om fakta. De handler om at lære en model, hvordan den skal udføre en opgave, som du allerede forstår godt.

De fleste fejl i RAG skyldes problemer med informationssøgningen

Når et team fortæller mig: “Vi prøvede RAG, men det virkede ikke”, er modellen sjældent problemet. Det er søgetrinnet. Modellen kan kun være så god som de tekstpassager, den får stillet til rådighed.

Løsningerne er ikke prangende, men de virker:

• Opdel efter mening, ikke efter antal tegn. Hvis man deler en kontrakt op for hver 500 tegn, bliver klausuler skåret midt over. Opdeling efter afsnit og overskrifter bevarer sammenhængen.
• Tilføj kontekst til hvert tekststykke. Et tekststykke, hvor der står “grænsen er 30 dage”, er ubrugeligt, hvis man ikke ved, hvilken politik det hører til. Anthropic har rapporteret, at tilføjelse af en kort kontekstbeskrivelse fra dokumentet til hvert tekststykke inden indeksering – en metode, virksomheden kalder kontekstbaseret informationssøgning – reducerede antallet af mislykkede søgninger med 49 % og med 67 %, når metoden blev kombineret med omrangering.
• Kombinér søgning efter søgeord med vektorsøgning. Vektorsøgning er god til at finde indhold ud fra betydning, men dårlig til præcise termer som varenumre. Hybridsøgning dækker begge dele.
• Test søgningen separat. Lav et sæt realistiske spørgsmål med kendte, korrekte kildetekster, og mål, om den rigtige tekst vises blandt de øverste resultater, før du vurderer de endelige svar.

Hvornår bør man bruge begge dele?

I produktionsmiljøer kombinerer de stærkeste systemer ofte de to metoder. RAG leverer faktaene. En let finjusteret model håndterer format, tone og fagsprog. Forskningen bevæger sig i samme retning: RAFT-tilgangen fra UC Berkeley finjusterer en model specifikt, så den bliver bedre til at udnytte de hentede dokumenter og ignorere irrelevante dokumenter.

Men rækkefølgen betyder noget. Vi bygger næsten altid først RAG, måler, hvor det kommer til kort, og beslutter først derefter, om finjustering er umagen værd. Hvis man begynder med finjustering, betaler man for træning, før man ved, hvad det egentlige problem er.

En enkel tjekliste til beslutningen

1. Afhænger opgaven af fakta, der ændrer sig mere end én gang i kvartalet? Brug RAG.
2. Har brugere eller revisorer brug for at se, hvor et svar stammer fra? Brug RAG.
3. Handler problemet om svarenes format, tone eller ordforråd og ikke om faktaene? Overvej finjustering.
4. Er der tale om en afgrænset opgave, der udføres i stor skala, hvor omkostninger eller hastighed er vigtige? Overvej at finjustere en mindre model.
5. Har du målt søgekvaliteten for sig? Hvis ikke, så gør det, før du foretager dig andet.

Konklusionen

RAG og finjustering er ikke konkurrenter. Den ene giver en model de rigtige oplysninger, mens den anden former dens adfærd. Find ud af, hvilket problem du faktisk står med, forbedr søgningen, før du giver modellen skylden, og betragt finjustering som noget, du først bør investere i, når systemet fungerer – ikke som en genvej til at få det til at fungere.