Hvad er RAG-arkitektur? En komplet definition med detaljerede praktiske eksempler

RAG, som står for retrieval augmented generation, er en proces, hvor LLM'er bruger ekstern information til at udbygge og forbedre deres output. RAG-arkitektur er det sæt af komponenter og forbindelser, der gør RAG muligt.

Der findes flere forskellige kategorier af RAG, og hver af dem kører på sin egen unikke arkitektur. Grundlæggende bestemmer arkitekturen i et RAG-system den særlige måde, hvorpå information lagres, hentes og føres videre til en LLM.

Hvad er RAG-arkitektur?

RAG-arkitektur er den underliggende konfiguration af komponenter (og deres tilhørende funktioner), der driver et givet RAG-system. Alle disse arkitekturer bygger på en grundlæggende skabelon, som ofte kaldes ”simpel” eller ”naiv” RAG.

Her er et overordnet overblik over den grundlæggende RAG-arkitektur:

• Informationskilde: Det er her, den eksterne information lagres. Det kan være et søgeindeks, en vektordatabase, der repræsenterer store mængder information, eller et lager af rå dokumenter.
• Hentningskomponent: Dette er den mekanisme, som informationskilden forespørges med. Et RAG-system kan for eksempel bruge en simpel søgeordssøgning til at finde relevante tekststykker eller mere komplekse vektorforespørgsler til at udføre en lighedssøgning.
• Orkestreringskomponent: Dette lag er den del af den LLM-baserede applikation, der igangsætter RAG-pipelinen for en brugerprompt, enten i samspil med LLM'en eller uafhængigt af den. Det samler også den hentede information i en udvidet prompt.

Komponenterne i en RAG-arkitektur er normalt organiseret i to stier. Indlæsningsstien tager data og organiserer dem i en søgbar informationskilde. Vektordatabaser, hvor store mængder tekst konverteres til et søgbart lager af vektorembeddings, er en af de mest udbredte anvendelser.

Hentningsstien tager en brugers prompt og genererer en forespørgsel, som informationskilden kan søges med. Orkestratoren føjer derefter den hentede information til LLM'ens kontekstinput. I agentiske og hybride RAG-arkitekturer kan der være flere hentningsstier.

Typer af RAG-arkitektur

Det er misvisende at tænke på RAG som helt adskilte arkitekturer. De fleste ingeniører vælger en modulær tilgang og implementerer separate komponenter, der passer til specifikke anvendelser. Selvom det er muligt at trække løse grænser, er det vigtigt at bemærke, at der er betydeligt overlap mellem arkitekturmodellerne.

1. Grundlæggende RAG

Grundlæggende RAG, også kaldet ”naiv” eller ”simpel” RAG, er den arkitektoniske skabelon for andre typer RAG.

Den underliggende proces er relativt ligetil: En bruger indtaster en prompt, orkestratoren afgør, om der er brug for ekstern information (enten selvstændigt eller i samspil med LLM'en), og formulerer og sender en hentningsforespørgsel i overensstemmelse hermed.

Den eksterne informationskilde er ofte en vektordatabase, men kan også være en SQL-database, en web-API, en vidensgraf eller endda et ”råt” dokumentlager. Denne ekstra information føjes derefter til LLM'ens inputkontekst.

Ud over SQL-forespørgsler og API'er findes der to overordnede typer hentningsmetoder:

• Leksikalsk søgning (søgeordssøgning): Dette er en simpel form for RAG, hvor søgeord udtrækkes fra en brugerforespørgsel og sammenholdes med tekstpassager, der indeholder de samme søgeord. I moderne pipelines kan orkestratoren gøre dette ved hjælp af en såkaldt sparsom vektorforespørgsel, som ikke indfanger betydning.
• Tæt vektorsøgning (semantisk søgning): Tætte vektorembeddings indfanger betydning. En orkestrator kan forespørge en tæt vektordatabase på en måde, der gør det muligt at indfange betydningen af både brugerprompten og kildeinformationen.

Brugen af hukommelse er også en vigtig del af RAG-arkitekturen. Det handler om, hvordan en LLM bruger kontekst fra tidligere chats til at opbygge en hentningsforespørgsel og dermed forankre den i den bredere kontekst af en samtale (eller flere samtaler). Samtalebaseret RAG er normen for de fleste chatbots, selvom nogle anvendelser, såsom svar på supportsager, kan bruge RAG med enkeltspørgsmål.

2. Hybrid

Hybrid RAG kombinerer to forskellige typer hentning, normalt søgeordsbaseret og semantisk hentning. Søgeordssøgningen finder matchende termer, og den vektorbaserede søgning finder passager med beslægtet betydning.

Andre former for hentning, såsom gennemløb af vidensgrafer eller forespørgsler i SQL-databaser, kan også bruges. Processen styres ofte af routinglogik, enten i form af programmerede regler eller en models klassificering af spørgsmålet (selvom flere pipelines også kan køre samtidig).

Orkestratoren sammenfletter resultaterne og kan omrangere dem, før de sendes videre til LLM'en. Omrangering er processen, hvor hentede tekststykker tildeles relevansscorer, så LLM'en prioriterer den mest anvendelige information.

3. Adaptiv RAG

I adaptiv RAG vælger en routingkomponent en hentningsstrategi ud fra brugerpromptens krav, hvorefter orkestratoren udfører den valgte arbejdsproces.

I det oprindelige framework (Adaptive-RAG) fungerede en mindre model som klassifikator og valgte mellem ingen hentning, hentning i ét trin eller hentning i flere trin. Nogle arkitekturer bruger nu i stedet generative modeller eller regelbaserede heuristikker.

Det er en populær arkitektur, fordi den fordeler regnekraft ud fra en prompts kompleksitet og krav og dermed reducerer unødvendige hentningstrin for enklere prompts. Den er udbredt i assistenter, der håndterer flere typer spørgsmål.

4. Korrigerende RAG (CRAG)

Korrigerende RAG evaluerer hentet information, før den føjes til LLM'ens kontekstinput. En hentningsevaluator vurderer, om den hentede information er relevant og nyttig. Det unikke arkitektoniske træk er det eksplicitte trin med evaluering og korrektion, før svaret genereres.

Hvis informationen viser sig at være ufuldstændig eller ikke relevant for prompten, udløses yderligere forespørgsler. De kan omfatte andre hentningsmetoder end dem, der blev brugt til den oprindelige forespørgsel, såsom websøgning eller gennemløb af vidensgrafer.

Korrigerende RAG er udbredt inden for områder, hvor nøjagtighed er vigtig, såsom medicin og jura. Den kræver dog en ekstra informationskilde, der kan supplere de oprindeligt hentede passager.

5. Self-RAG

I self-RAG kan modellen igangsætte forespørgsler efter at have modtaget det indledende kontekstinput. Genererede svar evalueres i forhold til den hentede evidens ved hjælp af refleksionstokens, og yderligere forespørgsler sendes via orkestratoren efter behov. Omvendt kan LLM'en også beslutte, at der slet ikke er behov for hentning.

Den adskiller sig fra korrigerende RAG ved, at LLM'en bedømmer sine egne output, afgør, om der er behov for hentning, og om den hentede tekst er nyttig, samt overvåger sine egne svar og ændrer dem efter behov. Korrigerende RAG evaluerer derimod kvaliteten af den hentede information før genereringen.

Denne arkitektur er særligt nyttig til komplekse prompts i stil med dybtgående forskning. Fordi den integrerer vurderinger af relevans (af den hentede information) i genereringen af svar, er den en god løsning til prompts, der kræver evidensbaserede svar.

6. Agentisk RAG

Agentisk RAG dækker over enhver form for RAG, der udføres i konteksten af en agentisk platform. Modellen bruger sine ræsonneringsevner til at afgøre, hvilken type information der er brug for, og vælger blandt de tilgængelige hentningsmuligheder.

Hentning kan udløses flere gange efter behov, og modellen har mulighed for at tildele agenter til mere komplekse forespørgsler. En LLM kan for eksempel anmode om et databaseopslag for at identificere en leverandør, udløse en dokumentsøgning for at finde relevante kontrakter og afslutte med en websøgning for at bekræfte kontaktoplysninger ved hjælp af offentlige kilder.

Agentisk RAG er den primære arkitekturimplementering i udbredte chatbots som Perplexity, ChatGPT, Claude og så videre. Fordi disse platforme giver kernemodellen adgang til flere værktøjer og RAG-pipelines, kan den vælge, hvilken form for hentning der passer bedst til en prompt.

7. Multimodal RAG

Multimodal RAG henter kontekst på tværs af forskellige medietyper. Det er en vigtig form for RAG, fordi den gør information som diagrammer og lydoptagelser, der ellers ville være utilgængelig, tilgængelig for LLM'er.

Den underliggende arkitektur er den samme som i ethvert andet system. En indekseringspipeline kan for eksempel forberede billeder til søgning ved at konvertere dem direkte til embeddings. Et agentisk RAG-system kan derefter hente disse billeder sammen med semantisk relevant tekst og sende dem til en vision-language-model til kombineret behandling.

8. GraphRAG

GraphRAG bruger vidensgrafer sammen med vektorsøgning til at hente information om entiteter. Typisk finder orkestratoren relevante startentiteter, også kaldet noder, ved hjælp af søgeordsudtrækning eller nogle gange en indledende vektorsøgning. En grafbaseret hentningskomponent gennemløber derefter en vidensgraf for at opbygge en bredere kontekst.

Som svar på en anmodning om en detaljeret gennemgang af en produktkategori kan en LLM for eksempel udløse en vektorsøgning for at identificere specifikke entiteter (produkter). Orkestratoren udløser derefter en søgning i vidensgrafen for at finde relaterede entiteter, såsom leverandører, butikker, anmeldelser og så videre.

9. Forgrenet RAG

Hvor en hybrid RAG-arkitektur kan bruge forskellige metoder til hentning, henviser forgrenet RAG til processen med at køre flere forespørgsler, kaldet grene, på samme tid. Hver gren kan forespørge en separat informationskilde, eller grenene kan forespørge den samme kilde parallelt med forskellige forespørgsler eller filtre. Agentisk RAG-arkitektur bruger ofte forgrenet RAG.

10. HyDE (Hypothetical Document Embeddings)

HyDE er en innovativ form for RAG, hvor en LLM genererer et hypotetisk tekstdokument, der viser, hvordan et optimalt svar kunne se ud. Dette ”hypotetiske dokument” bruges derefter til at oprette en forespørgsel, der giver mere præcis hentning. Selvom den relevante viden ikke er repræsenteret i LLM'ens parametre, er rationalet, at en svarlignende passage kan matche relevante dokumenter bedre end et kort spørgsmål eller en tvetydig prompt.

Eksempel på simpel RAG-arkitektur: Vektordatabase

Grundlæggende RAG fungerer som fundament for mere komplekse typer arkitektur. I et simpelt RAG-system, der bruger en vektordatabase, opdeles kildedokumentationen i mindre dele (chunks), som konverteres til tætte embeddings. Når en bruger indtaster en prompt, genererer orkestratoren en forespørgsel, koder den og forespørger databasen for at finde relevante passager.

Her er en trinvis gennemgang af processen:

1. Store mængder tekst konverteres til vektorer ved hjælp af en automatiseret indlæsningspipeline og en embeddingmodel som BERT.
2. Databaseapplikationen organiserer, indekserer og lagrer vektorerne, så der kan søges hurtigt.
3. Brugeren indtaster en prompt i en chatbot (såsom Perplexity).
4. Applikationens orkestrator koder prompten (ved hjælp af en embeddingmodel) for at hente relevant information fra vektordatabasen.
5. Vektordatabasen returnerer relevante tekststykker, og orkestratoren føjer dem til inputkonteksten (den ”store prompt”) og sender den til LLM'en.
6. LLM'en bruger den ekstra kontekst til at generere et svar ved hjælp af sin interne viden (lagret i dens parametriske vægte).

Udvid

Eksempel på avanceret RAG-arkitektur: Agentisk RAG

Agentisk RAG henviser til den underliggende arkitektur i RAG-systemer på en agentisk platform. Agentiske RAG-forløb er ofte komplekse, fordi AI-agenter kan aktivere forskellige værktøjer og pipelines afhængigt af promptens karakter og om nødvendigt sætte flere agenter i gang.

Her er et praktisk eksempel på processen:

1. En bruger indtaster et komplekst spørgsmål, der kræver dybtgående forskning i et emne. Lad os i dette eksempel sige, at prompten er ”Giv en prognose for virksomhedens indtjening over de næste seks måneder i lyset af større geopolitiske begivenheder.”
2. LLM'en ræsonnerer, at der vil være brug for en kombination af RAG-forespørgsler på tværs af forskellige indholdstyper.
3. Tre forskellige agenter sættes i gang til (a) vektorsøgning, (b) webforankring og (c) billedsøgning (multimodal).
4. Agenterne søger efter relevant information, såsom nyhedsartikler og interne finansielle data, via orkestratoren ved hjælp af de tilgængelige hentningsværktøjer.
5. LLM'en sammenligner de hentede resultater med hver agents forskningsspørgsmål og rangerer dem efter relevans.
6. LLM'en evaluerer informationen og udløser yderligere søgninger via de enkelte agenter, hvor der mangler information.
7. Når der er hentet tilstrækkelig information, genererer LLM'en scenarieprognoser baseret på eksisterende finansielle tal (hentet fra intern dokumentation) og kalder et lommeregnerværktøj for at fremskrive indtjeningen for hvert scenarie.
8. LLM'en genererer et endeligt svar ud fra den hentede information og beregningerne og angiver kilder efter behov.

Udvid

Hvad bringer fremtiden for RAG?

De aktuelle innovationer handler om at give nuværende RAG-arkitekturer mere dybde og hastighed, forbedre nøjagtigheden af multimediehentning og bygge systemer, der er designet til at håndtere information i realtid.

Her er tre tendenser, der i øjeblikket former forskningens retning:

• Dybtgående forskning på tværs af flere kilder: Dette er RAG-arkitektur, der kan planlægge søgninger, køre flere grene på tværs af forskelligartede kilder, evaluere den hentede evidens og selv optimere de genererede svar. Agentisk RAG, der kan udføre alle disse opgaver, bliver fortsat hurtigere og mere omkostningseffektiv.
• Multimodale anvendelser: Hentningspipelines bliver bedre til at arbejde med billeder og video. De kan i stigende grad finde specifikke typer information i komplekse multimodale data, såsom lange videoer og avancerede diagrammer.
• Forankring af svar i information, der konstant ændrer sig: LLM-baserede applikationer kan trække på informationskilder i realtid (såsom videofeeds og sensorer) for at levere inputkontekst. Systemer kan også generere mangefacetterede informationsnetværk, som med GraphRAG, for at fortolke disse data.

RAG er grundlæggende for, hvordan LLM-baserede applikationer fungerer. Det gør det muligt for en lang række forskellige brugere, fra almindelige forbrugere til virksomheder inden for specialiserede områder, at overvinde problemer med hallucinationer, ufuldstændige træningsdata og manglende adgang til specialiseret intern viden.

Derfor udgør RAG-systemer og deres underliggende arkitektur et af de hurtigst udviklende og mest spændende områder inden for AI-forskning.