Hva er RAG-arkitektur? En fullstendig definisjon med detaljerte praktiske eksempler

RAG, som står for retrieval augmented generation (gjenfinningsforsterket generering), er en prosess der LLM-er bruker ekstern informasjon til å utdype og forbedre svarene sine. RAG-arkitektur er settet med komponenter og forbindelser som gjør RAG mulig.

Det finnes flere ulike kategorier av RAG, og hver av dem bygger på sin egen unike arkitektur. I bunn og grunn bestemmer arkitekturen i et RAG-system hvordan informasjon lagres, hentes og mates inn i en LLM.

Hva er RAG-arkitektur?

RAG-arkitektur er den underliggende konfigurasjonen av komponenter (og tilhørende funksjoner) som driver et gitt RAG-system. Alle disse arkitekturene bygger på en grunnleggende mal, ofte kalt «enkel» eller «naiv» RAG.

Her er en overordnet oversikt over grunnleggende RAG-arkitektur:

• Informasjonskilde: Det er her den eksterne informasjonen lagres. Det kan være en søkeindeks, en vektordatabase som representerer store mengder informasjon, eller et lager med rådokumenter.
• Gjenfinningskomponent: Dette er mekanismen som brukes til å spørre informasjonskilden. Et RAG-system kan for eksempel bruke et enkelt nøkkelordsøk for å finne relevante tekstbiter, eller mer komplekse vektorspørringer for å utføre et likhetssøk.
• Orkestreringskomponent: Dette laget er den delen av den LLM-baserte applikasjonen som starter RAG-pipelinen for en brukerprompt, enten sammen med LLM-en eller uavhengig av den. Det setter også sammen den innhentede informasjonen til en utvidet prompt.

Komponentene i en RAG-arkitektur er vanligvis organisert i to baner. Inntaksbanen tar inn data og organiserer dem i en søkbar informasjonskilde. Vektordatabaser, der store mengder tekst konverteres til et søkbart lager av vektorinnbygginger, er et av de mest brukte bruksområdene.

Gjenfinningsbanen tar en brukers prompt og genererer en spørring som brukes til å søke i informasjonskilden. Orkestratoren legger deretter den innhentede informasjonen til i kontekstinndataene for LLM-en. I agentiske og hybride RAG-arkitekturer kan det være flere gjenfinningsbaner.

Typer RAG-arkitektur

Det er misvisende å tenke på RAG som helt atskilte arkitekturer. De fleste ingeniører velger en modulær tilnærming og implementerer separate komponenter tilpasset bestemte bruksområder. Selv om det er mulig å trekke løse grenser, er det viktig å merke seg at det er betydelig overlapp mellom arkitekturmodellene.

1. Grunnleggende RAG

Grunnleggende RAG, også kalt «naiv» eller «enkel» RAG, er den arkitektoniske malen for andre typer RAG.

Den underliggende prosessen er relativt enkel: En bruker skriver inn en prompt, orkestratoren avgjør om ekstern informasjon er nødvendig (enten uavhengig eller sammen med LLM-en), og formulerer og sender deretter en gjenfinningsspørring.

Den eksterne informasjonskilden er ofte en vektordatabase, men kan også være en SQL-database, et web-API, en kunnskapsgraf eller til og med et lager med «rå» dokumenter. Denne tilleggsinformasjonen legges deretter til i LLM-ens inndatakontekst.

Utenom SQL-spørringer og API-er finnes det to hovedtyper gjenfinningsmetoder:

• Leksikalsk søk (nøkkelordsøk): Dette er en enkel form for RAG der nøkkelord hentes ut fra en brukerspørring og matches mot tekstpassasjer som inneholder disse nøkkelordene. I moderne pipeliner kan orkestratoren gjøre dette med det som kalles en glissen vektorspørring (sparse vector query), som ikke fanger opp mening.
• Tett vektorsøk (semantisk søk): Tette vektorinnbygginger fanger opp mening. En orkestrator kan spørre en tett vektordatabase på en måte som gjør at meningen i både brukerprompten og kildeinformasjonen fanges opp.

Bruk av minne er også en viktig del av RAG-arkitektur. Det handler om hvordan en LLM bruker kontekst fra tidligere chatter til å bygge en gjenfinningsspørring, slik at den forankres i den bredere konteksten til en samtale (eller flere samtaler). Samtalebasert RAG er normen for de fleste chatboter, selv om enkelte bruksområder, som svar på supporthenvendelser, kan bruke RAG for enkeltspørsmål.

2. Hybrid

Hybrid RAG kombinerer to ulike typer gjenfinning, vanligvis nøkkelordbasert og semantisk gjenfinning. Nøkkelordsøket finner samsvarende termer, og det vektorbaserte søket finner passasjer med beslektet mening.

Andre former for gjenfinning, som traversering av kunnskapsgrafer eller spørringer mot SQL-databaser, kan også brukes. Prosessen styres ofte av rutinglogikk, enten i form av programmerte regler eller en modells klassifisering av spørsmålet (selv om flere pipeliner også kan kjøre samtidig).

Orkestratoren slår sammen resultatene og kan rangere dem på nytt før de sendes videre til LLM-en. Omrangering er prosessen med å tildele relevanspoeng til innhentede tekstbiter, slik at LLM-en prioriterer den mest relevante informasjonen.

3. Adaptiv RAG

I adaptiv RAG velger en rutingkomponent en gjenfinningsstrategi basert på kravene i brukerprompten, og orkestratoren utfører deretter den valgte arbeidsflyten.

I det opprinnelige rammeverket (Adaptive-RAG) fungerte en mindre modell som klassifikator og valgte mellom ingen gjenfinning, gjenfinning i ett trinn eller gjenfinning i flere trinn. Noen arkitekturer bruker nå generative modeller eller regelbaserte heuristikker i stedet.

Det er en populær arkitektur fordi den fordeler prosessorkraft etter hvor kompleks en prompt er og hvilke krav den stiller, noe som reduserer unødvendige gjenfinningstrinn for enklere prompter. Den er vanlig i assistenter som håndterer flere typer spørsmål.

4. Korrigerende RAG (CRAG)

Korrigerende RAG evaluerer innhentet informasjon før den legges til i LLM-ens kontekstinndata. En gjenfinningsevaluator vurderer om den innhentede informasjonen er relevant og nyttig. Det unike arkitektoniske trekket er det eksplisitte evaluer-og-korriger-trinnet før svaret genereres.

Hvis informasjonen viser seg å være ufullstendig eller ikke relevant for prompten, utløses flere forespørsler. Disse kan bruke andre gjenfinningsmetoder enn den opprinnelige forespørselen, for eksempel nettsøk eller traversering av kunnskapsgrafer.

Korrigerende RAG er vanlig innen fagfelt der nøyaktighet er viktig, som medisin og juss. Det krever imidlertid en ekstra informasjonskilde som kan supplere de opprinnelig innhentede passasjene.

5. Self-RAG

I Self-RAG kan modellen starte forespørsler etter å ha mottatt de første kontekstinndataene. Genererte svar evalueres opp mot det innhentede kildegrunnlaget ved hjelp av refleksjonstokener, og ytterligere forespørsler sendes via orkestratoren ved behov. Omvendt kan LLM-en også avgjøre at det ikke er behov for gjenfinning i det hele tatt.

Den skiller seg fra korrigerende RAG ved at LLM-en vurderer sine egne utdata, avgjør om gjenfinning er nødvendig og om innhentet tekst er nyttig, og overvåker sine egne svar og endrer dem ved behov. Korrigerende RAG vurderer derimot kvaliteten på den innhentede informasjonen før genereringen.

Denne arkitekturen er spesielt nyttig for komplekse prompter i stil med dypgående forskning. Fordi den integrerer vurderinger av relevans (for innhentet informasjon) i svargenereringen, er den et godt valg for prompter som krever evidensbaserte svar.

6. Agentisk RAG

Agentisk RAG viser til enhver form for RAG som utføres på en agentisk plattform. Modellen bruker resonneringsevnene sine til å avgjøre hvilken type informasjon som trengs, og velger blant tilgjengelige gjenfinningsalternativer.

Gjenfinning kan utløses flere ganger ved behov, og modellen kan sette inn agenter for mer komplekse spørringer. En LLM kan for eksempel be om et databaseoppslag for å identifisere en leverandør, utløse et dokumentsøk for å finne relevante kontrakter og avslutte med et nettsøk for å bekrefte kontaktopplysninger ved hjelp av offentlige kilder.

Agentisk RAG er den viktigste arkitekturen i utbredte chatboter som Perplexity, ChatGPT, Claude og lignende. Fordi disse plattformene gir kjernemodellen tilgang til flere verktøy og RAG-pipeliner, kan den velge hvilken form for gjenfinning som passer best til en prompt.

7. Multimodal RAG

Multimodal RAG henter kontekst på tvers av ulike medietyper. Det er en viktig form for RAG fordi den gjør informasjon som ellers ville vært utilgjengelig, som diagrammer og lydopptak, tilgjengelig for LLM-er.

Den underliggende arkitekturen er den samme som i alle andre systemer. En indekseringspipeline kan for eksempel klargjøre bilder for søk ved å konvertere dem direkte til innbygginger. Et agentisk RAG-system kan deretter hente disse bildene sammen med semantisk relevant tekst og sende dem til en visjons- og språkmodell for samlet behandling.

8. GraphRAG

GraphRAG bruker kunnskapsgrafer sammen med vektorsøk for å hente informasjon om entiteter. Vanligvis finner orkestratoren relevante startentiteter, også kalt noder, ved hjelp av nøkkelorduttrekking eller noen ganger et innledende vektorsøk. En grafhenter traverserer deretter en kunnskapsgraf for å bygge opp en bredere kontekst.

Hvis en bruker for eksempel ber om en detaljert gjennomgang av en produktkategori, kan en LLM utløse et vektorsøk for å identifisere bestemte entiteter (produkter). Orkestratoren utløser deretter et søk i kunnskapsgrafen for å finne relaterte entiteter, som leverandører, utsalgssteder, anmeldelser og så videre.

9. Forgrenet RAG

Mens en hybrid RAG-arkitektur kan bruke ulike metoder for gjenfinning, viser forgrenet RAG til prosessen med å kjøre flere spørringer, kalt grener, samtidig. Hver gren kan spørre en egen informasjonskilde, eller grenene kan spørre samme kilde parallelt med ulike spørringer eller filtre. Agentisk RAG-arkitektur bruker ofte forgrenet RAG.

10. HyDE (Hypothetical Document Embeddings)

HyDE er en innovativ form for RAG der en LLM lager et hypotetisk tekstdokument som viser hvordan et optimalt svar kan se ut. Dette «hypotetiske dokumentet» brukes deretter til å lage en spørring som gir mer presis gjenfinning. Selv om relevant kunnskap ikke er representert i LLM-ens parametere, er tanken at en svarlignende passasje kan samsvare bedre med relevante dokumenter enn et kort spørsmål eller en tvetydig prompt.

Eksempel på enkel RAG-arkitektur: Vektordatabase

Grunnleggende RAG danner grunnlaget for mer komplekse typer arkitektur. I et enkelt RAG-system som bruker en vektordatabase, deles kildedokumentasjonen opp i mindre biter (chunks) og konverteres til tette innbygginger. Når en bruker skriver inn en prompt, genererer orkestratoren en spørring, koder den og spør databasen for å finne relevante passasjer.

Her er en trinnvis gjennomgang av prosessen:

1. Store mengder tekst konverteres til vektorer ved hjelp av en automatisert inntakspipeline og en innbyggingsmodell som BERT.
2. Databaseapplikasjonen organiserer, indekserer og lagrer vektorene for raskt søk.
3. Brukeren skriver inn en prompt i en chatbot (for eksempel Perplexity).
4. Applikasjonens orkestrator koder prompten (ved hjelp av en innbyggingsmodell) for å hente relevant informasjon fra vektordatabasen.
5. Vektordatabasen returnerer relevante tekstbiter, og orkestratoren legger disse til i inndatakonteksten (den «store prompten») og sender den til LLM-en.
6. LLM-en bruker den ekstra konteksten til å generere et svar ved hjelp av sin interne kunnskap (lagret i de parametriske vektene).

Forstørr

Eksempel på avansert RAG-arkitektur: Agentisk RAG

Agentisk RAG viser til den underliggende arkitekturen i RAG-systemer på en agentisk plattform. Agentiske RAG-flyter er ofte komplekse fordi KI-agenter kan påkalle ulike verktøy og pipeliner avhengig av hva slags prompt det er, og sette inn flere agenter ved behov.

Her er et praktisk eksempel på prosessen:

1. En bruker skriver inn et komplekst spørsmål som krever dypgående forskning om et tema. I dette eksemplet sier vi at prompten er «Gi en prognose for selskapets inntjening de neste seks månedene i lys av store geopolitiske hendelser».
2. LLM-en resonnerer seg frem til at det trengs en kombinasjon av RAG-spørringer på tvers av ulike innholdstyper.
3. Tre ulike agenter settes inn for (a) vektorsøk, (b) nettforankring og (c) bildesøk (multimodalt).
4. Agentene søker etter relevant informasjon, som nyhetssaker og interne finansdata, via orkestratoren ved hjelp av tilgjengelige gjenfinningsverktøy.
5. LLM-en sammenligner de innhentede resultatene med hver agents forskningsspørsmål og rangerer dem etter relevans.
6. LLM-en evaluerer informasjonen og utløser flere søk via enkeltagenter der det mangler informasjon.
7. Når nok informasjon er hentet inn, genererer LLM-en scenarioprognoser basert på eksisterende finanstall (hentet fra intern dokumentasjon) og kaller et kalkulatorverktøy for å beregne forventet inntjening for hvert scenario.
8. LLM-en genererer et endelig svar ved hjelp av innhentet informasjon og beregninger, og oppgir kilder der det er nødvendig.

Forstørr

Hva blir det neste for RAG?

Dagens innovasjoner handler om å gi eksisterende RAG-arkitekturer mer dybde og fart, forbedre nøyaktigheten i gjenfinning av multimedieinnhold og bygge systemer som er laget for å håndtere informasjon som oppdateres fortløpende.

Her er tre trender som for tiden former retningen på forskningen:

• Dypgående forskning på tvers av flere kilder: Dette er RAG-arkitektur som kan planlegge søk, kjøre flere grener på tvers av ulike kilder, evaluere innhentet kildegrunnlag og selvoptimalisere genererte svar. Agentisk RAG som kan utføre alle disse oppgavene, blir stadig raskere og mer kostnadseffektiv.
• Multimodale bruksområder: Gjenfinningspipeliner blir stadig bedre til å håndtere bilder og video. De kan i økende grad finne bestemte typer informasjon i komplekse multimodale data, som lange videoer og avanserte diagrammer.
• Forankring av svar i informasjon som stadig endres: LLM-baserte applikasjoner kan hente inndatakontekst fra informasjonskilder i sanntid (som videostrømmer og sensorer). Systemer kan også generere mangefasetterte informasjonsnettverk, for eksempel med GraphRAG, for å tolke disse dataene.

RAG er grunnleggende for hvordan LLM-baserte applikasjoner fungerer. Det gjør det mulig for en rekke ulike brukere, fra vanlige forbrukere til virksomheter i spesialiserte fagfelt, å løse problemer knyttet til hallusinasjoner, ufullstendige treningsdata og manglende tilgang til spesialisert intern kunnskap.

Derfor er RAG-systemer og den underliggende arkitekturen deres blant de mest spennende områdene innen KI-forskning, og blant dem som utvikler seg raskest.