Wij gooiden onze RAG-pipeline na 9 maanden weg (en dit is waarom)
We bouwden een RAG-pipeline voor onze klantcontact-agent en gooiden hem na 9 maanden weg. De onderhoudskosten: €6.230 per maand. Nu met hybride aanpak: €840. Dit is het eerlijke verslag, inclusief de faalpatronen en een beslischecklist voor jouw situatie.
TL;DR: We bouwden een RAG-pipeline voor onze klantcontact-agent die 1.000+ gesprekken per week verwerkte. Na 9 maanden productie vervingen we hem door gestructureerde prompts, live API-calls en een lichtgewicht vector-index. Reden: het onderhoud kostte ons maandelijks meer dan de pipeline opleverde. Dit is ons eerlijke verslag, inclusief de faalpatronen, de kostencijfers en wanneer we RAG zelf nog wel aanraden.
AI-agent kennisbank: drie varianten op een rij
Een AI-agent weet van zichzelf alleen wat er in zijn trainingsdata zit. Wil je dat hij jouw prijslijst kent, je retourbeleid begrijpt of weet wie de contactpersoon is bij klant X, dan moet je hem die informatie aanleveren. Hoe je dat doet, is de architectuurkeuze die de meeste leveranciers achterwege laten bij de verkoop.
Drie gangbare benaderingen, eerlijk naast elkaar:
| Variant | Wanneer geschikt | Setup-kosten | Maandelijks onderhoud | Nauwkeurigheid bij verouderde data |
|---|---|---|---|---|
| Alleen system prompt | Stabiele, korte bedrijfsinfo (max ~2.000 tokens) | Laag (enkele uren) | Vrijwel nul | Hoog, mits handmatig bijgehouden |
| RAG-pipeline (vectordatabase + retrieval) | Grote, brede documentcorpora (500+ pagina's) | Hoog (2-4 weken bouwtijd) | 4-8 uur per klant per maand | Laag zonder actieve heringestie |
| Hybride (live API-calls + gerichte prompt-injectie) | Dynamische data (prijzen, CRM, voorraad) + selectief RAG | Middelhoog (1-2 weken) | 1-2 uur per maand | Hoog, data is altijd actueel via webhook |
De gangbare opvatting: RAG is de standaard aanpak voor elke AI-agent die bedrijfsspecifieke kennis nodig heeft. Onze productiepraktijk vertelt iets anders. Voor de meeste MKB-toepassingen teken je bij de livegang van een RAG-pipeline onbewust een onderhoudscontract dat duurder is dan de pipeline oplevert.
Waarom we begonnen met RAG
Onze klantcontact-agent verwerkte al vroeg meer dan 1.000 gesprekken per week voor meerdere klanten, elk met eigen producten, retourbeleid en contactpersonen. We wilden dat de agent per klant de juiste kennislaag kon raadplegen, zonder voor elke klant een apart model te draaien. RAG was de logische keuze.
We bouwden een gedeelde vectordatabase op pgvector (onze PostgreSQL-infrastructuur had die extensie al draaien), stopten er 800 documenten in en koppelden retrieval aan de agentlaag. Setup duurde iets minder dan 3 weken. De initiële nauwkeurigheid was overtuigend genoeg om live te gaan.
Wat we onderschatten, was het onderhoudscontract dat we daarmee impliciet tekenden. De pipeline werkte. Het ecosysteem eromheen bleek echter een voltijdse klus op zich te worden.
Vier stille killers van een RAG-pipeline
1. Knowledge base rot
Klanten updaten hun documenten regelmatig, maar de vector-index weet dat niet automatisch. In maand 4 van onze productierun paste een klant zijn retourbeleid aan: van 30 naar 14 dagen. De heringestie was niet geautomatiseerd. Resultaat: gedurende 6 weken gaf onze agent consequent de verkeerde retourperiode door aan klanten.
We schatten dat in die periode circa 720 gesprekken de foutieve informatie bevatten: bij een aandeel van ~12% retour-gerelateerde vragen op een weekvolume van 1.000 gesprekken, over 6 weken. Correctie kostte de klant handmatige escalaties en 2 extra supportweken. Een dure les die ook door externe data wordt ondersteund: 42% van productie-ML-systemen degradeert meetbaar binnen 12 maanden zonder actief onderhoud (Algorithmia, State of Enterprise ML 2022).
2. Retrieval-mismatch bij ambigue vragen
Korte klantvragen als "wanneer krijg ik mijn geld terug?" leverden bij de retriever regelmatig de verkeerde chunk op. De semantische afstand tussen de vraag en de relevante policy-paragraaf was groot genoeg dat de vector-search de verkeerde passage teruggaf. De LLM gaf vervolgens een confident antwoord op basis van foutieve context, zonder enige waarschuwing.
Dit is het fundamentele probleem met retrieval op ambigue, korte vragen: hoe compacter de vraag, hoe groter de kans op een mismatch. En klantenservice-vragen zijn per definitie kort en ambigu.
3. Chunking-overhead bij gestructureerde documenten
PDF-documenten met tabellen en bullet-lists leverden bij naieve chunking fragmentarische context op. Tabelrijen werden losgekoppeld van hun kolomheaders. Bullet-lijsten raakten hun context kwijt. De inhoud stond er wel in, maar de retriever kon er geen coherente betekenis aan geven.
Fix: we schreven per documenttype een handmatige chunking-strategie. Dat kostte 3 weken engineer-tijd. Niet eenmalig: elke keer dat een klant een nieuw documentformaat aanleverde, begon het opnieuw. Na 6 klanten hadden we 6 verschillende chunking-configuraties die elk apart onderhoud vroegen.
4. Escalerend onderhoud per klant
De echte killer was de lineaire schaal van onderhoud. Na de eerste 3 klanten was het systeem stabiel. Na 6 klanten besteedde een van onze engineers 40% van zijn werktijd aan kennisbankonderhoud: documenten ingesten, retrieval-mismatches debuggen, mismatch-logs doorzoeken, klant-specifieke edge cases oplossen.
Bij ons ingenieurstarief van €95 per uur: 40% van 160 uur per maand is 64 uur, maakt €6.080 per maand aan onderhoud alleen. Daarboven op kwamen de platformkosten van ~€150 per maand voor pgvector-hosting. Totale RAG-overhead: ruim €6.200 per maand voor 6 klanten. Meer dan €1.000 per klant per maand, uitsluitend aan kennisbankbeheer.
Wat we nu bouwen in plaats van RAG
Na 9 maanden besloten we te migreren. De overgang naar de hybride aanpak duurde 4 weken. Sindsdien draaien we vier lagen:
- Gestructureerde prompt-injectie voor klant-specifieke context die compact is: retourbeleid, SLA-afspraken, vaste contactpersonen. Direct in de system prompt gestopt, geen retrieval nodig.
- Live API-calls voor data die per definitie actueel moet zijn: voorraadbeschikbaarheid, CRM-status, orderstatus. Geen index die achterloopt, altijd de juiste waarde.
- Lichtgewicht vector-index uitsluitend voor grote documentcorpora waar retrieval werkelijk noodzakelijk is, zoals technische handleidingen en uitgebreide FAQ-documentatie met honderden pagina's.
- Webhook-trigger voor automatische heringestie zodra een document wordt aangepast. Geen handmatig proces meer, geen kennisbase rot.
De resultaten in onze eigen productiedata, RAG-periode versus hybride aanpak:
| Maatstaf | RAG-periode (9 maanden) | Hybride aanpak (huidig) | Verschil |
|---|---|---|---|
| Gemiddelde response-tijd | 2,3 seconden | 1,1 seconden | -52% |
| Engineer-uren/maand kennisbeheer | ~64 uur (40% FTE) | ~8 uur (<5% FTE) | -87% |
| Maandelijkse onderhoudskost | €6.230 (€6.080 + €150 platform) | €840 (€760 + €80 platform) | -87% |
| Incidenten door verouderde data | 3 in 9 maanden | 0 in 6 maanden | Nul |
| Nauwkeurigheid bij data-updates | Laag (handmatige heringestie) | Hoog (webhook-trigger) | Sterk verbeterd |
De antwoordkwaliteit is gelijkwaardig aan de RAG-periode. De latentie is gehalveerd. De onderhoudskosten daalden met 87%. De investering in de migratie was terugverdiend in minder dan 2 maanden.
Wil je meer weten over hoe je een AI-agent structureel opbouwt? Lees ons artikel over AI-agents bouwen voor MKB en de aanpak voor post-launch onderhoud van je agent.
Wanneer is een RAG-pipeline dan wel de juiste keuze?
We zijn niet tegen RAG. We zijn voor eerlijkheid over wanneer het zinvol is.
Drie situaties waarbij wij RAG aanraden:
- Grote, semi-statische documentcorpora: meer dan 500 pagina's technische documentatie, juridische teksten of handleidingen die minder dan één keer per maand wijzigen.
- Brede, ongestructureerde zoekvragen: de gebruiker stelt uiteenlopende vragen die je niet kunt voorspellen en niet kunt vatten in een compacte prompt-injectie.
- Interne kennisdeling op schaal: een kennisbank voor 50 of meer medewerkers waarbij het zoekvolume breed en ongestructureerd is.
Drie situaties waarbij wij RAG afraden:
- Data wijzigt wekelijks of vaker (prijzen, voorraad, beleid, contactpersonen).
- Je hebt geen engineer beschikbaar voor minimaal 4-8 uur onderhoud per maand.
- Je documentcorpus past volledig in een compact system prompt (minder dan 2.000 tokens).
Voor de meeste MKB-klantenservice- en leadopvolgingsagenten geldt situatie 3. In onze projecten voor AI-gedreven leadopvolging was prompt-injectie met CRM-data bijna altijd de betere keuze dan een volledige RAG-pipeline.
Beslisdiagram: heb ik RAG nodig?
Doorloop de vragen van boven naar beneden en stop bij het eerste "nee":
- Is je documentcorpus groter dan 500 pagina's? Zo nee: gebruik gerichte prompt-injectie, RAG is overkill.
- Verandert de inhoud minder dan één keer per maand? Zo nee: RAG kost meer dan hij oplevert, kijk naar live API-calls.
- Zijn de vragen van gebruikers breed en ongestructureerd? Zo nee: gestructureerde prompt-injectie werkt beter en is goedkoper.
- Heb je een engineer beschikbaar voor minimaal 4-8 uur onderhoud per maand? Zo nee: kies een SaaS-kennisbank of hybride aanpak.
- Heb je een automatische heringestie-trigger voor documentwijzigingen? Zo nee: bouw die eerst, anders beheert iemand het handmatig.
Vijf keer "ja"? Dan is een RAG-pipeline een serieuze optie voor jouw situatie.
Copy-paste: kennislaag-keuzechecklist
Gebruik deze checklist vóór je een architectuurkeuze maakt voor de kennislaag van je agent. Kopieer hem rechtstreeks naar je projectdocumentatie:
Kennislaag-keuzechecklist voor <jouw AI-agent-project>
=====================================================
Project: <vul projectnaam in>
Datum: <vul in>
Beoordelaar: <naam engineer of projectlead>
1. DOCUMENTVOLUME
Geschat aantal pagina's bedrijfskennis: <vul in>
Past alles in <2.000 tokens system prompt? [ ] ja [ ] nee
-> Zo ja: gebruik prompt-injectie. Stop hier.
2. UPDATEFREQUENTIE
Data wijzigt: [ ] dagelijks [ ] wekelijks [ ] maandelijks [ ] zelden
Is er een API of webhook beschikbaar voor live data? [ ] ja [ ] nee
-> Wekelijks of vaker, geen API: gebruik live API-calls. Stop hier.
3. VRAAGTYPE
Vragen zijn: [ ] breed en ongestructureerd [ ] compact en voorspelbaar
-> Compact en voorspelbaar: prompt-injectie volstaat. Stop hier.
4. ONDERHOUDSCAPACITEIT
Engineer beschikbaar voor kennisbeheer: <uren per maand>
-> Onder 4 uur/maand: overweeg SaaS-kennisbank of hybride aanpak.
5. HERINGESTIE-STRATEGIE
Automatische trigger bij documentwijziging: [ ] beschikbaar [ ] nog te bouwen
-> Nog te bouwen: reken 2-4 weken extra bouwtijd in voor go-live.
UITKOMST
[ ] Alleen prompt-injectie (corpus klein, stabiel)
[ ] Live API-calls + prompt-injectie (dynamische data)
[ ] Lichtgewicht RAG, selectief (groot corpus, semi-statisch, webhook actief)
[ ] Volledige RAG-pipeline (groot corpus, breed vraagtype, engineer beschikbaar)
Toelichting keuze: <vul in>
Geschatte maandelijkse onderhoudskost: <vul in>
Conclusie: de eerlijke keuzehulp
De drie vragen die wij het vaakst krijgen over AI-agent kennisbanken:
"Hebben we RAG nodig?" Waarschijnlijk niet. De meeste MKB-agents draaien beter op een combinatie van gerichte prompt-injectie voor stabiele info en live API-calls voor dynamische data.
"Wat kost het onderhoud?" Meer dan je verwacht. Bij 6 klanten op onze RAG-setup: ruim €6.200 per maand. Met de hybride aanpak: €840 per maand. Het kostenverschil betaalde onze migratie-investering terug in minder dan 2 maanden.
"Wanneer dan wel RAG?" Bij meer dan 500 pagina's semi-statische documentatie, een engineer die 4-8 uur per maand beschikbaar is voor onderhoud, en een automatische heringestie-trigger. Minder dan dat: bekijk het alternatief eerst.
Wij zijn niet het goedkoopste alternatief. Maar we vertellen je wel eerlijk of een RAG-pipeline jouw investering waard is, of dat je geld beter ergens anders naartoe gaat.
