मशीन लर्निंग @ बुकिंग। Com

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



अध्यक्ष के बारे में: विक्टर ब्लाईक ने Booking.com पर मशीन लर्निंग उत्पादों को वाणिज्यिक संचालन में पेश किया।


सबसे पहले, देखते हैं कि Booking.com किन उत्पादों में मशीन सीखने का उपयोग करता है।


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



यह मेरे खाते में एक स्क्रीनशॉट है, और मैं निश्चित रूप से इस वर्ष इनमें से दो क्षेत्रों का दौरा करूंगा।



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

हम समीक्षा का विश्लेषण करते हैं। मॉडल हमें बताते हैं कि लोग बर्लिन क्यों जाते हैं, कहते हैं।


मशीन लर्निंग मॉडल की मदद से, यह विश्लेषण किया जाता है कि होटल की प्रशंसा क्यों की जाती है ताकि आपको हजारों समीक्षाओं को स्वयं न पढ़ना पड़े।


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


हम अक्सर खुद को सही पाते हैं - 19 घंटों के बाद अंतिम कमरा पहले से ही बुक किया जाता है।


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

कार्यान्वयन की शुरुआत

चलिए कुछ साल पहले, 2015 में रिवाइंड करते हैं। जिन उत्पादों की मैंने बात की उनमें से कुछ पहले से मौजूद हैं। इसके अलावा, जिस प्रणाली के बारे में मैं आज बात करूंगा वह अभी तक नहीं है। उस समय कार्यान्वयन कैसे हुआ? चीजें बहुत स्पष्ट थीं, बहुत नहीं। तथ्य यह है कि हमारे पास एक बड़ी समस्या थी, जिसका एक हिस्सा तकनीकी है, और एक हिस्सा संगठनात्मक है।


हमने मौजूदा क्रॉस-फ़ंक्शनल टीमों के लिए डेटा वैज्ञानिकों को भेजा जो एक विशिष्ट उपयोगकर्ता समस्या पर काम करते हैं और उनसे किसी भी तरह उत्पाद में सुधार की उम्मीद करते हैं।

सबसे अधिक बार, उत्पाद के इन टुकड़ों को पर्ल स्टैक पर बनाया गया था। पर्ल के साथ एक स्पष्ट समस्या है - यह गहन कंप्यूटिंग के लिए डिज़ाइन नहीं किया गया है, और हमारा बैकएंड पहले से ही अन्य चीजों से भरा हुआ है। इसके अलावा, इस समस्या को हल करने वाले गंभीर प्रणालियों के विकास को टीम के भीतर प्राथमिकता नहीं दी जा सकती है, क्योंकि टीम का ध्यान उपयोगकर्ता समस्या को हल करने पर है, न कि मशीन सीखने का उपयोग करके उपयोगकर्ता की समस्या को हल करने पर। इसलिए, Product Owner (PO) इसका बहुत विरोध करेगा।

आइए देखें कि यह तब कैसे हुआ।

केवल दो विकल्प थे - मुझे यह निश्चित रूप से पता है, क्योंकि उस समय मैं सिर्फ ऐसी टीम में काम कर रहा था और डेटा वैज्ञानिकों को अपने पहले मॉडल को लड़ाई में लाने में मदद की।

पहला विकल्प भविष्यवाणियों का भौतिककरण था । मान लीजिए कि केवल दो विशेषताओं वाला एक बहुत ही सरल मॉडल है:

1. वह देश जहां आगंतुक स्थित है;
2. जिस शहर में वह एक होटल की तलाश में है।

हमें किसी घटना की संभावना का अनुमान लगाने की आवश्यकता है। हम सिर्फ सभी इनपुट वैक्टर उड़ाते हैं: कहते हैं, 100,000 शहरों, 200 देशों - MySQL में कुल 20 मिलियन लाइनें। यह उत्पादन के लिए कुछ छोटे रैंकिंग सिस्टम या अन्य सरल मॉडल के आउटपुट के लिए पूरी तरह कार्यात्मक विकल्प की तरह लगता है।


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


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

भविष्यवाणी सेवा

पहली चीज़ जो हमने की वह एक भविष्यवाणी सेवा थी। शायद, हैबे और हाईलाड ++ पर दिखाया गया सबसे सरल वास्तुकला कम है।


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


Booking.com में एक ईवेंट सिस्टम है - सभी प्रणालियों के लिए एक पत्रिका जैसा कुछ। वहां लिखना बहुत आसान है, और यह स्ट्रीम पुनर्निर्देशित करने के लिए बहुत सरल है। सबसे पहले, हमें क्लाइंट टेलीमेट्री को ग्रेफाइट और ग्राफाना के साथ कथित विलंबता और सर्वर साइड से विस्तृत जानकारी भेजने की आवश्यकता थी।


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


डेटा वैज्ञानिकों ने बहुत कम प्रतिबंधों के साथ काम करना शुरू कर दिया, और कुछ मामलों में बैक-ऑफर्स का काम एक एकल-पंक्ति तक कम हो गया।

उत्पाद की भविष्यवाणी

लेकिन आइए संक्षेप में वापस जाएं कि हमने उत्पाद में इन भविष्यवाणियों का उपयोग कैसे किया।

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

ऐसी विशेषताओं को लॉन्च करने में क्या समस्या है? बात यह है कि ये एक बोतल में दो चीजें हैं: एक मॉडल और उपयोगकर्ता इंटरफ़ेस में बदलाव। दोनों से प्रभावों को अलग करना बहुत मुश्किल है।

एक एबी प्रयोग के हिस्से के रूप में "अनुकूल प्रस्ताव" बैज लॉन्च करने की कल्पना करें। यदि यह बंद नहीं होता है - लक्ष्य मैट्रिक्स में कोई सांख्यिकीय रूप से महत्वपूर्ण परिवर्तन नहीं है - यह ज्ञात नहीं है कि समस्या क्या है: एक समझ से बाहर, छोटा, असंगत बैज या एक खराब मॉडल।

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


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

भविष्यवाणी की निगरानी

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


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

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

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

यह "सरल" मॉडल द्वारा की गई भविष्यवाणियों का सिर्फ एक हिस्टोग्राम निकला।


ग्राफ़ पर ऊपर एक लॉजिस्टिक रिग्रेशन है जो यह भविष्यवाणी करता है कि उपयोगकर्ता अपनी यात्रा की तारीख बदलेगा या नहीं। यह देखा जा सकता है कि यह उपयोगकर्ताओं को दो वर्गों में अच्छी तरह से विभाजित करता है: बाईं ओर, पहाड़ी वह है जो ऐसा नहीं करेगा; दाईं ओर की पहाड़ी वह है जो इसे करते हैं।


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

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

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

यह देखना दिलचस्प है कि विभिन्न वर्गों में ग्राफ़ कैसे बदलते हैं।


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

यह देखना भी दिलचस्प है कि बिक्री के फ़नल के माध्यम से उपयोगकर्ता के रूप में ये ग्राफ़ कैसे बदलते हैं।


बाईं ओर खोज पृष्ठ पर दिनांक बदलने की संभावना है, दाईं ओर पहले बुकिंग पृष्ठ पर है। यह देखा जा सकता है कि बहुत अधिक संख्या में लोग जो अपनी तारीखों को पहले ही तय कर चुके हैं वे बुकिंग पृष्ठ पर पहुंच जाते हैं।

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


कभी-कभी ये विशाल शिखर होते हैं।


यह एक लॉजिस्टिक रिग्रेशन भी है, और कुछ समय पहले तक यह दो पहाड़ियों के साथ एक सुंदर तस्वीर दिखाती थी, लेकिन एक सुबह ऐसा हो गया।

अंदर क्या हुआ, यह समझने के लिए, आपको यह समझने की आवश्यकता है कि लॉजिस्टिक प्रतिगमन की गणना कैसे की जाती है।

त्वरित संदर्भ

यह स्केलर उत्पाद का एक लॉजिस्टिक फ़ंक्शन है, जहां x _n कुछ विशेषताएं हैं। इनमें से एक विशेषता एक होटल (यूरो में) की एक रात की कीमत थी।


इस मॉडल को कॉल करना कुछ इस तरह होगा:


चयन पर ध्यान दें। कीमत को यूरो में बदलना आवश्यक था, लेकिन डेवलपर इसे करना भूल गया।


रुपये या रूबल जैसी मुद्राओं ने स्केलर उत्पाद को कई बार बढ़ाया, और, इसलिए, इस मॉडल को एकता के करीब एक मूल्य का उत्पादन करने के लिए मजबूर किया, बहुत अधिक बार, जिसे हम चार्ट पर देखते हैं।

थ्रेसहोल्ड मान

इन हिस्टोग्राम की एक और उपयोगी विशेषता थ्रेशोल्ड मूल्यों के एक सचेत और इष्टतम विकल्प की संभावना थी।


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

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

स्वयं भविष्यवाणियों के अलावा, हमने वैक्टर में इनपुट मूल्यों की निगरानी करना शुरू किया।

एक गर्म एन्कोडिंग

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


यह वही है जो आमतौर पर दिखता है।


डेस्टिनेशन_ड - वह शहर जिसमें उपयोगकर्ता किसी होटल की तलाश में है। स्वाभाविक रूप से, मॉडल ने लगभग 5% मूल्यों को नहीं देखा था, क्योंकि हम लगातार नए शहरों को जोड़ रहे हैं। visitor_cty_id = 23.32%, क्योंकि डेटासिएंटिस्ट कभी-कभी जानबूझकर कम आम शहरों को छोड़ देते हैं।

एक बुरे मामले में, यह इस तरह दिख सकता है:


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

अब डैशबोर्ड की मदद से, हम ऐसी स्थितियों का बहुत जल्दी पता लगा लेते हैं और उन्हें ठीक कर लेते हैं।

मशीन लर्निंग शोकेस

आइए अन्य मुद्दों के बारे में बात करते हैं जिन्हें हमने हल किया है। जब हमने क्लाइंट लाइब्रेरी और मॉनीटरिंग की, तो सेवा बहुत तेज़ी से गति प्राप्त करने लगी। हम सचमुच कंपनी के विभिन्न हिस्सों के अनुप्रयोगों से अभिभूत थे: “चलो इस मॉडल को भी कनेक्ट करें! चलो पुराने को अपडेट करें! ” हमने सिर्फ सिल दिया, वास्तव में, कोई भी नया विकास बंद हो गया है।

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

एक और समस्या थी।


Booking.com की लगभग 200 आईटी टीमें हैं। टीम को कंपनी के कुछ पूरी तरह से अलग हिस्से में कैसे जाने दें कि एक मॉडल है जो उनकी मदद कर सकता है? आप शायद यह नहीं जानते होंगे कि ऐसी टीम भी मौजूद है। यह कैसे पता करें कि कौन से मॉडल हैं और उनका उपयोग कैसे करें? परंपरागत रूप से, हमारी टीमों में बाहरी संचार PO (उत्पाद स्वामी) में लगे हुए हैं। इसका मतलब यह नहीं है कि हमारे पास कोई अन्य क्षैतिज कनेक्शन नहीं है, बस पीओ यह दूसरों की तुलना में अधिक है। लेकिन यह स्पष्ट है कि इस तरह के पैमाने पर, एक-पर-एक संचार पैमाने नहीं होता है। आपको इसके बारे में कुछ करने की जरूरत है।

संचार की सुविधा कैसे हो सकती है?

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


हमने अपने मॉडल के बारे में विस्तार से वर्णन करने के लिए डेटा विशेषज्ञों को सक्षम किया है। जब बहुत सारे मॉडल थे, तो हमने सुविधाजनक समूहन के लिए विषय और क्षेत्र लेबल जोड़े।


हमने अपने टूल को ExperimentTool के साथ जोड़ा। यह हमारी कंपनी के अंदर एक उत्पाद है जो ए / बी प्रयोग प्रदान करता है और प्रयोग के पूरे इतिहास को संग्रहीत करता है।


अब, मॉडल के विवरण के साथ, आप यह भी देख सकते हैं कि अन्य टीमों ने इस मॉडल के साथ पहले और सफलतापूर्वक क्या किया है। इसने सब कुछ बदल दिया है।

गंभीरता से, इसने आईटी के काम करने के तरीके को बदल दिया है, क्योंकि ऐसी स्थितियों में भी जब टीम में कोई डेटा वैज्ञानिक नहीं है, तो आप मशीन लर्निंग का उपयोग कर सकते हैं।


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

यह हमारे लिए क्या फैल गया? अभी, चरम पर, हम प्रति सेकंड लगभग 200 हजार भविष्यवाणियां देते हैं, जिसमें 20-30 एमएस से कम विलंबता है, जिसमें HTTP राउंड ट्रिप और 200 से अधिक मॉडल शामिल हैं।

यह लग सकता है कि यह पार्क में इतनी आसान सैर थी: हमने एक अद्भुत काम किया, सब कुछ काम करता है, हर कोई खुश है!


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


फिर हम अपने कंप्यूटिंग कोर में लौट आए, समीक्षा की, बेंचमार्क बनाया और क्षमता परीक्षण के परिणामस्वरूप, हमने सीखा कि उसी ट्रैफ़िक के लिए हमें केवल 4 मशीनों की आवश्यकता है। , , -, , , , 100 000 RPS 4 .

- , , . - , , , .

— , . , ID , . , 0.


— , — .


, . , . , — , . , , , - .

, — ID . — 49-51%. , . , , . , .

भविष्य की योजना

• Label based metrics
  

- , . Label based metrics, precision recall .

• More tools & integrations
  

, . , Perl Java, , , . Spark, .

• Reusable training pipelines
  

.

, -. , , , , , steaming — - , , .

. pipeline, , . , , .

• Async models
  

. , , 50 , . , . , , .

Start small

, , Booking.com, , , — !

, , MySQL. , , . - . B . , , - — .

, ?

Monitor

— , -, . — . — , . , , , . : , . , , , — !

Organization footprint

, . , . , .

(Don't) Follow our steps

- , , , . , - , . , . — , , ? , , , ?

, , !

HighLoad++ 2018, 8 9 , 135 , . 9 - . , .