Wat is RAG? Retrieval-Augmented Generation Uitgelegd (2026)
RAG (Retrieval-Augmented Generation) geeft een taalmodel toegang tot uw eigen data voordat het antwoord geeft. Het model haalt overeenkomende documenten op uit een vector database, voegt deze toe aan zijn prompt als context, en genereert een antwoord dat gegrond is in die documenten. Hier ziet u hoe het werkt, wat het kost en wanneer u het moet gebruiken.
Op deze pagina
- TL;DR — De 60-seconden uitleg
- Voorkennis & Setup
- Waarom RAG bestaat (het verhaal)
- Het mentale model
- Anatomie: volg één vraag
- Niveau 1 — Speelgoedvoorbeeld
- Niveau 2 — Realistisch
- Niveau 3 — Productie
- Acht valkuilen (productielessen)
- RAG vs Fine-tuning vs Long Context
- Kosten & Prestaties
- Verder gaan
- Geselecteerde bronnen
- Zelfcheck
- Veelgestelde vragen
AI Fundamentals · Bijgewerkt mei 2026 · Beoordeeld door het IITS Azure data engineering team · Den Haag
RAG = LLM + Uw Data.
RAG (Retrieval-Augmented Generation) is een techniek die een taalmodel toegang geeft tot uw eigen data voordat het antwoord geeft. Het model haalt overeenkomende documenten op uit een vector database, voegt deze als context toe aan zijn prompt, en genereert een antwoord dat gegrond is in die documenten. Geïntroduceerd door Lewis et al. (mei 2020), is dit nu de meest voorkomende manier om LLM-applicaties te bouwen die correct, actueel en klantspecifiek moeten zijn.
Wat het is
Zoeken + LLM in één pijplijn.
Wat het oplost
LLMs kennen uw privé, actuele data niet.
Wie het nodig heeft
Iedereen die LLM-apps bouwt met bedrijfsdata.
Na deze gids
U bouwt een werkend RAG-systeem in één dag.
De RAG-pijplijn
Vijf stappen. De vector database doet het zware werk — die vindt documenten op betekenis, niet op trefwoorden. Het LLM ziet nooit de hele kennisbank, alleen de stukken die ertoe doen.
Voorkennis & Setup
U heeft basiskennis Python nodig (functies, virtuele omgevingen, pip), het vermogen om een HTTP-aanroep te doen, en een API-sleutel voor OpenAI of Azure OpenAI. Meer niet.
Installatie eenmalig
python -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install openai chromadb sentence-transformers cohere langchain numpy
Zet uw API-sleutels in omgevingsvariabelen. Haal een OpenAI-sleutel (of gebruik Azure OpenAI in EU-regio voor productie). Optioneel: een Cohere-sleutel voor re-ranking.
Waarom RAG bestaat (het verhaal)
In 2019, als u een taalmodel vroeg "wat is ons retourbeleid?", had u drie slechte opties:
- Het model fine-tunen op uw beleid. Duur (€1.000+), langzaam (dagen), en elke beleidsupdate betekende opnieuw trainen.
- Het hele beleid in elke prompt plakken. Werkte voor één document. Viel uit elkaar bij de eerste kennisbank van duizend pagina's.
- Leven met hallucinaties. Het model verzon retourbeleid dat niet bestond.
In mei 2020 publiceerden Lewis et al. bij Facebook AI "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks". Het idee was elegant: monteer een zoekmachine op een taalmodel. Zoek voor elke vraag eerst in een kennisbank, voer dan de topresultaten samen met de vraag aan het model.
Het kerninzicht
U hoeft het model uw data niet te leren. U hoeft het alleen op antwoordmoment het relevante stuk te tonen. Die scheiding — tussen wat het model weet en wat u het geeft — is wat RAG goedkoop, actueel en auditbaar maakt.
In 2024 gebruikte elk serieus LLM-product RAG: ChatGPT for Business, Microsoft Copilot, Perplexity, Notion AI, Glean, Klarna's klantenservice, Stripe's docs-assistent. In 2026 is het de standaardarchitectuur voor LLM-apps met privédata.
Het mentale model
De open-boek-examen analogie
Een LLM zonder RAG is een student die een gesloten-boek examen maakt — die kan alleen gebruiken wat tijdens training is gememoriseerd. Een LLM met RAG maakt een open-boek examen — die moet nog steeds een goed antwoord schrijven, maar mag de feiten opzoeken in uw naslagwerk. Betere notities (chunks), beter zoeken (vector DB), betere antwoorden.
Vijf termen die u moet internaliseren:
Embedding
Technisch: een vector van vaste lengte (meestal 384 tot 3.072 getallen) die de betekenis van een stuk tekst vastlegt. Vriendelijk: een coördinaat in een "betekenisruimte" waar vergelijkbare onderwerpen dicht bij elkaar wonen. Veelvoorkomend misverstand: embeddings zijn niet leesbaar voor mensen; u kunt de tekst er niet uit terugleiden.
Vector database
Technisch: een database geoptimaliseerd voor nearest-neighbour zoeken over miljoenen vectoren via algoritmes als HNSW of IVF. Vriendelijk: een zoekmachine die documenten vindt op betekenis, niet op trefwoorden. Veelvoorkomend misverstand: u heeft geen aparte database nodig — u kunt vector search toevoegen aan Postgres met pgvector.
Chunking
Technisch: documenten splitsen in kleinere stukken (200–1.000 tokens elk) voor het embedden. Vriendelijk: uw kennisbank in hapklare pagina's snijden zodat zoeken de juiste alinea kan vinden, niet het hele boek. Veelvoorkomend misverstand: grotere chunks zijn niet beter — ze verwateren betekenis en proppen irrelevante inhoud in de prompt.
Retrieval
Technisch: de zoekstap — de top-K chunks vinden waarvan de embeddings het dichtst (via cosinus-gelijkenis) bij de vraag-embedding liggen. Vriendelijk: de "opzoek"-fase voordat het model antwoord geeft. Veelvoorkomend misverstand: retrieval-kwaliteit maakt of breekt RAG, niet het LLM. De meeste fouten zijn retrieval-fouten.
Re-ranking
Technisch: een tweede-pass model (meestal een cross-encoder) dat opgehaalde kandidaten opnieuw scoort op werkelijke relevantie, en de top 3–5 behoudt. Vriendelijk: retrieval is de grove sortering; re-ranking is de fijne sortering. Veelvoorkomend misverstand: re-ranking is optioneel — in productie is dit de enkele meest effectieve verbetering die u kunt maken.
Anatomie: volg één vraag
Laten we één vraag van begin tot eind volgen. De gebruiker vraagt: "Wat is het retourbeleid van IITS?"
Stap 1 — Embed de vraag
De vraag wordt naar een embedding-model gestuurd (bijv. text-embedding-3-small). Uitvoer: een vector van 1.536 dimensies. Deze vector representeert de betekenis van de vraag.
Stap 2 — Zoek in de vector database
De vector database vergelijkt de vraagvector met elke chunk-vector in uw index (met HNSW duurt dit milliseconden, zelfs bij miljoenen chunks). Geeft de top-K terug, bijv. K=20, gesorteerd op cosinus-gelijkenis.
Stap 3 — Herrangschik de kandidaten
Een cross-encoder (bijv. Cohere Rerank of BGE Reranker) scoort de 20 chunks op werkelijke relevantie. Behoud de top 3–5.
Stap 4 — Bouw de augmented prompt
De uiteindelijke prompt is [systeeminstructies] + [opgehaalde chunks] + [gebruikersvraag]. De systeeminstructies zeggen meestal: "Beantwoord alleen met de meegeleverde context. Als het antwoord daar niet in staat, zeg dat dan."
Stap 5 — Genereer
Het LLM (GPT-4o, Claude Sonnet, Gemini Pro, etc.) produceert een antwoord gegrond in de opgehaalde chunks — en kan ze cruciaal genoeg citeren. Zonder RAG: hallucinatie of "Ik weet het niet." Met RAG: een citaat uit uw werkelijke beleid.
Niveau 1 — Speelgoedvoorbeeld
De minimaal levensvatbare RAG. Twintig regels. In-memory. Geen vector database. Draait nu direct op uw laptop.
import os, numpy as np
from openai import OpenAI
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
DOCS = [
"Ons retourbeleid staat retouren toe binnen 30 dagen na aankoop.",
"Verzending is gratis voor bestellingen boven 50 euro binnen Nederland.",
"Klantenservice is beschikbaar maandag tot vrijdag, 9:00 tot 17:00 CET.",
"Wij accepteren iDEAL, creditcard en SEPA bankoverschrijvingen.",
]
def embed(text):
return client.embeddings.create(input=text, model="text-embedding-3-small").data[0].embedding
doc_vecs = np.array([embed(d) for d in DOCS])
question = "Kan ik iets retourneren dat ik vorige week heb gekocht?"
q_vec = np.array(embed(question))
scores = doc_vecs @ q_vec / (np.linalg.norm(doc_vecs, axis=1) * np.linalg.norm(q_vec))
top_doc = DOCS[int(np.argmax(scores))]
prompt = f"Context: {top_doc}\n\nVraag: {question}\n\nBeantwoord uitsluitend met de context hierboven."
answer = client.chat.completions.create(model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}])
print(answer.choices[0].message.content)
Verwachte uitvoer
Ja — ons retourbeleid staat retouren toe binnen 30 dagen na aankoop, dus een retour voor een artikel van vorige week valt binnen die termijn.
Wat er net gebeurde
U heeft vier documenten ge-embed, een vraag ge-embed, het meest nabije document gevonden via cosinus-gelijkenis, en het LLM gevraagd te antwoorden met uitsluitend dat document. Dat is RAG in 20 regels. Als u hier stopt, begrijpt u RAG beter dan de meeste mensen die de term gebruiken.
Niveau 2 — Realistisch
Niveau 1 valt om bij vier problemen: (a) de documenten passen niet in het geheugen, (b) er is geen chunking, (c) er is geen re-ranking, (d) de prompt forceert geen grounding. Niveau 2 lost alle vier op met ChromaDB en Cohere Rerank.
import os, chromadb, cohere
from openai import OpenAI
from langchain_text_splitters import RecursiveCharacterTextSplitter
openai = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
co = cohere.Client(os.environ["COHERE_API_KEY"])
db = chromadb.PersistentClient(path="./rag_db").get_or_create_collection("docs")
# 1. Chunk een echt document (recursive splitter respecteert paragrafen en zinnen)
with open("beleid.md") as f:
text = f.read()
splitter = RecursiveCharacterTextSplitter(chunk_size=512, chunk_overlap=64)
chunks = splitter.split_text(text)
# 2. Embed en sla op
vectors = [openai.embeddings.create(input=c, model="text-embedding-3-small").data[0].embedding for c in chunks]
db.add(ids=[str(i) for i in range(len(chunks))], embeddings=vectors, documents=chunks)
def vraag(vraag_tekst):
# 3. Haal top-20 kandidaten op
q_vec = openai.embeddings.create(input=vraag_tekst, model="text-embedding-3-small").data[0].embedding
results = db.query(query_embeddings=[q_vec], n_results=20)
candidates = results["documents"][0]
# 4. Herrangschik naar top-3
reranked = co.rerank(query=vraag_tekst, documents=candidates, top_n=3, model="rerank-multilingual-v3.0")
top_chunks = [candidates[r.index] for r in reranked.results]
# 5. Augmented prompt met grounding-instructie
context = "\n\n---\n\n".join(top_chunks)
prompt = (
"Beantwoord de vraag UITSLUITEND met de context hieronder. "
"Als het antwoord niet in de context staat, zeg dan 'Die informatie heb ik niet.' "
f"Verwijs naar het relevante chunknummer.\n\nContext:\n{context}\n\nVraag: {vraag_tekst}"
)
response = openai.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": prompt}],
temperature=0,
)
return response.choices[0].message.content
print(vraag("Wat is ons retourbeleid voor digitale producten?"))
Wat is veranderd t.o.v. Niveau 1
- Persistente opslag: ChromaDB schrijft naar schijf, dus niet opnieuw embedden bij elke herstart.
- Chunking: documenten worden gesplitst op natuurlijke grenzen met 64 token overlap voor context.
- Twee-staps retrieval: 20 snelle kandidaten, herrangschikt naar 3 precieze.
- Grounding-instructie: de prompt zegt het LLM expliciet niets te verzinnen.
- Temperatuur 0: deterministische antwoorden, minder hallucinaties.
Niveau 3 — Productiepatroon
In productie scheidt u verantwoordelijkheden, voegt u observability toe, evalueert u kwaliteit en voegt u hybride (vector + trefwoord) zoeken toe. Schets van een productie-vormige module:
# rag/pipeline.py
from dataclasses import dataclass
from typing import Sequence
import logging, time
@dataclass
class RetrievedChunk:
text: str
score: float
source: str
chunk_id: str
metadata: dict
class RAGPipeline:
def __init__(self, embedder, vector_store, keyword_store, reranker, llm, *, top_k=20, top_n=4):
self.embedder = embedder
self.vector_store = vector_store # bijv. Azure AI Search, pgvector
self.keyword_store = keyword_store # bijv. BM25 over dezelfde corpus
self.reranker = reranker
self.llm = llm
self.top_k = top_k
self.top_n = top_n
self.log = logging.getLogger("rag")
def ask(self, vraag: str, *, tenant_id: str, trace_id: str) -> dict:
t0 = time.perf_counter()
# 1. Hybride retrieval — vector + trefwoord parallel
q_vec = self.embedder.embed(vraag)
vec_hits = self.vector_store.search(q_vec, top_k=self.top_k, filter={"tenant": tenant_id})
kw_hits = self.keyword_store.search(vraag, top_k=self.top_k, filter={"tenant": tenant_id})
merged = self._reciprocal_rank_fusion(vec_hits, kw_hits)
# 2. Herrangschik
reranked = self.reranker.rerank(vraag, merged, top_n=self.top_n)
# 3. Fallback als niets relevant is
if not reranked or reranked[0].score < 0.3:
self.log.info("low_confidence_retrieval", extra={"trace_id": trace_id})
return {"answer": "Die informatie heb ik niet.", "sources": [], "trace_id": trace_id}
# 4. Augmented prompt
context = self._format_context(reranked)
prompt = self._build_prompt(vraag, context)
answer = self.llm.generate(prompt, temperature=0, max_tokens=600)
# 5. Observability
self.log.info(
"rag_query",
extra={
"trace_id": trace_id,
"tenant_id": tenant_id,
"latency_ms": int((time.perf_counter() - t0) * 1000),
"n_retrieved": len(merged),
"n_used": len(reranked),
"top_score": reranked[0].score,
},
)
return {
"answer": answer,
"sources": [{"id": c.chunk_id, "source": c.source, "score": c.score} for c in reranked],
"trace_id": trace_id,
}
Waarom hybride zoeken
Vector search mist exacte termen (SKU-codes, foutmeldingen). BM25 vangt ze. Reciprocal Rank Fusion combineert beide rangschikkingen goedkoop.
Waarom metadata-filtering
Filter op tenant, datum, rechten vóór vector search. Cruciaal voor multi-tenant of gereguleerde apps.
Waarom een fallback
Als de topscore onder een drempel ligt (bijv. 0.3), zeg "Ik weet het niet" in plaats van het LLM laten improviseren.
Waarom gestructureerde logging
Elke query logt latency, scores, chunk-ID's, tenant. U heeft dit nodig de eerste keer dat een klant vraagt "waarom zei uw AI dit?"
Voeg een evaluatieharnas toe met RAGAS dat faithfulness meet (is het antwoord gegrond in de context?), answer relevancy, en context precision/recall. Draai het bij elke wijziging aan chunking, embeddings of prompt.
Acht valkuilen (productielessen)
1. Chunkgrootte-hel
De val: mensen kiezen "elke 1.000 tekens chunken" omdat het rond klinkt. Het gevolg: zinnen halverwege afgekapt, codeblokken verbrokkeld, tabellen verwoest. De fix: gebruik een recursive splitter die paragrafen, koppen, zinnen respecteert. Begin bij 512 tokens met 64 overlap. Voor markdown gebruik MarkdownHeaderTextSplitter.
2. Re-ranking overslaan
De val: "vector search is snel en gratis, ik haal gewoon de top-5 op." Het gevolg: de juiste chunk staat op positie 7 en u mist hem. De fix: haal top-20 op, herrangschik naar top-3 met Cohere Rerank of BGE Reranker. Typische kwaliteitswinst: 20–30%.
3. Verkeerde embeddings voor uw domein
De val: "OpenAI embeddings zijn de standaard, dus moeten ze het beste zijn." Het gevolg: middelmatige retrieval bij juridische, medische, code- of meertalige data. De fix: benchmark Voyage AI (legal/code), BGE-M3 (multilingual), Cohere Embed v3 (general), en Azure-gehoste modellen. Test op uw queries.
4. Geen metadata-filtering
De val: één grote vector-index voor alle klanten. Het gevolg: tenant A ziet de data van tenant B. Of de prijslijst van vorig jaar duikt op in antwoorden over huidige prijzen. De fix: filter op tenant_id, valid_from, permission_level vóór de vector search. Elke moderne vector DB ondersteunt dit.
5. Retrieval-kwaliteit als black box behandelen
De val: "het antwoord ziet er goed uit, ship het." Het gevolg: u kunt niet zien of een regressie van chunking, embeddings, re-ranking of prompt kwam. De fix: bouw een golden set van 50–200 vraag/verwacht-antwoord paren. Meet recall@K (verscheen de juiste chunk überhaupt?) en precision@K (hoeveel van de K waren bruikbaar?) bij elke wijziging.
6. Te veel chunks in de prompt proppen
De val: "meer context = beter antwoord." Het gevolg: het model verliest de draad, latency verdubbelt, kosten verdrievoudigen. De fix: 3–5 hoogwaardige chunks verslaan 20 middelmatige. Als u meer nodig heeft, vat eerst samen of gebruik hiërarchische retrieval.
7. Geen fallback als retrieval niets vindt
De val: een lege context naar het LLM sturen met "beantwoord deze vraag." Het gevolg: het model improviseert een plausibel klinkend fout antwoord. De fix: als de topscore onder de drempel ligt, geef beleefd "Die informatie heb ik niet." Of escaleer naar een mens.
8. Vergeten dat embedding-model = vastgelegde kosten
De val: kies een embedding-model, embed miljoenen chunks, ship. Het gevolg: een jaar later wilt u een beter model — opnieuw embedden van de hele corpus kost duizenden euro's en dagen. De fix: benchmark embeddings voordat u opschaalt. Versie uw index zodat u twee modellen naast elkaar kunt draaien tijdens migratie.
Skim-samenvatting als u hier stopt
RAG is zoeken + LLM. De meeste fouten zijn retrieval-fouten, geen LLM-fouten. Chunk goed, herrangschik altijd, evalueer constant, val gracieus terug. U weet nu meer over RAG dan 95% van de mensen die het bouwen.
RAG vs Fine-tuning vs Long Context vs Cache-Augmented
| Dimensie | RAG | Fine-tuning | Long context | Cache-augmented (CAG) |
|---|---|---|---|---|
| Best voor | Veranderende kennis; grote corpora; citaten nodig | Stijl, formaat, domeinspecifiek redeneren | Enkel-document Q&A; eenmalige samenvatting | Kleine, stabiele kennisbank (< 100K tokens) |
| Slecht voor | Vaardigheden die nieuw gedrag vereisen (toon, formaat) | Vaak veranderende feiten | Corpora > 200K tokens; kostgevoelige workloads | Alles wat vaak verandert |
| Setup-kosten | Dagen | Weken + dataset-curatie | Uren | Uren |
| Per-query kosten | Laag (1–5 cent) | Laag | Hoog (long context tokens tikken aan) | Laag (gecached) |
| Update-latency | Seconden (herembed één doc) | Dagen (hertrainen) | Direct (wijzig de prompt) | Minuten (cache rebuilden) |
| Auditbaarheid | Hoog — citeer chunks | Laag — kennis in gewichten | Medium — context zichtbaar maar enorm | Medium |
Eerlijk oordeel
Kies RAG voor bijna elke business case met privé, veranderende, citeerbare data. Kies fine-tuning wanneer het model anders moet gedragen (toon, gestructureerde uitvoer, domeinredenering) — en combineer met RAG. Kies long context bij één groot document en klein queryvolume. Kies CAG alleen voor kleine, stabiele kennisbanken waar hergebruik van dezelfde gecachte context loont.
Kosten & Prestaties
| Component | Kosten (2026) | Latency | Notities |
|---|---|---|---|
| OpenAI text-embedding-3-small | $0.02 / 1M tokens | ~50 ms | Standaardkeuze; 1.536 dims |
| OpenAI text-embedding-3-large | $0.13 / 1M tokens | ~80 ms | 3.072 dims; ~5% betere kwaliteit |
| Voyage voyage-3-large | $0.12 / 1M tokens | ~60 ms | Sterk bij code, legal, finance |
| Cohere Rerank v3 | $2 / 1K searches | ~150 ms | Herrangschikt 100 docs per search |
| pgvector op uw Postgres | Gratis (alleen compute) | 5–50 ms | Best tot ~10M vectoren |
| Qdrant Cloud (managed) | Vanaf €25 / maand | 10–30 ms | Sterke filtering, open source |
| Pinecone Standard | Vanaf $70 / maand | 10–30 ms | Serverless opties beschikbaar |
| Azure AI Search (Basic) | Vanaf €70 / maand | 20–80 ms | EU-regio, integreert met Azure OpenAI |
| GPT-4o-mini antwoord | $0.15 / $0.60 per 1M tokens (in/out) | 300–800 ms | Standaard voor de meeste RAG |
| Claude Sonnet 4 antwoord | $3 / $15 per 1M tokens | 500–1500 ms | Best voor genuanceerd gegrond redeneren |
Typische end-to-end query (productie)
Embed (50ms) + vector search (20ms) + rerank (150ms) + LLM (600ms) = ~800ms p50 latency, ~$0.002–$0.01 per query. De verborgen kosten die de meeste teams missen: opnieuw embedden van de corpus bij modelupgrades. 10M chunks van 200 tokens = 2B tokens × $0.02/1M = ~$40 per re-embed — goedkoop met kleine embeddings, pijnlijk met grote. Reken erop.
Verder gaan
Morgen
Draai Niveau 1 tegen 50 documenten van uw team. Meet: vindt het de juiste voor 10 echte vragen? U leert meer van één middag testen dan een week lezen.
Volgende maand
Ship Niveau 2 naar staging. Voeg een RAGAS evaluatieharnas toe. A/B-test twee embedding-modellen op uw echte queries. Kies tussen pgvector (als u al Postgres heeft) en Qdrant/Pinecone (als u schaal nodig heeft).
Lange termijn
Verken GraphRAG (Microsoft), Contextual Retrieval (Anthropic), HyDE, RAG-Fusion, en Adaptive RAG. Lees de originele Lewis et al. paper en volg Eugene Yan's RAG patterns.
Geselecteerde bronnen
- Lewis et al. (2020) — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (de originele paper)
- Anthropic — Contextual Retrieval (een 2024-techniek die retrieval-fouten 49% verlaagt)
- Eugene Yan — Patterns for Building LLM-based Systems & Products (de meest geciteerde praktische gids)
- RAGAS — RAG-evaluatiebibliotheek
- LlamaIndex docs (het meest RAG-gerichte framework)
- Azure AI Search RAG-overzicht (productiepatronen voor Microsoft-stack)
Zelfcheck: heeft u het geleerd?
1. Waarom verslaat RAG meestal fine-tuning voor bedrijfskennis?
Antwoord: Bedrijfskennis verandert constant (beleid, prijzen, medewerkers). Fine-tuning bakt feiten in modelgewichten — elke wijziging betekent hertrainen. RAG laat u één document in seconden opnieuw embedden en het model ziet de nieuwe versie bij de volgende query.
2. Wat is het verschil tussen retrieval en re-ranking?
Antwoord: Retrieval is snel en bij benadering — vindt ~20 kandidaat-chunks via vectorgelijkenis in tientallen milliseconden. Re-ranking is langzamer en preciezer — gebruikt een cross-encoder om werkelijke relevantie te scoren en houdt de top 3–5. Zonder re-ranking zit de meest relevante chunk vaak in uw top-20 maar niet op positie 1.
3. Uw RAG-systeem geeft chunks terug maar de antwoorden zijn fout. Waar kijkt u eerst?
Antwoord: Inspecteer de werkelijke chunks die naar het LLM gaan. 80% van de tijd is het antwoord: de juiste chunk werd niet opgehaald (te agressieve chunking, verkeerd embedding-model, ontbrekend metadata-filter, geen re-ranking). 15%: de chunks zijn goed maar de prompt forceert geen grounding. Slechts 5% is "het LLM hallucineerde ondanks goede context."
4. U bedient 10 klanten vanuit één RAG. Hoe voorkomt u dat klant A de documenten van klant B ziet?
Antwoord: Metadata-filter op tenant_id toegepast vóór vector search. Elke chunk-metadata bevat de tenant; elke query stuurt de aanvragende tenant mee; de vector DB zoekt alleen binnen de vectoren van die tenant. Vertrouw nooit op het LLM om te filteren — filter op databaseniveau.
5. Wat is fout aan deze code?
chunks = db.query(query_embeddings=[q], n_results=50)
context = "\n".join(chunks)
prompt = f"Beantwoord: {vraag}\nContext: {context}"Antwoord: Drie problemen. (1) 50 chunks is te veel — het LLM verliest focus. Haal 20 op, herrangschik naar 3–5. (2) Geen grounding-instructie — het LLM wordt niet verteld alleen uit context te antwoorden. (3) Geen fallback bij lage scores — het model improviseert. Ook: "\n".join vernietigt chunkgrenzen; gebruik "\n\n---\n\n".
6. Wanneer kiest u long-context LLMs boven RAG?
Antwoord: Wanneer u één document heeft (onder 200K tokens), laag queryvolume, en het model erover moet redeneren. Voorbeelden: één jaarverslag samenvatten, vragen beantwoorden over één lang contract, code review van één repo. Voor al het andere is RAG goedkoper, sneller en accurater.
7. Ontwerp een RAG voor een interne HR-assistent die de persoonlijke data van 200 medewerkers verwerkt. Welke drie dingen doet u anders dan een generieke RAG?
Antwoord: (1) Per-medewerker metadata-filtering — elke chunk getagd met employee_id, query gefilterd zodat het LLM alleen de data van de vragende medewerker ziet. (2) Draai alles in uw eigen Azure-tenant in EU-regio — Azure OpenAI voor het LLM, Azure AI Search voor vectoren, geen externe API's. (3) Strikte audit-logging — elke query logt de gebruiker, opgehaalde chunks, prompt en antwoord, bewaard volgens AVG-regels. Plus een deny-list voor gevoelige acties ("nooit het salaris van een andere medewerker onthullen").
Veelgestelde vragen
Waar staat RAG voor?
RAG staat voor Retrieval-Augmented Generation. Geïntroduceerd door Lewis et al. bij Facebook AI Research in mei 2020.
Wanneer gebruik ik RAG in plaats van fine-tuning?
Gebruik RAG als data vaak verandert, u citaten nodig heeft, of meer dan een paar duizend documenten heeft. Gebruik fine-tuning voor gedrag dat het model moet leren (stijl, formaat, domeinredenering).
Heb ik een vector database nodig voor RAG?
Voor prototypes nee — NumPy in geheugen werkt. Voor productie ja — pgvector, Qdrant, Pinecone, Azure AI Search, Weaviate, Milvus of Chroma.
Hoeveel kost RAG?
$0.02 per 1M tokens voor OpenAI embeddings (2026), $25–$70/maand voor gehoste vector DB's, $0.001–$0.01 per query end-to-end. Verborgen kosten: opnieuw embedden bij modelupgrades.
Waarom geeft RAG soms foute antwoorden?
Meestal retrieval-falen: verkeerde chunk opgehaald, geen re-ranking, geen metadata-filter, of geen grounding-instructie in de prompt. Inspecteer de chunks voordat u het LLM de schuld geeft.
Wat is het verschil tussen RAG en een AI-agent?
RAG is een retrieval-patroon. Een agent is een systeem dat beslist welke tools (inclusief RAG) aan te roepen. De meeste productie-agents gebruiken RAG als één van hun tools.
Wat is chunking in RAG?
Documenten splitsen in kleinere stukken (meestal 200–1.000 tokens) voor embedden. Goede chunking respecteert paragrafen, koppen en codeblokken.
Wat is re-ranking en heb ik het nodig?
Een tweede-pass model dat top-20 retrievals scoort op werkelijke relevantie en de beste 3–5 behoudt. Verhoogt retrieval-kwaliteit 20–30% in productie. Ja, u heeft het bijna altijd nodig.
Kan RAG met privé of compliance-gevoelige data?
Ja — dat is de sterkste use case. Draai embeddings en vector DB in uw eigen Azure/AWS-regio, houd documenten in uw tenant, route LLM via Azure OpenAI of een zelf-gehost model.
Wat is het verschil tussen RAG en long-context LLMs?
Long-context laat u één groot document in een prompt plakken. RAG schaalt naar miljoenen documenten, kost minder per query, en blijft accuraat voorbij 100K tokens aan context.
Volgende leesstuk: hoe RAG in de volledige agent-stack past
RAG is één van zeven vaardigheden die een productie-agent engineer nodig heeft. Lees Van Prompt Engineer naar Agent Engineer: De 7 Vaardigheden die Er Echt Toe Doen om te zien hoe retrieval verbindt met tool contracts, betrouwbaarheid, beveiliging en observability.
Klaar om dit in productie te brengen?
IITS bouwt productieklare Azure data- en AI-systemen voor Nederlandse bedrijven. Vaste prijzen, 2-weken pilots, EU-region Azure.
Plan een strategiegesprek →