Hoe we Markov-ketens gebruiken bij het evalueren van oplossingen en het vinden van bugs. Met een Python-script

Het is belangrijk voor ons om te begrijpen wat er met onze studenten gebeurt tijdens de training en hoe deze gebeurtenissen het resultaat beïnvloeden. Daarom bouwen we een Customer Journey Map - een kaart van de klantervaring. Het leerproces is immers niet iets continu en integraals, het is een keten van onderling verbonden gebeurtenissen en acties van de leerling, en deze acties kunnen sterk variëren tussen de verschillende leerlingen. Nu heeft hij zijn les afgerond: wat gaat hij nu doen? Zal het naar huiswerk gaan? Zal het een mobiele applicatie lanceren? Zal hij van koers veranderen, vragen om van leraar te veranderen? Ga je meteen door naar de volgende les? Of zal hij gewoon teleurgesteld vertrekken? Is het mogelijk om door het analyseren van deze kaart patronen te identificeren die leiden tot het succesvol afronden van de cursus of, omgekeerd, tot de “uitval” van de student?

Hoe we Markov-ketens gebruiken bij het evalueren van oplossingen en het vinden van bugs. Met een Python-script

Meestal worden gespecialiseerde, zeer dure closed-source tools gebruikt om CJM te bouwen. Maar we wilden met iets simpels komen, dat minimale inspanning vergt en, indien mogelijk, open source. Zo ontstond het idee om Markov-kettingen te gebruiken - en dat is gelukt. We hebben een kaart gemaakt, gegevens over het gedrag van studenten geïnterpreteerd in de vorm van een grafiek, totaal niet voor de hand liggende antwoorden op mondiale zakelijke problemen gezien en zelfs diep verborgen bugs gevonden. We hebben dit allemaal gedaan met behulp van open source Python-scriptoplossingen. In dit artikel zal ik het hebben over twee gevallen met die zeer niet voor de hand liggende resultaten en het script met iedereen delen.

Markov-ketens tonen dus de waarschijnlijkheid van overgangen tussen gebeurtenissen. Hier is een primitief voorbeeld van Wikipedia:

Hoe we Markov-ketens gebruiken bij het evalueren van oplossingen en het vinden van bugs. Met een Python-script

Hier zijn “E” en “A” gebeurtenissen, de pijlen zijn overgangen daartussen (inclusief de overgang van een gebeurtenis naar dezelfde), en de gewichten van de pijlen zijn de waarschijnlijkheid van overgang (“gewogen gerichte grafiek”).

Wat heb je gebruikt?

Het circuit werd getraind met standaard Python-functionaliteit, die werd gevoed met logboeken van studentenactiviteiten. De grafiek op de resulterende matrix is ​​geconstrueerd door de NetworkX-bibliotheek.

Het logboek ziet er als volgt uit:

Hoe we Markov-ketens gebruiken bij het evalueren van oplossingen en het vinden van bugs. Met een Python-script

Dit is een csv-bestand met een tabel van drie kolommen: student-ID, naam van de gebeurtenis, tijdstip waarop deze plaatsvond. Deze drie velden zijn voldoende om de bewegingen van de cliënt te volgen, een kaart op te bouwen en uiteindelijk een Markov-keten te krijgen.

De bibliotheek retourneert de geconstrueerde grafieken in .dot- of .gexf-indeling. Om het eerste te visualiseren, kun je het gratis Graphviz-pakket (gvedit-tool) gebruiken, we werkten met .gexf en Gephi, ook gratis.

Vervolgens wil ik twee voorbeelden geven van het gebruik van Markov-ketens, waardoor we met een frisse blik naar onze doelen, onderwijsprocessen en het Skyeng-ecosysteem zelf konden kijken. Nou, repareer de bugs.

Eerste geval: mobiele applicatie

Om te beginnen hebben we het studententraject verkend via ons populairste product: de algemene cursus. Op dat moment werkte ik op de kinderafdeling van Skyeng en we wilden zien hoe effectief de mobiele applicatie werkte bij ons kinderpubliek.

Door de logboeken te nemen en ze door het script te laten lopen, kreeg ik zoiets als dit:

Hoe we Markov-ketens gebruiken bij het evalueren van oplossingen en het vinden van bugs. Met een Python-script

Het startknooppunt is Start Algemeen, en onderaan zijn er drie uitvoerknooppunten: de leerling is “in slaap gevallen”, heeft van koers veranderd en heeft de cursus afgerond.

  • In slaap gevallen, "In slaap gevallen" - dit betekent dat hij geen lessen meer volgt, hoogstwaarschijnlijk is hij eraf gevallen. We noemen deze toestand optimistisch ‘in slaap’, omdat... in theorie heeft hij nog steeds de mogelijkheid om zijn studie voort te zetten. Slechtste resultaat voor ons.
  • Generaal laten vallen, koers gewijzigd - overgestapt van Algemeen naar iets anders en verdwaald voor onze Markov-keten.
  • Cursus voltooid, cursus voltooid - ideale staat, de persoon heeft 80% van de lessen voltooid (niet alle lessen zijn vereist).

In het succesvolle klasknooppunt komen betekent dat je samen met de docent de les op ons platform succesvol afrondt. Het registreert de voortgang tijdens het parcours en de aanpak tot het gewenste resultaat - “Cursus voltooid.” Wij vinden het belangrijk dat studenten zoveel mogelijk aanwezig zijn.

Om nauwkeurigere kwantitatieve conclusies te krijgen voor de mobiele applicatie (app-sessieknooppunt), hebben we afzonderlijke ketens gebouwd voor elk van de laatste knooppunten en vervolgens de randgewichten paarsgewijs vergeleken:

  • van de app-sessie terug ernaartoe;
  • van app-sessie tot succesvolle les;
  • van succesvolle les tot app-sessie.

Hoe we Markov-ketens gebruiken bij het evalueren van oplossingen en het vinden van bugs. Met een Python-script
Links staan ​​studenten die de cursus hebben afgerond, rechts degenen die “in slaap zijn gevallen”

Deze drie randen laten de relatie zien tussen het succes van een leerling en zijn gebruik van de mobiele app. We verwachtten dat studenten die de cursus hebben afgerond een sterkere verbinding met de applicatie zouden hebben dan studenten die in slaap zijn gevallen. In werkelijkheid kregen we echter precies het tegenovergestelde resultaat:

  • we hebben ervoor gezorgd dat verschillende groepen gebruikers op een andere manier met de mobiele applicatie omgaan;
  • succesvolle studenten gebruiken de mobiele applicatie minder intensief;
  • studenten die in slaap vallen, gebruiken de mobiele applicatie actiever.

Dit betekent dat studenten die in slaap vallen steeds meer tijd in de mobiele applicatie doorbrengen en er uiteindelijk voor altijd in blijven zitten.

Hoe we Markov-ketens gebruiken bij het evalueren van oplossingen en het vinden van bugs. Met een Python-script

In eerste instantie waren we verrast, maar nadat we erover hadden nagedacht, beseften we dat dit een volkomen natuurlijk effect was. Ooit heb ik zelf Frans gestudeerd met behulp van twee tools: een mobiele applicatie en grammaticale lezingen op YouTube. In eerste instantie heb ik de tijd tussen hen verdeeld in een verhouding van 50 op 50. Maar de applicatie is leuker, er is gamification, alles is eenvoudig, snel en duidelijk, maar in de lezing moet je je erin verdiepen, iets opschrijven , oefen in een notitieboekje. Geleidelijk aan begon ik meer tijd op mijn smartphone door te brengen, totdat het aandeel ervan groeide tot 100%: als je er drie uur aan besteedt, creëer je een vals gevoel van voltooid werk, waardoor je geen zin hebt om ergens naar te gaan luisteren .

Maar hoe kan dit? We hebben tenslotte speciaal een mobiele applicatie gemaakt, daarin is de Ebbinghaus-curve ingebouwd, het gegamificeerd, aantrekkelijk gemaakt zodat mensen er tijd in zouden doorbrengen, maar het blijkt dat het hen alleen maar afleidt? De reden is eigenlijk dat het mobiele applicatieteam zijn taken te goed aankon, waardoor het een cool, zelfvoorzienend product werd en uit ons ecosysteem begon te vallen.

Als resultaat van het onderzoek werd duidelijk dat de mobiele applicatie op de een of andere manier aangepast moest worden, zodat deze minder afleidde van het hoofdvak van de studie. En zowel kinderen als volwassenen. Dit werk is momenteel aan de gang.

Tweede geval: onboarding-bugs

Onboarding is een optionele aanvullende procedure bij het registreren van een nieuwe student, waardoor potentiële technische problemen in de toekomst worden geëlimineerd. Het basisscenario gaat ervan uit dat een persoon zich heeft geregistreerd op de landingspagina, toegang heeft gekregen tot zijn persoonlijke account, wordt gecontacteerd en een introductieles krijgt. Tegelijkertijd constateren we tijdens de introductieles een groot percentage technische problemen: de verkeerde versie van de browser, de microfoon of het geluid werkt niet, de leraar kan niet meteen een oplossing voorstellen, en dit alles is vooral moeilijk als het gaat aan kinderen. Daarom hebben wij een extra applicatie ontwikkeld in je persoonlijke account, waarmee je vier eenvoudige stappen kunt doorlopen: controleer je browser, camera, microfoon en bevestig dat er ouders in de buurt zijn tijdens de introductieles (zij zijn immers degenen die betalen de opvoeding van hun kinderen).

Deze paar onboardingpagina's lieten een trechter als deze zien:

Hoe we Markov-ketens gebruiken bij het evalueren van oplossingen en het vinden van bugs. Met een Python-script
1: startblok met drie enigszins verschillende (afhankelijk van de klant) login- en wachtwoordinvoerformulieren.
2: selectievakje akkoord gaan met de aanvullende onboardingprocedure.
2.1-2.3: Controleer op aanwezigheid van ouders, Chrome-versie en geluid.
3: laatste blok.

Het ziet er heel natuurlijk uit: in de eerste twee stappen vertrekken de meeste bezoekers, zich realiserend dat er iets moet worden ingevuld, gecontroleerd, maar er is geen tijd. Als de cliënt de derde stap heeft bereikt, zal hij vrijwel zeker de finale bereiken. Er is geen enkele reden om iets op de trechter te vermoeden.

Toch hebben we besloten om onze onboarding niet te analyseren op basis van een klassieke eendimensionale trechter, maar op basis van een Markov-keten. We hebben wat meer evenementen ingeschakeld, het script uitgevoerd en dit gekregen:

Hoe we Markov-ketens gebruiken bij het evalueren van oplossingen en het vinden van bugs. Met een Python-script

In deze chaos kan maar één ding duidelijk worden begrepen: er is iets misgegaan. Het onboardingproces is lineair, dit is inherent aan het ontwerp, er mag niet zo'n web van verbindingen in zitten. En hier is meteen duidelijk dat de gebruiker tussen stappen wordt gegooid, waartussen helemaal geen overgangen mogen zijn.

Hoe we Markov-ketens gebruiken bij het evalueren van oplossingen en het vinden van bugs. Met een Python-script

Er kunnen twee redenen zijn voor dit vreemde beeld:

  • ondiepten kropen de logdatabase binnen;
  • Er zitten fouten in het product zelf: onboarding.

De eerste reden is waarschijnlijk waar, maar het testen ervan is behoorlijk arbeidsintensief, en het corrigeren van de logs zal de UX niet helpen verbeteren. Maar met de tweede moest er, als die bestaat, dringend iets gebeuren. Daarom gingen we naar de knooppunten kijken, randen identificeren die niet zouden mogen bestaan, en zoeken naar de redenen voor hun optreden. We zagen dat sommige gebruikers vastliepen en in cirkels liepen, anderen vielen uit het midden naar het begin en anderen konden in principe niet uit de eerste twee stappen komen. We hebben de gegevens overgedragen aan QA - en ja, het bleek dat er genoeg bugs zaten in de onboarding: dit is zo'n bijproduct, een beetje een kruk, het is niet diep genoeg getest, omdat... Wij hadden geen problemen verwacht. Nu is het hele opnameproces veranderd.

Dit verhaal liet ons een onverwachte toepassing zien van Markov-ketens op het gebied van QA.

Probeer het zelf!

Ik heb de mijne gepost Python-script voor het trainen van Markov-ketens in het publieke domein - gebruik het voor uw gezondheid. Documentatie op GitHub, vragen kunnen hier gesteld worden, ik zal proberen alles te beantwoorden.

Nou, nuttige links: NetworkX-bibliotheek, Graphviz-visualizer. En hier er is een artikel over Habré over Markov-ketens. De grafieken in het artikel zijn gemaakt met behulp van Gephi.

Bron: www.habr.com

Voeg een reactie