Kuidas kasutame Markovi ahelaid otsuste hindamisel ja vigade leidmisel. Python scriptiga

Meie jaoks on oluline mõista, mis toimub meie õpilastega õppe ajal ja kuidas need hetked mõjutavad tulemust, seetõttu kaardistame kliendi teekonna — klientide kogemuste kaardi. Õppeprotsess ei ole pidev ja terviklik, see on kimp omavahel seotud sündmustest ja õpilase tegevustest, mis võivad oluliselt erineda erinevate õpilaste seas. Siin on ta läbinud tunni: mida ta edasi teeb? Kas ta läheb kodutööle? Avab mobiilirakenduse? Muudab kursust, palub vahetada õpetajat? Sisestub kohe järgmistesse tundidesse? Või lahkub lihtsalt pettunult? Kas selle kaardi analüüsimise kaudu on võimalik tuvastada mustreid, mis viivad kursuse edukale lõpetamisele või vastupidi, „lahkumisele“?

Tavaliselt kasutatakse CJMi koostamiseks spetsialiseeritud, üsna kalliseid sulgeda koodiga tööriistu. Kuid me soovisime välja mõelda midagi lihtsat, mis vajaks minimaalset vaeva ja oleks võimalikult avatud lähtekoodiga. Nii tekkis idee kasutada Markovi ahelaid — ja meil õnnestus. Oleme koostanud kaardi, tõlgendanud õpilaste käitumise andmeid graafina, näinud täiesti mitteilmseid vastuseid globaalsele äri küsimusele ja isegi leidnud sügavale peidetud vigu. Kõike seda tegime avatud lähtekoodiga Python-skriptide abil. Selles artiklis räägin kahest juhtumist, mis andsid need mitteilmseid tulemusi ja jagan skripti kõigiga, kes soovivad.

Nii näitavad Markovi ahelad ülemineku tõenäosust sündmuste vahel. Siin on primitiivne näide Vikipeediast:

Siin on „E“ ja „A“ — sündmused, nooled — üleminekud nende vahel (sealhulgas üleminek sündmusest endasse), ja noolte kaalud — ülemineku tõenäosus („kaalutud suunatud graaf“).

Mida kasutati

Ahel õpetati Python'i standardse funktsionaalsusega, millele söödati õpilaste aktiivsuse logisid. Graaf saadi saadud maatriksist NetworkX teeki kasutades.

Logi näeb välja järgmine:

See on csv-fail, mis sisaldab kolme veergu: õpilase ID, sündmuse nimetus, aeg, millal see sündmus leidis aset. Need kolm välja on piisavad, et jälgida kliendi liikumisi, koostada kaart ja lõpuks saada Markovi ahel.

Raamatukogu tagastab ehitatud graafikuid .dot või .gexf formaadis. Esimeste visualiseerimiseks võib kasutada tasuta Graphviz paketti (tööriist gvedit), me töötasime .gexf ja Gephi'ga, mis on samuti tasuta.

Edasi tahan tuua kaks näidet Markovi ahelate kasutamisest, mis on võimaldanud meil uut moodi vaadata meie sihte, õppeprotsesse ja kogu Skyengi ökosüsteemi. Ja ka veidi vigu parandada.

Esimene juhtum: mobiilirakendus

Alguses uurisime õpilase teekonda meie kõige populaarsemas tootes — General kursusel. Sel hetkel töötasin Skyengi lasteosakonnas ja soovisime näha, kui efektiivselt mobiilirakendus meie laste sihtrühmas töötab.

Võttes logid ja viies need läbi skripti, sain midagi sellist:

Sissejuhatus sõlme — Start General, ja all kolm väljundsõlme: õpilane «magas», vahetas kurssi, lõpetas kursuse.

• Fell asleep, «Magas» — see tähendab, et ta ei osale enam tundides, tõenäoliselt on ta loovutanud. Me nimetame seda seisundit optimistlikult «magama», kuna teoorias on tal võimalus jätkata õpinguid. See on meie jaoks halvim tulemus.
• Dropped general, Vahetas kurssi — vahetas Generalilt millegi teise peale ja kadus meie Markovi ahelast.
• Finished course, Lõpetas kursuse — ideaalne seisund, inimene on läbinud 80% tundidest (kõik tunnid ei ole kohustuslikud).

Sattumine sõlme successful class tähistab õppetunni edukat läbimist meie platvormil koos õpetajaga. See fikseerib edusamme kursusel ja lähenemise soovitud tulemusele — «Lõpetas kursuse». Meile on tähtis, et õpilased külastaksid seda nii palju kui võimalik.

Kuna kahtlesime mobiilirakenduse täpsetes kvantitatiivsetes järeldustes (sõlm app session), ehitasime iga lõpp-sõlme jaoks eraldi ahelad ja seejärel võrdlesime paarikaupa servade kaalu:

• app session'ist tagasi sinna;
• app session'ist successful class'i;
• successful class'ist app session'i.

Vasakul — kursuse lõpetanud õpilased, paremal — «magajad»

Need kolm servi näitavad seost õpilase edukuse ja mobiilirakenduse kasutamise vahel. Ootasime, et kursuse lõpetanutel on mobiilirakendusega tugevam side kui «magajatel». Kuid reaalsuses saime hoopis vastupidiseid tulemusi:

• veendusime, et erinevad kasutajagruppide suhtlemised mobiilirakendusega on erinevad;
• Edukaorid kasutavad mobiilirakendust vähem intensiivselt;
• Uinuvad õpilased kasutavad mobiilirakendust aktiivsemalt.

See tähendab, et "uinuvad" õpilased hakkavad üha rohkem aega mobiilirakenduses veetma ja lõpuks jäävad nad sinna igaveseks.

Esmalt olime üllatunud, kuid pärast mõtlema hakates saime aru, et see on täiesti loogiline efekt. Aegade jooksul õppisin ma prantsuse keelt iseseisvalt, kasutades kahte tööriista: mobiilirakendust ja grammatika loenguid YouTube'is. Alguses jagasin aega nende vahel 50/50. Kuid rakendus oli lõbusam, seal oli mängude elemendid, kõik oli lihtne, kiire ja arusaadav, samas pidin loengutes süvenema, midagi üles kirjutama, harjutama märkmikus. Aja jooksul veetsin ma smartphone'is aina rohkem aega, kuni selle osa kasvas 100%-ni: kui veedad selles kolm tundi, tekib vale tunne tehtud tööst, mistõttu pole mingit soovi minna ja midagi kuulata.

Aga kuidas nii? Me ju tsükliliselt lõime mobiilirakenduse, integreerisime sellesse Ebbinghausi kõverat,mängustasime selle, muutsime selle atraktiivseks, et inimesed veedaksid seal rohkem aega, aga selgub, et see ainult segab neid? Tegelikult on põhjus see, et mobiilirakenduse tiim tegi oma ülesandeid liiga hästi, mille tulemuseks oli see, et see muutus suurepäraseks iseseisvaks tooteks ja hakkas meie ökosüsteemist välja kukkuma.

Uurimise tulemusena jõuti arusaamisele, et mobiilirakendust tuleb kuidagi muuta, et see ei segaks põhikursusest. Ja nii laste kui ka täiskasvanute puhul. Praegu on see töö käimas.

Teine juhtum: onboardingu vead.

Onboarding on uus õpilase registreerimise protseduur, mis ei ole kohustuslik, kuid aitab vältida tulevikus võimalikke tehnilisi probleeme. Põhistsenaarium hõlmab seda, et inimene registreerib end maandumislehel, saab juurdepääsu isiklikule kontole, temaga võetakse ühendust ning korraldatakse sissejuhatav tund. Samas märkame sissejuhatava tunni ajal suurt arvu tehnilisi raskusi: vale brauseri versioon, mikrofoni või heli probleemid, õpetaja ei saa kohe lahendust soovitada ja see kõik on eriti keeruline, kui tegu on lastega. Seetõttu oleme arendanud isiklikus kabinetis täiendava rakenduse, kus saab läbi viia neli lihtsat sammu: kontrollida brauserit, kaamerat, mikrofoni ja kinnitada, et vanemad on sissejuhatava tunni ajal läheduses (sest nemad maksavad laste hariduse eest).

Need paar onboarding'i lehte näitasid järgmist funnelskeemi:

1: algblokk kolme veidi erineva (olenevalt kliendist) sisselogimise vormiga.
2: nõusoleku kinnitamise märkeruut täiendava onboarding'i protseduuri jaoks.
2.1-2.3: vanema kohaloleku kontroll, Chrome'i versiooni ja heli kontroll.
3: lõppblokk.

See näeb väga loogiline välja: esimestel kahel sammul lahkub enamik külastajatest, mõistes, et siia tuleb midagi täita, kontrollida ja aega pole. Kui klient jõuab kolmandasse sammu, siis on ta juba peaaegu kindel, et ta jõuab lõpuni. Funnelskeemil ei ole ühtegi põhjust midagi kahtlustada.

Otsustasime siiski analüüsida meie onboarding'i mitte klassikalise ühemõõtmelise funnelskeemiga, vaid Markovi ahela abil. Lisame veidi rohkem sündmusi, käivitame skripti ja saame sellise tulemuse:

Selles segaduses on ühemõtteliselt aru saada vaid ühte: midagi on valesti läinud. Onboarding'i protsess on lineaarne, see on disainis paika pandud, selles ei tohiks olla sellist keerulist seostulemuste võrgustikku. Siin on kohe näha, et kasutajat visatakse sammude vahel, mille vahel ei tohiks üldse üleminekuid olla.

Selle kummalise pildi põhjused võivad olla kaks:

• vead on sattunud logide andmebaasi;
• vead on olemas ka tootes — onboarding'is.

Esimene põhjus on tõenäoliselt olemas, kuid selle kontrollimine on piisavalt tööintensiivne ja logide parandamine ei paranda kindlasti kasutajakogemust. Teise puhul, kui see on olemas, oleks pidanud kiiresti midagi ette võtma. Seetõttu asusime vaatama sõlmi, tuvastama servad, mida ei peaks olema, otsima nende tekkimise põhjuseid. Nägime, et mõned kasutajad jäid ringi käima, teised kukkusid keskmisest algusesse, kolmandad ei saanud üldse esimestest kahest sammust välja. Edastasime andmed QA-le — ja jah, välja tuli, et onboardimisel oli piisavalt vigu: see oli selline kõrvaltoode, veidi kätetööga tehtud, seda ei testitud piisavalt sügavalt, kuna ei oodatud mingeid probleeme. Praeguseks on kogu registreerimisprotsess muutunud.

See lugu näitas meile ootamatut Markovi ahelate rakendust QA valdkonnas.

Proovige ise!

Ma olen üles laadinud oma Markovi ahelate õpetamiseks mõeldud Python-skripti avalikuks — kasutage mureta. Dokumentatsioon on GitHubis, küsimusi võib esitada siin, püüan kõigile vastata.

Ja siin on kasulikud lingid: NetworkX teek, Graphviz visuaaliseerija. Siin on Habril artikkel Markovi ahelate kohta. Artiklis olevad graafid on loodud kasutades Gephi.

Allikas: habr.com