DI pokalbių boto atsiliepimų ciklas: grįžtamojo ryšio pavertimas geresniais atsakymais

Svetainės pokalbių botas netampa geresnis vien todėl, kad veda daug pokalbių. Be sutvarkyto grįžtamojo ryšio kanalo pasikartojantys nesusipratimai, trūkstami šaltiniai ir neaiškūs perdavimai lieka nematomi. Atsiliepimų ciklas pavienius atsiliepimus paverčia patikrinamais patobulinimais: renka signalus, rūšiuoja juos pagal riziką bei dažnumą, paverčia testavimo atvejais ir galiausiai patikrina, ar pakeitimas iš tiesų padeda. Tai ypač svarbu, kai pokalbių botas remiasi žinių baze, paieška ir automatizuotais atsakymais.

Kodėl atsiliepimai yra daugiau nei nykštys aukštyn arba žemyn

Paprastas įvertinimas gali būti naudingas signalas, tačiau retai paaiškina priežastį. Neigiamas įvertinimas gali reikšti, kad atsakymas faktiškai neteisingus, per ilgas, nelokalizuotas, neišsamus arba visiškai netinkamas situacijai. Ir priešingai – draugiškai skambantis atsakymas gali būti įvertintas teigiamai, nors neturėjo patikimo šaltinio. Todėl svetainių komandos atsiliepimus visada turėtų susieti su pokalbio kontekstu, naudotu šaltiniu, klausimo tipu ir rezultatu. Tik taip galima atskirti, ką reikia patobulinti: žinių bazę, paiešką, formuluotę ar perdavimą žmogui.

NIST AI Risk Management Framework aprašo galutinių vartotojų ir paveiktų asmenų atsiliepimų mechanizmus kaip vertinimo metrikų dalį. Svetainės pokalbių botui tai nereiškia, kad reikia neribotai saugoti kiekvieną pokalbį. Tai reiškia duomenis taupantį būdą pranešti apie problemas, užduoti patikslinamuosius klausimus arba užginčyti atsakymą. Atsiliepimams reikalinga aiški atsakomybė – jie neturi dingti bendroje pašto dėžutėje be triažo.

Tinkamų atsiliepimų signalų apibrėžimas

Pradėkite nuo kelių aiškių signalų. Pavyzdžiai: atsakymas buvo naudingas arba nenaudingas, trūksta šaltinio, atsakymas susijęs su netinkamu produktu, informacija pasenusi, kalba netinka, reikalingas kontaktas su žmogumi arba saugumo susirūpinimas. Laisvas tekstas gali būti vertingas, tačiau turėtų likti neprivalomas ir jame neturėtų būti prašoma duomenų, kurie nėra būtini tobulinimui. Papildykite techniniais signalais, tokiais kaip „rezultatų nėra“ atvejai, pakartotiniai klausimo performulavimai, pokalbio nutraukimai po atsakymo ir sėkmingi perdavimai.

Signalas nėra nuosprendis. Vienas spustelėjimas neturi sukelti automatinio žinių bazės pakeitimo. Tik triažas susieja signalą su įrodymais. Patikrinkite, koks klausimas buvo užduotas, kokius šaltinius pokalbių botas naudojo, ar teisingai veikė teisių ir metaduomenų filtrai ir ar žmogus pateiktų tokį patį atsakymą. Ypač kritinėms temoms galioja griežtesnės taisyklės: čia sričių atsakingi asmenys turi nuspręsti, ar pakeisti šaltinį, papildyti pastabą, ar padaryti perdavimą privalomu.

Triažas: skuba svarbiau už garsumą

Geras triažas atsiliepimus rūšiuoja ne tik pagal kiekį. Retai pasitaikanti problema gali būti skubi, jei ji susijusi su saugumu, duomenų apsauga, mokėjimais ar teisiškai svarbia informacija. Dažni, bet nekenksmingi supratimo sunkumai vis tiek gali sukelti daug pagalbos darbo sąnaudų. Dirbkite su nedidele matrica, sudaryta iš poveikio, pasiekiamumo, įrodymų ir pakartojamumo. Dokumentuokite sprendimą: kas nutiko, koks šaltinis dalyvavo, koks testavimo atvejis iš to kyla ir kas perima tolesnius veiksmus?

Venkite tokios kategorijos kaip „DI suklydo“ be tolesnio patikrinimo. Konkrečios klaidų klasės padeda geriau: trūkstamas šaltinis, neteisingas šaltinis, netinkamas kontekstas, pasenęs turinys, haliucinacija, kalbų maišymas, nepasiekiamas perdavimas arba neaiškus klausimas. Šias klases galima palyginti laike. Jos taip pat parodo, ar tariama modelio problema iš tikrųjų yra turinio ar integracijos problema.

Nuo pranešimo iki regresinio testo

Kiekvienas patvirtintas atsiliepimas turėtų išlikti kaip kompaktiškas testavimo atvejis. Užsirašykite klausimą, leidžiamus ir neleidžiamus šaltinius, tikėtinus esminius teiginius, pageidaujamą reakciją į neapibrėžtumą ir, jei reikia, tinkamą perdavimą. Pašalinkite arba anonimizuokite asmens duomenis. Generatyvinėms programoms Microsoft rekomenduoja vertinimus su tinkamais duomenimis, metrikomis ir analize prieš bei po įdiegimo. Regresinis testas susieja šią idėją su kasdienine svetainės komandos veikla: kas kartą buvo patikrinta ir išspręsta, neturi tyliai vėl sugesti atlikus kitą šaltinio ar užklausos (prompt) pakeitimą.

Testavimo atvejai neturi būti dirbtinai sudėtingi. Pradėkite nuo tikrų, išvalytų klausimų iš klientų aptarnavimo ir pardavimų: kainos klausimas be rinkos nurodymo, produkto pavadinimas su rašybos klaida, klausimas apie pasenusią instrukciją, neaiškus grąžinimo prašymas arba prašymas sujungti su žmogumi. Papildykite sąmoningais „rezultatų nėra“ atvejais. Pokalbių botas išlaiko testą ne tik tada, kai atsako, bet ir tada, kai aiškiai įvardija neapibrėžtumą ir siūlo saugų kitą veiksmą.

Žinių bazės, paieškos ir atsakymo tobulinimas atskirai

Atsiliepimų ciklas apsaugo nuo karštligišku masinių pakeitimų. Jei trūksta tinkamo šaltinio, pirmiausia papildykite arba atnaujinkite žinių bazę. Jei šaltinis yra, bet nerastas, patikrinkite skaidymą į dalis (chunking), pavadinimus, metaduomenis, kalbą ir paiešką (retrieval). Jei kontekstas teisingas, bet atsakymas klaidina, patikrinkite atsakymo instrukciją ir citavimo taisykles. Jei pokalbių botas nukreipia toliau per ilgai arba per anksti, patikrinkite perdavimo logiką. Šis atskyrimas padaro pakeitimo poveikį matuojamu ir neleidžia užklausai uždengti klaidingo šaltinio.

Suteikite pakeitimams atsekamą būseną: pasiūlyta, patikrinta, paskelbta, testuojama ir stebima. Trumpa šaltinių istorija padeda, jei taisyklė vėliau vėl pasikeičia. Ji taip pat svarbi daugiakalbėms svetainėms: ištaisytas vokiškas straipsnis nepakeičia patikrinimo, ar atitinkama kalbinė versija vaizduoja tą patį faktą ir tą patį šaltinį.

Praktiškas eigos planas kiekvienai savaitei

1. Rinkti: Taupant duomenis fiksuoti atsiliepimus, „rezultatų nėra“ atvejus ir perdavimus.
2. Valyti: Apjungti pasikartojančius pranešimus ir pašalinti nereikalingus asmens duomenis.
3. Atlikti triažą: Įvertinti riziką, pasiekiamumą ir įrodymus.
4. Atkurti: Parašyti aiškų testavimo atvejį su leidžiamais šaltiniais ir tikėtina reakcija.
5. Keisti: Pašalinti tiksliai vieną priežastį – šaltinį, metaduomenis, paiešką arba atsakymo taisyklę.
6. Įvertinti: Iš naujo paleisti naująjį ir esamus testus.
7. Stebėti: Po išleidimo patikrinti, ar klaidingi modeliai ir perdavimai mažėja.

Pavyzdys: pasikartojantis klausimas dėl sutarties nutraukimo

Keli lankytojai pažymi atsakymus dėl sutarties nutraukimo kaip nenaudingus. Triažas parodo: pokalbių botas cituoja senus DUK, nors egzistuoja aktualus puslapis. Klaida pirmiausia nėra kalbinė. Komanda pažymi senąjį šaltinį kaip nebegaliojantį, prideda galiojimo datą, patikrina paieškos filtrą ir sukuria testavimo atvejį. Tikėtinas atsakymas nurodo aktualų puslapį ir, jei nėra sutarties tipo, prašo patikslinti, užuot išgalvojęs terminą.

Po pakeitimo vieno sėkmingo pokalbio neužtenka kaip įrodymo. Testavimo atvejis turi veikti su variantais, tokiais kaip rašybos klaidos, keli sutarčių tipai ir klausimas be pakankamo konteksto. Gamybinėje stebėsenoje turėtų matytis, ar senasis šaltinis toliau pasirodo ir ar perdavimų skaičius šioje klausimų klasėje mažėja, ar didėja. Jei didėja, tai taip pat gali reikšti, kad naujasis atsakymas suformuluotas per atsargiai. Tuomet atsiliepimai veda į naują, pagrįstą iteraciją.

Metrikos, padedančios priimti sprendimus

Matuokite ne tik bendrą naudingų atsakymų dalį. Prasmingos metrikos yra, pavyzdžiui, šaltinių padengimas, pagrįstų atsakymų dalis, „rezultatų nėra“ rodiklis, pasikartojimų rodiklis, perdavimo sėkmė, patvirtintų klaidų dalis ir laikas iki triažo. Kiekvienam signalui turėtų būti aišku, kaip jis fiksuojamas ir kokia riba sukelia tyrimą. Microsoft pažymi, kad vertinimai gali matuoti našumą, kokybę ir saugumą prieš bei po įdiegimo. Metrika nėra savitikslis dalykas, o instrumentas, padedantis pamatyti patobulinimus ir regresijas.

Atsargiai lyginkite laiko laikotarpius. Sezoniškumas, kampanijos, nauji produktai ar kontakto pasiūlymo pakeitimai daro įtaką klausimams ir perdavimams. Todėl dokumentuokite išleidimus, šaltinių pakeitimus ir testo rinkinių versijas. Kitaip tariant, tariamai geresnis rodiklis gali būti susijęs tik su tuo, kad sudėtingi klausimai nebėra fiksuojami. Kokybinės specialistų imtys papildo skaičius, ypač retų, bet didelių pasekmių turinčių klaidų atvejais.

Duomenų apsauga ir žmogaus kontrolė

Atsiliepimų duomenys turėtų būti tvarkomi griežtai pagal paskirtį ir taupiai. Neprašykite asmens duomenų, jei pakanka kategorijos ir trumpo komentaro. Prieš pradėdami apibrėžkite saugojimą, prieigą ir ištrynimą. Jei atsiliepimas susijęs su individualiu sprendimu, jautriais duomenimis arba galimu saugumo pažeidimu, jam reikalingas aiškus žmogiškasis procesas. Svetainės pokalbių botas gali užfiksuoti ir perduoti pranešimą, bet neturi daryti nepatikrintų įsipareigojimų.

Žmogaus atliekama patikra yra vertinga ir sėkmingos automatizacijos atveju. Specialistai atpažįsta neteisingus prioritetus, dvispalvius terminus arba spragas šaltiniuose, kuriuos gryna metrika praleidžia. Atsiliepimų ciklo tikslas nėra nuimti atsakomybę nuo žmonių, o nukreipti jų ribotą laiką į atvejus, kuriems reikalingas įvertinimas.

Tipinių klaidų vengimas

• Atsiliepimų rinkimas be šaltinio, konteksto ar atsakomybės.
• Atskirų neigiamų spustelėjimų automatinis vertimas turinio pakeitimais.
• Tik atsakymo formuluotės keitimas, nors žinių šaltinis yra pasenęs.
• „Rezultatų nėra“ atvejų slėpimas kaip gėdingų, užuot tvarkius juos kaip turinio darbų sąrašą (backlog).
• Daugiakalbių variantų nepatikrinimas iš naujo po šaltinio pakeitimo.
• Sėkmės teigimas be regresinio testo ar gamybinės stebėsenos.

Kontrolinis sąrašas pradžiai

• Pateikti aiškias atsiliepimų kategorijas ir pasiekiamą perdavimą.
• Su sričių atsakingais asmenimis nustatyti rizikos ir triažo taisykles.
• Patvirtintus atvejus dokumentuoti kaip duomenis taupančius regresinius testus.
• Šaltinių, paieškos ir atsakymų pakeitimus matuoti atskirai.
• Reguliariai tikrinti metrikas, testo rinkinį ir versijos būseną.
• Atskleisti neapibrėžtumą, jei netinka joks patvirtintas šaltinis.

Išvada

Atsiliepimų ciklas svetainės pokalbių botus daro geresnius ne dėl didesnio duomenų kiekio, o dėl geresnių sprendimų. Jis susieja vartotojų pastabas su šaltiniais, triažu, testais ir kontroliuojamais pakeitimais. Taip pasikartojančios problemos tampa matomos, kritiniams atvejams suteikiamas prioritetas, o patobulinimai išlieka įrodomi. Tie, kurie į atsiliepimus, vertinimą ir žmogaus patikrą žiūri kaip į bendrą procesą, sustiprina atsakymų kokybę, nepavardami pokalbių boto juodąja dėže.

Šaltiniai

• NIST AI RMF Core
• Microsoft Learn: Evaluating generative AI applications
• Microsoft Learn: Run evaluations
• ChatReact: Golden Set ir atsakymų kokybė
• ChatReact: Žinių bazės palaikymas aktualia
• ChatReact: Perdavimas žmogui (Human Handoff)