ProHoster > Blogs > Administrācija > RÅ«pnieciskā maŔīnmācÄ«ba: 10 projektÄ“Å”anas principi

RÅ«pnieciskā maŔīnmācÄ«ba: 10 projektÄ“Å”anas principi

RÅ«pnieciskā maŔīnmācÄ«ba: 10 projektÄ“Å”anas principi

MÅ«sdienās katru dienu tiek radÄ«ti jauni pakalpojumi, aplikācijas un citas svarÄ«gas programmas, kas ļauj radÄ«t neticamas lietas: no programmatÅ«ras SpaceX raÄ·etes vadÄ«Å”anai lÄ«dz mijiedarbÄ«bai ar tējkannu blakus istabā, izmantojot viedtālruni.

Un dažreiz katrs iesācējs programmētājs, neatkarÄ«gi no tā, vai viņŔ ir kaislÄ«gs iesācējs vai parasts Full Stack vai Data Scientist, agrāk vai vēlāk saprot, ka programmÄ“Å”anai un programmatÅ«ras izveidei ir noteikti noteikumi, kas ievērojami vienkārÅ”o dzÄ«vi.

Å ajā rakstā es Ä«si aprakstÄ«Å”u 10 principus, kā programmēt industriālo maŔīnmācÄ«bu tā, lai to varētu viegli integrēt lietojumprogrammā/pakalpojumā, pamatojoties uz 12-faktoru App metodoloÄ£iju. ieteikusi Heroku komanda. Mana iniciatÄ«va ir palielināt izpratni par Å”o tehniku, kas var palÄ«dzēt daudziem izstrādātājiem un datu zinātnes cilvēkiem.

Å is raksts ir prologs rakstu sērijai par rÅ«pniecisko maŔīnmācÄ«Å”anos. Tajos es tālāk runāŔu par to, kā reāli izgatavot modeli un palaist to ražoÅ”anā, izveidot tam API, kā arÄ« piemērus no dažādām jomām un uzņēmumiem, kuru sistēmās ir iebÅ«vēts ML.

1. princips: viena koda bāze

Daži programmētāji pirmajos posmos aiz slinkuma to izdomāt (vai kaut kādu iemeslu dēļ) aizmirst par Gitu. Viņi vai nu pilnÄ«bā aizmirst vārdu, tas ir, viņi izmet failus viens otram diskā / vienkārÅ”i izmet tekstu / sÅ«ta baložus, vai arÄ« viņi nepārdomā savu darbplÅ«smu un piesaista katrs savā filiālē un pēc tam meistars.

Šis princips nosaka: ir viena kodu bāze un daudzi izvietojumi.

Git var izmantot gan ražoÅ”anā, gan pētniecÄ«bā un attÄ«stÄ«bā (R&D), kurā tas netiek izmantots tik bieži.

Piemēram, pētniecības un attīstības fāzē varat atstāt saistības ar dažādām datu apstrādes metodēm un modeļiem, lai pēc tam izvēlētos labāko un ērti turpinātu darbu ar to tālāk.

Otrkārt, ražoÅ”anā tā ir neaizvietojama lieta ā€“ jums bÅ«s nepārtraukti jāskatās, kā mainās jÅ«su kods un jāzina, kurÅ” modelis sniedza vislabākos rezultātus, kurÅ” kods beigās darbojās un kas notika, kā rezultātā tas pārstāja darboties vai sāka radÄ«t nepareizus rezultātus. . Tam ir paredzētas saistÄ«bas!

Varat arÄ« izveidot sava projekta paketi, ievietojot to, piemēram, Gemfury un pēc tam vienkārÅ”i importējot no tās funkcijas citiem projektiem, lai tās nepārrakstÄ«tu 1000 reizes, bet par to vēlāk.

2. princips: skaidri deklarējiet un izolējiet atkarības

Katram projektam ir dažādas bibliotēkas, kuras importējat no ārpuses, lai tās kaut kur lietotu. Neatkarīgi no tā, vai tās ir Python bibliotēkas vai citu valodu bibliotēkas dažādiem mērķiem, vai sistēmas rīki - jūsu uzdevums ir:

  • Skaidri deklarējiet atkarÄ«bas, tas ir, failu, kurā bÅ«s visas bibliotēkas, rÄ«ki un to versijas, kas tiek izmantotas jÅ«su projektā un kas ir jāinstalē (piemēram, Python to var izdarÄ«t, izmantojot Pipfile vai prasÄ«bas.txt. A saite, kas ļauj labi saprast: realpython.com/pipenv-guide)
  • Izstrādes laikā noŔķiriet atkarÄ«bas tieÅ”i savai programmai. Vai nevēlaties pastāvÄ«gi mainÄ«t versijas un pārinstalēt, piemēram, Tensorflow?

Tādējādi izstrādātāji, kas nākotnē pievienosies jÅ«su komandai, varēs ātri iepazÄ«ties ar bibliotēkām un to versijām, kas tiek izmantotas jÅ«su projektā, kā arÄ« jums bÅ«s iespēja pārvaldÄ«t paÅ”as versijas un bibliotēkas, kas instalētas konkrētam mērÄ·im. projektu, kas palÄ«dzēs izvairÄ«ties no bibliotēku vai to versiju nesaderÄ«bas.

JÅ«su lietojumprogrammai nevajadzētu paļauties arÄ« uz sistēmas rÄ«kiem, kas var bÅ«t instalēti noteiktā operētājsistēmā. Å ie rÄ«ki ir jādeklarē arÄ« atkarÄ«bu manifestā. Tas nepiecieÅ”ams, lai izvairÄ«tos no situācijām, kad rÄ«ku versija (kā arÄ« to pieejamÄ«ba) neatbilst konkrētas OS sistēmas rÄ«kiem.

Tādējādi, pat ja curl var izmantot gandrÄ«z visos datoros, jums tas joprojām ir jādeklarē atkarÄ«bās, jo, migrējot uz citu platformu, tās var nebÅ«t vai arÄ« versija nebÅ«s tā, kas jums sākotnēji bija nepiecieÅ”ama.

Piemēram, jÅ«su prasÄ«bas.txt varētu izskatÄ«ties Ŕādi:

# 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. princips: konfigurācijas

Daudzi ir dzirdējuÅ”i stāstus par dažādiem izstrādātājiem, kuri nejauÅ”i augÅ”upielādēja kodu GitHub publiskajās krātuvēs ar parolēm un citām AWS atslēgām, nākamajā dienā pamostoties ar parādu 6000 vai pat 50000 XNUMX ASV dolāru apmērā.

RÅ«pnieciskā maŔīnmācÄ«ba: 10 projektÄ“Å”anas principi

Protams, Å”ie gadÄ«jumi ir ārkārtēji, bet ļoti nozÄ«mÄ«gi. Ja kodā saglabājat savus akreditācijas datus vai citus konfigurÄ“Å”anai nepiecieÅ”amos datus, jÅ«s pieļaujat kļūdu, un es domāju, ka nav nepiecieÅ”ams paskaidrot, kāpēc.

Alternatīva tam ir saglabāt konfigurācijas vides mainīgajos. Varat lasīt vairāk par vides mainīgajiem Ŕeit.

Datu piemēri, kas parasti tiek glabāti vides mainīgajos:

  • Domēna vārdi
  • API URL/URI
  • Publiskās un privātās atslēgas
  • Kontakti (pasts, tālruņi utt.)

Tādā veidā jums nav pastāvīgi jāmaina kods, ja mainās jūsu konfigurācijas mainīgie. Tas palīdzēs ietaupīt laiku, pūles un naudu.

Piemēram, ja izmantojat Kaggle API, lai veiktu testus (piemēram, lejupielādējiet programmatÅ«ru un palaidiet modeli caur to, lai palaiÅ”anas laikā pārbaudÄ«tu, vai modelis darbojas labi), tad privātajām Kaggle atslēgām, piemēram, KAGGLE_USERNAME un KAGGLE_KEY, ir jābÅ«t glabājas vides mainÄ«gajos.

4. princips. TreŔās puses pakalpojumi

Å eit ir ideja izveidot programmu tā, lai koda ziņā nebÅ«tu atŔķirÄ«bas starp vietējiem un treÅ”o puÅ”u resursiem. Piemēram, varat savienot gan vietējos MySQL, gan treŔās puses. Tas pats attiecas uz dažādām API, piemēram, Google Maps vai Twitter API.

Lai atspējotu treŔās puses pakalpojumu vai savienotu citu, jums vienkārÅ”i jāmaina konfigurācijas atslēgas vides mainÄ«gajos, par ko es runāju iepriekŔējā punktā.

Tā, piemēram, tā vietā, lai katru reizi norādītu ceļu uz failiem ar datu kopām kodā, labāk ir izmantot pathlib bibliotēku un deklarēt ceļu uz datu kopām failā config.py, lai neatkarīgi no tā, kādu pakalpojumu izmantojat ( piemēram, CircleCI), programma varēja noskaidrot ceļu uz datu kopām, ņemot vērā jaunās failu sistēmas struktūru jaunajā pakalpojumā.

5. princips. BūvēŔana, izlaiŔana, izpildes laiks

Daudzi datu zinātnes speciālisti uzskata, ka ir noderÄ«gi uzlabot savas programmatÅ«ras rakstÄ«Å”anas prasmes. Ja vēlamies, lai mÅ«su programma avarētu pēc iespējas retāk un darbotos bez kļūmēm pēc iespējas ilgāk, jaunas versijas izlaiÅ”anas process ir jāsadala 3 posmos:

  1. Posms mezgli. Jūs pārveidojat savu tukŔo kodu ar atseviŔķiem resursiem par tā saukto paketi, kurā ir viss nepiecieŔamais kods un dati. Šo paketi sauc par montāžu.
  2. Posms atbrÄ«vot ā€” Å”eit mēs savienojam savu konfigurāciju ar montāžu, bez kuras mēs nevarētu atbrÄ«vot savu programmu. Tagad tas ir pilnÄ«bā gatavs izlaiÅ”anai.
  3. Tālāk nāk posms izpildi. Å eit mēs izlaižam lietojumprogrammu, palaižot nepiecieÅ”amos procesus no mÅ«su laidiena.

Šāda modeļa vai visa konveijera jaunu versiju izlaiÅ”anas sistēma ļauj nodalÄ«t lomas starp administratoriem un izstrādātājiem, ļauj izsekot versijām un novērÅ” nevēlamas programmas apstāŔanās.

IzlaiÅ”anas uzdevumam ir izveidoti daudzi dažādi pakalpojumi, kuros varat rakstÄ«t procesus, lai palaistu sevi .yml failā (piemēram, CircleCI tas ir config.yml, lai atbalstÄ«tu paÅ”u procesu). Wheely lieliski spēj izveidot projektu paketes.

Varat izveidot pakotnes ar dažādām maŔīnmācÄ«Å”anās modeļa versijām un pēc tam tās iesaiņot un atsaukties uz nepiecieÅ”amajām pakotnēm un to versijām, lai izmantotu no turienes rakstÄ«tās funkcijas. Tas palÄ«dzēs izveidot API savam modelim, un jÅ«su pakotne var tikt mitināta, piemēram, vietnē Gemfury.

6. princips. Palaidiet modeli kā vienu vai vairākus procesus

Turklāt procesiem nevajadzētu bÅ«t koplietotiem datiem. Tas nozÄ«mē, ka procesiem ir jāpastāv atseviŔķi, un visu veidu datiem ir jāpastāv atseviŔķi, piemēram, treÅ”o puÅ”u pakalpojumos, piemēram, MySQL vai citos, atkarÄ«bā no tā, kas jums nepiecieÅ”ams.

Tas ir, noteikti nav vērts glabāt datus procesa failu sistēmā, pretējā gadÄ«jumā tas var novest pie Å”o datu notÄ«rÄ«Å”anas nākamās izlaiÅ”anas/konfigurācijas maiņas vai sistēmas, kurā darbojas programma, pārsÅ«tÄ«Å”anas laikā.

Taču ir izņēmums: maŔīnmācÄ«Å”anās projektiem varat saglabāt bibliotēku keÅ”atmiņu, lai tās netiktu atkārtoti instalētas ikreiz, kad palaižat jaunu versiju, ja nav veiktas papildu bibliotēkas vai to versijās nav veiktas nekādas izmaiņas. Tādā veidā jÅ«s samazināsiet laiku, kas nepiecieÅ”ams modeļa ievieÅ”anai rÅ«pniecÄ«bā.

Lai modeli palaistu kā vairākus procesus, varat izveidot .yml failu, kurā norādīt nepiecieŔamos procesus un to secību.

7. princips. Pārstrādājamība

Procesus, kas darbojas jūsu modeļa lietojumprogrammā, jābūt viegli iesāktiem un apturētiem. Tādējādi tas ļaus ātri izvietot koda izmaiņas, konfigurācijas izmaiņas, ātri un elastīgi mērogot un novērst iespējamos darba versijas bojājumus.

Tas nozīmē, ka jūsu procesam ar modeli vajadzētu:

  • Samaziniet palaiÅ”anas laiku. Ideālā gadÄ«jumā palaiÅ”anas laikam (no startÄ“Å”anas komandas izdoÅ”anas brīža lÄ«dz procesa sākumam) nevajadzētu bÅ«t garākam par dažām sekundēm. IepriekÅ” aprakstÄ«tā bibliotēkas keÅ”atmiņa ir viens no paņēmieniem startÄ“Å”anas laika samazināŔanai.
  • Beigt pareizi. Tas ir, klausÄ«Å”anās apkalpoÅ”anas portā faktiski tiek apturēta, un jauni Å”ajā portā iesniegtie pieprasÄ«jumi netiks apstrādāti. Å eit jums vai nu jāizveido laba saziņa ar DevOps inženieriem, vai arÄ« paÅ”am jāsaprot, kā tas darbojas (vēlams, protams, pēdējais, taču komunikācija vienmēr ir jāuztur jebkurā projektā!)

8. princips. Nepārtraukta izvietoŔana/integrācija

Daudzi uzņēmumi izmanto atdalÄ«Å”anu starp lietojumprogrammu izstrādes un izvietoÅ”anas komandām (padarot lietojumprogrammu pieejamu galalietotājiem). Tas var ievērojami palēnināt programmatÅ«ras izstrādi un progresu tās uzlaboÅ”anā. Tas arÄ« sabojā DevOps kultÅ«ru, kur attÄ«stÄ«ba un integrācija, rupji runājot, ir apvienota.

Tāpēc Å”is princips nosaka, ka jÅ«su izstrādes videi ir jābÅ«t pēc iespējas tuvākai jÅ«su ražoÅ”anas videi.

Tas ļaus:

  1. Samaziniet izlaiŔanas laiku desmitiem reižu
  2. Samaziniet kļūdu skaitu koda nesaderības dēļ.
  3. Tas arī samazina personāla darba slodzi, jo izstrādātāji un cilvēki, kas izvieto lietojumprogrammu, tagad ir viena komanda.

Rīki, kas ļauj strādāt ar to, ir CircleCI, Travis CI, GitLab CI un citi.

Modelim var ātri veikt papildinājumus, to atjaunināt un nekavējoties palaist, savukārt kļūmju gadÄ«jumā bÅ«s viegli ļoti ātri atgriezties darba versijā, lai gala lietotājs to nemaz nepamanÄ«tu. ÄŖpaÅ”i viegli un ātri to var izdarÄ«t, ja jums ir labi testi.

Samazini atŔķirības!!!

9. princips. Jūsu žurnāli

Žurnāli (vai ā€œÅ½urnāliā€) ir notikumi, kas parasti tiek ierakstÄ«ti teksta formātā un notiek lietojumprogrammā (notikumu straumē). VienkārÅ”s piemērs: "2020-02-02 ā€” sistēmas lÄ«menis ā€” procesa nosaukums." Tie ir izstrādāti tā, lai izstrādātājs varētu burtiski redzēt, kas notiek, kad programma darbojas. ViņŔ redz procesu gaitu un saprot, vai tas ir tā, kā iecerējis pats izstrādātājs.

Å is princips nosaka, ka jums nevajadzētu glabāt savus žurnālus savā failu sistēmā - jums tie vienkārÅ”i ir ā€œjāizvadaā€ ekrānā, piemēram, tas jādara ar sistēmas standarta izvadi. Un tādā veidā izstrādes laikā bÅ«s iespējams uzraudzÄ«t plÅ«smu terminālÄ«.

Vai tas nozÄ«mē, ka žurnāli vispār nav jāsaglabā? Protams, nē. JÅ«su lietojumprogrammai to nevajadzētu darÄ«t ā€” atstājiet to treÅ”o puÅ”u pakalpojumu ziņā. JÅ«su lietojumprogramma var pārsÅ«tÄ«t žurnālus tikai uz noteiktu failu vai termināli, lai tos skatÄ«tu reāllaikā, vai pārsÅ«tÄ«t tos uz vispārējas nozÄ«mes datu glabāŔanas sistēmu (piemēram, Hadoop). JÅ«su lietojumprogrammai nevajadzētu glabāt žurnālus vai mijiedarboties ar tiem.

Princips 10. Pārbaudi!

RÅ«pnieciskajai maŔīnmācÄ«bai Å”is posms ir ārkārtÄ«gi svarÄ«gs, jo jums ir jāsaprot, ka modelis darbojas pareizi un rada to, ko vēlaties.

Testus var izveidot, izmantojot pytest, un pārbaudīt, izmantojot nelielu datu kopu, ja jums ir regresijas/klasifikācijas uzdevums.

Neaizmirstiet iestatÄ«t vienu un to paÅ”u sēklu dziļās mācÄ«Å”anās modeļiem, lai tie pastāvÄ«gi neradÄ«tu atŔķirÄ«gus rezultātus.

Å is bija Ä«ss 10 principu apraksts, un, protams, tos ir grÅ«ti izmantot, neizmēģinot un neredzot, kā tie darbojas, tāpēc Å”is raksts ir tikai prologs interesantu rakstu sērijai, kurā atklāŔu, kā izveidot rÅ«pnieciskās maŔīnmācÄ«Å”anās modeļi , kā tos integrēt sistēmās un kā Å”ie principi var atvieglot mÅ«su visu dzÄ«vi.

MēģināŔu izmantot arÄ« forÅ”us principus, kurus ikviens var atstāt komentāros, ja vēlas.

Avots: www.habr.com

Pievieno komentāru