RAG uitgelegd: Oorsprong en Fundamentals (Nederlands (Dutch))

RAG uitgelegd: Oorsprong en Fundamentals

Saturday, 22 November 2025

//

16 minute read

Ooit gezocht naar "workment guide" en kreeg niets, ook al is er een artikel over "publishing to production"? RAG (Retrieval-Augmented Generation) lost dit op door het begrijpen van betekenis, niet alleen trefwoorden. Deze serie laat je zien hoe RAG kwam, hoe het werkt onder de kap, en hoe je productiesystemen te bouwen. Van semantische zoekopdracht naar AI-aangedreven Q&A met citaten alle met werken C# code voorbeelden.

Inleiding

Serienavigatie: Dit is deel 1 van de RAG (Retrieval-Augmented Generation) serie:

RAG (Retrieval-Augmented Generation) werd ontwikkeld om AI slimmer te maken LLM's toegang te geven tot informatie waar ze niet op getraind waren. Maar hier is wat interessant is: de technologie opent mogelijkheden ver voorbij AI chatbots. Het geeft semantische zoekopdrachten op websites, content aanbeveling, schrijfhulp en kennismanagement.

De dubbele aard: RAG kan klanten helpen (beter zoeken, nauwkeurige antwoorden met citaten) of ze te exploiteren (manipulatieve aanbevelingen, het begraven van negatieve recensies, surface upsell content). Het verschil is niet de technologie het's intentie. Een semantische zoekopdracht die gebruikers helpt vinden wat ze eigenlijk nodig hebben? Geweldig. Een die prioriteert wat maakt u het meeste geld terwijl u verschijnt behulpzaam? Dat is donker patroon gebied, en het is waarom begrijpen hoe dit werkt belangrijk.

Hier is de waarheid over RAG: Het klinkt intimiderend. Vector inbeddingen? Transformer modellen? KV caches? Maar net als al het andere in software, het is gewoon over het begrijpen hoe het werkt. Je hoeft niet te weten de wiskunde achter transformator architecturen niet meer dan je nodig hebt om assemblage te begrijpen om C# te schrijven.

RAG in drie stappen:

  1. Tekst omzetten in getallen (invoegsels)
  2. Soortgelijke nummers zoeken (vector zoeken)
  3. Gebruik wat je gevonden hebt (resultaten weergeven of feed naar LLM)

De rest zijn de details van de uitvoering.

Deze serie laat zien hoe je RAG-systemen kunt bouwen met C#-code. Geen handgolven. Geen veronderstellingen. Alleen de stukken en hoe ze bij elkaar passen.

Wat je zult leren in deze serie:

  • Deel 1 (dit artikel): Hoe RAG tot stand kwam en waarom het er toe doet
  • Deel 2: Complete technische architectuur en LLM interne
  • Deel 3: Bouwen van echte systemen met codevoorbeelden

Later zal ik je ook laten zien hoe je complete RAG systemen kunt bouwen, waaronder:

Wat is RAG?

Retrieval-Augmented Generation: Vind relevante informatie, gebruik het dan.

flowchart LR
    A[User Question] --> B[Retrieve Relevant Info]
    B --> C[Retrieved Documents/Context]
    C --> D[Generate Response]
    A --> D
    D --> E[Grounded, Accurate Answer]

    style B stroke:#f9f,stroke-width:2px
    style D stroke:#bbf,stroke-width:2px

Zonder RAG: Gebruiker vraagt → LLM gissingen uit het geheugen → zou kunnen hallucineren

Met RAG: Gebruiker vraagt → Vind relevante documenten → LLM antwoorden met behulp van die documenten → gegrond in werkelijkheid

// Without RAG: Hope the LLM knows
var answer = await llm.GenerateAsync("How do I deploy Docker?");
// Risk: Might make up outdated or wrong steps

// With RAG: Give it the docs
var relevantDocs = await vectorSearch.FindSimilar("How do I deploy Docker?");
var context = string.Join("\n", relevantDocs.Select(d => d.Text));
var answer = await llm.GenerateAsync($"Context: {context}\n\nQuestion: How do I deploy Docker?");
// Result: Answer based on YOUR actual Docker deployment docs

Belangrijkste inzicht: Aparte kennisopslag (search) van redeneren (LLM). Update uw documenten, zoek blijft actueel. Geen omscholing nodig.

Waar kwam RAG vandaan?

RAG bouwt voort op tientallen jaren zoeken en NLP onderzoek. Het begrijpen van deze geschiedenis helpt u te begrijpen waarom RAG is ontworpen zoals het is en welke problemen het oplost.

Traditioneel zoeken (voor 2010)

Keyword-gebaseerde zoekopdracht:

  • TF-IDF: term frequency × invers document frequency - common words matter less
  • BM25: Probabilistic ranking - nog steeds de basis voor zoekterm zoeken
  • Fuzzy matching:
    • Soundex: Fonetisch algoritme ("Smith" komt overeen met "Smythe")
    • Levenshtein-afstand: Bewerk afstand (hoeveel invoegsels/deleties/subinstellingen)
    • N-Gramsunit synonyms for matching user input: Karakter/woordsequenties voor gedeeltelijke matching

Het probleem: Deze kwamen overeen tekens, niet Betekenis. Zoek "container orkestratie" en je zult niet vinden "Dokter Swarm" tenzij die exacte woorden verschijnen. Ze konden omgaan met typefouten, maar niet met semantiek.

Early Question Beantwoording (2010s)

Watson (IBM, 2011):

  • Gecombineerde opzoeking met op regels gebaseerde redenering
  • Won Jeopardy! maar vereist enorme handgemaakte kennis engineering
  • Nog steeds sterk afhankelijk van trefwoord matching

Het lezen van begrijpelijke modellen:

  • Kan antwoorden uit opgegeven passages halen
  • Maar je moest ze eerst de juiste doorgang geven.
  • Geen semantische zoektocht om die passage te vinden

De Deep Learning Revolution (2017+)

Transformatoren (2017): "Aandacht is alles wat je nodig hebt"

  • Neurale netwerken die de context kunnen begrijpen
  • Stichting voor alles wat volgde

BERT (2018):

  • Contextueel begrip van taal
  • "Bank" betekent verschillende dingen in "rivierbank" vs "reddende bank"
  • Kan inbeddingen genereren die de betekenis bevatten

GPT-2/3 (2019/2020):

  • Grote taalmodellen die coherente tekst kunnen genereren
  • Maar beperkt tot hun trainingsgegevens
  • Hallucinatieproblemen doen zich voor

Dichte vectorrepresentaties:

  • Tekst → betekenisvolle getallen in hoogdimensionale ruimte
  • Soortgelijke betekenissen → nabijgelegen vectoren
  • Dit maakte semantisch zoeken mogelijk

BART (Facebook AI, oktober 2019):

  • Bidirectionele en Auto-regressieve Transformer van Mike Lewis et al.
  • Gecombineerde BERT-achtige encoder met GPT-achtige decoder
  • Denoising autoencoder getraind door het corrumperen van tekst vervolgens reconstrueren
  • Uitstekend voor het genereren van tekst en het begrijpen van taken
  • Werd de basis voor RAG

M2M-100 (Facebook AI, oktober 2020):

  • Eerste veel-tot-veel meertalige vertaalmodel
  • Directe vertaling tussen 100 talen zonder Engels pivot
  • 2.200 taalrichtingen (10x meer dan vorige modellen)
  • Aangetoonde transformatoren kunnen enorme meertalige taken uitvoeren

Real-world voorbeeld: Mijn neurale machine vertaling hulpmiddel maakt gebruik van BART als fallback vertaalmodel wanneer primaire diensten niet beschikbaar zijn, waaruit blijkt hoe deze transformator-gebaseerde modellen praktische bouwstenen werden voor productiesystemen.

De geboorte van Modern RAG (mei 2020)

Het seminal paper "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" door Patrick Lewis et al. (Facebook AI Research) formeel geïntroduceerd RAG, direct bouwen op BART:

Wat ze samenvoegden:

  • Dense Passage Retrieval (DPR) - geleerde vectorrepresentaties, geen trefwoorden
  • BART generator - het seq2seq model uit 2019
  • End-to-end differentieerbare architectuur - samen ophalen en genereren

De resultaten: RAG-systemen overtreffen veel grotere modellen op kennisintensieve taken en zijn efficiënter en up-to-date. U kunt de kennisbasis bijwerken zonder het model om te zetten.

Waarom RAG explodeerde (2023-Present)

ChatGPT, GPT-4 en Claude maakten RAG essentieel:

  1. Hallucinatiesprobleem - LLM's maken met vertrouwen feiten op. RAG redenen antwoorden in echte documenten.
  2. Knowledge Cutoff - LLM's opgeleid op 2021 gegevens weten niet over 2024 evenementen. RAG maakt gebruik van de huidige documenten.
  3. Particuliere gegevens - LLM's hebben geen toegang tot de interne documenten van uw bedrijf.
  4. Kosten - Fine-tuning LLM's zijn duur ($10K-100K+). RAG is goedkoop (opslag + inbeddingen).
  5. Verklaarbaarheid - RAG kan bronnen noemen, waardoor het te controleren en betrouwbaar is.

Vandaag (2024-2025): RAG is de feitelijke standaard voor productie-AI-systemen die nauwkeurigheid en auditeerbaarheid nodig hebben. Elke grote AI-onderneming biedt RAG-tooling.

Hoe RAG werkt: De grote foto

Voordat we diep in de technische details duiken (die we in deel 2 zullen behandelen), laten we de high-level workflow begrijpen.

De drie fasen

RAG-systemen functioneren in drie verschillende fasen:

Fase 1: Indexering (één-tijdsopstelling)

flowchart LR
    A[Your Documents] --> B[Split into Chunks]
    B --> C[Generate Embeddings]
    C --> D[Store in Vector DB]

    style C stroke:#f9f,stroke-width:2px
    style D stroke:#bbf,stroke-width:2px

Wat er gebeurt:

  1. Neem uw kennisbasis (docs, blog posts, handleidingen)
  2. Opsplitsen in hanteerbare stukken (paragrafen, secties)
  3. Converteer elke brok naar een vector inbedding (array van getallen)
  4. Store vectoren in een database geoptimaliseerd voor gelijkenis zoeken

Sleutelbegrip: Soortgelijke betekenissen produceren vergelijkbare vectoren, dus "Docker container" en "containerization platform" eindigen dicht bij elkaar in vectorruimte.

Fase 2: Retrieval (Every Query)

flowchart LR
    A[User Question] --> B[Generate Query Embedding]
    B --> C[Search Vector DB]
    C --> D[Top K Most Similar Chunks]

    style B stroke:#f9f,stroke-width:2px
    style C stroke:#bbf,stroke-width:2px

Wat er gebeurt:

  1. Gebruiker stelt een vraag
  2. Vraag omzetten naar een vector (hetzelfde model gebruikt voor het indexeren)
  3. Zoek de meeste vergelijkbare vectoren in de database
  4. Geef de bovenste K meest relevante brokken terug (meestal 3-10)

Waarom het werkt: "Hoe gebruik ik containers?" (query) is semantisch vergelijkbaar met brokken over Docker-implementatie, zelfs als de exacte woorden verschillen.

Fase 3: Generatie (Every Query)

flowchart TB
    A[User Question] --> B[Build Prompt]
    C[Retrieved Context] --> B
    B --> D[LLM]
    D --> E[Generated Answer with Citations]

    style B stroke:#f9f,stroke-width:2px
    style D stroke:#bbf,stroke-width:2px

Wat er gebeurt:

  1. Neem de vraag van de gebruiker
  2. Neem de opgehaalde context brokken
  3. Teken een prompt: "Geef deze context..., beantwoord deze vraag..."
  4. Stuur naar LLM voor generatie
  5. LLM levert antwoord op grond van de verstrekte context

De magie: De LLM kan niet hallucineren feiten die niet in de context. Het kan alleen synthetiseren en uitleggen wat er wordt verstrekt.

Een eenvoudig voorbeeld

Laten we een query traceren via het systeem:

Gebruiker vraagt: "Hoe gebruik ik Docker Compose?"

Stap 1 - Terugwinning:

Query embedding: [0.234, -0.891, 0.567, ...]

Search vector DB for similar embeddings...

Retrieved chunks:
1. "Docker Compose is a tool for defining multi-container applications..." (similarity: 0.92)
2. "To use Docker Compose, create a docker-compose.yml file..." (similarity: 0.87)
3. "The docker-compose up command starts all services..." (similarity: 0.83)

Stap 2 - Generatie:

Prompt to LLM:
"Context:
[1] Docker Compose is a tool for defining multi-container applications...
[2] To use Docker Compose, create a docker-compose.yml file...
[3] The docker-compose up command starts all services...

Question: How do I use Docker Compose?

Answer (use the context above):"

LLM Response:
"To use Docker Compose [1], start by creating a docker-compose.yml file [2] that
defines your services. Then run 'docker-compose up' to start all services [3]..."

Resultaat: Nauwkeurig antwoord met impliciete citaten uit uw documentatie.

RAG vs. Andere benaderingen

Om te begrijpen wanneer RAG (en wanneer niet) moet worden gebruikt, moet het worden vergeleken met alternatieven.

RAG vs. Fine-Tuning

Fine-Tuning |--------|-----|-------------| | Kennisupdates Instant (net updaten van de kennisbasis) Vereist omscholing | Kosten Laag (opbergen + inbedding) Hoog (GPU trainingstijd) | Nauwkeurigheid Geaard in bronnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | Aanpassen Deep model adaptation | Verklaarbaarheid Hoog (kan bronnen aanhalen) Laag (zwarte doos) | Beste voor Knowledge-intensieve taken Stijl/format adaptatie

Wanneer Fine-Tuning te gebruiken:

  • Je hebt het model nodig om een specifiek te leren stijl of formaat
  • Je hebt een grote, schone dataset
  • Je hebt het model nodig om te internaliseren patronen, geen feiten
  • Voorbeeld: GPT laten schrijven als Shakespeare

Wanneer wordt RAG gebruikt:

  • Je hebt het nodig. feitelijke nauwkeurigheid met aanhalingstekens
  • Uw kennisbasis verandert vaak
  • U heeft privé-/privé-gegevens
  • Kosten en eenvoud
  • Voorbeeld: Customer support chatbot (de documenten van mijn bedrijf wisselen wekelijks)

Kun je beide combineren? Fine-tune voor stijl, RAG voor feiten.

RAG vs. Lange context vensters

Moderne LLM's hebben enorme contextvensters (GPT-4: 128K tokens, Claude: 200K tokens). Waarom niet gewoon al uw documenten in de context dumpen?

Problemen met een lange context:

  1. Kosten: Prijzen schalen met tokens - $10-100 per query voegt snel
  2. Matigheid: Het verwerken van 100K tokens kost tijd
  3. Verloren in het midden: LLM's worstelen om informatie te gebruiken in het midden van lange contexten
  4. Verdunning: Relevante info wordt begraven in lawaai
  5. Praktische grenzen: Je kunt de documenten van je hele bedrijf niet in de context passen

Wanneer lange context zinvol is:

  • Enig groot document (bv., het analyseren van een contract)
  • Alles is relevant (niet nodig om te filteren)
  • Kosten zijn geen probleem.
  • Laag queryvolume

Wanneer RAG zinvol is:

  • Grote kennisbasis (miljoenen documenten)
  • Noodzaak om de relevante subgroep te vinden
  • Hoog queryvolume (kosten)
  • Real-time updates voor kennis

Beste praktijk: Gebruik RAG om de meest relevante inhoud te selecteren en gebruik dan een lange context voor die subset.

RAG vs. Prompting with Examples

Weinig schot prompt (voorbeelden geven in de prompt) is een eenvoudige basislijn.

Voorbeeldprompt:

Examples:
Q: What is Docker?
A: Docker is a containerization platform...

Q: How does Kubernetes work?
A: Kubernetes orchestrates containers...

Q: What is my new question?
A: [LLM generates answer]

Beperkingen:

  • Beperkt tot wat past in het contextvenster
  • Handmatige genezing van voorbeelden
  • Schaalt niet naar grote kennisbases
  • Geen semantische zoekopdracht - u kiest handmatig voorbeelden

RAG-verbetering:

  • Vindt automatisch de beste voorbeelden (via gelijkenis zoeken)
  • Schalen naar ongelimiteerde voorbeelden (alleen top K verzonden naar LLM)
  • Past aan query (verschillende query's halen verschillende voorbeelden)

Je kunt RAG zien als "geautomatiseerd weinig schot prompt op schaal."

Hybrid Search: RAG + Traditioneel zoeken

U kunt RAG combineren met traditionele full-text zoekopdrachten met behulp van onderlinge Rank Fusion (RRF).

Waarom hybride?

  • Semantisch zoeken: Great for conceptual matches ("error handling" vindt "exception management")
  • Zoeken naar zoekwoorden: Geweldig voor exacte termen ("Dokter Compose," "Entity Framework")
  • Hybride: Beste van beide werelden
public async Task<List<SearchResult>> HybridSearchAsync(string query)
{
    // Run both searches in parallel
    var semanticTask = SemanticSearchAsync(query, limit: 20);
    var keywordTask = KeywordSearchAsync(query, limit: 20);

    await Task.WhenAll(semanticTask, keywordTask);

    var semanticResults = await semanticTask;
    var keywordResults = await keywordTask;

    // Combine using Reciprocal Rank Fusion
    return ApplyRRF(semanticResults, keywordResults);
}

private List<SearchResult> ApplyRRF(
    List<SearchResult> list1,
    List<SearchResult> list2,
    int k = 60)
{
    var scores = new Dictionary<string, double>();

    // Score from first list
    for (int i = 0; i < list1.Count; i++)
    {
        var id = list1[i].Id;
        scores[id] = scores.GetValueOrDefault(id, 0) + 1.0 / (k + i + 1);
    }

    // Score from second list
    for (int i = 0; i < list2.Count; i++)
    {
        var id = list2[i].Id;
        scores[id] = scores.GetValueOrDefault(id, 0) + 1.0 / (k + i + 1);
    }

    // Merge and sort by combined score
    var allResults = list1.Concat(list2)
        .GroupBy(r => r.Id)
        .Select(g => g.First())
        .OrderByDescending(r => scores[r.Id])
        .ToList();

    return allResults;
}

Waarom RAG-zaken

Nu je begrijpt wat RAG is, waar het vandaan komt, en hoe het zich vergelijkt met alternatieven, is dit waarom het belangrijk is:

1. Democratie van AI

  • Je hebt geen $100K fine-tuning budget nodig.
  • Je hebt geen team van ML ingenieurs nodig.
  • Elke ontwikkelaar kan RAG-systemen bouwen met bestaande tools

2. Praktische nauwkeurigheid

  • Hallucinatie is het #1 probleem met LLM's in productie
  • RAG lost het op door in reële documenten te antwoorden
  • Verwijzingen maken het te controleren en betrouwbaar

3. Altijd up-to-date

  • Traditionele AI: Train eenmaal, kennis is bevroren
  • RAG: Update uw documenten, kennisupdates direct
  • Kritisch voor snel bewegende domeinen (tech, nieuws, regelgeving)

4. Privacy en controle

  • Uw gegevens blijven in uw infrastructuur
  • Kan volledig lokaal draaien (lokale inbeddingen + lokale LLM + lokale vector DB)
  • Geen gegevens verzonden naar OpenAI of andere cloudproviders

5. Kosten-effectief

  • Opslag is goedkoop (pennies per GB)
  • Inbeddingen zijn goedkoop (fracties van een procent per 1000 documenten)
  • Veel goedkoper dan fine-tuning of lange contextvensters

6. Veelzijdige toepassingen

  • Semantisch zoeken (geen LLM nodig!)
  • Q&A-systemen met aanhalingstekens
  • Inhoudsaanbeveling
  • Schrijfassistenten
  • Kennisbeheer
  • Documentatie-helpers
  • Onderzoeksassistenten

Conclusie: Van geschiedenis tot uitvoering

We hebben RAG's evolutie getraceerd:

  • Voor 2010: Keyword search (karakters, not meansing)
  • 2010: Het lezen van begrip (moet de juiste passage)
  • 2017-2020: Transformatoren en inbeddingen (betekenis → vectoren)
  • 2020: Modern RAG (retrieve + generate)
  • 2023-Present: Productiestandaard (hallucinatie + kosten + privacy)

Belangrijkste inzichten uit deel 1:

  • RAG scheidt kennisopslag (vector DB) van motivering (LLM)
  • Het lost het hallucinatieprobleem op door antwoorden in echte documenten op te nemen.
  • Het is goedkoper en flexibeler dan fine-tuning
  • Het werkt beter dan lange context voor grote kennisbases
  • Het is in wezen "geautomatiseerd weinig schot prompt op schaal"

Het mentale model in drie stappen:

  1. Tekst omzetten in getallen (invoegsels)
  2. Soortgelijke nummers zoeken (vector zoeken)
  3. Gebruik wat je gevonden hebt (display of feed naar LLM)

Al het andere is optimalisatie.

Doorgaan naar deel 2: Architectuur en Interne Zaken

Je begrijpt het nu. wat RAG is, waarom het van belang is, en waarbij Maar hoe werkt het eigenlijk onder de motorkap?

In Deel 2: RAG-architectuur en interne markt, we duiken diep in de technische details:

Volledige RAG-pijpleiding:

  • Fase 1: Indexering (tekstextractie, chunking-strategieën, inbeddingsgeneratie, vectoropslag)
  • Fase 2: Retrieval (query inbeddingen, gelijkenismetrics, reranking)
  • Fase 3: Generatie (prompte constructie, LLM-parameters, nabewerking)

LLM intern:

  • Wat zijn tokens en waarom ze belangrijk zijn voor RAG?
  • De KV-cache: Hoe LLM's de context onthouden
  • Contextvensters en tokenbeheerstrategieën
  • Optimaliseren van RAG voor token efficiëntie en kosten

Technische diepe duiken:

  • Vector databases en gelijkenis zoekalgoritmen
  • Inbedding modellen en normalisatie
  • Chunking strategieën die context behouden
  • Praktische codevoorbeelden in C#

Doorgaan naar deel 2: Architectuur en Interne Zaken →

Na deel 2 ben je klaar voor deel 3, waar we echte systemen bouwen, gemeenschappelijke uitdagingen oplossen en geavanceerde technieken zoals HyDE, multi-query RAG en contextuele compressie verkennen.

Middelen

Fundamentele papers:

Meer lezen:

Volgende in deze serie:

Ga verder naar deel 2 →

Finding related posts...
logo

© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.