नफा:
- कोड-डेटा-मॉडेल त्रिकूट आणि पॅकेजशी संबंधित एमएलची विशेष आव्हाने ओळखण्याची आणि व्यवसायाच्या गरजेनुसार मॉडेल ऑनलाइन किंवा बॅचमध्ये सादर करण्याची क्षमता.
- हळूहळू आणि रोलबॅक डिप्लॉयमेंट पॅटर्न (सावली, कॅनरी, A/B, रोलबॅक) अंमलात आणण्याची क्षमता आणि प्रत्येक तैनातीसाठी चाचणी केलेली रोलबॅक योजना जोडणे
- उत्पादनामध्ये ठेवलेल्या मॉडेलचा डेटा-कोड-मेट्रिक लिंक मूल्यांकन थ्रेशोल्ड-नियंत्रित सीआय/सीडी आणि मॉडेल नोंदणीसह शोधण्यायोग्य ठेवण्याची क्षमता
नोटबुकमध्ये 95% अचूकता प्राप्त करण्यासाठी मॉडेल मिळवणे ही केवळ अर्धी गोष्ट आहे. दुसरा अर्धा—अनेकदा कठीण भाग—ते मॉडेल खऱ्या वापरकर्त्यांना विश्वसनीय, स्केलेबल आणि देखरेख करण्यायोग्य मार्गाने मिळवून देणे. MLOps (मशीन लर्निंग ऑपरेशन्स: उत्पादनात ML मॉडेल्स टाकणे, ऑपरेट करणे आणि देखरेख करणे) सॉफ्टवेअर अभियांत्रिकीच्या DevOps पद्धतींना ML च्या अद्वितीय आव्हानांसह एकत्रित करते. या युनिटमध्ये, आम्ही मॉडेलला उत्पादनात हलवण्याच्या पायऱ्या आणि या प्रक्रियेत कृत्रिम बुद्धिमत्ता कशी मदत करते ते समाविष्ट करतो.
ML नियमित सॉफ्टवेअरपेक्षा वेगळे का आहे?
सामान्य सॉफ्टवेअरमध्ये, वर्तन कोडमध्ये असते; जर कोड बदलला नाही तर वर्तन बदलत नाही. ML मध्ये, वर्तन कोड, डेटा आणि मॉडेल या दोन्हींवर अवलंबून असते. हे तीन आयाम MLOps ची अतिरिक्त आव्हाने निर्माण करतात:
- डेटा ड्रिफ्ट: उत्पादनातील डेटा कालांतराने प्रशिक्षणातील डेटापासून दूर जातो; मॉडेल अप्रचलित होते.
- तुम्हाला तीन गोष्टींची आवृत्ती तयार करण्याची आवश्यकता आहे: कोड, डेटा आणि मॉडेल - तिन्ही.
- मूक अपयश: एखादे मॉडेल क्रॅश न होता, त्रुटी न देता, फक्त चुकीचे अंदाज निर्माण करून अयशस्वी होऊ शकते. हे पकडण्यासाठी निरीक्षण आवश्यक आहे.
म्हणूनच "कार्यरत मॉडेल" आणि "उत्पादन-तयार मॉडेल" मध्ये मोठा फरक आहे.
मॉडेल पॅकेजिंग आणि सादरीकरण
मॉडेलला उत्पादनात आणण्याची पहिली पायरी म्हणजे त्याचे पॅकेजिंग करणे: मॉडेल फाइल, आवश्यक लायब्ररी, प्रीप्रोसेसिंग कोड आणि आवृत्ती माहिती एकत्रितपणे पुनरुत्पादित करणे. कंटेनरायझेशन (उदा. डॉकर: ऍप्लिकेशनला त्याच्या सर्व अवलंबनांसह वेगळ्या बॉक्समध्ये ठेवणे) येथे मानक आहे; हे "माझ्या मशीनवर काम करत होते" समस्या दूर करते.
मॉडेल सर्व्ह करण्याचे दोन मूलभूत नमुने:
- ऑनलाइन/रिअल-टाइम (ऑनलाइन): मॉडेल API च्या मागे बसते, प्रत्येक येणाऱ्या विनंतीसाठी त्वरित अंदाज परत करते. कमी विलंब गंभीर आहे.
- बॅच: मॉडेल वेळोवेळी मोठ्या डेटा सेटवर प्रक्रिया करते (उदा. रात्री सर्व ग्राहकांसाठी स्कोअर व्युत्पन्न करते). विलंब अप्रासंगिक आहे, कार्यक्षमता महत्वाची आहे.
कोणते योग्य आहे ते व्यवसायाच्या गरजेवर अवलंबून असते: ऑनलाइन त्वरित शिफारस, बॅचमध्ये मासिक जोखीम स्कोअर.
टीप: "रिअल-टाइम" ही किंमत आहे, डीफॉल्ट नाही. जर परिणाम काही तासांत वापरला जाईल तर बॅच खूपच स्वस्त आणि सोपी आहे. तुम्हाला खरोखरच झटपट उत्तर हवे आहे का? ते आधी विचारा.
सुरक्षित वितरण धोरणे
नवीन मॉडेल थेट सर्व रहदारीसाठी उघडणे धोकादायक आहे; जर ते चुकीचे असेल तर प्रत्येकजण प्रभावित होतो. सुरक्षित वितरण पद्धती:
- शॅडो डिप्लॉयमेंट: नवीन मॉडेलला प्रोडक्शन ट्रॅफिक मिळते, परंतु त्याचे अंदाज वापरकर्त्याला दाखवले जात नाहीत, फक्त लॉग केलेले असतात. वास्तविक डेटामध्ये सुरक्षित आहे की नाही हे पाहण्यासाठी जुन्या मॉडेलशी तुलना केली जाते.
- कॅनरी डिप्लॉयमेंट: नवीन मॉडेल प्रथम ट्रॅफिकच्या छोट्या टक्केवारीत आणले जाते (उदा. 5%); कोणतीही समस्या नसल्यास, ते हळूहळू वाढविले जाते.
- A/B चाचणी: वास्तविक वापरकर्त्याला दोन मॉडेल समांतर सादर केले जातात आणि व्यवसाय मेट्रिक्स (रूपांतरण, क्लिक) यांची तुलना केली जाते.
- रोलबॅक: नवीन मॉडेल खराब झाल्यास त्वरीत जुन्या आवृत्तीवर परत येण्याची क्षमता. प्रत्येक उपयोजनामध्ये रोलबॅक योजना असावी.
खबरदारी: रोलबॅक योजनेशिवाय तैनाती पूर्ण होत नाही. जेव्हा नवीन मॉडेल उत्पादनात अनपेक्षितपणे वागते तेव्हा काही मिनिटांत जुन्या आवृत्तीवर परत येण्यास सक्षम असणे वापरकर्त्याचे संरक्षण करते. तैनात करण्यापूर्वी याची चाचणी घ्या.
कमकुवत दृष्टीकोन / मजबूत दृष्टीकोन
कमकुवत: "मॉडेल चाचणीमध्ये चांगले होते, आम्ही थेट गेलो, आम्ही ते प्रत्येकासाठी उघडले."
Güçlü: "आम्ही मॉडेल कंटेनरीकृत केले, त्यास आवृत्ती म्हणून लेबल केले. प्रथम, जुन्या मॉडेलशी अंदाजांची तुलना करून, आम्ही ते उत्पादन रहदारीसह 3 दिवसांसाठी शॅडो मोडमध्ये चालवले - विचलन स्वीकार्य होते. नंतर आम्ही ते 5% कॅनरीसह उघडले, थ्रूपुट मेट्रिक्स आणि लेटन्सी यांचे परीक्षण केले. कोणतीही समस्या नसताना, आम्ही हळूहळू 10% चाचणी घेण्यापूर्वी त्याची चाचणी 10% वाढवली.
फरक: मजबूत दृष्टीकोन हळूहळू, मोजमाप आणि उलट करता येण्याजोगा आहे. प्रत्येक टप्प्यावर धोका मर्यादित आहे.
CI/CD आणि ऑटोमेशन
ML मधील CI/CD (सतत एकात्मता / सतत उपयोजन: आपोआप चाचणी आणि कोड बदल सोडण्याची पाइपलाइन) केवळ कोडच नाही तर डेटा आणि मॉडेल चरणांचाही समावेश करते. चांगली ML CI/CD पाइपलाइन: जेव्हा कोड बदलतो तेव्हा चाचण्या चालवते, डेटा प्रमाणीकरण करते, मॉडेलला पुन्हा प्रशिक्षित करते (आवश्यक असल्यास), मूल्यमापन थ्रेशोल्ड तपासते आणि थ्रेशोल्ड धारण केल्यासच तैनाती वाढवते. "प्रशिक्षण स्वयंचलित आहे, उपयोजन थ्रेशोल्ड-आधारित आहे" हे तत्त्व खराब मॉडेलला मूकपणे उत्पादनात लीक होण्यापासून प्रतिबंधित करते.
या पाइपलाइन सेट करताना AI खूप उपयुक्त आहे: कॉन्फिगरेशन फाइल (YAML) मसुदे, चाचणी प्रकरणे, उपयोजन स्क्रिप्ट लिहिणे. परंतु तुम्ही वितरण थ्रेशोल्ड (काही मेट्रिक प्रकाशित केलेल्या मूल्यापेक्षा जास्त असेल) आणि रोलबॅक धोरण निर्धारित करता; हे व्यवसाय जोखमीचे निर्णय आहेत.
पुनरुत्पादनक्षमता पायाभूत सुविधा
उत्पादनामध्ये मॉडेलचे वर्तन पुनरुत्पादित करण्यासाठी, मॉडेल नोंदणी: एक रेकॉर्ड जे ठेवते की कोणत्या मॉडेलला कोणत्या डेटा आणि कोडसह प्रशिक्षित केले गेले आणि त्याला कोणते मेट्रिक्स प्राप्त झाले. प्रत्येक उत्पादन मॉडेलसाठी, खालील गोष्टी ट्रॅक करण्यायोग्य असाव्यात: प्रशिक्षण डेटा आवृत्ती, कोड आवृत्ती (गिट कमिट), हायपरपॅरामीटर्स, मूल्यांकन स्कोअर आणि उपयोजन तारीख. जेव्हा एखादी समस्या उद्भवते, तेव्हा आपण "कोणत्या मॉडेलने हे अंदाज तयार केले, कोणत्या डेटासह?" या प्रश्नाचे उत्तर देण्यास सक्षम असावे. काही मिनिटांत. आम्ही हे युनिट 11 मध्ये सखोल करू.
तीन लहान प्रकरणे
केस 1 - छाया वितरणाने पकडलेली समस्या. एका शिफारस मॉडेलने जुन्या मॉडेलला चाचणीत हरवले. शॅडो मोडमध्ये उत्पादन ट्रॅफिकसह चालवणे वापरकर्त्यांच्या विशिष्ट विभागासाठी (नवीन वापरकर्ते) अतिशय खराब शिफारसी तयार करत असल्याचे आढळले — चाचणी डेटा या विभागाचा कमी प्रतिनिधी होता. मॉडेल वापरकर्त्यास कधीही प्रदर्शित न करता निश्चित केले गेले. ते थेट उघडल्यास, नवीन वापरकर्ता अनुभव व्यत्यय आणला जाईल.
केस 2 - अपरिवर्तनीय वितरण. एका टीमने सर्व ट्रॅफिकसाठी एक नवीन किंमत मॉडेल आणले, कोणत्याही रोलबॅक प्लॅनशिवाय. मॉडेलने अनपेक्षितपणे काही उत्पादनांची किंमत खूपच स्वस्त केली. जुन्या आवृत्तीवर परत येण्यासाठी काही तास लागले कारण प्रक्रिया तयार नव्हती. उत्पन्नाचे मोठे नुकसान झाले. त्यानंतर, प्रत्येक तैनातीमध्ये अनिवार्य रोलबॅक चाचणी जोडली गेली.
केस 3 - सायलेंट डेटा ड्रिफ्ट. एक फसवणूक नमुना काही महिन्यांसाठी कोणत्याही त्रुटीशिवाय दिसून आला. परंतु फसवणूक करणाऱ्यांचे डावपेच बदलले (डेटा ड्रिफ्ट) आणि मॉडेलचे रिकॉल शांतपणे सोडले. निगराणी नसल्याने कोणाच्याही लक्षात आले नाही. एकदा अंदाज वितरण मॉनिटरिंग पॅनेलची स्थापना झाल्यानंतर, प्रवाह लवकर दिसला. आम्ही युनिट 8 मध्ये मॉनिटरिंग कव्हर करू.
कॉपी करण्यायोग्य टेम्पलेट्स
या मॉडेलसाठी एक मसुदा उपयोजन योजना लिहा. मॉडेल: [ते काय करते], वापर: [ऑनलाइन किंवा बॅच?] यामध्ये समाविष्ट असावे: 1) पॅकेजिंग (कंटेनर, आवृत्ती) 2) वाढीव उपयोजन धोरण (छाया/कॅनरी/ए-बी) आणि का 3) मागोवा घेण्यासाठी मेट्रिक्स (व्यवसाय + तांत्रिक + विलंब) 4) रोलबॅक योजना आणि चाचणी कशी करावी 5) डिप्लॉयमेंटचे अतिरिक्त मूल्य किती असावे)
ही ML CI/CD पाइपलाइन तपासा: 1) डेटा प्रमाणीकरण लाइनमध्ये आहे का? 2) मूल्यमापन थ्रेशोल्ड न ठेवता उपयोजन पुढे जाऊ शकते का (ते नसावे)? 3) रोलबॅक ऑटोमॅटिक आहे का? 4) मॉडेल रेजिस्ट्रीमध्ये डेटा+कोड+मेट्रिक्सचा मागोवा घेतला गेला आहे का? प्लेन कॉन्फिगरेशन: [कॉन्फिगरेशन]
या मॉडेलसाठी ऑनलाइन किंवा बॅच प्रेझेंटेशन योग्य आहे की नाही हे ठरविण्यात मला मदत करा. परिणाम किती काळ वापरला जाईल: [त्वरित / मिनिट / तास / दिवस] अपेक्षित विनंती खंड: [संख्या] विलंब मर्यादा आहे का: [ms] तुम्ही किंमत आणि जटिलतेच्या दृष्टीने कोणती शिफारस कराल आणि का?
या मॉडेलसाठी रोलबॅक प्रक्रिया लिहा.- कोणती मेट्रिक/थ्रेशोल्ड खराब कार्यप्रदर्शन ट्रिगर करते?- रोलबॅक पायऱ्या काय आहेत?- रोलबॅक किती वेळ घ्यावा (लक्ष्य)?- उत्पादनापूर्वी मी या प्रक्रियेची चाचणी कशी करू?
सादरीकरण नमुना सारणी
निकष
ऑनलाइन (रिअल टाइम)
बॅच
विलंब
गंभीर (ms)
नगण्य
वापर
त्वरित प्रतिसाद आवश्यक
नियतकालिक स्कोअर
खर्च
उच्च
कमी
गुंतागुंत
उच्च
कमी
उदाहरण
थेट शिफारस, घोटाळा
मासिक जोखीम स्कोअर
सामान्य चुका
- पुनर्प्राप्तीच्या योजनेशिवाय वितरित करा. चुकीचे मॉडेल संपूर्ण वापरकर्त्याला मारते.
- थेट 100% रहदारीसाठी उघडत आहे. स्तब्ध वितरणासह जोखीम मर्यादित करा.
- देखरेख स्थापित करत नाही. मॉडेल त्रुटीशिवाय, शांतपणे त्रुटी निर्माण करते.
- निरर्थक रिअल-टाइम सादरीकरण. बॅचिंग पुरेसे असताना, खर्च आणि जटिलता वाढते.
- मॉडेल-डेटा-कोड आवृत्त्यांशी दुवा साधत नाही. आपण समस्येचे पुनरुत्पादन करू शकत नाही.
- वितरण थ्रेशोल्ड नसलेले स्वयंचलित प्रकाशन. वाईट मॉडेल शांतपणे आत डोकावते.
सारांशात
मॉडेलला उत्पादनाकडे नेणे हे प्रशिक्षण देण्यापेक्षा वेगळे आणि बरेचदा कठीण अभियांत्रिकी कार्य आहे. ML ला अतिरिक्त शिस्तीची आवश्यकता असते कारण ते कोड-डेटा-मॉडेल त्रिकूटावर अवलंबून असते: पॅकेजिंग आणि व्हर्जनिंग, डिलिव्हरी पॅटर्न (ऑनलाइन/बॅच), जो व्यवसायाच्या गरजेनुसार आहे, हळूहळू आणि उलट करता येण्याजोगा तैनाती, थ्रेशोल्ड-नियंत्रित CI/CD आणि मॉडेल नोंदणी. या पायाभूत सुविधांचे कोड आणि कॉन्फिगरेशन तयार करण्यासाठी कृत्रिम बुद्धिमत्ता ही एक शक्तिशाली मदत आहे; परंतु वितरण थ्रेशोल्ड, क्लॉबॅक धोरण आणि जोखीम निर्णय तुमचे आहेत. रोलबॅक योजनेशिवाय वितरण पूर्ण होत नाही.
अर्ज कार्य
कंटेनर (डॉकर) मॉडेल करा आणि त्यास आवृत्ती लेबल करा. तुमच्या व्यवसायाच्या गरजेनुसार तुम्ही ऑनलाइन ऑफर कराल की बॅच द्याल हे ठरवा आणि तुमचे औचित्य लिहा. टप्प्याटप्प्याने उपयोजन योजना (सावली किंवा कॅनरी) आणि चाचणी केलेली रोलबॅक प्रक्रिया दस्तऐवजीकरण करा. मॉडेल रेजिस्ट्रीमध्ये डेटा आवृत्ती, कोड कमिट आणि मूल्यमापन स्कोअर रेकॉर्ड केल्याचे सुनिश्चित करा.
चेकलिस्ट
- [] मॉडेल पॅकेज केलेले आणि आवृत्ती केलेले आहे (कंटेनर + लेबल).
- व्यवसायाच्या गरजेनुसार सादरीकरण नमुना (ऑनलाइन/बॅच) निवडला गेला.
- [] स्टेज्ड डिप्लॉयमेंट स्ट्रॅटेजी (सावली/कॅनरी) लागू केली.
- [] रोलबॅक प्रक्रिया लिखित आणि चाचणी केली.
- [ ] CI/CD मूल्यमापन थ्रेशोल्ड पूर्ण होण्यापूर्वी तैनाती वाढवत नाही.
- मॉडेल रेजिस्ट्रीमध्ये डेटा+कोड+मेट्रिक लिंक असते.