RAG eller finjustering? Vad verkliga kundprojekt har lärt oss om valet

Nästan varje samtal om AI i företag som jag deltar i når samma vägskäl redan under den första timmen. Kunden har en stor språkmodell som gör ett imponerande intryck i en demonstration, men som inte känner till kundens produkter, policyer eller sätt att skriva. Någon i rummet frågar: Ska vi finjustera modellen med våra data, eller ska vi bygga upp generering med förstärkt informationshämtning (RAG) kring den?

Det ärliga svaret är att frågan oftast ställs på fel sätt. RAG och finjustering löser olika problem. Team som behandlar dem som konkurrerande alternativ tenderar att lägga månader och en stor del av sin GPU-budget på att försöka lösa fel problem. Så här fattar vi beslut i praktiken, och det här har vi sett fungera – och inte fungera.

Börja med att ta reda på vad modellen saknar

När en modell ger ett dåligt svar på en affärsuppgift saknar den en av två saker.

Den saknar kunskap. Den känner inte till din senaste prislista, klausulen i ditt leverantörsavtal från 2025 eller felsökningsstegen för en produkt som lanserades förra månaden. Det här är ett faktaproblem.

Den saknar rätt beteende. Den kan tillräckligt mycket, men svarar inte på det sätt du behöver. Den ignorerar önskat svarsformat, skriver med fel ton, misstolkar dina interna koder eller klarar inte av en avgränsad, återkommande uppgift som att sortera ärenden i dina 40 kategorier. Det här är ett färdighetsproblem.

RAG är verktyget för det första problemet. Finjustering är verktyget för det andra. Mycket av den förvirring jag stöter på beror på att man försöker använda finjustering för att lära modellen fakta.

Därför är finjustering ett dåligt sätt att tillföra kunskap

Det är frestande att tro att modellen kommer att ”känna till” innehållet om man tränar den på sina dokument. I praktiken lär den sig dokumentens stil betydligt mer tillförlitligt än fakta i dem. Forskare vid Microsoft jämförde metoderna direkt för kunskapsintensiva frågor och fann att RAG konsekvent gav bättre resultat än oövervakad finjustering, både för fakta som modellen hade sett under träningen och för helt nya fakta.

Det finns också praktiska problem. Fakta förändras. Varje gång din policy eller katalog ändras blir en finjusterad modell inaktuell tills du tränar den på nytt. Du förlorar också spårbarheten: när en finjusterad modell anger en siffra kan du inte hänvisa till dokumentet som uppgiften kommer från. För kunder inom reglerade branscher som försäkring och hälso- och sjukvård räcker det oftast för att avsluta diskussionen.

RAG, som först beskrevs i artikeln från 2020 av Lewis med flera, håller kunskapen utanför modellen. När frågan ställs hämtar du relevanta textavsnitt och skickar dem till modellen som kontext. För att uppdatera kunskapen behöver du uppdatera ett index, inte träna om modellen. Dessutom kan varje svar hänvisa till sin källa.

En logistikföretagskund till oss är ett bra exempel. Kundens kunder ville få omedelbara svar om var deras försändelser befann sig och vilka dokument som saknades. Den informationen förändras med några minuters mellanrum. Ingen mängd träning hade kunnat hålla en modell uppdaterad, så assistenten vi byggde hämtar svar från aktuella spårnings- och IoT-data när frågan ställs, i stället för att förlita sig på minnet. Informationshämtning var den enda fungerande lösningen.

När finjustering kommer till sin rätt

Finjustering är inte död. Den är bara mer begränsad än många tror. Vi använder den i tre situationer:

• Strikta, återkommande svarsformat. När en modell måste ta fram samma strukturerade resultat tusentals gånger om dagen, till exempel genom att extrahera fält från fakturor till ett fast JSON-schema, är en finjusterad liten modell ofta mer tillförlitlig och mycket billigare än att styra en stor modell med promptar.
• Domänspråk. Inom vissa områden finns det förkortningar som grundmodellen misstolkar. Vanliga exempel är statuskoder inom logistik, kliniska förkortningar och interna produktkoder. En måttlig finjustering kan lösa problemet.
• Kostnad och svarstid i stor skala. När en uppgift är väl definierad kan en finjusterad liten modell ersätta en stor, generell modell. Metoder som LoRA gör detta ekonomiskt överkomligt, eftersom man tränar en liten uppsättning extra vikter i stället för hela modellen.

Lägg märke till att inget av detta handlar om fakta. Det handlar om att lära en modell hur den ska bete sig när den utför en uppgift som du redan förstår väl.

De flesta RAG-problem beror på brister i informationshämtningen

När någon i ett team säger till mig ”vi testade RAG och det fungerade inte” är modellen sällan problemet. Problemet ligger i steget där information hämtas. Modellen kan bara vara så bra som de textavsnitt den får.

Lösningarna är inte särskilt glamorösa, men de fungerar:

• Dela upp efter betydelse, inte efter antal tecken. Om ett avtal delas upp var 500:e tecken hamnar klausuler mitt itu. Om man delar upp efter avsnitt och rubriker bevaras sammanhanget.
• Lägg till kontext i varje textavsnitt. Ett textavsnitt som säger ”gränsen är 30 dagar” är värdelöst om man inte vet vilken policy det gäller. Anthropic rapporterade att antalet misslyckade informationshämtningar minskade med 49 procent när kort kontext från dokumentet lades till i varje textavsnitt före indexeringen – en metod som företaget kallar kontextuell informationshämtning – och med 67 procent när metoden kombinerades med omrangordning.
• Kombinera sökning med sökord och vektorsökning. Vektorsökning är bra på att hitta betydelsemässiga likheter, men sämre på exakta termer som artikelnummer. Hybridsökning klarar båda.
• Testa informationshämtningen separat. Sammanställ verkliga frågor med kända, korrekta källpassager och mät om rätt passage hamnar bland de översta resultaten innan du bedömer de slutliga svaren.

När du bör använda båda

I produktionsmiljö kombinerar de starkaste systemen ofta båda metoderna. RAG tillför fakta. En lätt finjusterad modell hanterar format, ton och fackspråk. Forskningen går i samma riktning: RAFT-metoden från UC Berkeley finjusterar en modell specifikt för att den ska kunna använda hämtade dokument bättre och ignorera irrelevanta dokument.

Men ordningsföljden spelar roll. Vi bygger nästan alltid först en RAG-lösning, mäter var den brister och avgör först därefter om finjustering är värd insatsen. Börjar man med finjustering betalar man för träning innan man vet vad den verkliga bristen är.

En enkel beslutschecklista

1. Beror uppgiften på fakta som ändras mer än en gång per kvartal? Använd RAG.
2. Behöver användare eller revisorer kunna se var ett svar kommer ifrån? Använd RAG.
3. Handlar problemet om svarens format, ton eller ordförråd, inte om fakta? Överväg finjustering.
4. Är det en avgränsad uppgift som utförs i stor skala, där kostnad eller hastighet spelar roll? Överväg att finjustera en mindre modell.
5. Har du mätt kvaliteten på informationshämtningen separat? Om inte, gör det innan du går vidare.

Slutsatsen

RAG och finjustering är inga rivaler. Den ena ger modellen rätt information, den andra formar hur den beter sig. Ta reda på vilket problem du faktiskt har, åtgärda informationshämtningen innan du skyller på modellen och betrakta finjustering som en optimering du får göra dig förtjänt av genom att först få systemet att fungera – inte som en genväg för att få det att fungera.