Retrieval-Augmented Generation (RAG)

Wat is Retrieval-Augmented Generation (RAG)?

Retrieval-Augmented Generation, meestal afgekort tot RAG, is een techniek die een taalmodel combineert met een eigen kennisbank. Het model krijgt voor het antwoorden eerst de meest relevante fragmenten uit jouw documenten aangereikt en gebruikt die als basis om de vraag te beantwoorden.

Je kan het vergelijken met een student die zijn cursus mag openhouden tijdens een examen. Het taalmodel doet de formulering, maar de feiten komen uit een afgeschermde set documenten die jij controleert. Dat is precies waarom RAG zo populair werd voor chatbots op eigen documentatie, klantenservice-tools en interne zoekmachines.

RAG bestaat uit twee duidelijke stukken. Er is een retrieval-stap die de juiste info ophaalt, en een generation-stap waarin het taalmodel een leesbaar antwoord schrijft op basis van die info. Zonder retrieval heb je een gewone LLM die moet gokken. Zonder generation heb je een klassieke zoekmachine die links teruggeeft. De kracht zit in de combinatie.

Waarom heb je RAG nodig?

Een taalmodel op zichzelf heeft drie pijnpunten die RAG oplost.

Verouderde kennis
Een LLM kent enkel wat in zijn trainingsdata zat. Jouw nieuwste prijslijst, vorige week ondertekend contract of huidige voorraadstand zit daar niet in. RAG haalt die info live op uit jouw bronnen.

Hallucinaties
Wanneer een model het antwoord niet kent, verzint het vaak iets plausibels. Door het model expliciet te voeden met de juiste tekst kan je de kans op hallucinaties serieus terugdringen en meteen ook een bronverwijzing tonen.

Bedrijfsspecifieke kennis
Een publiek model weet niets over jouw intern jargon, jouw klanten of jouw processen. RAG brengt die context binnen zonder dat je een volledig nieuw model moet trainen.

Hoe werkt RAG?

Een klassieke RAG-pipeline doorloopt vier stappen, twee aan de kant van de voorbereiding en twee aan de kant van de gebruiker.

1. Chunking
   Je documenten worden opgeknipt in kleinere stukken van bijvoorbeeld 300 tot 1000 woorden. Te grote blokken verliezen focus, te kleine verliezen context. De keuze van chunkgrootte heeft vaak grote impact op de kwaliteit.

2. Embedden en indexeren
   Elk stuk tekst wordt door een embedding-model omgezet in een vector, een rij getallen die de betekenis weergeeft. Die vectoren komen in een vector database zoals Azure AI Search, Pinecone, Qdrant of Weaviate.

3. Retrieval
   Bij een vraag van de gebruiker wordt ook die vraag omgezet in een vector. De vector database zoekt de chunks waarvan de vector er het dichtst bij ligt. Die worden geselecteerd als context.

4. Generation
   De gebruikersvraag plus de gevonden chunks worden samen naar een LLM gestuurd. Het model schrijft een antwoord dat steunt op die tekst, meestal met een verwijzing naar de bron.

Modernere varianten voegen extra bouwstenen toe: hybride zoeken (semantisch plus klassiek keyword), reranking van resultaten, query-herschrijving of agentische flows die meerdere zoekopdrachten achter elkaar uitvoeren.

Wanneer gebruik je RAG?

• Kennisassistent op interne documentatie
  HR-beleid, IT-handleidingen, productspecificaties, contracten. Medewerkers krijgen snel een antwoord in plaats van zelf SharePoint af te grazen.

• Klantenservice-chatbot
  Vragen over producten, leveringstermijnen of voorwaarden beantwoorden met verwijzing naar de officiële bron. Routeer naar een mens wanneer de vraag te complex wordt.

• Juridische en compliance-ondersteuning
  Zoeken doorheen wetgeving, contracten of beleidsdocumenten met volledige bronvermelding, zodat een jurist de bron altijd kan nalezen.

• Technische documentatie
  Ontwikkelaars en consultants laten doorzoeken via natuurlijke taal. Erg nuttig voor grote codebases of uitgebreide API-documentatie.

• Verkoop en marketing
  Offertes en productbladen snel samenstellen op basis van bestaande templates en case studies.

Valkuilen bij een RAG-oplossing

Een RAG-oplossing is snel in elkaar geklikt, maar betrouwbaar krijgen is vaak maanden werk. Dit zijn de meest voorkomende valkuilen:

Slechte brondata
Verouderde, dubbele of tegenstrijdige documenten in je index leiden tot tegenstrijdige antwoorden. Opschonen en versiebeheer is even belangrijk als het model zelf.

Verkeerde chunking
Als je een tabel halverwege doorknipt of een paragraaf uit zijn kop haalt, mist het model context. Formaat-bewuste chunking (Markdown-headers, tabelranden, PDF-secties respecteren) maakt een groot verschil.

Onvoldoende retrieval-kwaliteit
Zuiver semantisch zoeken mist soms exacte termen (artikelnummers, afkortingen). Hybride zoeken met een klassieke keyword-index ernaast helpt.

Geen evaluatie
Zonder een set testvragen met verwachte antwoorden weet je niet of je wijzigingen verbeteren of verslechteren. Bouw een evaluatieset op vanaf dag één.

Rechten en toegang
De chatbot mag nooit info tonen die de vragensteller zelf niet mag zien. Row level security op je bron, filters op de retrieval-laag en identity-bewuste indexering zijn geen optie maar een vereiste.

RAG versus fine-tuning

RAG en fine-tuning worden vaak als alternatieven voorgesteld, maar ze lossen andere problemen op.

RAG voegt kennis toe. Je brengt nieuwe feiten binnen zonder het model aan te passen. Ideaal wanneer de kennis vaak verandert of wanneer je controle wil over welke bronnen gebruikt worden.

Fine-tuning verandert gedrag. Je leert het model een stijl, een toon, een format of een specifieke taak. Ideaal voor consistente output, maar duur en traag bij veranderende info.

In de praktijk combineer je vaak beide: fine-tuning voor de toon en de structuur van het antwoord, RAG voor de actuele feiten. Voor de meeste bedrijfscases is RAG alleen al genoeg om zeer ver te komen.