Layanan taksi yang baik harus aman, andal, dan cepat. Pengguna tidak akan merinci: penting baginya untuk mengklik tombol "Pesan" dan menerima mobil secepat mungkin yang akan membawanya dari titik A ke titik B. Jika tidak ada mobil di dekatnya, layanan harus segera menginformasikan hal ini agar klien tidak mempunyai harapan yang salah. Namun jika tanda βDilarang mobilβ muncul terlalu sering, maka masuk akal jika seseorang akan berhenti menggunakan layanan ini dan beralih ke pesaing.
Dalam artikel ini saya ingin berbicara tentang bagaimana, dengan menggunakan pembelajaran mesin, kami memecahkan masalah pencarian mobil di area dengan kepadatan rendah (dengan kata lain, di mana, pada pandangan pertama, tidak ada mobil). Dan apa hasilnya.
prasejarah
Untuk memanggil taksi, pengguna melakukan beberapa langkah sederhana, tetapi apa yang terjadi di dalam layanan?
| Pengguna | Panggung | Backend Yandex.Taksi |
|---|---|---|
| Memilih titik awal | Pin | Kami meluncurkan pencarian kandidat yang disederhanakan - pencarian pin. Berdasarkan pengemudi yang ditemukan, waktu kedatangan diperkirakan - ETA di pin. Koefisien pertambahan pada titik tertentu dihitung. |
| Memilih tujuan, tarif, persyaratan | Menawarkan | Kami membangun rute dan menghitung harga untuk semua tarif, dengan mempertimbangkan koefisien kenaikan. |
| Menekan tombol βPanggil Taksiβ. | Memesan | Kami meluncurkan pencarian penuh untuk mobil tersebut. Kami memilih pengemudi yang paling cocok dan menawarinya pesanan. |
Tentang , ΠΈ kami sudah menulis. Dan ini adalah kisah tentang mencari pengemudi. Saat pesanan dibuat, pencarian dilakukan dua kali: pada Pin dan pada pesanan. Pencarian pesanan dilakukan dalam dua tahap: rekrutmen kandidat dan pemeringkatan. Pertama, ditemukan calon pengemudi yang tersedia yang paling dekat sepanjang grafik jalan. Kemudian bonus dan pemfilteran diterapkan. Kandidat yang tersisa diberi peringkat dan pemenangnya menerima tawaran pesanan. Jika dia setuju, dia ditugaskan untuk memesan dan pergi ke titik pengiriman. Jika dia menolak, maka tawaran berikutnya datang. Jika tidak ada kandidat lagi, pencarian dimulai lagi. Ini berlangsung tidak lebih dari tiga menit, setelah itu pesanan dibatalkan dan dibakar.
Pencarian pada Pin mirip dengan pencarian berdasarkan pesanan, hanya saja pesanan tersebut tidak dibuat dan pencarian itu sendiri hanya dilakukan satu kali. Pengaturan yang disederhanakan untuk jumlah kandidat dan radius pencarian juga digunakan. Penyederhanaan seperti itu diperlukan karena jumlah pin lebih banyak daripada jumlah pesanan, dan pencarian adalah operasi yang agak sulit. Poin kunci dari cerita kami: jika selama pencarian awal tidak ditemukan kandidat yang cocok di Pin, maka kami tidak mengizinkan Anda melakukan pemesanan. Setidaknya begitulah dulu.
Inilah yang dilihat pengguna di aplikasi:
Cari mobil tanpa mobil
Suatu hari kami mengajukan hipotesis: mungkin dalam beberapa kasus pesanan masih dapat diselesaikan, meskipun tidak ada mobil yang di pin. Lagi pula, beberapa waktu berlalu antara pin dan pesanan, dan pencarian pesanan lebih lengkap dan terkadang diulang beberapa kali: selama waktu ini, driver yang tersedia mungkin muncul. Kami juga tahu yang sebaliknya: jika driver ditemukan di pin, bukan fakta bahwa mereka akan ditemukan saat memesan. Terkadang mereka menghilang atau semua orang menolak perintah tersebut.
Untuk menguji hipotesis ini, kami meluncurkan eksperimen: kami berhenti memeriksa keberadaan mobil selama penelusuran Pin untuk sekelompok pengguna uji, yaitu, mereka memiliki kesempatan untuk melakukan βpesanan tanpa mobilβ. Hasilnya sangat tidak terduga: jika mobil tidak ada di pin, maka dalam 29% kasus ditemukan kemudian - saat mencari pesanan! Selain itu, pesanan tanpa mobil tidak berbeda secara signifikan dengan pesanan biasa dalam hal tingkat pembatalan, peringkat, dan indikator kualitas lainnya. Pemesanan tanpa mobil menyumbang 5% dari seluruh pemesanan, namun hanya lebih dari 1% dari seluruh perjalanan yang berhasil.
Untuk memahami dari mana asal pelaksana pesanan ini, mari kita lihat status mereka saat mencari Pin:
- Tersedia: tersedia, tetapi karena alasan tertentu tidak termasuk dalam calon, misalnya terlalu jauh;
- Sesuai pesanan: sedang sibuk, tetapi berhasil membebaskan dirinya atau siap sedia ;
- Sibuk: kemampuan untuk menerima pesanan dinonaktifkan, tetapi kemudian pengemudi kembali ke antrean;
- Tidak tersedia: pengemudinya tidak online, tapi dia muncul.
Mari tambahkan keandalan
Pesanan tambahan memang bagus, tetapi 29% penelusuran yang berhasil berarti 71% pengguna menunggu lama dan akhirnya tidak menghasilkan apa-apa. Meskipun hal ini bukan hal yang buruk dari sudut pandang efisiensi sistem, hal ini sebenarnya memberikan harapan palsu kepada pengguna dan membuang-buang waktu, setelah itu mereka menjadi kesal dan (mungkin) berhenti menggunakan layanan tersebut. Untuk mengatasi masalah ini, kami belajar memprediksi kemungkinan ditemukannya mobil pesanan.
Skemanya adalah sebagai berikut:
- Pengguna memasang pin.
- Pencarian dilakukan pada pin.
- Kalau tidak ada mobil, kami prediksi: mungkin akan muncul.
- Dan tergantung pada kemungkinannya, kami mengizinkan atau tidak mengizinkan Anda melakukan pemesanan, namun kami memperingatkan Anda bahwa kepadatan mobil di area ini saat ini rendah.
Di aplikasi tampilannya seperti ini:
Penggunaan model ini memungkinkan Anda membuat pesanan baru dengan lebih akurat dan tidak meyakinkan orang dengan sia-sia. Artinya, mengatur rasio keandalan dan jumlah pesanan tanpa mesin menggunakan model presisi-recall. Keandalan layanan mempengaruhi keinginan untuk terus menggunakan produk, yaitu pada akhirnya semuanya tergantung pada jumlah perjalanan.
Sedikit tentang penarikan presisiSalah satu tugas dasar dalam pembelajaran mesin adalah tugas klasifikasi: menugaskan suatu objek ke salah satu dari dua kelas. Dalam hal ini, hasil algoritma pembelajaran mesin sering kali berupa penilaian numerik keanggotaan di salah satu kelas, misalnya penilaian probabilitas. Namun, tindakan yang dilakukan biasanya bersifat biner: jika mobil tersedia, kami akan mengizinkan Anda memesannya, dan jika tidak, maka kami tidak akan memesannya. Untuk lebih spesifiknya, sebut saja algoritme yang menghasilkan estimasi numerik sebagai model, dan pengklasifikasi sebagai aturan yang menetapkannya ke salah satu dari dua kelas (1 atau β1). Untuk membuat pengklasifikasi berdasarkan penilaian model, Anda perlu memilih ambang penilaian. Bagaimana tepatnya sangat bergantung pada tugas.
Misalkan kita sedang melakukan tes (pengklasifikasi) untuk beberapa penyakit langka dan berbahaya. Berdasarkan hasil tes tersebut, kami akan mengirim pasien untuk pemeriksaan lebih detail, atau mengatakan: βBagus, pulanglah.β Bagi kami, memulangkan orang sakit jauh lebih buruk daripada memeriksa orang sehat secara sia-sia. Artinya, kami ingin tes ini dapat diterapkan pada sebanyak mungkin orang yang benar-benar sakit. Nilai ini disebut recall =. Pengklasifikasi yang ideal memiliki recall sebesar 100%. Situasi yang memburuk adalah mengirim semua orang untuk diperiksa, maka penarikannya juga akan 100%.
Hal ini juga terjadi sebaliknya. Misalnya, kami membuat sistem ujian untuk siswa, dan sistem tersebut memiliki pendeteksi kecurangan. Jika tiba-tiba cek tidak berfungsi untuk beberapa kasus kecurangan, maka ini tidak menyenangkan, tetapi tidak kritis. Di sisi lain, sangatlah buruk jika kita menuduh siswa secara tidak adil atas sesuatu yang tidak mereka lakukan. Artinya, penting bagi kita bahwa di antara jawaban positif pengklasifikasi ada sebanyak mungkin jawaban yang benar, mungkin sehingga merugikan jumlahnya. Artinya Anda perlu memaksimalkan presisi = . Jika pemicuan terjadi pada semua objek, maka presisi akan sama dengan frekuensi kelas yang ditentukan dalam sampel.
Jika algoritme menghasilkan nilai probabilitas numerik, maka dengan memilih ambang batas yang berbeda, Anda dapat mencapai nilai perolehan presisi yang berbeda.
Dalam masalah kita situasinya adalah sebagai berikut. Recall adalah jumlah pesanan yang dapat kami tawarkan, presisi adalah keandalan pesanan tersebut. Seperti inilah kurva presisi-recall model kita:
Ada dua kasus ekstrem: jangan izinkan siapa pun memesan dan izinkan semua orang memesan. Jika Anda tidak mengizinkan siapa pun, maka penarikan kembali akan menjadi 0: kami tidak membuat pesanan, tetapi tidak ada satupun yang gagal. Jika kami mengizinkan semua orang, maka penarikan kembali akan menjadi 100% (kami akan menerima semua kemungkinan pesanan), dan presisi akan menjadi 29%, yaitu 71% pesanan akan buruk.
Kami menggunakan berbagai parameter titik awal sebagai tanda:
- Waktu/tempat.
- Status sistem (jumlah mesin yang ditempati dari semua tarif dan pin di sekitarnya).
- Parameter pencarian (radius, jumlah kandidat, batasan).
Lebih lanjut mengenai tanda-tandanya
Secara konseptual, kami ingin membedakan dua situasi:
- "Hutan dalam" - tidak ada mobil di sini saat ini.
- βSialβ - ada mobil, tetapi saat mencari tidak ada yang cocok.
Salah satu contoh βSialβ adalah jika banyak permintaan di pusat pada Jumat malam. Ada banyak pesanan, banyak orang yang bersedia, dan tidak cukup supir untuk semua orang. Mungkin jadinya seperti ini: tidak ada driver yang cocok di pin. Namun hanya dalam hitungan detik mereka muncul, karena saat ini banyak sekali pengemudi di tempat ini dan statusnya terus berubah.
Oleh karena itu, berbagai indikator sistem di sekitar titik A ternyata memiliki fitur yang bagus:
- Jumlah total mobil.
- Jumlah mobil yang dipesan.
- Jumlah mobil yang tidak tersedia untuk dipesan dalam status βSibukβ.
- Jumlah pengguna.
Lagi pula, semakin banyak mobil yang ada, semakin besar kemungkinan salah satunya tersedia.
Faktanya, penting bagi kami agar tidak hanya lokasi mobil, tetapi juga perjalanan yang berhasil dilakukan. Oleh karena itu, kemungkinan perjalanan berhasil dapat diprediksi. Namun kami memutuskan untuk tidak melakukan ini, karena nilai ini sangat bergantung pada pengguna dan pengemudi.
Algoritma pelatihan model adalah . Data yang diperoleh dari percobaan digunakan untuk pelatihan. Setelah implementasi, data pelatihan harus dikumpulkan, terkadang memungkinkan sejumlah kecil pengguna untuk menentang keputusan model.
Hasil
Hasil percobaan seperti yang diharapkan: penggunaan model ini memungkinkan Anda meningkatkan jumlah perjalanan yang berhasil secara signifikan karena pesanan tanpa mobil, tetapi tanpa mengurangi keandalan.
Saat ini, mekanisme tersebut telah diluncurkan di semua kota dan negara dan dengan bantuannya, sekitar 1% perjalanan yang berhasil terjadi. Apalagi, di beberapa kota dengan kepadatan mobil rendah, porsi perjalanan mencapai 15%.
Postingan lain tentang teknologi Taksi
Sumber: www.habr.com