Industrial Machine Learning: 10 ûntwerpprinsipes
Tsjintwurdich wurde elke dei nije tsjinsten, applikaasjes en oare wichtige programma's makke dy't it mooglik meitsje om ongelooflijke dingen te meitsjen: fan software foar it kontrolearjen fan in SpaceX-raket oant ynteraksje mei in tsjettel yn 'e folgjende keamer fia in smartphone.
En, soms, elke begjinnende programmeur, oft hy in hertstochtlike startupper is as in gewoane Full Stack of Data Scientist, komt ier of letter ta it besef dat d'r bepaalde regels binne foar programmearring en it meitsjen fan software dy't it libben sterk ferienfâldigje.
Yn dit artikel sil ik koart beskriuwe 10-prinsipes fan hoe't jo yndustriële masine-learen kinne programmearje, sadat it maklik kin wurde yntegreare yn in applikaasje / tsjinst, basearre op 'e 12-faktor App-metodology. . Myn inisjatyf is om it bewustwêzen fan dizze technyk te fergrutsjen, dy't in protte ûntwikkelders en gegevenswittenskippen helpe kin.
Dit artikel is in prolooch foar in searje artikels oer yndustriële Machine Learning. Yn har sil ik fierder prate oer hoe't jo in model wirklik meitsje kinne en it yn produksje starte, in API foar meitsje, lykas foarbylden fan ferskate gebieten en bedriuwen dy't ML yn har systemen hawwe ynboud.
Prinsipe 1: Ien koadebasis
Guon programmeurs yn 'e earste fazen, út luiheid om it út te finen (of om ien of oare reden fan har eigen), ferjitte Git. Se ferjitte it wurd folslein, dat wol sizze, se smite triemmen nei inoar yn 'e stasjon / smyt gewoan tekst / ferstjoere troch dowen, of se tinke net troch har workflow, en sette elk yn foar har eigen branch, en dan foar de master.
Dit prinsipe stelt: hawwe ien codebase en in protte ynset.
Git kin brûkt wurde sawol yn produksje as yn ûndersyk en ûntwikkeling (R&D), wêryn it net sa faak brûkt wurdt.
Bygelyks, yn 'e R&D-faze kinne jo commits ferlitte mei ferskate gegevensferwurkingsmetoaden en modellen, om dan de bêste te selektearjen en maklik fierder mei te wurkjen.
Twad, yn produksje is dit in ûnferfangbere ding - jo moatte konstant sjen hoe't jo koade feroaret en witte hokker model de bêste resultaten produsearre, hokker koade op it lêst wurke en wat barde dat feroarsake dat it stopte mei wurkjen of begon te produsearjen fan ferkearde resultaten . Dat is wêr't commits foar binne!
Jo kinne ek in pakket fan jo projekt meitsje, it pleatse, bygelyks op Gemfury, en dan gewoan funksjes derút ymportearje foar oare projekten, om se net 1000 kear te herskriuwen, mar dêroer letter mear.
Prinsipe 2: Ferklearje en isolearje ôfhinklikens dúdlik
Elk projekt hat ferskate biblioteken dy't jo fan bûten ymportearje om se earne te tapassen. Oft it no Python-biblioteken binne, of biblioteken fan oare talen foar ferskate doelen, as systeemark - jo taak is:
- Ferklearje ôfhinklikens dúdlik, dat is in bestân dat alle biblioteken, ark en harren ferzjes befetsje dy't yn jo projekt wurde brûkt en dat moat wurde ynstalleare (bygelyks yn Python kin dit dien wurde mei Pipfile of requirements.txt. A keppeling dy't goed te begripen makket: )
- Isolearje ôfhinklikens spesifyk foar jo programma tidens ûntwikkeling. Jo wolle net konstant feroarje ferzjes en opnij ynstallearje, bygelyks, Tensorflow?
Op dizze manier kinne ûntwikkelders dy't yn 'e takomst mei jo team sille meidwaan, gau fertroud wurde mei de biblioteken en har ferzjes dy't yn jo projekt wurde brûkt, en jo sille ek de mooglikheid hawwe om de ferzjes en bibleteken sels te behearjen dy't binne ynstalleare foar in spesifyk projekt, dat sil helpe jo foarkomme ynkompatibiliteit fan biblioteken of harren ferzjes.
Jo applikaasje moat ek net fertrouwe op systeem ark dat kin wurde ynstallearre op in spesifyk OS. Dizze ark moatte ek wurde ferklearre yn it ôfhinklikens manifest. Dit is nedich om situaasjes te foarkommen wêrby't de ferzje fan 'e ark (lykas har beskikberens) net oerienkomt mei de systeemark fan in bepaald OS.
Dus, sels as curl kin wurde brûkt op hast alle kompjûters, moatte jo it noch ferklearje yn ôfhinklikens, om't by it migrearjen nei in oar platfoarm it d'r miskien net is of de ferzje sil net dejinge wêze dy't jo oarspronklik nedich hawwe.
Jo requirements.txt kin bygelyks der sa útsjen:
# 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
Prinsipe 3: Konfiguraasjes
In protte hawwe ferhalen heard fan ferskate ûntwikkelders dy't per ongeluk koade uploade nei GitHub yn iepenbiere repositories mei wachtwurden en oare kaaien fan AWS, en de oare deis wekker wurde mei in skuld fan $6000, of sels $50000.
Fansels binne dizze gefallen ekstreem, mar tige wichtich. As jo bewarje jo bewiisbrieven of oare gegevens dy't nedich binne foar konfiguraasje binnen de koade, jo meitsje in flater, en ik tink dat it is net nedich om út te lizzen wêrom.
In alternatyf hjirfoar is om konfiguraasjes te bewarjen yn omjouwingsfariabelen. Jo kinne mear lêze oer omjouwingsfariabelen .
Foarbylden fan gegevens dy't typysk wurde opslein yn omjouwingsfariabelen:
- Domeinnammen
- API URL's/URI's
- Iepenbiere en privee kaaien
- Kontakten (post, tillefoans, ensfh.)
Op dizze manier hoege jo de koade net konstant te feroarjen as jo konfiguraasjefariabelen feroarje. Dit sil helpe om jo tiid, muoite en jild te besparjen.
As jo bygelyks de Kaggle API brûke om tests út te fieren (bygelyks de software downloade en it model der troch rinne om te testen by it útfieren dat it model goed wurket), dan moatte privee kaaien fan Kaggle, lykas KAGGLE_USERNAME en KAGGLE_KEY, wêze opslein yn omjouwingsfariabelen.
Prinsipe 4: Tsjinsten fan tredden
It idee hjir is om it programma op sa'n manier te meitsjen dat d'r gjin ferskil is tusken lokale en boarnen fan tredden yn termen fan koade. Jo kinne bygelyks sawol lokale MySQL as tredden ferbine. Itselde jildt foar ferskate API's lykas Google Maps of Twitter API.
Om in tsjinst fan tredden út te skeakeljen of in oare te ferbinen, moatte jo gewoan de kaaien feroarje yn 'e konfiguraasje yn' e omjouwingsfariabelen, wêr't ik oer praat yn 'e paragraaf hjirboppe.
Dat, bygelyks, ynstee fan elke kear it paad nei bestannen mei datasetten yn 'e koade op te jaan, is it better om de pathlib-bibleteek te brûken en it paad nei de datasets yn config.py te ferklearjen, sadat hokker tsjinst jo ek brûke (foar bygelyks CircleCI), koe it programma it paad nei de datasets útfine, rekken hâldend mei de struktuer fan it nije bestânsysteem yn 'e nije tsjinst.
Prinsipe 5. Build, release, runtime
In protte minsken yn Data Science fine it nuttich om har skriuwfeardigens fan software te ferbetterjen. As wy wolle dat ús programma sa selden mooglik crasht en sa lang mooglik sûnder mislearrings wurket, moatte wy it proses fan it frijjaan fan in nije ferzje yn 3 stadia ferdiele:
- Stage gearkomsten. Jo transformearje jo bleate koade mei yndividuele middels yn in saneamde pakket dat alle nedige koade en gegevens befettet. Dit pakket wurdt in gearkomste neamd.
- Stage frijlitte - hjir ferbine wy ús konfiguraasje oan 'e gearkomste, sûnder dat wy ús programma net kinne frijlitte. No is dit in folslein klearebare release.
- Folgjende komt it poadium ferfolling. Hjir meitsje wy de applikaasje frij troch de nedige prosessen út te fieren fanút ús frijlitting.
Sa'n systeem foar it frijjaan fan nije ferzjes fan in model as de hiele pipeline lit jo rollen skiede tusken behearders en ûntwikkelders, kinne jo ferzjes folgje en foarkomt unwanted stops fan it programma.
Foar de frijlittingstaak binne in protte ferskillende tsjinsten makke wêryn jo prosessen skriuwe kinne om josels yn in .yml-bestân út te fieren (bygelyks yn CircleCI is dit config.yml om it proses sels te stypjen). Wheely is geweldich by it meitsjen fan pakketten foar projekten.
Jo kinne pakketten meitsje mei ferskate ferzjes fan jo masine-learmodel, en se dan ynpakke en ferwize nei de nedige pakketten en har ferzjes om de funksjes te brûken dy't jo dêrwei skreaun hawwe. Dit sil jo helpe om in API foar jo model te meitsjen, en jo pakket kin bygelyks wurde hosted op Gemfury.
Prinsipe 6. Run jo model as ien of mear prosessen
Boppedat moatte prosessen gjin dielde gegevens hawwe. Dat is, prosessen moatte apart bestean, en alle soarten gegevens moatte apart bestean, bygelyks op tsjinsten fan tredden lykas MySQL of oaren, ôfhinklik fan wat jo nedich binne.
Dat is, it is perfoarst net wurdich om gegevens yn it prosesbestânsysteem op te slaan, oars kin dit liede ta it wiskjen fan dizze gegevens by de folgjende release/feroaring fan konfiguraasjes of oerdracht fan it systeem wêrop it programma rint.
Mar d'r is in útsûndering: foar projekten foar masine-learen kinne jo in cache fan biblioteken opslaan om se net elke kear opnij te ynstallearjen as jo in nije ferzje starte, as der gjin ekstra bibleteken of feroaringen binne makke oan har ferzjes. Op dizze manier sille jo de tiid ferminderje dy't it nimt om jo model yn 'e yndustry te lansearjen.
Om it model as ferskate prosessen út te fieren, kinne jo in .yml-bestân meitsje wêryn jo de nedige prosessen en har folchoarder oantsjutte.
Prinsipe 7: Recyclability
De prosessen dy't rinne yn jo modelapplikaasje moatte maklik wêze om te begjinnen en te stopjen. Sa, dit sil tastean jo fluch ynsette koade feroarings, konfiguraasje feroarings, fluch en fleksibel skaalfergrutting, en foarkomme mooglike flaters fan de wurk ferzje.
Dat is, jo proses mei it model moat:
- Minimalisearje opstarttiid. Ideal, de opstarttiid (fan it momint dat it startkommando waard jûn oant it momint dat it proses yn wurking komt) moat net mear wêze as in pear sekonden. Bibleteek caching, hjirboppe beskreaun, is ien technyk foar it ferminderjen fan opstarttiid.
- Ein korrekt. Dat is, it harkjen op 'e tsjinsthaven is eins ophâlden, en nije oanfragen dy't yn dizze haven binne yntsjinne wurde net ferwurke. Hjir moatte jo of in goede kommunikaasje ynstelle mei DevOps-yngenieurs, of begripe hoe't it sels wurket (leafst, fansels, dat lêste, mar kommunikaasje moat altyd wurde ûnderhâlden, yn elk projekt!)
Prinsipe 8: trochgeande ynset / yntegraasje
In protte bedriuwen brûke in skieding tusken de applikaasjeûntwikkeling en ynsetteams (meitsje de applikaasje beskikber foar ein brûkers). Dit kin softwareûntwikkeling en foarútgong by it ferbetterjen sterk fertrage. It bedjerret ek de DevOps-kultuer, wêr't ûntwikkeling en yntegraasje, rûchwei sprutsen, kombineare binne.
Dêrom stelt dit prinsipe dat jo ûntwikkelingsomjouwing sa ticht mooglik by jo produksjeomjouwing moat wêze.
Dit sil tastean:
- Ferminderje frijlittingstiid mei tsientallen kearen
- Ferminderje it oantal flaters fanwege koade-ynkompatibiliteit.
- Dit ferleget ek de wurkdruk op personiel, om't ûntwikkelders en minsken dy't de applikaasje ynsette no ien team binne.
Ark wêrmei jo kinne wurkje mei dit binne CircleCI, Travis CI, GitLab CI en oaren.
Jo kinne fluch tafoegings oan it model meitsje, it bywurkje en it direkt starte, wylst it maklik sil wêze, yn gefal fan mislearrings, heul rap werom te gean nei de wurkferzje, sadat de ein brûker it net iens fernimt. Dit kin benammen maklik en fluch dien wurde as jo goede tests hawwe.
Minimearje ferskillen!!!
Prinsipe 9. Jo logs
Logs (as "Logboeken") binne eveneminten, meastentiids opnommen yn tekstformaat, dy't foarkomme binnen de applikaasje (evenemintstream). In ienfâldich foarbyld: "2020-02-02 - systeemnivo - prosesnamme." Se binne ûntwurpen sadat de ûntwikkelder letterlik kin sjen wat der bart as it programma rint. Hy sjocht de fuortgong fan prosessen en begrypt oft it is sa't de ûntwikkelder sels bedoeld hat.
Dit prinsipe stelt dat jo jo logs net yn jo bestânsysteem moatte opslaan - jo moatte se gewoan "útfiere" nei it skerm, bygelyks, dwaan dit op de standertútfier fan it systeem. En op dizze manier sil it mooglik wêze om de stream yn 'e terminal te kontrolearjen by ûntwikkeling.
Betsjut dit dat it hielendal net nedich is om logs op te slaan? Fansels net. Jo applikaasje soe dit gewoan net moatte dwaan - lit it oer oan tsjinsten fan tredden. Jo applikaasje kin allinich logs trochstjoere nei in spesifyk bestân of terminal foar real-time besjen, of trochstjoere nei in algemien doel gegevensopslachsysteem (lykas Hadoop). Jo applikaasje sels moat net opslaan of ynteraksje mei logs.
Prinsipe 10. Test!
Foar yndustriële masine learen is dizze faze ekstreem wichtich, om't jo moatte begripe dat it model goed wurket en produsearret wat jo woenen.
Tests kinne wurde makke mei pytest, en hifke mei in lytse dataset as jo in regression-/klassifikaasjetaak hawwe.
Ferjit net itselde sied te setten foar modellen foar djippe learen, sadat se net konstant ferskate resultaten produsearje.
Dit wie in koarte beskriuwing fan 'e 10 prinsipes, en, fansels, it is lestich om se te brûken sûnder te besykjen en te sjen hoe't se wurkje, dus dit artikel is gewoan in prolooch foar in searje nijsgjirrige artikels wêryn ik sil ûntdekke hoe't jo kinne meitsje yndustriële masine-learmodellen, hoe't se se kinne yntegrearje yn systemen, en hoe't dizze prinsipes it libben makliker meitsje kinne foar ús allegear.
Ik sil ek besykje koele prinsipes te brûken dy't elkenien yn 'e opmerkingen kin litte as se wolle.
Boarne: www.habr.com