Wat is RAG? Retrieval-augmented generation uitgelegd

Retrieval-augmented generation (RAG) is een methode waarbij een systeem in een externe documentindex naar relevante passages zoekt en die aan een taalmodel doorgeeft voordat het een antwoord genereert. Het model kan daardoor antwoorden met behulp van privégegevens, interne informatie of recent bijgewerkte informatie, in plaats van uitsluitend te vertrouwen op de tijdens de training vastgelegde gewichten.

Een standaardtaalmodel kent alleen de gegevens waarop het tot zijn kennispeildatum is getraind. Als een gebruiker vraagt naar het interne restitutiebeleid van uw bedrijf, een onlangs gepubliceerde API-specificatie of een accountgegeven dat vijf minuten geleden is bijgewerkt, kan het basismodel het antwoord niet uit zijn geheugen weten. RAG overbrugt die kloof door een zoekstap te combineren met de generatiestap: eerst de relevante feiten ophalen en vervolgens een antwoord genereren dat op de opgehaalde tekst is gebaseerd.

Wat betekent retrieval-augmented generation?

Retrieval-augmented generation betekent dat een systeem voor informatieopvraging wordt gecombineerd met een tekstgeneratiemodel, zodat de uitvoer wordt gebaseerd op externe documenten die tijdens de zoekopdracht worden opgehaald. In plaats van te verwachten dat een neuraal netwerk elk feit in zijn parameters onthoudt, behandelt RAG een externe tekstindex als een open boek dat het model kan raadplegen voordat het antwoord geeft.

Op hoofdlijnen bestaat elke RAG-werkwijze uit twee kernfasen:

1. Ophalen: wanneer een gebruiker een prompt indient, zet het systeem de vraag om in een zoekopdracht voor een externe gegevensopslag, zoals een vectordatabase, een trefwoordzoekindex of een combinatie van beide, en haalt het de meest relevante tekstpassages op.
2. Genereren: het systeem voegt de opgehaalde passages samen met de oorspronkelijke vraag van de gebruiker toe aan de context van het model. Het taalmodel genereert vervolgens een antwoord op basis van die passages.

Omdat de referentietekst voor elk verzoek dynamisch wordt opgehaald, kunt u de kennis van het systeem bijwerken door de documentindex aan te passen in plaats van het onderliggende model opnieuw te trainen. Daarom is RAG een gangbare methode voor het bouwen van supportassistenten, zoekfuncties voor interne documentatie en vraag-en-antwoordtools voor specifieke vakgebieden. Daarnaast zijn er creatieve toepassingen waarbij teams gespecialiseerde workflowtools zoals AI Studio Video gebruiken voor mediaproductie en tekst-API’s voor het ophalen van kennis.

Hoe verschilde het RAG-onderzoek uit 2020 van de huidige RAG-methode?

De term ‘retrieval-augmented generation’ komt uit een publicatie uit 2020 van Patrick Lewis en collega’s (arXiv:2005.11401), waarin een vooraf getraind sequence-to-sequence-model werd gecombineerd met een dichte vectorindex van Wikipedia. Tegenwoordig gebruiken ontwikkelaars de term meestal voor een eenvoudigere pijplijn die prompts samenstelt. Als u beide begrijpt, wordt duidelijk waarom ‘RAG’ in onderzoeksartikelen en technische documentatie op twee iets verschillende manieren wordt beschreven.

De architectuur van Lewis et al. uit 2020

In de oorspronkelijke publicatie uit 2020 en het bijbehorende onderzoeksartikel van Meta AI beschreven de auteurs taalmodellen als systemen met twee soorten geheugen:

• Parametrisch geheugen: kennis die is opgeslagen in de gewichten van het neurale netwerk, specifiek een vooraf getraind BART-sequence-to-sequence-model.
• Niet-parametrisch geheugen: kennis in een externe dichte vectorindex van Wikipedia-artikelen, die wordt doorzocht met een neurale retriever genaamd Dense Passage Retrieval (DPR).

In deze onderzoeksopzet werden de retriever en de generator gezamenlijk end-to-end getraind. Het artikel introduceerde twee formuleringen voor de invloed van opgehaalde passages op de generatie:

• RAG-Sequence: het model gebruikt dezelfde opgehaalde passages om de volledige uitvoersequentie te genereren.
• RAG-Token: het model kan voor elke afzonderlijke gegenereerde token verschillende opgehaalde passages gebruiken.

Op de benchmarks voor open-domeinvragen in de tabellen van het artikel (arXiv:2005.11401) behaalde RAG-Sequence een score van 44.5 Exact Match op de Natural Questions-benchmark. Daarmee presteerde het beter dan zowel de uitsluitend parametrische seq2seq-baselines als de in het onderzoek geteste architecturen voor ophalen en extraheren.

De huidige technische aanpak

Bij moderne applicatieontwikkeling trainen teams een retriever en generator zelden samen. In plaats daarvan verwijst ‘RAG’ vrijwel altijd naar een pijplijn tijdens inferentie, gebouwd rond kant-en-klare embeddingmodellen en algemene LLM-API’s:

1. Verdeel documenten in kleinere passages (chunks).
2. Zet die chunks om in vectorembeddings en sla ze op in een index.
3. Haal bij een zoekopdracht de best passende chunks op.
4. Rangschik de resultaten eventueel opnieuw voor betere relevantie.
5. Plaats de opgehaalde tekstchunks rechtstreeks in de prompt en vraag de LLM om een antwoord.

Zowel de end-to-end neurale architectuur uit 2020 als de huidige pijplijn die tekst in prompts plaatst, heet RAG. In de dagelijkse softwareontwikkeling wordt de moderne pijplijn bedoeld, tenzij iemand specifiek spreekt over het trainen van een retriever met een seq2seq-model.

Hoe werkt een moderne RAG-pijplijn stap voor stap?

Een RAG-systeem in productie verdeelt het werk over twee afzonderlijke processen: een offline ingestiepijplijn die documenten voorbereidt en indexeert, en een online zoekpijplijn die draait telkens wanneer een gebruiker een vraag stelt. Architectuurgidsen zoals de RAG-richtlijnen van AWS en de RAG-gids van het AWS Generative AI Innovation Center verdelen deze fasen in afzonderlijke onderdelen die u onafhankelijk kunt afstellen.

1. De ingestiepijplijn (gegevens indexeren)

Voordat een gebruiker een prompt verstuurt, moet uw systeem de brondocumenten doorzoekbaar maken:

• Documenten laden en opschonen: haal platte tekst en metadata (titels, URL’s, tijdstempels en toegangsrechten) uit pdf’s, wiki’s, databases of Markdown-bestanden en verwijder kapotte opmaak en terugkerende pagina-elementen.
• Chunking: verdeel lange documenten in kleinere delen, zodat u relevante passages ophaalt in plaats van volledige handleidingen. Zijn chunks te klein, dan verliezen ze hun context en worden gedachten afgebroken; zijn ze te groot, dan bevatten ze irrelevante ruis en stijgt het tokenverbruik. Teams laten aangrenzende chunks vaak iets overlappen zodat zinnen op de grens hun betekenis behouden.
• Embedding: haal elke chunk door een embeddingmodel dat de tekst omzet in een dichte numerieke vector die de betekenis weergeeft.
• Indexeren: sla deze vectoren samen met de ruwe tekst en metadatafilters op in een vectordatabase of een hybride zoekmachine die vectorovereenkomst combineert met trefwoordmatching, zoals BM25.

2. De zoekpijplijn (vragen beantwoorden)

Wanneer een gebruiker tijdens het gebruik een vraag stelt, stelt de zoekpijplijn de prompt samen:

• Zoekopdracht verwerken en embedding maken: neem de invoer van de gebruiker, herschrijf of breid die eventueel uit voor meer duidelijkheid, en zet deze om in een vector met exact hetzelfde embeddingmodel als bij de ingestie.
• Ophalen: doorzoek de index op chunks waarvan de vectoren het dichtst bij de zoekvector liggen. Vaak worden semantisch zoeken, trefwoordmatching en metadatafilters gecombineerd, bijvoorbeeld om resultaten te beperken tot documenten die de huidige gebruiker mag lezen.
• Optioneel opnieuw rangschikken: voer de eerste kandidaat-chunks door een cross-encoder-rerankermodel. Dit beoordeelt hoe direct elke passage de specifieke vraag beantwoordt en beperkt de lijst tot de beste resultaten.
• Prompt samenstellen en genereren: voeg de hoogst gerangschikte passages samen met de vraag van de gebruiker in een gestructureerd promptsjabloon in, stuur de volledige invoer naar de LLM en geef het gegenereerde antwoord terug, vaak met bronverwijzingen naar de metadata.

Hoe verhoudt RAG zich tot lange contextvensters en fine-tuning?

RAG, lange contextvensters en fine-tuning lossen verschillende onderdelen van het aanpassen van modellen op. Productiesystemen combineren ze vaak in plaats van ze als wederzijds uitsluitende keuzes te behandelen. De juiste aanpak hangt af van de vraag of u veranderlijke feiten, breed begrip binnen één sessie of veranderingen in het gedrag van het model nodig hebt.

Onderdeel	Retrieval-augmented generation (RAG)	Lang contextvenster	Fine-tuning
Hoofddoel	Per zoekopdracht relevante feiten uit een grote of veranderende verzameling leveren	Het model binnen één verzoek een grote hoeveelheid tekst laten lezen	Stijl, toon, opmaak of gedrag bij gespecialiseerde taken aanpassen
Kennis bijwerken	Documenten in de externe index bijwerken of vervangen	De ruwe documenten in de prompt vervangen	Nieuwe trainingsvoorbeelden verzamelen en opnieuw trainen
Effect op tokens per verzoek	Laag tot gemiddeld (alleen opgehaalde chunks worden verstuurd)	Hoog (elk document blijft in de prompt)	Laag (kennis of gedrag is in de modelgewichten opgenomen)
Bronvermelding	Specifieke opgehaalde chunks zijn eenvoudig te citeren	Mogelijk, maar bij zeer grote invoer moeilijker precies aan te wijzen	Moeilijk; gewichten bevatten geen expliciete documentverwijzingen
Toegangscontrole	Per zoekopdracht afgedwongen met metadatafilters in de index	Moet plaatsvinden vóór het samenstellen van de prompt	Moeilijk te isoleren; alles in de gewichten kan naar elke gebruiker lekken

RAG versus lange contextvensters

Nu moderne modellen grote contextvensters ondersteunen, is het verleidelijk om de zoekstap over te slaan en uw volledige kennisbank in elke prompt te plakken. Voor een handvol korte documenten werkt dat prima, vooral in combinatie met promptcaching en een reeds gevulde KV cache, zodat herhaalde voorvoegsels niet telkens opnieuw hoeven te worden verwerkt.

Zodra uw documentverzameling echter tot duizenden bestanden groeit, loopt het plaatsen van alles in de prompt tegen twee grenzen aan:

1. Kosten en vertraging: bij elke beurt enorme prompts versturen verhoogt de API-kosten en de tijd tot de eerste token. Daarom blijft selectief ophalen een kernstrategie bij het verlagen van AI-API-kosten.
2. Verminderde aandacht: modellen besteden niet evenveel aandacht aan elk deel van een enorme prompt. Naarmate irrelevante tekst zich in het venster opstapelt, neemt de nauwkeurigheid vaak af. Dit verschijnsel heet contextrot. RAG houdt de prompt gericht door alleen passages op te halen die voor de huidige vraag van belang zijn.

RAG versus fine-tuning

Fine-tuning werkt de gewichten van een model bij met zorgvuldig geselecteerde voorbeelden. Het is effectief als u wilt dat een model een strikt uitvoerschema volgt, een specifieke merkstem overneemt of vakspecifieke syntaxis leert. Het is geen geschikte manier om een model snel veranderende feiten aan te leren.

De publicatie van Lewis et al. uit 2020 (arXiv:2005.11401) liet met een experiment waarbij de index direct werd vervangen zien waarom niet-parametrisch geheugen belangrijk is voor veranderende feiten. De auteurs testten hun model met een Wikipedia-dump van december 2016 en een Wikipedia-dump van december 2018, aan de hand van vragen over wereldleiders die tussen die datums waren gewisseld:

• Wanneer het jaar van de vraag overeenkwam met dat van de index, beantwoordde het model met de index uit 2016 70% van de vragen over wereldleiders uit 2016 correct en met de index uit 2018 68% van de vragen over wereldleiders uit 2018.
• Wanneer de index niet bij de vragen paste, daalde de nauwkeurigheid naar 12% (index uit 2018 voor leiders uit 2016) en 4% (index uit 2016 voor leiders uit 2018).

Door alleen de externe index te vervangen, werd de feitelijke wereldkennis van het systeem bijgewerkt zonder ook maar één modelgewicht opnieuw te trainen.

Waar gaat RAG mis?

Zoeken toevoegen aan een taalmodel vermindert giswerk over privé- of recente onderwerpen, maar neemt AI-hallucinaties niet weg en garandeert geen nauwkeurige antwoorden. Een RAG-systeem heeft meerdere bewegende onderdelen, waardoor fouten zowel bij het zoeken als bij het genereren kunnen optreden:

• Gemiste zoekresultaten: als de gebruiker een vraag met andere termen formuleert dan het brondocument, of als bij het opdelen een tabel van de kop is gescheiden, vindt de retriever mogelijk niet de passage met het antwoord. Als de juiste chunk de prompt nooit bereikt, tast het model in het duister.
• Ruis of verouderde documenten: een index is slechts zo goed als de bestanden erin. Als uw kennisbank zowel de versie uit 2023 als die uit 2026 van een inwerkgids bevat zonder duidelijke filtering van verouderde versies, kan de retriever achterhaalde instructies aan het model geven.
• Te veel ophalen: 25 chunks ophalen ‘voor de zekerheid’ werkt vaak averechts. Een prompt vol zijdelings relevante passages vertroebelt het antwoord, verhoogt de vertraging en kan contextrot veroorzaken, waarbij het model wordt afgeleid door details die net niet relevant zijn.
• Indirecte promptinjectie via opgehaalde tekst: als uw index niet-vertrouwde externe inhoud opneemt, zoals inkomende e-mails, openbare webpagina’s of door gebruikers ingediende tickets, kan een aanvaller kwaadaardige instructies in een document plaatsen. Wanneer dat document wordt opgehaald en in de prompt geplaatst, kan het een promptinjectie veroorzaken die het gedrag van het model overneemt.
• Het model negeert of leest context verkeerd: zelfs als precies de juiste passage in de prompt staat, kan de generator een ontkenning verkeerd begrijpen, twee afzonderlijke chunks onjuist combineren of zijn voorkennis uit de training laten voorgaan op de verstrekte tekst wanneer de opgehaalde passage algemene kennis tegenspreekt.

Checklist voor een betrouwbaar RAG-systeem

Wanneer een RAG-prototype naar productie gaat, voorkomen enkele gedisciplineerde technische gewoonten de meest voorkomende fouten:

• Houd de index actueel en vrij van duplicaten: bouw geautomatiseerde pijplijnen die verwijderde documenten weghalen, vervangen versies archiveren en duidelijke tijdstempels en bron-URL’s aan elke geïndexeerde chunk toevoegen.
• Haal minder op, maar van hogere kwaliteit: combineer hybride zoeken (vector + trefwoord) met metadatafilters en een reranker, zodat u slechts een kleine set informatieve passages aan de generator doorgeeft in plaats van tientallen zwakke resultaten in de prompt te stoppen.
• Scheid niet-vertrouwde opgehaalde tekst duidelijk van systeeminstructies: plaats expliciete structurele scheidingstekens rond opgehaalde chunks, zoals XML-tags of gelabelde documentblokken, en instrueer de systeemprompt om deze blokken uitsluitend als passieve referentiegegevens te behandelen, nooit als uitvoerbare opdrachten.
• Laat het model afzien van antwoorden bij ontbrekende context: instrueer het model duidelijk te melden wanneer de aangeleverde passages onvoldoende informatie bevatten om de vraag te beantwoorden. Een instructie in de prompt garandeert niet dat het model altijd gehoorzaamt, maar biedt een duidelijker alternatief dan stilzwijgend gokken als de zoekopdracht niets oplevert.

Veelgestelde vragen

Heb je voor RAG altijd een vectordatabase nodig?

Nee. Retrieval-augmented generation vereist alleen een manier om relevante tekst op te halen voordat het model wordt aangeroepen. Vectordatabases zijn populair voor zoeken op semantische gelijkenis, maar veel RAG-systemen in productie gebruiken traditionele trefwoordzoekmachines, zoals BM25 in Elasticsearch of de volledige-tekstzoekfunctie van PostgreSQL, of hybride zoekmethoden die trefwoorden en vectoren combineren.

Kan RAG volledig voorkomen dat een LLM hallucineert?

Nee. RAG vermindert hallucinaties door ontbrekende of verouderde trainingsgegevens, omdat het de referentietekst direct in de prompt aan het model geeft. Het model kan een passage echter nog steeds verkeerd lezen, feiten uit twee ongerelateerde chunks verkeerd combineren of een antwoord gokken wanneer de retriever irrelevante documenten ophaalt.

Moet ik RAG of fine-tuning gebruiken voor de interne documenten van mijn bedrijf?

Begin met RAG als u wilt dat een model vragen beantwoordt over interne documenten die in de loop van de tijd veranderen. Met RAG kunt u bestanden in de index direct toevoegen, bewerken of verwijderen en bij elke zoekopdracht de toegangsrechten per gebruiker toepassen. Fine-tuning is beter geschikt om consistente opmaak, toon of taakprocessen aan te leren.

Bronnen

• Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — arXiv:2005.11401
• Meta AI Research Blog — Retrieval-Augmented Generation: Streamlining the creation of intelligent natural language processing models
• AWS Prescriptive Guidance — Understanding LLMs and RAG
• AWS Machine Learning Blog — From RAG to fabric: Lessons learned from building real-world RAGs at GenAIIC – Part 1