DI pokalbių robotų atsakymų atatsakymo scenarijai: kaip saugiai atpažinti ir nukreipti žinių spragas

Svetainės pokalbių robotas neprivalo atsakyti į kiekvieną klausimą. Svarbiausia – kad jis atpažintų, kada žinių bazė neturi patikimo pagrindo, ir išliktų naudingas lankytojams. Jei spraga užpildoma įtikinamai skambančia prielaida, kyla pasitikėjimo problema: neteisingas pristatymo terminas, išgalvota produkto taisyklė ar netinkamas pagalbos nurodymas gali sukelti daugiau rūpesčių nei aiški, trumpa riba.

Kodėl rezultatų nebuvimas yra atskira produkto problema

Kai DI pokalbių robotas su žinių baze nepateikia atsakymo, tam gali būti bent trys skirtingos priežastys. Pirma, informacija iš tiesų gali nesuteikta. Antra, ji gali būti žinių bazėje, tačiau nerandama dėl kalbos, formuluotės, metaduomenų ar reitingavimo. Trečia, ji randama, tačiau jos nepakanka saugiam atsakymui suformuoti. Chat lange šie atvejai iš pradžių atrodo panašiai, tačiau praktikoje reikalauja skirtingų veiksmų.

Informacijos paieškos (angl. Retrieval) sistemos automatiškai neįvertina, ar atsakymas yra verslo požiūriu priimtinas. Oficiali Retrieval-Augmented Generation (RAG) apžvalga „Azure AI Search“ sistemoje aprašo, kaip galima sujungti teksto ir vektorių paiešką, kad būtų pateikti šaltiniai atsakymui. Šis derinys pagerina paiešką, tačiau nepakeičia taisyklės, kada rezultatas laikomas pakankamu. Todėl pokalbių robotui prieš generuojant tekstą reikalingas aiškiai apibrėžtas sprendimas: atsakyti, pasitikslinti ar saugiai nukreipti toliau.

Atsakymo nebuvimas nėra aklavietė

Naudingas atsakymo atatsakymas (angl. fallback) nesako tiesiog „Apie tai informacijos neturiu“. Jį sudaro keturi elementai: jis įvardija ribą be techninių pasiteisinimų, vengia nepagrįstų teiginių, pasiūlo tikslų patikslinamąjį klausimą arba saugią alternatyvą ir, jei reikia, parodo kelią pas žmogų. Tonalumas gali būti draugiškas, tačiau neturi paslėpti neapibrėžtumo.

• Riba: „Patvirtintoje informacijoje nerandu patikimų duomenų šiuo klausimu.“
• Kontekstas: „Ar klausimas susijęs su užsakymu, sutartimi ar techniniu diegimu?“
• Kitas žingsnis: „Jei nurodysite produkto pavadinimą, galiu iš naujo patikrinti turimus dokumentus.“
• Perdavimas (Handoff): „Kad užklausa būtų patikrinta oficialiai, nukreipsime ją atsakingai komandai.“

Taip pokalbis išlieka naudingas, neišgalvojant kainų, terminų, teisinių pasekmių ar įsipareigojimų. Ypač tvarkant asmens duomenis, mokėjimus, individualius pasiūlymus ir su saugumu susijusius klausimus, perdavimo taisyklė turėtų suveikti anksčiau. Jau publikuotas gidas apie žmogiškąjį perdavimą svetainės aptarnavime padeda suplanuoti perdavimus kaip aiškų procesą, o ne kaip avarinį išėjimą.

Sprendimo priėmimo prieš atsakymą įgyvendinimas

Komandos neturėtų aklai perimti „magiškų“ ribinių reikšmių iš demonstracinių versijų. Paieškos balas tebūna signalas ir gali kisti priklausomai nuo indekso, modelio, kalbos ar užklausų derinio. Dokumentacija apie Semantinį reitingavimą (Semantic Ranking) atkreipia dėmesį, kad reitingavimo balų pasiskirstymas gali skirtis. Todėl slenkstinė reikšmė visada turi būti susieta su patikrinta duomenų baze ir konkrečia klaidos klase.

Praktinis sprendimas gali sujungti kelis patikrinimus. Ar yra bent vienas šaltinis iš leidžiamos turinio srities? Ar jis atitinka kalbą ir dabartinę produkto bei sutarties versiją? Ar jame yra tiesioginis argumentas planuojamam atsakymui? Ar geriausi paieškos rezultatai vienas kitam neprieštarauja? Tik tada, kai šie kriterijai yra pakankamai įvykdyti, generatoriui leidžiama suformuluoti atsakymą. Priešingu atveju robotas tikslingai paklausia arba pereina prie atsakymo atatsakymo.

Pavyzdys: Įsipareigojanti informacija apie pristatymą

Jei asmuo teiraujasi apie konkretaus produkto pristatymo terminą, bendro straipsnio apie siuntimą nepakanka. Robotas gali paaiškinti, kad neranda tikslios informacijos, paprašyti užsakymo numerio ar produkto varianto ir nukreipti į klientų aptarnavimą. Atsakymas „Jūsų siunta atvyks rytoj“ šiuo atveju ne būtų pagrįstas žinių baze. Tas pats principas galioja garantijoms, sutarties nutraukimui, sveikatos klausimams ir prieigai prie paskyros: kuo didesnė galima žala, tuo tvirtesnių įrodymų reikia.

Paieškos patikrinimas prieš perrašant turinį

Atsakymo nebuvimas dažnai yra geras matavimo signalas. Prieš rašydama naują sisteminį nurodymą (prompt), komanda turėtų peržiūrėti visą grandinę: originalų klausimą, atpažintą kalbą, normalizuotą paieškos užklausą, pritaikytus filtrus, geriausius paieškos rezultatus, naudotas šaltinių versijas ir pasirinktą baigtį. Taip iškart matyti, ar trūksta dokumento, ar paieška praėjo pro šalį.

1. Anonimiškai suklasifikuoti klausimą ir tikslą, pavyzdžiui: produktas, pagalba, paskyra ar teisiniai klausimai.
2. Palyginti tikėtinus šaltinius ir faktiškai gautus rezultatus.
3. Užregistruoti kalbos, galiojimo, prieigos ir produkto versijos filtrus.
4. Patikrinti, ar geriausi rezultatai iš tiesų įrodo atsakymą, ar tik turi panašių terminų.
5. Pažymėti atvejį kaip dokumentacijos spragą, paieškos problemą, saugumo taisyklę arba pagrįstą perdavimą žmogui.

Tokiems palyginimams tinka nedidelis „Auksinis rinkinys“ (Golden Set), sudarytas iš tikroviškų, iš anksto išvalytų klausimų. Straipsnyje apie DI pokalbių roboto atsakymų kokybės matavimą paaiškinama, kodėl kritiniai ir reti klausimai neturi pradingti bendrame vidurkyje. Sąmoningai įtraukite klausimų be tinkamo atsakymo. Tik taip galima patikrinti, ar pokalbių robotas saugiai reaguoja ir žinių trūkumo atveju.

Žinių spragų perkėlimas į redakcinį procesą

Vienas pokalbio langas dar nėra užduotis kurti naują DUK straipsnį. Tačiau keli vienodi saugūs atsatakymo scenarijai gali parodyti, kad svarbios informacijos trūksta arba ji sunkiai randama. Tam pakanka taupaus duomenų sąrašo su tikslu, klaidos klase, susijusia kalba, esamais šaltinių ID ir būsena. Visas pokalbių turinys, vardai ar paskyros duomenys neturėtų patekti į bendrą analizės skydelį.

Atsakingas kanceliarijos ar srities specialistas tada nusprendžia, ar papildyti DUK, tikslinti produkto puslapį, pagerinti metaduomenis ar pakoreguoti perdavimo tekstą. Kiekvienam papildymui reikalingas atsakingas asmuo, šaltinis ir data. Laikui jautriai informacijai, pavyzdžiui, likučiams ar akcijoms, papildomai naudinga nustatyti galiojimo pabaigos datą. Taip komanda išvengia situacijos, kai gerai apgalvotas straipsnis pats tampa kitu pasenusiu šaltiniu.

Nenaudokite haliucinacijų dažnio kaip kokybės rodiklio

Žemas matomų klaidų dažnis gali klaidingai sudaryti gerą įspūdį, jei robotas tiesiog per dažnai išsisukinėja nuo atsakymo. Ir priešingai – didelis atsakymų dažnis nėra sėkmė, jei atsakymai nesiremia šaltiniais. Geriau naudoti nedidelį rodiklių rinkinį: saugiai atsakytų užklausų dalis, pagrįstų atatsakymų dalis, perdavimo žmogui rodiklis pagal tikslą, laikas iki specialisto sprendimo, pasikartojančios spragos ir rankinių patikrinimų rezultatai. Analizė turi būti prieinama atskirai pagal kalbą, produkto sritį ir rizikos klasę.

NIST AI Risk Management Framework rekomenduoja valdyti riziką atsižvelgiant į kontekstą ir įdiegti matavimo bei valdymo procesus. Svetainių komandoms tai nereiškia, kad reikia saugoti kiekvieną pokalbį. Tai reiškia turėti aiškią atsakomybę ir tikrinamus kriterijus saugiems atsakymams.

Be to, patikrinimas turėtų atitikti realias naudojimo situacijas. Trumpas klausimas išmaniuoju telefonu dažnai turi mažiau konteksto nei išsamus užklausa kompiuteryje. Rašybos klaidos, produktų trumpiniai ir maišomos kalbos yra tikėtini įvesties duomenys, o ne išimtys. Todėl tikrinkite ne tik idealiai suformuluotą klausimą, bet ir variantus be užsakymo numerio, su keliais produktų pavadinimais arba neaiškiu laiko nurodymu. Kiekvienas variantas turi pateikti arba pagrįstą atsakymą, arba prasmingą patikslinimą, arba saugų perdavimą. Atsakymo atatsakymas, veikiantis tik su idealiai suformuluotais testo klausimais, kasdienybėje neapsaugos.

Ne mažiau svarbus ir grįžtamasis ryšys iš klientų aptarnavimo komandos. Kai darbuotojai atsako į nukreiptą užklausą, jie gali trumpai kategorizuoti priežastį: trūko informacijos, informacija buvo pasenusi, reikėjo specialios prieigos arba užklausai reikėjo individualaus sprendimo. Šios kategorijos sujungia svetainę, žinių redakciją ir aptarnavimą, nepaverčiant klausiančiojo asmens analizės objektu. Mėnesio apžvalgos apie dažniausias kategorijas paprastai pakanka prioritetiniams patobulinimams suplanuoti.

Saugaus atsatakymo (fallback) kontrolinis sąrašas

• Atsakymai teikiami tik naudojant tinkamus, patvirtintus ir aktualius šaltinius.
• Signalų slenksčiai ir deriniai buvo patikrinti naudojant „Auksinį rinkinį“ (Golden Set).
• Aukštos rizikos klasės turi atskiras taisykles patikslinimui ir perdavimui žmogui.
• Atsataskymo tekstai paaiškina ribą, nekurti vidinių techninių pasiteisinimų ar netikro saugumo jausmo.
• Žurnaluose (logs) saugoma tik būtina, duomenis taupanti diagnostinė informacija.
• Pasikartojantys atvejai gauna atsakingą asmenį ir patikrinamą patobulinimo būseną.
• Nauji šaltiniai iš naujo patikrinami prieš patvirtinimą, po pakeitimų ir pasibaigus galiojimui.

Išvada: Sąžiningos ribos pagerina atsakymų kokybę

Profesionalus DI pokalbių robotas neatsako į kiek įmanoma daugiau, o tik į tai, kas grindžiama jo patikrinta žinių baze. Geriausias atsatakymas yra konkretus, naudingas ir be kliūčių perduoda įsipareigojimų reikalaujančias užklausas. Kai komandos laiko atvejus be atsakymo testavimo duomenimis ir redakciniais signalais, tiek paieška, tiek turinys matomai gerėja. Pradėkite nuo dešimties svarbių klausimų, dešimties sąmoningai neatsakomų klausimų ir aiškaus perdavimo proceso kiekvienai rizikos klasei. Tai sukurs patikimą pagrindą, prieš pokalbių robotui perimant daugiau atsakomybės.

Šaltiniai

• 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