Արդյունաբերական մեքենաների ուսուցում. 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-ի կամ պահանջների.txt-ի միջոցով: A հղում, որը թույլ է տալիս լավ հասկանալ. realpython.com/pipenv-guide)
• Զարգացման ընթացքում առանձնացրեք կախվածությունը հատուկ ձեր ծրագրի համար: Չե՞ք ցանկանում անընդհատ փոխել տարբերակները և նորից տեղադրել, օրինակ, Tensorflow-ը:

Այսպիսով, ծրագրավորողները, ովքեր ապագայում կմիանան ձեր թիմին, կկարողանան արագ ծանոթանալ գրադարաններին և դրանց տարբերակներին, որոնք օգտագործվում են ձեր նախագծում, ինչպես նաև հնարավորություն կունենաք կառավարել իրենց կողմից տեղադրված տարբերակներն ու գրադարանները։ նախագիծ, որը կօգնի ձեզ խուսափել գրադարանների կամ դրանց տարբերակների անհամատեղելիությունից:

Ձեր հավելվածը նույնպես չպետք է հիմնվի համակարգի գործիքների վրա, որոնք կարող են տեղադրվել որոշակի ՕՀ-ում: Այս գործիքները նույնպես պետք է հայտարարվեն կախվածության մանիֆեստում: Սա անհրաժեշտ է, որպեսզի խուսափենք այնպիսի իրավիճակներից, երբ գործիքների տարբերակը (ինչպես նաև դրանց առկայությունը) չի համընկնում որոշակի ՕՀ-ի համակարգի գործիքներին:

Այսպիսով, նույնիսկ եթե curl-ը կարող է օգտագործվել գրեթե բոլոր համակարգիչների վրա, դուք դեռ պետք է այն հայտարարեք կախվածության մեջ, քանի որ այլ հարթակ տեղափոխելիս այն կարող է չլինել, կամ տարբերակը չլինի այն, ինչ ձեզ սկզբում անհրաժեշտ էր:

Օրինակ, ձեր request.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 պարտքով:

Իհարկե, այս դեպքերը ծայրահեղ են, բայց շատ էական։ Եթե ​​դուք ձեր հավատարմագրերը կամ կազմաձևման համար անհրաժեշտ այլ տվյալներ եք պահում կոդի ներսում, ապա սխալ եք թույլ տալիս, և կարծում եմ՝ կարիք չկա բացատրելու, թե ինչու:

Դրա այլընտրանքը կոնֆիգուրացիաների պահպանումն է շրջակա միջավայրի փոփոխականներում: Դուք կարող եք ավելին կարդալ շրջակա միջավայրի փոփոխականների մասին այստեղ.

Տվյալների օրինակներ, որոնք սովորաբար պահվում են շրջակա միջավայրի փոփոխականներում.

• Դոմենների անուններ
• API URL-ներ/URI-ներ
• Հանրային և մասնավոր բանալիներ
• Կոնտակտներ (փոստ, հեռախոսներ և այլն)

Այս կերպ դուք ստիպված չեք լինի անընդհատ փոխել կոդը, եթե ձեր կազմաձևման փոփոխականները փոխվեն: Սա կօգնի ձեզ խնայել ժամանակ, ջանք և գումար:

Օրինակ, եթե դուք օգտագործում եք Kaggle API-ն թեստեր անցկացնելու համար (օրինակ՝ ներբեռնեք ծրագրակազմը և գործարկեք մոդելը դրա միջոցով՝ փորձարկելու համար, որ մոդելը լավ է աշխատում), ապա Kaggle-ի անձնական բանալիները, ինչպիսիք են KAGGLE_USERNAME-ը և KAGGLE_KEY-ը, պետք է լինեն: պահվում է շրջակա միջավայրի փոփոխականներում:

Սկզբունք 4. Երրորդ կողմի ծառայություններ

Այստեղ գաղափարն այն է, որ ծրագիրը ստեղծվի այնպես, որ կոդի առումով տարբերություն չլինի տեղական և երրորդ կողմի ռեսուրսների միջև։ Օրինակ, դուք կարող եք միացնել ինչպես տեղական MySQL, այնպես էլ երրորդ կողմի: Նույնը վերաբերում է տարբեր API-ներին, ինչպիսիք են Google Maps-ը կամ Twitter 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. Թեստ.

Արդյունաբերական մեքենայական ուսուցման համար այս փուլը չափազանց կարևոր է, քանի որ դուք պետք է հասկանաք, որ մոդելը ճիշտ է աշխատում և արտադրում է այն, ինչ ցանկանում եք:

Թեստերը կարող են ստեղծվել pytest-ի միջոցով և փորձարկվել՝ օգտագործելով փոքր տվյալների բազա, եթե ունեք ռեգրեսիայի/դասակարգման առաջադրանք:

Մի մոռացեք նույն սերմը դնել խորը ուսուցման մոդելների համար, որպեսզի դրանք անընդհատ տարբեր արդյունքներ չտան:

Սա 10 սկզբունքների համառոտ նկարագրությունն էր, և, իհարկե, դժվար է դրանք օգտագործել առանց փորձելու և տեսնելու, թե ինչպես են դրանք աշխատում, ուստի այս հոդվածը պարզապես նախաբանն է մի շարք հետաքրքիր հոդվածների, որոնցում ես կբացահայտեմ, թե ինչպես ստեղծել Արդյունաբերական մեքենայական ուսուցման մոդելներ, ինչպես դրանք ինտեգրել համակարգերին և ինչպես այս սկզբունքները կարող են հեշտացնել բոլորիս կյանքը:

Կփորձեմ նաև օգտագործել թույն սկզբունքներ, որոնք ցանկության դեպքում յուրաքանչյուրը կարող է թողնել մեկնաբանություններում։

Source: www.habr.com