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\u00efndexeerd. 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.<\/p>\n\n\n\n
Welk symptoom wijst op welke oorzaak?<\/h2>\n\n\n\n![\"syptoom](\"https:\/\/datanorth.ai\/wp-content\/uploads\/2026\/10\/syptoom-links-waarschijnlijke-oorzaak-rechts-1.jpg\")
Zes symptomen van een haperende kennisbank-assistent met per symptoom de waarschijnlijke oorzaak<\/figcaption><\/figure>\n\n\n\nEen stellig maar fout antwoord<\/strong> 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.<\/p>\n\n\n\nHet juiste document maar de verkeerde passage<\/strong> 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.<\/p>\n\n\n\nEen verouderd antwoord<\/strong> 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.<\/p>\n\n\n\nTwee antwoorden die elkaar tegenspreken<\/strong> 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.<\/p>\n\n\n\nWerkt in de test, faalt live<\/strong> 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\u00e1\u00e1st 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.<\/p>\n\n\n\nStruikelen op samengestelde vragen<\/strong> betekent dat \u00e9\u00e9n 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 \u00e9\u00e9n. Dat is een ontwerpbeperking en geen fout, en het loont om vroeg te bepalen of jouw vragen dit nodig hebben, want de architectuur verschilt.<\/p>\n\n\n\nIn welke volgorde controleer je?<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
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\u00e9t 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.<\/p>\n\n\n\n
Is de passage nooit opgehaald, kijk dan naar de content voordat je naar de zoekinstellingen kijkt. Vraag of het antwoord \u00fcberhaupt 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.<\/p>\n\n\n\n
Gartner noemt onduidelijke businesswaarde als een van de hoofdredenen dat agentic AI-projecten worden stopgezet<\/a>, en een assistent waarvan de fouten nooit gediagnosticeerd worden wordt precies dat: iets dat niemand kan verdedigen omdat niemand het kan uitleggen.<\/p>\n\n\n\nPas wanneer de juiste passage w\u00e9l 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.<\/p>\n\n\n\n
Hoe meet je of het echt beter wordt?<\/h2>\n\n\n\n
Scheid ophaalkwaliteit van antwoordkwaliteit, want \u00e9\u00e9n nauwkeurigheidscijfer verbergt welke helft kapot is.<\/p>\n\n\n\n
Bij het ophalen is de vraag of de passage met het antwoord \u00fcberhaupt 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
E\u00e9n 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.<\/p>\n\n\n\n
Hoeveel hiervan is architectuur en niet afstellen?<\/h2>\n\n\n\n
Meer dan de meeste teams verwachten, en het loont om bij het ontwerp drie lagen te scheiden.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Verbeter de nauwkeurigheid van je RAG-assistent<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Bij DataNorth AI helpen we organisaties met het ontwikkelen en optimaliseren van betrouwbare RAG-oplossingen. Met onze RAG Readiness Assessment<\/a> onderzoeken we de kwaliteit van je databronnen, retrieval-pipeline en technische architectuur. Via onze RAG Ontwikkeling<\/a> bouwen en integreren we AI-assistenten op maat die relevante informatie ophalen en antwoorden baseren op je eigen bedrijfsgegevens.<\/p>\n\n\n\n
Een stellig maar fout antwoord<\/strong> 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.<\/p>\n\n\n\n Het juiste document maar de verkeerde passage<\/strong> 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.<\/p>\n\n\n\n Een verouderd antwoord<\/strong> 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.<\/p>\n\n\n\n Twee antwoorden die elkaar tegenspreken<\/strong> 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.<\/p>\n\n\n\n Werkt in de test, faalt live<\/strong> 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\u00e1\u00e1st 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.<\/p>\n\n\n\n Struikelen op samengestelde vragen<\/strong> betekent dat \u00e9\u00e9n 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 \u00e9\u00e9n. Dat is een ontwerpbeperking en geen fout, en het loont om vroeg te bepalen of jouw vragen dit nodig hebben, want de architectuur verschilt.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u00e9t 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.<\/p>\n\n\n\n Is de passage nooit opgehaald, kijk dan naar de content voordat je naar de zoekinstellingen kijkt. Vraag of het antwoord \u00fcberhaupt 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.<\/p>\n\n\n\n Gartner noemt onduidelijke businesswaarde als een van de hoofdredenen dat agentic AI-projecten worden stopgezet<\/a>, en een assistent waarvan de fouten nooit gediagnosticeerd worden wordt precies dat: iets dat niemand kan verdedigen omdat niemand het kan uitleggen.<\/p>\n\n\n\n Pas wanneer de juiste passage w\u00e9l 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.<\/p>\n\n\n\n Scheid ophaalkwaliteit van antwoordkwaliteit, want \u00e9\u00e9n nauwkeurigheidscijfer verbergt welke helft kapot is.<\/p>\n\n\n\n Bij het ophalen is de vraag of de passage met het antwoord \u00fcberhaupt 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n E\u00e9n 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.<\/p>\n\n\n\n Meer dan de meeste teams verwachten, en het loont om bij het ontwerp drie lagen te scheiden.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Bij DataNorth AI helpen we organisaties met het ontwikkelen en optimaliseren van betrouwbare RAG-oplossingen. Met onze RAG Readiness Assessment<\/a> onderzoeken we de kwaliteit van je databronnen, retrieval-pipeline en technische architectuur. Via onze RAG Ontwikkeling<\/a> bouwen en integreren we AI-assistenten op maat die relevante informatie ophalen en antwoorden baseren op je eigen bedrijfsgegevens.<\/p>\n\n\n\nIn welke volgorde controleer je?<\/h2>\n\n\n\n
Hoe meet je of het echt beter wordt?<\/h2>\n\n\n\n
Hoeveel hiervan is architectuur en niet afstellen?<\/h2>\n\n\n\n
Verbeter de nauwkeurigheid van je RAG-assistent<\/h2>\n\n\n\n