🥇औद्योगिक मेसिन लर्निङ: विकासका १० सिद्धान्तहरू

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

आजकल, नयाँ सेवाहरू, अनुप्रयोगहरू र अन्य महत्त्वपूर्ण कार्यक्रमहरू हरेक दिन सिर्जना गरिन्छन् जसले अविश्वसनीय चीजहरू सिर्जना गर्न सम्भव बनाउँदछ: स्पेसएक्स रकेट नियन्त्रण गर्न सफ्टवेयरबाट अर्को कोठामा स्मार्टफोन मार्फत केतलीसँग अन्तरक्रिया गर्न।

र, कहिलेकाहीँ, हरेक नौसिखिया प्रोग्रामर, चाहे त्यो एक भावुक स्टार्टअप होस् वा साधारण फुल स्ट्याक वा डाटा वैज्ञानिक, ढिलो होस् वा ढिलो यो अनुभवमा आउँछ कि प्रोग्रामिङ र सफ्टवेयर सिर्जना गर्नका लागि निश्चित नियमहरू छन् जसले जीवनलाई धेरै सरल बनाउँछ।

यस लेखमा, म 10-कारक एप पद्धतिको आधारमा, सजिलैसँग अनुप्रयोग/सेवामा एकीकृत गर्न सकोस् भनेर औद्योगिक मेसिन लर्निङलाई कसरी प्रोग्राम गर्ने भनेर 12 सिद्धान्तहरू संक्षिप्त रूपमा वर्णन गर्नेछु। Heroku टोली द्वारा सुझाव। मेरो पहल यस प्रविधिको जागरूकता बढाउन हो, जसले धेरै विकासकर्ताहरू र डेटा विज्ञान मानिसहरूलाई मद्दत गर्न सक्छ।

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

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

केही प्रोग्रामरहरू पहिलो चरणहरूमा, यो पत्ता लगाउन अल्छीपनबाट बाहिर (वा आफ्नै कारणको लागि), Git को बारेमा बिर्सन्छन्। तिनीहरू या त शब्द पूर्ण रूपमा बिर्सन्छन्, अर्थात्, तिनीहरूले ड्राइभमा एकअर्कालाई फाइलहरू फाल्छन्/केवल पाठ फाल्छन्/परेवाहरूद्वारा पठाउँछन्, वा तिनीहरूले आफ्नो कार्यप्रवाहको माध्यमबाट सोच्दैनन्, र प्रत्येकलाई आफ्नै शाखामा पठाउँछन्, र त्यसपछि। मास्टर

यो सिद्धान्त भन्छ: एउटा कोडबेस र धेरै डिप्लोइमेन्टहरू छन्।

Git दुबै उत्पादन र अनुसन्धान र विकास (R&D) मा प्रयोग गर्न सकिन्छ, जसमा यो प्रायः प्रयोग हुँदैन।

उदाहरणका लागि, R&D चरणमा तपाईले विभिन्न डेटा प्रशोधन विधिहरू र मोडेलहरूसँग कमिटहरू छोड्न सक्नुहुन्छ, त्यसपछि सबै भन्दा राम्रो चयन गर्न र सजिलैसँग यसको साथ काम जारी राख्न।

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

तपाईंले आफ्नो परियोजनाको प्याकेज पनि सिर्जना गर्न सक्नुहुन्छ, यसलाई राखेर, उदाहरणका लागि, Gemfury मा, र त्यसपछि केवल अन्य परियोजनाहरूका लागि यसबाट प्रकार्यहरू आयात गर्नुहोस्, ताकि तिनीहरूलाई 1000 पटक पुन: लेख्न नपरोस्, तर पछि त्यसमा थप।

सिद्धान्त २: निर्भरताहरू स्पष्ट रूपमा घोषणा गर्नुहोस् र अलग गर्नुहोस्

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

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

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

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

यसैले, यदि कर्ल लगभग सबै कम्प्यूटरहरूमा प्रयोग गर्न सकिन्छ भने, तपाईले अझै पनि निर्भरतामा घोषणा गर्नुपर्छ, किनकि अर्को प्लेटफर्ममा माइग्रेट गर्दा यो त्यहाँ नहुन सक्छ वा संस्करण तपाईलाई सुरुमा आवश्यक नहुन सक्छ।

उदाहरणका लागि, तपाईंको requirements.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 को ऋण लिएर उठेको कथाहरू धेरैले सुनेका छन्।

निस्सन्देह, यी घटनाहरू चरम, तर धेरै महत्त्वपूर्ण छन्। यदि तपाइँ तपाइँको प्रमाणहरू वा कोड भित्र कन्फिगरेसनको लागि आवश्यक अन्य डेटा भण्डार गर्नुहुन्छ भने, तपाइँ गल्ती गर्दै हुनुहुन्छ, र मलाई लाग्छ किन व्याख्या गर्न आवश्यक छैन।

यसको विकल्प भनेको वातावरणीय चरहरूमा कन्फिगरेसनहरू भण्डारण गर्नु हो। तपाईं वातावरण चर बारे थप पढ्न सक्नुहुन्छ यहाँ.

डेटाका उदाहरणहरू जुन सामान्यतया वातावरण चरहरूमा भण्डारण गरिन्छ:

डोमेन नामहरू
API URLs/URI's
सार्वजनिक र निजी कुञ्जीहरू
सम्पर्कहरू (मेल, फोन, आदि)

यस तरिकाले तपाइँको कन्फिगरेसन चर परिवर्तन भएमा तपाइँले लगातार कोड परिवर्तन गर्नु पर्दैन। यसले तपाईंलाई समय, प्रयास र पैसा बचत गर्न मद्दत गर्नेछ।

उदाहरणका लागि, यदि तपाइँ परीक्षणहरू सञ्चालन गर्न Kaggle API प्रयोग गर्नुहुन्छ (उदाहरणका लागि, सफ्टवेयर डाउनलोड गर्नुहोस् र मोडेल राम्रोसँग काम गर्दछ भनेर परीक्षण गर्न यसको माध्यमबाट मोडेल चलाउनुहोस्), त्यसपछि Kaggle बाट निजी कुञ्जीहरू, जस्तै KAGGLE_USERNAME र KAGGLE_KEY, हुनुपर्छ। वातावरण चर मा भण्डारण।

सिद्धान्त ४: तेस्रो पक्ष सेवाहरू

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

तेस्रो-पक्ष सेवा असक्षम गर्न वा अर्को जडान गर्नको लागि, तपाईंले वातावरण चरको कन्फिगरेसनमा कुञ्जीहरू परिवर्तन गर्न आवश्यक छ, जुन मैले माथिको अनुच्छेदमा कुरा गरेको छु।

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

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

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

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

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

रिलिज कार्यको लागि, धेरै फरक सेवाहरू सिर्जना गरिएका छन् जसमा तपाइँ आफैंलाई .yml फाइलमा चलाउन प्रक्रियाहरू लेख्न सक्नुहुन्छ (उदाहरणका लागि, CircleCI मा यो प्रक्रियालाई समर्थन गर्न config.yml हो)। व्हीली परियोजनाहरूको लागि प्याकेजहरू सिर्जना गर्न उत्कृष्ट छ।

तपाईंले आफ्नो मेसिन लर्निङ मोडेलका विभिन्न संस्करणहरूसँग प्याकेजहरू सिर्जना गर्न सक्नुहुन्छ, र त्यसपछि तिनीहरूलाई प्याकेज गर्नुहोस् र आवश्यक प्याकेजहरू र तिनीहरूका संस्करणहरूलाई तपाईंले त्यहाँबाट लेख्नुभएको कार्यहरू प्रयोग गर्न सन्दर्भ गर्नुहोस्। यसले तपाइँलाई तपाइँको मोडेलको लागि API सिर्जना गर्न मद्दत गर्दछ, र तपाइँको प्याकेज Gemfury मा होस्ट गर्न सकिन्छ, उदाहरण को लागी।

सिद्धान्त 6. एक वा धेरै प्रक्रियाहरूको रूपमा आफ्नो मोडेल चलाउनुहोस्

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

त्यो हो, यो निश्चित रूपमा प्रक्रिया फाइल प्रणाली भित्र डाटा भण्डारण गर्न लायक छैन, अन्यथा यसले अर्को रिलीज / कन्फिगरेसन परिवर्तन वा कार्यक्रम चल्ने प्रणालीको स्थानान्तरणको समयमा यो डाटा खाली गर्न नेतृत्व गर्न सक्छ।

तर त्यहाँ एउटा अपवाद छ: मेसिन लर्निङ प्रोजेक्टहरूका लागि, तपाईंले पुस्तकालयहरूको क्यास भण्डारण गर्न सक्नुहुन्छ ताकि कुनै पनि अतिरिक्त पुस्तकालयहरू वा तिनीहरूको संस्करणहरूमा कुनै परिवर्तनहरू नगरिएका खण्डमा तपाईंले नयाँ संस्करण सुरु गर्दा तिनीहरूलाई पुन: स्थापना नगर्न सक्नुहुन्छ। यस तरिकाले, तपाईंले उद्योगमा आफ्नो मोडेल सुरु गर्न लाग्ने समय कम गर्नुहुनेछ।

मोडेललाई धेरै प्रक्रियाहरूको रूपमा चलाउनको लागि, तपाईंले .yml फाइल सिर्जना गर्न सक्नुहुन्छ जसमा तपाईंले आवश्यक प्रक्रियाहरू र तिनीहरूको अनुक्रम निर्दिष्ट गर्नुहुन्छ।

सिद्धान्त 7: पुन: प्रयोग योग्यता

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

त्यो हो, मोडेलको साथ तपाईंको प्रक्रिया:

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

सिद्धान्त ८: निरन्तर परिनियोजन/एकीकरण

धेरै कम्पनीहरूले एप्लिकेसन डेभलपमेन्ट र डिप्लोइमेन्ट टोलीहरू (अन्तिम प्रयोगकर्ताहरूका लागि अनुप्रयोग उपलब्ध गराउने) बीचको विभाजन प्रयोग गर्छन्। यसले सफ्टवेयरको विकास र यसलाई सुधार गर्न प्रगतिलाई धेरै ढिलो गर्न सक्छ। यसले DevOps संस्कृतिलाई पनि बिगार्छ, जहाँ विकास र एकीकरण, मोटामोटी रूपमा, संयुक्त छन्।

तसर्थ, यो सिद्धान्तले बताउँछ कि तपाईंको विकास वातावरण तपाईंको उत्पादन वातावरणसँग सम्भव भएसम्म नजिक हुनुपर्छ।

यसले अनुमति दिनेछ:

दसौं पटक रिलीज समय घटाउनुहोस्
कोड असंगतिको कारण त्रुटिहरूको संख्या घटाउनुहोस्।
यसले कर्मचारीहरूमा कामको बोझ पनि कम गर्छ, किनकि विकासकर्ताहरू र अनुप्रयोग प्रयोग गर्ने व्यक्तिहरू अब एउटै टोली हुन्।

सर्कलसीआई, ट्राभिस सीआई, गिटल्याब सीआई र अन्य हुन्।

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

भिन्नताहरू कम गर्नुहोस् !!!

सिद्धान्त 9. तपाईंको लगहरू

लगहरू (वा "लगहरू") घटनाहरू हुन्, सामान्यतया पाठ ढाँचामा रेकर्ड हुन्छन्, जुन एप (घटना स्ट्रिम) भित्र हुन्छ। एक साधारण उदाहरण: "2020-02-02 - प्रणाली स्तर - प्रक्रिया नाम।" तिनीहरू डिजाइन गरिएका छन् ताकि विकासकर्ताले कार्यक्रम चलिरहेको बेला के भइरहेको छ भनेर शाब्दिक रूपमा हेर्न सक्छ। उसले प्रक्रियाहरूको प्रगति देख्छ र बुझ्छ कि यो विकासकर्ता आफैंले चाहेको हो कि होइन।

यो सिद्धान्तले बताउँछ कि तपाईंले आफ्नो फाइल प्रणाली भित्र आफ्नो लगहरू भण्डारण गर्नु हुँदैन - तपाईंले तिनीहरूलाई स्क्रिनमा "आउटपुट" मात्र गर्नुपर्छ, उदाहरणका लागि, यो प्रणालीको मानक आउटपुटमा गर्नुहोस्। र यस तरिकाले विकासको क्रममा टर्मिनलमा प्रवाह अनुगमन गर्न सम्भव हुनेछ।

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

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

औद्योगिक मेसिन लर्निङको लागि, यो चरण अत्यन्त महत्त्वपूर्ण छ, किनकि तपाईंले यो बुझ्न आवश्यक छ कि मोडेलले सही रूपमा काम गर्दछ र तपाईंले चाहेको कुरा उत्पादन गर्दछ।

परीक्षणहरू pytest प्रयोग गरेर सिर्जना गर्न सकिन्छ, र यदि तपाईंसँग रिग्रेसन/वर्गीकरण कार्य छ भने सानो डेटासेट प्रयोग गरेर परीक्षण गर्न सकिन्छ।

गहिरो सिकाइ मोडेलहरूको लागि एउटै बीउ सेट गर्न नबिर्सनुहोस् ताकि तिनीहरू लगातार फरक परिणामहरू उत्पादन गर्दैनन्।

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

म पनि राम्रो सिद्धान्तहरू प्रयोग गर्ने प्रयास गर्नेछु जुन जो कोहीले टिप्पणीहरूमा छोड्न सक्छन् यदि तिनीहरू चाहन्छन्।

स्रोत: www.habr.com

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

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

एक टिप्पणी थप्न Отменить ответ