தொழில்துறை இயந்திர கற்றல்: 10 வடிவமைப்பு கோட்பாடுகள்
В наше время каждый день создаются новые сервисы, приложения и другие важные программы, позволяющие создавать невероятные вещи: от софта для управления ракетой SpaceX до взаимодействия с чайником в соседней комнате через смартфон.
И, порой, каждый начинающий программист, будь он страстным стартапером или же рядовым Full Stack или Data Scientist, рано или поздно приходит к осознанию того, что есть определенные правила программирования и создания софта, которые сильно упрощают жизнь.
இந்தக் கட்டுரையில், 10-காரணி பயன்பாட்டு முறையின் அடிப்படையில், ஒரு பயன்பாடு/சேவையில் எளிதாக ஒருங்கிணைக்க, தொழில்துறை இயந்திரக் கற்றலை எவ்வாறு நிரல் செய்வது என்பதற்கான 12 கொள்கைகளை நான் சுருக்கமாக விவரிக்கிறேன். . இந்த நுட்பத்தைப் பற்றிய விழிப்புணர்வை அதிகரிப்பதே எனது முயற்சியாகும், இது பல டெவலப்பர்கள் மற்றும் தரவு அறிவியல் நபர்களுக்கு உதவும்.
இந்த கட்டுரை தொழில்துறை இயந்திர கற்றல் பற்றிய தொடர் கட்டுரைகளின் முன்னுரையாகும். அவற்றில் நான் உண்மையில் ஒரு மாதிரியை உருவாக்கி அதை தயாரிப்பில் எவ்வாறு தொடங்குவது, அதற்கான API ஐ உருவாக்குவது மற்றும் பல்வேறு பகுதிகள் மற்றும் நிறுவனங்களின் எடுத்துக்காட்டுகள் ஆகியவற்றைப் பற்றி மேலும் பேசுவேன்.
Принцип 1. Одна кодовая база
Некоторые программисты на первых этапах из-за лени разобраться (или по каким-то своим соображениям) забывают про Git. Забывают либо от слова совсем, то есть кидают файлы друг другу в драйве/просто кидают текст/отправляют голубями, либо не продумывают свой workflow, и делают commit каждый в свою ветку, а потом и в мастера.
இந்த கொள்கை கூறுகிறது: имейте одну кодовую базу и много развертываний.
Git உற்பத்தி மற்றும் ஆராய்ச்சி மற்றும் மேம்பாடு (R&D) இரண்டிலும் பயன்படுத்தப்படலாம், அதில் இது அடிக்கடி பயன்படுத்தப்படுவதில்லை.
Например, в R&D фазе Вы можете оставлять коммиты с разными методами обработки данных и моделями, для того, чтобы потом выбрать наилучший и легко продолжить работать с ним дальше.
இரண்டாவதாக, உற்பத்தியில் இது ஒரு ஈடுசெய்ய முடியாத விஷயம் - உங்கள் குறியீடு எவ்வாறு மாறுகிறது என்பதை நீங்கள் தொடர்ந்து பார்க்க வேண்டும் மற்றும் எந்த மாதிரி சிறந்த முடிவுகளைத் தந்தது, எந்த குறியீடு இறுதியில் வேலை செய்தது மற்றும் அது வேலை செய்வதை நிறுத்த அல்லது தவறான முடிவுகளை உருவாக்கத் தொடங்கியது. . அதற்காகத்தான் கமிட்கள்!
А также Вы можете создать package своего проекта, разместив его, например, на Gemfury, и дальше просто импортируя функции из него для других проектов, чтобы не переписывать их 1000 раз, но об этом чуть позже.
Принцип 2. Четко объявляйте и изолируйте dependencies
ஒவ்வொரு திட்டத்திலும் வெவ்வேறு நூலகங்கள் உள்ளன, அவற்றை எங்காவது பயன்படுத்துவதற்காக நீங்கள் வெளியில் இருந்து இறக்குமதி செய்கிறீர்கள். அது பைதான் நூலகங்கள், அல்லது பல்வேறு நோக்கங்களுக்காக மற்ற மொழிகளின் நூலகங்கள் அல்லது கணினி கருவிகள் - உங்கள் பணி:
- சார்புகளை தெளிவாக அறிவிக்கவும், அதாவது, உங்கள் திட்டத்தில் பயன்படுத்தப்படும் அனைத்து நூலகங்கள், கருவிகள் மற்றும் அவற்றின் பதிப்புகள் ஆகியவற்றைக் கொண்டிருக்கும் மற்றும் நிறுவப்பட வேண்டிய கோப்பு (உதாரணமாக, பைத்தானில் இதை Pipfile அல்லது requirements.txt ஐப் பயன்படுத்தி செய்யலாம். A நன்றாக புரிந்து கொள்ள உதவும் இணைப்பு: )
- வளர்ச்சியின் போது உங்கள் திட்டத்திற்கான சார்புகளை தனிமைப்படுத்தவும். நீங்கள் தொடர்ந்து பதிப்புகளை மாற்றி மீண்டும் நிறுவ விரும்பவில்லை, எடுத்துக்காட்டாக, 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, так и стороннюю. То же самое касается и различных API, таких как Google Maps или Twitter API.
Для того, чтобы отключить сторонний сервис или подключить другой, нужно всего лишь поменять ключи в конфигурации в переменных среды, о которой я рассказывал в пункте выше.
எனவே, எடுத்துக்காட்டாக, ஒவ்வொரு முறையும் குறியீட்டின் உள்ளே தரவுத்தொகுப்புகளைக் கொண்ட கோப்புகளுக்கான பாதையைக் குறிப்பிடுவதற்குப் பதிலாக, பாத்லிப் நூலகத்தைப் பயன்படுத்தி, தரவுத்தொகுப்புகளுக்கான பாதையை config.py இல் அறிவிப்பது நல்லது, எனவே நீங்கள் எந்த சேவையைப் பயன்படுத்தினாலும் (அதற்கு எடுத்துக்காட்டாக, CircleCI), புதிய சேவையில் புதிய கோப்பு முறைமையின் கட்டமைப்பை கணக்கில் எடுத்துக்கொண்டு தரவுத்தொகுப்புகளுக்கான பாதையை நிரல் கண்டறிய முடிந்தது.
Принцип 5. Сборка, релиз, runtime
தரவு அறிவியலில் பலர் தங்கள் மென்பொருள் எழுதும் திறனை மேம்படுத்துவது பயனுள்ளதாக இருக்கும். எங்கள் நிரல் முடிந்தவரை அரிதாகவே செயலிழக்க வேண்டும் மற்றும் முடிந்தவரை தோல்விகள் இல்லாமல் வேலை செய்ய விரும்பினால், புதிய பதிப்பை வெளியிடும் செயல்முறையை 3 நிலைகளாகப் பிரிக்க வேண்டும்:
- மேடை கூட்டங்கள். Вы преобразуете Ваш голый код с отдельными ресурсами в так называемый пакет, который содержит весь необходимый код и данные. Этот пакет и называется сборкой.
- மேடை வெளியீடு - இங்கே நாங்கள் எங்கள் கட்டமைப்பை சட்டசபையுடன் இணைக்கிறோம், இது இல்லாமல் எங்கள் நிரலை வெளியிட முடியாது. இப்போது இது முற்றிலும் வெளியீட்டுக்குத் தயாராக உள்ளது.
- அடுத்து மேடை வருகிறது மரணதண்டனை. எங்கள் வெளியீட்டிலிருந்து தேவையான செயல்முறைகளை இயக்குவதன் மூலம் இங்கே பயன்பாட்டை வெளியிடுகிறோம்.
ஒரு மாதிரியின் புதிய பதிப்புகள் அல்லது முழு பைப்லைனையும் வெளியிடுவதற்கான அத்தகைய அமைப்பு, நிர்வாகிகள் மற்றும் டெவலப்பர்களுக்கு இடையில் பங்குகளை பிரிக்க உங்களை அனுமதிக்கிறது, பதிப்புகளைக் கண்காணிக்க உங்களை அனுமதிக்கிறது மற்றும் நிரலின் தேவையற்ற நிறுத்தங்களைத் தடுக்கிறது.
வெளியீட்டு பணிக்காக, .yml கோப்பில் நீங்களே இயங்குவதற்கான செயல்முறைகளை எழுதக்கூடிய பல்வேறு சேவைகள் உருவாக்கப்பட்டுள்ளன (உதாரணமாக, CircleCI இல் இது செயல்முறையை ஆதரிக்க config.yml ஆகும்). திட்டங்களுக்கான தொகுப்புகளை உருவாக்குவதில் வீலி சிறந்தது.
Вы сможете создавать пакеты с различными версиями вашей machine learning модели, и после чего пакетировать их и отсылаться к нужным пакетам и их версиям, чтобы использовать оттуда функции, которые Вы написали. Это поможет Вам создать API для Вашей модели, а Ваш пакет можно разместить например на Gemfury.
கொள்கை 6. உங்கள் மாதிரியை ஒன்று அல்லது அதற்கு மேற்பட்ட செயல்முறைகளாக இயக்கவும்
மேலும், செயல்முறைகள் பகிரப்பட்ட தரவுகளைக் கொண்டிருக்கக்கூடாது. அதாவது, செயல்முறைகள் தனித்தனியாக இருக்க வேண்டும், மேலும் அனைத்து வகையான தரவுகளும் தனித்தனியாக இருக்க வேண்டும், எடுத்துக்காட்டாக, MySQL அல்லது பிற போன்ற மூன்றாம் தரப்பு சேவைகளில், உங்களுக்கு என்ன தேவை என்பதைப் பொறுத்து.
То есть данные внутри файловой системы процесса хранить точно не стоит, иначе это может привести к очищению от этих данных при следующем релизе/изменении конфигураций или переноса системы, на которой работает программа.
Но есть исключение: для machine learning проектов можно хранить кэш библиотек, чтобы не переустанавливать их каждый раз при запуске новой версии, если дополнительных библиотек или каких-либо изменений в их версиях произведено не было. Таким образом, вы сократите время запуска вашей модели в промышленности.
மாதிரியை பல செயல்முறைகளாக இயக்க, நீங்கள் ஒரு .yml கோப்பை உருவாக்கலாம், அதில் தேவையான செயல்முறைகள் மற்றும் அவற்றின் வரிசையை நீங்கள் குறிப்பிடலாம்.
Принцип 7. Утилизируемость
உங்கள் மாதிரி பயன்பாட்டில் இயங்கும் செயல்முறைகள் தொடங்குவதற்கும் நிறுத்துவதற்கும் எளிதாக இருக்க வேண்டும். எனவே, குறியீடு மாற்றங்கள், உள்ளமைவு மாற்றங்கள், விரைவாகவும் நெகிழ்வாகவும் அளவிடுதல் மற்றும் வேலை செய்யும் பதிப்பின் சாத்தியமான முறிவுகளைத் தடுக்க இது உங்களை அனுமதிக்கும்.
அதாவது, மாதிரியுடன் உங்கள் செயல்முறை:
- தொடக்க நேரத்தை குறைக்கவும். வெறுமனே, தொடக்க நேரம் (தொடக்க கட்டளை வழங்கப்பட்ட தருணத்திலிருந்து செயல்முறை செயல்பாட்டுக்கு வரும் வரை) சில வினாடிகளுக்கு மேல் இருக்கக்கூடாது. மேலே விவரிக்கப்பட்ட லைப்ரரி கேச்சிங், தொடக்க நேரத்தைக் குறைப்பதற்கான ஒரு நுட்பமாகும்.
- Завершаться корректно. То есть фактически приостанавливается прослушивание порта сервиса, и новые запросы, поданные в этот порт, не будут обрабатываться. Здесь уже нужно либо настраивать неплохую связь с DevOps инженерами, или самому понимать, как это работает (желательно, конечно, второе, но связь поддерживать нужно всегда, в любом проекте!)
Принцип 8. Непрерывное развертывание/интеграция
பல நிறுவனங்கள் பயன்பாட்டு மேம்பாடு மற்றும் வரிசைப்படுத்தல் குழுக்களுக்கு இடையே ஒரு பிரிவைப் பயன்படுத்துகின்றன (இறுதி பயனர்களுக்கு பயன்பாட்டைக் கிடைக்கச் செய்கிறது). இது மென்பொருள் மேம்பாட்டை வெகுவாகக் குறைக்கலாம் மற்றும் அதை மேம்படுத்துவதில் முன்னேற்றம் அடையலாம். இது டெவொப்ஸ் கலாச்சாரத்தையும் கெடுக்கிறது, அங்கு வளர்ச்சி மற்றும் ஒருங்கிணைப்பு, தோராயமாகச் சொன்னால், இணைக்கப்பட்டுள்ளது.
Поэтому этот принцип гласит о том, что среда Вашей разработки должна быть максимально приближена к среде Вашего продакшена.
Это позволит:
- வெளியீட்டு நேரத்தை பத்து மடங்கு குறைக்கவும்
- குறியீடு இணக்கமின்மை காரணமாக பிழைகளின் எண்ணிக்கையைக் குறைக்கவும்.
- Также это позволяет снизить нагрузку на персонал, так как разработчики и люди, развертывающие приложение — теперь одна команда.
CircleCI, Travis CI, GitLab CI மற்றும் பிறவற்றைக் கொண்டு வேலை செய்ய உங்களை அனுமதிக்கும் கருவிகள்.
நீங்கள் மாடலில் விரைவாகச் சேர்த்தல் செய்யலாம், அதைப் புதுப்பித்து உடனடியாகத் தொடங்கலாம், அதே நேரத்தில், தோல்விகள் ஏற்பட்டால், வேலை செய்யும் பதிப்பிற்கு மிக விரைவாகத் திரும்புவது எளிதாக இருக்கும், இதனால் இறுதிப் பயனர் அதைக் கூட கவனிக்கவில்லை. உங்களுக்கு நல்ல சோதனைகள் இருந்தால் இதை எளிதாகவும் விரைவாகவும் செய்யலாம்.
Минимизируйте различия!!!
கொள்கை 9. உங்கள் பதிவுகள்
பதிவுகள் (அல்லது "பதிவுகள்") நிகழ்வுகள், பொதுவாக உரை வடிவத்தில் பதிவு செய்யப்படும், அவை பயன்பாட்டில் (நிகழ்வு ஸ்ட்ரீம்) நிகழும். ஒரு எளிய எடுத்துக்காட்டு: "2020-02-02 - கணினி நிலை - செயல்முறை பெயர்." நிரல் இயங்கும் போது என்ன நடக்கிறது என்பதை டெவலப்பர் உண்மையில் பார்க்கும் வகையில் அவை வடிவமைக்கப்பட்டுள்ளன. அவர் செயல்முறைகளின் முன்னேற்றத்தைப் பார்க்கிறார் மற்றும் டெவலப்பர் தானே நோக்கம் கொண்டதா என்பதைப் புரிந்துகொள்கிறார்.
உங்கள் கோப்பு முறைமைக்குள் உங்கள் பதிவுகளை சேமிக்க வேண்டாம் என்று இந்தக் கொள்கை கூறுகிறது - நீங்கள் அவற்றை திரையில் "வெளியீடு" செய்ய வேண்டும், எடுத்துக்காட்டாக, கணினியின் நிலையான வெளியீட்டில் இதைச் செய்யுங்கள். இந்த வழியில் வளர்ச்சியின் போது முனையத்தில் ஓட்டத்தை கண்காணிக்க முடியும்.
Значит ли это что не нужно сохранять логи совсем? Конечно нет. Просто этим не должно заниматься Ваше приложение — оставьте это сторонним сервисам. Ваше приложение может лишь перенаправить логи в определенный файл или терминал для просмотра в реальном времени или перенаправить его в систему для хранения данных общего назначения (например, Hadoop). Само Ваше приложение не должно хранить или взаимодействовать с логами.
கொள்கை 10. சோதனை!
தொழில்துறை இயந்திர கற்றலுக்கு, இந்த கட்டம் மிகவும் முக்கியமானது, ஏனெனில் மாதிரி சரியாக வேலை செய்கிறது மற்றும் நீங்கள் விரும்பியதை உற்பத்தி செய்கிறது என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும்.
பைடெஸ்ட்டைப் பயன்படுத்தி சோதனைகளை உருவாக்கலாம், மேலும் உங்களிடம் பின்னடைவு/வகைப்படுத்தல் பணி இருந்தால் சிறிய தரவுத்தொகுப்பைப் பயன்படுத்தி சோதனை செய்யலாம்.
Не забывайте ставить одинаковый seed для deep learning моделей, чтобы они не выдавали постоянно разные результаты.
Это было краткое описание 10 принципов, и, конечно, сложно пользоваться ими не попробовав и не увидев то, как они работают, поэтому эта статья — это лишь пролог к серии интересных статей, в которые я буду раскрывать то, как создавать промышленные machine learning модели, как их интегрировать в системы, и как эти принципы могут упростить нам всем жизнь.
எவரும் விரும்பினால் கருத்துகளில் விடக்கூடிய அருமையான கொள்கைகளையும் பயன்படுத்த முயற்சிப்பேன்.
ஆதாரம்: www.habr.com