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.

25 min read·2026-05-26·Foundation
Op deze pagina

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

1. VRAAG "Wat is ons retourbeleid?" 2. EMBEDDEN Tekst → vector [0.12, -0.83, ...] 3. VECTOR DATABASE — Zoeken op betekenis Vind top-K chunks dichtst bij de vraagvector pgvector · Qdrant · Pinecone · Azure AI Search 4. TOP-K CHUNKS 3–5 meest relevante document chunks 5. LLM Genereer antwoord gegrond in chunks gegrond antwoord terug naar gebruiker GEBRUIKER GEGRONDE LLM-AANROEP

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

DimensieRAGFine-tuningLong contextCache-augmented (CAG)
Best voorVeranderende kennis; grote corpora; citaten nodigStijl, formaat, domeinspecifiek redenerenEnkel-document Q&A; eenmalige samenvattingKleine, stabiele kennisbank (< 100K tokens)
Slecht voorVaardigheden die nieuw gedrag vereisen (toon, formaat)Vaak veranderende feitenCorpora > 200K tokens; kostgevoelige workloadsAlles wat vaak verandert
Setup-kostenDagenWeken + dataset-curatieUrenUren
Per-query kostenLaag (1–5 cent)LaagHoog (long context tokens tikken aan)Laag (gecached)
Update-latencySeconden (herembed één doc)Dagen (hertrainen)Direct (wijzig de prompt)Minuten (cache rebuilden)
AuditbaarheidHoog — citeer chunksLaag — kennis in gewichtenMedium — context zichtbaar maar enormMedium

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

ComponentKosten (2026)LatencyNotities
OpenAI text-embedding-3-small$0.02 / 1M tokens~50 msStandaardkeuze; 1.536 dims
OpenAI text-embedding-3-large$0.13 / 1M tokens~80 ms3.072 dims; ~5% betere kwaliteit
Voyage voyage-3-large$0.12 / 1M tokens~60 msSterk bij code, legal, finance
Cohere Rerank v3$2 / 1K searches~150 msHerrangschikt 100 docs per search
pgvector op uw PostgresGratis (alleen compute)5–50 msBest tot ~10M vectoren
Qdrant Cloud (managed)Vanaf €25 / maand10–30 msSterke filtering, open source
Pinecone StandardVanaf $70 / maand10–30 msServerless opties beschikbaar
Azure AI Search (Basic)Vanaf €70 / maand20–80 msEU-regio, integreert met Azure OpenAI
GPT-4o-mini antwoord$0.15 / $0.60 per 1M tokens (in/out)300–800 msStandaard voor de meeste RAG
Claude Sonnet 4 antwoord$3 / $15 per 1M tokens500–1500 msBest 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

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 →