Teollinen koneoppiminen: 10 suunnitteluperiaatetta
Nykyään syntyy päivittäin uusia palveluita, sovelluksia ja muita tärkeitä ohjelmia, joiden avulla on mahdollista luoda uskomattomia asioita: SpaceX-raketin ohjaamiseen tarkoitetuista ohjelmistoista viereisen huoneen vedenkeittimen kanssa vuorovaikutukseen älypuhelimen kautta.
Ja joskus jokainen aloitteleva ohjelmoija, olipa hän intohimoinen aloittelija tai tavallinen Full Stack tai Data Scientist, ennemmin tai myöhemmin tajuaa, että ohjelmointiin ja ohjelmistojen luomiseen on tiettyjä sääntöjä, jotka yksinkertaistavat elämää suuresti.
Tässä artikkelissa kuvailen lyhyesti 10 periaatetta teollisen koneoppimisen ohjelmoimiseksi niin, että se voidaan helposti integroida sovellukseen/palveluun 12-faktorisen sovellusmetodologian pohjalta. . Aloitteeni on lisätä tietoisuutta tästä tekniikasta, joka voi auttaa monia kehittäjiä ja datatieteen ihmisiä.
Tämä artikkeli on esisana teollista koneoppimista käsittelevälle artikkelisarjalle. Niissä kerron edelleen mallin tekemisestä ja tuomisesta tuotantoon, APIn luomisesta sille sekä esimerkkejä eri alueilta ja yrityksiltä, joiden järjestelmiin on sisäänrakennettu ML.
Periaate 1: Yksi koodikanta
Jotkut ohjelmoijat ensimmäisissä vaiheissa, laiskuudesta selvittää se (tai jostain syystä omasta syystä), unohtavat Gitin. He joko unohtavat sanan kokonaan, eli he heittelevät tiedostoja toisilleen asemaan / heittävät vain tekstiä / lähettävät kyyhkysten kautta tai he eivät ajattele työnkulkuaan läpi ja sitoutuvat kukin omaan haaraansa ja sitten hallita.
Tämä periaate sanoo: on yksi koodikanta ja useita käyttöönottoja.
Gitiä voidaan käyttää sekä tuotannossa että tutkimus- ja kehitystoiminnassa (T&K), jossa sitä ei käytetä niin usein.
Esimerkiksi T&K-vaiheessa voit jättää sitoumuksia erilaisilla tietojenkäsittelymenetelmillä ja -malleilla, jotta voit valita niistä parhaan ja jatkaa sen kanssa helposti työskentelyä.
Toiseksi tuotannossa tämä on korvaamaton asia - sinun on jatkuvasti katsottava kuinka koodisi muuttuu ja tiedettävä, mikä malli tuotti parhaat tulokset, mikä koodi toimi lopulta ja mitä tapahtui, joka sai sen lakkautumaan toimimasta tai alkanut tuottaa vääriä tuloksia . Sitä varten sitoumukset ovat!
Voit myös luoda projektistasi paketin sijoittamalla sen esimerkiksi Gemfuryyn ja tuomalla siitä sitten funktioita muihin projekteihin, jotta et kirjoita niitä 1000 kertaa uudelleen, mutta siitä lisää myöhemmin.
Periaate 2: Ilmoita ja eristä riippuvuudet selvästi
Jokaisella projektilla on erilaisia kirjastoja, jotka tuot ulkopuolelta soveltaaksesi niitä johonkin. Olipa kyseessä Python-kirjastot tai muiden kielten kirjastot eri tarkoituksiin tai järjestelmätyökalut - sinun tehtäväsi on:
- Ilmoita selkeästi riippuvuudet, toisin sanoen tiedosto, joka sisältää kaikki projektissasi käytetyt kirjastot, työkalut ja niiden versiot, jotka on asennettava (esim. Pythonissa tämä voidaan tehdä käyttämällä Pipfile- tai prasības.txt-tiedostoa. A linkki, joka antaa hyvän ymmärtää: )
- Eristä riippuvuudet erityisesti ohjelmallesi kehityksen aikana. Etkö halua jatkuvasti vaihtaa versioita ja asentaa uudelleen esimerkiksi Tensorflowa?
Näin tiimiisi tulevaisuudessa liittyvät kehittäjät pääsevät nopeasti tutustumaan projektissasi käytettyihin kirjastoihin ja niiden versioihin, ja sinulla on myös mahdollisuus hallita itse tiettyä tiettyä kohdetta varten asennettuja versioita ja kirjastoja. projekti, joka auttaa sinua välttämään kirjastojen tai niiden versioiden yhteensopimattomuuden.
Sovelluksesi ei myöskään saa luottaa järjestelmätyökaluihin, jotka voidaan asentaa tiettyyn käyttöjärjestelmään. Nämä työkalut on myös ilmoitettava riippuvuuksien luettelossa. Tämä on tarpeen, jotta vältetään tilanteet, joissa työkalujen versio (sekä niiden saatavuus) ei vastaa tietyn käyttöjärjestelmän järjestelmätyökaluja.
Vaikka curlia voidaankin käyttää lähes kaikissa tietokoneissa, se kannattaa silti ilmoittaa riippuvuuksina, koska siirryttäessä toiseen alustaan se ei välttämättä ole siellä tai versio ei ole se, jota alun perin tarvitsit.
Vaatimukset.txt-tiedostosi voi esimerkiksi näyttää tältä:
# 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
Periaate 3: Kokoonpanot
Monet ovat kuulleet tarinoita eri kehittäjistä, jotka ovat vahingossa lataaneet koodia GitHubiin julkisiin arkistoihin salasanoilla ja muilla AWS:n avaimilla ja heränneet seuraavana päivänä 6000 50000 dollarin tai jopa XNUMX XNUMX dollarin velkaan.
Tietenkin nämä tapaukset ovat äärimmäisiä, mutta erittäin merkittäviä. Jos tallennat tunnistetietosi tai muut määritykseen tarvittavat tiedot koodin sisään, teet virheen, eikä mielestäni ole tarvetta selittää miksi.
Vaihtoehto tälle on konfiguraatioiden tallentaminen ympäristömuuttujiin. Voit lukea lisää ympäristömuuttujista .
Esimerkkejä tiedoista, jotka tavallisesti tallennetaan ympäristömuuttujiin:
- Domain-nimet
- API URL-osoitteet/URI:t
- Julkiset ja yksityiset avaimet
- Yhteystiedot (posti, puhelimet jne.)
Näin sinun ei tarvitse jatkuvasti muuttaa koodia, jos määritysmuuttujasi muuttuvat. Tämä auttaa säästämään aikaa, vaivaa ja rahaa.
Jos esimerkiksi käytät Kaggle-sovellusliittymää testien suorittamiseen (esimerkiksi lataa ohjelmisto ja suorita malli sen läpi testataksesi ajon aikana, että malli toimii hyvin), Kagglen yksityisten avainten, kuten KAGGLE_USERNAME ja KAGGLE_KEY, tulee olla tallennettu ympäristömuuttujiin.
Periaate 4: Kolmannen osapuolen palvelut
Ajatuksena tässä on luoda ohjelma siten, että paikallisten ja kolmannen osapuolen resurssien välillä ei ole eroa koodin suhteen. Voit esimerkiksi yhdistää sekä paikallisen MySQL:n että kolmannen osapuolen. Sama koskee erilaisia sovellusliittymiä, kuten Google Maps tai Twitter API.
Kolmannen osapuolen palvelun poistamiseksi käytöstä tai toisen yhdistämiseksi sinun on vain muutettava ympäristömuuttujien kokoonpanon avaimet, joista puhuin yllä olevassa kappaleessa.
Joten esimerkiksi sen sijaan, että määrität polun tiedostoihin, joissa on tietojoukkoja koodin sisällä joka kerta, on parempi käyttää pathlib-kirjastoa ja ilmoittaa tietojoukkojen polku tiedostossa config.py, jotta riippumatta siitä, mitä palvelua käytät (esim. esimerkiksi CircleCI), ohjelma pystyi selvittämään polun tietojoukkoon ottaen huomioon uuden palvelun uuden tiedostojärjestelmän rakenteen.
Periaate 5. Rakennus, julkaisu, suoritusaika
Monet datatieteen ammattilaiset pitävät hyödyllisenä parantaa ohjelmistojen kirjoitustaitojaan. Jos haluamme ohjelmamme kaatuvan mahdollisimman harvoin ja toimivan ilman vikoja mahdollisimman pitkään, meidän on jaettava uuden version julkaisuprosessi kolmeen vaiheeseen:
- vaihe kokoonpanot. Muunnat pelkän koodisi yksittäisillä resursseilla ns. paketiksi, joka sisältää kaikki tarvittavat koodit ja tiedot. Tätä pakettia kutsutaan kokoonpanoksi.
- vaihe julkaisu — Tässä yhdistämme kokoonpanomme kokoonpanoon, jota ilman emme pystyisi julkaisemaan ohjelmaamme. Nyt tämä on täysin valmis julkaisuun.
- Seuraavaksi tulee lava täyttymys. Tässä vapautamme sovelluksen suorittamalla tarvittavat prosessit julkaisustamme.
Tällainen mallin tai koko liukusarjan uusien versioiden julkaisemiseen tarkoitettu järjestelmä mahdollistaa järjestelmänvalvojien ja kehittäjien roolien erottamisen, versioiden seuraamisen ja ohjelman ei-toivottujen pysäytysten estämisen.
Julkaisutehtävää varten on luotu monia erilaisia palveluita, joissa voit kirjoittaa itse ajavia prosesseja .yml-tiedostoon (esimerkiksi CircleCI:ssä tämä on config.yml, joka tukee itse prosessia). Wheely on loistava luomaan paketteja projekteihin.
Voit luoda paketteja koneoppimismallistasi eri versioilla ja sitten pakata ne ja katsoa tarvittavat paketit ja niiden versiot käyttääksesi sieltä kirjoittamiasi toimintoja. Tämä auttaa sinua luomaan mallillesi API:n, ja pakettia voidaan isännöidä esimerkiksi Gemfuryssa.
Periaate 6. Suorita mallisi yhtenä tai useampana prosessina
Lisäksi prosesseilla ei pitäisi olla yhteisiä tietoja. Toisin sanoen prosessien on oltava erillään ja kaikenlaisten tietojen on oltava erikseen, esimerkiksi kolmannen osapuolen palveluissa, kuten MySQL tai muissa, riippuen siitä, mitä tarvitset.
Toisin sanoen ei todellakaan kannata tallentaa tietoja prosessitiedostojärjestelmän sisällä, muuten tämä voi johtaa näiden tietojen tyhjentämiseen seuraavan julkaisun/konfiguraatiomuutoksen tai ohjelman ajettavan järjestelmän siirron yhteydessä.
Mutta on poikkeus: koneoppimisprojekteissa voit tallentaa kirjastojen välimuistin, jotta et asentaisi niitä uudelleen joka kerta, kun käynnistät uuden version, jos lisäkirjastoja tai niiden versioihin ei ole tehty muutoksia. Tällä tavalla lyhennät mallisi lanseeraukseen kuluvaa aikaa.
Jos haluat suorittaa mallin useana prosessina, voit luoda .yml-tiedoston, jossa määrität tarvittavat prosessit ja niiden järjestyksen.
Periaate 7: Kierrätettävyys
Mallisovelluksessasi suoritettavien prosessien tulee olla helppo käynnistää ja lopettaa. Siten tämä mahdollistaa koodimuutosten, konfiguraatiomuutosten nopean käyttöönoton, nopean ja joustavan mittakaavan ja estää mahdolliset toimintaversion rikkoutumisen.
Eli mallin kanssa käyttämäsi prosessin tulisi:
- Minimoi käynnistysaika. Ihannetapauksessa käynnistysaika (käynnistyskomennon antohetkestä prosessin alkamiseen) ei saisi olla pidempi kuin muutama sekunti. Yllä kuvattu kirjaston välimuisti on yksi tekniikka käynnistysajan lyhentämiseksi.
- Lopeta oikein. Toisin sanoen palveluportin kuuntelu keskeytetään, eikä tähän porttiin lähetettyjä uusia pyyntöjä käsitellä. Täällä sinun on joko luotava hyvä kommunikointi DevOps-insinöörien kanssa tai ymmärrettävä itse, miten se toimii (mieluiten tietysti jälkimmäinen, mutta viestintää tulee aina ylläpitää kaikissa projekteissa!)
Periaate 8: Jatkuva käyttöönotto/integrointi
Monet yritykset erottelevat sovelluskehitys- ja käyttöönottotiimit (joka tuo sovelluksen loppukäyttäjien saataville). Tämä voi suuresti hidastaa ohjelmistokehitystä ja edistymistä sen parantamisessa. Se pilaa myös DevOps-kulttuurin, jossa kehitys ja integraatio yhdistyvät karkeasti sanottuna.
Siksi tämä periaate edellyttää, että kehitysympäristösi tulee olla mahdollisimman lähellä tuotantoympäristöäsi.
Tämä mahdollistaa:
- Lyhennä julkaisuaikaa kymmeniä kertoja
- Vähennä koodin yhteensopimattomuudesta johtuvien virheiden määrää.
- Tämä vähentää myös henkilöstön työtaakkaa, koska kehittäjät ja sovelluksen käyttöön ottavat ihmiset ovat nyt yksi tiimi.
Työkaluja, joiden avulla voit työskennellä tämän kanssa, ovat CircleCI, Travis CI, GitLab CI ja muut.
Voit nopeasti tehdä lisäyksiä malliin, päivittää ja käynnistää sen välittömästi, kun taas on helppo, vikojen sattuessa, palata hyvin nopeasti toimivaan versioon, jotta loppukäyttäjä ei edes huomaa sitä. Tämä voidaan tehdä erityisen helposti ja nopeasti, jos sinulla on hyvät testit.
Minimoi erot!!!
Periaate 9. Omat lokit
Lokit (tai "lokit") ovat tapahtumia, jotka on yleensä tallennettu tekstimuodossa ja jotka tapahtuvat sovelluksessa (tapahtumavirta). Yksinkertainen esimerkki: "2020-02-02 - järjestelmätaso - prosessin nimi." Ne on suunniteltu niin, että kehittäjä voi kirjaimellisesti nähdä, mitä tapahtuu, kun ohjelma on käynnissä. Hän näkee prosessien edistymisen ja ymmärtää, onko se niin kuin kehittäjä itse on tarkoittanut.
Tämä periaate sanoo, että sinun ei pidä tallentaa lokeja tiedostojärjestelmääsi - sinun tulee vain "tulostaa" ne näytölle, esimerkiksi tehdä tämä järjestelmän vakiotulosteessa. Ja tällä tavalla on mahdollista seurata virtausta terminaalissa kehityksen aikana.
Tarkoittaako tämä sitä, että lokeja ei tarvitse tallentaa ollenkaan? Ei tietenkään. Sovelluksesi ei vain pitäisi tehdä tätä – jätä se kolmannen osapuolen palveluihin. Sovelluksesi voi lähettää lokit vain tiettyyn tiedostoon tai päätteeseen reaaliaikaista tarkastelua varten tai lähettää ne yleiskäyttöiseen tiedontallennusjärjestelmään (kuten Hadoop). Itse sovelluksesi ei saa tallentaa lokeja tai olla vuorovaikutuksessa niiden kanssa.
Periaate 10. Testaa!
Teollisen koneoppimisen kannalta tämä vaihe on erittäin tärkeä, sillä sinun on ymmärrettävä, että malli toimii oikein ja tuottaa mitä halusit.
Testejä voidaan luoda pytestillä ja testata pienellä tietojoukolla, jos sinulla on regressio-/luokitustehtävä.
Älä unohda asettaa samaa siementä syväoppimismalleille, jotta ne eivät tuota jatkuvasti erilaisia tuloksia.
Tämä oli lyhyt kuvaus 10 periaatteesta, ja tietysti on vaikeaa käyttää niitä kokeilematta ja näkemättä, miten ne toimivat, joten tämä artikkeli on vain alkuosa mielenkiintoisten artikkelien sarjalle, jossa paljastan kuinka luoda teolliset koneoppimismallit , kuinka ne integroidaan järjestelmiin ja miten nämä periaatteet voivat helpottaa meidän kaikkien elämää.
Yritän myös käyttää hienoja periaatteita, joita kuka tahansa voi halutessaan jättää kommentteihin.
Lähde: will.com