RAG
Een RAG-kennisbank scopen: de DRE-score voor offertes
Voordat wij een RAG-build offreren, scoren we drie assen: documentverloop, de recall-target die de klant echt nodig heeft, en hoeveel experts een regressieset van vijftig vragen kunnen valideren.

De offerte die we mis hadden
Een logistiek bedrijf vroeg ons afgelopen voorjaar om een RAG-systeem boven op hun interne ops-documentatie. Zes weken, zeiden we. Drie engineers, vaste scope, evaluatie inbegrepen. Het getal klopte met een factor twee niet, en de reden was niet het embedding-model of de vector store. De reden was dat niemand bij de klant twee dagen kon gaan zitten om te valideren of de antwoorden ook echt klopten.
Dat project is opgeleverd. Het heeft elf weken geduurd. Wij hebben de overschrijding op ons genomen. Sindsdien lopen we voor elke RAG-build een klein werkblad door voordat we offreren, en het heeft ons behoed voor dezelfde valkuil.
Drie assen die de prijs echt bepalen
De interessante variabelen in een RAG-offerte zijn niet "hoeveel documenten" of "welk embedding-model". Dat zijn input voor een rekentool. De variabelen die de prijs bepalen zijn drie in getal, en we scoren ze elk op een schaal van 1 tot 5.
- D, documentverloop. Hoe snel de bronset verandert. Een statische kennisbank is goedkoop. Een map met PDF's die elke drie dagen een nieuwe revisie krijgt niet.
- R, recall-target. Wat het antwoord waard moet zijn. Intern "waar vind ik X" verdraagt een recall@5 rond de 0,80. Een compliance-antwoord dat aan een toezichthouder wordt voorgelezen niet.
- E, validatiecapaciteit van experts. Hoeveel uur per week de klant een domeinexpert voor de antwoorden kan zetten. Dit is de stille killer van RAG-projecten en de as die we bij die logistieke build hebben genegeerd.
Wij noemen het de DRE-score. We draaien hem voor de tweede meeting.
Documentverloop scoren
Je hebt geen enquête nodig. Staat de docs-map onder git, dan geeft dit je in dertig seconden een verdedigbaar getal:
git -C ./client-docs log \
--pretty=format: --name-only --since="6 months ago" \
| grep -v '^
| sort | uniq -c | sort -rn | head -20
Zitten ze in Confluence of Notion, trek dan de page-modified-datum op van de top 200 best bezochte pagina's. De vraag die we beantwoord willen zien is: hoeveel procent van de geïndexeerde set verandert in een gemiddelde maand? Onder de 2% is een D=1 (statisch). Boven de 25% een D=5 (levend document).
De D-score raakt niet alleen de kosten van opnieuw embedden. Hij raakt ook hoe snel je regressieset veroudert, hoe agressief je cachet, en of je een incrementele indexer nodig hebt of weg kunt komen met een nightly full rebuild.
Een recall-target zetten die je kunt verdedigen
"We willen dat het accuraat is" is geen recall-target. Het getal dat we afspreken is recall@k op een afgezonderde vragenset, gemeten met een framework als RAGAS of een zelfgebouwd equivalent. Het gesprek gaat zo:
Wat doet de gebruiker met het antwoord? Even doorlezen, in een reply plakken, of opnemen in een contract?
Elk van die drie heeft een andere acceptabele miss-rate. Interne triage werkt prima op een recall@5 van 0,80. Antwoorden naar klanten brengen we naar 0,90. Compliance- en contracttaal tekenen we niet af onder 0,95, en dan nog alleen met een citation gate die weigert te antwoorden als de retrieval-confidence wegzakt.
R is de recall-target maal vijf, afgerond. R=4 betekent recall@5 van 0,80. R=5 betekent 0,95. Een hogere R koopt meer tijd voor retrieval-tuning: hybrid search, contextual chunking, re-ranking. Het stuk van Anthropic over contextual retrieval is een goede basis voor wat zonder exotische tooling haalbaar is.
De expert-bottleneck
Dit is de as waar niemand naar vraagt. Een RAG-systeem is alleen zo goed als de regressieset waarop het wordt geëvalueerd, en die regressieset is alleen zo goed als de experts die hem hebben geschreven. Heeft de klant één domeinexpert die drie uur per week kan vrijmaken, dan heb je een plafond. Twee uur per vraag is realistisch voor een set met hoge inzet, inclusief het heen en weer over wat als correct antwoord telt.
Dus we vragen, voordat we offreren: hoeveel uur per week kan iemand die de juiste antwoorden echt kent de komende vier weken bij ons zitten, en daarna op maandelijkse retainer? De E-score:
- E=1: niemand, of alleen de oprichter, met minder dan een uur per week.
- E=3: één expert, twee tot vier uur per week.
- E=5: een klein groepje, zes uur of meer gecombineerd, met ten minste twee die het productief oneens kunnen zijn.
Is E gelijk aan 1, dan is het projectplafond "demo die er goed uitziet in een meeting". Dat zeggen we tegen de klant. Soms is dat alles wat ze nodig hebben en wordt de offerte klein. Soms verandert het de bemensing aan hun kant en wordt de offerte eerlijk.
Als E=1 en R=5, is het project op geen enkel budget op te leveren. Je kunt het systeem bouwen. Je kunt niet bewijzen dat het werkt. Loop weg, of schroef R terug voordat je tekent.
Waarom vijftig vragen, niet vijfhonderd
De vijftig in "regressieset van vijftig vragen" is niet willekeurig. In onze ervaring is dit ongeveer de kleinste set waarop het recall-getal niet meer wild op en neer gaat per toegevoegde vraag. Onder de dertig verschuift één slecht gechunkte bron je hoofdcijfer met meerdere punten. Boven de tachtig leert de marginale vraag je zelden iets nieuws en is de expert moe.
De runner is klein genoeg om in de opdrachtbevestiging te zetten:
import json, statistics
from pathlib import Path
def hits_at_k(expected_ids, retrieved_ids, k=5):
return int(bool(set(expected_ids) & set(retrieved_ids[:k])))
questions = json.loads(Path("regression.json").read_text())
scores = [
hits_at_k(q["expected_doc_ids"], my_retriever(q["question"]))
for q in questions
]
print(f"recall@5: {statistics.mean(scores):.2%} "
f"over {len(scores)} questions")
We geven de klant dit bestand op dag één. De regressieset is van hen, niet van ons. Bij oplevering moeten ze hem zonder onze hulp opnieuw kunnen draaien. Kunnen ze dat niet, dan is het project niet opgeleverd.
Het DRE-werkblad in de praktijk
D + R + E geeft een score tussen 3 en 15. De tiers waartegen we offreren:
- 3 tot 6, licht. Een prototype van twee weken, een vaste wekelijkse index, opleveren en weglopen. Kleine vaste prijs.
- 7 tot 10, standaard. Hybrid retrieval, een re-ranker, de regressieset, vier tot zes weken. Midden-tier vaste prijs met een gedefinieerde evaluatiemijlpaal.
- 11 tot 13, zwaar. Incrementele indexering, citation gates, wekelijkse expertsessies, acht tot twaalf weken. Nacalculatie, met een recall-bodem in het contract.
- 14 tot 15, R&D. Dan bespreken we of het project in zijn huidige vorm überhaupt moet bestaan. Meestal niet.
De scorekaart is geen toverkunst. Het is een manier om met elke prospect hetzelfde gesprek te voeren voordat er geld wordt overgemaakt, en om werk te weigeren dat we niet kunnen leveren.
Wat verandert er als je dit in het salesgesprek inbouwt
Drie dingen, in onze ervaring. Offertes komen terug met detail waar de prospect tegen in kan gaan, en dat is precies het gesprek dat je wilt. Projecten die niet zouden moeten bestaan sneuvelen eerder en goedkoper. En de domeinexpert van de klant wordt vanaf week één een benoemde rol, niet een verrassingsafhankelijkheid in week zes.
Toen we vorig jaar de support-antwoord-agent bouwden voor een Nederlandse verzekeringsmakelaar, was juist E wat we in de scoping hebben gemist. Twee acceptanten, ruim voldoende corpus, geen agenda. We hebben de regressiesessies uiteindelijk zes weken lang op vrijdagmiddag gedraaid, en een citation gate toegevoegd die weigerde te antwoorden als de retrieval-confidence onder een drempel zakte. Het is nu het patroon dat we toepassen op elke AI-agent-build die een echte kennisbank raakt.
Heb je deze week een RAG-offerte op je bureau, dan is het kleinste nuttige wat je kunt doen één vraag aan de klant stellen: wie, met naam, gaat de komende weken twee uur per week bij ons zitten om de antwoorden te scoren? Kunnen ze die niet noemen, dan heb je nog geen offerte.
Kern
De beperking die RAG-offertes doet ontsporen is niet de modelkeuze of de vector store: het is hoeveel uur een echte domeinexpert kan besteden aan het scoren van antwoorden.
FAQ
Wat is een redelijke recall-target voor een intern RAG-systeem?
Voor interne triage werkt recall@5 rond de 0,80 prima. Antwoorden naar klanten brengen we naar 0,90. Compliance-antwoorden tekenen we niet af onder 0,95, en alleen met een citation gate die low-confidence retrievals weigert.
Waarom vijftig vragen in de regressieset?
Onder de dertig verschuift één slecht gechunkte bron het hoofdgetal met meerdere punten. Boven de tachtig leert de marginale vraag zelden iets nieuws en brandt de domeinexpert op voordat het project wordt opgeleverd.
Kunnen we de expert overslaan als de bronset goed gestructureerd is?
Nee. Structuur helpt bij retrieval, niet bij evaluatie. Iemand moet bepalen wat het 'juiste antwoord' is op elke vraag, en dat is een domeinexpert, niet de engineer die de index heeft gebouwd.
Wat als het documentverloop heel hoog is?
Scoor het op D=5 en plan incrementele indexering plus een regressieset die maandelijks wordt ververst. Offreer de refresh als retainerregel, niet als one-off, zodat het systeem na overdracht eerlijk blijft.