Bagaimana kami menggunakan rantai Markov dalam mengevaluasi solusi dan menemukan bug. Dengan skrip Python

Penting bagi kami untuk memahami apa yang terjadi pada siswa kami selama pelatihan dan bagaimana peristiwa ini memengaruhi hasilnya, jadi kami membuat Peta Perjalanan Pelanggan - peta pengalaman pelanggan. Bagaimanapun juga, proses belajar bukanlah sesuatu yang berkesinambungan dan integral, melainkan suatu rangkaian peristiwa dan tindakan siswa yang saling berhubungan, dan tindakan tersebut dapat sangat bervariasi antar siswa. Sekarang dia telah menyelesaikan pelajarannya: apa yang akan dia lakukan selanjutnya? Apakah itu akan menjadi pekerjaan rumah? Apakah itu akan meluncurkan aplikasi seluler? Akankah dia mengubah haluan, meminta untuk mengganti guru? Apakah Anda akan langsung melanjutkan ke pelajaran berikutnya? Atau dia akan pergi dengan kecewa? Apakah mungkin, dengan menganalisis peta ini, untuk mengidentifikasi pola-pola yang mengarah pada keberhasilan penyelesaian kursus atau, sebaliknya, “putus sekolah” siswa?

Bagaimana kami menggunakan rantai Markov dalam mengevaluasi solusi dan menemukan bug. Dengan skrip Python

Biasanya, alat sumber tertutup khusus dan sangat mahal digunakan untuk membangun CJM. Namun kami ingin menghasilkan sesuatu yang sederhana, memerlukan sedikit usaha dan, jika memungkinkan, open source. Jadi muncul ide untuk menggunakan rantai Markov - dan kami berhasil. Kami membuat peta, menafsirkan data perilaku siswa dalam bentuk grafik, melihat jawaban yang sama sekali tidak jelas terhadap masalah bisnis global, dan bahkan menemukan bug yang sangat tersembunyi. Kami melakukan semua ini menggunakan solusi skrip Python open source. Dalam artikel ini saya akan membahas dua kasus dengan hasil yang sangat tidak jelas dan membagikan skripnya kepada semua orang.

Jadi, rantai Markov menunjukkan kemungkinan transisi antar peristiwa. Berikut adalah contoh primitif dari Wikipedia:

Bagaimana kami menggunakan rantai Markov dalam mengevaluasi solusi dan menemukan bug. Dengan skrip Python

Di sini “E” dan “A” adalah peristiwa, panah adalah transisi di antara keduanya (termasuk transisi dari suatu peristiwa ke peristiwa yang sama), dan bobot panah adalah probabilitas transisi (“grafik berarah berbobot”).

Apa yang kamu gunakan?

Sirkuit ini dilatih dengan fungsionalitas Python standar, yang diisi dengan log aktivitas siswa. Grafik pada matriks yang dihasilkan dibuat oleh perpustakaan NetworkX.

Lognya terlihat seperti ini:

Bagaimana kami menggunakan rantai Markov dalam mengevaluasi solusi dan menemukan bug. Dengan skrip Python

Ini adalah file csv yang berisi tabel tiga kolom: id siswa, nama acara, waktu terjadinya. Ketiga bidang ini cukup untuk melacak pergerakan klien, membangun peta, dan akhirnya mendapatkan rantai Markov.

Pustaka mengembalikan grafik yang dibuat dalam format .dot atau .gexf. Untuk memvisualisasikan yang pertama, Anda dapat menggunakan paket Graphviz gratis (alat gvedit), kami bekerja dengan .gexf dan Gephi, juga gratis.

Selanjutnya saya ingin memberikan dua contoh penggunaan rantai Markov, yang memungkinkan kita melihat kembali tujuan, proses pendidikan, dan ekosistem Skyeng itu sendiri. Baiklah, perbaiki bugnya.

Kasus pertama: aplikasi seluler

Untuk memulainya, kami menjelajahi perjalanan siswa melalui produk kami yang paling populer—kursus Umum. Saat itu, saya bekerja di departemen anak-anak di Skyeng dan kami ingin melihat seberapa efektif aplikasi seluler bekerja dengan audiens anak-anak kami.

Mengambil log dan menjalankannya melalui skrip, saya mendapatkan sesuatu seperti ini:

Bagaimana kami menggunakan rantai Markov dalam mengevaluasi solusi dan menemukan bug. Dengan skrip Python

Node awal adalah Mulai Umum, dan di bagian bawah terdapat tiga node keluaran: siswa “tertidur”, mengubah mata pelajaran, dan menyelesaikan mata pelajaran.

  • Tertidur, “Tertidur” - ini berarti dia tidak lagi mengikuti kelas, kemungkinan besar dia tertidur. Kami dengan optimis menyebut keadaan ini “tertidur”, karena... secara teori, ia masih memiliki kesempatan untuk melanjutkan studinya. Hasil terburuk bagi kami.
  • Jenderal turun, Mengubah arah - beralih dari Umum ke yang lain dan tersesat karena rantai Markov kami.
  • Kursus selesai, Kursus selesai - kondisi ideal, orang tersebut telah menyelesaikan 80% pelajaran (tidak semua pelajaran diperlukan).

Masuk ke node kelas yang berhasil berarti berhasil menyelesaikan pelajaran di platform kami bersama dengan guru. Ini mencatat kemajuan sepanjang kursus dan pendekatan terhadap hasil yang diinginkan - “Menyelesaikan kursus.” Penting bagi kami agar siswa hadir sebanyak mungkin.

Untuk mendapatkan kesimpulan kuantitatif yang lebih akurat untuk aplikasi seluler (node ​​sesi aplikasi), kami membuat rantai terpisah untuk setiap node akhir dan kemudian membandingkan bobot tepi secara berpasangan:

  • dari sesi aplikasi kembali ke sana;
  • dari sesi aplikasi hingga kelas sukses;
  • dari kelas yang sukses hingga sesi aplikasi.

Bagaimana kami menggunakan rantai Markov dalam mengevaluasi solusi dan menemukan bug. Dengan skrip Python
Di sebelah kiri adalah siswa yang telah menyelesaikan kursus, di sebelah kanan adalah mereka yang “tertidur”

Ketiga sisi ini menunjukkan hubungan antara keberhasilan siswa dan penggunaan aplikasi seluler. Kami berharap siswa yang menyelesaikan kursus akan memiliki koneksi yang lebih kuat ke aplikasi dibandingkan siswa yang tertidur. Namun kenyataannya, kami mendapatkan hasil sebaliknya:

  • kami memastikan bahwa kelompok pengguna yang berbeda berinteraksi dengan aplikasi seluler secara berbeda;
  • siswa yang berhasil menggunakan aplikasi seluler dengan kurang intensif;
  • siswa yang tertidur menggunakan aplikasi seluler lebih aktif.

Artinya, siswa yang tertidur mulai menghabiskan lebih banyak waktu di aplikasi seluler dan, pada akhirnya, tetap berada di dalamnya selamanya.

Bagaimana kami menggunakan rantai Markov dalam mengevaluasi solusi dan menemukan bug. Dengan skrip Python

Awalnya kami terkejut, namun setelah memikirkannya, kami menyadari bahwa ini adalah efek yang sepenuhnya alami. Pada suatu waktu, saya belajar bahasa Prancis sendiri menggunakan dua alat: aplikasi seluler dan kuliah tata bahasa di YouTube. Awalnya saya membagi waktu di antara mereka dengan perbandingan 50 banding 50. Tapi aplikasinya lebih menyenangkan, ada gamifikasi, semuanya sederhana, cepat dan jelas, tetapi dalam perkuliahan harus mendalami, tulis sesuatu , berlatih di buku catatan. Perlahan-lahan, saya mulai menghabiskan lebih banyak waktu di ponsel cerdas saya, hingga porsinya meningkat menjadi 100%: jika Anda menghabiskan tiga jam di atasnya, Anda menciptakan perasaan palsu tentang pekerjaan yang telah selesai, itulah sebabnya Anda tidak memiliki keinginan untuk pergi dan mendengarkan apa pun. .

Tapi bagaimana ini bisa terjadi? Bagaimanapun, kami secara khusus membuat aplikasi seluler, membangun kurva Ebbinghaus di dalamnya, melakukan gamifikasi, membuatnya menarik agar orang-orang menghabiskan waktu di dalamnya, namun ternyata hanya mengganggu perhatian mereka? Faktanya, alasannya adalah tim aplikasi seluler melakukan tugasnya dengan sangat baik, sehingga menjadi produk yang keren dan mandiri dan mulai keluar dari ekosistem kita.

Sebagai hasil dari penelitian, menjadi jelas bahwa aplikasi seluler perlu diubah agar tidak terlalu mengganggu mata pelajaran utama. Dan baik anak-anak maupun orang dewasa. Pekerjaan ini sedang berlangsung.

Kasus kedua: bug orientasi

Orientasi adalah prosedur tambahan opsional saat mendaftarkan siswa baru, sehingga menghilangkan potensi masalah teknis di masa depan. Skenario dasar mengasumsikan bahwa seseorang telah mendaftar di halaman arahan, memperoleh akses ke akun pribadinya, dihubungi dan diberi pelajaran pengantar. Pada saat yang sama, kami mencatat sebagian besar kesulitan teknis selama pelajaran pengantar: versi browser yang salah, mikrofon atau suara tidak berfungsi, guru tidak dapat segera menyarankan solusi, dan semua ini menjadi sangat sulit jika menyangkut masalah. kepada anak-anak. Oleh karena itu, kami telah mengembangkan aplikasi tambahan di akun pribadi Anda, di mana Anda dapat menyelesaikan empat langkah sederhana: periksa browser, kamera, mikrofon, dan konfirmasikan bahwa orang tua akan berada di dekatnya selama pelajaran pengantar (bagaimanapun juga, merekalah yang membayar untuk pendidikan anak-anak mereka).

Beberapa halaman orientasi ini menunjukkan corong seperti ini:

Bagaimana kami menggunakan rantai Markov dalam mengevaluasi solusi dan menemukan bug. Dengan skrip Python
1: blok awal dengan tiga formulir login dan entri kata sandi yang sedikit berbeda (tergantung pada klien).
2: kotak centang menyetujui prosedur orientasi tambahan.
2.1-2.3: Periksa kehadiran orang tua, versi Chrome, dan suara.
3: blok terakhir.

Kelihatannya sangat natural: pada dua langkah pertama, sebagian besar pengunjung keluar, menyadari ada yang harus diisi, diperiksa, tetapi tidak ada waktu. Jika klien sudah mencapai langkah ketiga, maka hampir pasti dia akan mencapai final. Tidak ada satu pun alasan untuk mencurigai apa pun di corong tersebut.

Namun demikian, kami memutuskan untuk menganalisis orientasi kami bukan pada corong satu dimensi klasik, tetapi menggunakan rantai Markov. Kami mengaktifkan lebih banyak acara, menjalankan skrip dan mendapatkan ini:

Bagaimana kami menggunakan rantai Markov dalam mengevaluasi solusi dan menemukan bug. Dengan skrip Python

Dalam kekacauan ini, hanya satu hal yang dapat dipahami dengan jelas: ada yang tidak beres. Proses orientasinya linier, ini melekat pada desain, tidak boleh ada jaringan koneksi seperti itu di dalamnya. Dan di sini terlihat jelas bahwa pengguna terlempar di antara langkah-langkah, di antaranya tidak boleh ada transisi sama sekali.

Bagaimana kami menggunakan rantai Markov dalam mengevaluasi solusi dan menemukan bug. Dengan skrip Python

Mungkin ada dua alasan untuk gambaran aneh ini:

  • beting merayap ke dalam database log;
  • Ada kesalahan dalam produk itu sendiri - orientasi.

Alasan pertama kemungkinan besar benar, tetapi mengujinya cukup memakan waktu, dan memperbaiki log tidak akan membantu meningkatkan UX. Namun untuk kasus kedua, jika memang ada, sesuatu harus segera dilakukan. Oleh karena itu, kami memeriksa node, mengidentifikasi tepi yang seharusnya tidak ada, dan mencari alasan kemunculannya. Kami melihat beberapa pengguna terjebak dan berjalan berputar-putar, yang lain terjatuh dari tengah ke awal, dan yang lain, pada prinsipnya, tidak dapat keluar dari dua langkah pertama. Kami mentransfer data ke QA - dan ya, ternyata ada cukup banyak bug saat orientasi: ini adalah produk sampingan, sedikit penopang, tidak diuji cukup mendalam, karena... Kami tidak mengharapkan adanya masalah. Sekarang seluruh proses perekaman telah berubah.

Kisah ini menunjukkan kepada kita penerapan rantai Markov yang tidak terduga di bidang QA.

Cobalah sendiri!

Saya memposting milik saya Skrip Python untuk melatih rantai Markov di domain publik - gunakan untuk kesehatan Anda. Dokumentasi di GitHub, pertanyaan bisa ditanyakan di sini, saya akan mencoba menjawab semuanya.

Nah, tautan yang bermanfaat: perpustakaan NetworkX, Visualisator Graphviz. Dan di sini ada artikel tentang Habré tentang rantai Markov. Grafik dalam artikel dibuat menggunakan Gefi.

Sumber: www.habr.com

Tambah komentar