Vad är RAG-arkitektur? En fullständig definition med detaljerade praktiska exempel

RAG, som står för retrieval augmented generation (hämtningsförstärkt generering), är en process där LLM:er använder extern information för att bygga ut och förbättra sina utdata. RAG-arkitektur är den uppsättning komponenter och kopplingar som gör RAG möjligt.

Det finns flera olika kategorier av RAG, och var och en bygger på sin egen unika arkitektur. I grund och botten avgör arkitekturen i ett RAG-system det unika sätt på vilket information lagras, hämtas och matas in i en LLM.

Vad är RAG-arkitektur?

RAG-arkitektur är den underliggande konfigurationen av komponenter (och deras tillhörande funktioner) som driver ett visst RAG-system. Alla dessa arkitekturer bygger på en grundläggande mall, som ofta kallas ”enkel” eller ”naiv” RAG.

Här är en övergripande genomgång av grundläggande RAG-arkitektur:

• Informationskälla: Här lagras den externa informationen. Det kan vara ett sökindex, en vektordatabas som representerar stora mängder information eller ett arkiv med råa dokument.
• Hämtningskomponent: Det här är den mekanism som används för att ställa frågor till informationskällan. Ett RAG-system kan till exempel använda en enkel nyckelordssökning för att hitta relevanta textstycken, eller mer komplexa vektorfrågor för att utföra en likhetssökning.
• Orkestreringskomponent: Det här lagret är den del av den LLM-baserade applikationen som startar RAG-pipelinen för en användarprompt, antingen tillsammans med LLM:en eller självständigt. Den sammanställer också den hämtade informationen till en utökad prompt.

Komponenterna i en RAG-arkitektur är vanligtvis organiserade i två vägar. Inmatningsvägen tar emot data och organiserar dem till en sökbar informationskälla. Vektordatabaser, där stora mängder text omvandlas till ett sökbart arkiv av vektorinbäddningar, är en av de mest använda tillämpningarna.

Hämtningsvägen tar en användares prompt och genererar en fråga som används för att söka i informationskällan. Orkestreraren lägger sedan till den hämtade informationen i kontextindata för LLM:en. I agentiska och hybrida RAG-arkitekturer kan det finnas flera hämtningsvägar.

Typer av RAG-arkitektur

Det är missvisande att se RAG som helt åtskilda arkitekturer. De flesta ingenjörer har ett modulärt angreppssätt och implementerar separata komponenter för specifika användningsfall. Även om det går att dra lösa gränser är det viktigt att notera att arkitekturmodellerna överlappar varandra betydligt.

1. Grundläggande RAG

Grundläggande RAG, även kallad ”naiv” eller ”enkel” RAG, är den arkitektoniska mallen för andra typer av RAG.

Den underliggande processen är relativt okomplicerad: en användare skriver en prompt, orkestreraren avgör om extern information behövs (antingen självständigt eller tillsammans med LLM:en) och formulerar och skickar sedan en hämtningsfråga utifrån det.

Den externa informationskällan är ofta en vektordatabas, men kan också vara en SQL-databas, ett webb-API, en kunskapsgraf eller till och med ett arkiv med ”råa” dokument. Denna ytterligare information läggs sedan till i LLM:ens indatakontext.

Utöver SQL-frågor och API:er finns det två huvudtyper av hämtningsmetoder:

• Lexikal sökning (nyckelordssökning): Detta är en enkel form av RAG där nyckelord extraheras från en användarfråga och matchas mot textavsnitt som innehåller dessa nyckelord. I moderna pipelines kan orkestreraren göra detta med en så kallad gles vektorfråga (sparse vector query), som inte fångar betydelse.
• Tät vektorsökning (semantisk sökning): Täta vektorinbäddningar fångar betydelse. En orkestrerare kan ställa frågor till en tät vektordatabas på ett sätt som gör att betydelsen i både användarprompten och källinformationen kan fångas.

Användningen av minne är också en viktig del av RAG-arkitekturen. Det handlar om hur en LLM använder kontext från tidigare chattar för att bygga en hämtningsfråga och därmed förankra den i det bredare sammanhanget för en diskussion (eller flera diskussioner). Konversationell RAG är normen för de flesta chattbottar, även om vissa användningsfall, till exempel svar på supportärenden, kan använda RAG för enskilda frågor.

2. Hybrid

Hybrid RAG kombinerar två olika typer av hämtning, vanligtvis nyckelordsbaserad och semantisk hämtning. Nyckelordssökningen hittar matchande termer och den vektorbaserade sökningen hittar avsnitt med besläktad betydelse.

Andra former av hämtning, till exempel genomgång av kunskapsgrafer eller frågor mot SQL-databaser, kan också användas. Processen styrs ofta av routningslogik, antingen i form av programmerade regler eller en modells klassificering av frågan (även om flera pipelines också kan köras samtidigt).

Orkestreraren slår samman resultaten och kan rangordna om dem innan de skickas vidare till LLM:en. Omrangordning (reranking) är processen att tilldela hämtade textstycken relevanspoäng så att LLM:en prioriterar den mest tillämpliga informationen.

3. Adaptiv RAG

I adaptiv RAG väljer en routningskomponent en hämtningsstrategi utifrån kraven i användarens prompt, och orkestreraren utför sedan det valda arbetsflödet.

I det ursprungliga ramverket (Adaptive-RAG) fungerade en mindre modell som klassificerare och valde mellan ingen hämtning, hämtning i ett steg eller hämtning i flera steg. Vissa arkitekturer använder nu i stället generativa modeller eller regelbaserade heuristiker.

Det är en populär arkitektur eftersom den fördelar beräkningskraft utifrån en prompts komplexitet och krav, vilket minskar onödiga hämtningssteg för enklare prompter. Den är vanlig i assistenter som hanterar flera typer av frågor.

4. Korrigerande RAG (CRAG)

Korrigerande RAG utvärderar hämtad information innan den läggs till i LLM:ens kontextindata. En hämtningsutvärderare bedömer om den hämtade informationen är relevant och användbar. Det unika arkitektoniska draget är det uttryckliga steget för utvärdering och korrigering före svarsgenereringen.

Om informationen visar sig vara ofullständig eller inte tillämplig på prompten utlöses ytterligare förfrågningar. Dessa kan omfatta andra hämtningsmetoder än de som användes för den ursprungliga förfrågan, till exempel webbsökning eller genomgång av kunskapsgrafer.

Korrigerande RAG är vanligt inom områden där noggrannhet är viktig, till exempel medicin och juridik. Det kräver dock en ytterligare informationskälla som kan komplettera de ursprungligen hämtade avsnitten.

5. Self-RAG

I self-RAG kan modellen initiera förfrågningar efter att ha fått den inledande kontexten som indata. Genererade svar utvärderas mot hämtade belägg med hjälp av reflektionstoken, och ytterligare förfrågningar skickas via orkestreraren vid behov. Omvänt kan LLM:en avgöra att ingen hämtning behövs alls.

Det skiljer sig från korrigerande RAG genom att LLM:en bedömer sina egna utdata, avgör om hämtning behövs och om hämtad text är användbar samt övervakar sina egna svar och ändrar dem vid behov. Korrigerande RAG utvärderar å andra sidan kvaliteten på den hämtade informationen före genereringen.

Den här arkitekturen är särskilt användbar för komplexa prompter i stil med djupgående forskning. Eftersom den integrerar relevansbedömningar (av hämtad information) i svarsgenereringen är den ett bra alternativ för prompter som kräver evidensbaserade svar.

6. Agentisk RAG

Agentisk RAG avser alla former av RAG som körs inom ramen för en agentisk plattform. Modellen använder sin resonemangsförmåga för att avgöra vilken typ av information som behövs och väljer bland tillgängliga hämtningsalternativ.

Hämtning kan utlösas flera gånger efter behov, och modellen kan tilldela agenter för mer komplexa frågor. En LLM kan till exempel begära en databasuppslagning för att identifiera en leverantör, utlösa en dokumentsökning för att hitta relevanta avtal och avsluta med en webbsökning för att verifiera kontaktuppgifter med hjälp av offentliga källor.

Agentisk RAG är den främsta arkitekturimplementeringen i populära chattbottar som Perplexity, ChatGPT, Claude med flera. Eftersom dessa plattformar ger kärnmodellen tillgång till flera verktyg och RAG-pipelines kan den välja vilken form av hämtning som passar bäst för en prompt.

7. Multimodal RAG

Multimodal RAG hämtar kontext från olika typer av medier. Det är en viktig form av RAG eftersom den gör information som annars skulle vara otillgänglig, till exempel diagram och ljudinspelningar, tillgänglig för LLM:er.

Den underliggande arkitekturen är densamma som i alla andra system. En indexeringspipeline kan till exempel förbereda bilder för sökning genom att omvandla dem till direkta inbäddningar. Ett agentiskt RAG-system kan sedan hämta dessa bilder tillsammans med semantiskt relevant text och mata in dem i en vision-språkmodell för kombinerad bearbetning.

8. GraphRAG

GraphRAG använder kunskapsgrafer tillsammans med vektorsökning för att hämta information om entiteter. Vanligtvis hittar orkestreraren relevanta startentiteter, även kallade noder, med hjälp av nyckelordsextrahering eller ibland en preliminär vektorsökning. En grafhämtare traverserar en kunskapsgraf för att bygga upp en bredare kontext.

Som svar på en begäran om en detaljerad genomgång av en produktkategori kan en LLM till exempel utlösa en vektorsökning för att identifiera specifika entiteter (produkter). Orkestreraren utlöser sedan en sökning i kunskapsgrafen för att hitta relaterade entiteter, till exempel leverantörer, butiker, recensioner och så vidare.

9. Förgrenad RAG

Medan en hybrid RAG-arkitektur kan använda olika metoder för hämtning avser förgrenad RAG processen att köra flera frågor, så kallade grenar, samtidigt. Varje gren kan ställa frågor till en separat informationskälla, eller så kan grenarna parallellt ställa olika frågor eller använda olika filter mot samma källa. Agentisk RAG-arkitektur använder ofta förgrenad RAG.

10. HyDE (Hypothetical Document Embeddings)

HyDE är en innovativ form av RAG där en LLM skapar ett hypotetiskt textdokument som visar hur ett optimalt svar skulle kunna se ut. Detta ”hypotetiska dokument” används sedan för att skapa en fråga som ger mer träffsäker hämtning. Även om relevant kunskap inte finns representerad i LLM:ens parametrar är tanken att ett svarsliknande avsnitt kan matcha relevanta dokument bättre än en kort fråga eller en tvetydig prompt.

Exempel på enkel RAG-arkitektur: vektordatabas

Grundläggande RAG utgör grunden för mer komplexa typer av arkitektur. I ett enkelt RAG-system som använder en vektordatabas delas källdokumentationen upp i mindre delar (chunks) och omvandlas till täta inbäddningar. När en användare skriver en prompt genererar orkestreraren en fråga, kodar den och söker i databasen efter relevanta avsnitt.

Här är en steg-för-steg-genomgång av processen:

1. Stora mängder text omvandlas till vektorer med hjälp av en automatiserad inmatningspipeline och en inbäddningsmodell som BERT.
2. Databasapplikationen organiserar, indexerar och lagrar vektorerna för snabb sökning.
3. Användaren skriver en prompt i en chattbot (till exempel Perplexity).
4. Applikationens orkestrerare kodar prompten (med hjälp av en inbäddningsmodell) för att hämta relevant information från vektordatabasen.
5. Vektordatabasen returnerar relevanta textstycken, och orkestreraren lägger till dem i indatakontexten (den ”stora prompten”) och matar in den i LLM:en.
6. LLM:en använder den ytterligare kontexten för att generera ett svar med hjälp av sin interna kunskap (lagrad i dess parametriska vikter).

Förstora

Exempel på avancerad RAG-arkitektur: agentisk RAG

Agentisk RAG avser den underliggande arkitekturen för RAG-system inom en agentisk plattform. Agentiska RAG-flöden tenderar att vara komplexa eftersom AI-agenter kan anropa olika verktyg och pipelines beroende på promptens karaktär och vid behov sätta in flera agenter.

Här är ett praktiskt exempel på processen:

1. En användare skriver en komplex fråga som kräver djupgående forskning om ett ämne. I det här exemplet antar vi att prompten är ”Ta fram en prognos för företagets resultat under de kommande sex månaderna mot bakgrund av större geopolitiska händelser.”
2. LLM:en resonerar sig fram till att det krävs en kombination av RAG-frågor över olika innehållstyper.
3. Tre olika agenter sätts in för (a) vektorsökning, (b) webbförankring och (c) bildsökning (multimodal).
4. Agenterna söker efter relevant information, till exempel nyhetsartiklar och interna finansiella data, via orkestreraren med hjälp av tillgängliga hämtningsverktyg.
5. LLM:en jämför de hämtade resultaten med varje agents forskningsfråga och rangordnar dem efter relevans.
6. LLM:en utvärderar informationen och utlöser ytterligare sökningar via enskilda agenter där information saknas.
7. När tillräckligt med information har hämtats genererar LLM:en scenarioprognoser baserade på befintliga finansiella siffror (hämtade från intern dokumentation) och anropar ett kalkylatorverktyg för att beräkna det förväntade resultatet för varje scenario.
8. LLM:en genererar ett slutligt svar utifrån den hämtade informationen och beräkningarna och anger källor vid behov.

Förstora

Vad händer härnäst med RAG?

Aktuella innovationer handlar om att ge dagens RAG-arkitekturer större djup och hastighet, förbättra noggrannheten i multimediahämtning och bygga system som är utformade för att hantera information i realtid.

Här är tre trender som just nu formar forskningens inriktning:

• Djupgående forskning över flera källor: Det här är RAG-arkitektur som kan planera sökningar, köra flera grenar över skilda källor, utvärdera hämtade belägg och självoptimera genererade svar. Agentisk RAG som kan utföra alla dessa uppgifter blir allt snabbare och mer kostnadseffektiv.
• Multimodala tillämpningar: Hämtningspipelines blir allt bättre på att hantera bilder och video. De kan i allt högre grad hitta specifika typer av information i komplexa multimodala data, till exempel långa videor och avancerade diagram.
• Förankra svar i ständigt föränderlig information: LLM-baserade applikationer kan använda informationskällor i realtid (till exempel videoflöden och sensorer) som indatakontext. System kan också skapa mångfacetterade informationsnätverk, till exempel med GraphRAG, för att tolka dessa data.

RAG är grundläggande för hur LLM-baserade applikationer fungerar. Det gör det möjligt för en mängd olika användare, från vanliga konsumenter till företag inom specialiserade områden, att komma till rätta med problem som hallucinationer, ofullständiga träningsdata och bristande tillgång till specialiserad intern kunskap.

Därför är RAG-system och deras underliggande arkitektur ett av de snabbast växande och mest spännande områdena inom AI-forskningen.