एक दिन में एक एमएल प्रोटोटाइप कैसे लॉन्च किया जाए। रिपोर्ट Yandex.Taxi

मशीन लर्निंग का उपयोग पूरे यैंडेक्स में किया जाता है। टेक्सी कार ऑर्डरिंग चक्र, और एमएल के लिए काम करने वाले सेवा घटकों की संख्या लगातार बढ़ रही है। उन्हें एक समान तरीके से बनाने के लिए, हमें एक अलग प्रक्रिया की आवश्यकता थी। रोमन खलकेव, मशीन लर्निंग एंड डेटा एनालिसिस सर्विस के प्रमुख ने डेटा प्रीप्रोसेसिंग, प्रोडक्शन में मॉडल्स के इस्तेमाल, प्रोटोटाइपिंग सर्विस और संबंधित टूल्स के बारे में बताया।


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

आइए समस्या का सूत्रीकरण करते हैं। ऐसे टैक्सी उपयोगकर्ता हैं जिन्हें पॉइंट ए से पॉइंट बी तक जाने की आवश्यकता है, और ऐसे ड्राइवर हैं जो पॉइंट ए से पॉइंट बी तक इन उपयोगकर्ताओं को वितरित करने के लिए एक निश्चित राशि के लिए तैयार हैं। उपयोगकर्ता के पास कई शर्तें हैं जिनमें वह है। वह एक टैक्सी बुलाता है, बिंदु A, बिंदु B, किराया इत्यादि का चयन करता है, एक टैक्सी लैंडिंग करता है, सवारी करता है, और अंत में एक लैंडिंग बनाता है। आज मैं एक कार और समस्याओं के बारे में बात करना चाहूंगा जो उत्पन्न हो सकती हैं।



एक नियम के रूप में, ये समस्याएं इस तथ्य से जुड़ी हुई हैं कि किसी व्यक्ति को एक जगह चुनने की आवश्यकता है जहां एक टैक्सी आना चाहिए। और यहां कई तरह की मुश्किलें हैं। ये कठिनाइयाँ उन चार चीजों से संबंधित हैं जिन्हें मैंने स्लाइड पर सूचीबद्ध किया है।



सबसे पहले, स्थान उपयोगकर्ता से परिचित नहीं हो सकता है। एक उदाहरण के रूप में, आप अपने आप को कल्पना कर सकते हैं जो किसी बड़े शॉपिंग सेंटर में आया था, जिसमें आप अक्सर नहीं जाते हैं। आप छोड़ना चाहते हैं, और आप वास्तव में यह नहीं जानते हैं कि आप यहां एक टैक्सी को कॉल कर सकते हैं, जहां कार कॉल कर सकते हैं, लेकिन जहां यह, उदाहरण के लिए, बाधा के कारण नहीं हो सकता है। इस तथ्य के साथ समस्याएं हैं कि कुछ जगहों पर बहुत सारे लोग हैं, बहुत सारी कारें हैं और आपके लिए अपनी कार को ढूंढना मुश्किल है। ऐसी जगहें हैं जहाँ आमतौर पर लोग कार में बैठते हैं, वहाँ जाना आसान है। और आपको पता नहीं हो सकता है, कुछ नई जगह पर होना, जरूरी नहीं कि शॉपिंग सेंटर में, जहां वास्तव में उतरना है। कठिनाइयों को इस तथ्य से जोड़ा जा सकता है कि ड्राइवर उस स्थान पर नहीं जा सकता है जहां आप टैक्सी कहते हैं: उसे यात्रा करने से मना किया गया है, शॉपिंग सेंटर से कुछ बड़ा निकास है, जिसके विपरीत आप रोक नहीं सकते हैं, आदि।

दूसरी ओर, आपको एक उपयोगकर्ता के रूप में समस्याएं हो सकती हैं। ड्राइवर आ गया, सब कुछ ठीक है, लेकिन आप नीचे बैठने के लिए असहज हैं, क्योंकि हर कोई खोदता है। आप ड्राइवर को कहीं और गाड़ी चलाने के लिए कहते हैं। अन्य कारण हैं।

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



समाधान स्लाइड के शीर्षक से पढ़ा जाता है। हमें उपयोगकर्ता को कुछ स्थानों पर अनुशंसा करते हैं जिसमें, हमारी राय में, यह जमीन पर सुविधाजनक है। सोचा स्पष्ट लगता है, लेकिन यहां कई बारीकियां हैं।

शुरुआत के लिए, "सुविधाजनक" एक व्यक्तिपरक अवधारणा है। ऐसा लगता है कि समस्या को हल करने से पहले, इस तथ्य के लिए कुछ मानदंड तैयार करना आवश्यक है कि समस्या को सही ढंग से हल किया जाएगा। हमने अपने लिए तीन मुख्य सूत्र तैयार किए हैं। पहला मानदंड सिफारिशों के किसी भी कार्य में है: शायद, सिफारिशें अच्छी हैं यदि उनका उपयोग किया जाता है। यदि हम ऐसे बिंदु दिखाते हैं जिससे उपयोगकर्ता वास्तव में छोड़ देगा - ये संभवतः अच्छे बिंदु हैं। लेकिन यह, ज़ाहिर है, यह सब नहीं है, क्योंकि आप कुछ सुझा सकते हैं, इसे दिखा सकते हैं, उपयोगकर्ता को इसका उपयोग करने के लिए प्रोत्साहित कर सकते हैं, लेकिन आपको कोई ठोस लाभ नहीं मिल सकता है (हम एक प्रणाली के रूप में नहीं मिलेंगे, न ही एक उपयोगकर्ता, और न ही एक ड्राइवर)। इसलिए, अन्य मैट्रिक्स को देखना बहुत महत्वपूर्ण है। हमने दो को चुना है।

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

यहाँ कुछ और उदाहरण दिए गए हैं। यह यात्रा से पहले रद्दीकरण का अनुपात हो सकता है। सिद्धांत रूप में, यह घटाना चाहिए यदि उपयोगकर्ता के लिए उतरना आसान हो। परंपरागत रूप से, ये कॉल तब होते हैं जब कोई उपयोगकर्ता ड्राइवर को उसे खोजने की कोशिश करता है, या, इसके विपरीत, ड्राइवर यात्रा शुरू होने से पहले उपयोगकर्ता को कॉल करता है। यह अपील समर्थन में है, और एक दर्जन अन्य लोगों के साथ है।

हमने समस्या तैयार की है। हमने लगभग इस कसौटी को समझा कि हम इस समस्या को हल कर सकते हैं। आइए अब इस समस्या को हल करने के बारे में सोचें। पहली बात जो ध्यान में आती है: आइए ऐसे किसी भी सिद्ध और समझने योग्य लैंडिंग बिंदुओं की अनुशंसा करें। यहां स्लाइड पर यूरोपीय शॉपिंग सेंटर का एक उदाहरण है। और हम यह सुनिश्चित करने के लिए जानते हैं कि आप इस शॉपिंग सेंटर से निकास के लिए ड्राइव कर सकते हैं, और यह किसी प्रकार का दिशानिर्देश है, जिसके लिए उपयोगकर्ता एक ड्राइवर ढूंढ सकता है। यह कोई भी संगठन हो सकता है। कुछ शॉपिंग सेंटर में स्वाद के एबीसी के साथ एक उदाहरण है। मेरी राय में, यह येरेवन प्लाजा है। यह उपयोगकर्ता और ड्राइवर के लिए किसी प्रकार का दिशानिर्देश भी है, जिसके बारे में हम जानते हैं कि आप वहां ड्राइव कर सकते हैं।



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

मशीन लर्निंग को किसी प्रकार के डेटा की आवश्यकता होती है, और हमारे पास वास्तव में वह डेटा है। इस डेटा का उपयोग करने के लिए समस्या को स्वचालित रूप से हल करने का एक और तरीका है। उच्च-स्तरीय विचार यह है कि हमारे पास जीपीएस, एप्लिकेशन लॉग के बारे में डेटा है, और एक रोड ग्राफ है। और हम समझ सकते हैं कि उपयोगकर्ता वास्तव में कार में कहां जाते हैं। उन बिंदुओं पर नहीं जहां वे कार को बुलाते हैं, लेकिन जहां वे उतरते हैं। और इसी के आधार पर कुछ ऐसा करें।



ये पहले से ही ऑरोरा व्यापार केंद्र के लिए स्वचालित रूप से प्राप्त अंक हैं, जहां हमारी यैंडेक्स। टेक्सी टीम वर्तमान में बैठी है।

मैंने हमारे कार्य के बारे में उच्च स्तर पर बात की। अब इस बारे में अधिक विस्तार से बात करते हैं कि इस समस्या का समाधान किन चरणों में है। यह स्पष्ट है कि डेटा तैयार करने का एक चरण है।



हमारे पास क्या डेटा है? सबसे पहले, हमारे पास हमारे उपयोगकर्ताओं का जीपीएस डेटा और हमारे ड्राइवरों का जीपीएस डेटा है। जब वे हमारे आवेदन का उपयोग करते हैं, तो हम उपयोगकर्ताओं के अनुमानित स्थान को जानते हैं। यह स्पष्ट है कि 13-15 मीटर के क्षेत्र में जीपीएस की एक बड़ी त्रुटि है, लेकिन फिर भी, कुछ है। दूसरे, हमारे पास ऐसी जानकारी है जो उस एप्लिकेशन लॉग में निहित है जब ड्राइवर ने स्थिति से स्विच किया "मैं उपयोगकर्ता की प्रतीक्षा कर रहा हूं" स्थिति "मैं उपयोगकर्ता ले रहा हूं"। यह माना जा सकता है कि इस समय ड्राइवर ने उपयोगकर्ता का इंतजार किया, उपयोगकर्ता कार में चढ़ गया, और उन्होंने उसे छोड़ दिया। इस जगह के आसपास, एक लैंडिंग बनाई गई थी। और हमारे पास एक रोड ग्राफ है। एक रोड ग्राफ न केवल किनारों, सड़कों का एक सेट है, बल्कि अतिरिक्त मेटा-जानकारी भी है: बाधाएं, पार्किंग के बारे में जानकारी आदि। इस डेटा के आधार पर, आप पहले से ही कुछ प्रकार के स्वचालित अंक प्राप्त कर सकते हैं।

यह स्रोत डेटा था। और बाहर निकलने पर, हम दो चीजें चाहते हैं। ये कुछ तथाकथित लैंडिंग बिंदु वाले उम्मीदवार हैं। वे कैसे आते हैं? यह अफ़सोस की बात है कि वीडियो दिखाना संभव नहीं था। निम्नलिखित लगभग होता है। हमारे पास कई जीपीएस बिंदु हैं, जिसमें हम जानते हैं कि ड्राइवर ने "यात्री की प्रतीक्षा कर रहा है" की स्थिति से "चलो चलते हैं" की स्थिति में स्विच किया है। हम सशर्त रूप से, उन्हें ग्राफ़ में खींच सकते हैं, अर्थात्, उन्हें रोड ग्राफ़ पर प्रोजेक्ट कर सकते हैं, क्योंकि, एक नियम के रूप में, कार कुछ सड़क से बढ़ना शुरू कर देती है। इस ग्राफ पर, इन बिंदुओं की किसी प्रकार की क्लस्टरिंग करें। और बड़ी संख्या में उम्मीदवारों को प्राप्त करने के लिए - ये ऐसे स्थान हैं जिनमें कुछ उपयोगकर्ता कार में चढ़े, और यह सामान्य था, उनके लिए सुविधाजनक था। न कि उन्होंने कहाँ बुलाया, लेकिन जहाँ वे बैठे थे।

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



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



डेटा तैयार करने में हम कौन से टूल का उपयोग करते हैं? मूल रूप से, पायथन स्टेक पर हमने पायथन में लिखी गई सभी डेटा तैयारी: ये मानक NumPy, Pandas, Scikit-learn आदि हैं। हमारे पास बहुत अधिक डेटा है। हमारे पास प्रति माह लाखों यात्राएँ हैं। जीपीएस के बारे में बहुत सारे डेटा, ड्राइवरों के ट्रैक के बारे में, एप्लिकेशन लॉग, इसलिए हमें क्लस्टर पर उन सभी को संसाधित करने की आवश्यकता है। ऐसा करने के लिए, हम अपने इंट्रा-यैंडेक्स संस्करण के मैपरेड को उपयोग करते हैं, जिसे वाईटी कहा जाता है, और इसके लिए पायथन में एक पुस्तकालय लिखा है, जो कुछ मैपर्स और रीड्यूसर लॉन्च करने की अनुमति देता है, और एक बड़े क्लस्टर पर कुछ गणना करने के लिए।

अंत में, जब पाइपलाइन तैयार होती है, तो हमें इसे स्वचालित करने की आवश्यकता होती है ताकि डेटा अद्यतित हो, और इसके लिए हम निर्वाण और हिटमैन जैसी चीज़ का उपयोग करें। यह इंट्रा-यैंडेक्स विकास भी है। निर्वाण एक क्लस्टर कंप्यूटिंग प्रबंधन ढांचा है। वास्तव में, वह जानती है कि किसी भी कार्यक्रम के बारे में कैसे चलाया जाए, दोष सहिष्णु हो, क्रॉस डीसी (00:14:53) हो। और जिस घटना में कुछ गिरता है, वह जानती है कि उसे कैसे पुनः आरंभ करना है, किसी भी घटना के घटित होने पर लॉन्च करना है। और टी। डी।



यह मोटे तौर पर हमारे MapReduce क्लस्टर का वेब इंटरफ़ेस जैसा दिखता है। यहां देखा जा सकता है कि हमारे पास बहुत सारी मशीनें हैं, ऐसे नोड्स हैं, जिन पर गणना की जाती है।



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

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



आइए इन मॉडलों का प्रयास करें, इस डेटा का उपयोग करें। ऐसा करने के लिए, कल्पना करें कि Yandex.Taxi सेवा क्या है।

एक बहुत ही सतही आरेख इस तरह दिखता है। उपयोगकर्ता हैं, उनके पास एक एप्लिकेशन है, और ड्राइवर हैं, उनके पास "टैक्समीटर" नामक एक एप्लिकेशन भी है। ये एप्लिकेशन किसी तरह बैकएंड के साथ संवाद करते हैं, और बैकएंड माइक्रोसेवर्स का एक सेट है जो एक दूसरे के साथ संवाद करते हैं - इल्या ने इस बारे में बात की। माइक्रोसर्विस में से एक हमारी सेवा है, हमारी टीम इसे करती है, इसे ML को सेवा, MLaaS के रूप में कहा जाता है।



आपको उसके बारे में जानने की जरूरत है, वह एमएलएएएस सी ++ में लिखा गया है, जो कि तथाकथित Fastcgi Daemon पर आधारित है। यह एक खुला स्रोत पुस्तकालय है, जो मोटे तौर पर बोल रहा है, एक वेब सर्वर लिखने के लिए एक रूपरेखा है जो अनुरोध प्राप्त और पोस्ट कर सकता है, सब कुछ मानक है। यह एक बार यैंडेक्स में लिखा गया था, जिसे खुले स्रोत में रखा गया था। हम कटे हुए संस्करण का उपयोग करते हैं। यह सेवा क्या कर सकती है? वह जानता है कि मॉडल के साथ कैसे काम करना है: उन्हें लागू करें, उन्हें घर पर रखें और कभी-कभी अपडेट करें, इस अद्भुत क्लाउड पर जाएं, जहां मॉडल नियमित रूप से अपडेट किए जाते हैं, सहेजे जाते हैं, और उन्हें डाउनलोड करते हैं।

प्रत्येक कार्यक्षमता, उदाहरण के लिए, ये लैंडिंग पॉइंट्स - अंदर हम उन्हें पिकअप पॉइंट्स कहते हैं - या, उदाहरण के लिए, पॉइंट बी की युक्तियों के बारे में जिनके बारे में इलिया ने बात की और लगातार पिछली रिपोर्ट में ब्रेकिंग की, प्रत्येक ऐसी कार्यक्षमता, जहाँ किसी प्रकार की मशीन लर्निंग है, मेल खाती है। हैंडलर, जो एक अनुरोध प्राप्त करने के तर्क को संग्रहीत करता है, मशीन सीखने के कारक पैदा करता है, और मॉडल लागू करता है, और एक प्रतिक्रिया उत्पन्न करता है। बेशक, यह सेवा अलग-अलग नहीं है, कुछ अतिरिक्त डेटा स्रोतों, डेटाबेस और कुछ अन्य माइक्रोसर्विसेज में जाने में सक्षम है।



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



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

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

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



हमने ऐसी सेवा बनाई, जिसे PyMLaaS कहा जाता है। वह क्या पसंद है? वास्तव में, यह MLaaS का एक पूरा एनालॉग है, जिसके बारे में मैंने पहले भी बात की थी, लेकिन फ्लास्क, नग्नेक्स और गुनिकॉर्न पर आधारित पायथन में लिखा गया था। वास्तुकला काफी सरल है, एमएलएएएस के समान है, लेकिन आपके ऑफ़लाइन प्रयोगों से कुछ प्रोटोटाइप को जल्दी से खोदने का अवसर है। इसके अलावा, हमने नंगेक्स स्तर पर इस तरह की समीपता की व्यवस्था की, ताकि, सशर्त रूप से, हमें MLaaS से PyMLaaS तक लोड को आगे बढ़ाने और इस तरह प्रयोग करने का अवसर मिले।



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

हमें यह इतना पसंद आया कि यह विचार सामने आया - हर समय इसका उपयोग क्यों नहीं किया जाता? क्योंकि, सशर्त रूप से, ऐसी विशेषताएं हैं जिनके लिए एक बड़े लोड, 1000 आरपीएस, बड़ी मेमोरी आवश्यकताओं की आवश्यकता होती है। मैं काफी लचीली समानता रखना चाहता हूं। लेकिन कुछ सुविधाओं के लिए, कुछ उत्पादों या सेवाओं के लिए जिनकी लोड, प्रदर्शन, आरपीएस, और इसी तरह की बहुत बड़ी मांग नहीं है, हम इस सेवा का सफलतापूर्वक उपयोग कर रहे हैं।



संक्षेप में देना। , . . . , - , , , -, - . - PyMLaaS, AB-, . , MLaaS, , .

pickup points — . . , . 30% , . .