Pramoninis mašinų mokymasis: 10 projektavimo principų
Šiais laikais kasdien sukuriamos naujos paslaugos, aplikacijos ir kitos svarbios programos, kurios leidžia sukurti neįtikėtinų dalykų: nuo programinės įrangos, skirtos SpaceX raketai valdyti, iki bendravimo su virduliu kitame kambaryje per išmanųjį telefoną.
Ir, kartais, kiekvienas pradedantysis programuotojas, nesvarbu, ar jis būtų aistringas startuolis, ar eilinis Full Stack ar Data Scientist, anksčiau ar vėliau supranta, kad yra tam tikros programavimo ir programinės įrangos kūrimo taisyklės, kurios labai supaprastina gyvenimą.
Šiame straipsnyje trumpai aprašysiu 10 principų, kaip programuoti pramoninį mašininį mokymąsi taip, kad jį būtų galima lengvai integruoti į aplikaciją/paslaugą, remiantis 12 faktorių App metodika. . Mano iniciatyva – didinti informuotumą apie šią techniką, kuri gali padėti daugeliui kūrėjų ir duomenų mokslo žmonių.
Šis straipsnis yra straipsnių apie pramoninį mašininį mokymąsi serijos prologas. Juose toliau kalbėsiu apie tai, kaip iš tikrųjų sukurti modelį ir paleisti jį į gamybą, sukurti jam API, taip pat pateiksiu pavyzdžius iš įvairių sričių ir įmonių, kurios savo sistemose turi integruotą ML.
1 principas: viena kodo bazė
Kai kurie programuotojai pirmaisiais etapais iš tingėjimo tai išsiaiškinti (arba dėl tam tikrų priežasčių) pamiršta apie Git. Jie arba visiškai pamiršta žodį, tai yra, jie meta failus vienas kitam į diską / tiesiog meta tekstą / siunčia balandžiais, arba neapmąsto savo darbo eigos ir įsipareigoja kiekvienas į savo šaką, o tada į meistras.
Šis principas teigia: turi vieną kodų bazę ir daug diegimų.
Git gali būti naudojamas tiek gamyboje, tiek tyrimams ir plėtrai (R&D), kuriuose jis ne taip dažnai naudojamas.
Pavyzdžiui, MTEP etape galite palikti įsipareigojimus su skirtingais duomenų apdorojimo metodais ir modeliais, kad vėliau pasirinktumėte geriausią ir galėtumėte lengvai tęsti darbą.
Antra, gamyboje tai yra nepakeičiamas dalykas – turėsite nuolat žiūrėti, kaip keičiasi jūsų kodas ir žinoti, kuris modelis davė geriausius rezultatus, kuris kodas galiausiai suveikė ir kas nutiko, dėl ko jis nustojo veikti arba pradėjo duoti neteisingus rezultatus. . Štai kam skirti įsipareigojimai!
Taip pat galite sukurti savo projekto paketą, įdėdami jį, pavyzdžiui, į Gemfury, o tada tiesiog importuodami iš jo funkcijas kitiems projektams, kad jų neperrašytumėte 1000 kartų, bet apie tai vėliau.
2 principas: aiškiai deklaruokite ir išskirkite priklausomybes
Kiekvienas projektas turi skirtingas bibliotekas, kurias importuojate iš išorės, kad galėtumėte jas kur nors pritaikyti. Nesvarbu, ar tai Python bibliotekos, ar kitų kalbų bibliotekos įvairiems tikslams, ar sistemos įrankiai - jūsų užduotis yra:
- Aiškiai deklaruokite priklausomybes, ty failą, kuriame bus visos bibliotekos, įrankiai ir jų versijos, kurios naudojamos jūsų projekte ir kurias būtina įdiegti (pavyzdžiui, Python tai galima padaryti naudojant Pipfile arba prasības.txt. A nuoroda, kuri leidžia gerai suprasti: )
- Kurdami atskirkite priklausomybes konkrečiai programai. Nenorite nuolat keisti versijų ir iš naujo įdiegti, pavyzdžiui, „Tensorflow“?
Tokiu būdu kūrėjai, kurie ateityje prisijungs prie jūsų komandos, galės greitai susipažinti su bibliotekomis ir jų versijomis, kurios naudojamos jūsų projekte, o jūs taip pat turėsite galimybę valdyti pačias versijas ir bibliotekas, įdiegtas konkrečiam projektui. projektas, kuris padės išvengti bibliotekų ar jų versijų nesuderinamumo.
Jūsų programa taip pat neturėtų pasikliauti sistemos įrankiais, kurie gali būti įdiegti konkrečioje OS. Šios priemonės taip pat turi būti nurodytos priklausomybių apraše. Tai būtina siekiant išvengti situacijų, kai įrankių versija (taip pat ir jų prieinamumas) neatitinka konkrečios OS sistemos įrankių.
Taigi, net jei curl galima naudoti beveik visuose kompiuteriuose, vis tiek turėtumėte jį deklaruoti kaip priklausomybes, nes perėjus į kitą platformą jos gali nebūti arba versija nebus tokia, kokios jums iš pradžių reikėjo.
Pavyzdžiui, jūsų reikalavimai.txt gali atrodyti taip:
# 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 principas: Konfigūracijos
Daugelis yra girdėję istorijų, kaip įvairūs kūrėjai netyčia įkėlė kodą į GitHub į viešas saugyklas su slaptažodžiais ir kitais AWS raktais, o kitą dieną atsibunda su 6000 USD ar net 50000 XNUMX USD skola.
Žinoma, šie atvejai yra kraštutiniai, bet labai reikšmingi. Jei kode saugote kredencialus ar kitus konfigūravimui reikalingus duomenis, darote klaidą ir manau, kad nereikia aiškinti kodėl.
Alternatyva yra saugoti konfigūracijas aplinkos kintamuosiuose. Galite perskaityti daugiau apie aplinkos kintamuosius .
Duomenų, kurie paprastai saugomi aplinkos kintamuosiuose, pavyzdžiai:
- Domeno vardai
- API URL / URI
- Viešieji ir privatūs raktai
- Kontaktai (paštas, telefonai ir kt.)
Tokiu būdu jums nereikės nuolat keisti kodo, jei pasikeičia jūsų konfigūracijos kintamieji. Tai padės sutaupyti laiko, pastangų ir pinigų.
Pavyzdžiui, jei bandymams atlikti naudojate Kaggle API (pavyzdžiui, atsisiųskite programinę įrangą ir paleiskite modelį per ją, kad paleisdami patikrintumėte, ar modelis veikia gerai), privatūs Kaggle raktai, tokie kaip KAGGLE_USERNAME ir KAGGLE_KEY, turėtų būti saugomi aplinkos kintamuosiuose.
4 principas: Trečiųjų šalių paslaugos
Idėja yra sukurti programą taip, kad pagal kodą nebūtų skirtumo tarp vietinių ir trečiųjų šalių išteklių. Pavyzdžiui, galite prijungti tiek vietinį MySQL, tiek trečiųjų šalių. Tas pats pasakytina apie įvairias API, tokias kaip „Google Maps“ ar „Twitter“ API.
Norėdami išjungti trečiosios šalies paslaugą arba prijungti kitą, tereikia pakeisti konfigūracijos raktus aplinkos kintamuosiuose, apie kuriuos kalbėjau aukščiau esančioje pastraipoje.
Taigi, pavyzdžiui, užuot kiekvieną kartą nurodę kelią į failus su duomenų rinkiniais kode, geriau naudoti pathlib biblioteką ir nurodyti kelią į duomenų rinkinius config.py, kad nesvarbu, kokią paslaugą naudojate (skirta Pavyzdžiui, CircleCI), programa galėjo sužinoti kelią į duomenų rinkinius, atsižvelgdama į naujos failų sistemos struktūrą naujoje tarnyboje.
Principas 5. Sukūrimas, išleidimas, vykdymo laikas
Daugelis duomenų mokslo darbuotojų mano, kad naudinga tobulinti programinės įrangos rašymo įgūdžius. Jei norime, kad mūsų programa strigtų kuo rečiau ir kuo ilgiau veiktų be gedimų, naujos versijos išleidimo procesą turime padalyti į 3 etapus:
- Etapas mazgai. Jūs paverčiate savo grynąjį kodą naudodami atskirus išteklius į vadinamąjį paketą, kuriame yra visas reikalingas kodas ir duomenys. Šis paketas vadinamas surinkimu.
- Etapas paleisti - čia mes prijungiame savo konfigūraciją prie surinkimo, be kurio negalėtume išleisti savo programos. Dabar tai yra visiškai paruoštas paleisti leidimas.
- Toliau ateina etapas išpildymas. Čia mes išleidžiame programą vykdydami būtinus procesus iš mūsų leidimo.
Tokia naujų modelio versijų ar viso konvejerio išleidimo sistema leidžia atskirti administratorių ir kūrėjų vaidmenis, sekti versijas ir užkirsti kelią nepageidaujamam programos sustabdymui.
Išleidimo užduočiai buvo sukurta daug įvairių paslaugų, kuriose galite rašyti procesus, kad paleistumėte save .yml faile (pavyzdžiui, CircleCI tai yra config.yml, kad palaikytų patį procesą). Wheely puikiai kuria projektų paketus.
Galite sukurti paketus su skirtingomis mašininio mokymosi modelio versijomis, tada juos supakuoti ir peržiūrėti reikiamus paketus bei jų versijas, kad galėtumėte naudoti funkcijas, kurias parašėte iš ten. Tai padės sukurti savo modelio API, o jūsų paketas gali būti talpinamas, pavyzdžiui, „Gemfury“.
6 principas. Paleiskite modelį kaip vieną ar daugiau procesų
Be to, procesai neturėtų turėti bendrų duomenų. Tai reiškia, kad procesai turi egzistuoti atskirai, o visų rūšių duomenys turi egzistuoti atskirai, pavyzdžiui, trečiųjų šalių paslaugose, tokiose kaip MySQL ar kitose, priklausomai nuo to, ko jums reikia.
Tai yra, tikrai neverta saugoti duomenų proceso failų sistemoje, nes kitaip šie duomenys gali būti išvalyti kito išleidimo/konfigūracijų pakeitimo metu arba sistemos, kurioje veikia, perkėlimas.
Tačiau yra išimtis: mašininio mokymosi projektams galite saugoti bibliotekų talpyklą, kad jos nebūtų įdiegtos iš naujo kiekvieną kartą paleidus naują versiją, jei nebuvo atlikta jokių papildomų bibliotekų ar jų versijų pakeitimų. Tokiu būdu sumažinsite laiką, kurio reikia modeliui pristatyti pramonėje.
Norėdami paleisti modelį kaip kelis procesus, galite sukurti .yml failą, kuriame nurodysite reikiamus procesus ir jų seką.
7 principas. Perdirbamumas
Procesus, kurie vykdomi jūsų modelio programoje, turėtų būti lengva pradėti ir sustabdyti. Taigi tai leis greitai įdiegti kodo pakeitimus, konfigūracijos pakeitimus, greitai ir lanksčiai keisti mastelį ir užkirsti kelią galimiems darbinės versijos gedimams.
Tai yra, jūsų procesas su modeliu turėtų:
- Sumažinkite paleidimo laiką. Idealiu atveju paleidimo laikas (nuo paleidimo komandos išdavimo iki proceso pradžios) turėtų būti ne ilgesnis nei kelios sekundės. Aukščiau aprašytas bibliotekos kaupimas talpykloje yra vienas iš būdų, kaip sumažinti paleidimo laiką.
- Baigti teisingai. Tai reiškia, kad klausymas aptarnavimo prievade iš tikrųjų yra sustabdytas, o į šį prievadą pateiktos naujos užklausos nebus apdorojamos. Čia reikia arba užmegzti gerą bendravimą su „DevOps“ inžinieriais, arba pačiam suprasti, kaip tai veikia (pageidautina, žinoma, pastarasis, bet komunikacija turi būti palaikoma visada, bet kuriame projekte!)
8 principas: Nuolatinis diegimas / integravimas
Daugelis įmonių naudoja programų kūrimo ir diegimo komandų atskyrimą (taikymą padaro prieinamą galutiniams vartotojams). Tai gali labai sulėtinti programinės įrangos kūrimą ir pažangą ją tobulinant. Tai taip pat gadina DevOps kultūrą, kur plėtra ir integracija, grubiai tariant, yra sujungti.
Todėl šis principas teigia, kad jūsų kūrimo aplinka turi būti kuo panašesnė į jūsų gamybos aplinką.
Tai leis:
- Sutrumpinkite išleidimo laiką dešimtis kartų
- Sumažinkite klaidų skaičių dėl kodo nesuderinamumo.
- Tai taip pat sumažina darbuotojų darbo krūvį, nes kūrėjai ir programą diegiantys žmonės dabar yra viena komanda.
Priemonės, leidžiančios su tuo dirbti, yra CircleCI, Travis CI, GitLab CI ir kt.
Galite greitai papildyti modelį, jį atnaujinti ir nedelsiant paleisti, o gedimų atveju bus lengva labai greitai grįžti prie veikiančios versijos, kad galutinis vartotojas to net nepastebėtų. Tai galima padaryti ypač lengvai ir greitai, jei turite gerų testų.
Sumažinkite skirtumus!!!
9 principas. Jūsų žurnalai
Žurnalai (arba „Žurnalai“) yra įvykiai, paprastai įrašomi teksto formatu, vykstantys programoje (įvykių sraute). Paprastas pavyzdys: „2020-02-02 – sistemos lygis – proceso pavadinimas“. Jie sukurti taip, kad kūrėjas galėtų tiesiogine prasme matyti, kas vyksta, kai programa veikia. Jis mato procesų eigą ir supranta, ar yra taip, kaip sumanė pats kūrėjas.
Šis principas teigia, kad neturėtumėte saugoti žurnalų savo failų sistemoje – tiesiog turėtumėte juos „išvesti“ į ekraną, pavyzdžiui, tai padaryti naudodami standartinę sistemos išvestį. Ir tokiu būdu bus galima stebėti srautą terminale kūrimo metu.
Ar tai reiškia, kad žurnalų saugoti visai nereikia? Žinoma ne. Jūsų programa tiesiog neturėtų to daryti – palikite tai trečiųjų šalių paslaugoms. Jūsų programa gali tik persiųsti žurnalus į konkretų failą ar terminalą, kad būtų galima peržiūrėti realiuoju laiku, arba persiųsti juos į bendros paskirties duomenų saugojimo sistemą (pvz., Hadoop). Pati programa neturėtų saugoti žurnalų arba su jais sąveikauti.
Principas 10. Išbandyk!
Pramoniniam mašininiam mokymuisi šis etapas yra nepaprastai svarbus, nes turite suprasti, kad modelis veikia tinkamai ir gamina tai, ko norėjote.
Testus galima sukurti naudojant pytest ir išbandyti naudojant nedidelį duomenų rinkinį, jei turite regresijos / klasifikavimo užduotį.
Nepamirškite nustatyti tos pačios sėklos giluminio mokymosi modeliams, kad jie nuolat neduotų skirtingų rezultatų.
Tai buvo trumpas 10 principų aprašymas, ir, žinoma, sunku juos panaudoti nepabandžius ir nematant, kaip jie veikia, todėl šis straipsnis yra tik įdomių straipsnių serijos prologas, kuriame atskleisiu, kaip sukurti pramoninių mašinų mokymosi modeliai , kaip juos integruoti į sistemas ir kaip šie principai gali palengvinti mūsų visų gyvenimą.
Taip pat pasistengsiu naudoti šaunius principus, kuriuos kiekvienas, jei nori, gali palikti komentaruose.
Šaltinis: www.habr.com