6.2 मशीन लर्निंग इंजीनियरिंग (एमएलऑप्स)

अवलोकन और प्रेरणा

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

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

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

यह भी देखें: अध्याय 8.1 (सीआई/सीडी और डिलीवरी), अध्याय 9.2 (ऑब्ज़र्वेबिलिटी और निगरानी), और अध्याय 6.6 (एआई इंफ्रास्ट्रक्चर और संचालन)।

मुख्य सिद्धांत

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

सिफ़ारिशें

पूरे एमएल जीवनचक्र को स्पष्ट रूप से प्रबंधित करें

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

फ़ीचर-स्टोर, प्रयोग-ट्रैकिंग, और मॉडल-रजिस्ट्री इस्तेमाल करें

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

डेटा और मॉडलों को वंशावली के साथ दोहराने-योग्य और वर्शन्ड बनाएँ

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

वर्कलोड से मेल खाने वाले डिप्लॉयमेंट-पैटर्न चुनें

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

आवश्यकता को पूरा करने वाला सबसे सरल पैटर्न चुनें, और छाया-डिप्लॉयमेंट, कैनरी, और तुरंत रोलबैक के साथ अपना रोलआउट डिज़ाइन करें।

बहाव, क्षय, और डेटा-गुणवत्ता की निगरानी करें

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

ट्रेड-ऑफ़: फ़ायदे और नुक़सान

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

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

अपनी टीम के साथ चर्चा के लिए प्रश्न

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

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

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

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

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

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

क्षेत्र-लेंस

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

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

उद्यम। समस्या दर्जनों मॉडलों और कई टीमों में स्केल है: एक साझा फ़ीचर-स्टोर, प्रयोग-ट्रैकिंग, और शासित प्रमोशन वाली मॉडल-रजिस्ट्री ताकि समूह पाइपलाइन फिर से ईजाद करना बंद करें। पक्की-सड़क डिफ़ॉल्ट देने वाली एक प्लेटफ़ॉर्म टीम के लिए बजट रखें, वंशावली और निगरानी को मानकीकृत करें ताकि हर मॉडल ऑडिट-योग्य और हर घटना समझाने-योग्य हो, और ऐसे इंटरफ़ेस के पीछे जान-बूझकर बनाना-बनाम-ख़रीदना और लॉक-इन प्रबंधित करें जो अंतर्निहित टूलों को बदलने-योग्य रखे। प्लेटफ़ॉर्म में सत्यापन-गेट और रोलबैक लागू करें, परंपरा में नहीं।

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

उदाहरण

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

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

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

व्यवसाय-मामला: प्रेरणाएँ, आरओआई, और टीसीओ

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

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

एंटी-पैटर्न और नुक़सान

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

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

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

चर्चा के लिए विचार

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

मुख्य निष्कर्ष

• एमएल व्यवहार कोड-प्लस-डेटा-प्लस-मॉडल से आता है; तीनों को साथ वर्शन और शासित करें।
• फ़ीचर-स्टोर, प्रयोग-ट्रैकिंग, और रजिस्ट्री दोहराने-योग्य एमएल की रीढ़ हैं।
• वंशावली मॉडलों को ऑडिट-योग्य और घटनाओं को समझाने-योग्य बनाती है: विनियमित परिवेश में ज़रूरी।
• विलंब, ताज़गी, और संप्रभुता-ज़रूरतों से मेल खाने के लिए बैच, ऑनलाइन, स्ट्रीमिंग, या एज चुनें।
• मॉडल बिगड़ते हैं; बहाव, डेटा-गुणवत्ता, और क्षय की निगरानी वैकल्पिक नहीं है।

संदर्भ और आगे पढ़ने के लिए

• चिप ह्युएन, डिज़ाइनिंग मशीन लर्निंग सिस्टम्स।
• एंड्रिय बर्कोव, मशीन लर्निंग इंजीनियरिंग।
• डी. स्कली एट अल., हिडन टेक्निकल डेब्ट इन मशीन लर्निंग सिस्टम्स।
• मार्क ट्रेविल एट अल., इंट्रोड्यूसिंग एमएलऑप्स।
• वल्लीअप्पा लक्ष्मणन, सारा रॉबिन्सन, और माइकल मुन, मशीन लर्निंग डिज़ाइन पैटर्न्स।
• इमैनुएल अमिज़ेन, बिल्डिंग मशीन लर्निंग पावर्ड एप्लिकेशन्स।