AI-chatbot-fallbacks: Kennisgaten veilig herkennen en doorverwijzen

Een website-chatbot hoeft niet elke vraag te beantwoorden. Cruciaal is dat hij herkent wanneer de kennisbank geen betrouwbare basis biedt en dat hij vervolgens nuttig blijft voor bezoekers. Wie een gat opvult met een aannemelijk klinkende gok, creëert een vertrouwenstekort: een verkeerde levertijd, een verzonnen productregel of een verkeerde support-instructie kan meer werk veroorzaken dan een duidelijke, korte grens.

Waarom ontbrekende resultaten een afzonderlijk productprobleem zijn

Bij een AI-chatbot met een kennisbank zijn er minstens drie verschillende oorzaken voor het uitblijven van een antwoord. Ten eerste kan de informatie daadwerkelijk ontbreken. Ten tweede kan de informatie wel aanwezig zijn, maar niet worden gevonden vanwege taal, formulering, metadata of ranking. Ten derde is de informatie wel vindbaar, maar onvoldoende voor een veilig antwoord. Deze gevallen lijken in de chat aanvankelijk op elkaar, maar vereisen in de praktijk verschillende maatregelen.

Retrieval-systemen beoordelen niet automatisch of een antwoord zakelijk verantwoord is. Eén officiële overlegpagina over Retrieval-Augmented Generation in Azure AI Search beschrijft hoe tekst- en vectorzoekopdrachten gecombineerd kunnen worden om bronnen voor een antwoord te leveren. Die combinatie verbetert de zoekopdracht, maar vervangt geen regel voor wanneer een resultaat als voldoende geldt. Een chatbot heeft daarom voorafgaand aan de tekstgeneratie een helder gedefinieerd besluit nodig: beantwoorden, doorvragen of veilig doorverwijzen.

Een No-Answer is geen lege doodlopende weg

Een bruikbaar fallback-antwoord zegt niet simpelweg "Daar heb ik geen informatie over". Het bestaat uit vier bouwstenen: het benoemt de grens zonder technische excuses, vermijdt beweringen, biedt een precieze vervolgvraag of een veilig alternatief en wijst desgewenst de weg naar een menselijke medewerker. De toon mag vriendelijk zijn, maar mag de onzekerheid niet verbergen.

• Grens: "Ik vind in de vrijgegeven informatie geen betrouwbare vermelding hierover."
• Context: "Gaat het om een bestelling, een contract of een technische instelling?"
• Volgende stap: "Als u de productnaam noemt, kan ik de beschikbare documenten opnieuw controleren."
• Handoff: "Voor een bindende controle sturen we uw verzoek door naar het verantwoordelijke team."

Daarmee blijft de chat nuttig, zonder prijzen, termijnen, juridische gevolgen of beloftes te verzinnen. Vooral bij persoonsgegevens, betalingen, individuele offertes en veiligheidsrelevante vragen moet de handoff-regel bewust sneller inspringen. De reeds gepubliceerde gids over Human Handoff in website-support helpt om overdrachten vorm te geven als een helder proces in plaats van een nooduitgang.

De beslissing vóór het antwoord operationaliseren

Teams moeten geen magische drempelwaarde uit een demo overnemen. Een score uit de zoekfunctie is slechts een signaal en kan veranderen met de index, het model, de taal en de query-mix. De documentatie van Semantic Ranking wijst erop dat de verdeling van reranker-scores kan variëren. Daarom hoort een drempelwaarde altijd bij een geteste dataset en een concrete foutklasse.

Een praktijkgerichte beslissing kan meerdere controles combineren. Is er minstens één bron uit een toegestane categorie? Past deze bij de taal en de huidige product- of contractversie? Bevat deze een directe onderbouwing voor het geplande antwoord? Spreken de topresultaten elkaar tegen? Pas als aan deze criteria voldoende is voldaan, mag de generator een antwoord formuleren. Anders vraagt de bot gericht door of schakelt over naar de fallback.

Voorbeeld: Bindende leveringsinformatie

Als iemand vraagt naar de leverdatum van een specifiek product, volstaat een algemeen verzendartikel niet. De bot kan uitleggen dat hij geen bindende informatie kan vinden, vragen om het bestelnummer of de productvariant, en verwijzen naar support. Een antwoord als "Uw pakket komt morgen" zou daarentegen niet gedekt zijn door de kennisbank. Hetzelfde principe geldt voor garanties, opzeggingen, medische vragen en toegang tot accounts: hoe groter de mogelijke schade, hoe sterker het bewijs moet zijn.

Retrieval controleren voordat inhoud wordt herschreven

Een No-Answer is vaak een goed meetsignaal. Voordat een team een nieuwe prompt schrijft, moet het de gehele keten bekijken: de originele vraag, de herkende taal, de genormaliseerde zoekopdracht, de toegepaste filters, de topresultaten, de gebruikte bronversies en de gekozen uitkomst. Zo wordt zichtbaar of een document ontbreekt of dat het ophalen van informatie erlangs zoekt.

1. Classificeer de vraag en de intentie geanonimiseerd, bijvoorbeeld product, support, account of juridisch.
2. Leg de verwachte bronnen en de daadwerkelijk opgehaalde resultaten naast elkaar.
3. Leg filters vast voor taal, geldigheid, toegang en productversie.
4. Controleer of de topresultaten de vraag echt onderbouwen of alleen soortgelijke termen bevatten.
5. Markeer het geval als documentatiegat, retrieval-probleem, veiligheidsregel of een terechte handoff.

Voor zulke vergelijkingen is een kleine Golden Set van realistische, vooraf opgeschoonde vragen zeer geschikt. Het artikel over het meten van de antwoordkwaliteit van AI-chatbots beschrijft waarom kritische en zeldzame vragen niet mogen verdwijnen in een gemiddelde. Voeg bewust vragen toe zonder passend antwoord. Alleen dan kun je testen of de chatbot ook bij gebrek aan kennis gecontroleerd reageert.

Kennisgaten overbrengen naar een redactionele workflow

Een enkele chatgesprek is nog geen aanleiding voor een nieuwe FAQ. Meerdere vergelijkbare, veilige fallbacks kunnen echter aantonen dat een belangrijk stuk informatie ontbreekt of moeilijk vindbaar is. Daarvoor volstaat een privacyvriendelijke lijst met de intentie, foutklasse, betrokken taal, aanwezige bron-ID's en status. Volledige gespreksinhoud, namen of accountgegevens horen niet thuis op een algemeen analyseboard.

De verantwoordelijke specialist beslist vervolgens of hij een FAQ aanvult, een productpagina verduidelijkt, metadata verbetert of de handoff-tekst aanpast. Elke aanvulling heeft een eigenaar, een bron en een datum nodig. Bij tijdgevoelige informatie, zoals beschikbaarheid of acties, is bovendien een vervaldatum zinvol. Zo voorkomt het team dat een goedbedoeld artikel zelf de volgende verouderde bron wordt.

Gebruik geen hallucinatiepercentage als kwaliteitsindicator

Een laag percentage zichtbare fouten kan misleidend zijn als de bot te vaak uitwijkt. Omgekeerd is een hoog antwoordpercentage geen succes als antwoorden niet door hun bronnen worden ondersteund. Beter is een kleine set KPI's: het aandeel veilig beantwoorde vragen, het aandeel onderbouwde fallbacks, de handoff-ratio per intentie, de tijd tot een beslissing door een specialist, terugkerende gaten en resultaten uit handmatige steekproeven. De evaluatie moet gesplitst kunnen worden op basis van taal, productcategorie en risicoklasse.

Het NIST AI Risk Management Framework adviseert om risico's in hun context te beheren en processen voor het meten en managen te verankeren. Voor websiteteams betekent dit niet dat elk gesprek opgeslagen moet worden. Het betekent dat er duidelijke verantwoordelijkheden en controleerbare criteria moeten zijn voor veilige antwoorden.

De controle moet bovendien aansluiten op reële gebruikssituaties. Een korte vraag op een smartphone bevat vaak minder context dan een uitgebreide vraag op een desktop. Typefouten, afkortingen van producten en gemengde talen zijn te verwachten invoer, geen uitzonderingen. Test daarom niet alleen de ideaal geformuleerde vraag, maar ook varianten met een ontbrekend bestelnummer, meerdere productnamen of een onduidelijke tijdsaanduiding. Elke variant moet ofwel een onderbouwd antwoord, een zinvolle vervolgvraag of een veilige handoff activeren. Een fallback die alleen werkt bij perfect geformuleerde testvragen, beschermt niet in de dagelijkse praktijk.

Even belangrijk is de terugkoppeling van support. Wanneer medewerkers een doorverwezen vraag beantwoorden, kunnen ze de reden kort categoriseren: informatie ontbrak, informatie was verouderd, toegang was vereist of de aanvraag vereiste een individuele beslissing. Deze categorieën verbinden de website, de kennisredactie en de klantenservice zonder van de persoon achter de aanvraag een analyse-object te maken. Een maandelijks overzicht van de meest frequente categorieën volstaat meestal om geprioriteerde verbeteringen te plannen.

Checklist voor een veilige fallback

• Antwoorden verschijnen alleen met passende, vrijgegeven en actuele bronnen.
• Drempelwaarden en combinaties van signalen zijn getest met een Golden Set.
• Hoge risicoklassen hebben eigen regels voor verduidelijking en menselijke overdracht.
• Fallback-teksten leggen de grens uit zonder interne techniek of valse zekerheid te simuleren.
• Logs bevatten alleen de noodzakelijke, privacyvriendelijke diagnose-informatie.
• Terugkerende gevallen krijgen een eigenaar en een controleerbare verbeterstatus.
• Nieuwe bronnen worden voor vrijgave, na wijzigingen en bij verloop opnieuw gecontroleerd.

Conclusie: Eerlijke grenzen verbeteren de antwoordkwaliteit

Een professionele AI-chatbot beantwoordt niet zo veel mogelijk, maar alleen wat door zijn gecontroleerde kennisbank wordt ondersteund. Het beste fallback-antwoord is concreet, behulpzaam en draagt bindende verzoeken zonder wrijving over. Wanneer teams No-Answer-situaties behandelen als testdata en redactionele signalen, worden zowel retrieval als inhoud meetbaar beter. Begin met tien belangrijke vragen, tien bewust onbeantwoordbare vragen en een heldere handoff per risicoklasse. Dat schept een solide basis voordat de chatbot meer verantwoordelijkheid overneemt.

Bronnen

• Microsoft Learn: RAG and Generative AI in Azure AI Search
• Microsoft Learn: Semantic Ranking Overview
• Microsoft Learn: Create a Full-Text Query
• NIST: AI Risk Management Framework