🥇औद्योगिक मशीन लर्निंग: विकास के 10 सिद्धांत

औद्योगिक मशीन लर्निंग: 10 डिज़ाइन सिद्धांत

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

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

इस लेख में, मैं संक्षेप में औद्योगिक मशीन लर्निंग को प्रोग्राम करने के 10 सिद्धांतों का वर्णन करूंगा ताकि इसे 12-कारक ऐप पद्धति के आधार पर किसी एप्लिकेशन/सेवा में आसानी से एकीकृत किया जा सके। हेरोकू टीम द्वारा सुझाया गया. मेरी पहल इस तकनीक के बारे में जागरूकता बढ़ाना है, जिससे कई डेवलपर्स और डेटा विज्ञान से जुड़े लोगों को मदद मिल सकती है।

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

सिद्धांत 1: एक कोड आधार

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

यह सिद्धांत बताता है: एक कोडबेस और कई परिनियोजन हैं।

Git का उपयोग उत्पादन और अनुसंधान एवं विकास (R&D) दोनों में किया जा सकता है, जिसमें इसका उपयोग अक्सर नहीं किया जाता है।

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

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

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

सिद्धांत 2: निर्भरताओं को स्पष्ट रूप से घोषित और अलग करें

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

निर्भरताओं को स्पष्ट रूप से घोषित करें, अर्थात, एक फ़ाइल जिसमें आपके प्रोजेक्ट में उपयोग की जाने वाली सभी लाइब्रेरी, टूल और उनके संस्करण शामिल होंगे और जिन्हें इंस्टॉल किया जाना चाहिए (उदाहरण के लिए, पायथन में यह पिपफ़ाइल या आवश्यकताओं.txt का उपयोग करके किया जा सकता है। ए लिंक जो अच्छी तरह से समझने की अनुमति देता है: realpython.com/pipenv-guide)
विकास के दौरान अपने प्रोग्राम के लिए विशेष रूप से निर्भरताएँ अलग करें। आप लगातार संस्करण बदलना और पुनः स्थापित नहीं करना चाहते, उदाहरण के लिए, टेन्सरफ़्लो?

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

आपके एप्लिकेशन को उन सिस्टम टूल्स पर भी निर्भर नहीं रहना चाहिए जो किसी विशिष्ट ओएस पर इंस्टॉल किए जा सकते हैं। इन उपकरणों को निर्भरता मैनिफ़ेस्ट में भी घोषित किया जाना चाहिए। यह उन स्थितियों से बचने के लिए आवश्यक है जहां टूल का संस्करण (साथ ही उनकी उपलब्धता) किसी विशेष ओएस के सिस्टम टूल से मेल नहीं खाता है।

इस प्रकार, भले ही कर्ल का उपयोग लगभग सभी कंप्यूटरों पर किया जा सकता है, फिर भी आपको इसे निर्भरता में घोषित करना चाहिए, क्योंकि किसी अन्य प्लेटफ़ॉर्म पर माइग्रेट करते समय यह वहां नहीं हो सकता है या संस्करण वह नहीं होगा जिसकी आपको मूल रूप से आवश्यकता थी।

उदाहरण के लिए, आपकी require.txt इस तरह दिख सकती है:

# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0

# testing requirements
pytest>=5.3.2,<6.0.0

# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0

# fetching datasets
kaggle>=1.5.6,<1.6.0

सिद्धांत 3: विन्यास

कई लोगों ने विभिन्न डेवलपर लोगों द्वारा गलती से AWS के पासवर्ड और अन्य कुंजियों के साथ सार्वजनिक रिपॉजिटरी में GitHub पर कोड अपलोड करने की कहानियाँ सुनी हैं, और अगले दिन $ 6000 या $ 50000 के ऋण के साथ जागते हैं।

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

इसका एक विकल्प कॉन्फ़िगरेशन को पर्यावरण चर में संग्रहीत करना है। आप पर्यावरण चर के बारे में अधिक पढ़ सकते हैं यहां.

डेटा के उदाहरण जो आमतौर पर पर्यावरण चर में संग्रहीत होते हैं:

कार्यक्षेत्र नाम
एपीआई यूआरएल/यूआरआई
सार्वजनिक और निजी कुंजी
संपर्क (मेल, फ़ोन, आदि)

इस तरह यदि आपके कॉन्फ़िगरेशन चर बदलते हैं तो आपको लगातार कोड बदलने की ज़रूरत नहीं है। इससे आपका समय, प्रयास और पैसा बचाने में मदद मिलेगी।

उदाहरण के लिए, यदि आप परीक्षण करने के लिए कागल एपीआई का उपयोग करते हैं (उदाहरण के लिए, सॉफ़्टवेयर डाउनलोड करें और मॉडल को चलाने के दौरान परीक्षण करने के लिए इसके माध्यम से मॉडल चलाएं), तो कागल से निजी कुंजी, जैसे कि KAGGLE_USERNAME और KAGGLE_KEY, होनी चाहिए पर्यावरण चर में संग्रहीत।

सिद्धांत 4: तृतीय पक्ष सेवाएँ

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

किसी तृतीय-पक्ष सेवा को अक्षम करने या किसी अन्य को कनेक्ट करने के लिए, आपको बस पर्यावरण चर में कॉन्फ़िगरेशन में कुंजियों को बदलने की आवश्यकता है, जिसके बारे में मैंने ऊपर पैराग्राफ में बात की थी।

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

सिद्धांत 5. निर्माण, रिलीज़, रनटाइम

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

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

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

रिलीज़ कार्य के लिए, कई अलग-अलग सेवाएँ बनाई गई हैं जिनमें आप स्वयं को .yml फ़ाइल में चलाने के लिए प्रक्रियाएँ लिख सकते हैं (उदाहरण के लिए, सर्कलसीआई में यह प्रक्रिया का समर्थन करने के लिए config.yml है)। व्हीली परियोजनाओं के लिए पैकेज बनाने में महान है।

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

सिद्धांत 6. अपने मॉडल को एक या अधिक प्रक्रियाओं के रूप में चलाएँ

इसके अलावा, प्रक्रियाओं में साझा डेटा नहीं होना चाहिए। अर्थात्, प्रक्रियाएँ अलग-अलग मौजूद होनी चाहिए, और सभी प्रकार के डेटा अलग-अलग मौजूद होने चाहिए, उदाहरण के लिए, MySQL या अन्य जैसी तृतीय-पक्ष सेवाओं पर, जो आपकी ज़रूरत पर निर्भर करता है।

यानी, यह निश्चित रूप से प्रक्रिया फ़ाइल सिस्टम के अंदर डेटा संग्रहीत करने के लायक नहीं है, अन्यथा इससे अगली रिलीज/कॉन्फ़िगरेशन के परिवर्तन या उस सिस्टम के स्थानांतरण के दौरान इस डेटा को साफ़ किया जा सकता है जिस पर प्रोग्राम चलता है।

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

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

सिद्धांत 7: पुनर्चक्रण क्षमता

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

अर्थात्, मॉडल के साथ आपकी प्रक्रिया यह होनी चाहिए:

स्टार्टअप समय कम से कम करें. आदर्श रूप से, स्टार्टअप समय (स्टार्टअप कमांड जारी होने के क्षण से लेकर प्रक्रिया के संचालन में आने तक) कुछ सेकंड से अधिक नहीं होना चाहिए। ऊपर वर्णित लाइब्रेरी कैशिंग, स्टार्टअप समय को कम करने की एक तकनीक है।
सही ढंग से समाप्त करें. यानी, सर्विस पोर्ट पर सुनना वास्तव में निलंबित है, और इस पोर्ट पर सबमिट किए गए नए अनुरोध संसाधित नहीं किए जाएंगे। यहां आपको या तो DevOps इंजीनियरों के साथ अच्छा संचार स्थापित करने की आवश्यकता है, या यह समझना होगा कि यह कैसे काम करता है (अधिमानतः, निश्चित रूप से बाद वाला, लेकिन किसी भी प्रोजेक्ट में संचार हमेशा बनाए रखा जाना चाहिए!)

सिद्धांत 8: सतत तैनाती/एकीकरण

कई कंपनियां एप्लिकेशन विकास और परिनियोजन टीमों के बीच अलगाव का उपयोग करती हैं (एप्लिकेशन को अंतिम उपयोगकर्ताओं के लिए उपलब्ध कराती है)। यह सॉफ़्टवेयर विकास और उसे सुधारने की प्रगति को बहुत धीमा कर सकता है। यह DevOps संस्कृति को भी ख़राब करता है, जहाँ विकास और एकीकरण, मोटे तौर पर, संयुक्त हैं।

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

यह अनुमति देगा:

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

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

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

मतभेद कम करें!!!

सिद्धांत 9. आपके लॉग

लॉग (या "लॉग") ईवेंट हैं, जो आमतौर पर टेक्स्ट प्रारूप में रिकॉर्ड किए जाते हैं, जो एप्लिकेशन (इवेंट स्ट्रीम) के भीतर होते हैं। एक सरल उदाहरण: "2020-02-02 - सिस्टम स्तर - प्रक्रिया का नाम।" इन्हें डिज़ाइन किया गया है ताकि डेवलपर सचमुच देख सके कि प्रोग्राम चलने पर क्या हो रहा है। वह प्रक्रियाओं की प्रगति को देखता है और समझता है कि क्या यह वैसा ही है जैसा डेवलपर ने स्वयं चाहा था।

यह सिद्धांत बताता है कि आपको अपने लॉग को अपने फ़ाइल सिस्टम के अंदर संग्रहीत नहीं करना चाहिए - आपको उन्हें केवल स्क्रीन पर "आउटपुट" करना चाहिए, उदाहरण के लिए, सिस्टम के मानक आउटपुट पर ऐसा करें। और इस तरह विकास के दौरान टर्मिनल में प्रवाह की निगरानी करना संभव होगा।

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

सिद्धांत 10. परीक्षण!

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

पाइटेस्ट का उपयोग करके परीक्षण बनाए जा सकते हैं, और यदि आपके पास प्रतिगमन/वर्गीकरण कार्य है तो एक छोटे डेटासेट का उपयोग करके परीक्षण किया जा सकता है।

गहन शिक्षण मॉडल के लिए एक ही बीज सेट करना न भूलें ताकि वे लगातार अलग-अलग परिणाम न दें।

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

मैं अच्छे सिद्धांतों का उपयोग करने का भी प्रयास करूंगा जिन्हें कोई भी चाहें तो टिप्पणियों में छोड़ सकता है।

स्रोत: www.habr.com

औद्योगिक मशीन लर्निंग: 10 डिज़ाइन सिद्धांत

औद्योगिक मशीन लर्निंग: 10 डिज़ाइन सिद्धांत

एक टिप्पणी जोड़ें उत्तर रद्द