DI pokalbių roboto žinių spragų atpažinimas: sistemingas neatsakytų klausimų sprendimas

Svetainės pokalbių robotas gali patikimai atsakinėti tik tada, kai gauna tinkamą, patvirtintą ir lengvai randamą informaciją. Praktikoje žinių spragos retai pasirodo kaip tvarkinga ataskaita. Jos slepiasi saugiuose atsarginiuose (fallback) atsakymuose, pakartotiniuose patikslinimuose, nereikalinguose nukreipimuose žmogui arba atsakymuose, kurie skamba įtikinamai, tačiau neturi patikimo šaltinio. Todėl tiems, kurie vertina tik neatsakytų klausimų skaičių, matoma tik dalis problemos.

Atsižvelgiant į tai, veiksmingas procesas apjungia veiklos duomenis, redakcinį patikrinimą ir testus. Tikslas nėra kiekvieną neįprastą formuluotę iškart kopijuoti į žinių bazę. Tikslas – atpažinti pasikartojančius informacijos poreikius, nustatyti jų priežastį ir patvirtinti tik tokius atsakymus, už kuriuos galima prisiimti profesinę atsakomybę. Šiame vadove pristatomas praktiškas procesas klientų aptarnavimo, turinio ir produktų komandoms.

Kas yra DI pokalbių roboto žinių spraga?

Žinių spraga atsiranda tada, kai į pagrįstą naudotojo klausimą numatytoje naudojimo srityje negalima patikimai atsakyti patvirtintu teiginiu. Tai gali reikšti, kad informacijos visiškai nėra. Tačiau dažniau ji egzistuoja, bet yra pasenusi, per daug bendra, kalbiškai netinkama, nenuskaitoma paieškos robotų (not crawlable) arba nerandama paieškos (retrieval) metu. Prieštaringi šaltiniai taip pat yra spraga: tokiu atveju pokalbių robotas turi per daug dviprasmiškų žinių, o ne per mažai.

Šios sąvokos nereikėtų tapatinti su kiekviena „neatitikimo“ (No-Match) situacija. „Google“ dokumentuoja „Dialogflow CX“ integruotus „No-Match“ įvykius, kai įvestys neatitinka jokio ketinimo (intent). „Microsoft“ savo „Copilot Studio“ analitikoje minėtus atvejus vadina „unrecognized utterances“ – t. y. formuluotėmis, kurios nesuaktyvina atskiros temos. Tokie signalai yra naudingas atskaitos taškas, tačiau dar neįrodo, kad reikia naujo turinio. Galbūt klausimas neįėjo į veikimo sritį (out of scope), formuluotė buvo dviprasmiška arba tiesiog nebuvo rastas esamas šaltinis.

Kokie signalai priklauso spragų analizei?

Saugūs atsarginiai atsakymai (fallbacks) ir neatsakyti klausimai

Aiškiausias pėdsakas – tai atsakymas, pavyzdžiui, „Apie tai neturiu patikimos informacijos“. Šis saugus atsarginis atsakymas (fallback) yra geriau nei išgalvotas teiginys, tačiau jis turėtų būti užfiksuotas kaip patikrinamas įvykis. Svarbu ne tik klausimo formuluotė, bet ir kalba, susijęs puslapis, laikas, pasirinkta sritis ir tolesnė pokalbio eiga. Asmens duomenys ar konfidencialus turinys neturėtų patekti į redagavimo sistemą neanonymizuoti.

Žemas patikimumo lygis ir silpna šaltinių bazė

Nurodytas atsakymas taip pat gali atskleisti žinių spragą. Pavyzdžiui, trūksta šaltinių, paieškos (retrieval) rezultatas yra mažai atitinkantis, rasti keli prieštaringi šaltiniai arba atsakymas padengia tik dalį klausimo. Vien tik techninio patikimumo (confidence) balo neužtenka: ribos skiriasi priklausomai nuo modelio, sistemos ir rizikos. Svarbiausia – ar komanda gali patikrinti ir patvirtinti teiginį remdamasi autoritingu šaltiniu.

Pakartotiniai patikslinimai, nutrūkę pokalbiai ir perdavimai žmogiškajam agentui (handoffs)

Jei naudotojai iš naujo formuluoja tą patį klausimą, kelis kartus tikslinasi arba iškart po to pareikalauja žmogaus pagalbos, pirmasis atsakymas galėjo neatitikti poreikio. Tai galioja ir neįprastai dideliam pokalbių nutrūkimo skaičiui po tam tikros temos. Tokias eigas būtina nagrinėti kontekste. Perdavimas žmogui (handoff) gali būti teisingas sprendimas, pavyzdžiui, nagrinėjant individualius atvejus, skundus ar jautrius duomenis. Tai nėra automatiškai turinio klaida.

Lokalizacijos (locale) ir kanalų skirtumai

Atsakymas vokiečių kalba gali veikti puikiai, tuo tarpu varianto prancūzų kalba trūksta arba produkto pavadinimas vartojamas kitaip. Taip pat klausimai kainų puslapyje gali būti formuluojami kitaip nei pagalbos centre. Todėl grupės (klasteriai) turėtų išlikti patikrinami bent jau pagal kalbą / lokalizaciją (locale) ir naudojimo kontekstą. Priešingu atveju bendra visuotinė suvestinė gali paslėpti aiškiai lokalizuotą spragą.

Nuo neapdoroto signalo iki prioritetizuoto turinio darbų sąrašo (backlog)

Sklandus procesas neleidžia komandai aklai rinkti transkripcijų ar pervertinti pavienių stebėjimų. Šiuos septynis žingsnius galima atlikti kas savaitę arba dažniau, jei srautas didesnis.

1. Apibrėžkite fiksavimą: Nustatykite, kokie įvykiai laikomi kandidatais: saugus atsarginis atsakymas (fallback), patikimo šaltinio trūkumas, pakartotinis klausimas, neigiamas atsiliepimas, nereikalingas perdavimas žmogui arba pranešta klaidinga informacija. Taip pat užfiksuokite, kokie duomenys sąmoningai nesaugomi.
2. Išvalykite turinį: Pašalinkite arba užmaskuokite asmens duomenis, užsakymų numerius, kontaktinę informaciją ir laisvą tekstą, kuris nebūtinas analizei. Vadove apie duomenis taupančią pokalbių roboto analitiką rodoma, kaip atskirai planuoti įvykius, imtis (sampling) ir saugojimą.
3. Normalizuokite klausimus: Sugrupuokite vienodos reikšmės formuluotes, neprarandant svarbių skirtumų. „Per kiek laiko galiu grąžinti?“ ir „Koks yra grąžinimo terminas?“ greičiausiai priklauso vienam klasteriui; „Ar galiu grąžinti personalizuotą prekę?“ gali reikalauti atskiros taisyklės.
4. Klasifikuokite priežastį: Atskirkite trūkstamą turinį, pasenusį šaltinį, paieškos (retrieval) ar struktūros problemą, neaiškią politiką, lokalizacijos spragą, sąmoningai pašalintą veikimo sritį ir būtiną žmogaus sprendimą. Ši diagnozė nustato tolesnius veiksmus.
5. Nustatykite prioritetą: Įvertinkite dažnumą, poveikį naudotojui, svarbą verslui ir riziką. Retas pastebėjimas apie saugumui kritinį apribojimą gali būti svarbesnis nei dažnas kasdienis klausimas (smalltalk). Formulė jūsų įmonėje turi būti suprantama ir patikrinama, o ne matematiškai sudėtinga.
6. Paskirkite atsakomybę už šaltinį: Kiekvienam planuojamam atsakymui reikia autoritingo šaltinio ir asmens ar vaidmens, galinčio patvirtinti jo turinį. Jei trūksta abiejų, įrašas lieka atviras; kalbos modelis negali pats išgalvoti politikos. Tinkamą veiklos modelį aprašo DI pokalbių robotų turinio valdymo (content governance) vadovas.
7. Sukurkite priėmimo testą: Išsaugokite reprezentatyvius klausimus, numatytus esminius teiginius, leistinus šaltinius ir laukiamą elgseną už veikimo srities ribų. Po kiekvieno pakeitimo tikrinama, ar spraga pašalinta ir ar esami atsakymai išlieka stabilūs.

Kokių laukų reikia geram darbų sąrašo (backlog) įrašui?

Užduotis su pavadinimu „Pokalbių robotas nežino grąžinimo termino“ yra per daug paviršutiniška. Ji lengvai veda prie teksto, kuris atsako į pavyzdinę užklausą, tačiau neatsižvelgia į variantus, išimtis ar atsakomybes. Tinkamai parengtame įraše turi būti bent:

• neutrali klasterio tema ir nuo dviejų iki penkių anonimizuotų pavyzdinių klausimų,
• lokalizacija (locale), puslapio kontekstas ir susijęs naudotojo kelias,
• stebėta elgsena bei pageidaujama elgsena,
• priežasties klasė ir pagrįstas prioritetas,
• autoritingo šaltinio URL arba būsena „Šaltinio trūksta“,
• turinio savininkas, peržiūros vaidmuo ir įvykdymo terminas,
• galiojimo data, žinomos išimtys ir pageidaujama perdavimo žmogui elgsena,
• testavimo atvejai ir matuojami priėmimo kriterijai.

Taip pokalbio stebėjimas paverčiamas redakciniu darbo vienetu. Kartu išlieka aišku, ar problema tikrai gali būti išspręsta turiniu. Pavyzdžiui, techninė paieškos klaida priklauso paieškos ar platformos komandai; neišaiškinta grąžinimo taisyklė – už sritį atsakingam padaliniui.

Praktinis pavyzdys: kaip teisingai išspręsti klausimus dėl grąžinimo

Tarkime, naudotojai pakartotinai klausia apie personalizuotų produktų grąžinimą. Pokalbių robotas kartais nurodo bendrą terminą, kartais neaiškią išimtį, o kartais nukreipia į klientų aptarnavimą. Komanda neturėtų kurti naujos taisyklės remdamasi tik ankstesniais atsakymais. Pirmiausia išaiškinama, kokia patvirtinta politika galioja, kurioms šalims bei produktų grupėms ji taikoma ir kada reikalingas individualus patikrinimas.

Tada sukuriamas struktūrizuotas šaltinis su bendra taisykle, aiškiai įvardytomis išimtimi, galiojimo sritimi ir eskalavimo kriterijumi. Testavimo atvejai apima tiesioginius klausimus, šnekamosios kalbos variantus, kitą lokalizaciją ir sąmoningai neautomatizuojamą ribinį atvejį. Ribiniam atvejui tikimasi skaidraus perdavimo žmogui (human handoff), o ne priverstinio savitarnos atsakymo.

Kodėl daugiau turinio ne visada yra geriau

Dažna klaida – bandymas į kiekvieną klasterį atsakyti nauju DUK įrašu. Tai gali sukelti dubliavimąsi, prieštaravimus ir pabloginti paieškos rezultatus. Prieš kurdami naują turinį, patikrinkite, ar esamas puslapis turėtų būti papildytas, geriau sustruktūrizuotas, ar pašalintas iš skaitomo turinio srities (crawl scope). Procesas, aprašytas vadove apie žinių bazės atnaujinimo palaikymą, padeda pasirinkti šaltinius, nustatyti nuskaitymo dažnumą ir valdyti pasenusį turinį.

Taip pat rizikinga tikras naudotojų formuluotes nepatikrinus naudoti kaip mokymo ar testavimo duomenis. „Google“ savo dizaino gairėse pažymi, kad atsitiktinis „No-Match“ įvesčių pridėjimas gali sukelti nepageidaujamą ketinimų šališkumą (intent bias). Tik priežasčių analizė nustato, ar formuluotę reiktų papildyti, sutvarkyti esamą formuluotę, ar ištaisyti neteisingai konkuruojantį ketinimą (intent).

Ciklo užbaigimas atliekant regresinius testus

Spraga nelaikoma pašalinta vien tik išpublikavus naują tekstą. Ji laikoma pašalinta, kai reprezentatyvūs klausimai numatytame kontekste rodo laukiamą elgseną. „Google“ aprašo testavimo atvejus su lūkesčiais pokalbio ar posūkio (turn) lygmeniu ir palyginimu su „Auksiniu pavyzdžiu“ (Golden Case). Svetainės pokalbių robotams šis principas gali būti taikomas nepriklausomai nuo modelio: dokumentuojamas klausimas, numatytas esminis teiginys, leidžiamas šaltinis, reikalingas perdavimas žmogui ir draudžiami teiginiai.

Mažas, gerai prižiūrimas testų rinkinys yra vertingesnis už didelę nepatikrintą kolekciją. Įtraukite patvirtintas spragas į esamą „Auksinį rinkinį“ (Golden Set) ir iš naujo atlikite susijusius testus pakeitus turinį, sisteminį nurodymą (prompt), modelį ar paieškos (retrieval) nustatymus. Išsamus DI pokalbių roboto atsakymų kokybės matavimo vadovas išsamiau paaiškina šį peržiūros procesą.

Kokie rodikliai rodo pažangą?

Stebėkite ne tik bendrą atsarginių atsakymų (fallback) rodiklį. Daugiau informacijos suteikia nedidelis rodiklių rinkinys: atviri prioritetiniai klasteriai, laikas iki turinio išaiškinimo, darbų sąrašo (backlog) įrašų su autoritingu šaltiniu dalis, išlaikyti regresiniai testai ir vėl atsirandančios spragos po patvirtinimo. Segmentuokite rezultatus pagal lokalizaciją (locale) ir pagrindinį naudojimo kelią, nedetalizuodami mažų grupių tiek, kad būtų galima netiesiogiai atpažinti asmenis.

„Microsoft“ įvardija neatpažintas formuluotes ir temas su žemu sprendimo rodikliu kaip galimus optimizavimo signalus. NIST savo „AI Risk Management Framework“ kartu pabrėžia nuolatinį stebėjimą, dokumentuotus testų rinkinius, grįžtamąjį ryšį ir elgsenos stebėjimą gamybinėje aplinkoje. Iš to išplaukia svarbi darbo taisyklė: rodikliai turi padėti priimti sprendimus, tačiau neturi pakeisti turinio šaltinio patikrinimo iš esmės.

Kassavaitinis kontrolinis sąrašas klientų aptarnavimo ir redakcijos komandoms

• Taupydami duomenis fiksuokite naujus kandidatus ir atmeskite akivaizdžias piktnaudžiavimo užklausas.
• Sugrupuokite vienodos reikšmės klausimus pagal lokalizaciją (locale) ir papildykite esamus klasterius.
• Svarbiausiems klasteriams patvirtinkite priežastį, poveikį ir riziką.
• Išieškokite esamus šaltinius, pažymėkite prieštaravimus ir išaiškinkite atsakomybę.
• Publikuokite tik patvirtintus pakeitimus; aiškiai apibrėžkite veikimo sritį ir perdavimą žmogui.
• Atlikite reprezentatyvius testavimo atvejus ir dokumentuokite rezultatus.
• Po kelių naudojimo dienų patikrinkite, ar klasteris vėl neatsirado arba ar nepasikeitė jo forma.

Išvada: žinių spragos yra redakcinis valdymo ciklas

Neatsakyti klausimai tampa vertingi tik tada, kai komanda į juos žiūri ne kaip į atskirus pokalbių protokolus, o kaip į patikrinamus signalus. Užfiksavimas, išvalymas, grupavimas (klasterizavimas), priežasties nustatymas, prioritetų suteikimas, šaltinio patvirtinimas ir testavimas: šis ciklas sujungia klientų aptarnavimo realybę su patikima žinių baze. Jis nesumažina kiekvieno perdavimo žmogui ir sąmoningai neatsako į kiekvieną klausimą automatiškai. Tačiau jis padaro matoma, kur pokalbių robotas gali patikimai padėti – ir kur aiški riba užtikrina geresnę naudotojo patirtį.

Šaltiniai

• 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