Индустриско машинско учење: 10 принципи за дизајн

Индустриско машинско учење: 10 принципи за дизајн

Во денешно време, секојдневно се создаваат нови услуги, апликации и други важни програми кои овозможуваат создавање неверојатни работи: од софтвер за контрола на ракета на SpaceX до интеракција со котел во соседната соба преку паметен телефон.

И, понекогаш, секој програмер почетник, без разлика дали е страстен стартап или обичен Full Stack или Data Scientist, порано или подоцна сфаќа дека постојат одредени правила за програмирање и креирање софтвер кои во голема мера го поедноставуваат животот.

Во оваа статија, накратко ќе опишам 10 принципи како да се програмира индустриското машинско учење за да може лесно да се интегрира во апликација/услуга, врз основа на методологијата на апликацијата со 12 фактори. предложено од тимот на Хероку. Мојата иницијатива е да ја зголемам свесноста за оваа техника, која може да им помогне на многу програмери и луѓе од областа на науката за податоци.

Оваа статија е пролог на серија статии за индустриско машинско учење. Во нив понатаму ќе зборувам за тоа како всушност да направите модел и да го лансирате во производство, да креирате API за него, како и примери од различни области и компании кои имаат вградено ML во нивните системи.

Принцип 1: База на еден код

Некои програмери во првите фази, од мрзеливост да сфатат (или поради некоја своја причина), забораваат на Git. Тие или целосно го забораваат зборот, односно, си фрлаат датотеки еден на друг во дискот/само фрлаат текст/испраќаат од гулаби, или не размислуваат за нивниот работен тек и се обврзуваат секој на својата гранка, а потоа на господар.

Овој принцип вели: имаат една база на кодови и многу распоредувања.

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

На пример, во фазата на истражување и развој можете да оставите обврзници со различни методи и модели за обработка на податоци, со цел потоа да го изберете најдобриот и лесно да продолжите понатаму да работите со него.

Второ, во производството ова е незаменлива работа - ќе треба постојано да гледате како се менува вашиот код и да знаете кој модел дал најдобри резултати, кој код работел на крајот и што се случило што го натерало да престане да работи или да почне да произведува неточни резултати. . За тоа служат обврските!

Можете исто така да креирате пакет од вашиот проект, ставајќи го, на пример, на Gemfury, а потоа едноставно да внесувате функции од него за други проекти, за да не ги препишувате 1000 пати, туку повеќе за тоа подоцна.

Принцип 2: Јасно декларирајте и изолирајте ги зависностите

Секој проект има различни библиотеки кои ги увезувате однадвор за да ги примените некаде. Без разлика дали се работи за библиотеки на Python, или библиотеки на други јазици за различни намени, или системски алатки - вашата задача е:

• Јасно декларирајте зависности, односно датотека што ќе ги содржи сите библиотеки, алатки и нивните верзии што се користат во вашиот проект и кои мора да се инсталираат (на пример, во Python ова може да се направи со помош на Pipfile или барања.txt. врска што овозможува добро да се разбере: realpython.com/pipenv-guide)
• Изолирајте ги зависностите специјално за вашата програма за време на развојот. Не сакате постојано да менувате верзии и повторно да го инсталирате, на пример, Tensorflow?

На овој начин, програмерите кои ќе се приклучат на вашиот тим во иднина ќе можат брзо да се запознаат со библиотеките и нивните верзии што се користат во вашиот проект, а исто така ќе имате можност да управувате со самите верзии и библиотеки инсталирани за одредено проект, кој ќе ви помогне да избегнете некомпатибилност на библиотеките или нивните верзии.

Вашата апликација исто така не треба да се потпира на системски алатки кои може да се инсталираат на одреден ОС. Овие алатки мора да бидат декларирани и во манифестот за зависности. Ова е неопходно за да се избегнат ситуации кога верзијата на алатките (како и нивната достапност) не се совпаѓа со системските алатки на одреден ОС.

Така, дури и ако curl може да се користи на речиси сите компјутери, сепак треба да го декларирате во зависности, бидејќи при мигрирање на друга платформа може да ја нема или верзијата нема да биде онаа што првично ви требаше.

На пример, вашите барања.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 долари.

Се разбира, овие случаи се екстремни, но многу значајни. Ако ги чувате вашите ингеренции или други податоци потребни за конфигурација во кодот, правите грешка и мислам дека нема потреба да објаснувате зошто.

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

Примери на податоци што вообичаено се складираат во променливите на околината:

• Имиња на домени
• УРЛ-адреси/URI на API
• Јавни и приватни клучеви
• Контакти (пошта, телефони, итн.)

На овој начин не мора постојано да го менувате кодот доколку се променат вашите конфигурациски променливи. Ова ќе ви помогне да заштедите време, напор и пари.

На пример, ако користите Kaggle API за спроведување на тестови (на пример, преземете го софтверот и стартувајте го моделот преку него за да тестирате дали моделот работи добро), тогаш приватните клучеви од 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 за да го поддржи самиот процес). Wheely е одличен во креирањето пакети за проекти.

Можете да креирате пакети со различни верзии на вашиот модел за машинско учење, а потоа да ги спакувате и да се повикате на потребните пакети и нивните верзии за да ги користите функциите што сте ги напишале од таму. Ова ќе ви помогне да креирате 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