Wat is RAG-architectuur? Een volledige definitie met gedetailleerde praktijkvoorbeelden

RAG, wat staat voor retrieval-augmented generation, is een proces waarbij LLM’s externe informatie gebruiken om hun output uit te breiden en te verbeteren. De architectuur van RAG is het geheel van componenten en verbindingen dat RAG mogelijk maakt.

Er bestaan verschillende categorieën RAG, en elk daarvan draait op een eigen, unieke architectuur. In wezen bepaalt de architectuur van een RAG-systeem op welke specifieke manier informatie wordt opgeslagen, opgehaald en aan een LLM wordt aangeleverd.

Wat is RAG-architectuur?

RAG-architectuur is de onderliggende configuratie van componenten (en de bijbehorende mogelijkheden) die een bepaald RAG-systeem aandrijft. Al deze architecturen bouwen voort op een basissjabloon, dat vaak “eenvoudige” of “naïeve” RAG wordt genoemd.

Hier volgt een globaal overzicht van de basisarchitectuur van RAG:

• Informatiebron: Hier wordt de externe informatie opgeslagen. Dat kan een zoekindex zijn, een vectordatabase die grote hoeveelheden informatie representeert, of een opslagplaats met ruwe documenten.
• Ophaalcomponent: Dit is het mechanisme waarmee de informatiebron wordt bevraagd. Een RAG-systeem kan bijvoorbeeld een eenvoudige zoekopdracht op trefwoorden gebruiken om relevante tekstfragmenten te vinden, of complexere vectorquery’s om op gelijkenis te zoeken.
• Orkestratiecomponent: Deze laag is het deel van de LLM-gebaseerde applicatie dat de RAG-pipeline voor een gebruikersprompt in gang zet, samen met het LLM of zelfstandig. Ook voegt deze laag de opgehaalde informatie samen tot een uitgebreide prompt.

De componenten van een RAG-architectuur zijn doorgaans georganiseerd in twee paden. Het ingestiepad neemt data op en organiseert die tot een doorzoekbare informatiebron. Vectordatabases, waarin grote hoeveelheden tekst worden omgezet in een doorzoekbare verzameling vector-embeddings, zijn een van de meest gebruikte toepassingen.

Het ophaalpad neemt de prompt van een gebruiker en genereert daaruit een query om de informatiebron te doorzoeken. De orchestrator voegt de opgehaalde informatie vervolgens toe aan de contextinput voor het LLM. Bij agentische en hybride RAG-architecturen kunnen er meerdere ophaalpaden zijn.

Soorten RAG-architectuur

Het is misleidend om RAG te zien als een reeks volledig afzonderlijke architecturen. De meeste engineers kiezen voor een modulaire aanpak, waarbij ze afzonderlijke componenten implementeren die aansluiten op specifieke use cases. Hoewel je globale grenzen kunt trekken, is het belangrijk om op te merken dat de verschillende architectuurmodellen elkaar sterk overlappen.

1. Basis-RAG

Basis-RAG, ook wel “naïeve” of “eenvoudige” RAG genoemd, is het architectuursjabloon voor andere soorten RAG.

Het onderliggende proces is relatief eenvoudig: een gebruiker voert een prompt in, de orchestrator bepaalt (zelfstandig of samen met het LLM) of er externe informatie nodig is, en stelt op basis daarvan een ophaalquery op en verstuurt die.

De externe informatiebron is meestal een vectordatabase, maar kan ook een SQL-database, een web-API, een kennisgraaf of zelfs een “ruwe” documentopslag zijn. Deze aanvullende informatie wordt vervolgens toegevoegd aan de inputcontext van het LLM.

Naast SQL-query’s en API’s zijn er twee brede categorieën ophaalmethoden:

• Lexicaal zoeken (zoeken op trefwoorden): Dit is een eenvoudige vorm van RAG waarbij trefwoorden uit een gebruikersquery worden gehaald en worden vergeleken met tekstpassages die deze trefwoorden bevatten. In moderne pipelines kan de orchestrator hiervoor een zogeheten sparse-vectorquery uitvoeren, die geen betekenis vastlegt.
• Zoeken met dense vectoren (semantisch zoeken): Dense vector-embeddings leggen betekenis vast. Een orchestrator kan een database met dense vectoren zo bevragen dat de betekenis van zowel de gebruikersprompt als de broninformatie wordt meegenomen.

Ook het gebruik van geheugen is een belangrijk onderdeel van RAG-architectuur. Dit verwijst naar de manier waarop een LLM context uit eerdere chats gebruikt om een ophaalquery op te bouwen, zodat die is verankerd in de bredere context van een gesprek (of meerdere gesprekken). Conversationele RAG is de norm voor de meeste chatbots, al kan voor sommige use cases, zoals het beantwoorden van supporttickets, RAG op basis van één vraag worden gebruikt.

2. Hybride

Hybride RAG combineert twee verschillende ophaalmethoden, meestal ophalen op basis van trefwoorden en semantisch ophalen. De zoekopdracht op trefwoorden vindt overeenkomende termen, en de vectorgebaseerde zoekopdracht vindt passages met een verwante betekenis.

Er kunnen ook andere vormen van ophalen worden gebruikt, zoals het doorlopen van een kennisgraaf of query’s op SQL-databases. Het proces wordt vaak gestuurd door routeringslogica, in de vorm van geprogrammeerde regels of een classificatie van de vraag door een model (al kunnen er ook meerdere pipelines tegelijk draaien).

De orchestrator voegt de resultaten samen en kan ze herrangschikken voordat ze naar het LLM gaan. Herrangschikken (reranking) is het proces waarbij relevantiescores worden toegekend aan opgehaalde fragmenten, zodat het LLM voorrang geeft aan de meest toepasselijke informatie.

3. Adaptieve RAG

Bij adaptieve RAG selecteert een routeringscomponent een ophaalstrategie op basis van de vereisten van de gebruikersprompt, waarna de orchestrator de geselecteerde workflow uitvoert.

In het oorspronkelijke framework (Adaptive-RAG) fungeerde een kleiner model als classificator die koos tussen geen ophalen, ophalen in één stap of ophalen in meerdere stappen. Sommige architecturen gebruiken tegenwoordig in plaats daarvan generatieve modellen of op regels gebaseerde heuristieken.

Dit is een populaire architectuur, omdat deze rekenkracht toewijst op basis van de complexiteit en vereisten van een prompt, waardoor onnodige ophaalstappen bij eenvoudigere prompts worden vermeden. Ze komt veel voor in assistenten die met verschillende soorten vragen te maken hebben.

4. Corrigerende RAG (CRAG)

Corrigerende RAG evalueert opgehaalde informatie voordat die aan de contextinput van het LLM wordt toegevoegd. Een ophaalevaluator beoordeelt of de opgehaalde informatie relevant en bruikbaar is. Het unieke architectuurkenmerk is de expliciete fase van evalueren en corrigeren vóór het genereren van het antwoord.

Als blijkt dat informatie onvolledig is of niet van toepassing is op de prompt, worden aanvullende verzoeken geactiveerd. Daarbij kunnen andere ophaalmethoden worden ingezet dan bij het oorspronkelijke verzoek, zoals zoeken op het web of het doorlopen van een kennisgraaf.

Corrigerende RAG komt veel voor in vakgebieden waar nauwkeurigheid belangrijk is, zoals geneeskunde en recht. Deze aanpak vereist echter wel een extra informatiebron die de oorspronkelijk opgehaalde passages kan aanvullen.

5. Self-RAG

Bij self-RAG kan het model zelf verzoeken starten nadat het de initiële contextinput heeft ontvangen. Gegenereerde antwoorden worden met behulp van reflectietokens getoetst aan opgehaald bewijs, en waar nodig worden via de orchestrator aanvullende verzoeken verstuurd. Omgekeerd kan het LLM ook besluiten dat ophalen helemaal niet nodig is.

Het verschil met corrigerende RAG is dat het LLM zijn eigen output beoordeelt, bepaalt of ophalen nodig is en of de opgehaalde tekst bruikbaar is, en zijn eigen antwoorden bewaakt en waar nodig aanpast. Corrigerende RAG beoordeelt daarentegen de kwaliteit van de opgehaalde informatie vóór het genereren.

Deze architectuur is vooral nuttig voor complexe prompts in de stijl van diepgaand onderzoek. Omdat ze beoordelingen van de relevantie (van opgehaalde informatie) integreert in het genereren van antwoorden, is ze een goede optie voor prompts die op bewijs gebaseerde antwoorden vereisen.

6. Agentische RAG

Agentische RAG verwijst naar elke vorm van RAG die wordt uitgevoerd binnen een agentisch platform. Het model gebruikt zijn redeneervermogen om te bepalen welk type informatie nodig is en kiest uit de beschikbare ophaalopties.

Ophalen kan zo vaak als nodig worden geactiveerd, en het model kan agents inzetten voor complexere query’s. Een LLM kan bijvoorbeeld een zoekactie in een database aanvragen om een leverancier te identificeren, een zoekopdracht in documenten starten om relevante contracten te vinden en afsluiten met een zoekopdracht op het web om contactgegevens te verifiëren aan de hand van openbare bronnen.

Agentische RAG is de belangrijkste architectuur in gangbare chatbots zoals Perplexity, ChatGPT, Claude enzovoort. Omdat deze platforms het kernmodel toegang geven tot meerdere tools en RAG-pipelines, kan het model kiezen welke vorm van ophalen het best bij een prompt past.

7. Multimodale RAG

Multimodale RAG haalt context op uit verschillende soorten media. Het is een belangrijke vorm van RAG, omdat ze informatie die anders ontoegankelijk zou blijven, zoals grafieken en audio-opnamen, beschikbaar maakt voor LLM’s.

De onderliggende architectuur is dezelfde als in elk ander systeem. Een indexeringspipeline kan bijvoorbeeld afbeeldingen doorzoekbaar maken door ze om te zetten in directe embeddings. Een agentisch RAG-systeem kan deze afbeeldingen vervolgens samen met semantisch relevante tekst ophalen en aan een vision-languagemodel aanbieden voor gecombineerde verwerking.

8. GraphRAG

GraphRAG gebruikt kennisgrafen naast vectorzoekopdrachten om informatie over entiteiten op te halen. Doorgaans vindt de orchestrator relevante startentiteiten, ook wel knooppunten (nodes) genoemd, via trefwoordextractie of soms een voorafgaande vectorzoekopdracht. Een graaf-retriever doorloopt vervolgens een kennisgraaf om een bredere context op te bouwen.

Bij een verzoek om een gedetailleerd overzicht van een productcategorie kan een LLM bijvoorbeeld een vectorzoekopdracht starten om specifieke entiteiten (producten) te identificeren. De orchestrator start daarna een zoekopdracht in de kennisgraaf om verwante entiteiten te vinden, zoals leveranciers, verkooplocaties, reviews enzovoort.

9. Vertakte RAG

Waar een hybride RAG-architectuur verschillende methoden voor ophalen kan gebruiken, verwijst vertakte RAG naar het tegelijkertijd uitvoeren van meerdere query’s, die takken (branches) worden genoemd. Elke tak kan een afzonderlijke informatiebron bevragen, of de takken kunnen dezelfde bron parallel bevragen met verschillende query’s of filters. Agentische RAG-architectuur maakt vaak gebruik van vertakte RAG.

10. HyDE (Hypothetical Document Embeddings)

HyDE is een innovatieve vorm van RAG waarbij een LLM een hypothetisch tekstdocument opstelt van hoe een optimaal antwoord eruit zou kunnen zien. Dit “hypothetische document” wordt vervolgens gebruikt om een query op te stellen die nauwkeuriger ophalen mogelijk maakt. Hoewel relevante kennis niet in de parameters van het LLM is vastgelegd, is de gedachte dat een passage die op een antwoord lijkt beter overeenkomt met relevante documenten dan een korte vraag of een dubbelzinnige prompt.

Voorbeeld van een eenvoudige RAG-architectuur: vectordatabase

Basis-RAG vormt het fundament voor complexere soorten architectuur. Bij een eenvoudig RAG-systeem met een vectordatabase wordt de brondocumentatie opgesplitst in kleinere stukken (chunks) en omgezet in dense embeddings. Wanneer een gebruiker een prompt invoert, genereert de orchestrator een query, codeert die en bevraagt de database om relevante passages te vinden.

Hier volgt het proces stap voor stap:

1. Grote hoeveelheden tekst worden met een geautomatiseerde ingestiepipeline en een embeddingmodel zoals BERT omgezet in vectoren.
2. De databaseapplicatie organiseert, indexeert en slaat de vectoren op, zodat er snel kan worden gezocht.
3. De gebruiker voert een prompt in een chatbot in (zoals Perplexity).
4. De orchestrator van de applicatie codeert de prompt (met een embeddingmodel) om relevante informatie uit de vectordatabase op te halen.
5. De vectordatabase retourneert relevante fragmenten, waarna de orchestrator deze toevoegt aan de inputcontext (de “grote prompt”) en die aan het LLM aanbiedt.
6. Het LLM gebruikt de aanvullende context om een antwoord te genereren met behulp van zijn interne kennis (opgeslagen in zijn parametrische gewichten).

Vergroten

Voorbeeld van een geavanceerde RAG-architectuur: agentische RAG

Agentische RAG verwijst naar de onderliggende architectuur van RAG-systemen binnen een agentisch platform. Agentische RAG-flows zijn vaak complex, omdat AI-agents afhankelijk van de aard van een prompt verschillende tools en pipelines kunnen aanroepen en zo nodig meerdere agents kunnen inzetten.

Hier is een praktijkvoorbeeld van het proces:

1. Een gebruiker stelt een complexe vraag die diepgaand onderzoek naar een onderwerp vereist. Stel dat de prompt in dit voorbeeld luidt: “Geef een prognose van de bedrijfswinst voor de komende zes maanden in het licht van belangrijke geopolitieke ontwikkelingen.”
2. Het LLM redeneert dat er een combinatie van RAG-query’s over verschillende contenttypen nodig zal zijn.
3. Er worden drie verschillende agents ingezet voor (a) vectorzoekopdrachten, (b) grounding via het web en (c) zoeken in afbeeldingen (multimodaal).
4. De agents zoeken via de orchestrator met de beschikbare ophaaltools naar relevante informatie, zoals nieuwsberichten en interne financiële gegevens.
5. Het LLM vergelijkt de opgehaalde resultaten met de onderzoeksvraag van elke agent en rangschikt ze op relevantie.
6. Het LLM evalueert de informatie en start via afzonderlijke agents aanvullende zoekopdrachten waar informatie ontbreekt.
7. Zodra er voldoende informatie is opgehaald, genereert het LLM scenarioprognoses op basis van bestaande financiële cijfers (opgehaald uit interne documentatie) en roept het een rekenmachinetool aan om voor elk scenario de winst te voorspellen.
8. Het LLM genereert een definitief antwoord op basis van de opgehaalde informatie en berekeningen, en vermeldt waar nodig de bronnen.

Vergroten

Wat brengt de toekomst voor RAG?

De huidige innovaties draaien om meer diepgang en snelheid in bestaande RAG-architecturen, nauwkeuriger ophalen van multimedia en systemen die zijn ontworpen om te werken met informatie die tot op de minuut actueel is.

Dit zijn drie trends die momenteel de richting van het onderzoek bepalen:

• Diepgaand onderzoek in meerdere bronnen: Dit is RAG-architectuur die zoekopdrachten kan plannen, meerdere takken over uiteenlopende bronnen kan uitvoeren, opgehaald bewijs kan evalueren en gegenereerde antwoorden zelf kan optimaliseren. Agentische RAG die al deze taken kan uitvoeren, wordt steeds sneller en kosteneffectiever.
• Multimodale toepassingen: Ophaalpipelines kunnen steeds beter overweg met afbeeldingen en video. Ze kunnen in toenemende mate specifieke soorten informatie lokaliseren in complexe multimodale data, zoals lange video’s en geavanceerde diagrammen.
• Antwoorden verankeren in voortdurend veranderende informatie: LLM-gebaseerde applicaties kunnen gebruikmaken van live informatiebronnen (zoals videofeeds en sensoren) om inputcontext te leveren. Systemen kunnen ook veelzijdige informatienetwerken genereren, bijvoorbeeld met GraphRAG, om deze data te interpreteren.

RAG is fundamenteel voor de werking van LLM-gebaseerde applicaties. Dankzij RAG kunnen allerlei gebruikers, van gewone consumenten tot bedrijven in gespecialiseerde sectoren, problemen overwinnen die samenhangen met hallucinaties, onvolledige trainingsdata en een gebrek aan toegang tot gespecialiseerde interne kennis.

Daarom behoren RAG-systemen en hun onderliggende architectuur tot de snelst evoluerende en meest spannende gebieden binnen AI-onderzoek.