RAG-chatbots: wanneer ze werken en wanneer niet

RAG — Retrieval-Augmented Generation — is het standaardantwoord dat elke leverancier geeft zodra je "AI op onze eigen data" zegt. De pitch klinkt magisch: documenten erin, chatbot erop, medewerkers stellen vragen in natuurlijke taal. De praktijk is genuanceerder. RAG is een nuttig patroon voor een specifieke klasse problemen, en een dure omweg voor de rest. Dit artikel is voor technische beslissers die voor de tekenpen willen weten welk geval van toepassing is.

We schrijven dit als softwareleverancier die RAG-systemen in productie zet voor middelgrote Nederlandse bedrijven. We hebben RAG-chatbots gebouwd die echt veranderden hoe teams werken. We zijn ook weggelopen van RAG-projecten waar een script van 200 regels of een betere zoekbalk hetzelfde had gedaan voor een tiende van de prijs.

Wat RAG echt is (en niet is)

RAG is een patroon in twee stappen: relevante content ophalen uit een corpus, en daarna een LLM laten genereren op basis van die content. Het ophalen gebeurt meestal via vector-search — documenten worden in chunks gesplitst, elke chunk krijgt een embedding, en bij een vraag haalt het systeem de dichtstbijzijnde chunks op. Het genereren is een API-call naar Claude of GPT met die chunks als context.

Wat RAG niet is: een nieuwe vorm van AI, een vervanger voor een zoekmachine, of een truc waarmee een LLM jouw data "leert". Het model onthoudt je documenten niet. Elke vraag wordt opnieuw beantwoord met wat de retriever toevallig op dat moment naar boven haalt. Slechte retrieval = slecht antwoord — geen prompt-tovenarij die een corpus repareert dat niet op orde is.

De vier patronen waar RAG werkt

In ons werk zien we RAG echt waarde leveren in vier scenario's. Ze hebben drie dingen gemeen: het corpus is te groot voor een mens om door te bladeren, de vragen zijn open, en antwoorden moeten naar bronnen verwijzen.

1. Interne kennisbank

Confluence, SharePoint, interne wiki's, beleids-PDF's — plekken waar het antwoord wel ergens staat, maar niemand het kan vinden. Een RAG-chatbot maakt van uren zoeken één vraag. De winst is zelden "nieuwe kennis"; het is snellere toegang tot kennis die er al ligt.

2. Klantenservice op productdocumentatie

Tier-1 vragen waar het antwoord in je helpcentrum staat. RAG vangt de long tail van "hoe doe ik X" af en escaleert de rest naar mensen. Werkt vooral als de documentatie actueel is — werkt niet als die dat niet is.

3. Sales enablement

Sales mensen hebben snel antwoord nodig op vragen over prijzen, concurrenten, integraties, randgevallen — tijdens een gesprek. Een RAG-bot bovenop case studies, battle cards en productspecs is hier echt nuttig. Het corpus is afgebakend, de vragen zijn voorspelbaar, de impact van een verkeerd antwoord is beperkt.

4. Compliance & beleidsvragen

Gereguleerde sectoren met dikke beleidsdocumenten. Medewerkers willen weten welke regel in een specifieke situatie geldt. RAG met strikte bronvermelding werkt — het model haalt de relevante clausule op en quote die. Cruciaal: het systeem moet "weet ik niet" zeggen als retrieval mist, en nooit verzinnen.

De vier patronen waar RAG faalt

Even belangrijk: wanneer RAG het verkeerde antwoord is. Vier gevallen die we keer op keer zien.

1. Het corpus is klein en schoon genoeg dat je geen RAG nodig hebt

Past je kennis in 50–100 pagina's gestructureerde tekst? Dan heb je geen vector store nodig. Stop het hele ding gewoon in de LLM context window. Moderne modellen hanteren 200K+ tokens. RAG voegt infrastructuur-complexiteit toe zonder waarde onder een bepaalde corpusgrootte.

2. De vraag vraagt om een actie, niet een antwoord

"Zeg mijn abonnement op", "maak een ticket aan met hoge prioriteit", "werk de einddatum van het contract bij in het CRM" — dat zijn geen retrieval-problemen. Dat zijn agent-problemen. Een RAG-bot legt vriendelijk uit hoe je een abonnement opzegt in plaats van het op te zeggen. Als de gewenste output een actie in een systeem is, heb je een agent met tools nodig, geen chatbot.

3. Latency telt zwaarder dan diepgang

RAG voegt minimaal één netwerk round-trip en één LLM-call toe aan elke vraag — meestal 1,5–4 seconden end-to-end. Voor autocomplete, real-time UI-hints of iets binnen een typflow is dat te traag. Gebruik een kleinere zoekindex of klassieke retrieval en sla de generatiestap over.

4. Je bronnen zijn niet te vertrouwen

Is je kennisbank een kerkhof van verouderde, tegenstrijdige of slecht geschreven documenten, dan zal RAG die rotzooi netjes en gezaghebbend in elkaar zetten. Garbage in, gezellig zelfverzekerde garbage out. Repareer eerst het corpus; pas daarna de chatbot.

De engineering-werkelijkheid

De demo van RAG kost een middag. De productie-versie kost weken. Het werk dat niet voor de hand ligt:

• Chunking: hoe je documenten splitst telt zwaarder dan welk embedding-model je kiest. Slechte chunks (midden in een zin afgesneden, koppen kwijt, geen overlap) verpesten retrieval. Goede chunking respecteert documentstructuur.
• Embedding-keuze: de default OpenAI- of Cohere-embedding is prima voor Engels. Voor Nederlands presteren multilingual modellen (zoals multilingual-e5) doorgaans merkbaar beter — testen vóór commitment.
• Retrieval-evaluatie: bouw een set van 50–200 echte vragen met verwachte bron-documenten. Meet recall@k. Zonder dit tune je blind.
• Reranking: een cross-encoder reranker bovenop vector-search verbetert antwoordkwaliteit consistent. Kost 200–500ms extra per query, meestal de moeite waard.
• De "weet ik niet"-guardrail: instrueer het model om te weigeren als de opgehaalde chunks het antwoord niet bevatten. Test daar agressief op — dat is het verschil tussen betrouwbaar en gevaarlijk.
• Bronvermelding: laat zien welke chunks zijn gebruikt, idealiter met paginanummers en een link naar het originele document. Bouwt vertrouwen en stelt gebruikers in staat te verifiëren.

RAG vs fine-tuning vs general LLM vs agent

Deze vier opties worden in leverancierspitches door elkaar gehaald. Ze lossen verschillende problemen op.

Ons standaardadvies: begin met een gewone LLM-call. Volstaat dat niet, voeg dan RAG toe. Voeg fine-tuning alleen toe als een specifieke stijl of format prompting onpraktisch maakt — dat is zelden. Wil de gebruiker dat er iets gebeurt in plaats van iets weet, dan bouw je een agent, geen chatbot.

Kosten en doorlooptijd, eerlijk

Realistische ranges voor een productie-RAG-chatbot bij een middelgroot bedrijf:

• Lichte interne RAG-bot, één bron, basis-UI: €20K–€35K, 4–5 weken.
• Multi-source RAG met reranking, evaluatieset, monitoring: €40K–€60K, 6–8 weken.
• Klantgerichte RAG met strikte guardrails, SSO, audit logging: €60K–€80K, 8–10 weken.
• Plus 15–25% per jaar onderhoud — het corpus verandert, modellen veranderen, prompts driften.

Wordt het dramatisch onder die ranges geoffreerd, dan slaan ze evaluatie over, gebruiken ze een gesloten platform waar je in vast komt te zitten, of zijn ze de scope te smal aan het maken. Dramatisch erboven betekent meestal scope creep — je betaalt voor een data platform dat je niet vroeg.

Hoe wij RAG bouwen

Wij bouwen RAG-chatbots en AI agents voor middelgrote Nederlandse bedrijven. We beginnen met een discovery van 1–2 weken: corpus beoordelen, evaluatieset bouwen, retrieval-pipeline prototypen en echte cijfers laten zien voordat we een build offreren. Meer over onze aanpak vind je op onze service-pagina voor RAG-chatbots.

Heb je een corpus en een vraag in gedachten? Beschrijf via ons contactformulier wat je gebruikers zouden moeten kunnen vragen — we reageren binnen één werkdag met een eerlijk oordeel of RAG de juiste vorm is en wat het ongeveer kost.