Mësimi i makinerive industriale: 10 parime të projektimit
Në ditët e sotme, shërbime të reja, aplikacione dhe programe të tjera të rëndësishme krijohen çdo ditë që bëjnë të mundur krijimin e gjërave të pabesueshme: nga softueri për kontrollin e një rakete SpaceX deri tek ndërveprimi me një kazan në dhomën tjetër nëpërmjet një smartphone.
Dhe, ndonjëherë, çdo programues fillestar, pavarësisht nëse ai është një startup i pasionuar apo një Full Stack ose shkencëtar i zakonshëm i të dhënave, herët a vonë kupton se ekzistojnë disa rregulla për programimin dhe krijimin e softuerëve që thjeshtojnë shumë jetën.
Në këtë artikull, unë do të përshkruaj shkurtimisht 10 parime se si të programohet mësimi i makinerive industriale në mënyrë që të mund të integrohet lehtësisht në një aplikacion/shërbim, bazuar në metodologjinë e aplikacionit 12-faktorësh. . Nisma ime është të rris ndërgjegjësimin për këtë teknikë, e cila mund të ndihmojë shumë zhvillues dhe njerëz të shkencës së të dhënave.
Ky artikull është një prolog i një serie artikujsh rreth Mësimit të Makinerisë industriale. Në to do të flas më tej se si të krijojmë një model dhe ta lëshojmë atë në prodhim, të krijojmë një API për të, si dhe shembuj nga fusha dhe kompani të ndryshme që kanë ML të integruar në sistemet e tyre.
Parimi 1: Baza e një kodi
Disa programues në fazat e para, nga përtacia për ta kuptuar atë (ose për ndonjë arsye të tyren), harrojnë Git-in. Ata ose e harrojnë plotësisht fjalën, d.m.th., i hedhin skedarë njëri-tjetrit në disk/thjesht hedhin tekst/dërgojnë nga pëllumbat, ose nuk mendojnë për rrjedhën e tyre të punës dhe angazhohen secili në degën e tij, dhe më pas në mjeshtër.
Ky parim thotë: kanë një bazë kodesh dhe shumë vendosje.
Git mund të përdoret si në prodhim ashtu edhe në kërkim dhe zhvillim (R&D), në të cilat nuk përdoret aq shpesh.
Për shembull, në fazën e R&D mund të lini angazhime me metoda dhe modele të ndryshme të përpunimit të të dhënave, në mënyrë që më pas të zgjidhni më të mirën dhe të vazhdoni lehtësisht të punoni më tej me të.
Së dyti, në prodhim kjo është një gjë e pazëvendësueshme - do t'ju duhet të shikoni vazhdimisht se si ndryshon kodi juaj dhe të dini se cili model prodhoi rezultatet më të mira, cili kod funksionoi në fund dhe çfarë ndodhi që bëri që ai të ndalojë së punuari ose të fillojë të prodhojë rezultate të pasakta . Për këtë janë angazhimet!
Ju gjithashtu mund të krijoni një paketë të projektit tuaj, duke e vendosur atë, për shembull, në Gemfury, dhe më pas thjesht duke importuar funksione prej tij për projekte të tjera, në mënyrë që të mos i rishkruani ato 1000 herë, por më shumë për këtë më vonë.
Parimi 2: Deklaroni dhe izoloni qartë varësitë
Çdo projekt ka biblioteka të ndryshme që i importoni nga jashtë për t'i zbatuar diku. Qofshin bibliotekat Python, ose biblioteka të gjuhëve të tjera për qëllime të ndryshme, ose mjete të sistemit - detyra juaj është:
- Deklaroni qartë varësitë, domethënë një skedar që do të përmbajë të gjitha bibliotekat, mjetet dhe versionet e tyre që përdoren në projektin tuaj dhe që duhet të instalohen (për shembull, në Python kjo mund të bëhet duke përdorur Pipfile ose kërkesat.txt. A lidhje që lejon mirë të kuptohet: )
- Izoloni varësitë posaçërisht për programin tuaj gjatë zhvillimit. Nuk dëshironi të ndryshoni vazhdimisht versionet dhe të riinstaloni, për shembull, Tensorflow?
Në këtë mënyrë, zhvilluesit që do t'i bashkohen ekipit tuaj në të ardhmen do të jenë në gjendje të njihen shpejt me bibliotekat dhe versionet e tyre që përdoren në projektin tuaj, si dhe ju do të keni mundësinë të menaxhoni vetë versionet dhe bibliotekat e instaluara për një specifikë specifike. projekt, i cili do t'ju ndihmojë të shmangni papajtueshmërinë e bibliotekave ose versioneve të tyre.
Aplikacioni juaj gjithashtu nuk duhet të mbështetet në mjetet e sistemit që mund të instalohen në një OS të veçantë. Këto mjete duhet gjithashtu të deklarohen në manifestin e varësive. Kjo është e nevojshme për të shmangur situatat kur versioni i mjeteve (si dhe disponueshmëria e tyre) nuk përputhet me mjetet e sistemit të një OS të veçantë.
Kështu, edhe nëse curl mund të përdoret pothuajse në të gjithë kompjuterët, përsëri duhet ta deklaroni atë në varësi, pasi kur migroni në një platformë tjetër mund të mos jetë aty ose versioni nuk do të jetë ai që ju nevojitet fillimisht.
Për shembull, kërkesat tuaja.txt mund të duket kështu:
# 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
Parimi 3: Konfigurimet
Shumë prej tyre kanë dëgjuar histori të djemve të ndryshëm zhvilluesish që ngarkojnë aksidentalisht kodin në GitHub në depo të hapura me fjalëkalime dhe çelësa të tjerë nga AWS, duke u zgjuar të nesërmen me një borxh prej 6000 dollarësh ose edhe 50000 dollarë.
Sigurisht, këto raste janë ekstreme, por shumë domethënëse. Nëse ruani kredencialet tuaja ose të dhëna të tjera të nevojshme për konfigurim brenda kodit, po bëni një gabim dhe mendoj se nuk ka nevojë të shpjegojë pse.
Një alternativë për këtë është ruajtja e konfigurimeve në variablat e mjedisit. Mund të lexoni më shumë rreth variablave të mjedisit .
Shembuj të të dhënave që zakonisht ruhen në variablat e mjedisit:
- Emrat e domeneve
- URL-të/URI-të API
- Çelësat publikë dhe privatë
- Kontaktet (posta, telefonat, etj.)
Në këtë mënyrë ju nuk keni nevojë të ndryshoni vazhdimisht kodin nëse ndryshojnë variablat e konfigurimit tuaj. Kjo do t'ju ndihmojë të kurseni kohë, përpjekje dhe para.
Për shembull, nëse përdorni API-në e Kaggle për të kryer teste (për shembull, shkarkoni softuerin dhe ekzekutoni modelin përmes tij për të provuar nëse modeli funksionon mirë), atëherë çelësat privatë nga Kaggle, si KAGGLE_USERNAME dhe KAGGLE_KEY, duhet të jenë të ruajtura në variablat e mjedisit.
Parimi 4: Shërbimet e Palës së Tretë
Ideja këtu është që të krijohet programi në atë mënyrë që të mos ketë dallim midis burimeve lokale dhe të palëve të treta për sa i përket kodit. Për shembull, mund të lidhni MySQL lokale dhe ato të palëve të treta. E njëjta gjë vlen edhe për API të ndryshme si Google Maps ose Twitter API.
Për të çaktivizuar një shërbim të palës së tretë ose për të lidhur një tjetër, thjesht duhet të ndryshoni çelësat në konfigurimin në variablat e mjedisit, për të cilat fola në paragrafin e mësipërm.
Kështu, për shembull, në vend që të specifikoni çdo herë shtegun për skedarët me grupe të dhënash brenda kodit, është më mirë të përdorni bibliotekën pathlib dhe të deklaroni shtegun për grupet e të dhënave në config.py, në mënyrë që pavarësisht se çfarë shërbimi përdorni (për shembull, CircleCI), programi ishte në gjendje të zbulonte rrugën drejt grupeve të të dhënave duke marrë parasysh strukturën e sistemit të ri të skedarëve në shërbimin e ri.
Parimi 5. Ndërtimi, lëshimi, koha e ekzekutimit
Shumë njerëz në Shkencën e të Dhënave e shohin të dobishme të përmirësojnë aftësitë e tyre të shkrimit të softuerit. Nëse duam që programi ynë të prishet sa më rrallë të jetë e mundur dhe të funksionojë pa dështime për aq kohë sa të jetë e mundur, ne duhet ta ndajmë procesin e lëshimit të një versioni të ri në 3 faza:
- Fazë kuvendet. Ju e transformoni kodin tuaj të zhveshur me burime individuale në një të ashtuquajtur paketë që përmban të gjithë kodin dhe të dhënat e nevojshme. Kjo paketë quhet asamble.
- Fazë lirim — këtu ne lidhim konfigurimin tonë me asamblenë, pa të cilën nuk do të ishim në gjendje ta lëshonim programin tonë. Tani ky është një version plotësisht i gatshëm për lançim.
- Më pas vjen skena përmbushje. Këtu ne lëshojmë aplikacionin duke ekzekutuar proceset e nevojshme nga lëshimi ynë.
Një sistem i tillë për lëshimin e versioneve të reja të një modeli ose të gjithë tubacionit ju lejon të ndani rolet midis administratorëve dhe zhvilluesve, ju lejon të gjurmoni versionet dhe parandaloni ndalesat e padëshiruara të programit.
Për detyrën e lëshimit, janë krijuar shumë shërbime të ndryshme në të cilat mund të shkruani procese për të ekzekutuar vetë në një skedar .yml (për shembull, në CircleCI kjo është config.yml për të mbështetur vetë procesin). Wheely është i shkëlqyeshëm në krijimin e paketave për projekte.
Mund të krijoni paketa me versione të ndryshme të modelit tuaj të mësimit të makinës dhe më pas t'i paketoni ato dhe t'i referoheni paketave të nevojshme dhe versioneve të tyre për të përdorur funksionet që keni shkruar prej andej. Kjo do t'ju ndihmojë të krijoni një API për modelin tuaj dhe paketa juaj mund të mbahet në Gemfury, për shembull.
Parimi 6. Drejtoni modelin tuaj si një ose më shumë procese
Për më tepër, proceset nuk duhet të kenë të dhëna të përbashkëta. Kjo do të thotë, proceset duhet të ekzistojnë veçmas, dhe të gjitha llojet e të dhënave duhet të ekzistojnë veçmas, për shembull, në shërbimet e palëve të treta si MySQL ose të tjera, në varësi të asaj që ju nevojitet.
Kjo do të thotë, definitivisht nuk ia vlen të ruani të dhënat brenda sistemit të skedarëve të procesit, përndryshe kjo mund të çojë në pastrimin e këtyre të dhënave gjatë lëshimit / ndryshimit të ardhshëm të konfigurimeve ose transferimit të sistemit në të cilin funksionon programi.
Por ekziston një përjashtim: për projektet e mësimit të makinerive, mund të ruani një memorie të bibliotekave në mënyrë që të mos i riinstaloni sa herë që lëshoni një version të ri, nëse nuk janë bërë biblioteka shtesë ose ndonjë ndryshim në versionet e tyre. Në këtë mënyrë, ju do të reduktoni kohën që duhet për të hedhur në treg modelin tuaj në industri.
Për të ekzekutuar modelin si disa procese, mund të krijoni një skedar .yml në të cilin specifikoni proceset e nevojshme dhe sekuencën e tyre.
Parimi 7: Riciklimi
Proceset që ekzekutohen në aplikacionin tuaj të modelit duhet të jenë të lehta për t'u nisur dhe për t'u ndalur. Kështu, kjo do t'ju lejojë të vendosni shpejt ndryshimet e kodit, ndryshimet e konfigurimit, të shkallëzoni shpejt dhe në mënyrë fleksibël dhe të parandaloni prishjet e mundshme të versionit të punës.
Kjo do të thotë, procesi juaj me modelin duhet:
- Minimizoni kohën e fillimit. Në mënyrë ideale, koha e fillimit (nga momenti kur është lëshuar komanda e nisjes deri në momentin kur procesi hyn në veprim) nuk duhet të jetë më shumë se disa sekonda. Memoria e bibliotekës, e përshkruar më sipër, është një teknikë për reduktimin e kohës së fillimit.
- Përfundoni saktë. Kjo do të thotë, dëgjimi në portin e shërbimit është pezulluar në të vërtetë dhe kërkesat e reja të paraqitura në këtë port nuk do të përpunohen. Këtu ose duhet të vendosni një komunikim të mirë me inxhinierët DevOps, ose të kuptoni se si funksionon vetë (mundësisht, sigurisht, kjo e fundit, por komunikimi duhet të ruhet gjithmonë, në çdo projekt!)
Parimi 8: Vendosja/Integrimi i vazhdueshëm
Shumë kompani përdorin një ndarje midis ekipeve të zhvillimit të aplikacionit dhe vendosjes (duke e bërë aplikacionin të disponueshëm për përdoruesit fundorë). Kjo mund të ngadalësojë shumë zhvillimin e softuerit dhe përparimin në përmirësimin e tij. Ai gjithashtu prish kulturën e DevOps, ku zhvillimi dhe integrimi, përafërsisht, kombinohen.
Prandaj, ky parim thotë se mjedisi juaj i zhvillimit duhet të jetë sa më afër mjedisit tuaj të prodhimit.
Kjo do të lejojë:
- Ulni kohën e lëshimit me dhjetëra herë
- Zvogëloni numrin e gabimeve për shkak të papajtueshmërisë së kodit.
- Kjo gjithashtu redukton ngarkesën e stafit, pasi zhvilluesit dhe njerëzit që vendosin aplikacionin tani janë një ekip.
Mjetet që ju lejojnë të punoni me këtë janë CircleCI, Travis CI, GitLab CI dhe të tjerë.
Modelin mund t'i bëni shpejt shtesa, ta përditësoni dhe ta lansoni menjëherë, ndërkohë që do të jetë e lehtë, në rast dështimesh, të ktheheni shumë shpejt në versionin e punës, në mënyrë që përdoruesi përfundimtar as të mos e vërejë. Kjo mund të bëhet veçanërisht lehtë dhe shpejt nëse keni teste të mira.
Minimizoni dallimet!!!
Parimi 9. Regjistrimet tuaja
Regjistrat (ose "Regjistrat") janë ngjarje, zakonisht të regjistruara në format teksti, që ndodhin brenda aplikacionit (transmetimi i ngjarjeve). Një shembull i thjeshtë: "2020-02-02 - niveli i sistemit - emri i procesit." Ato janë krijuar në mënyrë që zhvilluesi të mund të shohë fjalë për fjalë se çfarë po ndodh kur programi po funksionon. Ai sheh ecurinë e proceseve dhe kupton nëse është ashtu siç e ka menduar vetë zhvilluesi.
Ky parim thotë që ju nuk duhet t'i ruani regjistrat brenda sistemit tuaj të skedarëve - thjesht duhet t'i "i nxirrni" ato në ekran, për shembull, ta bëni këtë në daljen standarde të sistemit. Dhe në këtë mënyrë do të jetë e mundur të monitorohet rrjedha në terminal gjatë zhvillimit.
A do të thotë kjo se nuk ka nevojë të ruash fare regjistrat? Sigurisht që jo. Aplikacioni juaj thjesht nuk duhet ta bëjë këtë - ua lërë shërbimeve të palëve të treta. Aplikacioni juaj mund t'i përcjellë regjistrat vetëm në një skedar ose terminal specifik për t'i parë në kohë reale, ose t'i përcjellë në një sistem të ruajtjes së të dhënave për qëllime të përgjithshme (siç është Hadoop). Vetë aplikacioni juaj nuk duhet të ruajë ose të ndërveprojë me regjistrat.
Parimi 10. Test!
Për mësimin e makinerive industriale, kjo fazë është jashtëzakonisht e rëndësishme, pasi duhet të kuptoni se modeli funksionon siç duhet dhe prodhon atë që dëshironit.
Testet mund të krijohen duke përdorur pytest dhe të testohen duke përdorur një grup të dhënash të vogël nëse keni një detyrë regresioni/klasifikimi.
Mos harroni të vendosni të njëjtën farë për modelet e të mësuarit të thellë, në mënyrë që ato të mos prodhojnë vazhdimisht rezultate të ndryshme.
Ky ishte një përshkrim i shkurtër i 10 parimeve dhe, natyrisht, është e vështirë t'i përdorësh ato pa u përpjekur dhe pa parë se si funksionojnë, kështu që ky artikull është vetëm një prolog i një serie artikujsh interesantë në të cilët do të zbuloj se si të krijojmë Modelet industriale të mësimit të makinerive, si t'i integrojmë ato në sisteme dhe si këto parime mund ta bëjnë jetën më të lehtë për të gjithë ne.
Unë gjithashtu do të përpiqem të përdor parime të lezetshme që kushdo mund t'i lërë në komente nëse dëshiron.
Burimi: www.habr.com