Industrial Machine Learning: 10 diseinu printzipio
Gaur egun, zerbitzu, aplikazio eta bestelako programa garrantzitsu berriak sortzen dira egunero, gauza sinestezinak sortzea posible egiten dutenak: SpaceX kohete bat kontrolatzeko softwaretik, ondoko gelan dagoen kaldagailu batekin telefono bidez elkarreragintzeraino.
Eta, batzuetan, programatzaile hasiberri oro, startupper sutsua edo Full Stack edo Data Scientist arrunta izan, lehenago edo beranduago konturatzen da bizitza asko errazten duten softwarea programatzeko eta sortzeko arau batzuk daudela.
Artikulu honetan, makina-ikaskuntza industriala programatzeko 10 printzipio labur deskribatuko ditut aplikazio/zerbitzu batean erraz integratzeko, 12 faktoreko App metodologian oinarrituta. . Nire ekimena teknika honen kontzientzia areagotzea da, garatzaile eta datu-zientzietako pertsona askori lagundu diezaiokeena.
Artikulu hau Machine Learning industrialari buruzko artikulu batzuen hitzaurrea da. Horietan, eredu bat benetan egin eta produkziora abiarazteko moduari buruz gehiago hitz egingo dut, horretarako API bat sortu, baita beren sistemetan ML barneratua duten hainbat arlo eta enpresatako adibideak ere.
1. printzipioa: Kode-oinarri bakarra
Programatzaile batzuk lehen faseetan, hori asmatzeko alferkeriagatik (edo arrazoiren batengatik), Git-az ahaztu egiten dira. Edo hitza erabat ahazten dute, hau da, fitxategiak elkarri botatzen dizkiote diskoan/testua botatzen dute/usoek bidaltzen dute, edo ez dute beren lan-fluxuan pentsatzen, eta bakoitza bere adarretara konprometitzen da, eta gero. maisu.
Printzipio honek dio: kode-base bat eta inplementazio asko dituzte.
Git ekoizpenean zein ikerketa eta garapenean (I+G) erabil daiteke, eta horietan ez da hain maiz erabiltzen.
Esaterako, I+G fasean datuak prozesatzeko metodo eta eredu ezberdinekin konpromezuak utzi ditzakezu, ondoren onena aukeratzeko eta erraz lanean jarraitzeko.
Bigarrenik, ekoizpenean hori ordezkaezina da: etengabe begiratu beharko duzu zure kodea nola aldatzen den eta jakin beharko duzu zein modelok eman dituen emaitza onenak, zein kodek funtzionatu duen azkenean eta zer gertatu den funtzionatzeari utzi dion edo emaitza okerrak sortzen hasteko. . Horretarako dira konpromisoak!
Zure proiektuaren pakete bat ere sor dezakezu, adibidez, Gemfury-n jarriz, eta, ondoren, bertatik beste proiektu batzuetarako funtzioak inportatu besterik ez dago, 1000 aldiz berridatzi ez daitezen, gero gehiago gehiago.
2. printzipioa: menpekotasunak argi eta garbi adierazi eta isolatu
Proiektu bakoitzak liburutegi desberdinak ditu, kanpotik inportatzen dituzunak nonbait aplikatzeko. Python liburutegiak, edo beste hizkuntzetako liburutegiak helburu ezberdinetarako, edo sistema tresnak diren ala ez - zure zeregina hau da:
- Argi eta garbi adierazi menpekotasunak, hau da, zure proiektuan erabiltzen diren eta instalatu behar diren liburutegi, tresna eta haien bertsio guztiak edukiko dituen fitxategi bat (adibidez, Python-en Pipfile edo requirements.txt erabiliz egin daiteke hori. A ondo ulertzeko aukera ematen duen esteka: )
- Isolatu zure programaren menpekotasunak garapenean zehar. Ez duzu nahi etengabe bertsioak aldatu eta berriro instalatu, adibidez, Tensorflow?
Horrela, etorkizunean zure taldean sartuko diren garatzaileek azkar ezagutu ahal izango dituzte zure proiektuan erabiltzen diren liburutegiak eta haien bertsioak, eta, gainera, aukera izango duzu beraiek instalatutako bertsioak eta liburutegiak kudeatzeko. proiektua, eta horrek liburutegien edo haien bertsioen bateraezintasuna saihesten lagunduko dizu.
Zure aplikazioak ere ez luke sistema eragile zehatz batean instalatuta egon daitezkeen sistema-tresnetan oinarritu behar. Tresna hauek menpekotasunen manifestuan ere deklaratu behar dira. Hau beharrezkoa da tresnen bertsioa (baita haien erabilgarritasuna) sistema eragile jakin baten sistemako tresnekin bat ez datozen egoerak saihesteko.
Horrela, curl ia ordenagailu guztietan erabil daitekeen arren, menpekotasunetan deklaratu beharko zenuke, beste plataforma batera migratzean agian ez egotea edo bertsioa ez baita hasieran behar zenuena izango.
Esate baterako, zure requirements.txt-a honelakoa izan daiteke:
# 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. printzipioa: Konfigurazioak
Askok hainbat garatzaileren istorioak entzun dituzte ustekabean GitHub-era kodea kargatzen duten AWSko pasahitzak eta beste gako batzuk dituzten biltegi publikoetara, hurrengo egunean 6000 $ edo 50000 $-ko zorrarekin esnatuz.
Noski, kasu hauek muturrekoak dira, baina oso esanguratsuak. Zure kredentzialak edo konfiguratzeko beharrezkoak diren bestelako datuak kodearen barruan gordetzen badituzu, akats bat egiten ari zara, eta uste dut ez dagoela zergatik azaldu beharrik.
Horren alternatiba konfigurazioak ingurune-aldagaietan gordetzea da. Ingurune-aldagaiei buruzko informazio gehiago irakur dezakezu .
Normalean ingurune-aldagaietan gordetzen diren datuen adibideak:
- Domeinu-izenak
- API URLak/URIak
- Gako publikoak eta pribatuak
- Kontaktuak (posta, telefonoak, etab.)
Horrela, ez duzu kodea etengabe aldatu behar zure konfigurazio-aldagaiak aldatzen badira. Horrek denbora, ahalegina eta dirua aurrezten lagunduko dizu.
Adibidez, Kaggle APIa probak egiteko erabiltzen baduzu (adibidez, softwarea deskargatu eta eredua bertatik exekutatu ereduak ondo funtzionatzen duenean probatzeko), orduan Kaggle-ren gako pribatuak, hala nola KAGGLE_USERNAME eta KAGGLE_KEY, izan beharko lirateke. ingurune-aldagaietan gordeta.
4. printzipioa: Hirugarrenen Zerbitzuak
Hemen ideia da programa sortzea tokiko baliabideen eta hirugarrenen arteko desberdintasunik ez dagoen moduan kodeari dagokionez. Adibidez, tokiko MySQL eta hirugarrenen konekta ditzakezu. Gauza bera gertatzen da Google Maps edo Twitter API bezalako hainbat APIrekin.
Hirugarrenen zerbitzu bat desgaitzeko edo beste bat konektatzeko, ingurune-aldagaietako konfigurazioko gakoak aldatu besterik ez duzu behar, goiko paragrafoan aipatu dudana.
Beraz, adibidez, aldi bakoitzean kodearen barruan datu multzoak dituzten fitxategien bidea zehaztu beharrean, hobe da pathlib liburutegia erabiltzea eta datu multzoen bidea deklaratzea config.py-n, zer zerbitzu erabiltzen duzun edozein dela ere. adibidez, CircleCI), programak datu-multzoetarako bidea ezagutu ahal izan zuen zerbitzu berriko fitxategi-sistema berriaren egitura kontuan hartuta.
5. printzipioa. Eraiki, askatu, exekutatzeko denbora
Data Science-ko pertsona askori erabilgarria iruditzen zaie softwarea idazteko trebetasunak hobetzea. Gure programa ahalik eta gutxien hutsegitea eta hutsegiterik gabe ahalik eta denbora gehien funtzionatzea nahi badugu, bertsio berri bat kaleratzeko prozesua 3 fasetan banatu behar dugu:
- Etapa batzarrak. Baliabide indibidualekin zure kode hutsa eraldatzen duzu beharrezko kode eta datu guztiak dituen pakete deritzon batean. Pakete honi muntaia deitzen zaio.
- Etapa oharra β Hemen gure konfigurazioa asanbladara konektatzen dugu, hori gabe ezingo genuke gure programa kaleratu. Orain hau guztiz abiarazteko prest dagoen bertsioa da.
- Ondoren, eszenatokia dator betetzea. Hemen aplikazioa askatzen dugu gure bertsiotik beharrezko prozesuak exekutatuz.
Eredu baten edo kanalizazio osoaren bertsio berriak askatzeko sistema horrek administratzaileen eta garatzaileen artean rolak bereizteko aukera ematen du, bertsioen jarraipena egiteko aukera ematen du eta programaren nahigabeko geldialdiak saihesten ditu.
Askapen-zereginerako, hainbat zerbitzu sortu dira, zeinetan prozesuak idatzi ditzakezu .yml fitxategi batean exekutatzeko (adibidez, CircleCIn hau config.yml da prozesua bera laguntzeko). Wheely bikaina da proiektuetarako paketeak sortzeko.
Zure ikaskuntza automatikoko ereduaren bertsio ezberdinekin paketeak sor ditzakezu, eta gero paketatu eta beharrezko paketeei eta haien bertsioei erreferentzia egin hortik idatzi dituzun funtzioak erabiltzeko. Honek zure eredurako API bat sortzen lagunduko dizu, eta zure paketea Gemfury-n ostata daiteke, adibidez.
6. printzipioa. Exekutatu zure eredua prozesu bat edo gehiago gisa
Gainera, prozesuek ez dute datu partekaturik izan behar. Hau da, prozesuek bereizita egon behar dute, eta mota guztietako datuak bereizita egon behar dira, adibidez, hirugarrenen zerbitzuetan MySQL edo beste batzuetan, behar duzunaren arabera.
Hau da, zalantzarik gabe ez du merezi datuak prozesu fitxategi-sistemaren barruan gordetzeak, bestela honek datu hauek garbitzea ekar dezake hurrengo konfigurazioen bertsioan/aldaketan edo programa exekutatzen den sistemaren transferentzian.
Baina bada salbuespen bat: ikaskuntza automatikoko proiektuetarako, liburutegien cache bat gorde dezakezu, bertsio berri bat abiarazten duzun bakoitzean berriro instalatzeko, liburutegi gehigarririk edo haien bertsioetan aldaketarik egin ez bada. Horrela, zure eredua industrian abiarazteko behar den denbora murriztuko duzu.
Eredua hainbat prozesu gisa exekutatzeko, .yml fitxategi bat sor dezakezu eta bertan beharrezkoak diren prozesuak eta haien sekuentzia zehaztuko dituzu.
7. printzipioa: Birziklagarritasuna
Zure ereduko aplikazioan exekutatzen diren prozesuek abiarazteko eta gelditzeko errazak izan behar dute. Horrela, kode-aldaketak, konfigurazio-aldaketak, azkar eta malgutasunez eskalatu eta lan-bertsioaren matxura posibleak saihesteko aukera emango dizu.
Hau da, ereduarekin duzun prozesuak:
- Minimizatu abiarazteko denbora. Egokiena, abiarazte-denbora (abioko komandoa igorri zen unetik prozesua martxan jartzen den unera) segundo batzuk baino gehiago ez izatea. Liburutegiaren cachea, goian deskribatuta, abiarazteko denbora murrizteko teknika bat da.
- Ondo amaitu. Hau da, zerbitzu portuan entzutea etenda dago benetan, eta portu horretara bidalitako eskaera berriak ez dira prozesatuko. Hemen DevOps ingeniariekin komunikazio ona ezarri behar duzu, edo zuk zeuk nola funtzionatzen duen ulertu (hobe, noski, azken hau, baina komunikazioa beti mantendu behar da, edozein proiektutan!)
8. printzipioa: Etengabeko hedapena/integrazioa
Enpresa askok aplikazioen garapen eta inplementazio taldeen arteko bereizketa erabiltzen dute (aplikazioa azken erabiltzaileen eskura jarriz). Horrek asko moteldu dezake softwarearen garapena eta hobetzen aurrera egitea. DevOps kultura ere hondatzen du, non garapena eta integrazioa, gutxi gorabehera, konbinatzen diren.
Beraz, printzipio honek dio zure garapen-inguruneak zure ekoizpen-ingurunetik ahalik eta hurbilen egon behar duela.
Horrek aukera emango du:
- Murriztu askatzeko denbora hamarnaka aldiz
- Murriztu akatsen kopurua kodea bateraezintasuna dela eta.
- Horrek langileen lan karga ere murrizten du, garatzaileak eta aplikazioa zabaltzen duten pertsonak talde bat baitira orain.
Honekin lan egiteko aukera ematen duten tresnak dira CircleCI, Travis CI, GitLab CI eta beste batzuk.
Ereduari bizkor gehigarriak egin, eguneratu eta berehala abiarazi dezakezu, hutsegiteen kasuan, laneko bertsiora oso azkar itzultzea erraza izango den bitartean, azken erabiltzaileak ohartu ere egin ez dezan. Hau bereziki erraz eta azkar egin daiteke proba onak badituzu.
Desberdintasunak gutxitu!!!
9. printzipioa. Zure erregistroak
Erregistroak (edo "Erregistroak") aplikazioan (gertaeren korrontea) gertatzen diren gertaerak dira, normalean testu formatuan erregistratuta. Adibide sinple bat: "2020-02-02 - sistema maila - prozesuaren izena". Garatzaileak programa martxan dagoenean gertatzen ari dena literalki ikus dezan diseinatuta daude. Prozesuen aurrerapena ikusten du eta garatzaileak berak nahi zuen bezala den ulertzen du.
Printzipio honek dio ez duzula zure erregistroak gorde behar zure fitxategi-sisteman; pantailara "irteera" besterik ez zenuke egin behar, adibidez, sistemaren irteera estandarrean egin. Eta horrela, garapenean zehar terminaleko emaria kontrolatu ahal izango da.
Horrek esan nahi al du ez dagoela erregistroak gorde beharrik? Noski ezetz. Zure aplikazioak ez luke hori egin behar; utzi hirugarrenen zerbitzuen esku. Zure aplikazioak erregistroak fitxategi edo terminal zehatz batera soilik birbidal ditzake denbora errealean ikusteko, edo helburu orokorreko datuak biltegiratzeko sistema batera birbidal ditzake (hadoop adibidez). Zure aplikazioak berak ez luke erregistroak gorde edo elkarreragin behar.
10. printzipioa. Proba!
Makina-ikaskuntza industrialerako, fase hau oso garrantzitsua da, ereduak behar bezala funtzionatzen duela eta nahi duzuna sortzen duela ulertu behar baituzu.
Probak pytest erabiliz sor daitezke, eta datu multzo txiki bat erabiliz probatu, erregresio/sailkapen zeregin bat baduzu.
Ez ahaztu ikasketa sakoneko ereduetarako hazi bera ezartzea, etengabe emaitza desberdinak ekoizteko.
Hau 10 printzipioen deskribapen laburra izan zen, eta, noski, zaila da nola funtzionatzen duten probatu eta ikusi gabe erabiltzea, beraz, artikulu hau artikulu interesgarri batzuen hitzaurrea besterik ez da, non nola sortu nola sortu azalduko dudan. Makina ikasteko eredu industrialak, nola integratu sistemetan, eta printzipio horiek bizitza erraztu diezaguketen guztioi.
Nahi izanez gero, edonork iruzkinetan utzi ditzakeen printzipio politak erabiltzen ere saiatuko naiz.
Iturria: www.habr.com