ઔદ્યોગિક મશીન લર્નિંગ: 10 ડિઝાઇન સિદ્ધાંતો

ઔદ્યોગિક મશીન લર્નિંગ: 10 ડિઝાઇન સિદ્ધાંતો

આજકાલ, નવી સેવાઓ, એપ્લિકેશનો અને અન્ય મહત્વપૂર્ણ પ્રોગ્રામ્સ દરરોજ બનાવવામાં આવે છે જે અકલ્પનીય વસ્તુઓ બનાવવાનું શક્ય બનાવે છે: સ્પેસએક્સ રોકેટને નિયંત્રિત કરવા માટેના સૉફ્ટવેરથી લઈને સ્માર્ટફોન દ્વારા આગલા રૂમમાં કેટલ સાથે ક્રિયાપ્રતિક્રિયા કરવા સુધી.

અને, કેટલીકવાર, દરેક શિખાઉ પ્રોગ્રામર, પછી ભલે તે જુસ્સાદાર સ્ટાર્ટઅપર હોય કે સામાન્ય ફુલ સ્ટેક અથવા ડેટા સાયન્ટિસ્ટ હોય, વહેલા કે મોડા એ ખ્યાલ આવે છે કે પ્રોગ્રામિંગ અને સોફ્ટવેર બનાવવા માટે અમુક નિયમો છે જે જીવનને ખૂબ સરળ બનાવે છે.

આ લેખમાં, હું ઔદ્યોગિક મશીન શિક્ષણને કેવી રીતે પ્રોગ્રામ કરવું તેના 10 સિદ્ધાંતોનું સંક્ષિપ્તમાં વર્ણન કરીશ જેથી 12-પરિબળ એપ્લિકેશન પદ્ધતિના આધારે તેને એપ્લિકેશન/સેવામાં સરળતાથી સંકલિત કરી શકાય. Heroku ટીમ દ્વારા સૂચવવામાં આવ્યું હતું. મારી પહેલ આ ટેકનિકની જાગૃતિ વધારવાની છે, જે ઘણા ડેવલપર્સ અને ડેટા સાયન્સ લોકોને મદદ કરી શકે છે.

આ લેખ ઔદ્યોગિક મશીન લર્નિંગ વિશેના લેખોની શ્રેણીનો પ્રસ્તાવના છે. તેમાં હું આગળ વાત કરીશ કે વાસ્તવમાં મોડેલ કેવી રીતે બનાવવું અને તેને પ્રોડક્શનમાં કેવી રીતે લોંચ કરવું, તેના માટે એક API બનાવવું, તેમજ તેમની સિસ્ટમમાં બિલ્ટ-ઇન ML ધરાવતા વિવિધ ક્ષેત્રો અને કંપનીઓના ઉદાહરણો.

સિદ્ધાંત 1: એક કોડ બેઝ

પ્રથમ તબક્કામાં કેટલાક પ્રોગ્રામરો, તેને શોધવાની આળસને કારણે (અથવા તેમના પોતાના કોઈ કારણોસર), ગિટ વિશે ભૂલી જાય છે. તેઓ કાં તો શબ્દ સંપૂર્ણપણે ભૂલી જાય છે, એટલે કે, તેઓ ડ્રાઇવમાં એકબીજાને ફાઇલો ફેંકી દે છે/ફક્ત ટેક્સ્ટ ફેંકે છે/કબૂતરો દ્વારા મોકલે છે, અથવા તેઓ તેમના વર્કફ્લો દ્વારા વિચારતા નથી, અને દરેકને તેમની પોતાની શાખામાં મોકલે છે, અને પછી માસ્ટર

આ સિદ્ધાંત જણાવે છે: એક કોડબેઝ અને ઘણી જમાવટ છે.

Git નો ઉપયોગ ઉત્પાદન અને સંશોધન અને વિકાસ (R&D) બંનેમાં થઈ શકે છે, જેમાં તેનો વારંવાર ઉપયોગ થતો નથી.

ઉદાહરણ તરીકે, R&D તબક્કામાં તમે અલગ-અલગ ડેટા પ્રોસેસિંગ પદ્ધતિઓ અને મોડલ્સ સાથે કમિટ છોડી શકો છો, જેથી પછી શ્રેષ્ઠને પસંદ કરી શકાય અને તેની સાથે આગળ કામ કરવાનું ચાલુ રાખો.

બીજું, ઉત્પાદનમાં આ એક બદલી ન શકાય તેવી વસ્તુ છે - તમારે સતત જોવાની જરૂર પડશે કે તમારો કોડ કેવી રીતે બદલાય છે અને જાણવાની જરૂર પડશે કે કયા મોડેલે શ્રેષ્ઠ પરિણામો આપ્યા, કયા કોડે અંતે કામ કર્યું અને શું થયું જેના કારણે તે કામ કરવાનું બંધ કરે છે અથવા ખોટા પરિણામો આપવાનું શરૂ કરે છે. . તે માટે પ્રતિબદ્ધતાઓ છે!

તમે તમારા પ્રોજેક્ટનું પેકેજ પણ બનાવી શકો છો, ઉદાહરણ તરીકે, જેમફ્યુરી પર મૂકીને, અને પછી અન્ય પ્રોજેક્ટ્સ માટે ફક્ત તેમાંથી ફંક્શન્સ આયાત કરી શકો છો, જેથી તેને 1000 વખત ફરીથી લખવામાં ન આવે, પરંતુ તે પછીથી વધુ.

સિદ્ધાંત 2: નિર્ભરતાને સ્પષ્ટપણે જાહેર કરો અને અલગ કરો

દરેક પ્રોજેક્ટમાં અલગ-અલગ લાઇબ્રેરીઓ હોય છે જેને તમે ક્યાંક લાગુ કરવા માટે બહારથી આયાત કરો છો. પછી ભલે તે પાયથોન પુસ્તકાલયો હોય, અથવા વિવિધ હેતુઓ માટે અન્ય ભાષાઓની પુસ્તકાલયો, અથવા સિસ્ટમ ટૂલ્સ - તમારું કાર્ય છે:

• સ્પષ્ટપણે નિર્ભરતા જાહેર કરો, એટલે કે, એક ફાઇલ કે જેમાં તમારા પ્રોજેક્ટમાં ઉપયોગમાં લેવાતી તમામ લાઇબ્રેરીઓ, ટૂલ્સ અને તેમના વર્ઝનનો સમાવેશ થશે અને તે ઇન્સ્ટોલ કરેલ હોવું જ જોઈએ (ઉદાહરણ તરીકે, પાયથોનમાં આ Pipfile અથવા requirements.txt નો ઉપયોગ કરીને કરી શકાય છે. લિંક જે સારી રીતે સમજવા માટે પરવાનગી આપે છે: realpython.com/pipenv-guide)
• વિકાસ દરમિયાન તમારા પ્રોગ્રામ માટે ખાસ કરીને નિર્ભરતાને અલગ કરો. તમે સતત સંસ્કરણો બદલવા અને પુનઃસ્થાપિત કરવા માંગતા નથી, ઉદાહરણ તરીકે, ટેન્સરફ્લો?

આ રીતે, વિકાસકર્તાઓ કે જેઓ ભવિષ્યમાં તમારી ટીમમાં જોડાશે તેઓ તમારા પ્રોજેક્ટમાં ઉપયોગમાં લેવાતી લાઇબ્રેરીઓ અને તેના વર્ઝનથી ઝડપથી પરિચિત થઈ શકશે અને તમને ચોક્કસ માટે ઇન્સ્ટોલ કરેલ વર્ઝન અને લાઇબ્રેરીઓને મેનેજ કરવાની તક પણ મળશે. પ્રોજેક્ટ, જે તમને પુસ્તકાલયો અથવા તેમના સંસ્કરણોની અસંગતતા ટાળવામાં મદદ કરશે.

તમારી એપ્લિકેશન પણ ચોક્કસ 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, હોવી જોઈએ. પર્યાવરણ ચલોમાં સંગ્રહિત.

સિદ્ધાંત 4: તૃતીય પક્ષ સેવાઓ

અહીંનો વિચાર પ્રોગ્રામને એવી રીતે બનાવવાનો છે કે કોડના સંદર્ભમાં સ્થાનિક અને તૃતીય-પક્ષ સંસાધનો વચ્ચે કોઈ તફાવત ન હોય. ઉદાહરણ તરીકે, તમે સ્થાનિક MySQL અને તૃતીય-પક્ષ બંનેને કનેક્ટ કરી શકો છો. ગૂગલ મેપ્સ અથવા ટ્વિટર API જેવા વિવિધ API માટે સમાન છે.

તૃતીય-પક્ષ સેવાને અક્ષમ કરવા અથવા અન્યને કનેક્ટ કરવા માટે, તમારે ફક્ત પર્યાવરણ ચલોમાં ગોઠવણીમાં કી બદલવાની જરૂર છે, જેના વિશે મેં ઉપરના ફકરામાં વાત કરી છે.

તેથી, ઉદાહરણ તરીકે, દરેક વખતે કોડની અંદર ડેટાસેટ્સ સાથે ફાઇલોના પાથનો ઉલ્લેખ કરવાને બદલે, pathlib લાઇબ્રેરીનો ઉપયોગ કરવો અને config.py માં ડેટાસેટ્સનો પાથ જાહેર કરવો વધુ સારું છે, જેથી તમે કઈ સેવાનો ઉપયોગ કરો છો (માટે ઉદાહરણ તરીકે, CircleCI), પ્રોગ્રામ નવી સેવામાં નવી ફાઇલ સિસ્ટમની રચનાને ધ્યાનમાં લેતા ડેટાસેટ્સનો માર્ગ શોધવામાં સક્ષમ હતો.

સિદ્ધાંત 5. બિલ્ડ, રિલીઝ, રનટાઇમ

ડેટા સાયન્સમાં ઘણા લોકોને તેમની સૉફ્ટવેર લેખન કૌશલ્ય સુધારવા માટે ઉપયોગી લાગે છે. જો આપણે ઇચ્છીએ છીએ કે અમારો પ્રોગ્રામ શક્ય તેટલો ભાગ્યે જ ક્રેશ થાય અને શક્ય તેટલા લાંબા સમય સુધી નિષ્ફળતા વિના કાર્ય કરે, તો અમારે નવા સંસ્કરણને રિલીઝ કરવાની પ્રક્રિયાને 3 તબક્કામાં વહેંચવાની જરૂર છે:

1. સ્ટેજ વિધાનસભાઓ. તમે વ્યક્તિગત સંસાધનો સાથે તમારા બેર કોડને કહેવાતા પેકેજમાં રૂપાંતરિત કરો છો જેમાં તમામ જરૂરી કોડ અને ડેટા હોય છે. આ પેકેજને એસેમ્બલી કહેવામાં આવે છે.
2. સ્ટેજ પ્રકાશન — અહીં અમે અમારી રૂપરેખાને એસેમ્બલી સાથે જોડીએ છીએ, જેના વિના અમે અમારો પ્રોગ્રામ રિલીઝ કરી શકતા નથી. હવે આ સંપૂર્ણ રીતે તૈયાર-થી-લોન્ચ રિલીઝ છે.
3. આગળ સ્ટેજ આવે છે પરિપૂર્ણતા. અહીં અમે અમારા પ્રકાશનમાંથી જરૂરી પ્રક્રિયાઓ ચલાવીને એપ્લિકેશનને રિલીઝ કરીએ છીએ.

મોડેલના નવા સંસ્કરણો અથવા સમગ્ર પાઇપલાઇનને રિલીઝ કરવા માટેની આવી સિસ્ટમ તમને એડમિનિસ્ટ્રેટર્સ અને વિકાસકર્તાઓ વચ્ચેની ભૂમિકાઓને અલગ કરવાની મંજૂરી આપે છે, તમને સંસ્કરણોને ટ્રૅક કરવાની મંજૂરી આપે છે અને પ્રોગ્રામના અનિચ્છનીય સ્ટોપ્સને અટકાવે છે.

પ્રકાશન કાર્ય માટે, ઘણી જુદી જુદી સેવાઓ બનાવવામાં આવી છે જેમાં તમે તમારી જાતને .yml ફાઇલમાં ચલાવવા માટે પ્રક્રિયાઓ લખી શકો છો (ઉદાહરણ તરીકે, CircleCI માં આ પ્રક્રિયાને સમર્થન આપવા માટે config.yml છે). વ્હીલી પ્રોજેક્ટ્સ માટે પેકેજો બનાવવા માટે મહાન છે.

તમે તમારા મશીન લર્નિંગ મોડલના વિવિધ સંસ્કરણો સાથે પેકેજો બનાવી શકો છો, અને પછી તેમને પેકેજ કરી શકો છો અને તમે ત્યાંથી લખેલા કાર્યોનો ઉપયોગ કરવા માટે જરૂરી પેકેજો અને તેમના સંસ્કરણોનો સંદર્ભ લો. આ તમને તમારા મોડેલ માટે API બનાવવામાં મદદ કરશે, અને ઉદાહરણ તરીકે તમારું પેકેજ Gemfury પર હોસ્ટ કરી શકાય છે.

સિદ્ધાંત 6. તમારા મોડેલને એક અથવા વધુ પ્રક્રિયાઓ તરીકે ચલાવો

તદુપરાંત, પ્રક્રિયાઓમાં ડેટા શેર ન હોવો જોઈએ. એટલે કે, પ્રક્રિયાઓ અલગથી અસ્તિત્વમાં હોવી જોઈએ, અને તમામ પ્રકારના ડેટા અલગથી અસ્તિત્વમાં હોવા જોઈએ, ઉદાહરણ તરીકે, MySQL અથવા અન્ય જેવી તૃતીય-પક્ષ સેવાઓ પર, તમને જેની જરૂર છે તેના આધારે.

એટલે કે, પ્રક્રિયા ફાઇલ સિસ્ટમની અંદર ડેટા સંગ્રહિત કરવા તે ચોક્કસપણે યોગ્ય નથી, અન્યથા આનાથી આગામી પ્રકાશન/રૂપરેખાંકનોમાં ફેરફાર અથવા પ્રોગ્રામ જેના પર ચાલે છે તે સિસ્ટમના સ્થાનાંતરણ દરમિયાન આ ડેટા સાફ થઈ શકે છે.

પરંતુ તેમાં એક અપવાદ છે: મશીન લર્નિંગ પ્રોજેક્ટ્સ માટે, તમે લાઇબ્રેરીઓનો કેશ સ્ટોર કરી શકો છો જેથી કરીને જ્યારે પણ તમે નવું વર્ઝન લોંચ કરો ત્યારે તેને ફરીથી ઇન્સ્ટોલ ન કરો, જો કોઈ વધારાની લાઇબ્રેરીઓ અથવા તેના વર્ઝનમાં કોઈ ફેરફાર કરવામાં આવ્યો ન હોય. આ રીતે, તમે તમારા મૉડલને ઉદ્યોગમાં લૉન્ચ કરવામાં લાગતો સમય ઘટાડશો.

મોડેલને ઘણી પ્રક્રિયાઓ તરીકે ચલાવવા માટે, તમે .yml ફાઇલ બનાવી શકો છો જેમાં તમે જરૂરી પ્રક્રિયાઓ અને તેમનો ક્રમ સ્પષ્ટ કરો છો.

સિદ્ધાંત 7: રિસાયકલેબલ

તમારી મોડેલ એપ્લિકેશનમાં ચાલતી પ્રક્રિયાઓ શરૂ કરવા અને રોકવા માટે સરળ હોવી જોઈએ. આમ, આ તમને કોડ ફેરફારો, રૂપરેખાંકન ફેરફારો, ઝડપથી અને લવચીક રીતે સ્કેલ કરવા અને કાર્યકારી સંસ્કરણના સંભવિત ભંગાણને રોકવા માટે ઝડપથી જમાવવાની મંજૂરી આપશે.

એટલે કે, મોડેલ સાથેની તમારી પ્રક્રિયા આ હોવી જોઈએ:

• સ્ટાર્ટઅપનો સમય ઓછો કરો. આદર્શરીતે, સ્ટાર્ટઅપનો સમય (સ્ટાર્ટઅપ કમાન્ડ જારી કરવામાં આવ્યો હતો તે ક્ષણથી પ્રક્રિયા કાર્યરત થાય તે ક્ષણ સુધી) થોડી સેકંડથી વધુ ન હોવી જોઈએ. લાઇબ્રેરી કેશીંગ, ઉપર વર્ણવેલ, સ્ટાર્ટઅપ સમય ઘટાડવા માટેની એક તકનીક છે.
• યોગ્ય રીતે સમાપ્ત કરો. એટલે કે, સેવા પોર્ટ પર સાંભળવાનું ખરેખર સસ્પેન્ડ કરવામાં આવ્યું છે, અને આ પોર્ટ પર સબમિટ કરવામાં આવેલી નવી વિનંતીઓ પર પ્રક્રિયા કરવામાં આવશે નહીં. અહીં તમારે કાં તો DevOps એન્જિનિયરો સાથે સારો સંદેશાવ્યવહાર સેટ કરવાની જરૂર છે, અથવા તે જાતે કેવી રીતે કાર્ય કરે છે તે સમજવાની જરૂર છે (પ્રાધાન્યમાં, અલબત્ત, પછીનું, પરંતુ કોઈપણ પ્રોજેક્ટમાં, સંદેશાવ્યવહાર હંમેશા જાળવી રાખવો જોઈએ!)

સિદ્ધાંત 8: સતત જમાવટ/સંકલન

ઘણી કંપનીઓ એપ્લીકેશન ડેવલપમેન્ટ અને ડિપ્લોયમેન્ટ ટીમો વચ્ચે વિભાજનનો ઉપયોગ કરે છે (અંતિમ વપરાશકર્તાઓ માટે એપ્લિકેશન ઉપલબ્ધ કરાવે છે). આ સોફ્ટવેરના વિકાસને ધીમું કરી શકે છે અને તેને સુધારવામાં પ્રગતિ કરી શકે છે. તે DevOps સંસ્કૃતિને પણ બગાડે છે, જ્યાં વિકાસ અને સંકલન, લગભગ કહીએ તો, સંયુક્ત છે.

તેથી, આ સિદ્ધાંત જણાવે છે કે તમારું વિકાસ વાતાવરણ તમારા ઉત્પાદન વાતાવરણની શક્ય એટલું નજીક હોવું જોઈએ.

આ પરવાનગી આપશે:

1. પ્રકાશનનો સમય દસ ગણો ઓછો કરો
2. કોડની અસંગતતાને કારણે ભૂલોની સંખ્યા ઘટાડવી.
3. આનાથી સ્ટાફ પર કામનું ભારણ પણ ઘટે છે, કારણ કે ડેવલપર્સ અને એપ્લિકેશન જમાવતા લોકો હવે એક ટીમ છે.

ટૂલ્સ જે તમને આની સાથે કામ કરવાની મંજૂરી આપે છે તે છે CircleCI, Travis CI, GitLab CI અને અન્ય.

તમે મોડેલમાં ઝડપથી ઉમેરો કરી શકો છો, તેને અપડેટ કરી શકો છો અને તેને તરત જ લૉન્ચ કરી શકો છો, જ્યારે નિષ્ફળતાના કિસ્સામાં, કાર્યકારી સંસ્કરણ પર ખૂબ જ ઝડપથી પાછા આવવું સરળ હશે, જેથી અંતિમ વપરાશકર્તા તેની નોંધ પણ ન લે. જો તમારી પાસે સારા પરીક્ષણો હોય તો આ ખાસ કરીને સરળતાથી અને ઝડપથી કરી શકાય છે.

તફાવતો ઓછા કરો !!!

સિદ્ધાંત 9. તમારા લોગ

લૉગ્સ (અથવા "લૉગ્સ") એ ઇવેન્ટ્સ છે, જે સામાન્ય રીતે ટેક્સ્ટ ફોર્મેટમાં રેકોર્ડ કરવામાં આવે છે, જે એપ્લિકેશન (ઇવેન્ટ સ્ટ્રીમ) ની અંદર થાય છે. એક સરળ ઉદાહરણ: "2020-02-02 - સિસ્ટમ સ્તર - પ્રક્રિયાનું નામ." તેઓ ડિઝાઇન કરવામાં આવ્યા છે જેથી વિકાસકર્તા શાબ્દિક રીતે જોઈ શકે કે જ્યારે પ્રોગ્રામ ચાલી રહ્યો હોય ત્યારે શું થઈ રહ્યું છે. તે પ્રક્રિયાઓની પ્રગતિ જુએ છે અને સમજે છે કે શું તે વિકાસકર્તા પોતે ઇચ્છે છે તે પ્રમાણે છે.

આ સિદ્ધાંત જણાવે છે કે તમારે તમારા લોગ્સને તમારી ફાઇલ સિસ્ટમની અંદર સંગ્રહિત ન કરવા જોઈએ - તમારે ફક્ત તેમને સ્ક્રીન પર "આઉટપુટ" કરવું જોઈએ, ઉદાહરણ તરીકે, આ સિસ્ટમના માનક આઉટપુટ પર કરો. અને આ રીતે વિકાસ દરમિયાન ટર્મિનલમાં પ્રવાહનું નિરીક્ષણ કરવું શક્ય બનશે.

શું આનો અર્થ એ છે કે લૉગ્સ સાચવવાની બિલકુલ જરૂર નથી? અલબત્ત નહીં. તમારી એપ્લિકેશને આવું કરવું જોઈએ નહીં—તેને તૃતીય-પક્ષ સેવાઓ પર છોડી દો. તમારી એપ્લિકેશન રીઅલ-ટાઇમ જોવા માટે ફક્ત ચોક્કસ ફાઇલ અથવા ટર્મિનલ પર લોગ ફોરવર્ડ કરી શકે છે અથવા તેને સામાન્ય હેતુ ડેટા સ્ટોરેજ સિસ્ટમ (જેમ કે Hadoop) પર ફોરવર્ડ કરી શકે છે. તમારી એપ્લીકેશન પોતે જ લૉગ્સ સ્ટોર કે ઇન્ટરેક્ટ ન કરવી જોઈએ.

સિદ્ધાંત 10. ટેસ્ટ!

ઔદ્યોગિક મશીન શિક્ષણ માટે, આ તબક્કો અત્યંત મહત્વપૂર્ણ છે, કારણ કે તમારે સમજવાની જરૂર છે કે મોડેલ યોગ્ય રીતે કાર્ય કરે છે અને તમે જે ઇચ્છો છો તે ઉત્પન્ન કરે છે.

પાયટેસ્ટનો ઉપયોગ કરીને પરીક્ષણો બનાવી શકાય છે, અને જો તમારી પાસે રીગ્રેસન/વર્ગીકરણ કાર્ય હોય તો નાના ડેટાસેટનો ઉપયોગ કરીને પરીક્ષણ કરી શકાય છે.

ડીપ લર્નિંગ મોડલ્સ માટે સમાન બીજ સેટ કરવાનું ભૂલશો નહીં જેથી તેઓ સતત અલગ-અલગ પરિણામો ઉત્પન્ન ન કરે.

આ 10 સિદ્ધાંતોનું સંક્ષિપ્ત વર્ણન હતું, અને, અલબત્ત, તેઓ કેવી રીતે કાર્ય કરે છે તેનો પ્રયાસ કર્યા વિના અને જોયા વિના તેનો ઉપયોગ કરવો મુશ્કેલ છે, તેથી આ લેખ ફક્ત રસપ્રદ લેખોની શ્રેણીનો પ્રસ્તાવના છે જેમાં હું કેવી રીતે બનાવવું તે જાહેર કરીશ. ઔદ્યોગિક મશીન લર્નિંગ મોડલ્સ, તેમને સિસ્ટમમાં કેવી રીતે એકીકૃત કરવું અને આ સિદ્ધાંતો આપણા બધા માટે જીવનને કેવી રીતે સરળ બનાવી શકે છે.

હું મસ્ત સિદ્ધાંતોનો ઉપયોગ કરવાનો પણ પ્રયાસ કરીશ જે કોઈપણ વ્યક્તિ ઈચ્છે તો ટિપ્પણીઓમાં છોડી શકે છે.

સોર્સ: www.habr.com