RAG (Retrieval-Augmented Generation): definition og funktion

RAG er en af de tekniske byggeklodser, der driver nutidens autonome AI-agenter, sammen med værktøjskald og vedvarende hukommelse. Forkortelsen stammer fra en forskningsartikel udgivet i maj 2020 af et team fra Facebook AI Research (i dag Meta), med Patrick Lewis i spidsen. Dengang var konstateringen enkel: store sprogmodeller lagrer en imponerende mængde viden i deres parametre, men de kan hverken opdatere den let eller pege præcist på en kilde. RAG foreslår en løsning: lad modellen hente information i en ekstern base på svartidspunktet, i stedet for udelukkende at stole på sin hukommelse fra træningen.

Detaljeret definition

Retrieval-Augmented Generation, eller generation understøttet af søgning, betegner en arkitektur, der kombinerer to adskilte byggeklodser: en søgemekanisme (retrieval), der finder relevante passager i en ekstern dokumentbase, og en tekstgenererende model, der skriver det endelige svar ud fra disse passager. I den grundlæggende artikel af Lewis og medforfattere (NeurIPS 2020) kombinerer RAG en parametrisk hukommelse (den præ-trænede models interne viden) og en ikke-parametrisk hukommelse (en dokumentbase, der konsulteres løbende) for at forbedre præstationen på opgaver, der kræver præcis viden.

Konsensus om denne definition er bred: uanset om det er i den akademiske litteratur eller i populærvidenskabelige forklaringer som NVIDIA's, vender RAG altid tilbage til samme mekanik i to trin: søg, generér derefter. Uenighederne handler primært om den tekniske implementering (type af vektorbase, metode til opdeling af dokumenter, antal hentede passager), ikke om selve princippets definition.

RAG adresserer to kendte begrænsninger ved sprogmodeller: hallucinationer, når modellen opdigter et plausibelt men forkert svar, og forældelse, når en information har ændret sig siden modellens træningstidspunkt. Ved at forankre generationen i reelle og opdaterede dokumenter reducerer RAG begge problemer uden at kræve gentræning af modellen.

Sådan fungerer det

Et typisk RAG-forløb følger tre trin. Først omdannes brugerens spørgsmål (eller en agents behov) til en søgning i en dokumentbase, ofte via en similaritetssøgning på vektoriserede repræsentationer af teksten, nogle gange kombineret med klassisk nøgleordssøgning. Dernæst indsættes de mest relevante passager fra søgningen i den kontekst, der sendes til sprogmodellen, sammen med det oprindelige spørgsmål. Til sidst genererer modellen sit svar ud fra disse passager, ideelt ved at citere eller holde sig til deres indhold i stedet for at improvisere.

Denne mekanik egner sig godt til brug af en autonom AI-agent: dokumentsøgningen kan eksponeres som et værktøj, agenten selv kalder, i det øjeblik den vurderer at have brug for det, i stedet for systematisk at blive udløst før hvert svar. Det er forskellen på en "statisk" RAG, koblet foran hver forespørgsel, og en "agentisk" RAG, hvor modellen selv beslutter, hvornår den skal søge, hvad den skal søge efter, og om den skal søge igen, hvis det første resultat ikke er tilstrækkeligt.

Konkret eksempel fra Atako

Atakos offentlige dokumentation beskriver ikke i detaljer den interne søgearkitektur, agenterne bruger, så det kan ikke bekræftes her, at Atako bruger RAG i streng forstand som i Lewis et al.'s artikel. Det, der derimod er dokumenteret, er den nærmeste mekanisme: hver agent har et filbibliotek delt af virksomheden, organiseret i mapper, med formater der kan forhåndsvises (Markdown, CSV, JSON, PDF, HTML, billeder, tekst, kildekode). Disse filer kan deles med en agent til læsning eller tilføjes direkte i en mappe dedikeret til agenten, af et menneske eller af agenten selv.

Dette filbibliotek, kombineret med en agents vedvarende hukommelse, der overlever genstarter og pauser, spiller rollen som ekstern videnbase, agenten kan konsultere før den svarer eller handler, hvilket i ånden svarer til RAG-princippet: hent reel information i stedet for udelukkende at basere sig på det, modellen huskede fra træningen. En agent konfigureret til kundesupport kan for eksempel konsultere delte produktdokumentationsfiler i sin mappe, før den svarer på en sag, i stedet for at gætte svaret.

Almindelige fejl

Første almindelige misforståelse: at tro, RAG er en funktion, man aktiverer med et klik, som en kontakt i et program. Det er i virkeligheden en arkitektur med konkrete tekniske valg (hvordan dokumenter opdeles, hvordan de indekseres, hvor mange passager der hentes), som direkte afgør svarenes kvalitet.

Anden fejl: at tro, RAG helt fjerner hallucinationer. Det reducerer dem ved at forankre generationen i verificerbare dokumenter, men en model kan stadig fejlfortolke en passage eller generere et svar ud fra irrelevante dokumenter hentet af en ufuldkommen søgning. RAG flytter risikoen, den fjerner den ikke.

Tredje fejl: at forveksle RAG og fine-tuning. Fine-tuning ændrer modellen varigt ved at gentræne den på specifikke data. RAG lader modellen forblive uændret og tilføjer en ekstern base, der konsulteres ved hver forespørgsel, hvilket er hurtigere at opdatere og generelt billigere.

Endelig er det en klassisk fejl at undervurdere betydningen af dokumentbasens kvalitet. Et RAG-system koblet til forældede, dårligt strukturerede eller ufuldstændige dokumenter vil producere svar af ringe kvalitet, uanset hvor kraftfuld den bagvedliggende genererende model er.