தொழில்துறை இயந்திர கற்றல்: 10 வடிவமைப்பு கோட்பாடுகள்

தொழில்துறை இயந்திர கற்றல்: 10 வடிவமைப்பு கோட்பாடுகள்

இப்போதெல்லாம், ஒவ்வொரு நாளும் புதிய சேவைகள், பயன்பாடுகள் மற்றும் பிற முக்கியமான திட்டங்கள் உருவாக்கப்படுகின்றன, அவை நம்பமுடியாத விஷயங்களை உருவாக்குவதை சாத்தியமாக்குகின்றன: ஸ்பேஸ்எக்ஸ் ராக்கெட்டைக் கட்டுப்படுத்தும் மென்பொருள் முதல் ஸ்மார்ட்போன் வழியாக அடுத்த அறையில் உள்ள கெட்டிலுடன் தொடர்புகொள்வது வரை.

மேலும், சில சமயங்களில், ஒவ்வொரு புதிய ப்ரோக்ராமரும், அவர் ஒரு ஆர்வமுள்ள ஸ்டார்ட்அப்பர் அல்லது சாதாரண ஃபுல் ஸ்டாக் அல்லது டேட்டா விஞ்ஞானியாக இருந்தாலும், வாழ்க்கையை பெரிதும் எளிமையாக்கும் மென்பொருளை நிரலாக்க மற்றும் உருவாக்க சில விதிகள் உள்ளன என்பதை விரைவில் அல்லது பின்னர் புரிந்துகொள்வார்கள்.

இந்தக் கட்டுரையில், 10-காரணி பயன்பாட்டு முறையின் அடிப்படையில், ஒரு பயன்பாடு/சேவையில் எளிதாக ஒருங்கிணைக்க, தொழில்துறை இயந்திரக் கற்றலை எவ்வாறு நிரல் செய்வது என்பதற்கான 12 கொள்கைகளை நான் சுருக்கமாக விவரிக்கிறேன். Heroku குழு பரிந்துரைத்தது. இந்த நுட்பத்தைப் பற்றிய விழிப்புணர்வை அதிகரிப்பதே எனது முயற்சியாகும், இது பல டெவலப்பர்கள் மற்றும் தரவு அறிவியல் நபர்களுக்கு உதவும்.

இந்த கட்டுரை தொழில்துறை இயந்திர கற்றல் பற்றிய தொடர் கட்டுரைகளின் முன்னுரையாகும். அவற்றில் நான் உண்மையில் ஒரு மாதிரியை உருவாக்கி அதை தயாரிப்பில் எவ்வாறு தொடங்குவது, அதற்கான API ஐ உருவாக்குவது மற்றும் பல்வேறு பகுதிகள் மற்றும் நிறுவனங்களின் எடுத்துக்காட்டுகள் ஆகியவற்றைப் பற்றி மேலும் பேசுவேன்.

கொள்கை 1: ஒரு குறியீடு அடிப்படை

சில புரோகிராமர்கள் முதல் கட்டங்களில், அதைக் கண்டுபிடிக்கும் சோம்பலின் காரணமாக (அல்லது அவர்களின் சொந்த காரணங்களுக்காக), Git ஐ மறந்து விடுகிறார்கள். அவர்கள் வார்த்தையை முழுவதுமாக மறந்துவிடுகிறார்கள், அதாவது, அவர்கள் இயக்கியில் ஒருவருக்கொருவர் கோப்புகளை வீசுகிறார்கள் / உரையை வீசுகிறார்கள் / புறாக்கள் மூலம் அனுப்புகிறார்கள், அல்லது அவர்கள் தங்கள் பணிப்பாய்வுகளைப் பற்றி சிந்திக்காமல், ஒவ்வொன்றையும் தங்கள் சொந்த கிளைக்கு ஒப்புக்கொள்கிறார்கள், பின்னர் குரு.

இந்த கொள்கை கூறுகிறது: ஒரு கோட்பேஸ் மற்றும் பல வரிசைப்படுத்தல்கள் உள்ளன.

Git உற்பத்தி மற்றும் ஆராய்ச்சி மற்றும் மேம்பாடு (R&D) இரண்டிலும் பயன்படுத்தப்படலாம், அதில் இது அடிக்கடி பயன்படுத்தப்படுவதில்லை.

எடுத்துக்காட்டாக, R&D கட்டத்தில், நீங்கள் வெவ்வேறு தரவு செயலாக்க முறைகள் மற்றும் மாதிரிகளுடன் கமிட்களை விட்டுவிடலாம், பின்னர் சிறந்ததைத் தேர்ந்தெடுத்து, அதனுடன் எளிதாக தொடர்ந்து பணியாற்றலாம்.

இரண்டாவதாக, உற்பத்தியில் இது ஒரு ஈடுசெய்ய முடியாத விஷயம் - உங்கள் குறியீடு எவ்வாறு மாறுகிறது என்பதை நீங்கள் தொடர்ந்து பார்க்க வேண்டும் மற்றும் எந்த மாதிரி சிறந்த முடிவுகளைத் தந்தது, எந்த குறியீடு இறுதியில் வேலை செய்தது மற்றும் அது வேலை செய்வதை நிறுத்த அல்லது தவறான முடிவுகளை உருவாக்கத் தொடங்கியது. . அதற்காகத்தான் கமிட்கள்!

உங்கள் திட்டத்தின் ஒரு தொகுப்பை நீங்கள் உருவாக்கலாம், எடுத்துக்காட்டாக, Gemfury இல் வைக்கவும், பின்னர் மற்ற திட்டங்களுக்கு அதிலிருந்து செயல்பாடுகளை இறக்குமதி செய்யலாம், இதனால் அவற்றை 1000 முறை மீண்டும் எழுதக்கூடாது, ஆனால் பின்னர் மேலும்.

கொள்கை 2: சார்புகளை தெளிவாக அறிவித்து தனிமைப்படுத்தவும்

ஒவ்வொரு திட்டத்திலும் வெவ்வேறு நூலகங்கள் உள்ளன, அவற்றை எங்காவது பயன்படுத்துவதற்காக நீங்கள் வெளியில் இருந்து இறக்குமதி செய்கிறீர்கள். அது பைதான் நூலகங்கள், அல்லது பல்வேறு நோக்கங்களுக்காக மற்ற மொழிகளின் நூலகங்கள் அல்லது கணினி கருவிகள் - உங்கள் பணி:

• சார்புகளை தெளிவாக அறிவிக்கவும், அதாவது, உங்கள் திட்டத்தில் பயன்படுத்தப்படும் அனைத்து நூலகங்கள், கருவிகள் மற்றும் அவற்றின் பதிப்புகள் ஆகியவற்றைக் கொண்டிருக்கும் மற்றும் நிறுவப்பட வேண்டிய கோப்பு (உதாரணமாக, பைத்தானில் இதை Pipfile அல்லது requirements.txt ஐப் பயன்படுத்தி செய்யலாம். A நன்றாக புரிந்து கொள்ள உதவும் இணைப்பு: 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 URLகள்/URIகள்
• பொது மற்றும் தனிப்பட்ட விசைகள்
• தொடர்புகள் (அஞ்சல், தொலைபேசிகள் போன்றவை)

இந்த வழியில் உங்கள் கட்டமைப்பு மாறிகள் மாறினால் நீங்கள் தொடர்ந்து குறியீட்டை மாற்ற வேண்டியதில்லை. இது உங்கள் நேரத்தையும் முயற்சியையும் பணத்தையும் சேமிக்க உதவும்.

எடுத்துக்காட்டாக, நீங்கள் சோதனைகளை நடத்த Kaggle API ஐப் பயன்படுத்தினால் (உதாரணமாக, மென்பொருளைப் பதிவிறக்கி அதன் மூலம் மாடல் நன்றாகச் செயல்படுகிறதா என்று சோதிக்க மாடலை இயக்கவும்), பின்னர் Kaggle இலிருந்து KAGGLE_USERNAME மற்றும் KAGGLE_KEY போன்ற தனிப்பட்ட விசைகள் இருக்க வேண்டும். சூழல் மாறிகளில் சேமிக்கப்படுகிறது.

கொள்கை 4: மூன்றாம் தரப்பு சேவைகள்

குறியீட்டின் அடிப்படையில் உள்ளூர் மற்றும் மூன்றாம் தரப்பு ஆதாரங்களுக்கு இடையில் எந்த வித்தியாசமும் இல்லாத வகையில் நிரலை உருவாக்குவதே இங்கே யோசனை. எடுத்துக்காட்டாக, நீங்கள் உள்ளூர் MySQL மற்றும் மூன்றாம் தரப்பு இரண்டையும் இணைக்கலாம். Google Maps அல்லது Twitter API போன்ற பல்வேறு APIகளுக்கும் இதுவே செல்கிறது.

மூன்றாம் தரப்பு சேவையை முடக்க அல்லது மற்றொன்றை இணைக்க, மேலே உள்ள பத்தியில் நான் பேசிய சூழல் மாறிகளில் உள்ள உள்ளமைவில் உள்ள விசைகளை மாற்ற வேண்டும்.

எனவே, எடுத்துக்காட்டாக, ஒவ்வொரு முறையும் குறியீட்டின் உள்ளே தரவுத்தொகுப்புகளைக் கொண்ட கோப்புகளுக்கான பாதையைக் குறிப்பிடுவதற்குப் பதிலாக, பாத்லிப் நூலகத்தைப் பயன்படுத்தி, தரவுத்தொகுப்புகளுக்கான பாதையை config.py இல் அறிவிப்பது நல்லது, எனவே நீங்கள் எந்த சேவையைப் பயன்படுத்தினாலும் (அதற்கு எடுத்துக்காட்டாக, CircleCI), புதிய சேவையில் புதிய கோப்பு முறைமையின் கட்டமைப்பை கணக்கில் எடுத்துக்கொண்டு தரவுத்தொகுப்புகளுக்கான பாதையை நிரல் கண்டறிய முடிந்தது.

கொள்கை 5. உருவாக்க, வெளியீடு, இயக்க நேரம்

தரவு அறிவியலில் பலர் தங்கள் மென்பொருள் எழுதும் திறனை மேம்படுத்துவது பயனுள்ளதாக இருக்கும். எங்கள் நிரல் முடிந்தவரை அரிதாகவே செயலிழக்க வேண்டும் மற்றும் முடிந்தவரை தோல்விகள் இல்லாமல் வேலை செய்ய விரும்பினால், புதிய பதிப்பை வெளியிடும் செயல்முறையை 3 நிலைகளாகப் பிரிக்க வேண்டும்:

1. மேடை கூட்டங்கள். உங்கள் வெற்றுக் குறியீட்டை தனிப்பட்ட ஆதாரங்களுடன் தேவையான அனைத்து குறியீடு மற்றும் தரவைக் கொண்ட தொகுப்பு என அழைக்கப்படுபவையாக மாற்றுகிறீர்கள். இந்த தொகுப்பு ஒரு சட்டசபை என்று அழைக்கப்படுகிறது.
2. மேடை வெளியீடு - இங்கே நாங்கள் எங்கள் கட்டமைப்பை சட்டசபையுடன் இணைக்கிறோம், இது இல்லாமல் எங்கள் நிரலை வெளியிட முடியாது. இப்போது இது முற்றிலும் வெளியீட்டுக்குத் தயாராக உள்ளது.
3. அடுத்து மேடை வருகிறது மரணதண்டனை. எங்கள் வெளியீட்டிலிருந்து தேவையான செயல்முறைகளை இயக்குவதன் மூலம் இங்கே பயன்பாட்டை வெளியிடுகிறோம்.

ஒரு மாதிரியின் புதிய பதிப்புகள் அல்லது முழு பைப்லைனையும் வெளியிடுவதற்கான அத்தகைய அமைப்பு, நிர்வாகிகள் மற்றும் டெவலப்பர்களுக்கு இடையில் பங்குகளை பிரிக்க உங்களை அனுமதிக்கிறது, பதிப்புகளைக் கண்காணிக்க உங்களை அனுமதிக்கிறது மற்றும் நிரலின் தேவையற்ற நிறுத்தங்களைத் தடுக்கிறது.

வெளியீட்டு பணிக்காக, .yml கோப்பில் நீங்களே இயங்குவதற்கான செயல்முறைகளை எழுதக்கூடிய பல்வேறு சேவைகள் உருவாக்கப்பட்டுள்ளன (உதாரணமாக, CircleCI இல் இது செயல்முறையை ஆதரிக்க config.yml ஆகும்). திட்டங்களுக்கான தொகுப்புகளை உருவாக்குவதில் வீலி சிறந்தது.

உங்கள் இயந்திர கற்றல் மாதிரியின் வெவ்வேறு பதிப்புகளுடன் நீங்கள் தொகுப்புகளை உருவாக்கலாம், பின்னர் அவற்றை தொகுத்து, தேவையான தொகுப்புகள் மற்றும் அவற்றின் பதிப்புகளைப் பார்க்கவும், அங்கு நீங்கள் எழுதிய செயல்பாடுகளைப் பயன்படுத்தவும். இது உங்கள் மாடலுக்கான API ஐ உருவாக்க உதவும், மேலும் உங்கள் தொகுப்பை Gemfury இல் ஹோஸ்ட் செய்யலாம்.

கொள்கை 6. உங்கள் மாதிரியை ஒன்று அல்லது அதற்கு மேற்பட்ட செயல்முறைகளாக இயக்கவும்

மேலும், செயல்முறைகள் பகிரப்பட்ட தரவுகளைக் கொண்டிருக்கக்கூடாது. அதாவது, செயல்முறைகள் தனித்தனியாக இருக்க வேண்டும், மேலும் அனைத்து வகையான தரவுகளும் தனித்தனியாக இருக்க வேண்டும், எடுத்துக்காட்டாக, MySQL அல்லது பிற போன்ற மூன்றாம் தரப்பு சேவைகளில், உங்களுக்கு என்ன தேவை என்பதைப் பொறுத்து.

அதாவது, செயல்முறை கோப்பு முறைமைக்குள் தரவை சேமிப்பது நிச்சயமாக மதிப்புக்குரியது அல்ல, இல்லையெனில் இது அடுத்த வெளியீடு / உள்ளமைவுகளின் மாற்றம் அல்லது நிரல் இயங்கும் கணினியின் பரிமாற்றத்தின் போது இந்தத் தரவை அழிக்க வழிவகுக்கும்.

ஆனால் ஒரு விதிவிலக்கு உள்ளது: இயந்திர கற்றல் திட்டங்களுக்கு, கூடுதல் நூலகங்கள் அல்லது அவற்றின் பதிப்புகளில் ஏதேனும் மாற்றங்கள் செய்யப்படாவிட்டால், ஒவ்வொரு முறையும் புதிய பதிப்பைத் தொடங்கும் போது அவற்றை மீண்டும் நிறுவாமல் இருக்க, நீங்கள் நூலகங்களின் தற்காலிக சேமிப்பை சேமிக்கலாம். இந்த வழியில், தொழில்துறையில் உங்கள் மாதிரியைத் தொடங்க எடுக்கும் நேரத்தைக் குறைப்பீர்கள்.

மாதிரியை பல செயல்முறைகளாக இயக்க, நீங்கள் ஒரு .yml கோப்பை உருவாக்கலாம், அதில் தேவையான செயல்முறைகள் மற்றும் அவற்றின் வரிசையை நீங்கள் குறிப்பிடலாம்.

கொள்கை 7: மறுசுழற்சி

உங்கள் மாதிரி பயன்பாட்டில் இயங்கும் செயல்முறைகள் தொடங்குவதற்கும் நிறுத்துவதற்கும் எளிதாக இருக்க வேண்டும். எனவே, குறியீடு மாற்றங்கள், உள்ளமைவு மாற்றங்கள், விரைவாகவும் நெகிழ்வாகவும் அளவிடுதல் மற்றும் வேலை செய்யும் பதிப்பின் சாத்தியமான முறிவுகளைத் தடுக்க இது உங்களை அனுமதிக்கும்.

அதாவது, மாதிரியுடன் உங்கள் செயல்முறை:

• தொடக்க நேரத்தை குறைக்கவும். வெறுமனே, தொடக்க நேரம் (தொடக்க கட்டளை வழங்கப்பட்ட தருணத்திலிருந்து செயல்முறை செயல்பாட்டுக்கு வரும் வரை) சில வினாடிகளுக்கு மேல் இருக்கக்கூடாது. மேலே விவரிக்கப்பட்ட லைப்ரரி கேச்சிங், தொடக்க நேரத்தைக் குறைப்பதற்கான ஒரு நுட்பமாகும்.
• சரியாக முடிக்கவும். அதாவது, சேவை போர்ட்டில் கேட்பது உண்மையில் இடைநிறுத்தப்பட்டுள்ளது, மேலும் இந்த போர்ட்டில் சமர்ப்பிக்கப்பட்ட புதிய கோரிக்கைகள் செயலாக்கப்படாது. இங்கே நீங்கள் DevOps பொறியாளர்களுடன் நல்ல தொடர்பை அமைக்க வேண்டும், அல்லது அது எவ்வாறு செயல்படுகிறது என்பதை நீங்களே புரிந்து கொள்ள வேண்டும் (முன்னுரிமை, நிச்சயமாக, பிந்தையது, ஆனால் எந்த திட்டத்திலும் தொடர்பு எப்போதும் பராமரிக்கப்பட வேண்டும்!)

கொள்கை 8: தொடர்ச்சியான வரிசைப்படுத்தல்/ஒருங்கிணைப்பு

பல நிறுவனங்கள் பயன்பாட்டு மேம்பாடு மற்றும் வரிசைப்படுத்தல் குழுக்களுக்கு இடையே ஒரு பிரிவைப் பயன்படுத்துகின்றன (இறுதி பயனர்களுக்கு பயன்பாட்டைக் கிடைக்கச் செய்கிறது). இது மென்பொருள் மேம்பாட்டை வெகுவாகக் குறைக்கலாம் மற்றும் அதை மேம்படுத்துவதில் முன்னேற்றம் அடையலாம். இது டெவொப்ஸ் கலாச்சாரத்தையும் கெடுக்கிறது, அங்கு வளர்ச்சி மற்றும் ஒருங்கிணைப்பு, தோராயமாகச் சொன்னால், இணைக்கப்பட்டுள்ளது.

எனவே, உங்கள் வளர்ச்சிச் சூழல் உங்கள் உற்பத்தி சூழலுக்கு முடிந்தவரை நெருக்கமாக இருக்க வேண்டும் என்று இந்தக் கொள்கை கூறுகிறது.

இது அனுமதிக்கும்:

1. வெளியீட்டு நேரத்தை பத்து மடங்கு குறைக்கவும்
2. குறியீடு இணக்கமின்மை காரணமாக பிழைகளின் எண்ணிக்கையைக் குறைக்கவும்.
3. டெவலப்பர்களும் பயன்பாட்டைப் பயன்படுத்துபவர்களும் இப்போது ஒரு குழுவாக இருப்பதால், இது ஊழியர்களின் பணிச்சுமையைக் குறைக்கிறது.

CircleCI, Travis CI, GitLab CI மற்றும் பிறவற்றைக் கொண்டு வேலை செய்ய உங்களை அனுமதிக்கும் கருவிகள்.

நீங்கள் மாடலில் விரைவாகச் சேர்த்தல் செய்யலாம், அதைப் புதுப்பித்து உடனடியாகத் தொடங்கலாம், அதே நேரத்தில், தோல்விகள் ஏற்பட்டால், வேலை செய்யும் பதிப்பிற்கு மிக விரைவாகத் திரும்புவது எளிதாக இருக்கும், இதனால் இறுதிப் பயனர் அதைக் கூட கவனிக்கவில்லை. உங்களுக்கு நல்ல சோதனைகள் இருந்தால் இதை எளிதாகவும் விரைவாகவும் செய்யலாம்.

வேறுபாடுகளைக் குறைக்கவும்!!!

கொள்கை 9. உங்கள் பதிவுகள்

பதிவுகள் (அல்லது "பதிவுகள்") நிகழ்வுகள், பொதுவாக உரை வடிவத்தில் பதிவு செய்யப்படும், அவை பயன்பாட்டில் (நிகழ்வு ஸ்ட்ரீம்) நிகழும். ஒரு எளிய எடுத்துக்காட்டு: "2020-02-02 - கணினி நிலை - செயல்முறை பெயர்." நிரல் இயங்கும் போது என்ன நடக்கிறது என்பதை டெவலப்பர் உண்மையில் பார்க்கும் வகையில் அவை வடிவமைக்கப்பட்டுள்ளன. அவர் செயல்முறைகளின் முன்னேற்றத்தைப் பார்க்கிறார் மற்றும் டெவலப்பர் தானே நோக்கம் கொண்டதா என்பதைப் புரிந்துகொள்கிறார்.

உங்கள் கோப்பு முறைமைக்குள் உங்கள் பதிவுகளை சேமிக்க வேண்டாம் என்று இந்தக் கொள்கை கூறுகிறது - நீங்கள் அவற்றை திரையில் "வெளியீடு" செய்ய வேண்டும், எடுத்துக்காட்டாக, கணினியின் நிலையான வெளியீட்டில் இதைச் செய்யுங்கள். இந்த வழியில் வளர்ச்சியின் போது முனையத்தில் ஓட்டத்தை கண்காணிக்க முடியும்.

பதிவுகளை சேமிக்க வேண்டிய அவசியம் இல்லை என்று இது அர்த்தப்படுத்துகிறதா? நிச்சயமாக இல்லை. உங்கள் விண்ணப்பம் இதைச் செய்யக்கூடாது—அதை மூன்றாம் தரப்பு சேவைகளுக்கு விட்டுவிடுங்கள். உங்கள் பயன்பாட்டினால் பதிவுகளை ஒரு குறிப்பிட்ட கோப்பு அல்லது முனையத்திற்கு மட்டுமே நிகழ்நேர பார்வைக்கு அனுப்ப முடியும் அல்லது பொது நோக்கத்திற்கான தரவு சேமிப்பக அமைப்புக்கு (ஹடூப் போன்றவை) அனுப்ப முடியும். உங்கள் பயன்பாடு பதிவுகளை சேமிக்கவோ அல்லது தொடர்பு கொள்ளவோ ​​கூடாது.

கொள்கை 10. சோதனை!

தொழில்துறை இயந்திர கற்றலுக்கு, இந்த கட்டம் மிகவும் முக்கியமானது, ஏனெனில் மாதிரி சரியாக வேலை செய்கிறது மற்றும் நீங்கள் விரும்பியதை உற்பத்தி செய்கிறது என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும்.

பைடெஸ்ட்டைப் பயன்படுத்தி சோதனைகளை உருவாக்கலாம், மேலும் உங்களிடம் பின்னடைவு/வகைப்படுத்தல் பணி இருந்தால் சிறிய தரவுத்தொகுப்பைப் பயன்படுத்தி சோதனை செய்யலாம்.

ஆழமான கற்றல் மாதிரிகளுக்கு ஒரே விதையை அமைக்க மறக்காதீர்கள், இதனால் அவை தொடர்ந்து வெவ்வேறு முடிவுகளைத் தராது.

இது 10 கொள்கைகளின் சுருக்கமான விளக்கமாகும், நிச்சயமாக, அவை எவ்வாறு செயல்படுகின்றன என்பதைப் பார்க்காமல் அவற்றைப் பயன்படுத்துவது கடினம், எனவே இந்த கட்டுரை சுவாரஸ்யமான கட்டுரைகளின் தொடரின் முன்னுரையாகும், அதில் நான் எவ்வாறு உருவாக்குவது என்பதை வெளிப்படுத்துவேன். தொழில்துறை இயந்திர கற்றல் மாதிரிகள், அவற்றை எவ்வாறு அமைப்புகளில் ஒருங்கிணைப்பது மற்றும் இந்தக் கொள்கைகள் நம் அனைவருக்கும் வாழ்க்கையை எவ்வாறு எளிதாக்கும்.

எவரும் விரும்பினால் கருத்துகளில் விடக்கூடிய அருமையான கொள்கைகளையும் பயன்படுத்த முயற்சிப்பேன்.

ஆதாரம்: www.habr.com