Jak odhalit mezery v znalostech AI chatbota: Systematické řešení neodpovězených dotazů

Webový chatbot může spolehlivě odpovídat pouze tehdy, když má k dispozici vhodné, schválené a dohledatelné informace. V praxi se však mezery v znalostech málokdy objeví v podobě přehledného výkazu. Skrývají se za bezpečnými záložními odpověďmi (fallbacky), opakovanými doplňujícími dotazy, zbytečným předáváním na živé operátory nebo odpověďmi, které sice znějí věrohodně, ale nemají spolehlivý zdroj. Kdo sleduje pouze počet neodpovězených dotazů, vidí proto jen část problému.

Účinný proces proto propojujete provozní data, redakční kontrolu a testování. Cílem není okamžitě zkopírovat každou neobvyklou formulaci do znalostní báze. Cílem je rozpoznat opakující se informační potřeby, určovat jejich příčinu a schvalovat pouze takové odpovědi, za které se tým může odborně zaručit. Tento průvodce popisuje praktický postup pro týmy podpory, obsahu i produktu.

Co je mezera v znalostech AI chatbota?

O mezeru v znalostech jde v případě, kdy oprávněný dotaz uživatele v plánované oblasti použití nelze spolehlivě zodpovědět na základě schválených informací. To může znamenat, že informace zcela chybí. Častěji je sice k dispozici, ale je zastaralá, příliš obecná, jazykově nevhodná, nelze ji indexovat nebo ji vyhledávání (retrieval) nedokáže najít. Mezery tvoří i rozporuplné zdroje: chatbot má pak namísto nedostatku znalostí naopak příliš mnoho nejednoznačných informací.

Tento pojem by se neměl zaměňovat s každou situací typu „no match“. Google u platformy Dialogflow CX dokumentuje vestavěné události No-Match, pokud vstup neodpovídá žádnému intentu. Microsoft v analytikách Copilot Studia uvádí „unrecognized utterances“, tedy formulace, které nespustí žádné konkrétní téma. Takové signály jsou užitečným výchozím bodem, samy o sobě ale ještě nedokazují, že je potřeba nový obsah. Dotaz mohl být mimo rozsah (scope), formulace mnohoznačná nebo stávající zdroj jen nebyl nalezen.

Jaké signály patří do analýzy mezer?

Bezpečné fallbacky a neodpovězené dotazy

Nejvýraznější stopou je odpověď typu „K tomuto tématu nemám spolehlivé informace“. Tento bezpečný fallback je lepší než vymyslené tvrzení, měl by se však zaznamenávat jako ověřitelná událost. Důležitý přitom není jen samotný text dotazu, ale také jazyk, dotčená stránka, čas, zvolený rozsah (scope) a návazný průběh konverzace. Osobní nebo důvěrné údaje nepatří do redakčního systému bez předchozího filtrování.

Nízká míra jistoty a slabé podklady ve zdrojích

I zobrazená odpověď může odhalit mezeru v znalostech. Příkladem jsou chybějící zdroje, nízká shoda ve výsledcích vyhledávání (retrievalu), více rozporuplných nálezů nebo odpověď, která pokrývá pouze část dotazu. Samotná technická hodnota jistoty (confidence score) pro posouzení nestačí: prahové hodnoty se liší podle modelu, systému i míry rizika. Rozhodující je, zda tým dokáže tvrzení ověřit a schválit na základě autoritativního zdroje.

Opakované doplňující dotazy, předčasná ukončení a předání na operátory

Pokud uživatelé stejný dotaz přeformulovávají, opakovaně se doptávají nebo okamžitě poté požadují živého operátora, první odpověď pravděpodobně nemířila na podstatu věci. To platí i pro neobvykle vysoký počet opuštění konverzace po určitém tématu. Takové průběhy je nutné posuzovat v kontextu. Předání na operátora (handoff) může být správným řešením – například u individuálních posouzení, stížností nebo citlivých údajů. Nebývá to automaticky chyba obsahu.

Rozdíly mezi lokalizacemi a kanály

Odpověď v němčině může fungovat, zatímco francouzská varianta chybí nebo používá název produktu odlišně. Stejně tak mohou být dotazy na stránce s ceníkem formulovány jinak než v nápovědě. Shluky (clustery) by proto měly zůstat ověřitelné minimálně podle jazyka neboli lokalizace (locale) a podle kontextu použití. Globální souhrn by jinak mohl zakrýt jasně lokalizovanou mezeru.

Od neapracovaného signálu k prioritizovanému backlogu obsahu

Efektivní postup zabrání tomu, aby tým bezhlavě shromažďoval přepisy konverzací nebo přeceňoval ojedinělá pozorování. Následujících sedm kroků lze provádět týdně nebo při vyšším objemu i častěji.

1. Definujte sběr dat: Určete, které události se považují za kandidáty: bezpečný fallback, absence spolehlivého zdroje, opakovaný doplňující dotaz, negativní zpětná vazba, zbytečné předání na operátora nebo nahlášené nepravdivé tvrzení. Zdokumentujte také, které údaje se záměrně neukládají.
2. Očistěte obsah: Odstraňte nebo anonymizujte osobní údaje, čísla objednávek, kontaktní údaje a volné texty, které nejsou pro analýzu potřeba. Průvodce pro analytiku AI chatbota šetrnou k datům ukazuje, jak samostatně plánovat události, vzorkování a uchovávání dat.
3. Normalizujte dotazy: Seskupte formulace se stejným významem, aniž byste ztratili důležité rozdíly. „Jak dlouho mohu zboží vrátit?“ a „Jaká platí lhůta pro vrácení?“ patří pravděpodobně do jednoho clusteru; „Mohu vrátit personalizované zboží?“ může vyžadować vlastní pravidlo.
4. Klasifikujte příčinu: Rozlišujte chybějící obsah, zastaralý zdroj, problém s vyhledáváním (retrieval) či strukturou, nejasná pravidla (policy), mezeru v lokalizaci, záměrně vyloučený rozsah a nutné rozhodnutí člověka. Tato diagnóza určuje následné opatření.
5. Stanovte prioritu: Posuďte četnost, dopad na uživatele, obchodní relevanci a riziko. Ojedinělá poznámka k bezpečnostně kritickému omezení může být důležitější než častý dotaz z kategorie small talk. Vzorec musí být pro vaši společnost srozumitelný a ověřitelný, nikoli matematicky složitý.
6. Přiřaďte odpovědnost za zdroje: Každá plánovaná odpověď potřebuje autoritativní zdroj a osobu nebo roli, která smí její obsah schválit. Pokud obojí chybí, položka zůstává otevřená; jazykový model si pravidla nesmí vymýšlet. Vhodný provozní model popisuje průvodce pro správu obsahu (Content Governance) pro AI chatboty.
7. Vytvořte akceptační test: Uložte reprezentativní dotazy, očekávaná hlavní sdělení, povolené zdroje a očekávané chování mimo stanovený rozsah. Po každé změně ověřte, zda je mezera odstraněna a stávající odpovědi zůstávají stabilní.

Jaké položky potřebuje kvalitní zápis v backlogu?

Ticket s názvem „Chatbot nezná lhůtu pro vrácení zboží“ je příliš stručný. Snadno vede k textu, který sice odpoví na vzorový dotaz, ale nezohledňuje varianty, výjimky ani odpovědné osoby. Zpracovatelný záznam obsahuje minimálně:

• neutrální téma clusteru a dvě až pět anonymizovaných vzorových otázek,
• lokalizaci (locale), kontext stránky a dotčenou cestu uživatele,
• pozorované chování a požadované chování,
• kategorii příčiny a odůvodněnou prioritu,
• autoritativní URL zdroje nebo stav „zdroj chybí“,
• věcného vlastníka obsahu, roli pro schválení a cílový termín,
• datum platnosti, známé výjimky a požadované chování při předání operátorovi (handoff),
• testovací případy a měřitelná akceptační kritéria.

Díky tomu se z pozorování v chatu stává redakční pracovní úkol. Zároveň zůstává jasné, zda lze problém skutečně vyřešit obsahem. Technická chyba vyhledávání (retrievalu) patří například vyhledávacímu nebo platformnímu týmu; nevyjasněné pravidlo pro vrácení zboží zase věcně příslušnému oddělení.

Praktický příklad: Jak správně vyřešit dotazy k vrácení zboží

Předpokládejme, že se uživatelé opakovaně ptají na vrácení personalizovaných produktů. Chatbot někdy uvede obecnou lhůtu, jindy nejistou výjimku z vrácení a občas konverzaci předá zákaznické podpoře. Tým by neměl z dosavadních odpovědí vyvozovat nové pravidlo. Nejprve je nutné ujasnit, jaká schválená pravidla (policy) platí, pro které země a produktové skupiny se uplatňují a kdy je nutné posouzení jednotlivého případu.

Následně vznikne strukturovaný zdroj s obecným pravidlem, jasně definovanými výjimkami, rozsahem platnosti a eskalačními kritérii. Testovací případy pokrývají přímé dotazy, hovorové varianty, jinou lokalizaci (locale) a hraniční případ, který záměrně nelze automatizovat. Pro hraniční případ se očekává transparentní předání na živého operátora (Human Handoff) – nikoli vynucená samoobslužná odpověď.

Proč více obsahu neznamená automaticky lepší výsledky

Častou chybou bývá snaha odpovědět na každý cluster vytvořením nové položky FAQ. To může vést ke duplicitám, rozporům a horším výsledkům vyhledávání (retrievalu). Před vytvořením nového obsahu prověřte, zda by nebylo lepší doplnit či lépe strukturovat stávající stránku, případně ji odebrat z rozsahu indexace. Postup pro udržování aktuální znalostní báze pomáhá s výběrem zdrojů, frekvencí indexování a kontrolou zastaralého obsahu.

Stejně rizikové je přebírat reálné formulace uživatelů bez kontroly jako trénovací nebo testovací data. Google ve svých doporučeních pro návrh upozorňuje, že bezhlavé přidávání No-Match vstupů může vést k nežádoucímu skreslení záměrů (intent bias). Teprve analýza příčiny rozhodne, zda se má formulace doplnit, stávající formulace upravit, nebo opravit nesprávně konkurující intent.

Uzavření cyklu pomocí regresních testů

Mezera se nepovažuje za odstraněnou okamžikem zveřejnění nového textu. Považuje se za vyřešenou až tehdy, když reprezentativní dotazy v plánovaném kontextu vykazují očekávané chování. Google popisuje testovací případy s očekáváními na úrovni konverzace či jednotlivých kroků (turn level) a jejich porovnání s referenčním případem (Golden Case). Pro webové chatboty lze tento princip uplatnit nezávisle na použitém modelu: zdokumentuje se dotaz, očekávané hlavní sdělení, povolený zdroj, požadované předání na operátora a zakázaná tvrzení.

Malá, dobře udržovaná sada testů je hodnotnější než velká neprověřená sbírka. Zařaďte potvrzené mezery do stávajícího testovacího souboru (Golden Set) a po změnách obsahu, promptů, modelu nebo vyhledávání relevantní případy znovu spusťte. Podrobný průvodce pro měření kvality odpovědí AI chatbota tento revizní postup dále prohlubuje.

Jaké metriky ukazují pokrok?

Nesledujte pouze celkovou míru fallbacků (fallback rate). Mnohem vypovídající je malá sada metrik zahrnující otevřené prioritizované clustery, dobu do odborného vyjasnění, podíl položek v backlogu s autoritativním zdrojem, úspěšné regresní testy a opakovaně se objevující mezery po schválení. Výsledky segmentujte podle lokalizace (locale) a klíčových cest uživatele, aniž byste malé skupiny vyhodnocovali tak detailně, že by bylo možné nepřímým způsobem identifikovat konkrétní osoby.

Microsoft uvádí nerozpoznané promluvy a témata s nízkou mírou vyřešení jako možné signály pro optimalizaci. NIST ve svém AI Risk Management Frameworku zároveň zdůrazňuje průběžné monitorování, zdokumentované testovací sady, zpětnou vazbu a sledování chování v provozu. Z toho vyplývá důležité pravidlo: metriky mají podporovat rozhodování, nikoli však nahrazovat odborné přezkoumání zdroje odpovědi.

Týdenní kontrolní seznam pro zákaznickou podporu a redakci

• Zaznamenávejte nové kandidáty způsobem šetrným k datům a vyřaďte zjevné zneužití.
• Seskupujte dotazy se stejným významem podle lokalizace (locale) a doplňujte stávající clustery.
• U nejdůležitějších clusterů potvrdit příčinu, dopad a riziko.
• Vyhledejte stávající zdroje, označte rozpory a vyjasněte vlastníka obsahu.
• Zveřejňujte pouze schválené změny; rozsah (scope) a předání operátorovi (handoff) udržujte jednoznačné.
• Spouštějte reprezentativní testovací případy a dokumentujte výsledky.
• Po několika dnech provozu zkontrolujte, zda se cluster znovu neobjevuje nebo pouze nezměnil formu.

Závěr: Mezery v znalostech vyžadují redakční cyklus

Neodpovězené dotazy získávají hodnotu teprve tehdy, když k nim tým nepřistupuje jako k volným záznamům chatu, ale jako k ověřitelným podnětům. Zachytit, očistit, seskupit, určit příčinu, stanovit prioritu, schválit zdroj a otestovat: tento uzavřený cyklus propojuje realitu zákaznické podpory se spolehlivou znalostní bází. Nesnižuje počet předání za každou cenu a záměrně neodpovídá na všechny dotazy automaticky. Zviditelňuje však, kde chatbot může spolehlivě pomáhat – a kde je stanovení jasné hranice lepším řešením pro uživatelský zážitek.

Zdroje

• Microsoft Learn: Measure and improve agent performance with KPIs and analytics
• Google Cloud: Dialogflow CX obsluhy stavů a události No-Match
• Google Cloud: General agent design best practices
• Google Cloud: Dialogflow CX Test cases
• NIST AIRC: AI Risk Management Framework Core