De klant zegt: "We willen onze bedrijfsdocumentatie uploaden in GPT-5 / Claude / Llama, zodat het vragen van onze medewerkers / klanten / partners beantwoordt." Een helft denkt aan fine-tuning, een andere helft aan RAG, en een derde helft aan een onduidelijke mix. Dit artikel is een beslissingskader voor de eerste workshop: wanneer RAG, wanneer fine-tuning, wanneer combinatie, en wanneer u beter een half jaar moet wachten en niets uitrolt.
Twee werelden, twee doelen
**RAG (Retrieval-Augmented Generation):** - Data zijn extern, het model ziet ze niet tijdens training - Bij inference krijgt het model de vraag + relevante stukjes data als context - "Geef me de 5 meest relevante alinea's uit de documentatie die vraag X beantwoorden" → sturen we naar het model - Het model antwoordt met inachtneming van de exacte documentatie, kan de bron citeren
**Fine-tuning:** - Data zijn ingebakken in de gewichten van het model tijdens training - Bij inference "herinnert" het model de data (of in elk geval hun statistische weerspiegeling) - Het model antwoordt met stijl / format / domeinkennis die we het geleerd hebben - De oorspronkelijke databron is NIET toegankelijk bij inference, alleen de parametrische representatie ervan
Deze twee werelden **lossen niet hetzelfde probleem op.** Meest voorkomende fout van klanten: ze kiezen voor fine-tuning terwijl hun werkelijke probleem RAG vereist.
Test: wat is uw taak?
Beantwoord deze vier vragen:
1. Zoekt u FEITEN in de data, of leert u STIJL aan?
- **Feiten** ("Wat is ons uurtarief voor klant X?", "Wat zijn de parameters van machine Y?") → **RAG**. Een feit moet exact uit een autoritatieve bron worden gehaald. Een fine-tuned model verzint een feit (hallucinatie is een onvoorspelbare functie van trainingsdata).
- **Stijl** ("Schrijf in formele juridische taal", "Antwoord in het gestructureerde formaat van onze technische rapportages") → **fine-tuning** kan helpen. RAG met de juiste system prompts haalt vaak 80–90% van hetzelfde resultaat.
2. Hoe vaak veranderen de data?
- **Dagelijks / wekelijks** → **RAG**. Het model retrainen bij elke data-wijziging kost $50–500 en 2–8 uur. Een RAG-knowledge-base reindexeren = 5 minuten, € 0,5.
- **Maandelijks / per kwartaal** → beide. RAG is even comfortabel.
- **Eens per 2+ jaar** → fine-tuning is overweegbaar, mits stabiele domeinkennis (medische protocollen, wettelijke codes, technische normen).
3. Moet het antwoord auditeerbaar zijn?
- **Ja (gereguleerde sectoren)** → **RAG is vrijwel verplicht**. De klant moet kunnen aantonen: "Het model zei X omdat het Y zag in document Z." Een fine-tuned model "zei X" zonder dat aangetoond kan worden waar het dat vandaan haalt.
- **Nee** → fine-tuning komt in beeld.
4. Welk datavolume hebt u?
- **< 100k tokens** → geen RAG noch fine-tuning. Plaats ze direct in de system prompt van een model met 200k context window (Claude Sonnet 4.6, Gemini 2.5 Pro). Eenvoudigst, snelst.
- **100k – 10M tokens** → **RAG** is optimaal. Een vectorindex over 1–10M tokens is 200 MB geheugen, sub-100 ms latency.
- **10M – 1B tokens** → RAG werkt, maar vereist een gesofisticeerder architectuur (multi-stage retrieval, hybrid search, reranking). Fine-tuning als ondersteuning, niet als vervanging.
- **> 1B tokens** → fine-tuning als pre-training step + RAG bovenop.
Wanneer fine-tuning eenduidig wint
1. Domeinjargon / terminologie
Centraal-Europese jurisprudentie, medisch Latijn, technische afkortingen binnen uw bedrijf ("PVRZ" = naam van een productprotocol dat zelfs Google niet raadt). Het basismodel kent het niet. Fine-tuning leert het hem aan.
Voorbeeld: Mistral 7B fine-tuned op 5.000 voorbeelden van juridische documentatie in het Nederlands → antwoordt in correct juridisch taalgebruik, kent terminologie als "verweerder", "verzoeker", "schikking", "matiging van de sanctie" in de juiste context. Het basismodel schrijft in Wikipedia-stijl.
Kosten: SFT op 5.000 voorbeelden, RTX 4090, ~6 uur, ~€ 10 elektriciteit. Reëel in de praktijk.
2. Gestructureerde output met strikt formaat
"Antwoord altijd in JSON volgens dit schema." Een system prompt haalt 95% nauwkeurigheid. Fine-tuning haalt 99,5+% nauwkeurigheid. In productiesystemen is het verschil 95% vs. 99,5% van levensbelang — bij 95% hebt u 5% parse-errors die door de hele downstream pipeline lekken.
3. Snelheid (latency + cost) bij high-throughput
RAG = embedding (50 ms) + retrieval (100 ms) + LLM met uitgebreide prompt (8.000 tokens × 100 RPS = expensive). Fine-tuned model = LLM met een korte prompt (500 tokens × 100 RPS).
Bij >100 RPS-workloads is fine-tuning 5–10× goedkoper. Bij <10 RPS maakt het niet uit.
4. Off-line / on-device deployment
Een mobiele client kan geen RAG-knowledge-base aanroepen. Een fine-tuned 1B–4B model draaiend op het apparaat (CoreML, ExecuTorch, llama.cpp) — heeft alle domeinkennis ingebakken, geen internet nodig.
Wanneer RAG eenduidig wint
1. Data verandert snel
Customer support-knowledge-base, FAQ, product documentation, internal wikis. Een nieuw document toevoegen = reindex (seconden). Fine-tuning zou een nieuwe training per dag betekenen.
2. Citaties zijn verplicht
Compliance, recht, geneeskunde, financieel advies. De klant moet zien: "Het model denkt X omdat artikel 12 lid 3 van wet Y dat zo bepaalt." Fine-tuning produceert geen citaties — produceert een geparafraseerd antwoord zonder audit trail.
3. Personalisatie per gebruiker
Gebruiker A ziet zijn eigen data, gebruiker B ziet zijn eigen data. Het model is hetzelfde, maar de knowledge base wordt per gebruiker gefilterd. Een fine-tuned model kan niet wisselen wat het weet afhankelijk van de gebruiker.
4. Multi-language / multi-domain
De klant heeft documentatie in NL, EN, DE en wil antwoorden in de taal van de vraag. RAG: één model, 3 knowledge bases (of 1 base met taalmetadata). Fine-tuning: 3 modellen, of complexere multi-task training.
Hybride aanpak — meest voorkomende productierealiteit
In reële deployments in 2026 wordt typisch gecombineerd:
1. **Basismodel:** Claude Sonnet 4.6 of Llama 3.3 70B (open-weight) 2. **Light fine-tuning (LoRA):** op 1–5k voorbeelden domain-specific Q&A, leert het model "hoe te antwoorden" in stijl en formaat van uw bedrijf 3. **RAG:** over live data (documenten, database, ticketsystem) 4. **System prompt:** vat context, identity, guardrails samen 5. **Reranker:** BGE-Reranker, Cohere Rerank — herordent na retrieval de stukken, zodat de meest relevante bovenaan staan
Deze stack lost op: het model kent "hoe te antwoorden" (fine-tune), kent "actuele data" (RAG), kent "wie we zijn en welke regels gelden" (system prompt). Plus broncitaties, plus auditeerbaarheid.
Concrete tooling 2026
RAG-stack — onze standaardkeuze
- **Vector-DB:** Qdrant (self-hosted) of Weaviate. PostgreSQL + pgvector voor kleine use-cases (< 1M vectoren).
- **Embedding model:** BGE-M3 (open, NL/EN/DE multilingual) of OpenAI text-embedding-3-large voor cloud-only setups.
- **Reranker:** BGE-Reranker-Large of Cohere Rerank 3.
- **Orchestration:** LangChain of LlamaIndex voor snelle PoC, eigen Python-code voor productie (de LangChain abstraction layer wordt tax bij grotere systemen).
- **Document parsing:** Docling (IBM, open) of Unstructured.io voor PDF/DOCX/HTML.
- **Chunking-strategie:** semantic chunking (250–500 tokens per chunk), 10–20% overlap, metadata-rich.
Fine-tuning-stack — wanneer we het gebruiken
- **Framework:** Unsloth (2–5× sneller dan vanilla TRL), HuggingFace TRL voor standaard workflows.
- **Method:** LoRA (rank 16–32) of QLoRA voor VRAM-constrained setups. Full fine-tuning alleen bij >100k voorbeelden.
- **Base model:** Llama 3.3 70B, Mistral Small 3 (22B), Qwen 2.5 32B afhankelijk van licentie + taal.
- **Eval:** Custom eval set met 200+ vragen + standard benchmarks (MMLU, HellaSwag) voor regressiedetectie.
- **Serving:** vLLM of SGLang voor throughput, llama.cpp voor lokaal / on-device.
Kosten — reële cijfers 2026
RAG-deployment (typische B2B-kennisbank)
- 50k documenten, 10M tokens, 500 RPS peak
- Vector-DB: Qdrant op een 32GB VPS, $80/maand
- Embedding (BGE-M3 self-hosted): RTX 4090-server, $200/maand amortisatie
- LLM (Claude Sonnet 4.6): ~$3/M input tokens, ~$15/M output tokens. Bij 500 RPS met gemiddeld 8k input + 500 output → **$4.500–6.000 maandelijks**
- Totaal: **~$5.500–6.500/maand** plus eenmalige initialisatie $5.000–15.000
Of een volledig lokale stack met Llama 3.3 70B op 2× H100: hardware $80.000–120.000 eenmalig, prevoer $300/maand elektra + onderhoud. Terugverdientijd t.o.v. cloud-only: 12–18 maanden.
Fine-tuning-deployment
- Eenmalige training (LoRA, 5.000 voorbeelden, Llama 3.3 70B): $30–80 cloud-GPU, of $5 elektra op een eigen RTX 4090
- Eval + iteration cycle: 3–6 iteraties × $50 = $150–300
- Hosting van het fine-tuned model: gelijk aan het basismodel (LoRA-opslag is nul bij merged weights)
- Onderhoud: elke 3–6 maanden retrainen wanneer het domein wijzigt
Reële kosten van fine-tuning bij een productiesysteem: **< $1.000 per jaar**, mits u een team hebt dat het onderhoudt. Verborgen kosten zijn "iemand die een eval kan doen en de resultaten interpreteert" — niet de GPU.
Wanneer geen van beide inzetten
- Data zijn klein (< 50 documenten) → gebruik direct een cloud-LLM (Claude Project, GPT Custom GPT, Gemini Workspace), geen custom infra.
- Het team heeft geen MLOps-capaciteit en u bent niet bereid 6+ maanden in een data engineer te investeren.
- Het domein verandert snel (start-up MVP, productexperimenten) → wacht tot de data stabiliseren.
- Klantgegevens zijn sterk gereguleerd en u hebt geen DPIA (GDPR Impact Assessment) klaar — los eerst compliance op, deploy daarna.
---
*We doen RAG én fine-tuning als onderdeel van AI-integraties. Overweegt u LLM-inzet over een bedrijfsbasis, dan loopt het eerste consult (90 minuten) deze vier beslissingsvragen door op uw werkelijke use-case en geeft u een indicatieve architectuur en budget voordat u zich aan één van beide paden vastlegt.*