Өнөр жай машиналарын үйрөнүү: 10 долбоорлоо принциптери

Өнөр жай машиналарын үйрөнүү: 10 долбоорлоо принциптери

Бүгүнкү күндө укмуштуудай нерселерди жаратууга мүмкүндүк берген жаңы кызматтар, тиркемелер жана башка маанилүү программалар күн сайын түзүлүүдө: SpaceX ракетасын башкаруу үчүн программалык камсыздоодон баштап, смартфон аркылуу кийинки бөлмөдөгү чайнек менен иштешүүгө чейин.

Жана, кээде, ар бир башталгыч программист, мейли ал жалындуу стартапчы болобу, же кадимки Full Stack же Data Scientist болобу, эртеби-кечпи программалоонун жана программалык камсыздоону түзүүнүн белгилүү бир эрежелери бар экенин түшүнөт, алар жашоону абдан жөнөкөйлөтөт.

Бул макалада мен 10 фактордук Колдонмонун методологиясынын негизинде колдонмого/кызматка оңой интеграцияланышы үчүн өнөр жайлык машинаны үйрөнүүнү кантип программалоонун 12 принциптерин кыскача сүрөттөп берем. Heroku командасы тарабынан сунушталган. Менин демилгесим - көптөгөн иштеп чыгуучуларга жана маалымат илиминдеги адамдарга жардам бере турган бул техниканын маалымдуулугун жогорулатуу.

Бул макала өнөр жайлык машиналарды үйрөнүү жөнүндө бир катар макалалардын прологу. Аларда мен андан ары моделди кантип жасоо жана аны өндүрүшкө киргизүү, ал үчүн API түзүү, ошондой эле системаларында ML орнотулган ар кандай аймактардан жана компаниялардан мисалдар жөнүндө сүйлөшөм.

1-принцип: Бир код базасы

Кээ бир программисттер биринчи этапта аны түшүнүү үчүн жалкоолуктан (же кандайдыр бир себептерден улам) Гитти унутуп коюшат. Алар же бул сөздү таптакыр унутуп коюшат, башкача айтканда, дискте бири-бирине файлдарды ыргытып жиберишет/жөн гана текст ыргытышат/көгүчкөндөр аркылуу жөнөтүшөт, же алардын иш процессин ойлонбой, ар бирин өз бутагына, анан агай.

Бул принцип мындай дейт: бир код базасы жана көптөгөн жайылтуулары бар.

Git өндүрүштө да, илимий-изилдөө жана өнүктүрүүдө да (R&D) колдонулушу мүмкүн, анда ал көп колдонулбайт.

Мисалы, R&D фазасында сиз эң жакшысын тандап алуу жана аны менен иштөөнү оңой улантуу үчүн маалыматтарды иштетүүнүн ар кандай ыкмалары жана моделдери менен милдеттенмелерди калтырсаңыз болот.

Экинчиден, өндүрүштө бул алмаштырылгыс нерсе - сиз дайыма сиздин кодуңуздун кандайча өзгөргөнүн карап, кайсы модель эң жакшы натыйжаларды бергенин, аягында кайсы код иштегенин жана анын иштебей калышына же туура эмес натыйжаларды бере баштаганын билүү керек. . Милдеттенмелер ошол үчүн!

Сиз ошондой эле долбооруңуздун пакетин түзүп, аны, мисалы, Gemfury-ге жайгаштырып, андан кийин жөн гана башка долбоорлор үчүн функцияларды импорттосоңуз болот, аларды 1000 жолу кайра жазбаш үчүн, бирок кийинчерээк көбүрөөк.

2-принцип: Көз карандылыкты так жарыялоо жана изоляциялоо

Ар бир долбоордо сиз аларды бир жерде колдонуу үчүн сырттан импорттогон ар кандай китепканалар бар. Бул Python китепканалары болобу, же ар кандай максаттар үчүн башка тилдердин китепканалары болобу же тутум куралдары болобу - сиздин милдетиңиз:

• Көз карандылыкты так жарыялаңыз, башкача айтканда, сиздин долбооруңузда колдонулган жана орнотулушу керек болгон бардык китепканаларды, куралдарды жана алардын версияларын камтый турган файл (мисалы, Pythonдо муну Pipfile же талаптар.txt аркылуу жасоого болот. A. жакшы түшүнүүгө мүмкүндүк берген шилтеме: 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 доллар, ал тургай XNUMX XNUMX доллар карызы менен ойгонгону тууралуу окуяларды уккан.

Албетте, бул учурлар экстремалдык, бирок абдан маанилүү. Эгерде сиз коддун ичинде конфигурациялоо үчүн керектүү маалыматтарыңызды же башка маалыматтарды сактасаңыз, анда сиз ката кетирип жатасыз жана мунун себебин түшүндүрүүнүн кереги жок деп ойлойм.

Буга альтернатива - конфигурацияларды чөйрө өзгөрмөлөрүндө сактоо. Сиз айлана-чөйрө өзгөрмөлөрү жөнүндө көбүрөөк окуй аласыз бул жерде.

Адатта чөйрө өзгөрмөлөрүндө сакталган маалыматтардын мисалдары:

• Домен аттары
• API URL'дери/URI'дери
• Ачык жана купуя ачкычтар
• Байланыш (почта, телефондор ж.б.)

Ошентип, конфигурацияңыздын өзгөрмөлөрү өзгөрсө, кодду тынымсыз өзгөртүүнүн кажети жок. Бул убакытты, күч-аракетти жана акчаны үнөмдөөгө жардам берет.

Мисалы, сиз сыноолорду өткөрүү үчүн Kaggle API колдонсоңуз (мисалы, программаны жүктөп алып, моделдин жакшы иштеп жатканын текшерүү үчүн ал аркылуу моделди иштетиңиз), анда Kaggle'дун KAGGLE_USERNAME жана KAGGLE_KEY сыяктуу купуя ачкычтары болушу керек. чөйрө өзгөрмөлөрүндө сакталат.

4-принцип: Үчүнчү Тарап Кызматтары

Бул жерде идея программаны код жагынан жергиликтүү жана үчүнчү тараптын ресурстарынын ортосунда эч кандай айырма болбогудай кылып түзүү. Мисалы, сиз жергиликтүү MySQL жана үчүнчү тараптарды туташтыра аласыз. Ошол эле Google Карталар же Twitter API сыяктуу ар кандай API'лерге да тиешелүү.

Үчүнчү тараптын кызматын өчүрүү же башкасын туташтыруу үчүн, сиз жөн гана жогорудагы абзацта айткан чөйрө өзгөрмөлөрүндөгү конфигурациядагы баскычтарды өзгөртүшүңүз керек.

Ошентип, мисалы, коддун ичиндеги берилиштер топтому бар файлдарга жолду ар бир жолу көрсөтүүнүн ордуна, pathlib китепканасын колдонуп, config.py ичинде берилиштер топтомуна жолду жарыялоо жакшы, ошондуктан сиз кандай кызматты колдонбоңуз (үчүн Мисалы, CircleCI), программа жаңы кызматта жаңы файл тутумунун түзүмүн эске алуу менен берилиштер топтомуна жолду таба алды.

Принцип 5. Куруу, чыгаруу, аткаруу убактысы

Маалымат илиминдеги көптөгөн адамдар программалык камсыздоону жазуу көндүмдөрүн жакшыртууну пайдалуу деп эсептешет. Эгерде биз программабыздын мүмкүн болушунча сейрек бузулушун кааласак жана мүмкүн болушунча узак убакыт бою үзгүлтүксүз иштешин кааласак, жаңы версияны чыгаруу процессин 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-принцип. Test!

Өнөр жай машинасын үйрөнүү үчүн бул этап өтө маанилүү, анткени сиз модель туура иштеп, сиз каалаган нерсени чыгара тургандыгын түшүнүшүңүз керек.

Тесттерди pytest аркылуу түзсө болот, эгер сизде регрессия/классификация тапшырмасы бар болсо, кичинекей берилиштер топтомун колдонуп сынаса болот.

Алар ар дайым ар кандай натыйжаларды бербеши үчүн, терең үйрөнүү моделдери үчүн бир эле үрөндү коюуну унутпаңыз.

Бул 10 принциптин кыскача сүрөттөлүшү эле, жана, албетте, аларды сынап көрбөй жана кантип иштээрин көрбөй колдонуу кыйын, ошондуктан бул макала жөн гана кызыктуу макалалардын бир катар прологу, анда мен кантип түзүү керектигин ачып берем. өнөр жайлык машина үйрөнүү моделдери, аларды системаларга кантип интеграциялоо керек жана бул принциптер баарыбыз үчүн жашоону кантип жеңилдетет.

Мен ошондой эле салкын принциптерди колдонууга аракет кылам, ким кааласа комментарийге калтыра алат.

Source: www.habr.com