Si i përdorim zinxhirët Markov në vlerësimin e vendimeve dhe kërkimin e gabimeve. Me një skript në Python

Na është e rëndësishme të kuptojmë se çfarë ndodh me studentët tanë gjatë mësimit dhe si këto ngjarje ndikojnë në rezultatet, prandaj ne krijojmë Hartën e Udhëtimit të Klientit — hartën e përvojës së klientit. Procesi i mësimit nuk është një gjë e vazhdueshme dhe e njëtrajtshme; është një varg ngjarjesh dhe veprimesh të ndërlidhura të studentëve, dhe këto veprime mund të dallohen shumë nga njëri student në tjetrin. Ky student ka përfunduar një mësim: çfarë do të bëjë më pas? Do të shkojë për në detyrën e shtëpisë? Do të hapë aplikacionin mobil? Do të ndryshojë kursin, do të kërkojë të ndryshojë mësuesin? Do të hyjë menjëherë në mësimin tjetër? Apo thjesht do të largohet i zhgënjyer? A është e mundur që, duke analizuar këtë hartë, të identifikojmë tendenca që çojnë në përfundimin e suksesshëm të kursit ose, nga ana tjetër, që çojnë në "largimin" e studentëve?

Zakonisht, për ndërtimin e CJM përdoren mjete të specializuara, mjaft të shtrenjta me kod të mbyllur. Por ne doja të mendonim për diçka të thjeshtë, që kërkonte përpjekje minimale dhe, sa më shumë të ishte e mundur, me kod të hapur. Kështu lindi ideja për të përdorur zinxhirët Markov — dhe ia dolëm. Ndërtuam një hartë, interpretuam të dhënat mbi sjelljen e studentëve në formën e një grafi, panë përgjigje të paqarta për pyetje globale të biznesit dhe madje gjetëm bugs të thella të fshehura. Të gjitha këto i bëmë me ndihmën e zgjidhjeve me kod të hapur Python. Në këtë artikull do të tregoj për dy raste me ato rezultate pikërisht të paqarta dhe do të ndaj skenarin me të gjithë ata që janë të interesuar.

Pra, zinxhirët Markov tregojnë probabilitetin e kalimeve ndërmjet ngjarjeve. Këtu është një shembull primitv nga Wikipedia:

Këtu "E" dhe "A" janë ngjarje, shigjetat janë kalime midis tyre (përfshirë kalimin nga një ngjarje në vetveten), dhe pesha e shigjetave është probabiliteti i kalimit ("graf i orientuar me pesha").

Çfarë përdorëm

Zgjidhja u trajnua me funksionalitetin standard të Python, i cili përfshinte logjet e aktivitetit të studentëve. Grafiku mbi matricën e marrë u ndërtua me bibliotekën NetworkX.

Logu duket kështu:

Ky është një skedar csv që përmban një tabelë me tre kolona: id e studentit, emri i ngjarjes, koha kur ndodhi ajo. Këto tri fusha janë të mjaftueshme për të ndjekur lëvizjet e klientit, për të ndërtuar një hartë dhe përfundimisht për të marrë një zinxhir Markov.

Biblioteka kthen grafet e ndërtuara në formatin .dot ose .gexf. Për vizualizimin e të parëve, mund të përdorni paketën falas Graphviz (instrumentin gvedit); ne kemi punuar me .gexf dhe Gephi, gjithashtu falas.

Më pas do të sjell dy shembuj të përdorimit të zinxhirëve Markov, të cilat na lejuan të shohim qëllimet tona, proceset mësimore dhe vetë ekosistemin Skyeng nga një këndvështrim të ri. Po ashtu, të korrigjojmë disa probleme.

Shembulli i parë: aplikacioni mobil

Për fillim, ne hulumtuam rrugën e studentëve për produktin tonë më të popullarizuar — kursin General. Në atë kohë, unë punoja në departamentin e fëmijëve në Skyeng dhe ne donim të shihnim sa efikas është aplikacioni mobil me audiencën tonë të fëmijëve.

Pasë marrë logët dhe i kalova ato përmes skriptit, mora diçka të tillë:

Noda fillestare — Start General, dhe poshtë tre nodat dalëse: studenti «ka fjetur», ndryshoi kursin, përfundoi kursin.

• Ka fjetur, «Ka fjetur» — do të thotë se nuk po vazhdon mësimet, shumë mundësisht, ai është larguar. Ne e quajmë optimistisht këtë gjendje «ka fjetur», pasi teorikisht ka ende mundësinë të vazhdojë mësimin. Rezultati më i keq për ne.
• Ndryshoi kursin, ka kaluar nga General në diçka tjetër dhe humbi për rrjetin tonë Markov.
• Përfundoi kursin, gjendja ideale, personi kaloi 80% të mësimeve (jo të gjitha mësimet janë të detyrueshme).

Pjesëmarrja në nodën successful class do të thotë kalim të suksesshëm të mësimit në platformën tonë me mësuesin. Ajo regjistron avancimin në kurs dhe afërsinë me rezultatin e dëshiruar — «Përfundoi kursin». Na rëndësishme që studentët ta vizitojnë sa më shumë.

Për të marrë konkluzione më të sakta sasiore për aplikacionin mobil (noda app session), ndërtuam zinxhirë të veçantë për secilën nga nodat përfundimtare dhe më pas krahasuam pesha të brendshme:

• nga app session mbrapsht në të njëjtin;
• nga app session në successful class;
• nga successful class në app session.

Në majë — studentët që përfunduan kursin, në të djathtë — ata që "flinin"

Këto tri grafa tregojnë lidhjen mes suksesit të studentit dhe përdorimit të aplikacionit mobil. Ne prisnim të shihnim se studentët që përfunduan kursin do kishin një lidhje më të fortë me aplikacionin se ata që "flinin". Megjithatë, përfundimisht morëm rezultate të kundërta:

• ne konstatuam se grupe të ndryshme përdoruesish ndërveprojnë ndryshe me aplikacionin mobil;
• studentët e suksesshëm përdorin më pak intensitet aplikacionin mobil;
• studentët që flinin përdorin më aktivisht aplikacionin mobil.

Kjo do të thotë se studentët "f sleeping" fillojnë të kalojnë gjithnjë e më shumë kohë në aplikacionin mobil dhe në fund mbeten atje përgjithmonë.

Së pari u habitëm, por pas disa mendimeve, e kuptuam se ishte një efekt krejtësisht i natyrshëm. Njëherë, kam mësuar frëngjishten duke përdorur dy mjete: një aplikacion celular dhe ligje për gramatikën në YouTube. Në fillim e ndaja kohën time midis tyre me një raport 50 me 50. Por aplikacioni është më argëtues, ka gamifikim, gjithçka është e thjeshtë, e shpejtë dhe e kuptueshme, ndërsa në ligjet duhet të përqendrohem, të shkruaj diçka dhe të praktikoj në ditar. Gradualisht, fillova të kaloj më shumë kohë në smartphone, derisa pjesa e tij arriti në 100%: nëse kalon tre orë aty, krijohet një ndjesi e gabuar e përfundimit të punës, për shkakun e të cilës nuk kam asnjë dëshirë të shkoj dhe të dëgjoj diçka.

Por si është e mundur? Sepse ne e krijuam veçanërisht aplikacionin celular, e integruam me kurbën e Ebbinghausit, e gamifikuam, e bëmë tërheqëse, që njerëzit të kalonin kohë në të, dhe rezulton se vetëm i shpërqendron? Në të vërtetë, arsyeja është se ekipi i aplikacionit celular e ka bërë kaq mirë punën e tij, saqë është bëre një produkt i shkëlqyer i pavarur dhe ka filluar të dalë jashtë ekosistemit tonë.

Si rezultat i studimit, u arrit në përfundimin se aplikacioni mobil duhet të ndryshohet ndonjëherë, për të mos e tërhequr shumë nga kursi kryesor i mësimit. Kjo vlen për të dyja, fëmijët dhe të rriturit. Aktualisht, kjo punë është duke u kryer.

Rasti i dytë: defektet e onboardingut

Onboarding është një procedurë e opcional, e cila ndihmon gjatë regjistrimit të një nxënësi të ri dhe e shfuqizon potencialisht problemet teknike në të ardhmen. Skenari bazë nënkupton se personi është regjistruar në landing page, ka marrë qasje në llogarinë personale, janë në kontakt me të dhe bëjnë një mësim të hyrjes. Gjatë kësaj, ne vërejmë një përqindje të madhe të vështirësive teknike gjatë mësimit të hyrjes: versioni i gabuar i shfletuesit, mikrofonin ose tingujt që nuk punojnë, mësuesi nuk mund ta japë menjëherë një zgjidhje, dhe e gjithë kjo është veçanërisht e vështirë kur flitet për fëmijët. Prandaj, ne kemi zhvilluar një aplikacion shtesë në llogarinë personale, ku mund të përfundohet katër hapa të thjeshtë: kontrolloni shfletuesin, kamerën, mikrofonin dhe konfirmoni se prindërit do të jenë pranë gjatë mësimit të hyrjes (pasi ata janë ata që paguajnë për mësimin e fëmijëve).

Këto disa faqe on boarding tregonin një funnel të tillë:

1: blloku fillestar me tre forma pak të ndryshme (në varësi të klientit) për futjen e përdoruesit dhe fjalëkalimit.
2: kutia e pajtimit për një procedurë shtesë onboarding.
2.1-2.3: kontrolli i pranisë së prindit, versions së Chrome dhe zërit.
3: blloku përfundimtar.

Duket shumë natyrshëm: në dy hapat e parë pjesa më e madhe e vizitorëve largohet, duke kuptuar se duhet të plotësojnë, kontrollojnë, dhe se nuk kanë kohë. Nëse klienti arrin hapin e tretë — ai pothuajse me siguri do të arrijë në përfundim. Në tunelin e konvertimit nuk duket asnjë arsyetim për të dyshuar se diçka nuk shkon.

Megjithatë, vendosëm të analizojmë onboarding-un tonë jo në një tunel klasik një-dimensional, por me ndihmën e zinxhirit Markov. Përfshimë pak më shumë ngjarje, aktivizuam skenarin dhe dhamë këtë rezultat:

Të kuptosh qartë në këtë kaos mund të thuhet vetëm një gjë: diçka nuk shkoi siç duhet. Procesi i onboarding-ut është linear, kjo është e inkorporuar në dizajn, dhe nuk duhet të ketë një rrjet të tillë lidhjesh. Dhe këtu menjëherë duket se përdoruesi lëviz mes hapave, mes të cilëve nuk duhet të ketë kalime.

Arsyet për këtë pamje të çuditshme mund të jenë dy:

• gabime janë fshehur në bazën e log-eve;
• problem përmbajnë në produktin vetë — onboarding.

Arsyeja e parë, me siguri, ekziston, por të kontrollosh atë është mjaft punë e vështirë, dhe korrigjimi i logëve nuk ndihmon aspak në përmirësimin e UX. Ndërsa për të dytën, nëse ekziston, duhej të merreshim urgjentisht me atë. Prandaj, filluam të shqyrtonim nyjet, të identifikonim skajet që nuk duhej të ishin, të kërkonim arsyet e shfaqjes së tyre. Vërejta se disa përdorues ngacmoheshin dhe rrotulloheshin në një cikël, disa të tjerë — dilnin nga mesi në fillim, të tretët në tërësi nuk mund të dilnin nga dy hapat e parë. I përcollëm të dhënat në QA — dhe po, doli se në onboarding kishte shumë bugs: ky është një produkt i tillë anësor, pak i përkohshëm, nuk ishte testuar mjaft thellë, sepse nuk prisnim ndonjë problem. Tani i gjithë procesi i regjistrimit është ndërruar.

Kjo histori na tregoi një përdorim të papritur të zinxhirëve Markov në fushën e QA.

Provoje vetë!

Kam postuar skriptin tim Python për trajnimin e zinxhirëve Markov në akses të hapur — përdorni me shëndet. Dokumentacioni në GitHub, pyetje mund të bëhen këtu, do të përpiqem të përgjigjem për të gjitha.

Dhe disa lidhje të dobishme: biblioteka NetworkX, vizualizuesi Graphviz. Këtu në Habrë ka një artikull rreth zinxhirëve Markov. Grafet në artikull janë bërë me ndihmën e Gephi.

Burimi: habr.com