AI-chatbot-kennislacunes herkennen: Onbeantwoorde vragen systematisch oplossen

Een website-chatbot kan alleen betrouwbaar antwoorden als hij passende, goedgekeurde en vindbare informatie ontvangt. In de praktijk doen kennislacunes zich echter zelden voor als een overzichtelijk rapport. Ze verbergen zich achter veilige fallback-antwoorden, herhaalde vervolgvragen, onnodige overdrachten aan medewerkers of antwoorden die weliswaar aannemelijk klinken, maar geen onderbouwde bron hebben. Wie alleen naar het aantal onbeantwoorde vragen kijkt, ziet daarom slechts een deel van het probleem.

Een doeltreffend proces combineert daarom operationele data, redactionele controle en tests. Het doel is niet om elke ongebruikelijke formulering direct naar de kennisbank te kopiëren. Het doel is om terugkerende informatiebehoeften te herkennen, de oorzaak ervan te bepalen en alleen die antwoorden vrij te geven waarvoor inhoudelijke verantwoordelijkheid kan worden genomen. Deze gids toont een praktische werkwijze voor support-, content- en productteams.

Wat is een kennislacune in een AI-chatbot?

Er is sprake van een kennislacune wanneer een terechte gebruikersvraag binnen het beoogde toepassingsgebied niet betrouwbaar kan worden beantwoord met een goedgekeurde verklaring. Dit kan betekenen dat de informatie volledig ontbreekt. Vaker is de informatie wel aanwezig, maar verouderd, te algemeen, taalkundig ongeschikt, niet te crawlen of niet vindbaar in het retrieval-proces. Ook tegenstrijdige bronnen vormen een lacune: de chatbot beschikt dan over te veel onduidelijke kennis in plaats van te weinig.

Het begrip moet niet worden gelijkgesteld met elke no-match-situatie. Google documenteert voor Dialogflow CX ingebouwde no-match-gebeurtenissen wanneer invoer niet overeenkomt met een intent. Microsoft noemt in Copilot Studio-analyses "unrecognized utterances", oftewel formuleringen die geen eigen onderwerp activeren. Zulke signalen zijn nuttige vertrekpunten, maar bewijzen nog niet dat er nieuwe content nodig is. Misschien viel de vraag buiten de scope, was de formulering voor meerderlei uitleg vatbaar of werd de bestaande bron gewoon niet gevonden.

Welke signalen horen thuis in de lacune-analyse?

Veilige fallbacks en niet-beantwoorde vragen

Het duidelijkste spoor is een antwoord zoals "Daarover heb ik geen betrouwbare informatie". Deze veilige fallback is beter dan een verzonnen bewering, maar moet wel als een controleerbare gebeurtenis worden geregistreerd. Relevant dabei zijn niet alleen de precieze bewoordingen van de vraag, maar ook de taal, de betreffende pagina, het tijdstip, de gekozen scope en het verdere verloop van het gesprek. Persoonsgegevens of vertrouwelijke inhoud horen niet ongefilterd in een redactioneel systeem thuis.

Lage zekerheid en een zwakke bronnenbasis

Ook een gegeven antwoord kan een kennislacune blootleggen. Voorbeelden zijn ontbrekende bronnen, een retrieval-resultaat met een lage relevantie, meerdere tegenstrijdige bronnen of een antwoord dat slechts een deel van de vraag dekt. De technische confidence-score alleen is niet voldoende als oordeel: drempels verschillen per model, systeem en risiconiveau. Bepalend is of het team de bewering aan de hand van een gezaghebbende bron kan verifiëren en goedkeuren.

Herhaalde vervolgvragen, afhaakmomenten en handoffs

Wanneer gebruikers dezelfde vraag anders formuleren, meerdere keren doorvragen of direct danach een menselijke medewerker verlangen, sluit het eerste antwoord mogelijk niet aan op de behoefte. Dat geldt ook voor een ongebruikelijke hoeveelheid afhaakmomenten bij een bepaald onderwerp. Zulke gespreksverlopen moeten in hun context worden beoordeeld. Een handoff kan de juiste oplossing zijn, bijvoorbeeld bij individuele beslissingen, klachten of gevoelige gegevens. Het is niet automatisch een contentfout.

Verschillen per taal, regio en kanaal

Een Duits antwoord kan goed werken, terwijl de Franse variant ontbreekt of een productnaam anders gebruikt. Ook kunnen vragen op een prijzenpagina anders geformuleerd worden dan in het helpcentrum. Daarom moeten clusters minimaal per taal of locale en per gebruikscontext analyseerbaar blijven. Een globale samenvatting kan anders een duidelijk gelokaliseerde lacune verbergen.

Van ruw signaal naar een geprioriteerde contentbacklog

Een gestroomlijnde workflow voorkomt dat het team willekeurig transcripten verzamelt of individuele observaties overwaardeert. De volgende zeven stappen kunnen wekelijks of bij een hoger volume frequenter worden uitgevoerd.

1. Registratie definiëren: Bepaal welke gebeurtenissen als kandidaat gelden: veilige fallback, geen onderbouwde bron, herhaalde vervolgvraag, negatief feedbacksignaal, onnodige handoff of gemelde onjuiste bewering. Documenteer ook welke gegevens bewust niet worden opgeslagen.
2. Inhoud opschonen: Verwijder of anonimiseer persoonsgegevens, bestelnummers, contactgegevens en vrije teksten die niet nodig zijn voor de analyse. Het artikel over datazuinige chatbot-analytics laat zien hoe gebeurtenissen, sampling en bewaartermijnen gescheiden kunnen worden gepland.
3. Vragen normaliseren: Bundel formuleringen met dezelfde betekenis zonder wichtige verschillen te verliezen. "Hoe lang kan ik retourneren?" en "Welke retourtermijn geldt er?" horen waarschijnlijk in hetzelfde cluster; "Kan ik gepersonaliseerde artikelen retourneren?" heeft mogelijk een eigen regel nodig.
4. Oorzaak categoriseren: Maak onderscheid tussen ontbrekende content, een verouderde bron, een retrieval- of structuurprobleem, een onduidelijk beleid, een specifieke taallacune, een bewust uitgesloten scope en een noodzakelijke menselijke beslissing. Deze diagnose bepaalt de vervolgstap.
5. Prioriteit bepalen: Beoordeel frequentie, impact op de gebruiker, zakelijk belang en risico. Een zeldzame opmerking over een veiligheidskritische beperking kan belangrijker zijn dan een veelgestelde smalltalk-vraag. De formule moet voor je organisatie begrijpelijk en toetsbaar zijn, niet mathematisch ingewikkeld.
6. Bronverantwoordelijkheid toewijzen: Elk gepland antwoord heeft een autoritatieve bron nodig en een persoon of rol die de inhoud mag goedkeuren. Als beide ontbreken, blijft het item openstaan; een taalmodel mag niet zelf beleid verzinnen. Een passend operationeel model wordt beschreven in de gids over content governance voor AI-chatbots.
7. Acceptatietest opstellen: Leg representatieve vragen, verwachte kernbeweringen, toegestane bronnen en het gewenste gedrag buiten de scope vast. Na elke wijziging wordt gecontroleerd of de lacune is gedicht en of bestaande antwoorden stabiel blijven.

Welke velden heeft een goed backlog-item nodig?

Een ticket met de titel "Chatbot kent retourtermijn niet" is te mager. Dit leidt al snel tot een tekst die weliswaar de voorbeeldvraag beantwoordt, maar geen rekening houdt met varianten, uitzonderingen of verantwoordelijkheden. Een werkbaar item bevat minimaal:

• een neutraal cluster-onderwerp en twee tot vijf geanonimiseerde voorbeeldvragen,
• taal/locale, paginacontext en het betreffende gebruikerspad,
• waargenomen gedrag en het gewenste gedrag,
• oorzaakcategorie en onderbouwde prioriteit,
• gezaghebbende bron-URL of de status "bron ontbreekt",
• inhoudelijk eigenaarschap, reviewrol en streefdatum,
• geldigheidsdatum, bekende uitzonderingen en gewenst handoff-gedrag,
• testgevallen en meetbare acceptatiecriteria.

Daarmee verandert een chat-observatie in een redactionele taak. Tegelijkertijd blijft zichtbaar of het probleem wel echt met content opgelost kan worden. Een technische retrieval-fout hoort beispielsweise thuis bij het zoek- of platformteam; een onduidelijke retourregel bij de inhoudelijk verantwoordelijke afdeling.

Praktijkvoorbeeld: vragen over retourneren correct oplossen

Stel dat gebruikers herhaaldelijk vragen stellen over het retourneren van gepersonaliseerde producten. De chatbot noemt soms de algemene termijn, soms een onzekere uitsluiting en draagt af en toe over aan de klantenservice. Het team moet dan niet op basis van de eerdere antwoorden een nieuwe regel bedenken. Eerst wordt verhelderd welk goedgekeurd beleid geldt, voor welke landen en productgroepen dit geldt en wanneer een individuele beoordeling nodig is.

Vervolgens ontstaat er een gestructureerde bron met een algemene regel, duidelijk benoemde uitzonderingen, het toepassingsgebied en escalatiecriteria. Testgevallen dekken directe vragen, spreektaalvarianten, een andere taal/locale en een bewust niet-geautomatiseerd grensgeval af. Voor dat grensgeval wordt een transparante human handoff verwacht – geen geforceerd zelfservice-antwoord.

Waarom meer content niet automatisch beter is

Een veelvoorkomende valkuil is om elk cluster te beantwoorden met een nieuwe FAQ. Dit kan dubbelingen, tegenstrijdigheden en slechtere retrieval-resultaten veroorzaken. Controleer voordat je nieuwe content aanmaakt of een bestaande pagina kan worden aangevuld, beter kan worden gestructureerd of uit de crawl-scope moet worden verwijderd. Het proces voor het actueel houden van een kennisbank helpt bij de bronselectie, crawl-frequentie en de controle op verouderde content.

Net zo risicovol is het om echte gebruikersformuleringen ongecontroleerd als trainings- of testdata over te nemen. Google wijst er in zijn ontwerprichtlijnen op dat het willekeurig toevoegen van no-match-invoer kan leiden tot ongewenste intent-bias. Pas de oorzakenanalyse bepaalt of een formulering moet worden toegevoegd, een bestaande formulering moet worden opgeschoond of een verkeerd concurrerende intent moet worden gecorrigeerd.

De cirkel rondmaken met regressietests

De lacune geldt niet als gedicht zodra er nieuwe tekst is gepubliceerd. Hij geldt pas als gedicht wanneer representatieve vragen binnen de beoogde context het verwachte gedrag vertonen. Google beschrijft testgevallen met verwachtingen op gespreks- of turn-niveau en de vergelijking met een golden case. Voor website-chatbots kan dit principe modelonafhankelijk worden toegepast: vraag, verwachte kernbewering, toegestane bron, vereiste handoff en verboden beweringspunten worden gedocumenteerd.

Een kleine, goed onderhouden testset is waardevoller dan een grote, ongecontroleerde verzameling. Neem bevestigde lacunes op in de bestaande golden set en voer de relevante gevallen opnieuw uit na wijzigingen in content, prompt, model of retrieval. De uitgebreide gids voor het meten van de antwoordkwaliteit van AI-chatbots gaat dieper in op deze review-workflow.

Welke KPI's tonen voortgang?

Kijk niet alleen naar een algemeen fallback-percentage. Veelzeggender is een kleine set indicatoren: openstaande geprioriteerde clusters, de doorlooptijd tot inhoudelijke verheldering, het aandeel backlog-items met een autoritatieve bron, geslaagde regressietests en terugkerende lacunes na een vrijgave. Segmenteer de resultaten op basis van taal/locale en het centrale pad, zonder kleine groepen zo gedetailleerd te evalueren dat personen indirect herleidbaar worden.

Microsoft noemt niet-herkende uitingen en onderwerpen met een lage oplossingsgraad als mogelijke optimalisatiesignalen. NIST benadrukt in het AI Risk Management Framework tevens continue monitoring, gedocumenteerde testsets, feedback en het observeren van het systeemgedrag in de praktijk. Hieruit volgt een wichtige werkafspraak: KPI's moeten beslissingen ondersteunen, maar mogen de inhoudelijke controle van een bron niet vervangen.

Wekelijkse checklist voor support en redactie

• Nieuwe kandidaten datazuinig registreren en duidelijke spam of misbruik eruit filteren.
• Vragen met dezelfde betekenis per taal/locale clusteren en bestaande clusters aanvullen.
• Voor de belangrijkste clusters oorzaak, impact en risico bevestigen.
• Bestaande bronnen zoeken, tegenstrijdigheden markeren en eigenaarschap verhelderen.
• Alleen goedgekeurde wijzigingen publiceren; houd scope en handoff expliciet.
• Representatieve testgevallen uitvoeren en de resultaten documenteren.
• Na enkele dagen gebruik controleren of het cluster opnieuw optreedt of alleen van vorm is veranderd.

Conclusie: kennislacunes vragen om een continue redactionele cyclus

Onbeantwoorde vragen worden pas waardevol wanneer een team ze niet als losse chatlogs behandelt, maar als toetsbare aanwijzingen. Registreren, opschonen, clusteren, de oorzaak bepalen, prioriteren, bronnen goedkeuren en testen: deze cyclus verbindt de praktijk van support met een betrouwbare kennisbank. Het voorkomt niet elke overdracht en beantwoordt bewust niet elke vraag automatisch. Wel maakt het zichtbaar waar de chatbot betrouwbaar kan helpen – en waar een duidelijke grens de betere gebruikerservaring biedt.

Bronnen

• Microsoft Learn: Measure and improve agent performance with KPIs and analytics
• Google Cloud: Dialogflow CX State handlers en No-Match-gebeurtenissen
• Google Cloud: General agent design best practices
• Google Cloud: Dialogflow CX Test cases
• NIST AIRC: AI Risk Management Framework Core