A/B testi tīmekļa vietņu tērzēšanas botiem: variantu mērīšana, neriskējot ar kvalitāti

Jauns sveiciens palielina sākto tērzēšanu skaits. Īsāka atbilde nodrošina vairāk klikšķu. Cits modelis atrisina vairāk vaicājumu. Šādi apgalvojumi izklausās nepārprotami, taču tīmekļa vietņu tērzēšanas botu gadījumā var ātri kļūt maldinoši. Iespējams, atkārtoti apmeklētāji tika pārvirzīti starp variantiem, izsekošanas kļūda pilnībā uzskaita tikai vienu grupu vai arī šķietami veiksmīgais variants atbild uz vairāk jautājumiem, taču biežāk izdomā detaļas. Tāpēc uzticams A/B tests mēra ne tikai lietojumu, bet arī atbilžu kvalitāti, drošību un faktisko ietekmi uz lietotāju.

Šajā rokasgrāmatā ir parādīta pragmatiska eksperimenta uzbūve tērzēšanas botu izstrādes komandām. Tā sākas ar pārbaudāmu hipotēzi, saglabā stabilu iedalījumu un savieno primāro veiksmes metriku ar fiksētām aizsargmargas metrikām. Mērķis nav pēc iespējas ātrāka uzvarētāja pasludināšana, bet gan lēmums, ko vēlāk var saprast un pamatot.

Sāciet ar mazu, apgāžamu hipotēzi

Eksperimentam vajadzētu izolēt tieši vienu būtisku izmaiņu. Tā vietā, lai teiktu "Mēs testējam labāku tērzēšanas botu", ir nepieciešams šāds apgalvojums: "Sveiciens ar trim konkrētiem tēmu ieteikumiem palielina veiksmīgi atrisināto informācijas pieprasījumu īpatsvaru, nepasliktinot nodošanas kļūdas, atbildes aizturi vai nepamatotus apgalvojumus." Šis formulējums nosauc izmaiņu, paredzamo ieguvumu un robežas.

Microsoft Research uzticamiem tiešsaistes eksperimentiem iesaka skaidru, pārbaudāmu hipotēzi, kā arī iepriekš definētas veiksmes, aizsargmargas un datu kvalitātes metrikas. Ja vienlaikus tiek aktivizētas vairākas lielas izmaiņas, rezultātā paliek neskaidrs, kura daļa nodrošināja ietekmi. Tāpēc sadaliet modeļa maiņu, uzvednes pielāgošanu, jauno logrīka dizainu un nodošanas loģiku atsevišķos soļos.

Izvēlieties pareizo randomizācijas vienību

Tērzēšanas botu gadījumā katra atsevišķa ziņa reti kad ir piemērota vienība. Ja viens un tas pats cilvēks sarunas laikā pārslēgtos starp A un B variantu, sajauktos tonalitāte, atmiņa un atbilžu loģika. Visbiežāk jēgpilnāks ir pseidonimizēts apmeklētāja vai sesijas identifikators. Reiz izvēlētais variants paliek stabils visu definēto eksperimenta laiku. Autentificētus lietotājus var iedalīt pēc konta, ja to pieļauj mērķis, datu aizsardzība un lomu modelis.

Dokumentējiet jauciena algoritmus, eksperimenta ID, variantu īpatsvarus un izslēgšanas noteikumus. Jau pašā sākumā pārbaudiet, vai faktiskā grupu attiecība atbilst plānotajam sadalījumam. Pamanāma izlases proporciju neatbilstība (Sample Ratio Mismatch) var norādīt uz bojātu iedalīšanu, atšķirīgām ielādes kļūdām vai trūkstošiem notikumiem. Šādā gadījumā turpmākie veiksmes rādītāji nav uzticami.

Viena veiksmes metrika, vairākas aizsardzības metrikas

Primārajam rādītājam jābūt cieši saistītam ar lietotāja mērķi. Vienkāršs nosūtīto ziņojumu skaits var nepamatoti apbalvot nevajadzīgi garas sarunas. Informatīvāki ir, piemēram, veiksmīgi atrisināti vaicājumi, apstiprināti atbilstoši pāradresējumi vai pabeigti nākamie soļi. Definējiet "atrisināts" iepriekš: izmantojot skaidru atsauksmi, verificētu mērķa notikumu vai kontrolētu paraugu – nevis paļaujoties tikai uz tērzēšanas bota apgalvojumu.

Līdzās tam katram eksperimentam ir nepieciešamas aizsargmargas (Guardrails), kas nedrīkst pasliktināties:

• Kvalitāte: Pamatoto atbilžu īpatsvars, trāpījumi Golden Set izlasē un drošu rezerves scenāriju īpatsvars zināšanu robos.
• Drošība: Neatļauta datu izpaušana, kļūdainas rīku darbības, uzvedņu injekcijas un piekļuves tiesību pārkāpumu gadījumi.
• Lietotāja pieredze: Pārtraukšanas līmenis, atkārtoti jautājumi, atbildes aizture, kā arī funkcionējoša tastatūras un ekrāna lasītāja lietošana.
• Darbība: Kļūdu līmenis, noildzes, žetonu patēriņš un nodošana cilvēkam (Human-Handoff) bez konteksta zaudēšanas.
• Datu kvalitāte: Trūkstoši notikumi, dubulta uzskaite, nezināmi varianti un neticamas grupu attiecības.

Šīm metrikām jābūt fiksētām neatkarīgi no cerētā rezultāta. Kurš tās izvēlas tikai pēc pozitīvām izmaiņām, var neapzināti meklēt tieši to rādītāju, kas atbilst vēlamajam stāstam. NIST AI riska pārvaldības ietvars definē mērīšanu kā nepārtrauktu procesu: mākslīgā intelekta sistēmas ir jāpārbauda pirms ieviešanas un regulāri darbības laikā, izmantojot dokumentētas, atkārtojamas procedūras.

Pārbaudiet bezsaistē pirms reāllaika testa

A/B tests neaizstāj regresijas testēšanu. Vispirms palaidiet abus variantus pret vienu un to pašu atlasīto tipisko, sarežģīto un ļaunprātīgo pieprasījumu kopu. Tas ietver divdomīgus jautājumus, trūkstošus zināšanu avotus, sensitīvus datus, valodas maiņu un nodošanas scenārijus. Ja kāds variants bloķē drošības noteikumu vai nesasniedz norunāto kvalitātes vērtību, tam nav vietas reāllaika testā.

Tikai pēc tam seko neliela Canary daļa. Novērojiet tehniskās kļūdas un stingrās drošības robežas gandrīz reāllaikā. Parastās rezultātu atšķirības turpretim tiek vāktas līdz iepriekš definētajām testa beigām. Šī nošķiršana ir svarīga: datu noplūde prasa tūlītēju apturēšanu; provizorisks neliels ieguvums klikšķos nav iemesls, lai mēģinājumu priekšlaicīgi pasludinātu par uzvarētāju.

Savlaicīgas ieskatīšanās un mazu segmentu pārvaldība

Kurš katru stundu pārbauda būtiskumu un apstājas pie pirmajiem labvēlīgajiem rādītājiem, palielina nejaušības varbūtību. Pirms starta nosakiet minimālo darbības laiku, nepieciešamo izlasi, mazāko būtisko efektu un novērtēšanas metodi. Microsoft arī norāda, ka atkārtotas starpnozariskās analīzes ir statistiski jāņem vērā.

Segmentējiet tikai pēc iepriekš pamatotām dimensijām, piemēram, valodas, ierīces vai nolūka klases. Globāls uzlabojums var apslēpt būtisku kaitējumu mazā valodas grupā. Vienlaikus desmitiem vēlāk meklētu segmentu var viegli radīt nejaušus mērījumus. Uztveriet izpētes atradumus kā hipotēzi nākamajam testam, nevis kā apstiprinātu efektu.

Atpazīt tērzēšanas botiem specifiskas nobīdes

Tīmekļa vietņu tērzēšanas botiem ir īpatnības, kas sarežģī klasiskos klikšķu testus. Variants var sākt vairāk sarunu, jo izskatās uzmācīgāks. Tas palielina skaitītāju, bet iespējams arī pārtraukšanu skaitu. Garāka atbilde var parādīt vairāk saišu un tādējādi palielināt klikšķu iespējas. Labāka nodošana var samazināt šķietamo automatizācijas līmeni, lai gan lietotāji ātrāk nonāk pie īstā cilvēka.

Tāpēc izmantojiet saucējus, kas pret abām grupām izturas vienādi, un pārbaudiet visu ceļu: parādīšana, sākums, atbilde, rezultāts un iespējamā nodošana. Tāpat fiksējiet konfigurācijas versiju, zināšanu stāvokli un modeļa maršrutu. Ja testa vidū zināšanu bāze mainās tikai vienam variantam, rezultāts vairs nemēra sākotnēji formulēto izmaiņu.

Neziedot datu aizsardzību un piekrišanu eksperimentam

Lielākajai daļai produkta metriku pilns sarunas saturs nav nepieciešams. Pseidonimizēti eksperimenta un sesijas ID, notikumu kategorijas, aiztures un kontrolētas kvalitātes etiķetes bieži ir pilnīgi pietiekamas. Nesaglabājiet brīvi ievadītus kontaktlatus analītikas notikumos. Definējiet eksperimenta datu glabāšanu, piekļuves tiesības un dzēšanu tāpat kā parastajiem tērzēšanas datiem.

Ja kāds variants apstrādā jaunus personas datus vai maina izmantošanas mērķi, tas nav vienkāršs saskarnes tests. Tādā gadījumā juridiskais pamats, lietotāju informēšana un, ja nepieciešams, piekrišana ir jāatrisina pirms starta. Funkciju karogs (Feature Flag) neatceļ šos pienākumus.

Iepriekš aprakstiet lēmumu par ieviešanu

Pirms eksperimenta pierakstiet, ko nozīmē "ieviest", "iterēt" un "apturēt". Piemēram: variants tiek pārņemts tikai tad, ja risinājuma līmenis sasniedz noteikto būtisko efektu, netiek pārkāpta neviena drošības aizsargmarga un kvalitātes, kā arī aiztures vērtības paliek savās robežās. Pretrunīgu metriku gadījumā lēmumu pieņem nozīmētais atbildīgais, nevis skaļākais momentuzņēmums informācijas panelī.

Pēc tam arhivējiet hipotēzi, variantus, laika posmu, iedalījumu, datu kvalitātes pārbaudes, rezultātus un lēmumu. Tādējādi tiek izveidots eksperimentu reģistrs, kas novērš dubultus mēģinājumus un padara vēlākas izmaiņas saprotamas. Negatīvs rezultāts ir vērtīgs: tas novērš ieviešanu, kas izskatījās pārliecinoša tikai intuitīvi.

Praktisks kontrolsaraksts

1. Formulējiet vienu, apgāžamu hipotēzi ar ietekmi uz lietotāju.
2. Nosakiet randomizācijas vienību un stabilu piesaisti.
3. Iepriekš definējiet primāro metriku, aizsargmargas, datu kvalitāti un apturēšanas noteikumus.
4. Pārbaudiet abus variantus bezsaistē ar Golden Set un drošības testiem.
5. Sāciet ar nelielu trafiku un uzreiz uzraugiet kritiskos riskus.
6. Nesaīsiniet testa ilgumu un izlasi pēc agrīna izrāviena.
7. Dokumentējiet rezultātu, ieskaitot nenoteiktību, segmentus un pretmetrikas.
8. Veiciet ieviešanu pakāpeniski un turpiniet novērot tās pašas aizsargmargas.

Secinājums: Neuzvar skaļākā metrika

Labs tērzēšanas bota tests savieno cēloņsakarību mērīšanu ar atbildību par produktu. Stabila piešķiršana, īsta veiksmes metrika, neapspriežamas aizsargmargas un iepriekš definēts lēmuma pieņemšanas ceļš pārvērš variantu salīdzināšanu par uzticamu mācīšanās instrumentu. Tādējādi komanda uzlabo ne tikai klikšķus vai tērzēšanas sākumus, bet arī iespēju, ka cilvēki saņem uzticamas atbildes un drošu nākamo soli.

Sāciet ar izmaiņu, ko var paskaidrot vienā teikumā. Ja veiksmes un apturēšanas kritēriji ir tikpat skaidri, eksperiments ir gatavs bezsaistes testam – vēl ne automātiski pilnai ieviešanai.

Avoti

• Microsoft Research: Patterns of Trustworthy Experimentation – Pre-Experiment
• Microsoft Research: Patterns of Trustworthy Experimentation – During Experiment
• Microsoft Research: Common Metric Interpretation Pitfalls
• NIST AI RMF Core: Measure