Învățare automată industrială: 10 principii de proiectare
În zilele noastre, în fiecare zi sunt create noi servicii, aplicații și alte programe importante care fac posibilă crearea unor lucruri incredibile: de la software pentru controlul unei rachete SpaceX până la interacțiunea cu un fierbător din camera alăturată prin intermediul unui smartphone.
Și, uneori, fiecare programator începător, fie că este un startupper pasionat sau un Full Stack obișnuit sau un Data Scientist, mai devreme sau mai târziu își dă seama că există anumite reguli de programare și creare de software care simplifică foarte mult viața.
În acest articol, voi descrie pe scurt 10 principii despre cum să programați învățarea automată industrială, astfel încât să poată fi integrată cu ușurință într-o aplicație/serviciu, pe baza metodologiei aplicației cu 12 factori. . Inițiativa mea este de a crește gradul de conștientizare a acestei tehnici, care poate ajuta mulți dezvoltatori și oameni din știința datelor.
Acest articol este un prolog la o serie de articole despre învățarea automată industrială. În ele voi vorbi în continuare despre cum să creez un model și să-l lansez în producție, să creez un API pentru acesta, precum și despre exemple din diverse zone și companii care au încorporat ML în sistemele lor.
Principiul 1: O bază de cod
Unii programatori din primele etape, din lenea de a-și da seama (sau dintr-un motiv propriu), uită de Git. Fie uită complet cuvântul, adică își aruncă fișiere unul altuia în unitate/doar aruncă text/trimit de porumbei, fie nu se gândesc la fluxul lor de lucru și se angajează pe fiecare la propria ramură, apoi la maestru.
Acest principiu prevede: au o bază de cod și multe implementări.
Git poate fi folosit atât în producție, cât și în cercetare și dezvoltare (R&D), în care nu este folosit atât de des.
De exemplu, în faza de cercetare și dezvoltare, puteți lăsa commit-uri cu diferite metode și modele de prelucrare a datelor, pentru a-l selecta apoi pe cel mai bun și a continua cu ușurință să lucrați cu acesta în continuare.
În al doilea rând, în producție, acesta este un lucru de neînlocuit - va trebui să te uiți constant la modul în care se schimbă codul tău și să știi care model a produs cele mai bune rezultate, care cod a funcționat în cele din urmă și ce s-a întâmplat care l-a determinat să nu mai funcționeze sau să înceapă să producă rezultate incorecte. . Pentru asta sunt commit-urile!
De asemenea, puteți crea un pachet al proiectului dvs., plasându-l, de exemplu, pe Gemfury, și apoi pur și simplu importând funcții din acesta pentru alte proiecte, pentru a nu le rescrie de 1000 de ori, dar mai multe despre asta mai târziu.
Principiul 2: Declarați și izolați clar dependențele
Fiecare proiect are biblioteci diferite pe care le importați din exterior pentru a le aplica undeva. Fie că este vorba de biblioteci Python, sau biblioteci ale altor limbi pentru diverse scopuri, sau instrumente de sistem - sarcina ta este:
- Declarați clar dependențele, adică un fișier care va conține toate bibliotecile, instrumentele și versiunile acestora care sunt utilizate în proiectul dvs. și care trebuie instalate (de exemplu, în Python acest lucru se poate face folosind Pipfile sau requirements.txt. A link care permite bine să înțeleagă: )
- Izolați dependențele special pentru programul dvs. în timpul dezvoltării. Nu doriți să schimbați în mod constant versiunile și să reinstalați, de exemplu, Tensorflow?
În acest fel, dezvoltatorii care se vor alătura echipei dvs. în viitor se vor putea familiariza rapid cu bibliotecile și versiunile acestora care sunt utilizate în proiectul dvs. și veți avea, de asemenea, posibilitatea de a gestiona versiunile și bibliotecile instalate pentru un anumit proiect, care vă va ajuta să evitați incompatibilitatea bibliotecilor sau a versiunilor acestora.
Aplicația dvs. nu ar trebui, de asemenea, să se bazeze pe instrumentele de sistem care pot fi instalate pe un anumit sistem de operare. Aceste instrumente trebuie, de asemenea, declarate în manifestul dependențelor. Acest lucru este necesar pentru a evita situațiile în care versiunea instrumentelor (precum și disponibilitatea acestora) nu se potrivește cu instrumentele de sistem ale unui anumit sistem de operare.
Astfel, chiar dacă curl poate fi folosit pe aproape toate computerele, ar trebui să îl declarați în dependențe, deoarece la migrarea pe o altă platformă este posibil să nu fie acolo sau versiunea nu va fi cea de care aveți nevoie inițial.
De exemplu, requirements.txt ar putea arăta astfel:
# 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
Principiul 3: Configurații
Mulți au auzit povești despre diverși dezvoltatori care încarcă accidental cod în GitHub în depozitele publice cu parole și alte chei de la AWS, trezindu-se a doua zi cu o datorie de 6000 USD sau chiar 50000 USD.
Desigur, aceste cazuri sunt extreme, dar foarte semnificative. Dacă vă stocați acreditările sau alte date necesare pentru configurare în interiorul codului, faceți o greșeală și cred că nu este nevoie să explic de ce.
O alternativă la aceasta este stocarea configurațiilor în variabilele de mediu. Puteți citi mai multe despre variabilele de mediu .
Exemple de date care sunt de obicei stocate în variabile de mediu:
- Nume de domenii
- URL-uri/URI-uri API
- Chei publice și private
- Contacte (e-mail, telefoane etc.)
În acest fel, nu trebuie să schimbați în mod constant codul dacă variabilele de configurare se modifică. Acest lucru vă va ajuta să economisiți timp, efort și bani.
De exemplu, dacă utilizați API-ul Kaggle pentru a efectua teste (de exemplu, descărcați software-ul și rulați modelul prin el pentru a testa atunci când rulați că modelul funcționează bine), atunci cheile private de la Kaggle, cum ar fi KAGGLE_USERNAME și KAGGLE_KEY, ar trebui să fie stocate în variabilele de mediu.
Principiul 4: Servicii ale terților
Ideea aici este de a crea programul în așa fel încât să nu existe nicio diferență între resursele locale și cele terțe în ceea ce privește codul. De exemplu, puteți conecta atât MySQL local, cât și cele terțe. Același lucru este valabil și pentru diferite API-uri, cum ar fi Google Maps sau Twitter API.
Pentru a dezactiva un serviciu terță parte sau pentru a conecta altul, trebuie doar să schimbați cheile din configurație în variabilele de mediu, despre care am vorbit în paragraful de mai sus.
Deci, de exemplu, în loc să specificați calea către fișierele cu seturi de date în interiorul codului de fiecare dată, este mai bine să utilizați biblioteca pathlib și să declarați calea către seturile de date în config.py, astfel încât indiferent de serviciul pe care îl utilizați (pentru de exemplu, CircleCI), programul a putut afla calea către seturile de date ținând cont de structura noului sistem de fișiere din noul serviciu.
Principiul 5. Construire, lansare, rulare
Mulți oameni din Data Science consideră că este util să-și îmbunătățească abilitățile de scriere software. Dacă dorim ca programul nostru să se blocheze cât mai rar posibil și să funcționeze fără eșecuri cât mai mult timp posibil, trebuie să împărțim procesul de lansare a unei noi versiuni în 3 etape:
- etapă adunări. Îți transformi codul de bază cu resurse individuale într-un așa-numit pachet care conține tot codul și datele necesare. Acest pachet se numește ansamblu.
- etapă eliberare — aici ne conectăm configurația la asamblare, fără de care nu ne-am putea elibera programul. Acum, aceasta este o versiune complet gata de lansare.
- Urmează scena împlinire. Aici lansăm aplicația rulând procesele necesare din versiunea noastră.
Un astfel de sistem pentru lansarea de noi versiuni ale unui model sau a întregii conducte vă permite să separați rolurile între administratori și dezvoltatori, vă permite să urmăriți versiunile și împiedică opririle nedorite ale programului.
Pentru sarcina de lansare, au fost create multe servicii diferite în care puteți scrie procese pentru a vă rula într-un fișier .yml (de exemplu, în CircleCI acesta este config.yml pentru a sprijini procesul în sine). Wheely este grozav la crearea de pachete pentru proiecte.
Puteți crea pachete cu diferite versiuni ale modelului dvs. de învățare automată, apoi le puteți împacheta și vă referiți la pachetele necesare și versiunile acestora pentru a utiliza funcțiile pe care le-ați scris de acolo. Acest lucru vă va ajuta să creați un API pentru modelul dvs., iar pachetul dvs. poate fi găzduit pe Gemfury, de exemplu.
Principiul 6. Rulați modelul ca unul sau mai multe procese
În plus, procesele nu ar trebui să aibă date partajate. Adică procesele trebuie să existe separat și toate tipurile de date trebuie să existe separat, de exemplu, pe servicii terțe precum MySQL sau altele, în funcție de ceea ce aveți nevoie.
Adică, cu siguranță nu merită stocarea datelor în sistemul de fișiere de proces, altfel acest lucru poate duce la ștergerea acestor date în timpul următoarei ediții/modificare a configurațiilor sau transferul sistemului pe care rulează programul.
Există însă o excepție: pentru proiectele de învățare automată, puteți stoca un cache de biblioteci pentru a nu le reinstala de fiecare dată când lansați o nouă versiune, dacă nu au fost făcute biblioteci suplimentare sau vreo modificare la versiunile acestora. În acest fel, vei reduce timpul necesar lansării modelului tău în industrie.
Pentru a rula modelul ca mai multe procese, puteți crea un fișier .yml în care specificați procesele necesare și secvența acestora.
Principiul 7: Reciclabilitate
Procesele care rulează în aplicația dvs. model ar trebui să fie ușor de pornit și oprit. Astfel, acest lucru vă va permite să implementați rapid modificări de cod, modificări ale configurației, să scalați rapid și flexibil și să preveniți posibile defecțiuni ale versiunii de lucru.
Adică, procesul tău cu modelul ar trebui:
- Minimizați timpul de pornire. În mod ideal, timpul de pornire (din momentul în care a fost emisă comanda de pornire până în momentul în care procesul intră în funcțiune) nu ar trebui să fie mai mare de câteva secunde. Memorarea în cache a bibliotecii, descrisă mai sus, este o tehnică pentru reducerea timpului de pornire.
- Încheiați corect. Adică, ascultarea pe portul de serviciu este de fapt suspendată, iar cererile noi trimise către acest port nu vor fi procesate. Aici trebuie fie să stabiliți o bună comunicare cu inginerii DevOps, fie să înțelegeți singur cum funcționează (de preferință, desigur, cel din urmă, dar comunicarea ar trebui să fie întotdeauna menținută, în orice proiect!)
Principiul 8: Implementare/Integrare continuă
Multe companii folosesc o separare între echipele de dezvoltare și implementare a aplicației (făcând aplicația disponibilă utilizatorilor finali). Acest lucru poate încetini foarte mult dezvoltarea software-ului și poate progresa în îmbunătățirea acestuia. De asemenea, strică cultura DevOps, unde dezvoltarea și integrarea sunt, în linii mari, combinate.
Prin urmare, acest principiu prevede că mediul dumneavoastră de dezvoltare ar trebui să fie cât mai aproape posibil de mediul dumneavoastră de producție.
Acest lucru va permite:
- Reduceți timpul de eliberare de zeci de ori
- Reduceți numărul de erori din cauza incompatibilității codului.
- Acest lucru reduce, de asemenea, volumul de muncă al personalului, deoarece dezvoltatorii și oamenii care implementează aplicația sunt acum o echipă.
Instrumentele care vă permit să lucrați cu acest lucru sunt CircleCI, Travis CI, GitLab CI și altele.
Puteți face rapid completări la model, îl actualizați și îl puteți lansa imediat, în timp ce va fi ușor, în caz de defecțiuni, să reveniți foarte repede la versiunea de lucru, astfel încât utilizatorul final să nu-l observe nici măcar. Acest lucru se poate face mai ales ușor și rapid dacă aveți teste bune.
Minimizează diferențele!!!
Principiul 9. Jurnalele dumneavoastră
Jurnalele (sau „Jurnalele”) sunt evenimente, de obicei înregistrate în format text, care apar în cadrul aplicației (flux de evenimente). Un exemplu simplu: „2020-02-02 - nivel de sistem - nume proces”. Sunt proiectate astfel încât dezvoltatorul să poată vedea literalmente ce se întâmplă atunci când programul rulează. El vede progresul proceselor și înțelege dacă este așa cum a intenționat dezvoltatorul însuși.
Acest principiu afirmă că nu ar trebui să vă stocați jurnalele în sistemul de fișiere - ar trebui doar să le „exprimați” pe ecran, de exemplu, să faceți acest lucru pe ieșirea standard a sistemului. Și în acest fel va fi posibilă monitorizarea fluxului în terminal în timpul dezvoltării.
Înseamnă asta că nu este deloc nevoie să salvați jurnalele? Desigur că nu. Aplicația dvs. pur și simplu nu ar trebui să facă acest lucru - lăsați-l pe seama serviciilor terță parte. Aplicația dvs. poate redirecționa jurnale doar către un anumit fișier sau terminal pentru vizualizare în timp real sau le poate redirecționa către un sistem de stocare a datelor de uz general (cum ar fi Hadoop). Aplicația în sine nu ar trebui să stocheze sau să interacționeze cu jurnalele.
Principiul 10. Testează!
Pentru învățarea automată industrială, această fază este extrem de importantă, deoarece trebuie să înțelegeți că modelul funcționează corect și produce ceea ce v-ați dorit.
Testele pot fi create folosind pytest și testate folosind un set de date mic dacă aveți o sarcină de regresie/clasificare.
Nu uitați să setați aceeași sămânță pentru modelele de învățare profundă, astfel încât acestea să nu producă în mod constant rezultate diferite.
Aceasta a fost o scurtă descriere a celor 10 principii și, desigur, este dificil să le folosiți fără să încercați și să vedeți cum funcționează, așa că acest articol este doar un prolog la o serie de articole interesante în care voi dezvălui cum să creați. modele industriale de învățare automată, cum să le integrăm în sisteme și cum aceste principii ne pot face viața mai ușoară tuturor.
De asemenea, voi încerca să folosesc principii cool pe care oricine le poate lăsa în comentarii dacă dorește.
Sursa: www.habr.com