कोणतीही नसताना Yandex.Taxi कार कशा प्रकारे शोधते

चांगली टॅक्सी सेवा सुरक्षित, विश्वासार्ह आणि जलद असावी. वापरकर्ता तपशीलात जाणार नाही: त्याच्यासाठी हे महत्वाचे आहे की त्याने "ऑर्डर" बटणावर क्लिक केले आणि शक्य तितक्या लवकर एक कार प्राप्त केली जी त्याला पॉइंट A ते पॉइंट B पर्यंत घेऊन जाईल. जवळपास कोणतीही कार नसल्यास, सेवा करावी याबद्दल ताबडतोब माहिती द्या जेणेकरून क्लायंटच्या चुकीच्या अपेक्षा नसतील. परंतु जर "कार नाही" चिन्ह बर्‍याचदा दिसत असेल तर एखादी व्यक्ती ही सेवा वापरणे थांबवेल आणि प्रतिस्पर्ध्याकडे जाईल हे तर्कसंगत आहे.

या लेखात मला मशीन लर्निंगचा वापर करून, कमी-घनता असलेल्या भागात (दुसर्‍या शब्दात, जिथे पहिल्या दृष्टीक्षेपात, कार नाहीत) कार शोधण्याची समस्या कशी सोडवली याबद्दल मला बोलायचे आहे. आणि त्यातून काय आले.

prehistory

टॅक्सी कॉल करण्यासाठी, वापरकर्ता काही सोप्या चरणांचे पालन करतो, परंतु सेवेमध्ये काय होते?

वापरकर्ता	स्टेज	बॅकएंड Yandex.Taxi
प्रारंभ बिंदू निवडतो	पिन	आम्ही उमेदवारांसाठी एक सरलीकृत शोध सुरू करत आहोत - पिन शोध. सापडलेल्या ड्रायव्हर्सच्या आधारावर, आगमन वेळेचा अंदाज लावला जातो - पिनमध्ये ETA. दिलेल्या बिंदूवर वाढणारे गुणांक मोजले जाते.
गंतव्यस्थान, भाडे, आवश्यकता निवडते	ऑफर	आम्ही एक मार्ग तयार करतो आणि वाढत्या गुणांक लक्षात घेऊन सर्व दरांसाठी किंमतींची गणना करतो.
"टॅक्सी कॉल करा" बटण दाबा	ऑर्डर	आम्ही कारसाठी संपूर्ण शोध सुरू करतो. आम्ही सर्वात योग्य ड्रायव्हर निवडतो आणि त्याला ऑर्डर ऑफर करतो.

वर पिनमध्ये ETA, किंमत गणना и सर्वात योग्य ड्रायव्हर निवडणे आम्ही आधीच लिहिले आहे. आणि ही ड्रायव्हर्स शोधण्याबद्दलची कथा आहे. ऑर्डर तयार केल्यावर, शोध दोनदा होतो: पिनवर आणि ऑर्डरवर. ऑर्डरचा शोध दोन टप्प्यात होतो: उमेदवारांची भरती आणि रँकिंग. प्रथम, उपलब्ध उमेदवार ड्रायव्हर्स आढळतात जे रस्त्याच्या आलेखाच्या सर्वात जवळ आहेत. मग बोनस आणि फिल्टरिंग लागू केले जातात. उर्वरित उमेदवारांना रँक दिले जाते आणि विजेत्याला ऑर्डर ऑफर मिळते. जर तो सहमत असेल, तर त्याला ऑर्डरसाठी नियुक्त केले जाते आणि डिलिव्हरी पॉईंटवर जाते. जर त्याने नकार दिला तर पुढच्याकडे ऑफर येते. आणखी उमेदवार नसल्यास, शोध पुन्हा सुरू होईल. हे तीन मिनिटांपेक्षा जास्त काळ टिकत नाही, त्यानंतर ऑर्डर रद्द केली जाते आणि बर्न केली जाते.

पिनवर शोधणे हे ऑर्डरवर शोधण्यासारखेच आहे, फक्त ऑर्डर तयार होत नाही आणि शोध एकदाच केला जातो. उमेदवारांच्या संख्येसाठी सरलीकृत सेटिंग्ज आणि शोध त्रिज्या देखील वापरल्या जातात. अशी सरलीकरणे आवश्यक आहेत कारण ऑर्डरपेक्षा जास्त पिनचा क्रम आहे आणि शोध घेणे हे एक कठीण ऑपरेशन आहे. आमच्या कथेचा मुख्य मुद्दा: जर प्राथमिक शोधादरम्यान पिनवर योग्य उमेदवार सापडले नाहीत, तर आम्ही तुम्हाला ऑर्डर देण्याची परवानगी देत ​​नाही. निदान ते असेच असायचे.

वापरकर्त्याने अनुप्रयोगात हे पाहिले:

कारशिवाय कार शोधा

एके दिवशी आम्ही एक गृहीतक घेऊन आलो: कदाचित काही प्रकरणांमध्ये ऑर्डर अद्याप पूर्ण केली जाऊ शकते, जरी पिनवर कार नसल्या तरीही. तथापि, पिन आणि ऑर्डर दरम्यान काही वेळ जातो आणि ऑर्डरचा शोध अधिक पूर्ण होतो आणि कधीकधी अनेक वेळा पुनरावृत्ती होते: या काळात, उपलब्ध ड्रायव्हर्स दिसू शकतात. आम्हाला उलट देखील माहित होते: जर ड्रायव्हर्स पिनवर आढळले तर ते ऑर्डर करताना सापडतील हे तथ्य नाही. कधीकधी ते अदृश्य होतात किंवा प्रत्येकजण ऑर्डर नाकारतो.

या गृहीतकाची चाचणी घेण्यासाठी, आम्ही एक प्रयोग सुरू केला: आम्ही वापरकर्त्यांच्या चाचणी गटासाठी पिनवर शोध घेत असताना कारची उपलब्धता तपासणे थांबवले, म्हणजे, त्यांना "कारशिवाय ऑर्डर" करण्याची संधी मिळाली. परिणाम अगदी अनपेक्षित होता: जर कार पिनवर नसेल तर 29% प्रकरणांमध्ये ती नंतर सापडली - ऑर्डरवर शोधताना! शिवाय, कारशिवाय ऑर्डर रद्द करण्याचे दर, रेटिंग आणि इतर गुणवत्ता निर्देशकांच्या बाबतीत नियमित ऑर्डरपेक्षा लक्षणीय भिन्न नव्हते. सर्व बुकिंगपैकी 5% गाड्यांशिवाय बुकिंगचा वाटा होता, परंतु सर्व यशस्वी सहलींपैकी फक्त 1%.

या ऑर्डरची अंमलबजावणी करणारे कोठून आले आहेत हे समजून घेण्यासाठी, पिनवर शोध घेत असताना त्यांची स्थिती पाहू:

• उपलब्ध: उपलब्ध होते, परंतु काही कारणास्तव उमेदवारांमध्ये समाविष्ट केले गेले नाही, उदाहरणार्थ, तो खूप दूर होता;
• ऑर्डर वर: व्यस्त होता, परंतु स्वत: ला मुक्त करण्यात किंवा उपलब्ध होण्यात व्यवस्थापित केले साखळी क्रम;
• व्यस्त: ऑर्डर स्वीकारण्याची क्षमता अक्षम केली गेली, परंतु नंतर ड्रायव्हर लाइनवर परत आला;
• उपलब्ध नाही: ड्रायव्हर ऑनलाइन नव्हता, पण तो दिसला.

चला विश्वसनीयता जोडूया

अतिरिक्त ऑर्डर उत्तम आहेत, परंतु 29% यशस्वी शोधांचा अर्थ असा आहे की 71% वेळ वापरकर्त्याने बराच वेळ प्रतीक्षा केली आणि कुठेही गेले नाही. सिस्टम कार्यक्षमतेच्या दृष्टिकोनातून ही वाईट गोष्ट नसली तरी प्रत्यक्षात वापरकर्त्याला खोटी आशा देते आणि वेळ वाया जातो, त्यानंतर ते अस्वस्थ होतात आणि (शक्यतो) सेवा वापरणे थांबवतात. या समस्येचे निराकरण करण्यासाठी, आम्ही ऑर्डरवर कार सापडण्याची शक्यता वर्तवण्यास शिकलो.

योजना अशी आहे:

• वापरकर्ता पिन ठेवतो.
• पिनवर शोध घेतला जातो.
• जर कार नसतील तर आम्ही अंदाज लावतो: कदाचित त्या दिसतील.
• आणि संभाव्यतेवर अवलंबून, आम्ही तुम्हाला ऑर्डर देण्याची परवानगी देतो किंवा देत नाही, परंतु आम्ही तुम्हाला चेतावणी देतो की यावेळी या क्षेत्रातील कारची घनता कमी आहे.

अनुप्रयोगात ते असे दिसले:

मॉडेल वापरणे आपल्याला नवीन ऑर्डर अधिक अचूकपणे तयार करण्याची परवानगी देते आणि व्यर्थ लोकांना आश्वासन देत नाही. म्हणजेच, अचूक-आठवण मॉडेल वापरून विश्वासार्हतेचे गुणोत्तर आणि मशीनशिवाय ऑर्डरची संख्या नियंत्रित करणे. सेवेची विश्वासार्हता उत्पादन वापरणे सुरू ठेवण्याच्या इच्छेवर प्रभाव पाडते, म्हणजेच शेवटी हे सर्व ट्रिपच्या संख्येवर येते.

नेमकेपणाबद्दल थोडेसे-आठवणमशीन लर्निंगमधील मूलभूत कार्यांपैकी एक म्हणजे वर्गीकरण कार्य: दोनपैकी एका वर्गाला ऑब्जेक्ट नियुक्त करणे. या प्रकरणात, मशीन लर्निंग अल्गोरिदमचा परिणाम बहुतेकदा वर्गांपैकी एकामध्ये सदस्यत्वाचे संख्यात्मक मूल्यांकन बनतो, उदाहरणार्थ, संभाव्यता मूल्यांकन. तथापि, केल्या जाणार्‍या क्रिया सहसा बायनरी असतात: जर कार उपलब्ध असेल, तर आम्ही तुम्हाला ती ऑर्डर करू देऊ आणि नसल्यास, आम्ही करणार नाही. विशिष्ट होण्यासाठी, आपण एका अल्गोरिदमला कॉल करूया जो संख्यात्मक अंदाज तयार करतो एक मॉडेल, आणि एक वर्गीकरण करणारा एक नियम जो त्यास दोन वर्गांपैकी एकास नियुक्त करतो (1 किंवा –1). मॉडेल मूल्यांकनावर आधारित वर्गीकरण करण्यासाठी, तुम्हाला एक मूल्यांकन थ्रेशोल्ड निवडण्याची आवश्यकता आहे. नेमके कसे हे कार्यावर बरेच अवलंबून असते.

समजा आपण काही दुर्मिळ आणि धोकादायक आजारासाठी चाचणी (वर्गीकरण) करत आहोत. चाचणी परिणामांवर आधारित, आम्ही एकतर रुग्णाला अधिक तपशीलवार तपासणीसाठी पाठवतो किंवा म्हणतो: "चांगले, घरी जा." आमच्यासाठी, आजारी व्यक्तीला घरी पाठवणे हे निरोगी व्यक्तीची अनावश्यक तपासणी करण्यापेक्षा खूप वाईट आहे. म्हणजेच, चाचणी शक्य तितक्या खरोखर आजारी लोकांसाठी कार्य करू इच्छित आहे. या मूल्याला recall = म्हणतात. एक आदर्श वर्गीकरण 100% रिकॉल आहे. सगळ्यांना परीक्षेसाठी पाठवावे, तर रिकॉलही १००% होईल.

याच्या उलटही घडते. उदाहरणार्थ, आम्ही विद्यार्थ्यांसाठी एक चाचणी प्रणाली बनवत आहोत आणि त्यात फसवणूक करणारा शोधक आहे. फसवणूकीच्या काही प्रकरणांसाठी अचानक चेक कार्य करत नसल्यास, हे अप्रिय आहे, परंतु गंभीर नाही. दुसरीकडे, विद्यार्थ्यांनी जे केले नाही त्याबद्दल अन्यायकारकपणे आरोप करणे अत्यंत वाईट आहे. म्हणजेच, आमच्यासाठी हे महत्त्वाचे आहे की वर्गीकरणकर्त्याच्या सकारात्मक उत्तरांमध्ये शक्य तितक्या योग्य उत्तरे आहेत, कदाचित त्यांच्या संख्येस हानी पोहोचेल. याचा अर्थ असा की तुम्हाला जास्तीत जास्त अचूकता = . जर सर्व ऑब्जेक्ट्सवर ट्रिगरिंग होत असेल, तर अचूकता नमुन्यातील परिभाषित वर्गाच्या वारंवारतेइतकी असेल.

जर अल्गोरिदमने संख्यात्मक संभाव्यता मूल्य तयार केले, तर भिन्न थ्रेशोल्ड निवडून, तुम्ही भिन्न अचूक-आठवणी मूल्ये प्राप्त करू शकता.

आमच्या समस्येमध्ये परिस्थिती खालीलप्रमाणे आहे. रिकॉल म्हणजे आम्ही ऑफर करू शकणाऱ्या ऑर्डरची संख्या, अचूकता ही या ऑर्डरची विश्वासार्हता आहे. आमच्या मॉडेलचे प्रिसिजन-रिकॉल वक्र असे दिसते:

दोन टोकाची प्रकरणे आहेत: कोणालाही ऑर्डर करण्याची परवानगी देऊ नका आणि प्रत्येकाला ऑर्डर करण्याची परवानगी देऊ नका. जर तुम्ही कोणालाही परवानगी दिली नाही, तर रिकॉल 0 असेल: आम्ही ऑर्डर तयार करत नाही, परंतु त्यापैकी काहीही अपयशी ठरणार नाही. आम्ही प्रत्येकाला परवानगी दिल्यास, रिकॉल 100% असेल (आम्हाला सर्व संभाव्य ऑर्डर प्राप्त होतील), आणि अचूकता 29% असेल, म्हणजे 71% ऑर्डर खराब असतील.

आम्ही चिन्हे म्हणून प्रारंभ बिंदूचे विविध पॅरामीटर्स वापरले:

• वेळ/स्थळ.
• सिस्टम स्थिती (सर्व टॅरिफ आणि आसपासच्या पिनच्या व्यापलेल्या मशीनची संख्या).
• शोध पॅरामीटर्स (त्रिज्या, उमेदवारांची संख्या, निर्बंध).

चिन्हांबद्दल अधिक

वैचारिकदृष्ट्या, आम्ही दोन परिस्थितींमध्ये फरक करू इच्छितो:

• "खोल जंगल" - यावेळी येथे कोणत्याही कार नाहीत.
• "अशुभ" - तेथे कार आहेत, परंतु शोधत असताना तेथे कोणतेही योग्य नव्हते.

शुक्रवारी संध्याकाळी केंद्रात भरपूर मागणी असल्यास “अशुभ” चे एक उदाहरण आहे. तेथे भरपूर ऑर्डर आहेत, बरेच लोक इच्छुक आहेत आणि प्रत्येकासाठी पुरेसे ड्रायव्हर्स नाहीत. हे असे होऊ शकते: पिनमध्ये कोणतेही योग्य ड्रायव्हर्स नाहीत. परंतु अक्षरशः काही सेकंदात ते दिसतात, कारण यावेळी या ठिकाणी बरेच ड्रायव्हर्स आहेत आणि त्यांची स्थिती सतत बदलत आहे.

म्हणून, बिंदू A च्या परिसरातील विविध सिस्टम निर्देशक चांगली वैशिष्ट्ये असल्याचे दिसून आले:

• कारची एकूण संख्या.
• ऑर्डरवर असलेल्या कारची संख्या.
• "व्यस्त" स्थितीत ऑर्डर करण्यासाठी अनुपलब्ध कारची संख्या.
• वापरकर्त्यांची संख्या.

शेवटी, जितक्या जास्त कार आहेत, तितकीच त्यापैकी एक उपलब्ध होण्याची शक्यता जास्त आहे.
खरं तर, आमच्यासाठी हे महत्वाचे आहे की केवळ कारच नाही तर यशस्वी सहली देखील केल्या जातात. त्यामुळे यशस्वी सहलीच्या संभाव्यतेचा अंदाज बांधता आला. परंतु आम्ही हे न करण्याचा निर्णय घेतला, कारण हे मूल्य वापरकर्त्यावर आणि ड्रायव्हरवर अवलंबून असते.

मॉडेल प्रशिक्षण अल्गोरिदम होते कॅट बूस्ट. प्रयोगातून मिळालेला डेटा प्रशिक्षणासाठी वापरण्यात आला. अंमलबजावणीनंतर, प्रशिक्षण डेटा संकलित करणे आवश्यक होते, काहीवेळा मॉडेलच्या निर्णयाच्या विरोधात काही वापरकर्त्यांना ऑर्डर करण्याची परवानगी दिली.

परिणाम

प्रयोगाचे परिणाम अपेक्षेप्रमाणे होते: मॉडेल वापरणे आपल्याला कारशिवाय ऑर्डरमुळे यशस्वी ट्रिपची संख्या लक्षणीयरीत्या वाढविण्यास अनुमती देते, परंतु विश्वासार्हतेशी तडजोड न करता.

याक्षणी, यंत्रणा सर्व शहरे आणि देशांमध्ये सुरू केली गेली आहे आणि त्याच्या मदतीने, सुमारे 1% यशस्वी ट्रिप होतात. शिवाय, कारची कमी घनता असलेल्या काही शहरांमध्ये अशा सहलींचा वाटा 15% पर्यंत पोहोचतो.

टॅक्सी तंत्रज्ञान बद्दल इतर पोस्ट

• आम्ही Yandex.Taxi मधील ड्रायव्हर्समध्ये ऑर्डर कसे वितरित करतो
• डायनॅमिक किंमत, किंवा How Yandex.Taxi उच्च मागणीचा अंदाज लावते
• कारच्या स्थितीचे मूल्यांकन करण्यासाठी संगणक दृष्टी कशी वापरावी. Yandex.Taxi अनुभव
• Yandex.Taxi मशीन लर्निंग वापरून कार पिकअप वेळेचा अंदाज कसा लावते

स्त्रोत: www.habr.com