Industriële Masjienleer: 10 Ontwerpbeginsels
Deesdae word elke dag nuwe dienste, toepassings en ander belangrike programme geskep wat dit moontlik maak om ongelooflike dinge te skep: van sagteware om 'n SpaceX-vuurpyl te beheer tot interaksie met 'n ketel in die volgende kamer via 'n slimfoon.
En soms kom elke beginner programmeerder, of hy nou 'n passievolle beginner of 'n gewone Full Stack of Data Scientist is, vroeër of later tot die besef dat daar sekere reëls is vir programmering en skep van sagteware wat die lewe aansienlik vereenvoudig.
In hierdie artikel sal ek kortliks 10 beginsels beskryf van hoe om industriële masjienleer te programmeer sodat dit maklik in 'n toepassing/diens geïntegreer kan word, gebaseer op die 12-faktor App metodologie. . My inisiatief is om die bewustheid van hierdie tegniek te verhoog, wat baie ontwikkelaars en datawetenskapmense kan help.
Hierdie artikel is 'n proloog tot 'n reeks artikels oor industriële masjienleer. In hulle sal ek verder praat oor hoe om werklik 'n model te maak en dit in produksie te begin, 'n API daarvoor te skep, sowel as voorbeelde van verskeie gebiede en maatskappye wat ingeboude ML in hul stelsels het.
Beginsel 1: Een kodebasis
Sommige programmeerders in die eerste stadiums, uit luiheid om dit uit te vind (of om een of ander rede van hul eie), vergeet van Git. Hulle vergeet of heeltemal die woord, dit wil sê, hulle gooi lêers vir mekaar in die dryf/gooi net teks/stuur deur duiwe, of hulle dink nie deur hul werkstroom nie, en verbind elkeen tot hul eie tak, en dan tot die meester.
Hierdie beginsel lui: het een kodebasis en baie ontplooiings.
Git kan beide in produksie en in navorsing en ontwikkeling (N&O) gebruik word, waarin dit nie so gereeld gebruik word nie.
Byvoorbeeld, in die R&D-fase kan jy commits verlaat met verskillende dataverwerkingsmetodes en -modelle, om dan die beste een te kies en maklik verder daarmee voort te werk.
Tweedens, in produksie is dit 'n onvervangbare ding - jy sal voortdurend moet kyk hoe jou kode verander en weet watter model die beste resultate opgelewer het, watter kode op die ou end gewerk het en wat gebeur het wat veroorsaak het dat dit ophou werk het of verkeerde resultate begin lewer het . Dis waarvoor commits is!
Jy kan ook 'n pakket van jou projek skep, dit byvoorbeeld op Gemfury plaas, en dan eenvoudig funksies daaruit invoer vir ander projekte, om dit nie 1000 keer te herskryf nie, maar later meer daaroor.
Beginsel 2: Verklaar en isoleer afhanklikhede duidelik
Elke projek het verskillende biblioteke wat jy van buite af invoer om dit iewers toe te pas. Of dit nou Python-biblioteke is, of biblioteke van ander tale vir verskeie doeleindes, of stelselgereedskap - jou taak is:
- Verklaar afhanklikhede duidelik, dit wil sê 'n lêer wat al die biblioteke, gereedskap en hul weergawes sal bevat wat in jou projek gebruik word en wat geïnstalleer moet word (byvoorbeeld, in Python kan dit gedoen word deur Pipfile of requirements.txt te gebruik. A skakel wat dit toelaat om goed te verstaan: )
- Isoleer afhanklikhede spesifiek vir jou program tydens ontwikkeling. Wil u nie voortdurend weergawes verander en byvoorbeeld Tensorflow weer installeer nie?
Op hierdie manier sal ontwikkelaars wat in die toekoms by jou span aansluit, vinnig vertroud kan raak met die biblioteke en hul weergawes wat in jou projek gebruik word, en jy sal ook die geleentheid kry om die weergawes en biblioteke wat self geïnstalleer is vir 'n spesifieke projek, wat jou sal help om onversoenbaarheid van biblioteke of hul weergawes te vermy.
Jou toepassing moet ook nie staatmaak op stelselnutsgoed wat op 'n spesifieke bedryfstelsel geïnstalleer kan word nie. Hierdie instrumente moet ook in die afhanklikheidsmanifes verklaar word. Dit is nodig om situasies te vermy waar die weergawe van die gereedskap (sowel as hul beskikbaarheid) nie ooreenstem met die stelselnutsgoed van 'n spesifieke bedryfstelsel nie.
Dus, selfs al kan krul op byna alle rekenaars gebruik word, moet jy dit steeds in afhanklikhede verklaar, aangesien wanneer jy na 'n ander platform migreer, dit dalk nie daar is nie of die weergawe sal nie die een wees wat jy oorspronklik nodig gehad het nie.
Byvoorbeeld, jou requirements.txt kan soos volg lyk:
# 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
Beginsel 3: Konfigurasies
Baie het al stories gehoor van verskillende ontwikkelaars wat per ongeluk kode na GitHub in openbare bewaarplekke met wagwoorde en ander sleutels van AWS oplaai, en die volgende dag wakker word met 'n skuld van $6000, of selfs $50000.
Natuurlik is hierdie gevalle uiters, maar baie betekenisvol. As jy jou geloofsbriewe of ander data wat nodig is vir konfigurasie binne die kode stoor, maak jy 'n fout, en ek dink dit is nie nodig om te verduidelik hoekom nie.
'n Alternatief hiervoor is om konfigurasies in omgewingsveranderlikes te stoor. Jy kan meer lees oor omgewingsveranderlikes .
Voorbeelde van data wat tipies in omgewingsveranderlikes gestoor word:
- Domeinname
- API URL's/URI's
- Publieke en private sleutels
- Kontakte (pos, telefone, ens.)
Op hierdie manier hoef jy nie voortdurend die kode te verander as jou konfigurasie veranderlikes verander nie. Dit sal jou help om tyd, moeite en geld te bespaar.
Byvoorbeeld, as jy die Kaggle API gebruik om toetse uit te voer (laai byvoorbeeld die sagteware af en hardloop die model daardeur om te toets wanneer dit loop dat die model goed werk), dan behoort private sleutels van Kaggle, soos KAGGLE_USERNAME en KAGGLE_KEY, te wees gestoor in omgewingsveranderlikes.
Beginsel 4: Derdepartydienste
Die idee hier is om die program op so 'n manier te skep dat daar geen verskil is tussen plaaslike en derdeparty-hulpbronne in terme van kode nie. Byvoorbeeld, jy kan beide plaaslike MySQL en derdepartye koppel. Dieselfde geld vir verskeie API's soos Google Maps of Twitter API.
Om 'n derdepartydiens te deaktiveer of 'n ander te koppel, hoef u net die sleutels in die konfigurasie in die omgewingsveranderlikes te verander, waaroor ek in die paragraaf hierbo gepraat het.
So, byvoorbeeld, in plaas daarvan om elke keer die pad na lêers met datastelle binne die kode te spesifiseer, is dit beter om die pathlib-biblioteek te gebruik en die pad na die datastelle in config.py te verklaar, sodat dit nie saak maak watter diens jy gebruik nie (vir byvoorbeeld CircleCI), kon die program die pad na die datastelle uitvind met inagneming van die struktuur van die nuwe lêerstelsel in die nuwe diens.
Beginsel 5. Bou, vrystel, looptyd
Baie mense in Data Science vind dit nuttig om hul sagteware-skryfvaardighede te verbeter. As ons wil hê dat ons program so selde moontlik ineenstort en so lank as moontlik sonder mislukkings moet werk, moet ons die proses om 'n nuwe weergawe vry te stel in 3 fases verdeel:
- Verhoog vergaderings. Jy transformeer jou blote kode met individuele hulpbronne in 'n sogenaamde pakket wat al die nodige kode en data bevat. Hierdie pakket word 'n samestelling genoem.
- Verhoog vrylating - hier koppel ons ons konfigurasie aan die samestelling, waarsonder ons nie ons program sou kon vrystel nie. Nou is dit 'n heeltemal gereed-vir-bekendstelling vrystelling.
- Volgende kom die verhoog vervulling. Hier stel ons die toepassing vry deur die nodige prosesse vanaf ons vrystelling uit te voer.
So 'n stelsel vir die vrystelling van nuwe weergawes van 'n model of die hele pyplyn laat jou toe om rolle tussen administrateurs en ontwikkelaars te skei, laat jou toe om weergawes op te spoor en verhoed ongewenste stops van die program.
Vir die vrystellingstaak is baie verskillende dienste geskep waarin jy prosesse kan skryf om jouself in 'n .yml-lêer te laat loop (byvoorbeeld, in CircleCI is dit config.yml om die proses self te ondersteun). Wheely is wonderlik om pakkette vir projekte te skep.
Jy kan pakkette met verskillende weergawes van jou masjienleermodel skep, en dan verpak en na die nodige pakkette en hul weergawes verwys om die funksies wat jy van daar af geskryf het, te gebruik. Dit sal jou help om 'n API vir jou model te skep, en jou pakket kan byvoorbeeld op Gemfury gehuisves word.
Beginsel 6. Begin jou model as een of meer prosesse
Boonop moet prosesse nie gedeelde data hê nie. Dit wil sê, prosesse moet afsonderlik bestaan, en alle soorte data moet afsonderlik bestaan, byvoorbeeld op derdepartydienste soos MySQL of ander, afhangende van wat jy nodig het.
Dit wil sê, dit is beslis nie die moeite werd om data binne die proseslêerstelsel te stoor nie, anders kan dit lei tot die skoonmaak van hierdie data tydens die volgende vrystelling/verandering van konfigurasies of oordrag van die stelsel waarop die program loop.
Maar daar is 'n uitsondering: vir masjienleerprojekte kan u 'n kas van biblioteke stoor om dit nie elke keer as u 'n nuwe weergawe bekendstel, weer te installeer as geen bykomende biblioteke of enige veranderinge aan hul weergawes aangebring is nie. Op hierdie manier sal jy die tyd wat dit neem om jou model in die industrie bekend te stel, verminder.
Om die model as verskeie prosesse te laat loop, kan jy 'n .yml-lêer skep waarin jy die nodige prosesse en hul volgorde spesifiseer.
Beginsel 7: Herwinbaarheid
Die prosesse wat in jou modeltoepassing loop, behoort maklik te begin en te stop. Dit sal jou dus toelaat om kodeveranderings, konfigurasieveranderings vinnig te ontplooi, vinnig en buigsaam te skaal, en moontlike ineenstortings van die werkende weergawe te voorkom.
Dit wil sê, jou proses met die model moet:
- Minimaliseer opstarttyd. Die ideaal is dat die opstarttyd (vanaf die oomblik dat die opstartbevel uitgereik is tot die oomblik dat die proses in werking tree) nie meer as 'n paar sekondes moet wees nie. Biblioteekkas, hierbo beskryf, is een tegniek om opstarttyd te verminder.
- Eindig reg. Dit wil sê, luister op die dienspoort word eintlik opgeskort, en nuwe versoeke wat by hierdie poort ingedien word, sal nie verwerk word nie. Hier moet jy óf goeie kommunikasie met DevOps-ingenieurs opstel, óf self verstaan hoe dit werk (verkieslik, natuurlik, laasgenoemde, maar kommunikasie moet altyd gehandhaaf word, in enige projek!)
Beginsel 8: Deurlopende ontplooiing/integrasie
Baie maatskappye gebruik 'n skeiding tussen die toepassingsontwikkeling- en ontplooiingspanne (wat die toepassing aan eindgebruikers beskikbaar stel). Dit kan sagteware-ontwikkeling aansienlik vertraag en vordering in die verbetering daarvan. Dit bederf ook die DevOps-kultuur, waar ontwikkeling en integrasie, rofweg gesproke, gekombineer word.
Daarom bepaal hierdie beginsel dat jou ontwikkelingsomgewing so na as moontlik aan jou produksie-omgewing moet wees.
Dit sal toelaat:
- Verminder vrystellingstyd met tientalle kere
- Verminder die aantal foute as gevolg van kodeonversoenbaarheid.
- Dit verminder ook die werkslading op personeel, aangesien ontwikkelaars en mense wat die toepassing ontplooi nou een span is.
Gereedskap wat jou toelaat om hiermee te werk, is CircleCI, Travis CI, GitLab CI en ander.
U kan vinnig byvoegings tot die model maak, dit opdateer en dit onmiddellik begin, terwyl dit maklik sal wees om, in geval van mislukkings, baie vinnig terug te keer na die werkende weergawe, sodat die eindgebruiker dit nie eers agterkom nie. Dit kan veral maklik en vinnig gedoen word as jy goeie toetse het.
Minimaliseer verskille!!!
Beginsel 9. Jou logs
Logs (of “Logs”) is gebeurtenisse, gewoonlik aangeteken in teksformaat, wat binne die toepassing (gebeurtenisstroom) voorkom. 'n Eenvoudige voorbeeld: "2020-02-02 - stelselvlak - prosesnaam." Hulle is so ontwerp dat die ontwikkelaar letterlik kan sien wat gebeur wanneer die program loop. Hy sien die vordering van prosesse en verstaan of dit is soos die ontwikkelaar self bedoel het.
Hierdie beginsel bepaal dat jy nie jou logs in jou lêerstelsel moet stoor nie - jy moet dit net "output" na die skerm, byvoorbeeld, doen dit op die stelsel se standaarduitvoer. En op hierdie manier sal dit moontlik wees om die vloei in die terminaal tydens ontwikkeling te monitor.
Beteken dit dat dit glad nie nodig is om logs te stoor nie? Natuurlik nie. Jou toepassing moet dit net nie doen nie - laat dit oor aan derdepartydienste. Jou toepassing kan logs net aanstuur na 'n spesifieke lêer of terminaal vir intydse besigtiging, of dit aanstuur na 'n algemene doel-databergingstelsel (soos Hadoop). Jou toepassing self moet nie logs stoor of daarmee interaksie het nie.
Beginsel 10. Toets!
Vir industriële masjienleer is hierdie fase uiters belangrik, aangesien jy moet verstaan dat die model reg werk en produseer wat jy wou hê.
Toetse kan geskep word met behulp van pytest, en getoets met 'n klein datastel as jy 'n regressie-/klassifikasietaak het.
Moenie vergeet om dieselfde saad vir diepleermodelle te stel sodat hulle nie voortdurend verskillende resultate lewer nie.
Dit was 'n kort beskrywing van die 10 beginsels, en dit is natuurlik moeilik om dit te gebruik sonder om te probeer sien hoe dit werk, so hierdie artikel is net 'n proloog tot 'n reeks interessante artikels waarin ek sal onthul hoe om te skep industriële masjienleermodelle, hoe om dit in stelsels te integreer, en hoe hierdie beginsels die lewe vir ons almal makliker kan maak.
Ek sal ook probeer om koel beginsels te gebruik wat enigiemand in die kommentaar kan los as hulle wil.
Bron: will.com