Industrijsko strojno učenje: 10 načel oblikovanja
Dandanes vsak dan nastajajo nove storitve, aplikacije in drugi pomembni programi, ki omogočajo ustvarjanje neverjetnih stvari: od programske opreme za upravljanje rakete SpaceX do interakcije s kotličkom v sosednji sobi prek pametnega telefona.
In včasih vsak programer začetnik, ne glede na to, ali je strasten startupper ali navaden Full Stack ali Data Scientist, prej ali slej pride do spoznanja, da obstajajo določena pravila za programiranje in ustvarjanje programske opreme, ki močno poenostavijo življenje.
V tem članku bom na kratko opisal 10 principov, kako programirati industrijsko strojno učenje, tako da ga je mogoče preprosto integrirati v aplikacijo/storitev, ki temelji na metodologiji 12-factor App. . Moja pobuda je povečati ozaveščenost o tej tehniki, ki lahko pomaga številnim razvijalcem in ljudem v znanosti o podatkih.
Ta članek je prolog k seriji člankov o industrijskem strojnem učenju. V njih bom nadalje govoril o tem, kako dejansko narediti model in ga lansirati v proizvodnjo, ustvariti API zanj, pa tudi o primerih iz različnih področij in podjetij, ki imajo vgrajen ML v svojih sistemih.
Načelo 1: ena kodna osnova
Nekateri programerji na prvih stopnjah zaradi lenobe, da bi to ugotovili (ali iz nekega lastnega razloga), pozabijo na Git. Ali popolnoma pozabijo na besedo, to pomeni, da drug drugemu mečejo datoteke v pogon/samo vržejo besedilo/pošiljajo po golobih, ali pa ne premislijo o svojem delovnem procesu in se zavežejo vsak v svojo vejo, nato pa v gospodar.
To načelo pravi: imajo eno kodno osnovo in veliko razmestitev.
Git se lahko uporablja tako v produkciji kot v raziskavah in razvoju (R&R), kjer se ne uporablja tako pogosto.
Na primer, v fazi raziskav in razvoja lahko pustite zaveze z različnimi metodami in modeli obdelave podatkov, da nato izberete najboljšega in enostavno nadaljujete delo z njim.
Drugič, v proizvodnji je to nenadomestljiva stvar - nenehno boste morali gledati, kako se vaša koda spreminja in vedeti, kateri model je dal najboljše rezultate, katera koda je na koncu delovala in kaj se je zgodilo, da je prenehala delovati ali začela proizvajati napačne rezultate . Temu so zaveze!
Prav tako lahko ustvarite paket svojega projekta, ga postavite na primer na Gemfury in nato preprosto uvozite funkcije iz njega za druge projekte, da jih ne prepisujete 1000-krat, vendar o tem kasneje.
Načelo 2: Jasno deklarirajte in izolirajte odvisnosti
Vsak projekt ima različne knjižnice, ki jih uvozite od zunaj, da jih nekje uporabite. Ne glede na to, ali gre za knjižnice Python ali knjižnice drugih jezikov za različne namene ali sistemska orodja - vaša naloga je:
- Jasno navedite odvisnosti, to je datoteko, ki bo vsebovala vse knjižnice, orodja in njihove različice, ki se uporabljajo v vašem projektu in ki jih je treba namestiti (na primer, v Pythonu je to mogoče storiti z uporabo Pipfile ali requirements.txt. A povezava, ki omogoča dobro razumevanje: )
- Med razvojem izolirajte odvisnosti posebej za vaš program. Ne želite nenehno spreminjati različic in znova namestiti na primer Tensorflow?
Tako se bodo lahko razvijalci, ki se bodo pridružili vaši ekipi v prihodnosti, hitro seznanili s knjižnicami in njihovimi različicami, ki se uporabljajo v vašem projektu, prav tako pa boste imeli možnost upravljati same različice in knjižnice, nameščene za določeno projekt, ki vam bo pomagal preprečiti nekompatibilnost knjižnic ali njihovih različic.
Vaša aplikacija se prav tako ne sme zanašati na sistemska orodja, ki so lahko nameščena v določenem OS. Ta orodja morajo biti deklarirana tudi v manifestu odvisnosti. To je potrebno, da se izognete situacijam, ko se različica orodij (kot tudi njihova razpoložljivost) ne ujema s sistemskimi orodji določenega OS.
Torej, tudi če je mogoče curl uporabljati na skoraj vseh računalnikih, ga morate še vedno prijaviti v odvisnostih, saj ga pri selitvi na drugo platformo morda ne bo tam ali različica ne bo tista, ki ste jo prvotno potrebovali.
Na primer, vaš requirements.txt je lahko videti takole:
# 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
Načelo 3: Konfiguracije
Mnogi so slišali zgodbe o različnih razvijalcih, ki so pomotoma naložili kodo na GitHub v javne repozitorije z gesli in drugimi ključi iz AWS in se naslednji dan zbudili z dolgom v višini 6000 $ ali celo 50000 $.
Seveda so ti primeri ekstremni, a zelo pomembni. Če svoje poverilnice ali druge podatke, potrebne za konfiguracijo, shranite znotraj kode, delate napako in mislim, da ni treba pojasnjevati, zakaj.
Alternativa temu je shranjevanje konfiguracij v spremenljivke okolja. Več o spremenljivkah okolja lahko preberete .
Primeri podatkov, ki so običajno shranjeni v spremenljivkah okolja:
- Imena domen
- API URL-ji/URI-ji
- Javni in zasebni ključi
- Kontakti (pošta, telefoni itd.)
Tako vam ni treba nenehno spreminjati kode, če se spremenijo vaše konfiguracijske spremenljivke. To vam bo pomagalo prihraniti čas, trud in denar.
Na primer, če uporabljate Kaggle API za izvajanje testov (na primer, prenesete programsko opremo in zaženete model prek nje, da med izvajanjem preizkusite, ali model dobro deluje), potem bi morali biti zasebni ključi Kaggle, kot sta KAGGLE_USERNAME in KAGGLE_KEY shranjene v spremenljivkah okolja.
Načelo 4: Storitve tretjih oseb
Ideja tukaj je ustvariti program na tak način, da ni razlike med lokalnimi viri in viri tretjih oseb v smislu kode. Na primer, lahko povežete lokalne MySQL in druge proizvajalce. Enako velja za različne API-je, kot sta Google Maps ali Twitter API.
Če želite onemogočiti storitev tretje osebe ali povezati drugo, morate samo spremeniti ključe v konfiguraciji v spremenljivkah okolja, o katerih sem govoril v zgornjem odstavku.
Torej, na primer, namesto da vsakič določite pot do datotek z nabori podatkov znotraj kode, je bolje uporabiti knjižnico pathlib in deklarirati pot do naborov podatkov v config.py, tako da ne glede na to, katero storitev uporabljate (za na primer CircleCI), je program lahko ugotovil pot do naborov podatkov ob upoštevanju strukture novega datotečnega sistema v novi storitvi.
Načelo 5. Gradnja, izdaja, čas izvajanja
Veliko ljudi v Data Science meni, da je koristno izboljšati svoje veščine pisanja programske opreme. Če želimo, da se naš program sesuje čim redkeje in da čim dlje deluje brez napak, moramo proces izdaje nove različice razdeliti na 3 stopnje:
- Faza sklopov. Svojo golo kodo s posameznimi viri pretvorite v tako imenovani paket, ki vsebuje vso potrebno kodo in podatke. Ta paket se imenuje sklop.
- Faza sprostitev — tukaj povežemo našo konfiguracijo s sklopom, brez katerega ne bi mogli izdati našega programa. Zdaj je to izdaja, ki je popolnoma pripravljena za zagon.
- Sledi oder izpolnitev. Tukaj izdamo aplikacijo z izvajanjem potrebnih procesov iz naše izdaje.
Takšen sistem izdajanja novih verzij modela ali celotnega cevovoda omogoča ločevanje vlog med skrbniki in razvijalci, omogoča sledenje različicam in preprečuje neželene zaustavitve programa.
Za nalogo sprostitve je bilo ustvarjenih veliko različnih storitev, v katere lahko napišete procese, ki jih sami izvajate, v datoteko .yml (na primer, v CircleCI je to config.yml za podporo samemu procesu). Whee je odličen pri ustvarjanju paketov za projekte.
Ustvarite lahko pakete z različnimi različicami vašega modela strojnega učenja, nato pa jih zapakirate in se obrnete na potrebne pakete in njihove različice za uporabo funkcij, ki ste jih napisali od tam. To vam bo pomagalo ustvariti API za vaš model, vaš paket pa lahko gosti na primer Gemfury.
Načelo 6. Zaženite svoj model kot enega ali več procesov
Poleg tega procesi ne bi smeli imeti deljenih podatkov. To pomeni, da morajo procesi obstajati ločeno in vse vrste podatkov morajo obstajati ločeno, na primer v storitvah tretjih oseb, kot je MySQL ali drugih, odvisno od tega, kaj potrebujete.
To pomeni, da se zagotovo ne splača shranjevati podatkov znotraj datotečnega sistema procesa, sicer lahko to privede do izbrisa teh podatkov med naslednjo izdajo/spremembo konfiguracij ali prenosom sistema, v katerem se program izvaja.
Vendar obstaja izjema: za projekte strojnega učenja lahko shranite predpomnilnik knjižnic, da jih ne boste znova namestili vsakič, ko zaženete novo različico, če v njihovih različicah niso bile narejene dodatne knjižnice ali kakršne koli spremembe. Na ta način boste skrajšali čas, potreben za lansiranje vašega modela v industriji.
Če želite zagnati model kot več procesov, lahko ustvarite datoteko .yml, v kateri podate potrebne procese in njihovo zaporedje.
Načelo 7: možnost recikliranja
Procese, ki se izvajajo v vaši modelni aplikaciji, mora biti enostavno zagnati in zaustaviti. Tako vam bo to omogočilo hitro uvajanje sprememb kode, sprememb konfiguracije, hitro in prilagodljivo skaliranje ter preprečilo morebitne okvare delujoče različice.
To pomeni, da bi moral vaš postopek z modelom:
- Zmanjšajte čas zagona. V idealnem primeru čas zagona (od trenutka, ko je bil izdan ukaz za zagon, do trenutka, ko proces začne delovati), ne sme biti daljši od nekaj sekund. Zgoraj opisano predpomnjenje knjižnice je ena od tehnik za skrajšanje časa zagona.
- Končaj pravilno. To pomeni, da je poslušanje na servisnih vratih dejansko začasno ustavljeno in nove zahteve, poslane v ta vrata, ne bodo obdelane. Tukaj morate vzpostaviti dobro komunikacijo z inženirji DevOps ali sami razumeti, kako deluje (po možnosti slednje, vendar je treba komunikacijo vedno vzdrževati, v katerem koli projektu!)
Načelo 8: Nenehno uvajanje/integracija
Številna podjetja uporabljajo ločitev med skupinami za razvoj aplikacije in skupino za uvajanje (tako da je aplikacija na voljo končnim uporabnikom). To lahko močno upočasni razvoj programske opreme in napredek pri njeni izboljšavi. Kvari tudi kulturo DevOps, kjer sta razvoj in integracija, grobo rečeno, združena.
Zato to načelo navaja, da mora biti vaše razvojno okolje čim bližje vašemu proizvodnemu okolju.
To bo omogočilo:
- Skrajšajte čas sproščanja za desetkrat
- Zmanjšajte število napak zaradi nezdružljivosti kode.
- To tudi zmanjša delovno obremenitev osebja, saj so razvijalci in ljudje, ki uvajajo aplikacijo, zdaj ena ekipa.
Orodja, ki vam omogočajo delo s tem, so CircleCI, Travis CI, GitLab CI in drugi.
Model lahko hitro dopolnjujete, posodabljate in takoj zaženete, hkrati pa se boste v primeru okvar enostavno zelo hitro vrnili na delujočo verzijo, tako da končni uporabnik tega sploh ne opazi. To lahko storite še posebej enostavno in hitro, če imate dobre teste.
Zmanjšaj razlike!!!
Načelo 9. Vaši dnevniki
Dnevniki (ali »dnevniki«) so dogodki, običajno zabeleženi v besedilni obliki, ki se zgodijo v aplikaciji (tok dogodkov). Preprost primer: "2020-02-02 - sistemska raven - ime procesa." Zasnovani so tako, da lahko razvijalec dobesedno vidi, kaj se dogaja, ko se program izvaja. Vidi potek procesov in razume, ali je tako, kot si je zamislil razvijalec.
To načelo navaja, da svojih dnevnikov ne smete shranjevati znotraj svojega datotečnega sistema - preprosto jih morate "izpisati" na zaslon, na primer, to storite na standardnem izhodu sistema. In na ta način bo možno spremljati pretok v terminalu med razvojem.
Ali to pomeni, da dnevnikov sploh ni treba shranjevati? Seveda ne. Vaša aplikacija tega preprosto ne bi smela narediti – prepustite jo storitvam tretjih oseb. Vaša aplikacija lahko samo posreduje dnevnike določeni datoteki ali terminalu za ogled v realnem času ali jih posreduje splošnemu sistemu za shranjevanje podatkov (kot je Hadoop). Vaša aplikacija sama ne bi smela shranjevati ali komunicirati z dnevniki.
Načelo 10. Test!
Za industrijsko strojno učenje je ta faza izjemno pomembna, saj morate razumeti, da model deluje pravilno in proizvaja tisto, kar ste želeli.
Preizkuse je mogoče ustvariti s pytestom in jih preizkusiti z majhnim naborom podatkov, če imate nalogo regresije/razvrščanja.
Ne pozabite nastaviti istega semena za modele globokega učenja, da ne ustvarjajo nenehno različnih rezultatov.
To je bil kratek opis 10 principov, ki jih je seveda težko uporabiti, ne da bi poskusili in videli, kako delujejo, zato je ta članek le prolog v niz zanimivih člankov, v katerih vam bom razkril, kako ustvariti modeli industrijskega strojnega učenja, kako jih integrirati v sisteme in kako lahko ta načela olajšajo življenje vsem nam.
Poskušal bom uporabiti tudi kul principe, ki jih lahko vsakdo pusti v komentarjih, če želi.
Vir: www.habr.com