İyi bir taksi hizmeti güvenli, güvenilir ve hızlı olmalıdır. Kullanıcı ayrıntılara girmeyecektir: “Sipariş” butonuna tıklaması ve kendisini A noktasından B noktasına götürecek bir arabayı mümkün olduğu kadar çabuk alması onun için önemlidir. Yakınlarda araba yoksa, servisin Müşterinin yanlış beklentilere kapılmaması için derhal bu konuda bilgi verin. Ancak "Araba yok" işareti çok sık görünüyorsa, kişinin bu hizmeti kullanmayı bırakıp bir rakibe gitmesi mantıklıdır.
Bu yazıda, makine öğrenimini kullanarak düşük yoğunluklu alanlarda (başka bir deyişle ilk bakışta arabaların olmadığı yerlerde) araba arama sorununu nasıl çözdüğümüzden bahsetmek istiyorum. Ve bundan ne çıktı?
tarih öncesi
Kullanıcı taksi çağırmak için birkaç basit adımı gerçekleştiriyor ancak hizmetin içinde ne oluyor?
| Kullanıcı | evre | Arka uç Yandex.Taksi |
|---|---|---|
| Başlangıç noktasını seçer | pim | Adaylar için basitleştirilmiş bir arama başlatıyoruz - pin araması. Bulunan sürücülere göre varış zamanı tahmin edilir - pinte ETA. Belirli bir noktadaki artan katsayı hesaplanır. |
| Varış noktasını, ücreti ve gereksinimleri seçer | Teklif | Artan katsayıyı dikkate alarak bir rota oluşturuyoruz ve tüm tarifeler için fiyatları hesaplıyoruz. |
| “Taksi Çağır” butonuna basar | Заказ | Araba için tam bir arama başlatıyoruz. En uygun sürücüyü seçip siparişini veriyoruz. |
Hakkında , и zaten yazdık. Ve bu, sürücüleri bulmayla ilgili bir hikaye. Bir sipariş oluşturulduğunda arama iki kez gerçekleşir: Pinde ve siparişte. Sipariş arayışı iki aşamada gerçekleşir: adayların işe alınması ve sıralama. Öncelikle yol grafiğine en yakın olan mevcut aday sürücüler bulunur. Daha sonra bonuslar ve filtreleme uygulanır. Kalan adaylar sıralanır ve kazanana sipariş teklifi verilir. Kabul etmesi durumunda siparişe atanır ve teslimat noktasına gider. Reddederse teklif bir sonrakine gelir. Başka aday yoksa arama yeniden başlar. Bu, üç dakikadan fazla sürmez, ardından sipariş iptal edilir ve yakılır.
Pinde arama yapmak, siparişte aramaya benzer; yalnızca sipariş oluşturulmaz ve arama yalnızca bir kez gerçekleştirilir. Aday sayısı ve arama yarıçapı için basitleştirilmiş ayarlar da kullanılır. Bu tür basitleştirmeler gereklidir çünkü pin sayısı sipariş sayısından çok daha fazladır ve arama oldukça zor bir işlemdir. Hikayemizin kilit noktası: Ön arama sırasında Pinde uygun aday bulunamazsa, sipariş vermenize izin vermiyoruz. En azından eskiden böyleydi.
Kullanıcının uygulamada gördüğü şey şuydu:
Arabasız araba ara
Bir gün bir hipotez ortaya attık: Belki bazı durumlarda, pinte hiç araba olmasa bile sipariş hala tamamlanabiliyordu. Sonuçta, pin ile sipariş arasında bir süre geçiyor ve siparişin aranması daha eksiksiz oluyor ve bazen birkaç kez tekrarlanıyor: bu süre zarfında mevcut sürücüler görünebilir. Bunun tersini de biliyorduk: Eğer pin üzerinde sürücüler bulunuyorsa, sipariş verirken de bulunacakları bir gerçek değildi. Bazen ortadan kayboluyorlar ya da herkes emri reddediyor.
Bu hipotezi test etmek için bir deney başlattık: Bir test grubu kullanıcı için bir Pin üzerinde arama yaparken arabaların varlığını kontrol etmeyi bıraktık, yani "arabasız sipariş" verme fırsatına sahip oldular. Sonuç oldukça beklenmedikti: araba pin üzerinde değilse, vakaların% 29'unda daha sonra bulundu - siparişte arama yaparken! Üstelik araçsız siparişler, iptal oranları, puanlar ve diğer kalite göstergeleri açısından normal siparişlerden çok da farklı değildi. Araçsız rezervasyonlar tüm rezervasyonların %5'ini oluştururken, tüm başarılı seyahatlerin %1'inden biraz fazlasını oluşturdu.
Bu emirleri uygulayanların nereden geldiğini anlamak için bir Pin üzerinde arama yaparken durumlarına bakalım:
- Mevcut: müsaitti ama nedense adaylar arasında yer almıyordu, mesela çok uzaktaydı;
- Sipariş üzerine: meşguldü ama kendini serbest bırakmayı veya müsait olmayı başardı ;
- Meşgul: emir kabul etme yeteneği devre dışı bırakıldı, ancak sürücü hatta geri döndü;
- Müsait değil: sürücü çevrimiçi değildi ama ortaya çıktı.
Güvenilirlik katalım
Ek siparişler harikadır, ancak başarılı aramaların %29'u, zamanın %71'inin kullanıcının uzun süre beklediği ve hiçbir yere varamadığı anlamına gelir. Her ne kadar sistem verimliliği açısından bu kötü bir şey olmasa da aslında kullanıcıya yanlış umut veriyor ve zaman kaybına neden oluyor, sonrasında üzülüyor ve (muhtemelen) hizmeti kullanmayı bırakıyor. Bu sorunu çözmek için sipariş üzerine bir arabanın bulunma olasılığını tahmin etmeyi öğrendik.
Şema aşağıdaki gibidir:
- Kullanıcı bir pin koyar.
- Pin üzerinde bir arama gerçekleştirilir.
- Araba yoksa tahmin ediyoruz: belki ortaya çıkacaklar.
- Ve olasılığa göre sipariş vermenize izin verir veya vermiyoruz ancak bu dönemde bu bölgedeki araç yoğunluğunun düşük olduğu konusunda sizi uyarıyoruz.
Uygulamada şöyle görünüyordu:
Modeli kullanmak, yeni siparişleri daha doğru oluşturmanıza ve insanlara boşuna güven vermemenize olanak tanır. Yani, hassas geri çağırma modelini kullanarak güvenilirlik oranını ve makineler olmadan sipariş sayısını düzenlemek. Hizmetin güvenilirliği, ürünü kullanmaya devam etme isteğini etkiler, yani sonuçta her şey yolculuk sayısına bağlıdır.
Hassas hatırlama hakkında birazMakine öğrenimindeki temel görevlerden biri sınıflandırma görevidir: bir nesneyi iki sınıftan birine atamak. Bu durumda, makine öğrenimi algoritmasının sonucu genellikle sınıflardan birine üyeliğin sayısal bir değerlendirmesi, örneğin bir olasılık değerlendirmesi haline gelir. Ancak gerçekleştirilen eylemler genellikle ikili niteliktedir: Araç mevcutsa sipariş vermenize izin veririz, yoksa sipariş vermeyiz. Daha spesifik olmak gerekirse, sayısal bir tahmin üreten bir algoritmaya model, sınıflandırıcıya ise onu iki sınıftan birine (1 veya –1) atayan bir kural diyelim. Model değerlendirmesine dayalı bir sınıflandırıcı oluşturmak için bir değerlendirme eşiği seçmeniz gerekir. Tam olarak nasıl olacağı büyük ölçüde göreve bağlıdır.
Bazı nadir ve tehlikeli hastalıklar için bir test (sınıflandırıcı) yaptığımızı varsayalım. Test sonuçlarına göre ya hastayı daha detaylı muayeneye gönderiyoruz ya da “İyi, evine git” diyoruz. Bizim için hasta bir insanı evine göndermek, sağlıklı bir insanı gereksiz yere muayene etmekten çok daha kötü. Yani testin mümkün olduğunca çok sayıda gerçekten hasta insanda işe yaramasını istiyoruz. Bu değere geri çağırma denir =. İdeal bir sınıflandırıcının geri çağırma oranı %100'dür. Dejenere bir durum herkesi muayeneye göndermek, o zaman geri çağırma da %100 olacaktır.
Aynı zamanda bunun tersi de olur. Mesela öğrencilere yönelik bir sınav sistemi yapıyoruz, onun kopya dedektörü var. Bazı hile vakalarında aniden kontrol işe yaramazsa, bu hoş olmayan bir durumdur, ancak kritik değildir. Öte yandan öğrencileri yapmadıkları bir şeyle ilgili haksız yere suçlamak son derece kötüdür. Yani, sınıflandırıcının olumlu cevapları arasında, belki de sayılarının zararına olacak şekilde, mümkün olduğu kadar çok doğru cevabın bulunması bizim için önemlidir. Bu, hassasiyeti en üst düzeye çıkarmanız gerektiği anlamına gelir = . Tetikleme tüm nesnelerde meydana gelirse hassasiyet, örnekte tanımlanan sınıfın frekansına eşit olacaktır.
Algoritma sayısal bir olasılık değeri üretiyorsa, farklı eşikler seçerek farklı hassaslık-geri çağırma değerleri elde edebilirsiniz.
Bizim problemimizde durum şu şekildedir. Geri çağırma sunabileceğimiz siparişlerin sayısıdır, hassasiyet ise bu siparişlerin güvenilirliğidir. Modelimizin kesinlik-geri çağırma eğrisi şöyle görünür:
İki uç durum vardır: Kimsenin sipariş vermesine izin vermeyin ve herkesin sipariş vermesine izin verin. Kimseye izin vermezseniz geri çağırma 0 olacaktır: sipariş oluşturmuyoruz ama hiçbiri başarısız olmayacak. Herkese izin verirsek, geri çağırma %100 olacaktır (olası tüm siparişleri alacağız) ve kesinlik %29 olacaktır, yani siparişlerin %71'i hatalı olacaktır.
Başlangıç noktasının çeşitli parametrelerini işaret olarak kullandık:
- Zaman yeri.
- Sistem durumu (tüm tarifelerdeki ve civardaki pinlerdeki meşgul makinelerin sayısı).
- Arama parametreleri (yarıçap, aday sayısı, kısıtlamalar).
İşaretler hakkında daha fazla bilgi
Kavramsal olarak iki durumu birbirinden ayırmak istiyoruz:
- “Derin orman” - şu anda burada araba yok.
- "Şanssız" - arabalar var, ancak arama yaparken uygun olanı bulamadık.
Cuma akşamı merkezde çok fazla talep olması "Şanssızlığa" bir örnektir. Çok fazla sipariş var, istekli çok sayıda insan var ve herkese yetecek kadar sürücü yok. Şöyle ortaya çıkabilir: Pimde uygun sürücü yok. Ancak kelimenin tam anlamıyla saniyeler içinde ortaya çıkıyorlar, çünkü şu anda burada çok sayıda sürücü var ve onların durumları sürekli değişiyor.
Bu nedenle, A noktasının yakınındaki çeşitli sistem göstergelerinin iyi özellikler olduğu ortaya çıktı:
- Toplam araba sayısı.
- Sipariş edilen araba sayısı.
- "Meşgul" durumunda sipariş verilemeyen araba sayısı.
- Kullanıcı sayısı.
Sonuçta, ne kadar çok araba olursa, bunlardan birinin piyasaya çıkma olasılığı da o kadar yüksek olur.
Aslında sadece arabaların konumlandırılması değil, başarılı yolculukların yapılması da bizim için önemli. Bu nedenle başarılı bir yolculuğun olasılığını tahmin etmek mümkün oldu. Ancak bunu yapmamaya karar verdik çünkü bu değer büyük ölçüde kullanıcıya ve sürücüye bağlıdır.
Model eğitim algoritması . Deneyden elde edilen veriler eğitim amaçlı kullanıldı. Uygulamadan sonra, bazen az sayıda kullanıcının modelin kararına karşı sipariş vermesine izin vererek eğitim verilerinin toplanması gerekiyordu.
sonuçlar
Deneyin sonuçları beklendiği gibiydi: Modeli kullanmak, arabasız siparişler nedeniyle başarılı yolculukların sayısını önemli ölçüde artırmanıza olanak tanır, ancak güvenilirlikten ödün vermeden.
Şu anda mekanizma tüm şehirlerde ve ülkelerde başlatıldı ve onun yardımıyla başarılı yolculukların yaklaşık% 1'i gerçekleşiyor. Üstelik araç yoğunluğunun düşük olduğu bazı şehirlerde bu tür yolculukların payı %15'e ulaşıyor.
Taksi teknolojisi hakkındaki diğer yazılar
Kaynak: habr.com