DI pokalbių botų analitika taupant duomenis: įvykiai, imtys ir saugojimas

DI pokalbių botų analitika turi parodyti, ar lankytojai gauna tinkamus atsakymus, kada pokalbiai nutrūksta ir kurioje vietoje turėtų perimti žmogiškoji komanda. Tačiau tam įmonėms nebūtina automatiškai visiška apimtimi išsaugoti kiekvieno pokalbio. Dažnai redakcinei kokybės patikrai pakanka aiškiai apibrėžtų įvykių, agreguotų rodiklių ir nedidelės, kontroliuojamos imties.

Todėl duomenis taupanti matavimo koncepcija prasideda ne nuo kuo didesnės duomenų saugyklos, o nuo konkrečių sprendimų: koks rodiklis atsako į kokį klausimą? Kokia informacija tam tikrai reikalinga? Kas gali ją matyti ir kada ji bus ištrinta? Šiame gide aprašoma praktiška struktūra svetainės, klientų aptarnavimo ir produktų komandoms. Jis nepakeičia individualios teisinės konsultacijos.

Pradėkite nuo sprendimų, o ne nuo neapdorotų protokolų

Daugelis analitikos projektų iš pradžių renka viską, o vėliau svarsto, kokia analizė prasminga. Pokalbių botų atveju tokia praktika ypač rizikinga: laisvajame tekste gali būti vardų, el. pašto adresų, užsakymų numerių, sveikatos duomenų ar kitos informacijos, kurią lankytojas įveda savanoriškai arba netyčia. Net jei įvesties lauke to neprašoma, tokie duomenys gali pasirodyti pokalbyje.

Pirmiausia apibrėžkite verslo klausimus. Norite sužinoti, ar botas išsprendė užklausą? Tuomet jums reikia rezultato įvykio ir aiškaus „išspręsta“ apibrėžimo. Jei reikia patikrinti nukreipimo kokybę, dažnai pakanka atpažintos intencijos klasės, tikslinio maršruto ir faktinės baigties. Straipsnyje DI pokalbių boto nukreipimo testavimas rodoma, kaip tokie rezultatai gali būti tikrinami pagal tikėtinus kelių scenarijus.

Bendrojo duomenų apsaugos reglamento (BDAR) 5 straipsnyje, be kita ko, minimi tikslo apribojimo, duomenų kiekio mažinimo ir saugojimo trukmės apribojimo principai. Analitikai tai nereiškia, kad duomenų visai negalima tvarkyti. Tai reiškia, kad tikslas, apimtis ir trukmė turėtų būti pagrįsti ir apriboti iki būtino masto. Teisinis pagrindas, informavimo prievolės ir, jei reikia, sutikimas turi būti patikrinti konkrečiam naudojimo atvejui.

Sukurkite glaudžią įvykių taksonomiją

Įvykių taksonomija nustato, apie kokius būsenos pokyčius praneša pokalbių botas. Geri įvykiai apibūdina rezultatus, o ne visą dialogą. Jie turėtų būti pakankamai stabilūs laiko palyginimams ir kartu išlikti suprantami. Pradėkite nuo kelių pagrindinių įvykių ir papildykite juos tik tada, kai nuo to priklauso realus sprendimas.

Galimą bazinį rinkinį sudaro:

• conversation_started pradėtam dialogui be žinutės teksto,
• answer_delivered su bendra temos klase ir kalbos kodu,
• source_opened paspaudimui ant pateikto šaltinio,
• fallback_triggered su kontroliuojama klaidos kategorija,
• handoff_offered ir handoff_accepted perdavimui žmogui,
• feedback_submitted su apribota vertinimo skale.

Prie kiekvieno įvykio priskiriami tik tie atributai, kurie reikalingi analizei: laiko langas, kalbos/lokalės kodas, temos kategorija, rezultato būsena, boto versija arba žinių lygis. Laisvasis tekstas, pilni IP adresai, priigos žetonai (access tokens), seanso slapukai ir tiesioginiai kontaktai pagal numatytuosius nustatymus neturėtų patekti į analitikos įvykį. OWASP programų žurnalams taip pat rekomenduoja pašalinti, užmaskuoti ar kitaip apsaugoti seanso identifikatorius, žetonus, jautrius asmens duomenis ir paslaptis.

Įvykių duomenis ir pokalbių turinį tvarkykite atskirai

Agreguoti įvykiai ir ištisi pokalbių protokolai turi skirtingus tikslus. Įvykiai tinka tendencijoms, piltuvėliams (funnels) ir palyginimams. Pokalbių turinys gali padėti atliekant redakcinę klaidų analizę, tačiau jame yra gerokai daugiau konteksto ir kartu daugiau potencialių asmens duomenų. Abiem duomenų tipams neturėtų būti automatiškai taikomos tos pačios prieigos teisės, saugojimo terminai ar eksporto galimybės.

Praktiška architektūra remiasi trimis lygmenimis:

1. Rodikliai: agreguotos reikšmės, tokios kaip išsprendimo rodiklis, atsarginio varianto (fallback) dažnumas ar perdavimo žmogui priėmimo rodiklis.
2. Įvykiai: pseudoniminiai duomenų įrašai su ribotais atributais, skirti laiko ir techninei analizei.
3. Kokybės imtys: atrinkti pokalbiai kontroliuojamai peržiūrai, jei įmanoma, su automatiniu ir rankiniu tiesioginių identifikatorių redagavimu/maskavimu.

Šis atskyrimas palengvina skirtingų ištrynimo terminų ir rolių taikymą. Pavyzdžiui, rinkodaros skydelis (dashboard) neprivalo turėti prieigos prie pokalbių turinio, jei jis analizuoja tik agreguotą tikslų pasiekimą. Kaip profesionaliai apibrėžti rodiklius, aprašoma gide DI pokalbių botų KPI.

Pseudonimizavimas nėra anonimizavimas

Atsitiktinis pokalbio ID gali padėti išvengti tiesioginių identifikatorių analizėje. Tačiau tai nepadaro duomenų automatiškai anoniminiais. Europos duomenų apsaugos valdyba paaiškina, kad pseudonimizuoti duomenys ir toliau lieka asmens duomenimis, jei pasitelkus papildomą informaciją juos galima vėl susieti su asmeniu. Todėl susiejimo galimybė ir atskiras rakto saugojimas yra esminiai aspektai.

Stabilius identifikatorius naudokite tik tada, kai to tikrai reikalauja analizės tikslas. Kasdieniam atsarginių atsakymų (fallback) rodikliui apskaičiuoti paprastai nereikia savaičių savaitėmis atpažįstamo vartotojo ID. Jei reikalingi susiję techniniai įvykiai, gali pakakti trumpalaikio atsitiktinio pokalbio identifikatoriaus. Susiejimo lenteles saugokite atskirai, ribokite prieigą ir dokumentuokite, kada identifikatorius rotuojamas arba ištrinamas.

NIST privatumo sistema („NIST Privacy Framework“) aprašo „atsietą apdorojimą“ („disassociated processing“) kaip būdą apriboti stebimumą, susiejamumą ir identifikavimą. Praktiškai tai gali reikšti atributų pakeitimą kategorijomis, vietinio išankstinio apdorojimo naudojimą arba tik jau agreguotų reikšmių siuntimą į centrinę sistemą.

Tikrinkite kokybę naudodami kontroliuojamas imtis

Kokybinei patikrai ne kiekvienas pokalbis yra vienodai svarbus. Atsitiktinė imtis suteikia neutralesnį kasdienybės vaizdą, o rizika pagrįsta imtis tikslingai apima klaidų atvejus. Derinkite abu požiūrius, užuot skaitę tik ypač blogus ar ypač ilgus pokalbius.

Prasmingas peržiūros planas vienam laikotarpiui gali apimti šias grupes:

• nedidelę atsitiktinę imtį iš sėkmingai atrodančių atsakymų,
• atsarginius atsakymus (fallbacks) ir neatsakytus klausimus,
• pasiūlytus ir priimtus perdavimus žmogui (human handoffs),
• atsakymus apie jautrias ar verslui kritines temas,
• pastebimus nuokrypius tarp kalbų/lokalių, įrenginių ar žinių būsenų.

Prieš suteikdami prieigą apibrėžkite, kurios rolės gali matyti pokalbius, kurie laukai yra maskuojami ir kaip vertintojai dokumentuoja neatitikimus. Laisvi komentarai peržiūros įrankiuose patys gali turėti asmens duomenų; tam taip pat reikia aiškių taisyklių. Peržiūra turėtų padėti imtis konkrečių veiksmų, pavyzdžiui, pataisyti šaltinį, sukurti naują bandomąjį klausimą arba pritaikyti perdavimo žmogui taisyklę.

Planuokite saugojimą pagal duomenų lygmenis

Vienodas ištrynimo terminas visiems analitikos duomenims yra patogus, tačiau retai tikslus. Nustatykite terminus kiekvienam duomenų lygmeniui ir tikslui. Neapdorotas turinys, skirtas trumpalaikei klaidų analizei, gali būti ištrintas gerokai anksčiau nei mėnesinės neasmeninės agregacijos. Su saugumu susijusiems žurnalams savo ruožtu gali būti taikomi kitokie reikalavimai nei produkto analitikai.

Dokumentuokite kiekvienam duomenų rinkiniui:

• tikslą ir atsakingą rolę,
• įtrauktus laukus ir galimus identifikatorius,
• saugojimo vietą ir įgaliotuosius gavėjus,
• terminą, termino pradžios tašką ir ištrynimo mechanizmą,
• atsarginių kopijų, eksporto failų ir išvestinių kopijų tvarkymą.

OWASP atkreipia dėmesį, kad žurnalų duomenys neturėtų būti nei sunaikinami anksčiau nei būtina, nei saugomi ilgiau nei reikia. Konkreti trukmė priklauso nuo teisinių, sutartinių, saugumo ir veiklos reikalavimų. Todėl ištrynimo koncepcija turėtų būti patikrinta techniškai: ar įrašai tikrai pašalinami, ar jie dingsta iš paieškos indeksų ir ar atsižvelgiama į laikinus eksporto failus?

Apsaugokite prieigą, eksportą ir klaidų atvejus

Duomenų taupymas vienas pats neapsaugo analitikos sistemos. Rolės turėtų matyti tik tuos lygmenis, kurių reikia jų užduotims atlikti. Produktų komandoms dažnai reikia agreguotų tendencijų, kokybės komandoms – atrinktų redaguotų pokalbių, o administratoriams – techninių klaidų duomenų. Prieiga prie neapdorotų duomenų turėtų būti registruojama žurnaluose, reguliariai tikrinama ir panaikinama pasikeitus rolei.

Traktuokite analitikos atributus kaip nepatikimą įvestį. Pašalinkite valdymo simbolius, apribokite laukų ilgį ir neleiskite, kad manipuliuojami tekstai iškreiptų žurnalų formatu ar analitika. Eksporto funkcijoms reikia tokių pačių prieigos kontrolės priemonių kaip ir vartotojo sąsajai. CSV ar lentelių eksporto failuose neturi būti papildomų laukų vien todėl, kad jie techniškai prieinami.

Taip pat išbandykite žurnalų vedimo sutrikimus. Pokalbių botas neturėtų nekontroliuojamai rašyti jautrių duomenų į atsarginį žurnalą, jei analitikos sistema nepasiekiama. Nustatykite, kurie minimalūs saugumo įvykiai turi būti išsaugoti, o kurių produkto matavimų laikinai galima atsisakyti.

Lokalizacijų palyginimai be klaidingų išvadų

Daugiakalbė analitika yra naudinga, jei sąvokos ir vardikliai išlieka nuoseklūs. Nelyginkite vien tik absoliučių atvejų skaičiaus. Didesnis perdavimų (handoffs) skaičius gali atsirasti dėl didesnio srauto, kitokių aptarnavimo valandų ar sąmoningai atsargesnio dialogo. Naudokite rodiklius su aiškiai apibrėžtu vardikliu ir dokumentuokite nukreipimo, žinių bazės bei siūlomų kontaktų kanalų skirtumus.

Išsaugokite kalbos/lokalės kodą kaip techninį atributą, o ne kaip prielaidą apie asmens kilmę ar tapatybę. Reguliariai tikrinkite, ar kalbos kelias ir faktinė atsakymo kalba sutampa. Perdavimui žmogui padės straipsnis Žmogiškasis perdavimas (Human Handoff) DI pokalbių bote.

Duomenis taupančios pokalbių botų analitikos kontrolinis sąrašas

• Kiekvienas rodiklis yra susietas su konkrečiu sprendimu ir atsakingu asmeniu.
• Įvykiuose pagal numatytuosius nustatymus nėra žinutės teksto ir tiesioginių identifikatorių.
• Rodikliai, įvykiai ir kokybės imtys yra techniškai ir organizaciškai atskirti.
• Pseudoniminiai identifikatoriai yra trumpalaikiai arba pagrįsti; raktai saugomi atskirai.
• Imtys derina atsitiktinius atvejus su rizika pagrįstomis klaidų grupėmis.
• Rolės, maskavimas ir peržiūros rezultatai yra privalomai apibrėžti.
• Saugojimo ir ištrynimo terminai galioja ir eksporto failams, atsarginėms kopijoms bei paieškos indeksams.
• Lokalizacijų palyginimai naudoja nuoseklius apibrėžimus ir tinkamus vardiklius.
• Sutrikimai, manipuliacijos ir neteisėtas eksportas yra reguliariai išbandomi.

Išsamesnį teisinių pagrindų, informavimo prievolių ir duomenų tvarkymo vertinimą rasite straipsnyje DI pokalbių botas ir BDAR. Konkretaus įgyvendinimo atitiktį leiskite patikrinti atsakingiems duomenų apsaugos ir teisės ekspertams.

Šaltiniai

• Europos Komisija: Bendrojo duomenų apsaugos reglamento principai
• Europos duomenų apsaugos valdyba: Pseudonimizavimo gairės
• NIST privatumo sistema: gairės ir įrankiai
• OWASP Logging Cheat Sheet

Planuojant pokalbių boto analitiką remiantis sprendimais, minimaliais įvykiais ir kontroliuojamomis imtimis, gaunami naudingi kokybės signalai be nereikalingo neapdorotų duomenų archyvo. ChatReact gali būti naudojamas kaip tokio proceso dalis, siūlantis aiškius šaltinius, daugiakalbius dialogus ir apibrėžtus perdavimo žmogui kelių scenarijus.