Een kennisbank-assistent die fout antwoordt, heeft vrijwel nooit een modelprobleem. In de assistenten die wij bouwen zit de oorzaak in de grote meerderheid van de gevallen in de content, de chunking of de index, en de diagnosevolgorde die dat het snelst vindt is: kijk eerst naar wat er is opgehaald en pas daarna naar wat er is geantwoord.
Die volgorde telt, omdat de twee faalvormen er van buitenaf identiek uitzien. Een assistent die de verkeerde passage ophaalde en een assistent die de juiste passage ophaalde en negeerde, produceren allebei een zelfverzekerd, plausibel en onjuist antwoord. Zonder logging van het ophalen kun je ze niet uit elkaar houden, en dan gaan teams prompts aanpassen om contentproblemen op te lossen.
Hieronder staan zes herkenbare symptomen, de oorzaak achter elk, en wat je eraan doet.
Waarom is de content meestal de dader?
Omdat een ophaalsysteem elk gebrek erft van het materiaal waar het naar wijst, en de meeste organisaties hebben dat materiaal nooit voor dit doel doorgelicht.
Documentatie is geschreven voor mensen die kunnen scannen, een collega kunnen vragen en zien dat een pagina gedateerd is. Een ophaalsysteem doet geen van drieën. Het behandelt een vervallen procedure en de huidige als even gezaghebbend, omdat nergens in de tekst staat welke welke is. Het leest een tabel zonder kop als een verzameling ongelabelde getallen. Het kan niet zien dat een productpagina een uit assortiment genomen lijn beschrijft.
Het onderzoek van RAND naar de oorzaken waarom AI-projecten mislukken, gebaseerd op gesprekken met vijfenzestig ervaren vakmensen, noemt gebrekkige data als een van de belangrijkste faaloorzaken in het algemeen. Bij ophaalsystemen is die bevinding ongewoon letterlijk, want hier is de data simpelweg de documenten die je al hebt.
Daarom is het contentwerk het echte werk. Bij een klantgerichte assistent die wij opleverden, begon de bouw met een gestructureerde analyse van websiteteksten, FAQ-items, productpagina’s, technische bladen, brochures en oude klantcontactgesprekken, voordat er iets werd geïndexeerd. Die analyse is geen voorbereiding op het project, het is een groot deel van het project, en hem overslaan is de meest voorkomende reden dat een pilot die in week twee iedereen overtuigde in week acht tegenvalt.
Welk symptoom wijst op welke oorzaak?
Een stellig maar fout antwoord betekent meestal dat het ophalen niets relevants opleverde en het model het gat opvulde. Dit is het symptoom dat mensen hallucinatie noemen, en het als modelgebrek behandelen leidt nergens toe. De oplossing is een onderbouwingscontrole: ondersteunt de opgehaalde context geen antwoord, dan hoort het systeem dat te zeggen en door te verwijzen in plaats van vloeiende tekst te produceren. Die route ontwerpen is een van de waardevolste beslissingen in de hele bouw.
Het juiste document maar de verkeerde passage wijst op chunking. Ofwel is de chunkgrens dwars door een idee gegaan en is de context weggevallen die het betekenis gaf, ofwel is de chunk zo groot dat de relevante zin verdrinkt tussen vier andere onderwerpen. Tabellen die van hun kop gescheiden zijn, zijn het klassieke geval, want de getallen overleven en de betekenis niet.
Een verouderd antwoord betekent dat een vervallen bron nog in de index staat. Dat is een levenscyclusprobleem van de index en geen ophaalprobleem, en het vraagt om een verversingsritme en een verwijderproces, niet om beter zoeken. Organisaties plannen consequent het invoeren en vergeten het verwijderen.
Twee antwoorden die elkaar tegenspreken betekent dat de bronverzameling beide versies bevat en het ophalen kiest welke het beste bij de formulering van de vraag past. Geen enkele prompt lost dat op, want het systeem rapporteert getrouw wat het heeft gekregen. De oplossing is redactioneel: bepaal welk document leidend is en verwijder of markeer het andere.
Werkt in de test, faalt live betekent bijna altijd dat de testvragen zijn geschreven door degene die het systeem bouwde. Bouwers bedenken vragen waarvan ze het antwoord kennen, geformuleerd zoals de documentatie het formuleert. Echte gebruikers vragen naar het ding náást het ding, in hun eigen woorden, met een typefout. Oude supporttickets zijn de beste beschikbare bron van realistische testvragen, juist omdat niemand ze heeft verzonnen.
Struikelen op samengestelde vragen betekent dat één ophaalslag twee feiten uit verschillende documenten niet kan samenvoegen. Vragen wat de garantie is op het product dat een klant vorig jaar kocht, vergt twee opzoekacties en een koppeling, en een eenvoudige opzet doet er één. Dat is een ontwerpbeperking en geen fout, en het loont om vroeg te bepalen of jouw vragen dit nodig hebben, want de architectuur verschilt.
In welke volgorde controleer je?
Eerst het ophalen, dan de content, dan de prompt, en het model als laatste. Die volgorde is precies omgekeerd aan het instinct, want de prompt is het goedkoopst om te veranderen.
Begin met het loggen van de opgehaalde passages naast elk antwoord. Zonder dat log is diagnose gokwerk, en het later toevoegen betekent dat je de faalvoorbeelden weggooit die je al had verzameld. Mét dat log lost het merendeel van de gevallen zich binnen een minuut op: de juiste passage staat er wel of niet in, en dat ene feit scheidt een content- of ophaalprobleem van een promptprobleem.
Is de passage nooit opgehaald, kijk dan naar de content voordat je naar de zoekinstellingen kijkt. Vraag of het antwoord überhaupt in de verzameling staat, of het er in meerdere versies in staat, en of het geformuleerd is in woorden die een gebruiker nooit zou gebruiken. Veel ogenschijnlijke ophaalfouten zijn gevallen waarin het antwoord simpelweg nergens is opgeschreven, en dat lost geen enkele afstelling op.
Gartner noemt onduidelijke businesswaarde als een van de hoofdredenen dat agentic AI-projecten worden stopgezet, en een assistent waarvan de fouten nooit gediagnosticeerd worden wordt precies dat: iets dat niemand kan verdedigen omdat niemand het kan uitleggen.
Pas wanneer de juiste passage wél wordt opgehaald en het antwoord alsnog fout is, wordt de prompt verdachte. En pas wanneer een juiste, goed geprompte context nog steeds een slecht antwoord geeft, is het model zelf het bevragen waard, wat in de praktijk zelden voorkomt.
Hoe meet je of het echt beter wordt?
Scheid ophaalkwaliteit van antwoordkwaliteit, want één nauwkeurigheidscijfer verbergt welke helft kapot is.
Bij het ophalen is de vraag of de passage met het antwoord überhaupt in de resultaten voorkomt. Dat is meetbaar tegen een set vragen met bekende bronpassages, en het verbetert door contentwerk en chunking in plaats van door prompten. Bij de antwoordkwaliteit is de vraag of het antwoord juist en volledig is gegeven wat er is opgehaald, en dat is een andere meting die door andere ingrepen verbetert.
Stel de evaluatieset samen uit echte vragen, bij voorkeur vijftig tot tweehonderd, met de lastige er bewust bij. Die set is het waardevolste onderdeel van het project, want hij verandert elke volgende wijziging van een mening in een vergelijking. Hem samenstellen is werk voor degene die de content bezit en niet voor de engineer, want alleen zij weten welke vragen echt moeilijk zijn.
Eén meting wordt overgeslagen en hoort dat niet te worden: hoe vaak de assistent weigert te antwoorden. Een stijgend weigerpercentage is niet per se een achteruitgang, het kan betekenen dat de onderbouwingscontrole werkt. Een weigerpercentage van nul, op een verzameling die niet alles dekt, betekent dat het systeem vragen beantwoordt die het niet zou moeten beantwoorden.
Hoeveel hiervan is architectuur en niet afstellen?
Meer dan de meeste teams verwachten, en het loont om bij het ontwerp drie lagen te scheiden.
De kennislaag is de content, de chunking en de index. De gesprekslaag is hoe de assistent intentie interpreteert en hoe hij klinkt. De overdrachtslaag is wat er gebeurt als hij niet kan helpen, of dat nu een route naar een mens is, een formulier of een telefoonnummer. Die drie gescheiden houden maakt diagnose aanzienlijk eenvoudiger, want een klacht over toon en een klacht over juistheid zijn dan niet langer hetzelfde ticket.
Het voorkomt ook een specifieke en veelvoorkomende faalvorm: een assistent die technisch juiste antwoorden geeft waar niemand iets mee doet. Krijgt een klant de juiste informatie en weet hij nog steeds niet wat hij nu moet doen, dan werkte de kennislaag en is de overdrachtslaag nooit ontworpen. Dat is een productbeslissing en geen ophaalprobleem.
Verbeter de nauwkeurigheid van je RAG-assistent
Een AI-assistent die verkeerde antwoorden geeft, heeft niet altijd een beter AI-model nodig. Betrouwbare RAG-systemen beginnen bij kwalitatieve data, nauwkeurige informatieophaling en een goed ingerichte kennisbank. Door de oorzaken van RAG-fouten gericht aan te pakken, kun je hallucinaties verminderen en de betrouwbaarheid van je AI-assistent verbeteren.
Bij DataNorth AI helpen we organisaties met het ontwikkelen en optimaliseren van betrouwbare RAG-oplossingen. Met onze RAG Readiness Assessment onderzoeken we de kwaliteit van je databronnen, retrieval-pipeline en technische architectuur. Via onze RAG Ontwikkeling bouwen en integreren we AI-assistenten op maat die relevante informatie ophalen en antwoorden baseren op je eigen bedrijfsgegevens.
Geeft jouw AI-assistent onjuiste, verouderde of tegenstrijdige antwoorden? Neem contact op met DataNorth AI en ontdek hoe we de nauwkeurigheid, betrouwbaarheid en prestaties van je RAG-systeem kunnen verbeteren.
Veelgestelde vragen over de nauwkeurigheid van AI-assistenten
Waarom hallucineert een kennisbank-assistent?
Meestal omdat het ophalen niets relevants opleverde en het model toch antwoordde. Een taalmodel dat een vraag krijgt zonder onderbouwende context produceert nog steeds vloeiende tekst. De oplossing is een controle die weigert te antwoorden bij een lege ophaalslag, niet een beter model.
Hoe achterhaal je waarom een antwoord fout is?
Kijk eerst naar wat er is opgehaald en pas daarna naar wat er is geantwoord. Log de opgehaalde passages bij elk antwoord. Is de juiste passage nooit opgehaald, dan zit het probleem in de content of het zoeken. Is hij wel opgehaald en genegeerd, dan zit het in de prompt.
Welke chunkgrootte werkt het beste?
Er is geen universele maat, maar de bruikbare regel is dat een chunk een compleet idee moet bevatten plus genoeg context om zelfstandig begrepen te worden. Chunks die een tabel van zijn kop scheiden, of vijf onderwerpen bundelen, veroorzaken meer fouten dan welke modelkeuze ook.
Hoe test je een kennisbank-assistent goed?
Met echte vragen van echte gebruikers, niet met vragen die de bouwer heeft bedacht. Oude supporttickets en klantcontactgesprekken zijn de beste bron, omdat daar de formuleringen en de lastige gevallen in zitten die een bouwer nooit zou verzinnen.
Mag een assistent zeggen dat hij het niet weet?
Ja, en die route ontwerpen is een van de waardevolste beslissingen in de hele bouw. Een assistent die twijfel toegeeft en doorverwijst naar een mens behoudt vertrouwen. Een assistent die altijd antwoord geeft, leert gebruikers alles te controleren, en dan vervalt het nut.
De ene wijziging die je als eerste doet
Log de opgehaalde passages naast elk antwoord, vanaf vandaag. Het kost vrijwel niets, het verandert diagnose van speculatie in een controle van twee minuten, en het is het enige dat je niet met terugwerkende kracht kunt toevoegen aan de fouten die je al hebt gezien.
Al het andere in dit artikel wordt makkelijker zodra dat log bestaat, want elk symptoom hierboven wordt dan een vraag die je kunt beantwoorden door te kijken in plaats van een theorie die je moet testen.
