כיצד אנו משתמשים בשרשראות מרקוב בהערכת פתרונות ומציאת באגים. עם סקריפט Python

חשוב לנו להבין מה קורה לתלמידים שלנו במהלך ההכשרה וכיצד אירועים אלו משפיעים על התוצאה, ולכן אנו בונים מפת מסע לקוחות – מפה של חווית הלקוח. הרי תהליך הלמידה הוא לא משהו מתמשך ואינטגרלי, הוא שרשרת של אירועים ופעולות הקשורות זו בזו של התלמיד, ופעולות אלו יכולות להשתנות מאוד בין תלמידים שונים. עכשיו הוא השלים את השיעור שלו: מה יעשה אחר כך? זה ילך לשיעורי בית? האם זה ישיק אפליקציה לנייד? האם הוא ישנה מסלול, יבקש להחליף מורים? האם תעבור ישר לשיעור הבא? או שהוא פשוט יעזוב מאוכזב? האם ניתן, על ידי ניתוח מפה זו, לזהות דפוסים המובילים לסיום מוצלח של הקורס או להיפך, ל"נשירה" של התלמיד?

בדרך כלל משתמשים בכלים מיוחדים ויקרים מאוד במקור סגור לבניית CJM. אבל רצינו להמציא משהו פשוט, הדורש מאמץ מינימלי ואם אפשר, קוד פתוח. אז עלה הרעיון להשתמש ברשתות מרקוב – והצלחנו. בנינו מפה, פירשנו נתונים על התנהגות תלמידים בצורה של גרף, ראינו תשובות לגמרי לא ברורות לבעיות עסקיות גלובליות, ואפילו מצאנו באגים חבויים עמוק. עשינו את כל זה באמצעות פתרונות סקריפט של Python בקוד פתוח. במאמר זה אדבר על שני מקרים עם אותן תוצאות מאוד לא ברורות ואשתף את התסריט עם כולם.

אז, שרשראות מרקוב מראות את ההסתברות למעברים בין אירועים. הנה דוגמה פרימיטיבית מויקיפדיה:

כאן "E" ו-"A" הם אירועים, החצים הם מעברים ביניהם (כולל המעבר מאירוע לאותו), ומשקולות החצים הם ההסתברות למעבר ("גרף מכוון משוקלל").

במה השתמשת?

המעגל הוכשר עם פונקציונליות סטנדרטית של Python, שהוזנה ביומני פעילות של תלמידים. הגרף על המטריצה ​​שהתקבלה נבנה על ידי ספריית NetworkX.

היומן נראה כך:

זהו קובץ csv המכיל טבלה של שלוש עמודות: זיהוי תלמיד, שם האירוע, שעה שבה הוא התרחש. שלושת השדות הללו מספיקים כדי להתחקות אחר תנועות הלקוח, לבנות מפה ובסופו של דבר לקבל שרשרת מרקוב.

הספרייה מחזירה את הגרפים שנבנו בפורמט .dot או .gexf. כדי לדמיין את הראשון, אתה יכול להשתמש בחבילת Graphviz החינמית (כלי gvedit), עבדנו עם .gexf ו-Gephi, גם בחינם.

בשלב הבא אני רוצה לתת שתי דוגמאות לשימוש ברשתות מרקוב, שאפשרו לנו להסתכל מחדש על המטרות שלנו, התהליכים החינוכיים והאקולוגית של Skyeng עצמה. ובכן, תקן את הבאגים.

מקרה ראשון: אפליקציה לנייד

מלכתחילה, חקרנו את מסע הסטודנטים דרך המוצר הפופולרי ביותר שלנו - הקורס הכללי. באותו רגע עבדתי במחלקת הילדים של Skyeng ורצינו לראות באיזו יעילות האפליקציה הסלולרית עובדת עם קהל הילדים שלנו.

כשלקחתי את היומנים והרצתי אותם בסקריפט, קיבלתי משהו כזה:

צומת ההתחלה הוא Start General, ובתחתית יש שלושה צמתי פלט: התלמיד "נרדם", שינה קורס וסיים את הקורס.

• נרדם, "נרדם" - זה אומר שהוא כבר לא לוקח שיעורים, סביר להניח שהוא נפל. אנו קוראים באופטימיות למצב הזה "ישן", כי... בתיאוריה, עדיין יש לו הזדמנות להמשיך את לימודיו. התוצאה הגרועה ביותר עבורנו.
• ירד גנרל, שינה מסלול - עבר מגנרל למשהו אחר והלך לאיבוד לרשת מרקוב שלנו.
• סיים קורס, סיים את הקורס - מצב אידיאלי, האדם סיים 80% מהשיעורים (לא כל השיעורים נדרשים).

כניסה לצומת הכיתה המוצלחת פירושה השלמת השיעור בהצלחה בפלטפורמה שלנו יחד עם המורה. הוא מתעד את ההתקדמות לאורך הקורס והגישה לתוצאה הרצויה - "סיים את הקורס". חשוב לנו שהסטודנטים ישתתפו כמה שיותר.

כדי לקבל מסקנות כמותיות מדויקות יותר עבור האפליקציה לנייד (צומת הפעלה של אפליקציה), בנינו שרשראות נפרדות עבור כל אחד מהצמתים הסופיים ולאחר מכן השווינו את משקלי הקצוות בזוג:

• מההפעלה של האפליקציה חזרה אליו;
• מסשן אפליקציה לשיעור מוצלח;
• משיעור מוצלח להפעלת אפליקציה.

משמאל סטודנטים שסיימו את הקורס, מימין אלו ש"נרדמו"

שלושת הקצוות הללו מראים את הקשר בין הצלחתו של תלמיד לבין השימוש שלו באפליקציה לנייד. ציפינו לראות שלסטודנטים שסיימו את הקורס יהיה קשר חזק יותר לאפליקציה מאשר לסטודנטים שנרדמו. עם זאת, במציאות קיבלנו בדיוק את התוצאות ההפוכות:

• דאגנו שקבוצות שונות של משתמשים יקיימו אינטראקציה שונה עם האפליקציה לנייד;
• תלמידים מצליחים משתמשים באפליקציה לנייד באופן פחות אינטנסיבי;
• תלמידים שנרדמים משתמשים באפליקציה לנייד בצורה פעילה יותר.

המשמעות היא שסטודנטים שנרדמים מתחילים לבלות יותר ויותר זמן באפליקציית המובייל ובסופו של דבר נשארים בה לנצח.

בהתחלה הופתענו, אבל אחרי שחשבנו על זה, הבנו שמדובר באפקט טבעי לחלוטין. פעם, למדתי צרפתית לבד באמצעות שני כלים: אפליקציה לנייד והרצאות דקדוק ביוטיוב. בהתחלה חילקתי את הזמן ביניהם ביחס של 50 ל-50. אבל האפליקציה יותר כיפית, יש משחקיות, הכל פשוט, מהיר וברור, אבל בהרצאה צריך להתעמק, לרשום משהו. , תרגול במחברת. לאט לאט התחלתי לבלות יותר זמן בסמארטפון שלי, עד שחלקו גדל ל-100%: אם משקיעים בו שלוש שעות, נוצרת הרגשה שקרית של עבודה גמורה, שבגללה אין לך חשק ללכת ולהקשיב לכלום. .

אבל איך זה יכול להיות? אחרי הכל, יצרנו במיוחד אפליקציה לנייד, מובנה בתוכו את עקומת האבינגהאוס, הפך אותו לאטרקטיבי כדי שאנשים יבלו בו זמן, אבל מסתבר שזה רק מסיח את דעתם? למעשה, הסיבה היא שצוות האפליקציות למובייל התמודד טוב מדי עם המשימות שלו, וכתוצאה מכך הוא הפך למוצר מגניב, עצמאי והחל לנשור מהאקוסיסטם שלנו.

כתוצאה מהמחקר, התברר שצריך לשנות איכשהו את אפליקציית המובייל כדי שהיא פחות תסיח את הדעת ממהלך הלימודים העיקרי. וגם ילדים ומבוגרים. עבודה זו מתבצעת כעת.

מקרה שני: באגים למטוס

השתלמות היא הליך נוסף אופציונלי בעת רישום תלמיד חדש, המבטל בעיות טכניות פוטנציאליות בעתיד. התרחיש הבסיסי מניח שאדם נרשם בדף הנחיתה, השיג גישה לחשבון האישי שלו, פנה אליו וניתן לו שיעור היכרות. יחד עם זאת, אנו מבחינים באחוז גדול של קשיים טכניים במהלך שיעור המבוא: גרסה לא נכונה של הדפדפן, המיקרופון או הסאונד לא עובדים, המורה לא יכול להציע מיד פתרון, וכל זה קשה במיוחד כשזה מגיע לילדים. לכן, פיתחנו אפליקציה נוספת בחשבון האישי שלכם, בה תוכלו לבצע ארבעה שלבים פשוטים: בדקו את הדפדפן, המצלמה, המיקרופון ואשרו שההורים יהיו בקרבת מקום במהלך שיעור ההיכרות (הרי הם אלה שמשלמים עבור חינוך ילדיהם).

כמה דפי ההצטרפות האלה הראו משפך כמו זה:

1: בלוק התחלה עם שלושה טפסי כניסה וסיסמה מעט שונים (בהתאם ללקוח).
2: תיבת סימון הסכמה לנוהל ההצטרפות הנוסף.
2.1-2.3: בדוק נוכחות הורים, גרסת Chrome וצליל.
3: בלוק אחרון.

זה נראה מאוד טבעי: בשני השלבים הראשונים רוב המבקרים עוזבים, מבינים שיש מה למלא, בודקים, אבל אין זמן. אם הלקוח הגיע לשלב השלישי, אז הוא יגיע כמעט בוודאות לגמר. אין סיבה אחת לחשוד במשהו במשפך.

עם זאת, החלטנו לנתח את ההטמעה שלנו לא במשפך חד-ממדי קלאסי, אלא באמצעות שרשרת מרקוב. הפעלנו עוד קצת אירועים, הרצנו את התסריט וקיבלנו את זה:

בכאוס הזה אפשר להבין בבירור רק דבר אחד: משהו השתבש. תהליך ההטמעה הוא ליניארי, זה טבוע בעיצוב, לא אמור להיות בו רשת כזו של קשרים. וכאן ברור מיד שהמשתמש נזרק בין שלבים, שביניהם לא אמורים להיות מעברים כלל.

יכולות להיות שתי סיבות לתמונה המוזרה הזו:

• להקות התגנבו למאגר היומנים;
• יש טעויות במוצר עצמו - onboarding.

סביר להניח שהסיבה הראשונה נכונה, אבל הבדיקה היא די דורשת עבודה, ותיקון היומנים לא יעזור לשפר את ה-UX. אבל עם השני, אם הוא קיים, היה צריך לעשות משהו בדחיפות. לכן, הלכנו להסתכל על הצמתים, לזהות קצוות שלא אמורים להתקיים ולחפש את הסיבות להופעתם. ראינו שחלק מהמשתמשים נתקעו והלכו במעגלים, אחרים נפלו מהאמצע להתחלה ואחרים, באופן עקרוני, לא הצליחו לצאת משני השלבים הראשונים. העברנו את הנתונים ל-QA - וכן, התברר שיש מספיק באגים ב-onboarding: זה כזה תוצר לוואי, קצת קב, זה לא נבדק מספיק עמוק, כי... לא ציפינו לבעיות. עכשיו כל תהליך ההקלטה השתנה.

הסיפור הזה הראה לנו יישום לא צפוי של רשתות מרקוב בתחום ה-QA.

נסה זאת בעצמך!

פרסמתי את שלי תסריט פייתון לאימון שרשראות מרקוב ברשות הרבים - השתמש בו לבריאותך. תיעוד ב-GitHub, ניתן לשאול שאלות כאן, אנסה לענות על הכל.

ובכן, קישורים שימושיים: ספריית NetworkX, Visualizer של Graphviz. והנה יש מאמר על Habré על רשתות מרקוב. הגרפים במאמר נעשים באמצעות גפי.

מקור: www.habr.com