RAG (Retrieval-Augmented Generation): definition och funktion

RAG är en av de tekniska byggstenarna som driver dagens autonoma AI-agenter, tillsammans med verktygsanrop och beständigt minne. Förkortningen kommer från en forskningsartikel publicerad i maj 2020 av ett team från Facebook AI Research (idag Meta), med Patrick Lewis i spetsen. Vid den tiden var konstaterandet enkelt: stora språkmodeller lagrar en imponerande mängd kunskap i sina parametrar, men de kan varken uppdatera den enkelt eller peka precist mot en källa. RAG föreslår en lösning: låta modellen hämta information från en extern databas vid tidpunkten för svaret, i stället för att förlita sig helt på sitt minne som fryses vid träningen.

Detaljerad definition

Retrieval-Augmented Generation, eller generering förstärkt av sökning, beskriver en arkitektur som kombinerar två separata byggstenar: en sökmekanism (retrieval) som hämtar relevanta avsnitt från en extern dokumentbas, och en textgenereringsmodell som skriver det slutliga svaret utifrån dessa avsnitt. I grundartikeln av Lewis och medförfattare (NeurIPS 2020) kombinerar RAG ett parametriskt minne (den förtränade modellens interna kunskap) och ett icke-parametriskt minne (en dokumentbas som konsulteras löpande), för att förbättra prestandan på uppgifter som kräver precis kunskap.

Konsensus kring den här definitionen är bred: oavsett om det är i den akademiska litteraturen eller i populärvetenskapliga förklaringar som NVIDIA:s, landar RAG alltid i samma tvåstegsmekanik, söka och sedan generera. Skillnaderna gäller framför allt den tekniska implementationen (typ av vektordatabas, metod för att dela upp dokument, antal hämtade avsnitt), inte definitionen av principen i sig.

RAG adresserar två kända begränsningar hos språkmodeller: hallucinationer, när modellen hittar på ett trovärdigt men felaktigt svar, och inaktualitet, när information har förändrats sedan modellens träningsdatum. Genom att förankra genereringen i verkliga och aktuella dokument minskar RAG båda dessa problem utan att kräva omträning av modellen.

Så fungerar det

Det typiska förloppet för en RAG-förfrågan följer tre steg. Först omvandlas användarens fråga (eller en agents behov) till en sökning i en dokumentbas, ofta via en likhetssökning på vektorrepresentationer av texten, ibland kombinerad med en klassisk nyckelordssökning. Sedan injiceras de mest relevanta avsnitten som sökningen hittar i kontexten som skickas till språkmodellen, utöver den ursprungliga frågan. Till sist genererar modellen sitt svar utifrån dessa avsnitt, gärna genom att citera eller hålla sig till deras innehåll snarare än att improvisera.

Den här mekaniken passar väl för en autonom AI-agent: dokumentsökningen kan exponeras som ett verktyg som agenten själv anropar, när den bedömer att den behöver det, i stället för att systematiskt utlösas innan varje svar. Det är skillnaden mellan en "statisk" RAG, kopplad före varje förfrågan, och en "agentisk" RAG, där modellen bestämmer när den ska söka, vad den ska söka efter, och om den behöver söka igen om det första resultatet inte räcker.

Konkret exempel med Atako

Atakos publika dokumentation beskriver inte i detalj den interna sökarkitekturen som dess agenter använder, så det går inte att här hävda att Atako använder RAG i strikt mening enligt Lewis et al.:s artikel. Det som däremot är dokumenterat är den närmast liggande mekanismen: varje agent har tillgång till ett filbibliotek delat av företaget, organiserat i mappar, med förhandsgranskningsbara format (Markdown, CSV, JSON, PDF, HTML, bilder, text, källkod). De här filerna kan delas med en agent i läsläge, eller läggas direkt i en mapp dedikerad till agenten, av en människa eller av agenten själv.

Det här filbiblioteket, i kombination med en agents beständiga minne som överlever omstarter och pauser, fungerar som en extern kunskapsbas som agenten kan konsultera innan den svarar eller agerar, vilket i andan motsvarar RAG-principen: hämta verklig information i stället för att bara förlita sig på det modellen memorerat under träningen. En agent konfigurerad för kundsupport kan till exempel konsultera produktdokumentationsfiler delade i sin mapp innan den svarar på ett ärende, i stället för att gissa svaret.

Vanliga misstag

Den första vanliga förväxlingen är att tro att RAG är en funktion man aktiverar med ett klick, som en knapp i en mjukvara. Det är i själva verket en arkitektur, med konkreta tekniska val (hur dokumenten delas upp, hur de indexeras, hur många avsnitt som hämtas) som direkt avgör svarens kvalitet.

Andra misstaget: tro att RAG helt eliminerar hallucinationer. Det minskar dem genom att förankra genereringen i verifierbara dokument, men en modell kan fortfarande feltolka ett avsnitt, eller generera ett svar utifrån irrelevanta dokument som en ofullständig sökning hämtat. RAG förskjuter risken, det tar inte bort den.

Tredje misstaget: blanda ihop RAG och finjustering. Finjustering förändrar modellen varaktigt genom att träna om den på specifik data; RAG lämnar modellen intakt och lägger till en extern databas som konsulteras vid varje förfrågan, vilket är snabbare att uppdatera och generellt billigare.

Slutligen är det ett klassiskt misstag att underskatta betydelsen av dokumentbasens kvalitet. Ett RAG-system kopplat till föråldrade, dåligt strukturerade eller ofullständiga dokument kommer att producera svar av dålig kvalitet, oavsett hur kraftfull genereringsmodellen bakom är.