Industria Maŝina Lernado: 10 Dezajnaj Principoj
Nuntempe, novaj servoj, aplikoj kaj aliaj gravaj programoj estas kreitaj ĉiutage, kiuj ebligas krei nekredeblajn aferojn: de programaro por kontroli SpaceX-raketon ĝis interagado kun kaldrono en la apuda ĉambro per inteligenta telefono.
Kaj, foje, ĉiu komencanto programisto, ĉu li estas pasia startulo aŭ ordinara Full Stack aŭ Data Scientist, baldaŭ aŭ malfrue ekkomprenas, ke ekzistas certaj reguloj por programado kaj kreado de programaro, kiuj multe simpligas la vivon.
En ĉi tiu artikolo, mi mallonge priskribos 10 principojn pri kiel programi industrian maŝinlernadon, por ke ĝi povu facile integriĝi en aplikaĵon/servon, surbaze de la 12-faktora App-metodaro. . Mia iniciato estas pliigi la konscion pri ĉi tiu tekniko, kiu povas helpi multajn programistojn kaj datumsciencajn homojn.
Tiu artikolo estas prologo al serio de artikoloj pri industria Maŝinlernado. En ili mi plue parolos pri kiel efektive fari modelon kaj lanĉi ĝin en produktadon, krei API por ĝi, kaj ankaŭ ekzemplojn de diversaj areoj kaj kompanioj, kiuj havas enkonstruitan ML en siaj sistemoj.
Principo 1: Unu koda bazo
Iuj programistoj en la unuaj etapoj, pro maldiligento eltrovi ĝin (aŭ ial propra), forgesas pri Git. Ili aŭ tute forgesas la vorton, tio estas, ili ĵetas dosierojn unu al la alia en la disko/nur ĵetas tekston/sendas per kolomboj, aŭ ili ne pripensas sian laborfluon, kaj devigas ĉiun al sia branĉo, kaj poste al la majstro.
Ĉi tiu principo diras: havas unu kodbazon kaj multajn deplojojn.
Git povas esti uzata kaj en produktado kaj en esplorado kaj evoluo (R&D), en kiuj ĝi ne estas uzata tiel ofte.
Ekzemple, en la R&D-fazo vi povas lasi komitaĵojn kun malsamaj metodoj kaj modeloj de datumtraktado, por tiam elekti la plej bonan kaj facile daŭrigi labori kun ĝi plu.
Due, en produktado ĉi tio estas neanstataŭebla afero - vi devos konstante rigardi kiel via kodo ŝanĝiĝas kaj scii kiu modelo produktis la plej bonajn rezultojn, kiu kodo funkciis finfine kaj kio okazis, kio kaŭzis, ke ĝi ĉesis funkcii aŭ komenci produkti malĝustajn rezultojn. . Por tio estas kommitaĵoj!
Vi ankaŭ povas krei pakaĵon de via projekto, metante ĝin, ekzemple, sur Gemfury, kaj poste simple importi funkciojn de ĝi por aliaj projektoj, por ne reverki ilin 1000 fojojn, sed pli pri tio poste.
Principo 2: Klare deklari kaj izoli dependecojn
Ĉiu projekto havas malsamajn bibliotekojn, kiujn vi importas de ekstere por apliki ilin ie. Ĉu temas pri Python-bibliotekoj, aŭ bibliotekoj de aliaj lingvoj por diversaj celoj, aŭ sistemaj iloj - via tasko estas:
- Klare deklaru dependecojn, tio estas, dosieron, kiu enhavos ĉiujn bibliotekojn, ilojn kaj iliajn versiojn, kiuj estas uzataj en via projekto kaj kiuj devas esti instalitaj (ekzemple, en Python tio povas esti farita per Pipfile aŭ requirements.txt. A ligilo kiu permesas bone kompreni: )
- Izolu dependecojn specife por via programo dum disvolviĝo. Ĉu vi ne volas konstante ŝanĝi versiojn kaj reinstali, ekzemple, Tensorflow?
Tiel, programistoj, kiuj estonte aliĝos al via teamo, povos rapide konatiĝi kun la bibliotekoj kaj iliaj versioj, kiuj estas uzataj en via projekto, kaj vi ankaŭ havos la ŝancon administri la versiojn kaj bibliotekojn mem instalitajn por specifa. projekto, kiu helpos vin eviti nekongruecon de bibliotekoj aŭ iliaj versioj.
Via aplikaĵo ankaŭ ne devas fidi sistemajn ilojn, kiuj povas esti instalitaj en specifa OS. Ĉi tiuj iloj ankaŭ devas esti deklaritaj en la manifestaĵo pri dependecoj. Ĉi tio estas necesa por eviti situaciojn, kie la versio de la iloj (same kiel ilia havebleco) ne kongruas kun la sistemaj iloj de aparta OS.
Tiel, eĉ se buklo povas esti uzata en preskaŭ ĉiuj komputiloj, vi ankoraŭ devus deklari ĝin en dependecoj, ĉar dum migrado al alia platformo ĝi eble ne estas tie aŭ la versio ne estos tiu, kiun vi bezonis origine.
Ekzemple, via requirements.txt povus aspekti jene:
# 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
Principo 3: Agordoj
Multaj aŭdis rakontojn pri diversaj programistoj hazarde alŝutantaj kodon al GitHub en publikajn deponejojn kun pasvortoj kaj aliaj ŝlosiloj de AWS, vekiĝante la sekvan tagon kun ŝuldo de $6000, aŭ eĉ $50000.
Kompreneble, ĉi tiuj kazoj estas ekstremaj, sed tre signifaj. Se vi konservas viajn akreditaĵojn aŭ aliajn datumojn necesajn por agordo ene de la kodo, vi faras eraron, kaj mi pensas, ke ne necesas klarigi kial.
Alternativo al tio estas stoki agordojn en mediovariabloj. Vi povas legi pli pri mediaj variabloj .
Ekzemploj de datenoj kiuj estas tipe stokitaj en mediovariabloj:
- Domajnaj nomoj
- API URL-oj/URI-oj
- Publikaj kaj privataj ŝlosiloj
- Kontaktoj (poŝto, telefonoj, ktp.)
Tiel vi ne devas konstante ŝanĝi la kodon se viaj agordaj variabloj ŝanĝiĝas. Ĉi tio helpos ŝpari al vi tempon, penadon kaj monon.
Ekzemple, se vi uzas la Kaggle API por fari testojn (ekzemple, elŝutu la programaron kaj rulu la modelon per ĝi por provi, kiam vi funkcias, ke la modelo funkcias bone), tiam privataj ŝlosiloj de Kaggle, kiel KAGGLE_USERNAME kaj KAGGLE_KEY, devus esti stokita en mediovariabloj.
Principo 4: Triaj Servoj
La ideo ĉi tie estas krei la programon tiel, ke ne ekzistas diferenco inter lokaj kaj triaj rimedoj laŭ kodo. Ekzemple, vi povas konekti ambaŭ lokajn MySQL kaj triajn. La sama validas por diversaj APIoj kiel Google Maps aŭ Twitter API.
Por malŝalti trian servon aŭ konekti alian, vi nur bezonas ŝanĝi la ŝlosilojn en la agordo en la medio-variabloj, pri kiuj mi parolis en la supra alineo.
Do, ekzemple, anstataŭ specifi la vojon al dosieroj kun datumaroj ene de la kodo ĉiufoje, estas pli bone uzi la pathlib-bibliotekon kaj deklari la vojon al la datumseroj en config.py, tiel ke negrave kian servon vi uzas (por ekzemplo, CircleCI), la programo povis eltrovi la vojon al la datumaroj konsiderante la strukturon de la nova dosiersistemo en la nova servo.
Principo 5. Konstruo, liberigo, rultempo
Multaj homoj en Datuma Scienco trovas ĝin utila plibonigi siajn programajn skribkapablojn. Se ni volas, ke nia programo kraŝu kiel eble plej malofte kaj funkciu sen misfunkciadoj kiel eble plej longe, ni devas dividi la procezon de publikigo de nova versio en 3 stadiojn:
- Scenejo asembleoj. Vi transformas vian nudan kodon per individuaj rimedoj en tiel nomatan pakaĵon, kiu enhavas ĉiujn necesajn kodon kaj datumojn. Ĉi tiu pako nomiĝas asembleo.
- Scenejo liberigo — ĉi tie ni ligas nian agordon al la asembleo, sen kiu ni ne povus liberigi nian programon. Nun ĉi tio estas tute preta lanĉo-eldono.
- Poste venas la scenejo plenumo. Ĉi tie ni liberigas la aplikaĵon rulante la necesajn procezojn de nia eldono.
Tia sistemo por publikigi novajn versiojn de modelo aŭ la tuta dukto ebligas al vi apartigi rolojn inter administrantoj kaj programistoj, permesas spuri versiojn kaj malhelpas nedeziratajn haltojn de la programo.
Por la eldontasko, multaj malsamaj servoj estis kreitaj en kiuj vi povas skribi procezojn por ruli vin mem en .yml dosiero (ekzemple, en CircleCI ĉi tio estas config.yml por subteni la procezon mem). Wheely estas bonega krei pakaĵojn por projektoj.
Vi povas krei pakaĵojn kun malsamaj versioj de via maŝinlernada modelo, kaj poste paki ilin kaj referenci al la necesaj pakaĵoj kaj iliaj versioj por uzi la funkciojn, kiujn vi skribis de tie. Ĉi tio helpos vin krei API por via modelo, kaj via pako povas esti gastigita ĉe Gemfury, ekzemple.
Principo 6. Kuru vian modelon kiel unu aŭ pluraj procezoj
Krome, procezoj ne devus havi komunajn datumojn. Tio estas, procezoj devas ekzisti aparte, kaj ĉiuj specoj de datumoj devas ekzisti aparte, ekzemple en triaj servoj kiel MySQL aŭ aliaj, depende de tio, kion vi bezonas.
Tio estas, certe ne indas konservi datumojn ene de la proceza dosiersistemo, alie ĉi tio povas konduki al forigo de ĉi tiuj datumoj dum la sekva eldono/ŝanĝo de agordoj aŭ translokigo de la sistemo, sur kiu funkcias la programo.
Sed estas escepto: por maŝinlernado projektoj, vi povas konservi kaŝmemoron da bibliotekoj por ne reinstali ilin ĉiufoje kiam vi lanĉas novan version, se neniuj aldonaj bibliotekoj aŭ ajnaj ŝanĝoj estis faritaj al iliaj versioj. Tiel vi reduktos la tempon necesan por lanĉi vian modelon en industrio.
Por ruli la modelon kiel pluraj procezoj, vi povas krei .yml-dosieron, en kiu vi specifas la necesajn procezojn kaj ilian sinsekvon.
Principo 7: Recikleblo
La procezoj kiuj funkcias en via modela aplikaĵo devus esti facile komenci kaj haltigi. Tiel, ĉi tio permesos al vi rapide deploji kodŝanĝojn, agordajn ŝanĝojn, rapide kaj flekseble skali, kaj malhelpi eblajn paneojn de la funkcianta versio.
Tio estas, via procezo kun la modelo devus:
- Minimumu la ektempon. Ideale, la ektempo (de la momento, kiam la ekkomando estis elsendita ĝis la momento, kiam la procezo ekfunkcias) devus esti ne pli ol kelkaj sekundoj. Biblioteko-kaŝmemoro, priskribita supre, estas unu tekniko por redukti lanĉtempon.
- Finu ĝuste. Tio estas, aŭskultado sur la serva haveno estas fakte suspendita, kaj novaj petoj senditaj al ĉi tiu haveno ne estos procesitaj. Ĉi tie vi aŭ devas starigi bonan komunikadon kun DevOps-inĝenieroj, aŭ mem kompreni kiel ĝi funkcias (prefere, kompreneble, ĉi-lasta, sed komunikado ĉiam estu konservita, en iu ajn projekto!)
Principo 8: Kontinua Deplojo/Integriĝo
Multaj firmaoj uzas apartigon inter la aplikaĵdisvolvado kaj deplojteamoj (farante la aplikaĵon havebla al finuzantoj). Ĉi tio povas multe malrapidigi programaron kaj progresi en plibonigo de ĝi. Ĝi ankaŭ ruinigas la kulturon DevOps, kie evoluo kaj integriĝo estas, proksimume, kombinitaj.
Tial ĉi tiu principo deklaras, ke via evolua medio estu kiel eble plej proksima al via produktadmedio.
Ĉi tio permesos:
- Reduktu eldontempon je dekoj da fojoj
- Redukti la nombron da eraroj pro koda nekongruo.
- Ĉi tio ankaŭ reduktas la laborkvanton de dungitaro, ĉar programistoj kaj homoj deplojantaj la aplikaĵon nun estas unu teamo.
Iloj kiuj permesas vin labori kun ĉi tio estas CircleCI, Travis CI, GitLab CI kaj aliaj.
Vi povas rapide fari aldonojn al la modelo, ĝisdatigi ĝin kaj lanĉi ĝin tuj, dum estos facile, en kazo de malsukcesoj, reveni tre rapide al la funkcianta versio, por ke la fina uzanto eĉ ne rimarku ĝin. Ĉi tio povas esti farita precipe facile kaj rapide se vi havas bonajn testojn.
Minimumu diferencojn!!!
Principo 9. Viaj ŝtipoj
Protokoloj (aŭ "Protokoloj") estas eventoj, kutime registritaj en tekstformato, kiuj okazas ene de la aplikaĵo (okazaĵfluo). Simpla ekzemplo: "2020-02-02 - sistemnivelo - proceza nomo." Ili estas dizajnitaj tiel ke la programisto povas laŭvorte vidi kio okazas kiam la programo funkcias. Li vidas la progreson de procezoj kaj komprenas ĉu ĝi estas kiel la programisto mem celis.
Ĉi tiu principo deklaras, ke vi ne devas konservi viajn protokolojn ene de via dosiersistemo - vi devus nur "eligi" ilin al la ekrano, ekzemple, faru tion sur la norma eligo de la sistemo. Kaj tiamaniere eblos monitori la fluon en la terminalo dum disvolviĝo.
Ĉu tio signifas, ke tute ne necesas konservi protokolojn? Kompreneble ne. Via aplikaĵo simple ne devus fari tion - lasu ĝin al triaj servoj. Via aplikaĵo povas nur plusendi protokolojn al specifa dosiero aŭ terminalo por realtempa spektado, aŭ plusendi ĝin al ĝeneraluzebla datuma stokado (kiel ekzemple Hadoop). Via aplikaĵo mem ne devas konservi aŭ interagi kun protokoloj.
Principo 10. Provu!
Por industria maŝinlernado, ĉi tiu fazo estas ege grava, ĉar vi devas kompreni, ke la modelo funkcias ĝuste kaj produktas tion, kion vi deziris.
Testoj povas esti kreitaj per pytest, kaj testitaj per malgranda datumaro se vi havas regresan/klasifikan taskon.
Ne forgesu agordi la saman semon por profundaj lernaj modeloj, por ke ili ne konstante produktas malsamajn rezultojn.
Ĉi tio estis mallonga priskribo de la 10 principoj, kaj, kompreneble, estas malfacile uzi ilin sen provi kaj vidi kiel ili funkcias, do ĉi tiu artikolo estas nur prologo al serio de interesaj artikoloj en kiuj mi malkaŝos kiel krei. industriaj maŝinlernantaj modeloj, kiel integri ilin en sistemojn, kaj kiel ĉi tiuj principoj povas faciligi la vivon al ni ĉiuj.
Mi ankaŭ provos uzi bonegajn principojn, kiujn ĉiu povas lasi en la komentoj, se ili deziras.
fonto: www.habr.com