RAG, retrieval-augmented generation, is een patroon waarbij relevante documenten worden opgehaald uit een externe opslag en als context aan een taalmodel worden doorgegeven voordat het een antwoord genereert. Het model beantwoordt vragen op basis van wat het ophaalt, niet alleen op basis van wat het tijdens de training heeft geleerd.

Waarom het bestaat

Taalmodellen hebben een vaste kennisgrens en geen toegang tot privédata. Een model getraind op publieke tekst kan geen vragen beantwoorden over je interne documentatie, recente gebeurtenissen of bedrijfseigen gegevens, tenzij die informatie tijdens inferentie wordt aangeleverd. RAG is de standaardmanier om dat te doen.

Het alternatief, fine-tuning, brengt kennis aan in de gewichten van het model. Dat is duur, langzaam bij te werken en slecht geschikt voor informatie die regelmatig verandert. RAG houdt de kennisopslag en het model gescheiden, zodat je documenten kunt bijwerken zonder het model aan te raken.

Hoe het werkt

Op hoog niveau heeft een RAG-pipeline drie fasen:

  1. Indexering. Brondocumenten worden opgesplitst in stukken, omgezet naar vector-embeddings en opgeslagen in een vectordatabase. Metadata wordt vaak naast de vectors opgeslagen om filtering te ondersteunen.
  2. Ophalen. Wanneer een zoekopdracht binnenkomt, wordt deze ook omgezet naar een embedding. Het systeem doorzoekt de vectoropslag naar stukken waarvan de embeddings dicht bij de query-embedding liggen, doorgaans via cosinus-similariteit of dotproduct. Sommige pipelines voegen een herrangschikkingsstap toe om de precisie te verbeteren.
  3. Generatie. De opgehaalde fragmenten worden als context in de prompt ingevoegd. Het taalmodel leest zowel de zoekopdracht als de opgehaalde tekst en genereert vervolgens een antwoord dat in dat materiaal is verankerd.

Dit wordt ook wel het contextvenster als werkoppervlak genoemd: je vult het contextvenster van het model met opgehaalde feiten in plaats van te vertrouwen op parametrisch geheugen.

Wat er mis kan gaan

RAG is geen automatische garantie voor nauwkeurigheid. Er zijn een aantal veelvoorkomende manieren waarop het misgaat.

Gemiste retrieval. Als het relevante fragment niet wordt opgehaald, hallucineert het model of geeft het aan niets te weten. Fragmentgrootte, de keuze van het embeddingmodel en de formulering van de zoekopdracht beïnvloeden allemaal de recall.

Contextvervuiling. Opgehaalde tekst die verouderd, tegenstrijdig of niet relevant is, kan het model misleiden, ook als de retrieval-stap technisch gezien succesvol is.

Prompt injection. Kwaadaardige inhoud die in een opgehaald document is ingebed, kan proberen het gedrag van het model te sturen. Dit is een reëel risico wanneer het documentcorpus niet volledig wordt beheerd. Zie what is prompt injection voor meer details.

Attributiefouten. Modellen combineren opgehaalde inhoud soms met trainingskennis op manieren die moeilijk te traceren zijn. Claims terugleiden naar bronfragmenten is een goede werkwijze, maar vereist een weloverwogen pipeline-ontwerp.

Hoe RAG past in een groter systeem

RAG is vaak één component in een grotere architectuur. Een MCP server kan retrieval beschikbaar stellen als een tool die een agent dynamisch aanroept, in plaats van bij elk verzoek op te halen. Agentic coding-omgevingen gebruiken RAG soms om codebase-context op te halen die niet in één enkele prompt past.

Evaluatie is hier van belang. Een RAG-pipeline moet worden getest op retrievalkwaliteit, antwoordgetrouwheid en antwoordrelevantie als drie afzonderlijke aandachtspunten. Eén gecombineerde metric verbergt welk onderdeel tekortschiet. Zie what is an eval voor de manier waarop evaluatieontwerp van toepassing is.

Waar we op testen

Engineers die met RAG-pipelines werken, moeten helder kunnen redeneren over waar een fout ontstaat: in de retrieval-stap, de context die aan het model wordt meegegeven, of het gebruik dat het model van die context maakt. Onze beoordeling toetst dit direct. In de AI-native assessment worden kandidaten gescoord op AI-outputverificatie en AI-versneld debuggen, die beide blootleggen of iemand de volledige pipeline begrijpt of hem als een black box behandelt. De volledige aanpak staat beschreven bij hoe we vetten.

Korte antwoorden

Wat is het verschil tussen RAG en fine-tuning?

Fine-tuning verankert kennis in de modelgewichten en vereist hertraining om te updaten. RAG haalt kennis op tijdens inferentie vanuit een externe opslag, waardoor het eenvoudiger actueel te houden is en beter geschikt voor privé-informatie of informatie die regelmatig verandert.

Elimineert RAG hallucinaties?

Nee. RAG vermindert hallucinaties door antwoorden te verankeren in opgehaalde tekst, maar het model kan die tekst nog steeds verkeerd lezen, combineren of negeren. Retrieval-fouten laten het model ook zonder de benodigde context, wat zelfverzekerd maar onjuiste antwoorden kan opleveren.

Welk type database gebruikt RAG?

De meeste RAG-pipelines gebruiken een vectordatabase om documentembeddings op te slaan en op similariteit te doorzoeken. Sommige implementaties voegen relationele metadataopslag of zoeken op trefwoorden toe naast vectorzoekopdrachten om de retrievalprecisie te verbeteren.

Laten we praten

Ontvang binnen vijf werkdagen een shortlist

Je deelt de rollen en de stack in een kort formulier of een gesprek van dertig minuten. Binnen vijf werkdagen krijg je senior engineers met naam en toenaam om te beoordelen, elk met beide scorecards.

Beoordeeld opClutch4.9 van 5 op basis van 36 reviews
ISO 27001
Gecertificeerd

Plan een afspraak van dertig minuten met Dale

De kalender wordt aangeboden door HubSpot, dat zijn eigen cookies plaatst. Laad hem hier, of boek via de pagina van HubSpot.

Boekingspagina openen