🏫 🐴 🤹🏿 गतिशील मूल्य निर्धारण, या कैसे Yandex.Taxi उच्च मांग की भविष्यवाणी करता है 🎧 👦🏼 👴🏻

पहले, एक टैक्सी को कॉल करने के लिए, उन्हें विभिन्न प्रेषण सेवाओं को कॉल करना था और कार के आधे घंटे या अधिक समय तक वितरित होने की प्रतीक्षा करनी थी। अब टैक्सी सेवाएं अच्छी तरह से स्वचालित हैं, और मास्को में Yandex.Taxi कार की डिलीवरी का औसत समय लगभग 3-4 मिनट है। लेकिन एक सामूहिक घटना को बारिश या समाप्त करने के लिए इसके लायक है, और फिर से हम मुफ्त कारों की कमी में भाग सकते हैं।

मेरा नाम एंटोन स्कोगोरेव है, मैं Yandex.Taxi मंच प्रदर्शन विकास समूह का प्रमुख हूं। आज मैं Habr के पाठकों को बताऊंगा कि कैसे हमने उच्च मांग की भविष्यवाणी करना सीखा और इसके अलावा ड्राइवरों को आकर्षित किया ताकि उपयोगकर्ता किसी भी समय एक मुफ्त कार पा सकें। आप सीखेंगे कि एक गुणांक कैसे बनता है जो आदेश के मूल्य को प्रभावित करता है। वहाँ सब कुछ के रूप में सरल रूप में यह पहली नज़र में लग सकता है से दूर है।

गतिशील मूल्य निर्धारण चुनौती

गतिशील मूल्य निर्धारण का सबसे महत्वपूर्ण कार्य हमेशा टैक्सी ऑर्डर करने का अवसर प्रदान करना है। यह सर्ज प्राइसिंग गुणांक का उपयोग करके प्राप्त किया जाता है, जिसके द्वारा गणना की गई कीमत को गुणा किया जाता है। हम इसे बस वृद्धि कहते हैं। यह कहना महत्वपूर्ण है कि वृद्धि न केवल टैक्सियों की मांग को नियंत्रित करती है, बल्कि नए ड्राइवरों को आपूर्ति बढ़ाने में भी मदद करती है।

यदि वृद्धि बहुत बड़ी है, तो हम मांग को बहुत कम कर देंगे, मुफ्त कारों की अधिकता होगी। यदि बहुत कम सेट किया जाता है, तो उपयोगकर्ता "कोई निःशुल्क कार नहीं" देखेंगे। आपको एक गुणांक चुनने में सक्षम होने की आवश्यकता है जिस पर हम मुफ्त कारों की कमी और कम मांग के बीच पतली बर्फ पर चलेंगे।

यह गुणांक किस पर निर्भर होना चाहिए? यह तुरंत उपयोगकर्ता के आसपास कारों और ऑर्डर की संख्या पर निर्भरता को ध्यान में रखता है। अब आप बस ड्राइवरों की संख्या से आदेशों की संख्या को विभाजित कर सकते हैं, गुणांक प्राप्त कर सकते हैं और इसे कुछ सूत्र (संभवतः रैखिक) के साथ हमारे उछाल में बदल सकते हैं।

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

आइए समस्या को तैयार करते हैं: हमें उपयोगकर्ता के किसी बिंदु पर मशीनों और पिनों के तात्कालिक मूल्यों को पढ़ने की आवश्यकता है।

हम चारों ओर पिन और कारों की संख्या की गणना करते हैं

जब पिन की स्थिति बदलती है (उपयोगकर्ता बिंदु "ए" का चयन करता है), तो उपयोगकर्ता एप्लिकेशन नए निर्देशांक और अतिरिक्त जानकारी की एक छोटी शीट बैकएंड पर भेजता है, जो पिन को अधिक सटीक रूप से मूल्यांकन करने में मदद करता है (उदाहरण के लिए, चयनित टैरिफ)।

हम microservice वास्तुकला का पालन करने की कोशिश करते हैं, जहां प्रत्येक microservice अलग कार्यों में लगी हुई है। सर्जर माइक्रोसिस्टम सर्ज की गणना में लगा हुआ है। यह पिनों को पंजीकृत करता है, उन्हें डेटाबेस में सहेजता है, और रैम में पिनों की डली को भी अद्यतन करता है, जिसमें वे बहुत अच्छी तरह से फिट होते हैं। ऐसे काम के दौरान कैश अंतराल केवल कुछ सेकंड है, जो हमारे मामले में स्वीकार्य है।

डेटाबेस के बारे में कुछ शब्द

पंजीकरण करते समय, प्रत्येक पिन को TTL इंडेक्स के साथ MongoDb में अतुल्य रूप से जोड़ा जाता है, जहां TTL पिन का "आजीवन" होता है, जिस पर हम इसे बढ़ाने वाले गुणांक की गणना के लिए सक्रिय मानते हैं। जब हम इन क्रियाओं को करते हैं तो उपयोगकर्ता प्रतीक्षा नहीं करता है। भले ही कुछ गलत हो जाए, लेकिन पिन खोना इतनी बड़ी त्रासदी नहीं है।

एक गर्म कैश भू-हैश सूचकांक के साथ बनाया गया है। हम जियोश द्वारा सभी पिनों को समूहीकृत करते हैं, और फिर आदेश बिंदु के चारों ओर वांछित त्रिज्या के लिए पिन एकत्र करते हैं।

हम कारों के साथ भी ऐसा ही करते हैं, लेकिन ट्रैकर नामक एक अन्य सेवा में, जिसमें सर्जर बस इस सवाल के साथ जाता है कि "इस दायरे में कितने ड्राइवर हैं।"

तो हम गुणांक के तात्कालिक मूल्यों पर विचार करते हैं।

कैशिंग

मामला : आप मास्को में गार्डन रिंग में खड़े हैं और कार बुक करना चाहते हैं। इसी समय, कीमत बहुत बार उछलती है और यह कष्टप्रद है।

पहले से ही यांत्रिकी जानने वाले, यह समझ सकते हैं कि यह इस तथ्य के कारण हो सकता है कि ड्राइवर सर्ज के अनुरोध के समय सशर्त ट्रैफिक लाइट में जमा होते हैं और जल्दी से निकल जाते हैं। इस वजह से, वृद्धि और मूल्य काफ़ी हद तक "कूद" सकते हैं।

इससे बचने के लिए, हम उपयोगकर्ता द्वारा वृद्धि के मूल्य को कैश करते हैं। जब कोई उपयोगकर्ता वृद्धि के लिए आता है, तो हम यह देखते हैं कि क्या इस उपयोगकर्ता के लिए एक स्वीकार्य त्रिज्या (उपयोगकर्ता के सभी सहेजे गए सर्जेस का एक रैखिक दौरा) में बचाया गया मूल्य है। अगर वहाँ है, तो हम इसे वापस दे देते हैं, अन्यथा हम एक नए पर भरोसा कर रहे हैं और इसे भी बचा रहे हैं।

यह अच्छी तरह से काम किया, लेकिन अन्य स्थितियां हैं।

केस : 2 उपयोगकर्ता वृद्धि का अनुरोध करते हैं। एक के 30 सेकंड बाद के आदेश की तुलना में जब एक पिछले मामले से एक ट्रैफिक लाइट से कारें पहले ही निकल चुकी हैं। हमें एक तस्वीर मिलती है जहां 2 उपयोगकर्ता लगभग एक साथ ऑर्डर करते हैं, जिसमें अलग-अलग वृद्धि हो सकती है।

और यहाँ हम स्थिति से उपयोगकर्ता द्वारा कैश से कैश पर जाते हैं। अब, केवल उपयोगकर्ता द्वारा वृद्धि मूल्य को कैशिंग करने के बजाय, हम इसे भू-हैश द्वारा कैशिंग करना शुरू करते हैं जिसे हम पहले से जानते हैं। तो हम समस्या को लगभग ठीक कर देते हैं। लगभग क्यों? क्योंकि जियोहेस की सीमाओं पर मतभेद हो सकते हैं। लेकिन समस्या इतनी महत्वपूर्ण नहीं है, क्योंकि हमारे पास चौरसाई है।

चौरसाई

शायद, ट्रैफिक लाइट के बारे में एक मामले को पढ़ते हुए, यह आपके साथ हुआ कि ट्रैफिक लाइट के आधार पर तत्काल उछाल पर विचार करना किसी तरह अनुचित था। हम भी ऐसा सोचते हैं, इसलिए हमने सोचा कि स्थिति को कैसे ठीक किया जाए।

हमने यह निर्धारित करने के लिए कि क्या आसपास हो रहा है, तत्काल उछाल का मूल्य कितना है, यह निर्धारित करने के लिए मशीन सीखने से निकटतम पड़ोसियों की विधि को उधार लेने का फैसला किया।

प्रशिक्षण चरण, विधि के औपचारिक विवरण के रूप में, सभी वस्तुओं को संग्रहीत करने में शामिल हैं - हमारे मामले में, पिन में वृद्धि की गणना मूल्यों, हम पहले से ही सभी पिनों को कैश में लोड करने के समय यह सब करते हैं। छोटी सी बात तात्कालिक मूल्य की गणना करने के लिए है, इसे ज़ोन में मान के साथ तुलना करें और सहमत हैं कि हम ज़ोन में मूल्य से बहुत अधिक विचलन नहीं कर सकते हैं।

इसलिए हमें घटनाओं पर त्वरित प्रतिक्रिया के साथ एक प्रणाली मिलती है और आपको बढ़ते गुणांक के मूल्य को जल्दी से पढ़ने की अनुमति मिलती है।

सर्ज ड्राइविंग कार्ड

ड्राइवर के साथ संवाद करने के लिए, हमें ड्राइवर के अनुप्रयोग में एक करिमीटर - वृद्धि मानचित्र को प्रदर्शित करने में सक्षम होना चाहिए। यह ड्राइवर को यह प्रतिक्रिया देता है कि क्या उस क्षेत्र में मांग है जहां वह अब है और जहां उसे सबसे महंगे ऑर्डर प्राप्त करने के लिए स्थानांतरित करना चाहिए। हमारे लिए, इसका मतलब है कि अधिक चालक उच्च मांग के साथ क्षेत्र में आएंगे और इसे सुलझाएंगे।

हम प्रतिमान के साथ रहते हैं कि ड्राइवर का उपकरण एक कमजोर डिवाइस है। इसलिए, उछाल के हेक्सागोनल ग्रिड का प्रतिपादन बैकएंड की तरफ है। ग्राहक टाइल के लिए बैकेंड में आता है। ये नक्शे पर प्रत्यक्ष प्रदर्शन के लिए रेखापुंज चित्र काट रहे हैं।

हमारे पास एक अलग सेवा है जो समय-समय पर सर्जोस माइक्रोसर्विस से पिंस के कास्ट को उठाती है और हेक्सागोनल ग्रिड के प्रतिपादन के लिए आवश्यक सभी मेटा-जानकारी की गणना करती है: हेक्स कौन है और प्रत्येक में कौन सा उछाल है।

निष्कर्ष

गतिशील मूल्य निर्धारण आपूर्ति और मांग के बीच संतुलन के लिए एक निरंतर खोज है, ताकि उपयोगकर्ताओं को हमेशा मुफ्त कारें उपलब्ध हों, जिनमें उच्च मांग वाले क्षेत्रों में अतिरिक्त ड्राइवरों को आकर्षित करने के तंत्र के माध्यम से भी शामिल है। उदाहरण के लिए, हम वर्तमान में वृद्धि की गणना के लिए मशीन लर्निंग के गहन उपयोग पर काम कर रहे हैं। इस दिशा के कार्यों में से एक के ढांचे के भीतर, हम एक पिन को एक आदेश में परिवर्तित करने की संभावना निर्धारित करने और इस जानकारी को ध्यान में रखना सीख रहे हैं। यहां पर्याप्त काम है, इसलिए हम हमेशा टीम में नए विशेषज्ञों के लिए खुश हैं।

यदि आप इस बड़े विषय के एक हिस्से के बारे में अधिक विस्तार से जानने में रुचि रखते हैं, तो टिप्पणियों में लिखें। प्रतिक्रिया और विचारों का भी स्वागत है!

PS अगले प्रकाशन में, मेरा सहयोगी एक टैक्सी के अपेक्षित आगमन के समय की भविष्यवाणी करने के लिए मशीन लर्निंग के उपयोग के बारे में बात करेगा।