एमएलओपीएस पर सबसे विस्तृत मार्गदर्शिका: भाग 1

हाय हैकरनून! इस लेख में, मैं एमएलओपीएस की अवधारणा पर विस्तार से चर्चा करूंगा। इसके अलावा, मैं इसे 3 तरीकों से करूंगा। सबसे पहले, सैद्धांतिक रूप से - सबसे समझदार एमएलओपीएस योजना के माध्यम से। फिर, वैचारिक रूप से, उन कलाकृतियों के माध्यम से जो दृष्टिकोण में अंतर्निहित हैं। और अंत में, एमएलओपीएस को एक सूचना प्रणाली के रूप में समझने के माध्यम से।

चलिए, शुरू करते हैं।

एमएलओपीएस क्या है?

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

सिस्टम के किसी भी अन्य घटक की तरह, व्यवसाय तर्क के इस हिस्से को बदलते व्यवसाय और ग्राहकों की अपेक्षाओं को पूरा करने के लिए अद्यतन करने की आवश्यकता है। एमएलओपीएस इस नियमित अपडेट के बारे में है।

एमएलओपीएस परिभाषा और स्पष्टीकरण

एमएलओपीएस की अभी तक कोई एकल और सर्वसम्मत परिभाषा नहीं है। कई लेखकों ने इसे देने की कोशिश की है, लेकिन एक ही समय में स्पष्ट और व्यवस्थित विवरण ढूंढना चुनौतीपूर्ण था।

एक ऐसा है जिसे इस प्रकार माना जा सकता है:

एमएलओपीएस एक इंजीनियरिंग अनुशासन है जिसका उद्देश्य उत्पादन में उच्च प्रदर्शन वाले मॉडल की निरंतर डिलीवरी को मानकीकृत और सुव्यवस्थित करने के लिए एमएल सिस्टम विकास (डेव) और एमएल सिस्टम परिनियोजन (ऑप्स) को एकीकृत करना है।

आइए एमएलओपीएस परिभाषा के महत्वपूर्ण भागों पर प्रकाश डालें:

• अभियांत्रिक अनुशासन
• इसका उद्देश्य एमएल सिस्टम के विकास और तैनाती प्रक्रियाओं को एकीकृत करना है
• नए संस्करणों की निरंतर डिलीवरी को मानकीकृत और अनुकूलित करता है
• उच्च प्रदर्शन मॉडल

तो, एमएलओपीएस एमएल मॉडल के लिए एक प्रकार का डेवऑप्स है।

एमएलओपीएस के उद्भव का इतिहास

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

डी. स्कली ने टीम के तकनीकी ऋण के दृष्टिकोण से मॉडलों के साथ काम पर विचार करना शुरू किया। हां, मॉडलों के नए संस्करण शीघ्रता से जारी करना संभव है, लेकिन परिणामी प्रणाली के समर्थन की लागत का कंपनी के बजट पर महत्वपूर्ण प्रभाव पड़ेगा।

उनके काम का परिणाम पेपर "मशीन लर्निंग सिस्टम में छिपा हुआ तकनीकी ऋण "2015 में NeurIPS सम्मेलन में प्रकाशित। इस लेख के प्रकाशन की तारीख को MLOps के अस्तित्व का प्रारंभिक बिंदु माना जा सकता है।

एमएलओपीएस परिपक्वता स्तर: सबसे प्रसिद्ध मॉडल

अधिकांश आईटी प्रक्रियाओं की तरह, एमएलओपीएस में परिपक्वता स्तर होता है। वे कंपनियों को यह समझने में मदद करते हैं कि वे अभी कहाँ हैं और वे अगले स्तर तक कैसे जा सकते हैं (यदि ऐसा कोई लक्ष्य है)। साथ ही, आम तौर पर स्वीकृत परिपक्वता निर्धारण विधियां आपको प्रतिस्पर्धियों के बीच अपना स्थान निर्धारित करने की अनुमति देती हैं।

GigaOm MLOps परिपक्वता मॉडल

सबसे अच्छी तरह से वर्णित और काफी हद तक समझने योग्य मॉडल एनालिटिक्स फर्म GigaOm का है। यह सभी मॉडलों की क्षमता परिपक्वता मॉडल एकीकरण (सीएमएमआई) के सबसे करीब है। यह संगठनात्मक प्रक्रियाओं में सुधार के लिए कार्यप्रणाली का एक सेट है, जिसमें 5 स्तर भी शामिल हैं - 0 से 4 तक।

GigaOm का मॉडल प्रत्येक परिपक्वता स्तर को 5 श्रेणियों के माध्यम से खोलता है: रणनीति, वास्तुकला, मॉडलिंग, प्रक्रियाएं और शासन।

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

Google MLOps परिपक्वता मॉडल

यह ध्यान देने योग्य है कि Google के पास अपना MLOps परिपक्वता स्तर मॉडल भी है। यह सबसे पहले प्रदर्शित होने वालों में से एक था। यह संक्षिप्त है और इसमें 3 स्तर हैं:

• स्तर 0: मैन्युअल प्रक्रिया
• स्तर 1: एमएल पाइपलाइन स्वचालन
• स्तर 2: सीआई/सीडी पाइपलाइन स्वचालन

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

Azure MLOps परिपक्वता मॉडल

आज, एमएल का उपयोग करने वाली कई बड़ी कंपनियों ने अपने परिपक्वता मॉडल संकलित किए हैं। नीला , जो स्तरों को अलग करने के लिए एक समान दृष्टिकोण का उपयोग करता है, शामिल है। हालाँकि, उनमें से Google की तुलना में अधिक हैं:

• स्तर 0: कोई एमएलओपीएस नहीं
• स्तर 1: DevOps लेकिन कोई MLOps नहीं
• स्तर 2: स्वचालित प्रशिक्षण
• स्तर 3: स्वचालित मॉडल परिनियोजन
• स्तर 4: पूर्ण एमएलओपीएस स्वचालित संचालन

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

एमएलओपीएस संकल्पनात्मक ढांचा

आप एमएलओपीएस की अवधारणा से जुड़ी सभी प्रक्रियाओं का वर्णन कैसे करते हैं? आश्चर्यजनक रूप से, तीन जर्मन - लेख के लेखक " मशीन लर्निंग ऑपरेशंस (एमएलओपीएस): अवलोकन, परिभाषा और वास्तुकला - यहां तक कि उन्हें एक आरेख में समाहित करने में भी कामयाब रहे। उन्होंने एक वास्तविक अध्ययन किया और एमएलओपीएस की अवधारणा का विस्तार से वर्णन किया।

यह डराने वाला हो सकता है क्योंकि इसमें कई तत्व एक-दूसरे के साथ बातचीत करते हैं। हालाँकि, ऊपर उल्लिखित परिपक्वता स्तरों की कई विशेषताएँ इसमें पाई जा सकती हैं। कम से कम स्वचालित पाइपलाइन, सीआई/सीडी, मॉनिटरिंग, मॉडल रजिस्ट्री, वर्कफ़्लो ऑर्केस्ट्रेशन और सर्विंग कंपोनेंट।

आइए इस आरेख पर चर्चा करें और प्रत्येक के बारे में अधिक विस्तार से बात करें।

एमएलओपीएस कोर प्रक्रियाएं

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

प्रयोग

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

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

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

ऐसी गतिविधि को प्रयोग कहा जाता है। इसका अर्थ है एक कार्यशील एमएल मॉडल प्राप्त करना, जिसका उपयोग प्रासंगिक समस्याओं को हल करने के लिए किया जा सकता है।

आरेख में दिखाया गया ब्लॉक सी एमएल प्रयोगों के संचालन की प्रक्रिया का वर्णन करता है।

कार्य के दायरे में उपलब्ध डेटा का विश्लेषण करना

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

इसलिए, यह पता लगाना महत्वपूर्ण है कि हमें कौन सा डेटा प्राप्त हुआ है और हम इसके साथ क्या कर सकते हैं। उदाहरण के लिए, ऐसा करने के लिए, हम यह कर सकते हैं:

• ज्यूपिटर या सुपरसेट का उपयोग करके एक एडहॉक अध्ययन संचालित करें
• मानक ईडीए (खोजपूर्ण डेटा विश्लेषण)

डेटा की बेहतर समझ तभी प्राप्त की जा सकती है जब इसे सिमेंटिक और संरचनात्मक विश्लेषण के साथ जोड़ा जाए।

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

गुणवत्तापूर्ण डेटासेट का निर्माण

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

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

एमएल मॉडल प्रशिक्षण और सत्यापन

पिछले चरण के बाद, प्रयोग करते समय प्रशिक्षित मॉडल के मेट्रिक्स पर विचार करना समझ में आता है। विचाराधीन ब्लॉक के ढांचे के भीतर, प्रयोग में एमएल मॉडल के प्रशिक्षण और सत्यापन को जोड़ना शामिल है।

प्रयोग में तैयार डेटासेट पर हाइपरपैरामीटर के चयनित सेट के साथ मॉडल के वांछित संस्करण को प्रशिक्षित करने की शास्त्रीय योजना शामिल है। इस प्रयोजन के लिए, डेटासेट को स्वयं प्रशिक्षण, परीक्षण और सत्यापन नमूनों में विभाजित किया गया है:

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

आप सत्यापन नमूनों के बारे में अधिक पढ़ सकते हैं यह लेख .

रिपॉजिटरी में कोड और हाइपरपैरामीटर सहेजना

यदि मॉडल लर्निंग मेट्रिक्स अच्छे हैं, तो मॉडल कोड और चयनित पैरामीटर कॉर्पोरेट रिपॉजिटरी में संग्रहीत किए जाते हैं।

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

प्रयोगों के संचालन में कठिनाई यह है कि डेवलपर को एमएल-मॉडल ऑपरेशन मापदंडों के कई संयोजनों की जांच करने की आवश्यकता होती है। और हम प्रयुक्त गणितीय उपकरण के विभिन्न प्रकारों के बारे में बात नहीं कर रहे हैं।

सामान्य तौर पर, इसमें काम लगता है। और यदि मॉडल मापदंडों के संयोजन के ढांचे के भीतर वांछित मेट्रिक्स हासिल नहीं किए जाते हैं तो क्या करें?

फ़ीचर इंजीनियरिंग

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

नई सुविधाओं में शामिल हो सकते हैं:

• सारणीबद्ध डेटा के लिए: पहले से मौजूद ऑब्जेक्ट विशेषताओं का मनमाना परिवर्तन - उदाहरण के लिए, X^2, SQRT(X), लॉग(x), X1*X2, आदि।
• विषय क्षेत्र के आधार पर: बॉडी मास इंडेक्स, एक वर्ष के लिए अतिदेय ऋण भुगतान की संख्या, आदि।

आइए आरेख के उस भाग को देखें जो फ़ीचर इंजीनियरिंग से संबंधित है।

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

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

ब्लॉक बी2 डेटा में नई सुविधाएँ जोड़ने की तत्काल प्रक्रिया का वर्णन करता है।

डेटा स्रोतों से कनेक्ट करना और पुनर्प्राप्त करना तकनीकी कार्य हैं जो काफी जटिल हो सकते हैं। स्पष्टीकरण की सरलता के लिए, मैं मान लूंगा कि ऐसे कई स्रोत हैं जिन तक टीम के पास पहुंच है और इन स्रोतों से डेटा अनलोड करने के लिए उपकरण हैं (कम से कम पायथन स्क्रिप्ट)।

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

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

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

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

स्वचालित एमएल वर्कफ़्लो

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

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

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

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

अब अधिक वास्तविक दुनिया के उदाहरणों पर। आइए किसी बाज़ार के लिए अनुशंसा प्रणाली के विकास पर विचार करें।

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

कुछ घटित होता है, और ग्राहकों की ज़रूरतें बदल जाती हैं। नतीजतन, उनकी सिफारिशें अब प्रासंगिक नहीं रह गई हैं। अनुशंसित उत्पादों की मांग कम हो गई है। इन सबके कारण राजस्व में कमी आती है।

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

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

यह योजना का सबसे भारी लोड वाला अनुभाग है। ब्लॉक डी के संचालन में कई प्रमुख तृतीय-पक्ष घटक शामिल हैं:

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

ब्लॉक की संरचना स्वयं प्रयोग और फीचर विकास (बी2) ब्लॉक के चरणों को जोड़ती है। यह आश्चर्य की बात नहीं है, यह देखते हुए कि ये ऐसी प्रक्रियाएं हैं जिन्हें स्वचालित करने की आवश्यकता है। मुख्य अंतर अंतिम 2 चरणों में हैं:

• निर्यात मॉडल
• मॉडल रजिस्ट्री पर पुश करें

शेष चरण ऊपर वर्णित चरणों के समान हैं।

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

अक्सर, विभिन्न एमएल उपकरण कोड के भीतर चलाए जाते हैं, जिसके भीतर पाइपलाइनों के चरणों का निष्पादन होता है, उदाहरण के लिए:

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

यहां ध्यान देने योग्य बात यह है कि प्रयोगों को स्वचालित करना आम तौर पर असंभव है। बेशक, प्रक्रिया में ऑटोएमएल अवधारणा को जोड़ना संभव है। हालाँकि, वर्तमान में कोई मान्यता प्राप्त समाधान नहीं है जिसका प्रयोग प्रयोग के किसी भी विषय के लिए समान परिणामों के साथ किया जा सके।

सामान्य स्थिति में, ऑटोएमएल इस तरह काम करता है:

1. किसी तरह मॉडल ऑपरेशन मापदंडों के कई संयोजनों का एक सेट तैयार करता है
2. प्रत्येक परिणामी संयोजन के लिए एक प्रयोग चलाता है। प्रत्येक प्रयोग के लिए मेट्रिक्स तय करता है जिसके आधार पर सर्वश्रेष्ठ मॉडल का चयन किया जाता है
3. ऑटोएमएल वे सभी जोड़-तोड़ करता है जो एक जूनियर/मध्यम डेटा वैज्ञानिक कम या ज्यादा मानक कार्यों के चक्र में करता है

स्वचालन पर थोड़ा ध्यान दिया गया है। इसके बाद, हमें उत्पादन के लिए मॉडल के एक नए संस्करण की डिलीवरी को व्यवस्थित करने की आवश्यकता है।

मॉडलों की सेवा और निगरानी

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

एमएल मॉडल फ़ाइल प्राप्त होने के क्षण से, चीजें कई तरीकों से सामने आ सकती हैं। टीम जा सकती है:

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

सभी मॉडलों के लिए ऐसा करना और भविष्य में संपूर्ण कोड आधार को बनाए रखना एक श्रमसाध्य कार्य है। इसे आसान बनाने के लिए, विशेष सेवा उपकरण सामने आए हैं, जिन्होंने 3 नई इकाइयाँ पेश कीं:

• अनुमान उदाहरण/सेवा
• अनुमान सर्वर
• सर्विंग इंजन

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

अनुमान सर्वर अनुमान उदाहरणों/सेवाओं का निर्माता है। इंफ़रेंस सर्वर के कई कार्यान्वयन हैं। प्रत्येक विशिष्ट एमएल फ्रेमवर्क के साथ काम कर सकता है, इनपुट प्रश्नों को संसाधित करने और भविष्यवाणियां उत्पन्न करने के लिए उनमें प्रशिक्षित मॉडल को उपयोग के लिए तैयार मॉडल में परिवर्तित कर सकता है।

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

विचाराधीन योजना में, मॉडल सेवारत घटकों का ऐसा कोई विवरण नहीं है, लेकिन समान पहलुओं को रेखांकित किया गया है:

• सीआई/सीडी घटक, जो उत्पादन में चलने के लिए तैयार मॉडलों को तैनात करता है (इसे सर्विंग इंजन के संस्करणों में से एक माना जा सकता है)
• मॉडल सर्विंग, इसके लिए उपलब्ध बुनियादी ढांचे के भीतर, स्ट्रीमिंग और बैच दोनों परिदृश्यों के लिए एमएल मॉडल के लिए भविष्यवाणी पीढ़ी की योजना का आयोजन करता है (इसे अनुमान सर्वर के संस्करणों में से एक माना जा सकता है)

सर्विंग के लिए पूर्ण स्टैक के उदाहरण के लिए, हम सेल्डन के स्टैक का उल्लेख कर सकते हैं:

• सेल्डन कोर सर्विंग इंजन है
• सेल्डन एमएल सर्वर अनुमान सर्वर है, जो REST या gRPC के माध्यम से मॉडल तक पहुंच तैयार करता है
• सेल्डन एमएलसर्वर कस्टम रनटाइम अनुमान उदाहरण है, किसी भी एमएल मॉडल के लिए एक शेल उदाहरण जिसका उदाहरण भविष्यवाणियां उत्पन्न करने के लिए चलाने की आवश्यकता है।

सर्विंग को लागू करने के लिए एक मानकीकृत प्रोटोकॉल भी है, जिसका समर्थन ऐसे सभी उपकरणों में वास्तव में अनिवार्य है। इसे V2 इंफ़रेंस प्रोटोकॉल कहा जाता है और इसे कई प्रमुख बाज़ार खिलाड़ियों - केसर्व, सेल्डन और एनवीडिया ट्राइटन द्वारा विकसित किया गया है।

सेवा बनाम तैनाती

विभिन्न लेखों में, आपको एक इकाई के रूप में सेवा और तैनाती के लिए उपकरणों का संदर्भ मिल सकता है। हालाँकि, दोनों के उद्देश्य में अंतर को समझना आवश्यक है। यह एक बहस का मुद्दा है, लेकिन यह लेख इसे इस प्रकार रखेगा:

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

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

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

परियोजना का प्रारम्भ

ऊपर लिखी गई हर बात को देखते हुए, यह पता चलता है कि एमएल कमांड:

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

यह महँगा लगता है और कभी-कभी ही उचित भी लगता है। इसलिए, तर्कसंगत लक्ष्य निर्धारण के लिए जिम्मेदार आरेख में एक अलग एमएलओपीएस प्रोजेक्ट इनिशिएशन (ए) ब्लॉक है।

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

• नई एमएल प्रणाली से आप किस व्यावसायिक समस्या का समाधान करने जा रहे हैं?
• आपने यह निर्णय क्यों लिया कि नई एमएल प्रणाली को इस समस्या का समाधान करना चाहिए?
• क्या प्रक्रियाओं को बदलना या तकनीकी सहायता में अधिक लोगों को नियुक्त करना आसान और सस्ता होगा?
• आप एमएल-सिस्टम घटकों का तुलनात्मक विश्लेषण कहां देख सकते हैं जिसने आपके वर्तमान चयन का आधार बनाया है?
• चुना हुआ एमएल-सिस्टम आर्किटेक्चर किसी व्यावसायिक समस्या को हल करने में कैसे मदद करेगा?
• क्या आप आश्वस्त हैं कि एमएल के पास पहचानी गई समस्या को हल करने के लिए आवश्यक गणितीय उपकरण हैं?
• समाधान के लिए समस्या कथन क्या है?
• मॉडलों को प्रशिक्षित करने के लिए आपको डेटा कहां से मिलेगा? क्या आप जानते हैं कि मॉडल तैयार करने के लिए आपको किस डेटा की आवश्यकता होगी?
• क्या आपने पहले ही उपलब्ध आंकड़ों की जांच कर ली है?
• क्या डेटा की गुणवत्ता मॉडल को हल करने के लिए पर्याप्त है?

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

अगला प्रश्न: क्या मुझे इसमें MLOps करने की आवश्यकता है?

समस्या पर निर्भर करता है. यदि आपको एक बार का समाधान खोजने की आवश्यकता है, उदाहरण के लिए, पीओसी (अवधारणा का प्रमाण), तो आपको एमएलओपीएस की आवश्यकता नहीं है। यदि कई आने वाले अनुरोधों को संसाधित करना आवश्यक है, तो MLOps की आवश्यकता है। संक्षेप में, यह दृष्टिकोण किसी भी कॉर्पोरेट प्रक्रिया को अनुकूलित करने के समान है।

प्रबंधन के लिए एमएलओपीएस की आवश्यकता को उचित ठहराने के लिए, आपको प्रश्नों के उत्तर तैयार करने होंगे:

• क्या बेहतर होने वाला है?
• हम कितना पैसा बचाएंगे?
• क्या हमें अपने स्टाफ का विस्तार करने की आवश्यकता है?
• हमें क्या खरीदने की जरूरत है?
• विशेषज्ञता कहाँ से प्राप्त करें?

अगला काम आईटी निदेशक की परीक्षा दोबारा देना है।

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

टीम को समझाने के लिए, प्रश्नों के उत्तर तैयार करना उचित है:

• पुराने तरीके से काम करना अब संभव क्यों नहीं?
• परिवर्तन का उद्देश्य क्या है?
• प्रौद्योगिकी स्टैक क्या होगा?
• क्या और किससे सीखें?
• कंपनी परिवर्तनों को लागू करने में कैसे सहायता करेगी?
• परिवर्तन करने में कितना समय लगता है?
• जो ऐसा नहीं कर पाते उनका क्या होता है?

जैसा कि आप देख सकते हैं, यह प्रक्रिया सरल नहीं है।

छोटा सा निष्कर्ष

मैंने यहां एमएलओपीएस योजना का विस्तृत अध्ययन पूरा कर लिया है। हालाँकि, ये केवल सैद्धांतिक पहलू हैं। व्यावहारिक कार्यान्वयन से हमेशा अतिरिक्त विवरण सामने आते हैं जो बहुत सी चीज़ें बदल सकते हैं।

अगले लेख में मैं चर्चा करूंगा:

• एमएलओपीएस कलाकृतियाँ
• एक सूचना प्रणाली के रूप में एमएलओप्स
• एमएलओपीएस के लिए खुला स्रोत: क्यूबफ्लो बनाम एमएलफ्लो बनाम पचीडर्म

आपके ध्यान देने के लिए धन्यवाद!