Harga dinamis, atau Bagaimana Yandex.Taxi memprediksi permintaan tinggi

Sebelumnya, untuk memanggil taksi, mereka harus memanggil nomor yang berbeda dari layanan pengiriman dan menunggu mobil dikirim selama setengah jam atau lebih. Sekarang layanan taksi diotomatisasi dengan baik, dan waktu rata-rata untuk pengiriman mobil Yandex.Taxi di Moskow adalah sekitar 3-4 menit. Tapi itu layak untuk turun hujan atau mengakhiri acara massal, dan sekali lagi kita mungkin mengalami kekurangan mobil gratis.

Nama saya Anton Skogorev, saya memimpin grup pengembangan kinerja platform Yandex.Taxi. Hari ini saya akan memberi tahu pembaca Habr bagaimana kami belajar memprediksi permintaan tinggi dan juga menarik pengemudi sehingga pengguna dapat menemukan mobil gratis kapan saja. Anda akan belajar bagaimana koefisien terbentuk yang mempengaruhi nilai pesanan. Segala sesuatu di sana jauh dari sesederhana yang mungkin tampak pada pandangan pertama.

Tantangan penetapan harga dinamis

Tugas terpenting dari penetapan harga dinamis adalah untuk selalu memberikan kesempatan untuk memesan taksi. Hal ini dicapai dengan menggunakan koefisien penetapan harga, dimana harga yang dihitung dikalikan. Kami menyebutnya hanya gelombang. Penting untuk mengatakan bahwa lonjakan tidak hanya mengatur permintaan taksi, tetapi juga membantu menarik pengemudi baru untuk meningkatkan pasokan.

Jika lonjakan ditetapkan terlalu besar, kami akan mengurangi permintaan terlalu banyak, akan ada kelebihan mobil gratis. Jika disetel terlalu rendah, pengguna akan melihat "tidak ada mobil gratis." Anda harus dapat memilih koefisien di mana kita akan berjalan di atas es tipis antara kurangnya mobil gratis dan permintaan rendah.

Apa yang harus bergantung pada koefisien ini? Segera terlintas dalam pikiran ketergantungan pada jumlah mobil dan pesanan di sekitar pengguna. Sekarang Anda dapat dengan mudah membagi jumlah pesanan dengan jumlah driver, dapatkan koefisien dan mengubahnya menjadi lonjakan kami dengan beberapa formula (mungkin linier).

Tetapi ada masalah kecil dalam tugas ini - mungkin sudah terlambat untuk menghitung pesanan di sekitar pengguna. Lagi pula, pesanan hampir selalu merupakan mesin yang sudah ditempati, yang berarti bahwa peningkatan koefisien kami akan selalu terlambat. Oleh karena itu, kami menganggap tidak membuat pesanan, tetapi niat untuk memesan pin. Pin adalah label "A" pada kartu yang diletakkan pengguna saat meluncurkan aplikasi kami.



Mari kita rumuskan masalahnya: kita perlu membaca nilai instan dari mesin dan pin di beberapa titik di pengguna.

Kami menghitung jumlah pin dan mobil di sekitar

Ketika posisi pin berubah (pengguna memilih titik "A"), aplikasi pengguna mengirimkan koordinat baru dan selembar kecil informasi tambahan ke backend, yang membantu mengevaluasi pin secara lebih akurat (misalnya, tarif yang dipilih).

Kami mencoba untuk mematuhi arsitektur microservice, di mana setiap microservice terlibat dalam tugas yang terpisah. Surger microservice terlibat dalam perhitungan lonjakan. Ini mendaftar pin, menyimpannya ke database, dan juga memperbarui nugget pin dalam RAM, di mana mereka cocok dengan cukup baik. Cache cache selama pekerjaan tersebut hanya beberapa detik, yang dapat diterima dalam kasus kami.


Cache panas dibuat dengan indeks geo-hash . Kami mengelompokkan semua pin berdasarkan geohash, dan kemudian mengumpulkan pin untuk radius yang diinginkan di sekitar titik pesanan.

Kami melakukan hal yang sama dengan mobil, tetapi dalam layanan lain yang disebut Tracker, yang mana Surger hanya pergi dengan pertanyaan "berapa banyak pengemudi dalam radius ini."

Jadi kami mempertimbangkan nilai koefisien instan.

Caching

Kasing : Anda berdiri di Garden Ring di Moskow dan ingin memesan mobil. Pada saat yang sama, harganya melonjak cukup sering dan ini menjengkelkan.

Sudah mengetahui mekanika, orang dapat memahami bahwa ini bisa disebabkan oleh fakta bahwa pengemudi menumpuk di lampu lalu lintas bersyarat pada saat permintaan lonjakan dan juga pergi dengan cepat. Karena itu, lonjakan dan harga terasa "melompat".

Untuk menghindari ini, kami menyimpan nilai lonjakan oleh pengguna. Ketika pengguna datang untuk lonjakan, kami melihat untuk melihat apakah ada nilai lonjakan yang disimpan untuk pengguna ini dalam radius yang dapat diterima (tur linear semua lonjakan yang disimpan pengguna). Jika ada, kami mengembalikannya, jika tidak, kami mengandalkan yang baru dan juga menyimpannya.

Ini bekerja dengan baik, tetapi ada situasi lain.

Kasus : 2 pengguna meminta lonjakan. Satu pesanan 30 detik lebih lambat dari yang lain ketika mobil-mobil dari lampu lalu lintas dari kasing lalu telah pergi. Kami mendapatkan gambar di mana 2 pengguna yang memesan hampir secara bersamaan dapat memiliki lonjakan yang sangat berbeda.

Dan di sini kita beralih dari cache oleh pengguna ke cache oleh posisi. Sekarang, alih-alih men-cache nilai lonjakan hanya oleh pengguna, kita mulai caching dengan geo-hash yang sudah kita ketahui. Jadi kami hampir memperbaiki masalahnya. Kenapa hampir? Karena mungkin ada perbedaan di perbatasan geoheshes. Tetapi masalahnya tidak begitu signifikan, karena kita memiliki perataan.

Menghaluskan

Mungkin, membaca sebuah kasus tentang lampu lalu lintas, terpikir oleh Anda bahwa entah bagaimana tidak adil untuk mempertimbangkan lonjakan instan, tergantung pada lampu lalu lintas. Kami juga berpikir begitu, jadi kami menemukan cara untuk memperbaiki situasi.

Kami memutuskan untuk meminjam metode tetangga terdekat dari pembelajaran mesin untuk masalah regresi untuk menentukan berapa nilai lonjakan instan berbeda dari apa yang terjadi di sekitar.

Tahap pelatihan, seperti dalam deskripsi formal metode, terdiri dalam menyimpan semua objek - dalam kasus kami, nilai-nilai terhitung dari lonjakan di pin, kami sudah melakukan semua ini pada saat memuat semua pin ke dalam cache. Hal kecil adalah menghitung nilai sesaat, membandingkannya dengan nilai di zona dan setuju bahwa kita tidak bisa menyimpang terlalu banyak dari nilai di zona.

Jadi kami mendapatkan sistem dengan respons cepat terhadap berbagai peristiwa dan memungkinkan Anda untuk dengan cepat membaca nilai dari koefisien yang meningkat.

Surge Driving Card

Untuk berkomunikasi dengan pengemudi, kita harus dapat menampilkan peta lonjakan pada aplikasi pengemudi - sebuah taksimeter. Ini memberikan umpan balik kepada pengemudi tentang apakah ada permintaan di daerah di mana dia sekarang dan di mana dia harus pindah untuk mendapatkan pesanan yang paling mahal. Bagi kami, ini berarti lebih banyak pengemudi akan datang ke zona dengan permintaan tinggi dan menyelesaikannya.



Kita hidup dengan paradigma bahwa perangkat pengemudi adalah perangkat yang agak lemah. Oleh karena itu, rendering dari grid heksagonal terletak di sisi backend. Klien datang ke backend untuk ubin. Ini adalah gambar raster yang dipotong untuk tampilan langsung pada peta.

Kami memiliki layanan terpisah yang secara berkala mengambil gips pin dari layanan microser Surger dan menghitung semua informasi meta yang diperlukan untuk merender kisi heksagonal: di mana hex dan lonjakan mana di masing-masing.

Kesimpulan

Harga dinamis adalah pencarian konstan untuk keseimbangan antara penawaran dan permintaan, sehingga pengguna selalu memiliki mobil gratis yang tersedia, termasuk melalui mekanisme menarik driver tambahan ke area permintaan tinggi. Misalnya, kami saat ini sedang mengerjakan penggunaan pembelajaran mesin yang lebih dalam untuk menghitung lonjakan. Dalam kerangka kerja salah satu tugas dari arah ini, kami belajar untuk menentukan probabilitas mengubah pin menjadi pesanan dan mempertimbangkan informasi ini. Ada cukup banyak pekerjaan di sini, jadi kami selalu senang dengan spesialis baru dalam tim.

Jika Anda tertarik untuk mempelajari bagian dari topik besar ini secara lebih terperinci, maka tulis di komentar. Umpan balik dan gagasan juga kami terima!

NB Dalam publikasi berikutnya , kolega saya akan berbicara tentang penggunaan pembelajaran mesin untuk memprediksi perkiraan waktu kedatangan taksi.