AI-chatbot-fallbacks: Genkend og videresend videnshuller sikkert

En website-chatbot behøver ikke at besvare ethvert spørgsmål. Det afgørende er, at den erkender, hvornår vidensbasen ikke giver et pålideligt grundlag, og at den derefter fortsat er til hjælp for de besøgende. Hvis man udfylder et hul med et sandsynligt gæt, skaber man et tillidsproblem: En forkert leveringstid, en opdigtet produktregel eller en upassende supportanvisning kan forårsage mere arbejde end en klar, kort grænse.

Hvorfor manglende resultater er et selvstændigt produktproblem

Ved en AI-chatbot med vidensbase er der mindst tre forskellige årsager til, at et svar udebliver. For det første kan informationen reelt mangle. For det andet kan den være til stede, men ikke blive fundet på grund af sprog, formulering, metadata eller ranking. For det tredje er den gennemsøgelig, men rækker ikke til et sikkert svar. Disse tilfælde ser i første omgang ens ud i chatten, men kræver forskellige tiltag i driften.

Retrieval-systemer vurderer ikke automatisk, om et svar er forretningsmæssigt forsvarligt. Den officielle oversigt om Retrieval-Augmented Generation i Azure AI Search beskriver, hvordan tekst- og vektorsøgning kan kombineres for at levere kilder til et svar. Kombinationen forbedrer søgningen, men erstatter ikke en regel for, hvornår et resultat anses for at være tilstrækkeligt. En chatbot har derfor brug for en klart defineret beslutning før tekstgenereringen: svar, stil uddybende spørgsmål eller videresend sikkert.

En No-Answer er ikke en blindgyde

Et brugbart fallback-svar siger ikke bare "Det har jeg ingen informationer om". Det består af fire byggeklodser: Det angiver grænsen uden tekniske bortforklaringer, undgår påstande, tilbyder et præcist opfølgende spørgsmål eller et sikkert alternativ og viser om nødvendigt vejen til et menneske. Tonefaldet må gerne være venligt, men det må ikke skjule usikkerheden.

• Grænse: "Jeg finder ingen pålidelige oplysninger om dette i de godkendte informationer."
• Kontekst: "Drejer det sig om en ordre, en kontrakt eller en teknisk opsætning?"
• Næste skridt: "Hvis du oplyser produktnavnet, kan jeg tjekke de tilgængelige dokumenter igen."
• Handoff: "For en bindende afklaring videresender vi din forespørgsel til det ansvarlige team."

Dermed forbliver chatten nyttig uden at opdigte priser, frister, juridiske konsekvenser eller tilsagn. Især ved personoplysninger, betalinger, individuelle tilbud og sikkerhedsrelevante spørgsmål bør handoff-reglen bevidst træde i kraft tidligere. Den tidligere offentliggjorte guide om Human Handoff i website-support hjælper med at udforme overdragelser som en klar proces i stedet for en nødudgang.

Operationaliser beslutningen før svaret

Teams bør ikke bare overtage en magisk tærskelværdi fra en demo. En score fra søgningen er kun et signal og kan ændre sig med indeks, model, sprog og query-mix. Dokumentationen for Semantic Ranking peger på, at reranker-score-fordelinger kan variere. Derfor hører en tærskelværdi altid sammen med et testet datagrundlag og en konkret fejlkategori.

En praksisorienteret beslutning kan kombinere flere kontroltrin. Findes der mindst én kilde fra et tilladt indholdsområde? Passer den til sproget og den aktuelle produkt- eller kontraktversion? Indeholder den en direkte begrundelse for det planlagte svar? Er de bedste resultater modstridende? Først når disse kriterier er tilstrækkeligt opfyldt, må generatoren formulere et svar. Ellers spørger botten målrettet ind eller skifter til fallback.

Eksempel: Bindende leveringsoplysning

Spørger en person om leveringsdatoen for et konkret produkt, er en generel forsendelsesartikel ikke nok. Botten kan forklare, at den ikke finder nogen bindende oplysning, spørge efter ordrenummer eller produktvariant og henvise til supporten. Et svar som "Din pakke kommer i morgen" ville derimod ikke være dækket af vidensbasen. Samme princip gælder for garantier, opsigelser, sundhedsspørgsmål og kontoadgang: Jo større den mulige skade er, desto stærkere skal dokumentationen være.

Tjek retrieval, før indhold omskrives

En No-Answer er ofte et godt målesignal. Før et team skriver en ny prompt, bør det gennemgå hele kæden: det oprindelige spørgsmål, det registrerede sprog, den normaliserede søgeforespørgsel, anvendte filtre, toptræffere, anvendte kildeversioner og det valgte resultat. På den måde bliver det synligt, om et dokument mangler, eller om søgningen rammer ved siden af.

1. Klassificer spørgsmål og hensigt anonymiseret, f.eks. produkt, support, konto eller juridisk.
2. Sammenhold forventede kilder med de faktisk hentede træffere.
3. Log filtre for sprog, gyldighed, adgang og produktversion.
4. Kontroller, om toptræfferne reelt underbygger spørgsmålet eller blot indeholder lignende begreber.
5. Markér sagen som et dokumentationshul, et retrieval-problem, en sikkerhedsregel eller en berettiget handoff.

Til sådanne sammenligninger er et lille Golden Set bestående af realistiske, forudgående rensede spørgsmål velegnet. Artiklen om måling af AI-chatbot-svarkvalitet beskriver, hvorfor kritiske og sjældne spørgsmål ikke må forsvinde i et gennemsnit. Tilføj bevidst spørgsmål uden et passende svar. Kun på den måde kan det testet, om chatbotten også reagerer kontrolleret ved manglende viden.

Overfør videnshuller til et redaktionelt workflow

Et enkelt chatforløb er endnu ikke en opgave til en ny FAQ. Flere ensartede, sikre fallbacks kan dog vise, at en vigtig information mangler eller er svær at finde. Til det formål er det nok med en dataminimeret liste med hensigt, fejlkategori, berørt sprog, eksisterende kilde-ID'er og status. Komplette samtaleindhold, navne eller kontooplysninger hører ikke hjemme på et generelt analyseboard.

Den ansvarlige fagperson afgør derefter, om vedkommende vil tilføje en FAQ, præcisere en produktside, forbedre metadata eller tilpasse handoff-teksten. Enhver tilføjelse skal have en ejer, en kilde og en dato. Ved tidskritiske informationer som tilgængelighed eller kampagner giver en udløbsdato ligeledes mening. På den måde forhindrer teamet, at en velment artikel selv bliver til den næste forældede kilde.

Brug ikke hallucineringsrate som kvalitetsmetrik

En lav rate af synlige fejl kan bedrage, hvis botten undviger for ofte. Omvendt er en høj svarrate ikke en succes, hvis svarene ikke er bakket op af deres kilder. Det er bedre med et lille sæt af nøgletal: andel af sikkert besvarede henvendelser, andel af begrundede fallbacks, handoff-rate pr. hensigt, tid indtil faglig afgørelse, tilbagevendende huller og resultater fra manuelle stikprøver. Evalueringen skal være mulig opdelt efter sprog, produktområde og risikoklasse.

NIST AI Risk Management Framework anbefaler at styre risici i kontekst og forankre processer til måling og håndtering. For website-teams betyder det ikke, at enhver samtale skal gemmes. Det betyder at have klare ansvarsområder og efterprøvelige kriterier for sikre svar.

Gennemgangen bør desuden passe til reale brugssituationer. Et kort spørgsmål på smartphonen indeholder ofte mindre kontekst end en udførlig forespørgsel på computeren. Stavefejl, produktforkortelser og sprogblandinger er forventelige input, ikke undtagelsestilfælde. Test derfor ikke kun det ideelt formulerede spørgsmål, men varianter med manglende ordrenummer, flere produktnavne eller en uklar tidsangivelse. Enhver variant skal enten udløse et underbygget svar, et meningfuldt opfølgende spørgsmål eller en sikker handoff. En fallback, der kun fungerer ved perfekt formulerede testspørgsmål, beskytter ikke i hverdagen.

Lige så vigtig er tilbagemeldingen fra supporten. Når medarbejdere besvarer en videresendt forespørgsel, kan de kort kategorisere årsagen: information manglede, information var forældet, adgang var nødvendig, eller forespørgslen krævede en individuel afgørelse. Disse kategorier forbinder website, vidensredaktion og service uden at gøre personen bag forespørgslen til et analyseobjekt. Et månedligt kig på de hyppigste kategorier er som regel nok til at planlægge prioriterede forbedringer.

Tjekliste til en sikker fallback

• Svar vises kun med passende, godkendte og aktuelle kilder.
• Tærskelværdierne og kombinationerne af signaler er testet med et Golden Set.
• Høje risikoklasser har egne regler for opfølgende spørgsmål og menneskelig overdragelse.
• Fallback-tekster forklarer grænsen uden at foregøgle intern teknik eller falsk sikkerhed.
• Logs indeholder kun nødvendige, dataminimerede diagnoseoplysninger.
• Tilbagevendende tilfælde tildeles en ejer og en efterprøvelig forbedringsstatus.
• Nye kilder tjekkes igen før godkendelse, efter ændringer og ved udløb.

Konklusion: Ærlige grænser forbedrer svarkvaliteten

En professionel AI-chatbot besvarer ikke mest muligt, men kun det, som dens kontrollerede vidensbase understøtter. Det bedste fallback-svar er konkret, hjælpsomt og overdrager bindende henvendelser uden gnidninger. Når teams behandler No-Answer-tilfælde som testdata og redaktionelle signaler, bliver både retrieval og indhold målbart bedre. Start med ti vigtige spørgsmål, ti bevidst ubesvarelige spørgsmål og en klar handoff pr. risikoklasse. Det skaber et solidt fundament, før chatbotten overtager mere ansvar.

Kilder

• 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