RAG vs. LLM: technische uitleg (definities, verschillen, gebruiksscenario's)

LLM's genereren reacties met parameters die zijn geleerd uit patronen in hun trainingsdata. Omdat die parameters mogelijk geen recente of volledige informatie weerspiegelen, vult RAG, wat staat voor retrieval-augmented generation, het proces aan door data uit externe bronnen toe te voegen aan de invoercontext van de LLM. Een AI-tool haalt informatie van buiten op om het genereren-proces van de LLM aan te vullen.

In werkelijkheid kies je niet tussen RAG of een LLM. Het gaat om de keuze tussen een hybride aanpak en een aanpak die alleen een LLM gebruikt.

RAG is nodig wanneer een LLM toegang nodig heeft tot bedrijfsdocumentatie, databases of snel veranderende informatie. Een aanpak zonder LLM is geschikt voor bepaalde administratieve, dataverwerking- en contentcreatietaken waarbij alle invoer door de gebruiker kan worden aangeleverd.

RAG vs. LLM: Wat zijn de belangrijkste verschillen?

• RAG en LLM's vullen elkaar aan. Je kunt een AI-model gebruiken zonder RAG (waarbij het uitsluitend vertrouwt op zijn bestaande parameters), maar je kunt geen RAG-systeem gebruiken zonder model.
• RAG is geïntroduceerd om drie kernproblemen met LLM's te overwinnen: verouderde informatie, gehallucineerde antwoorden en een gebrek aan verificatie tegenover bronnen van derden.
• RAG maakt AI in praktijksituaties in het bedrijfsleven veel effectiever, omdat het LLM's verbindt met geverifieerde interne documentatie, databases en API-endpoints.
• Belangrijke RAG-gebruiksscenario's zijn onder meer chatbots voor klantondersteuning, vragen op basis van snel veranderende data (zoals branchenieuws) en gespecialiseerde vakgebieden, zoals geneeskunde en recht, waar nauwkeurigheid en broncontrole belangrijk zijn.
• Er zijn drie hoofdtypen RAG: naive RAG, modular RAG en advanced RAG. Naive RAG kan het best worden gezien als eenvoudige informatieopvraging, terwijl modular en advanced RAG extra functionaliteit toevoegen, zoals het herschrijven van zoekopdrachten en het optimaliseren van chunks.

Wat is een large language model (LLM)?

Een LLM, of large language model, is een systeem dat content genereert met behulp van fijn afgestelde parameters. Deze parameters bepalen de waarschijnlijkheden die worden toegekend aan alle tokens in de woordenschat van een LLM en geven aan welk token in een gegeven reeks het waarschijnlijkst als volgende komt.

Om beter te begrijpen hoe RAG werkt (en verschilt van) LLM's, is het nuttig om op een basisniveau te bekijken hoe generatieve AI werkt:

1. Tokenization: Een prompt van een gebruiker wordt opgesplitst in tokens, die woorden, delen van woorden of afzonderlijke tekens kunnen zijn.
2. Embedding: Tokens worden omgezet in embeddings, numerieke representaties (reeksen cijfers) die vectors worden genoemd, en die het neurale netwerk, inclusief een decoder, kan verwerken.
3. Decoding: De lagen van de decoder (die een groot deel van het neurale netwerk van de LLM vormen) manipuleren deze vectoren en gebruiken daarbij een proces dat attention heet om betekenis vast te leggen. Dit proces bepaalt hoe sterk elk token verband moet houden met andere tokens in de reeks.
4. Waardering: Het model kent aan elk token in zijn bestaande woordenschat een waarschijnlijkheid van compatibiliteit toe en selecteert een waarschijnlijk volgend token voor de reeks.

Het belangrijke punt is dat een LLM alleen uitvoer kan produceren op basis van zijn bestaande parameters en de tokens in zijn contextvenster. Tijdens de training wordt een LLM miljarden keren gevraagd om delen van onvolledige tekst af te maken, en worden de parameters aangepast totdat het tokens betrouwbaar waarschijnlijkheden toekent (en daarmee de tekst aanvult).

Stel je bijvoorbeeld voor dat je een AI-model de vraag stelt: “Wat zegt ons terugbetalingsbeleid voor 2026?” De LLM kan alleen de volgende tokens voorspellen op basis van zijn bestaande parameters, die niet zijn fijn afgesteld met behulp van je ondersteuningsdocumentatie. Als je het deze vraag stelt zonder aanvullende context, kan het simpelweg niet op een zinvolle manier reageren of zal het een onjuist antwoord hallucineren.

Wat is retrieval-augmented generation (RAG)?

RAG (retrieval-augmented generation) is het proces waarbij informatie uit externe systemen wordt opgenomen in een LLM-prompt.

Het onderliggende LLM-proces, waarbij embedding en probabilistische tokenmatching betrokken zijn, blijft hetzelfde. RAG introduceert een voorbereidende stap waarin de gebruikersprompt wordt uitgebreid met extra data.

Hier volgt een overzicht van hoe RAG werkt:

1. Kennisvoorbereiding: Er wordt een kennisbron voorbereid. Dat kan een set documenten zijn, een vector database, een knowledge graph of een live index (zoals voor AI search).
2. Prompting: Een gebruiker voert een prompt in, zoals: “Moet ik vandaag gaan wandelen in Londen?”
3. Retrieval: De externe informatiebron wordt door de retriever van de AI-tool bevraagd. Deze kan de prompt embedden, waardoor die in een vector wordt omgezet, en vervolgens een vector database doorzoeken. Als alternatief kan het een andere methode gebruiken, zoals een API-call, keyword-matching of traversal van een knowledge graph.
4. Invoegen: Deze informatie wordt toegevoegd aan de oorspronkelijke prompt van de gebruiker. In het voorbeeld van de vraag over wandelen in Londen kan dit weersinformatie in Londen en de huidige toegankelijkheid van populaire wandelroutes omvatten.
5. Antwoordgeneratie: De LLM genereert op de gebruikelijke manier een reactie met behulp van de uitgebreide prompt.

Onder de motorkap wordt de opgehaalde tekst toegevoegd aan de invoercontext, getokeniseerd en ge-embed. Het model verwerkt die extra context vervolgens via zijn decoder, wat de waarschijnlijkheden van de uitvoertokens verandert.

In brede zin kan RAG worden opgesplitst in drie subtypen. Naive RAG volgt het basis-RAG-proces door informatie op te halen en die in de prompt te verwerken. Advanced RAG voegt extra functies toe, zoals het herschrijven van zoekopdrachten en meerdere zoekrondes. Modular RAG verwijst naar een type architectuur waarin verschillende geavanceerde functionaliteiten als componenten kunnen worden behandeld en naar behoefte kunnen worden gecombineerd.

RAG vs. LLM: Overzicht van gebruiksscenario's

RAG geeft gebruikers toegang tot actuele data. Daardoor is de kans kleiner dat LLM-uitvoer hallucinaties en informatielacunes bevat. Als je de bronnen van de informatie in een uitvoer wilt zien, is RAG ook essentieel, omdat LLM-antwoorden zonder onderbouwing geen bronvermeldingen bevatten.

Vergroten

RAG-gebruiksscenario's

• Verzoeken om tijdsgevoelige informatie: Alle vragen naar informatie die snel veroudert, of dat nu iets eenvoudigs is zoals een weersverwachting of iets complexs zoals een gedetailleerde analyse van een opkomend nieuwsverhaal, moeten gebaseerd zijn op gevalideerde bronnen van derden.
• Bedrijfsdocumentatie: Interne of klantgerichte AI-chatbots waarbij gebruikers vragen stellen over bedrijfs- of productdocumentatie, moeten RAG-ondersteund zijn, vooral als de documentatie vaak wordt bijgewerkt.
• Klantondersteuning: Chatbots voor klanten hebben toegang nodig tot actuele, gedetailleerde ondersteuningsdocumentatie om nauwkeurige antwoorden te kunnen geven.
• Gespecialiseerde vakgebieden (geneeskunde, recht, financiën, enz.): LLM's die niet zijn getraind op domeinspecifieke corpora (vooral mainstreammodellen) hebben doorgaans moeite met de nuance van gespecialiseerde prompts.

LLM-gebruiksscenario's

• Administratieve taken: LLM's kunnen basistaken uitvoeren met minimale vertraging. RAG is niet nodig voor eenvoudig schrijf- en administratief werk, zoals spellingcontrole of samenvatting, waarbij geen externe informatie vereist is.
• Creatieve taken: Voor sommige creatieve taken, zoals het genereren van een kort verhaal of een afbeelding, is alleen de informatie nodig die in de oorspronkelijke prompt is meegegeven.
• Redenerings- en datagestuurde taken: Als je werkt met een grote dataset, heeft een LLM geen toegang tot externe informatie nodig om redenerings- en analysefuncties toe te passen.
• Algemene codering: Hoewel een coding-workflow toegang kan vereisen tot een private codebase of documentatie, zijn LLM's zeer goed in staat algemene codingtaken uit te voeren, zoals bugs oplossen en functies maken, zonder externe bronnen te raadplegen.

RAG vs. LLM met long-context, agentische AI en grounding

Er zijn drie verwante concepten die relevant zijn voor het onderscheid tussen RAG en LLM's. Dat zijn LLM's met een lang contextvenster, agentische AI en grounding.

LLM's met een lang contextvenster kunnen soms worden gebruikt in plaats van RAG-ondersteunde systemen, terwijl agentische AI en grounding ermee synoniem zijn of ernaast werken.

LLM's met een lang contextvenster

Dit zijn modellen met grote contextvensters, waarbij sommige breed beschikbare commerciële modellen tot wel één miljoen tokens aankunnen.

Als relevante materialen in het contextvenster van een model passen en beschikbaar zijn in een tekstformaat, biedt een aanpak zonder LLM enkele voordelen. Die kan de kans op opvragingsfouten verkleinen, meer volledige context bieden en de noodzaak voor uitgebreide opzet van RAG-architectuur wegnemen.

Agentische AI

Een agent is een systeem dat gebruikmaakt van meerdere tools, waaronder RAG-mogelijkheden, om complexe taken uit te voeren. RAG is één component van agentische AI, en een agent gebruikt vaak verschillende soorten opvraagmethoden (bijv. webzoekopdrachten versus vectorzoekopdrachten), afhankelijk van de inhoud van een prompt.

Grounding

Grounding verwijst naar het bredere proces van het gebruik van bewijs of data om de nauwkeurigheid van een reactie van een LLM te verbeteren, of die reactie te onderbouwen. RAG is één vorm van grounding, maar het toevoegen van een technisch document aan een contextvenster zou ook als grounding gelden.

RAG vs. LLM: Voorbeelden uit de praktijk

Om beter te begrijpen hoe RAG werkt vergeleken met LLM-gebruik zonder RAG, kunnen we kijken naar een eenvoudig praktijkvoorbeeld met Perplexity en een hypothetische enterprise-case waarin een vector database wordt geraadpleegd.

RAG vs. LLM met een eenvoudige prompt

Hier is de uitvoer (beperkt tot twee zinnen) wanneer Perplexity wordt gevraagd: "Moet ik vandaag gaan wandelen in Londen?" met AI-webzoekopdrachten (een vorm van RAG) uitgeschakeld:

Ja — als het weer redelijk droog is en je de tijd hebt, kan een wandeling door Londen vandaag een verfrissende afwisseling zijn. Kies een route langs de South Bank, Regent’s Canal of door Hyde Park, en neem voor de zekerheid een lichte waterdichte jas mee.

Vergelijk dit met de prompt wanneer de LLM externe bronnen kan raadplegen:

Ja, het is een goede dag voor een wandeling in Londen: de verwachting gaat uit van milde temperaturen rond 19–21°C, met zonnige perioden en slechts een zeer kleine kans op regen. Met gedeeltelijk bewolkte luchten en een zachte bries zijn de omstandigheden aangenaam om parken of routes langs de rivier, zoals de South Bank, te verkennen.

Er zijn overeenkomsten tussen de twee, omdat de LLM hetzelfde onderliggende proces voor tokenwaardering gebruikt. Het tweede voorbeeld bevat echter gedetailleerde weersinformatie, waardoor het veel nuttiger is.

RAG vs. LLM met een enterprise vector database

Stel je voor dat een gebruiker een chatbot in een bankapp de volgende vraag stelt: “Waar kan ik mijn meest recente afschrift downloaden?”

De bank die de app beheert, heeft een database gemaakt met embeddings van de up-to-date productdocumentatie en deze gekoppeld aan de RAG-pijplijn van de chatbot. De documentatie bestaat uit ongeveer 1.000 brondocumenten, die zijn opgesplitst in kleinere chunks en omgezet in vectors voor retrieval.

De zoekopdracht van de gebruiker wordt naar een embeddingmodel gestuurd, en de applicatie stuurt die vector naar de database, die de relevante chunks teruggeeft.

Het embeddingmodel zou een verzoek als dit ontvangen:

Het embeddingmodel geeft de volgende vectorembedding terug:

De vector database ontvangt vervolgens een verzoek als het volgende:

In dit (sterk vereenvoudigde) voorbeeld geeft de database de vijf chunks terug die het meest relevant zijn voor de zoekopdracht van de gebruiker; deze worden naar de applicatie gestuurd en opgenomen in de LLM-prompt.

Wanneer kies je voor RAG versus een LLM, en wanneer combineer je ze

LLM's en RAG zijn complementaire systemen. Daarom is de vraag: “Wanneer moet ik kiezen voor een LLM en wanneer voor RAG?” eigenlijk onjuist gesteld. Je moet eerder vragen: “Wanneer volstaat een LLM en wanneer is RAG optimaal?”

Wanneer je een LLM zonder RAG inschakelt

• Je gekozen AI-model heeft een groot contextvenster: Als het eenvoudiger is om alle informatie of data die nodig is voor een nauwkeurig antwoord op te nemen in je prompt, bijvoorbeeld door een document te uploaden, kan dat de latency verlagen en retrievalgerelateerde problemen voorkomen.
• Redenerings- en data-analysestromen: Analyse- en redeneringsstromen die alleen verwijzen naar de data die in een prompt wordt meegegeven, hebben geen RAG-mogelijkheden nodig.
• Codegeneratie: RAG is doorgaans niet nodig voor algemeen coderingwerk, al wordt het meestal wel ingezet voor projectspecifieke taken, zoals het ophalen van eerdere fixes of vendor-API's en documentatie.

Wanneer je een LLM met RAG inschakelt

• Je hebt toegang nodig tot actuele informatie: Als een AI-applicatie externe bronnen met actuele informatie moet raadplegen om een nauwkeurig antwoord te genereren, moet je er altijd voor zorgen dat RAG-mogelijkheden zijn ingeschakeld.
• Je werkt in een gespecialiseerd vakgebied: Voor domeinen zoals geneeskunde, recht, onderwijs en dergelijke, waar nauwkeurigheid, detail en broncontrole belangrijk zijn, is gebruik zonder LLM vaak onvoldoende.
• Uitvoer moet verwijzen naar interne bedrijfsbestanden: Als je AI gebruikt, intern of in een klantgerichte app, om content te genereren op basis van interne bedrijfsdocumenten, zoals data, een brand kit, documentatie of bestanden, biedt RAG toegang tot die informatie.

RAG en LLM's zijn complementaire, zich ontwikkelende technologieën

RAG betekende een grote innovatie in de evolutie van AI. Het pakt drie grote problemen aan: verouderde informatie, beperkte modelgeheugen en informatielacunes door een gebrek aan relevante trainingsdata, wat vaak resulteerde in hallucinaties. Natuurlijk hebben LLM's deze problemen nog niet volledig overwonnen, maar hun voorkomen is sinds de komst van RAG aanzienlijk afgenomen.

RAG is geen statische technologie. Verwacht wordt dat deze op uiteenlopende gebieden verbeteringen zal zien, waaronder reranking, latency tijdens retrieval en tokengebruik, beveiligingsmaatregelen tegen gevaarlijke databronnen, het integreren van opgehaalde data uit meerdere bronnen, en meer. Naarmate LLM's en agentische AI zich verder ontwikkelen, zullen ook de RAG-systemen die hen ondersteunen dat doen.