Perkhidmatan teksi yang baik hendaklah selamat, boleh dipercayai dan pantas. Pengguna tidak akan menjelaskan butiran: adalah penting baginya untuk mengklik butang "Pesan" dan menerima kereta secepat mungkin yang akan membawanya dari titik A ke titik B. Jika tiada kereta berdekatan, perkhidmatan itu harus segera memaklumkan perkara ini supaya pelanggan tidak mempunyai jangkaan palsu. Tetapi jika tanda "Tiada kereta" muncul terlalu kerap, maka adalah logik bahawa seseorang hanya akan berhenti menggunakan perkhidmatan ini dan pergi ke pesaing.
Dalam artikel ini saya ingin bercakap tentang bagaimana, menggunakan pembelajaran mesin, kami menyelesaikan masalah mencari kereta di kawasan berkepadatan rendah (dengan kata lain, di mana, pada pandangan pertama, tidak ada kereta). Dan apa yang datang daripadanya.
prasejarah
Untuk menghubungi teksi, pengguna melakukan beberapa langkah mudah, tetapi apa yang berlaku di dalam perkhidmatan?
| Pengguna | Pentas | Bahagian belakang Yandex.Taxi |
|---|---|---|
| Memilih titik permulaan | Sematkan | Kami melancarkan carian mudah untuk calon - carian pin. Berdasarkan pemandu yang ditemui, masa ketibaan diramalkan - ETA dalam pin. Pekali peningkatan pada titik tertentu dikira. |
| Memilih destinasi, tambang, keperluan | Tawaran | Kami membina laluan dan mengira harga untuk semua tarif, dengan mengambil kira pekali yang semakin meningkat. |
| Tekan butang "Panggil Teksi". | Perintah | Kami melancarkan carian penuh untuk kereta itu. Kami memilih pemandu yang paling sesuai dan menawarkan pesanan kepadanya. |
pada , ΠΈ kami sudah menulis. Dan ini adalah cerita tentang mencari pemandu. Apabila pesanan dibuat, carian berlaku dua kali: pada Pin dan pada pesanan. Pencarian untuk pesanan berlaku dalam dua peringkat: pengambilan calon dan kedudukan. Pertama, calon pemandu yang tersedia didapati yang paling hampir di sepanjang graf jalan. Kemudian bonus dan penapisan digunakan. Calon yang selebihnya diberi kedudukan dan pemenang menerima tawaran pesanan. Jika dia bersetuju, dia ditugaskan untuk pesanan dan pergi ke tempat penghantaran. Jika dia menolak, maka tawaran itu datang kepada yang seterusnya. Jika tiada lagi calon, pencarian dimulakan semula. Ini berlangsung tidak lebih daripada tiga minit, selepas itu pesanan dibatalkan dan dibakar.
Carian pada Pin adalah serupa dengan carian pada pesanan, hanya pesanan tidak dibuat dan carian itu sendiri dilakukan sekali sahaja. Tetapan ringkas untuk bilangan calon dan jejari carian juga digunakan. Penyederhanaan sedemikian adalah perlu kerana terdapat susunan magnitud lebih banyak pin daripada pesanan, dan pencarian adalah operasi yang agak sukar. Perkara utama untuk cerita kami: jika semasa carian awal tiada calon yang sesuai ditemui pada Pin, maka kami tidak membenarkan anda membuat pesanan. Sekurang-kurangnya begitulah dulu.
Inilah yang dilihat pengguna dalam aplikasi:
Cari kereta tanpa kereta
Pada suatu hari kami membuat hipotesis: mungkin dalam beberapa kes pesanan masih boleh diselesaikan, walaupun tiada kereta pada pin. Lagipun, beberapa masa berlalu antara pin dan pesanan, dan carian untuk pesanan itu lebih lengkap dan kadangkala diulang beberapa kali: pada masa ini, pemandu yang tersedia mungkin muncul. Kami juga tahu sebaliknya: jika pemandu ditemui pada pin, ia bukan fakta bahawa mereka akan ditemui semasa membuat pesanan. Kadang-kadang mereka hilang atau semua orang menolak perintah itu.
Untuk menguji hipotesis ini, kami melancarkan percubaan: kami berhenti menyemak kehadiran kereta semasa carian pada Pin untuk kumpulan ujian pengguna, iaitu, mereka berpeluang membuat "pesanan tanpa kereta." Hasilnya agak tidak dijangka: jika kereta itu tiada pada pin, maka dalam 29% kes ia ditemui kemudian - apabila mencari pada pesanan! Selain itu, pesanan tanpa kereta tidak jauh berbeza daripada pesanan biasa dari segi kadar pembatalan, penilaian dan penunjuk kualiti yang lain. Tempahan tanpa kereta menyumbang 5% daripada semua tempahan, tetapi hanya lebih 1% daripada semua perjalanan yang berjaya.
Untuk memahami dari mana pelaksana pesanan ini datang, mari lihat status mereka semasa carian pada Pin:
- Tersedia: tersedia, tetapi atas sebab tertentu tidak termasuk dalam calon, sebagai contoh, dia terlalu jauh;
- Atas pesanan: sibuk, tetapi berjaya membebaskan dirinya atau menjadi tersedia untuk ;
- Sibuk: keupayaan untuk menerima pesanan telah dilumpuhkan, tetapi kemudian pemandu kembali ke talian;
- Tidak tersedia: pemandu tidak dalam talian, tetapi dia muncul.
Mari tambah kebolehpercayaan
Pesanan tambahan adalah hebat, tetapi 29% daripada carian yang berjaya bermakna 71% daripada masa pengguna menunggu lama dan akhirnya tidak ke mana-mana. Walaupun ini bukan perkara yang buruk dari sudut kecekapan sistem, ia sebenarnya memberikan harapan palsu kepada pengguna dan membuang masa, selepas itu mereka kecewa dan (mungkin) berhenti menggunakan perkhidmatan tersebut. Untuk menyelesaikan masalah ini, kami belajar untuk meramalkan kemungkinan kereta dalam pesanan akan ditemui.
Skimnya adalah seperti ini:
- Pengguna meletakkan pin.
- Pencarian dilakukan pada pin.
- Jika tiada kereta, kami meramalkan: mungkin ia akan muncul.
- Dan bergantung pada kebarangkalian, kami membenarkan atau tidak membenarkan anda membuat pesanan, tetapi kami memberi amaran kepada anda bahawa kepadatan kereta di kawasan ini pada masa ini adalah rendah.
Dalam aplikasi ia kelihatan seperti ini:
Menggunakan model membolehkan anda membuat pesanan baharu dengan lebih tepat dan tidak meyakinkan orang dengan sia-sia. Iaitu, untuk mengawal nisbah kebolehpercayaan dan bilangan pesanan tanpa mesin menggunakan model precision-recall. Kebolehpercayaan perkhidmatan mempengaruhi keinginan untuk terus menggunakan produk, iaitu pada akhirnya semuanya bergantung kepada bilangan perjalanan.
Sedikit tentang precision-recallSalah satu tugas asas dalam pembelajaran mesin ialah tugas pengelasan: memberikan objek kepada salah satu daripada dua kelas. Dalam kes ini, hasil algoritma pembelajaran mesin sering menjadi penilaian berangka keahlian dalam salah satu kelas, sebagai contoh, penilaian kebarangkalian. Walau bagaimanapun, tindakan yang dilakukan biasanya binari: jika kereta itu tersedia, maka kami akan membenarkan anda memesannya, dan jika tidak, maka kami tidak akan melakukannya. Untuk lebih spesifik, mari kita panggil algoritma yang menghasilkan anggaran berangka sebagai model dan pengelas peraturan yang menetapkannya kepada salah satu daripada dua kelas (1 atau β1). Untuk membuat pengelas berdasarkan penilaian model, anda perlu memilih ambang penilaian. Bagaimana sebenarnya bergantung pada tugas.
Katakan kita sedang melakukan ujian (pengelas) ββuntuk beberapa penyakit yang jarang berlaku dan berbahaya. Berdasarkan keputusan ujian, kami sama ada menghantar pesakit untuk pemeriksaan yang lebih terperinci, atau berkata: "Baik, pulang ke rumah." Bagi kami, menghantar orang sakit ke rumah adalah lebih teruk daripada memeriksa orang yang sihat secara sia-sia. Maksudnya, kami mahu ujian itu berkesan untuk seramai mungkin orang yang benar-benar sakit. Nilai ini dipanggil ingat =. Pengelas ideal mempunyai penarikan balik sebanyak 100%. Keadaan yang merosot adalah untuk menghantar semua orang untuk pemeriksaan, maka penarikan balik juga akan menjadi 100%.
Ia juga berlaku sebaliknya. Sebagai contoh, kami sedang membuat sistem ujian untuk pelajar, dan ia mempunyai pengesan penipuan. Jika tiba-tiba cek tidak berfungsi untuk beberapa kes penipuan, maka ini tidak menyenangkan, tetapi tidak kritikal. Sebaliknya, adalah amat buruk untuk menuduh pelajar secara tidak adil atas sesuatu yang tidak mereka lakukan. Iaitu, adalah penting bagi kita bahawa antara jawapan positif pengelas terdapat sebanyak mungkin yang betul, mungkin menjejaskan bilangannya. Ini bermakna anda perlu memaksimumkan ketepatan = . Jika pencetusan berlaku pada semua objek, maka ketepatan akan sama dengan kekerapan kelas yang ditentukan dalam sampel.
Jika algoritma menghasilkan nilai kebarangkalian berangka, maka dengan memilih ambang yang berbeza, anda boleh mencapai nilai ingatan ketepatan yang berbeza.
Dalam masalah kita keadaannya adalah seperti berikut. Ingat ialah bilangan pesanan yang boleh kami tawarkan, ketepatan adalah kebolehpercayaan pesanan ini. Beginilah rupa keluk ingat-ingat ketepatan model kami:
Terdapat dua kes yang melampau: jangan benarkan sesiapa sahaja untuk memesan dan benarkan semua orang untuk memesan. Jika anda tidak membenarkan sesiapa, maka ingat akan menjadi 0: kami tidak membuat pesanan, tetapi tiada satu pun daripada mereka akan gagal. Jika kami membenarkan semua orang, maka penarikan balik akan menjadi 100% (kami akan menerima semua pesanan yang mungkin), dan ketepatan akan menjadi 29%, iaitu 71% pesanan akan menjadi buruk.
Kami menggunakan pelbagai parameter titik permulaan sebagai tanda:
- Masa/tempat.
- Keadaan sistem (bilangan mesin yang diduduki bagi semua tarif dan pin di sekitar).
- Parameter carian (jejari, bilangan calon, sekatan).
Lebih lanjut mengenai tanda-tanda
Secara konsep, kami ingin membezakan antara dua situasi:
- "Hutan dalam" - tiada kereta di sini pada masa ini.
- "Malang" - ada kereta, tetapi ketika mencari tidak ada yang sesuai.
Salah satu contoh "Unlucky" adalah jika terdapat banyak permintaan di pusat pada petang Jumaat. Terdapat banyak pesanan, ramai orang bersedia, dan pemandu tidak mencukupi untuk semua orang. Ia mungkin menjadi seperti ini: tiada pemandu yang sesuai dalam pin. Tetapi secara literal dalam beberapa saat mereka muncul, kerana pada masa ini terdapat banyak pemandu di tempat ini dan status mereka sentiasa berubah.
Oleh itu, pelbagai penunjuk sistem di sekitar titik A ternyata menjadi ciri yang baik:
- Jumlah bilangan kereta.
- Bilangan kereta yang dipesan.
- Bilangan kereta tidak tersedia untuk pesanan dalam status "Sibuk".
- Bilangan pengguna.
Lagipun, semakin banyak kereta yang ada, semakin besar kemungkinan salah satu daripadanya akan tersedia.
Malah, adalah penting bagi kami bahawa bukan sahaja kereta terletak, tetapi juga perjalanan yang berjaya dibuat. Oleh itu, adalah mungkin untuk meramalkan kebarangkalian perjalanan yang berjaya. Tetapi kami memutuskan untuk tidak melakukan ini, kerana nilai ini sangat bergantung pada pengguna dan pemandu.
Algoritma latihan model ialah . Data yang diperoleh daripada eksperimen digunakan untuk latihan. Selepas pelaksanaan, data latihan perlu dikumpul, kadangkala membenarkan sebilangan kecil pengguna membuat pesanan terhadap keputusan model.
Keputusan
Keputusan percubaan adalah seperti yang dijangkakan: menggunakan model membolehkan anda meningkatkan dengan ketara bilangan perjalanan yang berjaya disebabkan oleh pesanan tanpa kereta, tetapi tanpa menjejaskan kebolehpercayaan.
Pada masa ini, mekanisme itu telah dilancarkan di semua bandar dan negara dan dengan bantuannya, kira-kira 1% daripada perjalanan yang berjaya berlaku. Lebih-lebih lagi, di beberapa bandar dengan kepadatan kereta yang rendah, bahagian perjalanan sedemikian mencapai 15%.
Siaran lain tentang teknologi Teksi
Sumber: www.habr.com