Индустриално машинно обучение: 10 принципа на проектиране

Индустриално машинно обучение: 10 принципа на проектиране

В днешно време всеки ден се създават нови услуги, приложения и други важни програми, които правят възможно създаването на невероятни неща: от софтуер за управление на ракета SpaceX до взаимодействие с чайник в съседната стая чрез смартфон.

И понякога всеки начинаещ програмист, независимо дали е страстен стартиращ бизнес или обикновен Full Stack или Data Scientist, рано или късно разбира, че има определени правила за програмиране и създаване на софтуер, които значително опростяват живота.

В тази статия ще опиша накратко 10 принципа как да програмираме индустриално машинно обучение, така че да може лесно да бъде интегрирано в приложение/услуга, базирано на методологията на 12-факторното приложение. предложено от екипа на Heroku. Моята инициатива е да повиша осведомеността за тази техника, която може да помогне на много разработчици и хора в науката за данни.

Тази статия е пролог към поредица от статии за индустриалното машинно обучение. В тях по-нататък ще говоря за това как всъщност да направя модел и да го пусна в производство, да създам API за него, както и примери от различни области и компании, които имат вграден ML в своите системи.

Принцип 1: Една кодова база

Някои програмисти на първите етапи, от мързел да го разберат (или по някаква своя причина), забравят за Git. Те или напълно забравят думата, тоест хвърлят си файлове един на друг в устройството/просто хвърлят текст/изпращат чрез гълъби, или не обмислят работния си процес и се ангажират всеки със собствения си клон, а след това с майстор.

Този принцип гласи: имат една кодова база и много внедрявания.

Git може да се използва както в производството, така и в научноизследователската и развойна дейност (R&D), в които не се използва толкова често.

Например, във фазата на R&D можете да оставите ангажименти с различни методи и модели за обработка на данни, за да изберете най-добрия и лесно да продължите да работите с него по-нататък.

Второ, в производството това е незаменимо нещо - ще трябва постоянно да гледате как се променя кодът ви и да знаете кой модел е дал най-добри резултати, кой код е работил в крайна сметка и какво се е случило, което го е накарало да спре да работи или да започне да дава неправилни резултати . За това са ангажиментите!

Можете също така да създадете пакет от вашия проект, като го поставите например на Gemfury и след това просто да импортирате функции от него за други проекти, за да не ги пренаписвате 1000 пъти, но повече за това по-късно.

Принцип 2: Ясно декларирайте и изолирайте зависимостите

Всеки проект има различни библиотеки, които импортирате отвън, за да ги приложите някъде. Независимо дали става въпрос за библиотеки на Python, или библиотеки на други езици за различни цели, или системни инструменти - вашата задача е:

• Ясно декларирайте зависимости, тоест файл, който ще съдържа всички библиотеки, инструменти и техните версии, които се използват във вашия проект и които трябва да бъдат инсталирани (например в Python това може да се направи с помощта на Pipfile или requirements.txt. A връзка, която позволява добре да се разбере: realpython.com/pipenv-guide)
• Изолирайте зависимости специално за вашата програма по време на разработката. Не искате постоянно да сменяте версиите и да преинсталирате например Tensorflow?

По този начин разработчиците, които ще се присъединят към вашия екип в бъдеще, ще могат бързо да се запознаят с библиотеките и техните версии, които се използват във вашия проект, а също така ще имате възможност да управлявате самите версии и библиотеки, инсталирани за конкретен проект, който ще ви помогне да избегнете несъвместимост на библиотеки или техни версии.

Вашето приложение също не трябва да разчита на системни инструменти, които може да са инсталирани на конкретна операционна система. Тези инструменти също трябва да бъдат декларирани в манифеста на зависимостите. Това е необходимо, за да се избегнат ситуации, при които версията на инструментите (както и тяхната наличност) не съответства на системните инструменти на определена ОС.

По този начин, дори ако curl може да се използва на почти всички компютри, все пак трябва да го декларирате в зависимости, тъй като при мигриране към друга платформа той може да не е там или версията няма да е тази, от която първоначално се нуждаете.

Например вашият 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: Конфигурации

Мнозина са чували истории за различни разработчици, които случайно качват код в GitHub в публични хранилища с пароли и други ключове от AWS, събуждайки се на следващия ден с дълг от $6000 50000 или дори $XNUMX XNUMX.

Разбира се, тези случаи са крайни, но много значими. Ако съхранявате вашите идентификационни данни или други данни, необходими за конфигуриране в кода, правите грешка и мисля, че няма нужда да обяснявам защо.

Алтернатива на това е да съхранявате конфигурации в променливи на средата. Можете да прочетете повече за променливите на средата тук.

Примери за данни, които обикновено се съхраняват в променливи на средата:

• Имена на домейни
• API URL/URI адреси
• Публични и частни ключове
• Контакти (поща, телефони и др.)

По този начин не е необходимо постоянно да променяте кода, ако вашите конфигурационни променливи се променят. Това ще ви помогне да спестите време, усилия и пари.

Например, ако използвате API на Kaggle за провеждане на тестове (например, изтеглете софтуера и стартирайте модела през него, за да тествате, когато работите дали моделът работи добре), тогава частните ключове от Kaggle, като KAGGLE_USERNAME и KAGGLE_KEY, трябва да бъдат съхранявани в променливи на средата.

Принцип 4: Услуги на трети страни

Идеята тук е да се създаде програмата по такъв начин, че да няма разлика между местни ресурси и ресурси на трети страни по отношение на кода. Например, можете да свържете както локален MySQL, така и такива на трети страни. Същото важи и за различни API като Google Maps или Twitter API.

За да деактивирате услуга на трета страна или да свържете друга, просто трябва да промените ключовете в конфигурацията в променливите на средата, за които говорих в параграфа по-горе.

Така например, вместо всеки път да указвате пътя към файловете с набори от данни вътре в кода, по-добре е да използвате библиотеката pathlib и да декларирате пътя до наборите от данни в config.py, така че без значение каква услуга използвате (за например CircleCI), програмата успя да намери пътя до наборите от данни, като взе предвид структурата на новата файлова система в новата услуга.

Принцип 5. Изграждане, пускане, изпълнение

Много хора в Data Science намират за полезно да подобрят своите умения за писане на софтуер. Ако искаме нашата програма да се срива възможно най-рядко и да работи безпроблемно възможно най-дълго, трябва да разделим процеса на пускане на нова версия на 3 етапа:

1. етап сглобки. Трансформирате своя гол код с индивидуални ресурси в така наречен пакет, който съдържа целия необходим код и данни. Този пакет се нарича сборка.
2. етап пускане — тук свързваме нашата конфигурация към сборката, без която не бихме могли да пуснем нашата програма. Сега това е напълно готова за пускане версия.
3. Следва сцената изпълнение. Тук пускаме приложението, като изпълняваме необходимите процеси от нашата версия.

Такава система за пускане на нови версии на модел или целия конвейер ви позволява да разделите ролите между администратори и разработчици, позволява ви да проследявате версиите и предотвратява нежелано спиране на програмата.

За задачата за освобождаване са създадени много различни услуги, в които можете да пишете процеси, които да изпълнявате сами в .yml файл (например в CircleCI това е config.yml за поддръжка на самия процес). Wheee е страхотен в създаването на пакети за проекти.

Можете да създадете пакети с различни версии на вашия модел за машинно обучение и след това да ги пакетирате и да се обърнете към необходимите пакети и техните версии, за да използвате функциите, които сте написали от там. Това ще ви помогне да създадете API за вашия модел и вашият пакет може да бъде хостван на Gemfury, например.

Принцип 6. Стартирайте вашия модел като един или повече процеси

Освен това процесите не трябва да имат споделени данни. Тоест, процесите трябва да съществуват отделно и всички видове данни трябва да съществуват отделно, например в услуги на трети страни като MySQL или други, в зависимост от това, от което се нуждаете.

Тоест, определено не си струва да съхранявате данни във файловата система на процеса, в противен случай това може да доведе до изчистване на тези данни по време на следващото издание/промяна на конфигурации или прехвърляне на системата, на която работи програмата.

Но има изключение: за проекти за машинно обучение можете да съхранявате кеш от библиотеки, за да не ги преинсталирате всеки път, когато стартирате нова версия, ако не са направени допълнителни библиотеки или промени в техните версии. По този начин ще намалите времето, необходимо за пускане на вашия модел в индустрията.

За да стартирате модела като няколко процеса, можете да създадете .yml файл, в който да посочите необходимите процеси и тяхната последователност.

Принцип 7: Възможност за рециклиране

Процесите, които се изпълняват във вашето моделно приложение, трябва да могат лесно да се стартират и спират. По този начин това ще ви позволи бързо да внедрявате промени в кода, промени в конфигурацията, бързо и гъвкаво мащабиране и предотвратяване на възможни повреди на работещата версия.

Тоест вашият процес с модела трябва:

• Минимизирайте времето за стартиране. В идеалния случай времето за стартиране (от момента на подаване на командата за стартиране до момента, в който процесът влезе в действие) не трябва да бъде повече от няколко секунди. Кеширането на библиотеката, описано по-горе, е една техника за намаляване на времето за стартиране.
• Край правилно. Това означава, че слушането на сервизния порт всъщност е спряно и новите заявки, изпратени до този порт, няма да бъдат обработени. Тук или трябва да настроите добра комуникация с инженерите на DevOps, или да разберете как работи сами (за предпочитане, разбира се, последното, но комуникацията винаги трябва да се поддържа във всеки проект!)

Принцип 8: Непрекъснато внедряване/интегриране

Много компании използват разделение между екипите за разработка и внедряване на приложения (правейки приложението достъпно за крайните потребители). Това може значително да забави развитието на софтуера и напредъка в подобряването му. Освен това разваля културата на DevOps, където развитието и интеграцията са, грубо казано, комбинирани.

Следователно този принцип гласи, че вашата среда за разработка трябва да бъде възможно най-близо до вашата производствена среда.

Това ще позволи:

1. Намалете времето за освобождаване десетки пъти
2. Намалете броя на грешките поради несъвместимост на кода.
3. Това също намалява натоварването на персонала, тъй като разработчиците и хората, внедряващи приложението, вече са един екип.

Инструменти, които ви позволяват да работите с това са CircleCI, Travis CI, GitLab CI и други.

Можете бързо да правите допълнения към модела, да го актуализирате и да го стартирате незабавно, докато в случай на повреда ще бъде лесно да се върнете много бързо към работната версия, така че крайният потребител дори да не го забележи. Това може да стане особено лесно и бързо, ако имате добри тестове.

Минимизирайте разликите!!!

Принцип 9. Вашите дневници

Дневниците (или „Дневниците“) са събития, обикновено записани в текстов формат, които се случват в приложението (поток от събития). Прост пример: "2020-02-02 - системно ниво - име на процес." Те са проектирани така, че разработчикът да може буквално да вижда какво се случва, когато програмата работи. Той вижда напредъка на процесите и разбира дали е така, както е замислил самият разработчик.

Този принцип гласи, че не трябва да съхранявате вашите регистрационни файлове във вашата файлова система - трябва просто да ги „изведете“ на екрана, например, направете това на стандартния изход на системата. И по този начин ще бъде възможно да се следи потокът в терминала по време на разработката.

Това означава ли, че изобщо не е необходимо да се записват регистрационни файлове? Разбира се, че не. Вашето приложение просто не трябва да прави това - оставете го на услуги на трети страни. Вашето приложение може само да препраща регистрационни файлове към конкретен файл или терминал за преглед в реално време или да ги препраща към система за съхранение на данни с общо предназначение (като Hadoop). Самото ви приложение не трябва да съхранява или да взаимодейства с регистрационни файлове.

Принцип 10. Тествайте!

За индустриалното машинно обучение тази фаза е изключително важна, тъй като трябва да разберете, че моделът работи правилно и произвежда това, което искате.

Тестовете могат да бъдат създадени с помощта на pytest и тествани с помощта на малък набор от данни, ако имате задача за регресия/класификация.

Не забравяйте да зададете една и съща начална стойност за моделите за задълбочено обучение, така че те да не произвеждат постоянно различни резултати.

Това беше кратко описание на 10-те принципа и, разбира се, е трудно да ги използвате, без да опитате и видите как работят, така че тази статия е само пролог към поредица от интересни статии, в които ще разкрия как да създавате индустриални модели за машинно обучение, как да ги интегрираме в системи и как тези принципи могат да улеснят живота на всички нас.

Ще се опитам да използвам и готини принципи, които всеки може да остави в коментарите, ако желае.

Източник: www.habr.com