AI čatbotu zināšanu robu atpazīšana: neatbildēto jautājumu sistemātiska novēršana

Tīmekļa vietnes čatbots var atbildēt uzticami tikai tad, ja tas saņem piemērotu, apstiprinātu un viegli atrodamu informāciju. Praksē gan zināšanu robi reti parādās glīta ziņojuma veidā. Tie paslēpjas drošās rezerves (fallback) atbildēs, atkārtotos precizējošos jautājumos, nevajadzīgā pāradresācijā cilvēkiem vai atbildēs, kas izklausās ticamas, bet kurām nav droša avota. Tāpēc tie, kuri vēro tikai neatbildēto jautājumu skaitu, redz tikai daļu no problēmas.

Tāpēc efektīvs process apvieno darbības datus, redakcionālu pārbaudi un testus. Mērķis nav katru neparastu formulējumu uzreiz kopēt zināšanu bāzē. Mērķis ir atpazīt atkārtotas informācijas vajadzības, noteikt to cēloni un apstiprināt tikai tādas atbildes, par kurām var uzņemties profesionālu atbildību. Šajā rokasgrāmatā parādīta praktiski lietojama darba gaita atbalsta, satura un produktu komandām.

Kas ir zināšanu robs AI čatbotā?

Zināšanu robs pastāv tad, ja uz pamatotu lietotāja jautājumu paredzētajā lietošanas jomā nevar uzticami atbildēt ar apstiprinātu paziņojumu. Tas var nozīmēt, ka informācijas trūkst pilnībā. Biežāk gan tā ir pieejama, taču ir novecojusi, pārāk vispārīga, valodnieciski nepiemērota, nav indeksējama (crawlbar) vai arī nav atrodama meklēšanas (retrieval) procesā. Arī pretrunīgi avoti ir robs: čatbotam tādā gadījumā ir pārāk daudz neskaidru zināšanu, nevis par maz.

Šo jēdzienu nevajadzētu pielīdzināt katrai No-Match situācijai. Google dokumentē Dialogflow CX iebūvētos No-Match notikumus, kad ievadītais teksts neatbilst nevienam nolūkam (intent). Microsoft savā Copilot Studio analītikā min „unrecognized utterances“ – t. i., formulējumus, kas neaktivizē atsevišķu tēmu. Šādi signāli ir noderīgi sākumpunkti, taču paši par sevi nepierāda, ka ir nepieciešams jauns saturs. Iespējams, jautājums bija ārpus darbības jomas (scope), formulējums bija divdomīgs vai arī esošais avots vienkārši netika atrasts.

Kādi signāli jāiekļauj robu analīzē?

Drošas rezerves atbildes (fallbacks) un neatbildēti jautājumi

Visskaidrākās pēdas atstāj tāda atbilde kā „Man nav ticamas informācijas par šo jautājumu“. Šāda droša rezerves atbilde ir labāka par izdomātu apgalvojumu, taču tā būtu jāfiksē kā pārbaudāms notikums. Turklāt būtisks ir ne tikai jautājuma formulējums, bet arī valoda, attiecīgā lapa, laiks, izvēlētais apjoms (scope) un turpmākā sarunas gaita. Personu dati vai konfidenciāls saturs nedrīkst nekontrolēti nonākt rediģēšanas sistēmā.

Zema pārliecība un vāji avoti

Arī sniegtā atbilde var atklāt zināšanu robu. Piemēri ir trūkstoši avoti, meklēšanas rezultāts ar zemu atbilstību, vairāki pretrunīgi avoti vai atbilde, kas aptver tikai daļu no jautājuma. Ar tehnisko pārliecības rādītāju (confidence score) vien nepietiek spriedumam: sliekšņi atšķiras atkarībā no modeļa, sistēmas un riska. Izšķirošais ir tas, vai komanda var izsekot un apstiprināt paziņojumu, balstoties uz autoritatīvu avotu.

Atkārtoti precizējoši jautājumi, pārtraukumi un nodošana cilvēkiem (handoffs)

Ja lietotāji pārfrāzē vienu un to pašu jautājumu, vaicā vairākkārt vai uzreiz pēc tam pieprasa cilvēku, pirmā atbilde var būt aizgājusi garām vajadzībai. Tas pats attiecas uz neparasti lielu sarunu pārtraukumu skaitu pēc noteiktas tēmas. Šādas sarunas jāpārbauda kontekstā. Pāradresācija pie cilvēka (handoff) var būt pareizais risinājums, piemēram, atsevišķu gadījumu lēmumos, sūdzību gadījumos vai strādājot ar jutīgiem datiem. Tā nav automātiski satura kļūda.

Reģiona/valodas (locale) un kanālu atšķirības

Atbilde vācu valodā var darboties labi, kamēr franču varianta trūkst vai produkta nosaukums tiek lietots citādi. Tāpat jautājumi cenu lapā var tikt formulēti citādi nekā palīdzības centrā. Tāpēc klasteriem jābūt pārbaudāmiem vismaz pēc valodas vai reģiona (locale) un lietošanas konteksta. Pretējā gadījumā globāls kopsavilkums var aizsegt skaidri lokalizētu robu.

No neapstrādāta signāla līdz prioritizētam satura uzkrājumam (backlog)

Vienkārša un efektīva darba plūsma neļauj komandai nekontrolēti vākt transkriptus vai pārvērtēt atsevišķus novērojumus. Šos septiņus soļus var veikt katru nedēļu vai biežāk, ja apjoms ir lielāks.

1. Definējiet fiksēšanu: Noteiciet, kuri notikumi tiek uzskatīti par kandidātiem: drošas rezerves atbildes, droša avota trūkums, atkārtoti precizējoši jautājumi, negatīvas atsauksmes norādes, nevajadzīga pāradresācija pie cilvēka vai ziņots nepareizs paziņojums. Dokumentējiet arī to, kādi dati apzināti netiek saglabāti.
2. Attīriet saturu: Dzēsiet vai maskējiet personas datus, pasūtījumu numurus, kontaktinformāciju un brīvos tekstus, kas nav nepieciešami analīzei. Rakstā par datu ziņā taupīgu čatbotu analītiku parādīts, kā notikumus, izlasi (sampling) un glabāšanu var plānot atsevišķi.
3. Normalizējiet jautājumus: Apvienojiet nozīmes ziņā līdzīgus formulējumus, nezaudējot svarīgas atšķirības. „Cik ilgā laikā varu atgriezt preci?“ un „Kāds ir atgriešanas termiņš?“ visticamāk pieder vienam klasterim; „Vai varu atgriezt personalizētu preci?“ var prasīt atsevišķu noteikumu.
4. Klasificējiet cēleni: Elkšķiriet trūkstošu saturu, novecojušu avotu, meklēšanas vai struktūras problēmu, neskaidrus noteikumus, lokalizācijas (locale) robu, apzināti izslēgtu darbības jomu un nepieciešamību pēc cilvēka lēmuma. Šī diagnoze nosaka veicamos pasākumus.
5. Nosakiet prioritāti: Novērtējiet biežumu, ietekmi uz lietotāju, biznesa nozīmīgumu un risku. Rets norādījums par drošībai kritisku ierobežojumu var būt svarīgāks par biežu sarunu par ikdienišķām tēmām (smalltalk). Formulai jābūt saprotamai un pārbaudāmai jūsu uzņēmumam, nevis matemātiski sarežģītai.
6. Piešķiriet atbildību par avotiem: Katrai plānotajai atbildei ir nepieciešams autoritatīvs avots un persona vai loma, kas drīkst apstiprināt tās saturu. Ja trūkst abu, ieraksts paliek atvērts; valodas modelis nedrīkst izdomāt noteikumus. Piemērotu darbības modeli apraksta pamācība par satura pārvaldību (content governance) AI čatbotiem.
7. Izveidojiet pieņemšanas testu: Saglabājiet reprezentatīvus jautājumus, paredzētos pamata paziņojumus, pieļaujamos avotus un paredzēto uzvedību ārpus definētā apjoma. Pēc katras izmaiņas tiek pārbaudīts, vai robs ir novērsts un vai esošās atbildes paliek stabilas.

Kādi lauki ir nepieciešami labam darba uzkrājuma (backlog) ierakstam?

Pieteikums ar nosaukumu „Čatbots nezina atgriešanas termiņu“ ir pārāk virspusējs. Tā dēļ viegli var tikt izveidots teksts, kas gan atbild uz piemēra vaicājumu, bet neņem vērā variantus, izņēmumus vai atbildības. Apstrādājams ieraksts satur vismaz:

• neitrālu klastera tēmu un divus līdz piecus anonimizētus piemēru jautājumus,
• lokalizāciju (locale), lapas kontekstu un skarto lietotāja ceļu,
• novēroto uzvedību, kā arī vēlamo uzvedību,
• cēloņa kategoriju un pamatotu prioritāti,
• autoritatīvu avota URL vai statusu „avots trūkst“,
• profesionālo atbildīgo īpašnieku, pārbaudes lomu un izpildes termiņa mērķi,
• derīguma termiņu, zināmos izņēmumus un vēlamo pāradresācijas uzvedību,
• testēšanas gadījumus un mērāmus pieņemšanas kritērijus.

Tādējādi čata novērojums pārtop par redakcionālu darba vienību. Vienlaikus paliek redzams, vai problēmu patiešām var atrisināt ar saturu. Piemēram, tehniska meklēšanas kļūda pieder meklēšanas vai platformas komandai; neskaidrs atgriešanas noteikums – par jomu atbildīgajai strukturālajai vienībai.

Praktisks piemērs: pareiza atbilžu sniegšana uz jautājumiem par preču atgriešanu

Pieņemsim, ka lietotāji atkārtoti jautā par personalizētu produktu atgriešanu. Čatbots brīžiem nosauc vispārīgo termiņu, brīžiem neprecīzu izņēmumu un reizēm nodod jautājumu atbalsta dienestam. Komandai nevajadzētu izdomāt jaunu noteikumu, balstoties uz līdzšinējām atbildēm. Vislabāk vispirms noskaidrot, kādi apstiprināti noteikumi pastāv, uz kurām valstīm un produktu grupām tie attiecas un kad ir nepieciešama atsevišķa pārbaude.

Pēc tam tiek izveidots strukturēts avots ar vispārīgo noteikumu, skaidri nosauktiem izņēmumiem, derīguma jomu un eskalācijas kritēriju. Testēšanas gadījumi aptver tiešos jautājumus, sarunvalodas variantus, citu reģionu/valodu un apzināti neautomatizējamu robežgadījumu. Robežgadījumā tiek sagaidīta caurspīdīga pāradresācija pie cilvēka (Human Handoff) – nevis mākslīgi piespiesta pašapkalpošanās atbilde.

Kāpēc vairāk satura automātiski nenozīmē labāku rezultātu

Bieža kļūda ir mēģinājums atbildēt uz katru klasteri ar jaunu FAQ sadaļu. Tas var radīt dublikātus, pretrunas un pasliktināt meklēšanas rezultātus. Pirms jauna satura izveides pārbaudiet, vai esošo lapu nevajadzētu papildināt, labāk strukturēt vai izslēgt no indeksēšanas (crawl scope). Process atjauninātas zināšanu bāzes uzturēšanai palīdz izvēlēties avotus, plānot indeksēšanas biežumu un kontrolēt novecojušu saturu.

Tāpat ir riskanti pārņemt reālus lietotāju formulējumus kā apmācības vai testa datus bez pārbaudes. Google savās izstrādes vadlīnijās norāda, ka nekontrolēta No-Match ievades datu pievienošana var izraisīt nevēlamu nolūka nobīdi (intent bias). Tikai cēloņu pārbaude ļauj izlemt, vai formulējums būtu jāpapildina, jāattīra esošais formulējums vai jāizlabo nepareizi konkurējošs nolūks.

Cikla noslēgšana ar regresijas testiem

Robs netiek uzskatīts par novērstu uzreiz pēc jauna teksta publicēšanas. Tas ir novērsts tad, kad reprezentatīvi jautājumi paredzētajā kontekstā parāda sagaidāmo uzvedību. Google apraksta testa gadījumus ar cerībām sarunas vai atsevišķa replikas līmenī un salīdzināšanu ar vēlamo paraugu (Golden Case). Tīmekļa vietņu čatbotiem šo principu var lietot neatkarīgi no modeļa: tiek dokumentēts jautājums, sagaidāmais pamata paziņojums, atļautais avots, nepieciešamais handoffs un aizliegtie apgalvojumi.

Neliels, labi uzturēts testu komplekts ir vērtīgāks par lielu, nepārbaudītu kolekciju. Iekļaujiet apstiprinātos robus esošajā Golden Set un veiciet attiecīgo gadījumu atkārtotu pārbaudi pēc satura, uzvednes (prompt), modeļa vai meklēšanas mehānisma izmaiņām. Detalizētā pamācība par AI čatbota atbilžu kvalitātes mērīšanu padziļināti iztirzā šo pārbaudes darba gaitu.

Kādi rādītāji liecina par progresu?

Nevērojiet tikai globālo rezerves atbilžu īpatsvaru (fallback rate). Daudz informatīvāka ir neliela rādītāju kopa: atvērtie prioritizētie klasteri, laiks līdz satura noskaidrošanai, to uzkrājuma ierakstu īpatsvars, kuriem ir autoritatīvs avots, izturētie regresijas testi un atkārtoti radušies robi pēc apstiprināšanas. Segmentējiet rezultātus pēc reģiona/valodas (locale) un galvenā lietošanas ceļa, padziļināti neanalizējot mazas grupas tādā mērā, ka personas kļūst netieši atpazīstamas.

Microsoft norāda neatpazītus izteikumus un tēmas ar zemu atrisināšanas rādītāju kā iespējamos optimizācijas signālus. Savukārt NIST mākslīgā intelekta risku pārvaldības satvarā (AI Risk Management Framework) uzsver nepārtrauktu uzraudzību, dokumentētus testu komplektus, atsauksmes un uzvedības novērošanu darbības laikā. No tā izriet svarīgs darba noteikums: rādītājiem būtu jāatbalsta lēmumu pieņemšana, taču tie nedrīkst aizstāt atbildes avota profesionālu pārbaudi.

Iknedēļas kontrolsaraksts atbalsta dienestam un redakcijai

• Datutaupīgā veidā fiksējiet jaunus kandidātus un atsijājiet acīmredzamu ļaunprātīgu izmantošanu.
• Grupējiet līdzīgas nozīmes jautājumus pēc katra reģiona/valodas (locale) un papildiniet esošos klasterus.
• Svarīgākajiem klasteriem apstipriniet cēloni, ietekmi un risku.
• Meklējiet esošos avotus, atzīmējiet pretrunas un noskaidrojiet atbildību.
• Publicējiet tikai apstiprinātas izmaiņas; saglabājiet skaidras robežas (scope) un pāradresāciju.
• Izpildiet reprezentatīvus testēšanas gadījumus un dokumentējiet rezultātus.
• Pēc dažām lietošanas dienām pārbaudiet, vai klasteris atkārtojas vai ir mainījis tikai savu formu.

Secinājums: zināšanu robi ir redakcionāls kontroles cikls

Neatbildētie jautājumi kļūst vērtīgi tikai tad, ja komanda tos uztver nevis kā atsevišķus čata protokolus, bet gan kā pārbaudāmas norādes. Fiksēšana, attīrīšana, grupēšana, cēloņu noteikšana, prioritāšu piešķiršana, avota apstiprināšana un testēšana: šis kontroles cikls savieno atbalsta ikdienu ar uzticamu zināšanu bāzi. Tas nesamazina katru pāradresāciju un apzināti neatbild uz katru jautājumu automātiski. Tā vietā tas parāda, kur čatbots var uzticami palīdzēt – un kur skaidra robeža ir labākas lietotāja pieredzes atslēga.

Avoti

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