Practic

MLOPSCUM SĂ TE PREPARE PENTRU

MODELEDEPRODUCȚIE

CU CAPITOLURI DIN
2 Cuprins

Conț inut
De ce contează MLOps? (Cuvânt înainte) 3

Oameni ai Învăț ării Automate 5

Cum se diferenț iază învăț area automată de software-ul tradiț ional? 8

Fluxul de lucru MLOps 10

Care este scopul MLOps? 10

Riscul în Învăț area Automatizată 11
Time to Market 15
Fluxul de lucru MLOps impune cele mai bune practici 18

Cum să cuantifici succesul într-un proiect MLOps? 20

Vorbeș te aceeaș i limbă 22
Foloseș te fiecare proiect ca o oportunitate de a-ț i educa organizaț ia
despre Învăț area Automată 22
Definirea unui Obiectiv Comun Clar ș i Metrici 22

Exemplu din viaț a reală - Povestea a două companii 25

Compania 1 25
Compania 2 26
Învăț ături26
Lanț ul de instrumente MLOps 28
Model ș i explorarea datelor 28
Metrici ș i Optimizarea Modelului 31
Producț ionalizare - Linii de producț ie End-to-End 35
Producț ionalizare - Magazine de caracteristici 39

Testing 43
Implementare ș i Inferenț ă 46

Concluzie 50

Despre autori 52
 De ce contează MLOps? 3

De ce contează MLOps? (Prefaț ă)

În mod tradi ț ional, învă ț area automată a fost abordată din
o perspectivă asupra experimentelor ș tiinț ifice individuale care sunt
în principal realizată în izolare de către oamenii de ș tiinț ă în domeniul datelor. Totuș i,

pe măsură ce modelele de învă ț are automată devin parte a solu ț iilor din lumea reală

ș i esenț ial pentru afaceri, va trebui să ne schimbăm perspectiva, nu

pentru a deprecia principiile ș tiinț ifice, dar pentru a le face mai u ș or
accesibil, reproductibil ș i colaborativ.

În mai 2020, am sondat 330 de oameni de ș tiinț ă ai datelor, învă ț are automată

engineers and managers in a broad range of companies to ask what

ei s-au concentrat pe următoarele 3 luni ș i ce obstacole majore
la care s-au confruntat. Deș i 20% dintre respondenț i au spus că încă
concentrându-se mai mult asupra fazei de experimentare ș i învăț are, jumătate din
respondentii au spus ca sunt concentrati pe dezvoltarea de modele pentru
utilizarea în producț ie ș i peste 40% au declarat că îș i vor desfăș ura modelele

pentru producț ie.

Starea ML 2020, Valohai

330 de respondenț i

50%

40%

30%

20%

10%

0%
Colectează mai mult Stabileș te cum Să faci datele mai Învăț aț i maș ina Dovedeș te potenț ialul Dezvoltă modele Publică modele Optimizare automate Monitor
date datele pot fi accesibil învăț are de maș ină pentru producț ie în producț ie modele reformare model(e) în
folosit tehnologii învăț are foloseș te model(e) producț ie
4 De ce contează MLOps?

Automatizarea reantrenării modelelor ș i monitorizarea modelelor în producț ie

încă nu erau relevante pentru majoritatea respondenț ilor, ceea ce sugerează despre maș ină

învăț area în producț ie fiind relativ nouă pentru majoritatea. Totuș i,

interesul în continuă creș tere pentru MLOps bazat pe volumul de căutare ș i
articolele de ș tiri vorbesc despre aceste aspecte devenind din ce în ce mai mult

relevant. Modelele de producț ie ridică noi provocări, nu doar pentru date

oamenii de ș tiinț ă, dar echipa extinsă de ingineri, manageri de produs ș i
ofiterii de conformitate, care vor trebui să fie rezolvaț i în mod colaborativ.

În cele mai multe aplica ț ii din lumea reală, datele de bază se schimbă
constant ș i astfel modelele trebuie să fie reantrenate sau întregi procese
chiar trebuie reconstruite pentru a face faț ă derapajului de caracteristici. Afacerea ș i reglementările

cerin ț ele pot, de asemenea, să se schimbe rapid, necesitând o frecven ț ă mai mare

ciclul de lansare. Aici intervine MLOps pentru a combina operaț ional

cunoș tinț e despre învăț area automată ș i ș tiinț a datelor.

În învăț area automată, 2020 este anul modelelor de producț ie ș i noi

presupunem că 2021 va fi anul MLOps. Sperăm să vă bucuraț i
ebook-ul nostru despre MLOps ș i obț ineț i idei noi ș i proaspete pentru cazul dvs. de utilizare.
 Oamenii de învăț are automată 5

Oamenii Învăț ării Automate

Dimensiunea ș i domeniul proiectelor de învăț are automată din lumea reală au avut cu siguranț ă

a surprins majoritatea, dacă nu pe toț i. Ceea ce pare o sarcină simplă

de a aduna unele date, de a antrena un model ș i apoi de a-l folosi pentru profit
ajunge să devină o adâncă bursă de iepuri care se extinde de la afaceri ș i
operaț iuni pentru IT. Un singur proiect acoperă subiecte precum stocarea datelor,
securitatea datelor ș i controlul accesului, gestionarea resurselor, înalt

availability, integrations to existing business applications, testing,

reînvăț are ș i multe altele. Multe proiecte de învăț are automată ajung să
fiind unele dintre cele mai mari multidisciplinare ș i interorganizaț ionale
eforturile de dezvoltare cu care companiile s-au confruntat vreodată.

Pentru a înț elege natura multidisciplinară a proiectelor ML, începem

prin examinarea rolurilor implicate în acestea. Aceste roluri provin din
punctul nostru de vedere colectiv unic de a vedea aproximativ 500 de diferite

organizaț ii de la startup-uri la Fortune 500 în ultimii 4 ani. În timp ce

lista de roluri de mai jos nu este completă, oferă o imagine de ansamblu
al oamenilor implicaț i.

Amintiț i-vă că aceste roluri nu sunt neapărat unul per persoană, ci

mai degrabă o persoană singulară poate - ș i în organizaț ii mai mici adesea trebuie -
îndeplinesc multiple roluri. De exemplu, mulț i oameni de ș tiinț ă ai datelor gestionează ș i ML

Sarcinile de inginerie, ș i uneori DevOps ș i IT sunt sinonime.

Regula generală este că, cu cât organizaț ia este mai mare, cu atât este mai specializată.

iar persoanele izolate sunt cele care necesită ș i mai multă colaborare.

Data Scientist
Oamenii de ș tiinț ă ai datelor au sarcina de a găsi solu ț ii bazate pe date pentru

probleme de afaceri. Oamenii de ș tiinț ă în date tind să fie foarte bine pregătiț i cu

un titlu de master sau superior în matematică ș i statistică, informatică

ș tiinț ă sau inginerie. Punctele lor forte se află în manipularea datelor, statistică
analiză, vizualizarea datelor ș i aplicarea învăț ării automate.

În general, sunt desfăș uraț i mai întâi pentru a analiza datele existente ș i pentru a găsi
6 Oamenii în Învăț area Automată

modele care ar putea fi folosite pentru a rezolva problemele de afaceri fundamentale.

De exemplu, ar putea analiza datele utilizatorilor pentru a găsi semnificaț ii

segmente de utilizatori ș i construirea de modele care pot clasifica aceș ti utilizatori în

segmente pentru a diferenț ia experienț a utilizatorului final ș i a conduce

mai mult angajament. În timp ce scopul principal al ș tiinț ei datelor este să
explorează datele ș i construieș te modele, adesea o mare parte din timp este petrecută
manipularea datelor pentru a se potrivi cazului de utilizare.

Inginer de date
Inginerii de date sunt responsabili pentru infrastructura care asigură
datele sunt stocate ș i disponibile pentru oamenii de ș tiinț ă ai datelor. Ei construiesc sistemele

care ingerează datele brute din diverse surse ș i le stochează într-un sistem centralizat

lac de date. Inginerii de date construiesc adesea ș i alte depozite de date

care derivă date din lacul de date, dar le transformă astfel încât să fie mai
util pentru utilizatorul final; de exemplu, datele de imagine ar putea fi redimensionate ș i

reformatat astfel încât oamenii de ș tiinț ă de date să se poată concentra pe analiza datelor mai degrabă

decât manipularea datelor.

Inginer în Învăț area Automată

Inginerul de învăț are automată este un rol destul de nou care devine
din ce în ce mai relevant pe măsură ce companiile se străduiesc să ob ț ină valoare din lumea reală

din învăț area automată. În timp ce oamenii de ș tiinț ă de date explorează ș i dovedesc un

concept teoretic, inginerii ML iau aceste concepte ș i le construiesc

într-un sistem de scară industrială. Aș a cum sugerează titlul, inginerii ML
în ț eleg partea teoretică a învă ț ării automate, dar sunt mai
implicat în paradigmele întâlnite în inginerie, cum ar fi continuu
integrarea (CI) ș i livrarea continuă (CD). Acestea abordează automatizarea
ș i scalarea antrenării modelului, testarea modelelor înainte de desfăș urare ș i
implementarea ș i monitorizarea modelelor în produc ț ie. Adesea, acestea vor
rescrierea sau restructurarea codului scris de oameni de ș tiinț ă ai datelor; de exemplu,

transformarea notelor în scripturi.

Inginer DevOps
Inginerii DevOps combină domeniile ingineriei software
ș i infrastructura cloud. În proiectele tradi ț ionale de software, DevOps
 Oamenii învăț ării automate 7

manejează automatizarea în jurul testării ș i lansării de nou cod, ș i

de multe ori gestionează ș i medii de testare ș i de producț ie. În maș ină
proiecte de învăț are, DevOps poate fi conexiunea între ML
modelul ș i aplicaț ia pentru utilizatorul final; de exemplu, lansarea unui nou

motor de recomandări pentru o aplicaț ie web. Scalabilitate, stabilitate ș i

responsivitatea aplicaț iei pentru utilizatorul final este adesea în prim-plan
mintea lor ș i se vor implica în asigurarea învăț ării automate
modelele nu degradează aceste elemente.

IT
Operaț iunile IT pot fi găsite în majoritatea organizaț iilor mai mari. Ele sunt
în general, responsabil cu gestionarea resurselor, controlul accesului ș i
securitatea informaț iilor. Deș i adesea este percepută ca o birocraț ie, operaț iunile IT ș i

procesele implicate pot ajuta un proiect să decurgă mai bine, indiferent dacă

it’s through requesting that computing resources be provisioned or

asigurându-se că furnizorii externi sunt aprobaț i.

Antreprenor
Nu există un titlu specific pentru un proprietar de afacere în învăț area automată.
mediul, dar este un rol cheie pentru a asigura succesul. Proprietarii de afaceri
au cea mai profundă înț elegere a utilizatorului final ș i a cazului de utilizare, ș i

ghidaț i echipa să producă sisteme ML care nu sunt doar precise

ș i bine concepute, dar ș i valoroase. Ele vor ajuta la definirea ceea ce tip
predicț iile sunt utile ș i ajută la înț elegerea locului în care se află riscurile

dintr-o perspectivă operaț ională ș i de reglementare.

Manager
Rolul de management într-o echipă care lucrează cu învăț area automată tinde
a fi puț in neclar, deoarece aceste echipe tind să fie relativ noi. Cheia
aspectele de care trebuie să ț inem cont sunt că proiectele de învăț are automată sunt înș elătoare

complex ș i multidisciplinar. Toate resursele necesare pentru a executa

un proiect nu se află adesea într-o singură echipă ș i un manager trebuie să asigure

acestea din părț i diferite ale organizaț iei. O altă sarcină dificilă
pentru un manager este să înț eleagă ș i să comunice ROI-ul echipei
munca ca costuri ș i beneficii nu sunt probabil legate direct de echipă.
8 Cum este învăț area automată diferită de software-ul tradiț ional?

Cum este diferită învăț area automată

din software-ul tradiț ional?
Am stabilit deja că natura transdomenială a ML cauzează
un nou nivel de disciplină în organizaț ii, dar aceasta este doar o parte din
imagine. Există o dimensiune suplimentară care diferen ț iază ML
ș i software-ul clasic — date. Ar putea părea de la sine înț eles ș i
simplu, dar adăugarea de date, de obicei date mari, aduce un întreg nou
provocări în procesul de dezvoltare.

Deș i software-ul poate fi dezvoltat în general local cu aproape instantaneu

feedback cu privire la modul în care o modificare a codului afectează rezultatul final; în maș ină

învă ț area, pentru a vedea efectele unei schimbări de cod este necesară reantrenarea

un model. Atunci când lucra ț i cu modele care sunt antrenate cu date mari
seturi de date, acesta impune provocări uriaș e de infrastructură deoarece fie va trebui să

vei aș tepta mult, mult timp sau va trebui să foloseș ti calculul la distanț ă.
Imaginaț i-vă doar diferenț a dintre un dezvoltator de aplicaț ii care tocmai
salvarea unei modificări de cod ș i apăsarea refresh în browserul lor, ș i
un om de ș tiinț ă a datelor care salvează o modificare de cod similară ș i apoi rulează

un cluster de GPU-uri, implementarea codului, transferul de date ș i antrenarea unui

model înainte de a vedea rezultate.

Cu toate acestea, nu este vorba doar despre modul în care introducerea datelor schimbă modul în care codul

lucrează în procesul de dezvoltare, dar ș i că datele sunt un alt aspect

asta se poate schimba. În dezvoltarea software-ului clasic, o versiune a
codul produce o versiune a software-ului, în timp ce în învăț area automată,
o versiune a codului ș i o versiune a datelor împreună produc o
versiunea modelului ML.
 Cum se diferenț iază învăț area automată de software-ul tradiț ional? 9

Datele ca o nouă variabilă în procesul de dezvoltare cresc

complexitatea drastic, deoarece pentru a reproduce rezultatele trebuie să fii

capabil să reproducă datele pe care le-aț i folosit. Deș i s-ar putea să nu fiț i

producând fiecare variantă posibilă a modelului, componentele trebuie să

fi versionat pentru a asigura reproducibilitatea. Problema versionării atât
datele ș i codul devin din ce în ce mai complexe atunci când începi să gândeș ti
despre întregi sisteme de învă ț are automată care au pa ș i pentru date
preparare, augmentare ș i generare.
10 Fluxul de lucru MLOps

Fluxul de lucru MLOps

Care este scopul MLOps?
Este posibil să fi descărcat această carte pentru că ș tiț i în mod intuitiv
că MLOps este esen ț ial. Această intui ț ie provine, fără îndoială, din
urmărirea de a face lucrurile în mod corect ș i simț irea durerii constante
lupta tehnică în munca de zi cu zi.

Totuș i, intuiț ia singură poate fi greu de contestat atunci când vorbeș ti cu

coechipierii caută aprobat pentru o investiț ie – de timp sau bani.

This chapter solidifies the idea of MLOps to help understand why it is

merită să ne concentrăm asupra acestuia ș i cum să justificăm acest lucru. Capitolul va ajuta de asemenea

evaluează pe ce domenii să te concentrezi, iar capitolele următoare vor aprofunda

mai profund în moduri concrete de a măsura ș i a arăta ROI.

Când ne uităm la modul în care literatura actuală descrie un model

ciclul de viaț ă, adesea vedem o imagine ca aceasta:

Model
Design Operaț iuni
Dezvoltare

Cu toate acestea, în realitate, majoritatea organizaț iilor de astăzi funcț ionează încă într-un ciclu

unde sunt predările între dezvoltarea modelului ș i operaț iuni –

simplu spus - dezordonat ș i manual.

La fel de distractiv cum este dezvoltarea în vid (cu toț ii am făcut-o), realitatea
doar un model care rulează în producț ie poate aduce valoare. Modelele
au un ROI zero până când pot fi folosite. Prin urmare, timpul de lansare pe piaț ă ar trebui să

fii numărul unu metric pe care să-l urmăreș ti ș i să-l optimizezi pentru orice proiect ML.
 Fluxul de lucru MLOps 11

Timpul până la piaț ă

Model de 10%
Dezvoltare
Design Operaț iuni
90% Lipici
Codare

Complex
nestructurat
predare

Scopul MLOps este de a reduce fricț iunea tehnică pentru a obț ine
modelul dintr-o idee în producț ie în cel mai scurt timp
timp posibil de lansare pe piaț ă cu cât mai puț in risc posibil.

Să analizăm afirmaț ia. Aceasta conț ine două părț i, reducând

timpul de lansare pe piaț ă ș i reducerea riscurilor implicate. Aceste obiective ajută datele

oameni de ştiinţă şi părţile interesate din afaceri să vorbească aceeaşi limbă şi

încadraț i MLOps ca o necesitate dictată de afaceri. Deș i MLOps va ajuta

automatizaț i paș ii manuali ș i îmbunătăț iț i calitatea codului, dar ele sunt
nu obiectivele de bază în jurul cărora se va uni întreaga organizaț ie.

Următorul, vom vorbi despre risc ș i timpul până la lansare. Domeniul riscului

evaluarea este un concept mai simplu, aș a că să începem de acolo.

Riscul în Învăț area Automată

Scopul MLOps este de a reduce fricț iunea tehnică pentru a obț ine modelul
dintr-o idee în producț ie în cel mai scurt timp posibil de lansare pe piaț ă
cu cât mai puț in risc posibil.

Am identificat trei tipuri principale de riscuri în fluxul de lucru MLOps

tackles:

1. Pierdere de cuno ș tinț e

2. E ș ecuri în produc ț ie
3. Regulatorii ș i etica
12 Fluxul de lucru MLOps

Există o mul ț ime de industrie, implementare ș i chiar companie-

detalii specifice implicate în fiecare dintre aceste subiecte principale. Cu toate acestea,

riscurile cele mai semnificative pe care le introduce în producț ie învăț area automată
se încadrează într-una dintre aceste categorii.

Ț ineț i cont că sări peste riscurile IT de bază care sunt deja bine
documentat ș i acoperit în alte părț i, dar nu este exclusiv pentru maș ină
învăț area în producț ie; de exemplu, securitatea datelor. Este clar că nu-
cineva ar trebui să poată fura date din baza ta de date, dar asta este adevărat
pentru toate bazele de date – nu doar pentru cele folosite pentru învăț area automată.

Pierderea cunoș tinț elor

Doar eu ș tiu
cum să ne antrenăm
producț ie
models

Factor de autobuz

Factorul autobuzului este un termen comun în ingineria software care descrie

riscul ca un contributor cheie să dispară neaș teptat dintr-un proiect
– pentru că sunt loviț i de un autobuz. Deș i este o problemă bine documentată
pentru dezvoltarea de software clasic, învăț area automată amplifică
factorul de autobuz semnificativ.

În ML, în plus faț ă de codul care este adesea oarecum auto-documentat,

există date. Un singur set de date poate conț ine cantităț i uriaș e de informaț ii ascunse

informaț ii despre modul în care a fost colectată ș i apoi cum sunt caracteristicile
extras. Este posibil să existe multe versiuni ale caietelor sau scripturilor care

produca un singur set de date.

Pierderea cunoș tinț elor poate avea loc în multe moduri diferite. Cel mai evident
de un om de ș tiinț ă de date care părăseș te compania, iar majoritatea echipelor mai mari au

deja m-am confruntat cu asta. Dar poate apărea ș i fără schimbări de personal.
Când lucrezi la mai multe proiecte pe o perioadă mai lungă, te
 Fluxul de lucru MLOps 13

tindeț i să uitaț i detaliile despre propria dvs. muncă, de asemenea. Poate fi provocator

a reveni la un proiect vechi de ș ase luni ș i a reantrena un model fără

ruperea lucrurilor. Mulț i cititori pot avea modele existente care rulează că
le este teamă să se întoarcă de frica de a strica ceva.

Pentru dezvoltarea software tradiț ională, reproducibilitatea este în mare parte acceptată
îngrijit de instrumente de control al versiunilor dovedite, cum ar fi Git. Pentru a realiza o gestionare adecvată

controlul versiunilor ș i reproducibilitatea pentru ML, vei avea nevoie de puț in mai mult pe

în plus

Intrare Executare Ieș ire

Cod de antrenament hardware folosit Model

Parametrii Mediu Jurnale
Set de date Costul experimentului rezultate
Statistics

Controlul versiunilor pentru experimentele de învăț are automată

În ML, un model este o combinaț ie de cod, date, parametri ș i

mediu de antrenament. Pentru a prelua de unde a lăsat altcineva (sau tu însuț i acum ș ase

cu câteva luni în urmă) ai rămas cu un model, vei avea nevoie de mult mai mult decât doar un

Repozitoriu Git.

Trebuie să ș tii ce date foloseș te codul ș i cum au venit acele date

a fi. Adesea există mai multe scripturi care reunesc diferite
sursele de date ș i realizarea agregării caracteristicilor pentru a construi setul de date pe care îl

nevoie. Împreună piesele unui puzzle din mai multe scripturi ș i surse de date
altcineva a făcut, lăsând în urmă zero documentaț ie poate fi adesea
mai complicat decât doar a porni de la zero.

Pentru a aborda acest lucru, recomandăm un sistem de control al versiunilor care poate urmări

întreaga ta linie de procesare de la datele brute la model, inclusiv codul tău,

mediu, configuraț ii ș i parametri.

Defecț iuni în producț ie

Următoarea categorie de risc este eș ecurile în producț ie. Toț i cei care au
cei care au lucrat în dezvoltarea software-ului ș tiu că livrarea de cod defect este
14 Fluxul de lucru MLOps

to production is a prevalent failure point for systems. Teams spend

timp extensiv investit în crearea de pipeline-uri CI/CD pentru ca dezvoltatorii
poate fi încrezător că ultima lor actualizare nu rup nimic în
producț ie.

Acelaș i lucru se aplică ș i ML. De la erori de sintaxă de bază până la modificări în

fluxul de date sau performanț a modelului neaș teptată.

Într-o lume perfectă, nu doar că instrumentele tale MLOps sprijină diverse

metode de testare a codului ș i datelor de-a lungul întregului flux, dar
ai adoptat de asemenea o practică de a începe să codifici aceste teste, începând
din faza de proiectare a unui proiect ML.

Vom acoperi diferite părț i ale fluxului de lucru ML ș i testarea aferentă

în capitolele ulterioare ale cărț ii, dar iată câteva indicaț ii generale pentru
ai grijă de.

1. Asigura ț i-vă că datele utilizate pentru a antrena un model arată a ș a cum v-a ț i a ș teptat

pot fi. Este posibil să existe modificări în sus, de exemplu, cum sunt datele

este colectat sau stocat.

2. Asigura ț i-vă că modelul func ț ionează nu doar în timpul antrenării, ci ș i în lumea reală

mediu. Suprainvăț area este un risc real care ar trebui să fie abordat de
conducta ș i procesul tău.

3. Asigura ț i-vă că infrastructura func ț ionează în mod constant. Pipeline-ul dvs. ML

ar trebui să producă rezultate identice dacă intrările rămân aceleaș i, ș i
ar trebui să poț i întotdeauna să revii.

Regulatoriu ș i Etic
Algoritmii de învă ț are automată se supun unor reglementări severe ș i
examinare etică din cauza faptului că nu este definită în mod explicit de o persoană.

Când sunt realizate, consecinț ele pot fi financiare, dar poate chiar mai mult.

prevalent este pierderea încrederii ș i reputaț iei.

Prin urmare, un om de ș tiinț ă a datelor ar putea fi interesat de guvernanț a frecventă

audituri, făcând multe persoane nervoase. Impunerea celor mai bune practici în MLOps
 Fluxul de lucru MLOps 15

practica face reproducibilitatea o prioritate ș i introduce versiunea

control pentru fiecare componentă a unui model de învăț are automată. Gândeș te-te la

aceasta ca contabilitate, ș i când cărț ile sunt în ordine, nu este nimic de

îngrijora. Cel mai important, dacă o predicț ie a unui model de producț ie are
servit devine o problemă, se poate întotdeauna reveni la modul în care
modelul a fost antrenat.

Cele mai multe instrumente MLOps vor introduce controlul versiunilor în fluxul tău de lucru,

dar aceasta este doar jumătate din bătălie în minimizarea riscului reglementar. A doua
jumătate este asigurarea că modelele de produc ț ie nu sunt părtinitoare, iar asta este

în general, mult mai dificil, deoarece uneltele pot oferi doar un cadru, dar
Expertiza în domeniu este necesară pentru a aplica regulile corecte.

Un model prejudiciat probabil nu va e ș ua dintr-o perspectivă tehnică,

dar s-ar putea din perspectiva reglementării. Prin urmare, bazându-ne pe
teste tehnice prin includerea testelor care combat biasul ș i alte aspecte etice
îngrijorările trebuie luate în considerare într-un pipeline ML Aceste îngrijorări

variază foarte mult în funcț ie de aplicaț ie; de exemplu, un sistem de sănătate

aplicaț ia va avea preocupări etice foarte diferite faț ă de o financiară
aplicaț ie.

Deș i MLOps nu poate rezolva partialităț ile modelului, vine cu noț iunea că
aceste îngrijorări ar trebui abordate prin codificarea testelor pentru acestea în
o conductă de învăț are automată. Puncte de control ș i măsuri de siguranț ă pentru modul în care

datele folosite pentru antrenare ar trebui să arate ș i ce predicț ii sunt aș teptate

ar trebui să facă auditurile de guvernanț ă mult mai puț in intimidante. Toate

modelele de producț ie vor fi produse în conformitate cu stabilitatea
ș i reguli fiabile.

Timp pentru Piaț ă

Este greu de învins un flux de lucru ad-hoc în ceea ce priveș te viteza de a ajunge pe piaț ă atunci când eşti primul.

dezvoltarea unui model de învăț are automată. Pentru mulț i economiș ti de date ș i

inginerii, acesta este motivul pentru care sunt ezitanț i să adopte rigurozitatea în
proces. Cu toate acestea, în producț ie, învăț area automată este rar despre o
versiunea unică a unui singur model intrând în producț ie, ci mai degrabă un
angajament pe termen lung pentru construirea capacităț ilor de învăț are automată care
16 Fluxul de lucru MLOps

se dezvoltă continuu.

În cele mai multe cazuri, ai o mulț ime de dimensionalitate în construirea modelului.

În primul rând, modelele rareori funcț ionează pe termen lung ș i tind să necesite
reînvăț are oarecum regulat. În al doilea rând, există adesea mai multe alte
dimensiuni de care să ț inem cont. Este comun ca modelele să fie, de exemplu,
reantrenat pentru fiecare client pe baza datelor lor specifice sau în funcț ie de apartenenț a geografică,

etc. Aceeaș i arhitectură de model poate fi utilizată în producț ie ca

mai multe versiuni ale mai multor seturi de date sunt reînvăț ate periodic
în timp. Aceasta duce rapid la retraining exponential ș i ad-hoc
fluxurile de lucru vor duce rapid la haos, nemulț umirea clienț ilor, ș i
rezultate slabe. Pentru a obț ine un model de afaceri cu adevărat scalabil în jurul ML, de obicei

necesită să te retragi ș i să îț i pui produsul în termenii

pipeline în locul unei singure instanț e a unui model antrenat. Iată unde
cele mai de succes companii în ML sunt astăzi.

Model

Client 1 Customer 2

Sursa de date 1 Data Source 3 Sursa de date 1 Sursa de date 3

Time 1 Time 2 Time 3 Sursa de date 2 Time 1 Time 2 Time 3 Time 1 Time 2 Time 3 Sursa de date 2 Time 1 Time 2 Time 3

Time 1 Time 2 Time 3 Time 1 Time 2 Time 3

18 modele instruite
 Fluxul de lucru MLOps 17

În linii mari, există două moduri în care MLOps ajută la accelerare

timpul de lansare pe piaț ă al învăț ării automate:

1. Creează un limbaj comun între echipa extinsă.

2. Automatizează sarcini manuale.

Limba comună
Am observat o creș tere drastică a vitezei de livrare a dezvoltării software.
ș i rata de-a lungul anilor. Instrumente moderne ș i metode de lucru comune
(CI/CD, controlul versiunilor, microservicii) au permis companiilor să
să îș i scaleze prinputerea în dezvoltarea software-ului exponenț ial.

O limbă comună permite noilor membri ai echipei să înceapă rapid

alergând atunci când trebuie să accelerezi dezvoltarea ta. Există foarte
puț in pentru a sugera că aceleaș i cerinț e pentru livrarea exponenț ială
creș terea nu s-ar menț ine nici pentru învăț area automată.

În al doilea rând, aș a cum am discutat anterior, MLOps se învârte în jurul transformării

procesul de creare a unui model într-un pipeline de învă ț are automată. Pentru
pentru a realiza acest lucru, echipele trebuie să codeze ș i să structureze munca lor.

În timp ce necesită un efort suplimentar comparativ cu un singur caiet ș i ceva

acț iuni manuale, împărț irea muncii în componente permite scalarea muncii în
o modalitate complet diferită. Aceasta este foarte similară cu ceea ce fac microserviciile

au realizat în proiecte de dezvoltare mai mari.

Un singur om de ș tiinț ă a datelor nu trebuie să creeze întregul model, dar

mai degrabă o echipă poate lucra pe piese separate, cum ar fi preprocesarea datelor,
antrenarea ș i testarea modelului. Pe măsură ce complexitatea creării modelului

creș te, la fel ș i beneficiile de a lucra în jurul unui pipeline comun.

De asemenea, o linie de procesare constând din diverse fragmente de cod este în mod inerent auto-

documentare - într-o oarecare măsură - ș i poate fi oferit mai uș or

persoana următoare decât acț iunile manuale.

Automatizare
DevOps a permis dezvoltatorilor de software să treacă de la o lună
18 Fluxul de lucru MLOps

sau un ciclu de lansare trimestrial la un ciclu zilnic sau săptămânal. În ciuda

complexităț ile pe care le-am explicat mai sus cu învăț area automată conț in
mai multe variabile decât doar cod, ar trebui să ne asigurăm totuș i un progres optim.

Construirea unei pipeline CI/CD pentru învăț area automată este mai provocatoare
decât pentru software-ul tradiț ional, dar aceleaș i beneficii se aplică. Automatizarea

colectarea datelor, antrenarea ș i evaluarea modelelor permite cel mai mult

resurse rare, adică specialiș ti în ș tiinț a datelor, pentru a-ș i concentra eforturile pe continuare

dezvoltare. Aceste ț evi nu sunt nici ele de aruncat, deoarece poț i re-
folosiț i părț i atunci când dezvoltaț i un model pentru un scop diferit.

Din nou, importanț a variază în funcț ie de aplicaț ie, deoarece beneficiul unei soluț ii mai rapide

ciclul de lansare nu este acelaș i în diferite cazuri de utilizare. Cu toate acestea, în

în cele mai extreme cazuri, modelul tău trebuie să fie actualizat tot timpul
pentru a ț ine pasul cu ritmul în care datele fundamentale se schimbă.
Aceasta este un motiv pentru care unele companii inovatoare, cum ar fi Facebook
ș i Uber a construit propria infrastructură MLOps înainte ca termenul să existe
a fost chiar inventat.

Timp până la lansare

Model
Design Operaț iuni
Dezvoltare

Controlul Versiunilor
Conducte
Testare
Automatizare

Fluxul de lucru MLOps impune cele mai bune practici

MLOps leagă dezvoltarea modelului ș i opera ț iunile împreună într-un
o buclă continuă printr-un set de bune practici. Aceste bune practici
poate fi impus în multe moduri, cel mai frecvent printr-o împărtăș ire
platformă. Pentru a rezuma rapid, am identificat patru bune practici care
te va ajuta să reduci fricț iunea tehnică pentru a transforma modelul dintr-o idee
 Fluxul de lucru MLOps 19

în producț ie în cel mai scurt timp posibil pentru piaț ă, cu cât mai puț in
riscuri posibile.

•Versa ț i totul, inclusiv modele, cod, date,

parametrii ș i mediu. Permite oricui să urmărească modul în care un model
a fost produs.

•Componentează pa ș ii procesului de creare a modelului ș i construie ș te

le într-o conductă. Un singur caiet nu este o conductă.

•Codifica ț i testarea. Cu puncte de control ș i măsuri de siguran ț ă implementate, există

o normă la care modelele trebuie să adere.

•Automatizează munca pentru a cre ș te timpul care poate fi petrecut în viitor

dezvoltare.
20 Cum să cuantifici succesul într-un proiect MLOps?

Cum să cuantifici succesul într-un

Proiect MLOps?
Cantificarea succesului nu este doar despre succesul afacerii
rezultat. În această etapă a maturităț ii MLOps, este de asemenea despre succes
al procesului, inclusiv colaborarea multidisciplinară ș i
documentaț ia învăț ării.

„Numai un model care este în producț ie poate aduce

valoare.

Pe măsură ce trecem de la proiecte care experimentează cu învăț area automată

la proiecte care au ca scop aducerea unei valori reale de afaceri în producț ie

sisteme, cre ș tem complexitatea proiectului. Odată cu aceasta,
incertitudinea succesului creș te. Iată trei paș i pentru a începe:

1. Define ș te-ț i obiectivul ș i măsurile clare, concrete ș i măsurabile

cu toț i factorii relevanț i

Asigura ț i-vă că toată lumea în ț elege „ de ce” din spatele proiectului ș i

beneficiile aș teptate pe care le va aduce ș i a educa pe toată lumea cu privire la

bazele pe care va fi evaluat proiectul ML. Toată lumea

ar trebui să cunoască elementele de bază ale modului în care poate fi acurata unui model

măsurat ș i ce este supra- / sub-învaț are.

•Documentează ș i împărtă ș eș te cum se desfă ș oară în prezent munca ș i

evaluat în cadrul echipei ș i ce va fi necesar pentru a înlocui

modul actual de lucru.

Identifică presupunerile pe care le au diferi ț i membri ai echipei

by hosting a session to discover pre-conceptions about the

problemă ș i găsi ț i posibile solu ț ii. Presupozi ț ii
ar putea fi legate de, de exemplu, ce surse de date ar trebui să fie
utilizat, cum ar trebui prelucrate datele sau cum ar trebui modelul
ar trebui publicată. Încerca ț i să dezvălui ț i aceste presupuneri ș i
explora experimente mici pentru a testa ipotezele înainte de
considerându-le ca fiind fapte.
 Cum să cuantifici succesul într-un proiect MLOps? 21

2.Măsura ț i succesul diferitelor etape ale proiectului - nu doar

rezultatul final

Va fi greu să estimăm timpul total necesar pentru livrare

pe întregul proiect MLOps, ș i adesea este greu de justificat
the costs of a project that might take 6 or 12 months before we
poate determina succesul acestuia.

Asigură-te că î ț i împar ț i proiectul în păr ț i mai mici pentru a valida.

presupunerile tale, urmăreș te progresul tău ș i adună feedback.
Vechea zicală „ Împingeț i către ‘ producț ie’ adesea ș i itera ț i cu
feedback” se aplică ș i aici. Nu spunem să săriț i peste lung-
angajament pe termen lung, dar în schimb ar trebui să arăț i progres,
de exemplu, la fiecare ș ase săptămâni sau cam aș a ceva.

Pe măsură ce treci prin diferitele etape ale proiectului, asigură-te că

reflectezi asupra progresului tău ș i dacă te îndrepț i în

direcț ia corectă pentru a rezolva problema iniț ială. Nu te teme
pentru a reveni la definirea problemei. Documenta ț i lec ț iile
ai învăț at ș i le-ai aș ezat într-un Wiki intern pentru alț ii
echipe de la care să învăț i. Aceste lecț ii ar putea fi despre date interne

politica de acces, procese interne pe care nu le-ai identificat în

începutul, sau limitările infrastructurii tale.

3. Ave ț i o echipă multidisciplinară cu roluri ș i responsabilită ț i clare

Ca parte a metricelor tale de succes, ar trebui să măsori cât de bine

echipa ta lucrează împreună. Având o abordare multidisciplinară
echipa virtuală pentru proiectul MLOps vă va permite să eficientizaț i
abordează blocajele surprinzătoare care vor apărea din diferite părț i ale
organizaț ia ta.

Asigura ț i-vă că toată lumea în ț elege rolurile celorlal ț i

responsabilităț ile în acest proiect. Având această claritate, va ajuta pe
echipa colaborează ș i merge înainte - nimeni nu este „barierele administrative”

cu intenț ie.

•Implică IT-ul din timp - au fost aici o vreme ș i au o

infrastructură matură pe care te poț i baza.

•IT va dori ca modelul tău să fie automatizat (de exemplu, automatizat

22 Cum să cuantifici succesul într-un proiect MLOps?

preprocesare, antrenare, construire ș i implementare

IT-ul este de obicei bine informat cu privire la conformitatea datelor ș i accesul acestora.

Vorbeș te aceeaș i limbă

Fluxul de lucru al unui om de ș tiinț ă de date ar putea consta în extragerea de date dintr-un

bază de date internă, explorând cu acele date, dezvoltând un model, ș i

salvându-l în stocarea cloud de unde alț ii îl pot folosi.
criteriile de succes ale modelului ar putea consta în principal în evaluarea modelului

metrice (de exemplu, acurate ț e, precizie, rechemare) bazate pe afacere

specificaț ia iniț ială a proprietarului.

Punerea asta în producț ie cel mai probabil nu se va întâmpla prin copierea

transferaț i fiș ierele model pe serverul de producț ie. În majoritatea organizaț iilor,

calea către producț ie va fi gestionată de departamentul IT (sau Ops),

care există de ceva vreme ș i are o infrastructură matură
cu practici stabilite. Ei vor presupune că poț i automatiza
majoritatea (dacă nu chiar toate) paș ii din fluxul dvs. de lucru ML, de la re-antrenarea modelului

cu date noi, pentru a le compara cu modelele existente ș i a le publica în

producț ie.

Foloseș te fiecare proiect ca pe o oportunitate de a educa

Organizaț ia dumneavoastră despre Învăț area Automată
Indiferent de preferinț a ta: întâlniri la nivel de companie, întâlniri publice sau

cafea slabă, asigură-te că împărtăș eș ti învăț ătura din învăț area ta automată
proiecte la nivelul organiza ț iei. Acestea pot fi fie de nivel înalt
subiecte sau detalii esenț iale despre cum echipele organizaț iei tale trebuie să
colaboraț i pentru a permite o colaborare eficientă în proiectele MLOps.

Proiectele MLOps vor continua să necesite contribuț ii dintr-o gamă mai largă
o varietate de profesioniș ti în organizaț ia ta. Nu aș tepta până în ultima
minute pentru a educa personalul dvs. despre procesul MLOps.

Definiț i un Obiectiv Comun Clar ș i Metrici

După ce ai descoperit presupunerile, asigură-te că le notezi ș i
 Cum să cuantifici succesul într-un proiect MLOps? 23

împărtăș iț i obiectivul proiectului ș i metricile individuale utilizate pentru a urmări

succesul său în cadrul echipei virtuale.

Presupuneri

De ce există acest proiect?

Ce a declanș at începerea acestui proiect
ca un proiect de învăț are automată? Care este
aș teptare în afaceri?

Cum este măsurată performanț a astăzi?

Împotriva a ce ne măsurăm? Este
obiectivul nostru este de a îmbunătăț i un proces existent, sau
să augmentăm sau să automatizăm un proces manual?

Cum va fi modelul implementat

consumat?
Modelul va fi accesibil publicului?
ca un punct final HTTP? Sau accesul va fi
fi limitat ș i modelul consumat doar de
servicii interne?

Cine deț ine datele?

Unde este stocată datele ș i cum va fi aceasta
accesat? Cât de des sunt actualizate datele?

Criterii de succes

Fiecare organizaț ie ș i fiecare Când definiț i metricii pentru dvs.

proiectul va avea propriul său custom criterii de succes, gândeș te-te la:
metrice.
• Care este metrica cheie care va
Ai putea să te concentrezi pe îmbunătăț ire determină dacă modelul poate fi luat
procese existente sau augmentare în producț ie?
un proces manual, sau complet • Cum va fi modelul dus la
automatizându-l. producț ie?
• Cât de des va trebui modelul să
Indiferent ce faci, asigură-te că fii actualizat?
ai enumerat rezultatele (nu • Metriș ii modelului (de exemplu, acurateț e,

echipa ta virtuală ar trebui să precizie, revenire

urmăreș te ș i ce numere ar trebui să fie • Costul de întreț inere ș i actualizare a
ajuns. model (ș i pipeline)
• Consideraț ii etice
24 Cum să cuantifici succesul într-un proiect MLOps?

Criterii de succes

Care este minimul viabil • Acurateț ea modelului x pentru a putea testa

produs? într-un mediu sandbox
Defineș te minimul necesar care • Antrenează, construieș te ș i desfăș oară manual
va fi necesar să testăm modelul. conducta.
Acest lucru te va ajuta să împarț i proiectul
în bucăț i mai mici ș i „ajunge la o
numărul mai repede.

Metrice MLOps • Frecvenț a actualizării modelului îndeplinită (ș i

Aici veț i găsi câteva informaț ii suplimentare capabil să identifice modele învechite
metrici pe care ai putea să le iei în considerare • Timpul de a reantrena ș i desfăș ura un nou
pentru proiectul tău MLOps. modelează ș i împinge în producț ie
• Performanț a punctului final al modelului pentru
predicț ii online (de exemplu, răspuns)
timp în ms)
• # de apeluri / % de apeluri eș uate către
endpoint de model
• Colaborarea între multi-
echipă disciplinară (de exemplu, date
oameni de ș tiinț ă, ingineri, IT-Ops, juridic,
afacere)
• Participarea părț ilor interesate cheie
la actualizări regulate ale proiectului (pentru
exemplu, la fiecare ș ase săptămâni)
• Infrastructura se scalează la maș ină
echipe de învăț are fără manual
lucrează în IT.
 Exemplu din viaț a reală - Povestea a două companii 25

Exemplu din viaț a reală - Povestea lui

Două companii
Exemplele prezentate sunt fictive, dar ilustrează modele care
am văzut repetat de-a lungul celor cinci ani trecuț i.

Compania 1

Colectaț i date Antrenează modelul Implementaț i modelul

Caută pentru pre-

sursa anterioară Colectează date Antrenează modelul Dezvoltare model
le

Află cum
Caută pentru pre- Îț i dai seama cum
Încercaț i să vă antrenaț i Antrenează modelul
a desfăș ura pe un
sursa anterioară Colectează date a antrena modelul Deplasaț i modelul
model clustere scalabile
les pe GPU cloud
ter

Schimbă cariera

Compania 1 se apucă direct de treabă ș i începe să adune ș i

analizând date. Ș eful lor de ș tiinț ă a datelor dezvoltă un model în Jupyter
notebook pe laptopul lor. Modelul este ulterior implementat în
producț ie de către un inginer DevOps dintr-o altă echipă. De la idee la
în producț ie, timpul de livrare este extrem de rapid.

Dar problemele încep pe măsură ce timpul trece; feedback-ul utilizatorilor arată că

predic ț iile pe care le produce modelul devin din ce în ce mai slabe. Poate că

Datele de bază s-au schimbat, iar modelul trebuie să fie reantrenat.

Cu toate acestea, prima dată a fost prost documentată ș i realizată.
în principal pe un singur computer. Este greu să reproduci toț i paș ii pe care îi
a necesitat timp pentru a antrena modelul – dar se finalizează.
26 Exemplu din lumea reală - Povestea a două companii

Compania desfăș oară acelaș i exerciț iu de stingere a incendiilor de mai multe ori.

timpuri cu variaț ii diferite. Ș eful echipei de ș tiinț ă a datelor a plecat

compania, iar o mare parte din munca pe care o făceau la computer a fost pierdută. The

antrenamentul modelului a devenit prea lent pentru a se finaliza pe o maș ină locală, ș i

Oamenii din DevOps au trebuit să intervină pentru a rezolva cum să antreneze modelul pe

maș ini GPU în cloud.

În cele din urmă, compania decide să implementeze unelte pentru automatizare

reînvăț are ș i desfăș urare, ș i în acest moment, totul este reconstruit.

Compania 2

Selectare unelte Construieș te conducta Colectaț i date Antrenează modelul Evaluaț i modelul Implementaț i modelul

Automatizaț i

Compania 2 recunoaș te că modelele de învăț are automată vor fi esenț iale

activele în viitor ș i decid să adopte instrumente axate pe ML înainte
trecând peste prima dovadă de concept de succes. Echipa petrece un
luna în avans în selectarea tehnologiilor, înlocuind paș ii manuali (cum ar fi
colectarea de date) cu scripturi ș i construirea unui pipeline de la început până la sfârș it.

În timp ce Compania 2 este mai lentă în livrarea iniț ială, beneficiile încep să

se compune rapid. Totul este reproducibil automat, ș i

oamenii de ș tiinț ă ai datelor se pot concentra pe dezvoltarea ulterioară decât pe

stingere a incendiilor.

Învăț ăminte
Aceste două poveș ti ilustrează de ce nu recomandăm să luăm în considerare ML
flux de lucru ca o reflexie ulterioară. Este o eroare să crezi: "Pur ș i simplu nu suntem
încă.” Momentul potrivit pentru a considera instrumentele ș i fluxul de lucru este atunci când

primul data scientist este angajat, nu când primul model merge la

producț ia sau predicț ia serveș te întreruperi pentru a n-a oară.
 Exemplu din viaț a reală - Povestea a două companii 27

Construirea unui flux de lucru ML necesită un angajament strategic

ș i investiț ii din partea companiei. Cu toate acestea, nu credem că o gestionare
echipa îș i poate permite să nu susț ină oamenii de ș tiinț ă de date cu anticipaț ie în

peisajul actual. Expertiza în învăț area automată este foarte căutată ș i

vine cu un preț piperat ș i ar fi iresponsabil să iroseș ti
orice parte dintre asta.
28 Toolchain-ul MLOps

Chaină de unelte MLOps

În acest capitol, vom explora ceea ce numim lanț ul de instrumente MLOps.
scopul este de a examina domeniile de MLOps de care este probabil să ai nevoie de uneltele

pentru ș i cum ar trebui să lucraț i cu ele. Există multe moduri de

creează-ț i propriul set de unelte MLOps, fie că achiziț ionezi o platformă
care acoperă majoritatea, dacă nu toate, nevoile tale, foloseș te câteva mai specializate
instrumente în combinaț ie sau construieș te ceva personalizat folosind sursă deschisă

unelte.

În timp ce acest eBook nu oferă recomandări directe pentru instrumente, noi

încerc să te ajut să fii mai bine informat pentru a face alegeri corecte ș i,
mai important, profită la maximum de instrumentele pe care le alegi.

Model ș i Explorarea Datelor

Explorarea este primul pas concret ș i practic în orice învăț are automată
proiect. Astfel, este cel mai familiar pas ș i unul care domină
educaț ie, competiț ii ș i alte proiecte de hobby. Pentru mulț i date
oamenii de ș tiinț ă, pasul de explorare este analog cu învăț area automată
proiect. Acest lucru duce adesea la confuzie când un proiect avansează la
produse ș i implementare, deoarece necesită instrumente diferite ș i
mentalitate.

Explorarea Datelor
Fără date, nu poate exista un model, aș a că explorarea datelor precede
explorarea modelului într-un mod destul de natural.

Scopul explorării datelor este de a înț elege datele. Calculatoarele

în mod natural, deț ineț i toate datele într-un format tabular, ceea ce nu este natural pentru noi.

O tabelă brută de două milioane de rânduri nu este interfaț a optimă pentru oameni.

înț elegere. Suntem foarte buni la citirea lumii în termeni de forme,

dimensiuni ș i culori în schimb. Pentru a înț elege trăsăturile unui singur
pentru a înț elege o variabilă sau relaț iile sale cu alte variabile, este necesar să aibă uneltele

a analiza datele vizual. În ț elegerea datelor duce, de asemenea, la

transformarea ș i procesarea datelor în caracteristici de nivel superior, care
 Chaină de instrumente MLOps - Explorarea modelului ș i a datelor 29

devin valoros în etapa de explorare a modelului.

Explorarea datelor are cele mai scăzute cerinț e din punct de vedere tehnic ș i

Punctul de vedere DevOps. Iteraț ii rapide ș i feedback vizual sunt

componente critice pentru munca de explorare a datelor. Jurnalele sunt o
potrivire naturală datorită capacităț ii lor de a combina codul, vizualizarea ș i rapiditatea

cicluri de iterare ca niciun alt instrument de acolo. Multe dintre caiete

pentru ca acest pas să se încheie ca obiecte de aruncat. Valoarea este în
perspective ș i descoperiri pe care le-au oferit, fără a păstra
mediul care le-a produs. Reproducibilitate, bibliotecă
dependenț ele ș i controlul versiunilor pot aduce o anumită valoare, dar sunt adesea

nu este o cerinț ă strictă.

Explorarea modelului
Explorarea modelului poate suprapune cu explorarea datelor, dar poate fi
considerat ca un pas separat. În timpul etapei de explorare a modelului,
omul de ș tiinț ă în domeniul datelor explorează viabilitatea diferitelor modele, cum ar fi regresia,

arbore de decizie sau pădure aleatoare pentru problema în cauză. Alegând

modelul necesită adesea ca omul de ș tiinț ă de date să încerce ș i să caute optimal
parametrii (cunoscu ț i ș i sub denumirea de hiperparametri) în cadrul modelului.

Există instrumente pentru a găsi automat modelele ș i parametrii optimi

(AutoML). Totu ș i, ele tind să nu func ț ioneze bine pentru cazuri mai complicate

proiectele ș i adesea nu sunt viabile deloc pentru cazurile de învăț are profundă.

Explorarea modelului are cerinț e mai mari din partea tehnică ș i

Punctul de vedere DevOps este mai important decât explorarea datelor. Notele unice sunt încă

adesea folosit, dar dependenț a de biblioteci terț e, experiment

reproducibilitate, infrastructură de calcul scalabilă ș i control al versiunilor
devine mult mai valoroasă. Explorarea datelor poate fi de obicei
finalizat pe un laptop local; pasul de explorare a modelului are mult mai multe

cerin ț e computa ț ionale. Testarea viabilită ț ii unui model cu un

un set singur de parametri poate dura uneori ore, dacă nu zile.
un mediu cloud auto-scalabil devine în curând o cerinț ă strictă
pentru un lucru eficient. Explorarea modelului costă atât timp, cât ș i bani,
a ș a că controlul versiunilor ș i reproducibilitatea sunt esen ț iale pentru toate

experimente.
30 Toolchain-ul MLOps - Explorarea Modelului ș i a Datelor

Explorare ș i MLOps
Considerând explorarea ca un pas separat de aruncare ș i nu un
o parte a pipeline-ului MLOps este periculoasă. Creează un decalaj între
oamenii de ș tiinț ă ai datelor ș i inginerii tăi. Oamenii de ș tiinț ă ai datelor vor explora pur ș i simplu

ș i să producă notebook-uri enorme ș i neordonate de dovadă a conceptului ș i să se aș tepte

inginerii să facă restul, practic reinventează roata. Având o

pipeline unificat pentru oameni de ș tiinț ă ș i ingineri de date pentru a trece de la

primul experiment până la modelul final produsificat este esenț ial. Unificat
platforma pentru toate etapele proiectului creează un limbaj comun ș i
understanding from start to finish.

Concluzii esenț iale

[Link] datelor este o sarcină u ș oară, offline, pentru a în ț elege

date folosind vizualizarea

2. Explora ț ia modelului are cerin ț e mai mari pentru puterea de calcul

ș i controlul versiunilor

3. Deconectarea explorării ș i MLOps înseamnă deconectarea datelor.

oameni de ș tiinț ă ș i ingineri
 Instrumentul MLOps - Metrici ș i Optimizarea Modelului 31

Metrici ș i Optimizarea Modelului

În sec ț iunea anterioară, am discutat despre capacitatea de a vizualiza ș i
explorează datele ș i modelele asociate. Aici, luăm în considerare cum să evaluăm

modele diferite ș i identificarea eficientă a celor mai bune modele

pentru producț ie. În special, cum ar trebui să fie hyperparametrii de
model ales?

Metricile sunt cantită ț ile care definesc succesul sau e ș ecul

un model. Câte tranzac ț ii frauduloase cu cardul de credit vor fi
identificat înainte de a fi aprobat? Câț i spectatori vor răspunde la
o reclamă dată? Cât va costa achiziț ionarea oț elului în ș ase
luni?

Definirea metrilor este doar jumătate din bătălie, însă. Înainte de a pune o
pentru a pune modelul în producț ie, scientistul de date trebuie să găsească un model care

satisface aș teptările de performanț ă necesare pe metrici cheie. A

performan ț a modelului este puternic influen ț ată de hiperparametrii săi
(numite ș i parametri liberi) cum ar fi rata de învăț are, nodurile pe strat sau
numărul maxim de estimatori.

Vocabular de optimizare
În ingineria software (algoritmi), optimizarea unei func ț ii înseamnă
rescrierea pentru a fi mai rapidă sau mai mică, ceea ce este un lucru complet diferit
ș i uneori cauzează confuzie.

În ș tiinț a datelor (matematic), optimizarea unei funcț ii înseamnă modificarea

intrarea pentru a minimiza (sau maximiza) ie ș irea. O func ț ie de pierdere este

formula pentru eroarea modelului, ș i când cineva spune că sunt

optimizând funcț ia de pierdere, ei de fapt minimizează modelul’s
eroare.

Actul de optimizare a funcț iei de pierdere este adesea numit antrenament. În

antrenament, hrăneș ti modelul repetat cu date de antrenament, ajustându-l în
paș i mici, lucrând spre erori tot mai mici. Eroarea în timpul
antrenamentul se numeș te pierdere de antrenament.
32 Toolchain-ul MLOps - Metrici ș i Optimizarea Modelului

Seturi de date de antrenament/validare/test

Într-un mediu de producț ie, este obiș nuit să se împartă toate datele disponibile
în trei seturi de date diferite: seturi de date pentru antrenament, validare ș i testare.

Set de date

Set de date pentru antrenament Set de date de validare Set de date de test

60-95% 3-20% 2-20%

Aceste seturi de date sunt, de obicei, e ș antionate într-un fel stratificat, pentru a

reprezintă în mod constant întreaga populaț ie.

•Set de date de antrenament - Între 60-95% din datele disponibile. Folosit

pentru a calcula pierderea de antrenament pentru un model - minimizând antrenamentul

pierdere găseș te parametrii unui model (de exemplu, diviziunile pădurii aleatorii sau

greutăț ile reț elei neuronale).

•Set de date de validare - Între 3-20% din datele disponibile.

Utilizat pentru a defini metrici de validare pentru un model - optimizând
metricile de validare găsesc hiperparametrii unui model (de exemplu.
momentum/dropout SGD, frac ț iunea minimă de împăr ț ire RF, box SVM
constraint).

•Set de date de test - Între 2-20% din datele disponibile. Folosit pentru

calculează metricile de validare pe un set de date separat. După

tuning-ul modelului, oferă o estimare nepartinitoare a modului în care validarea

metricele vor funcț iona în producț ie.

Metricile de validare sunt instrumentul cheie în identificarea sistematică a

cele mai bune alegeri de hiperparametrii. Dacă hiperparametrii sunt ajusta ț i prin
minimizând pierderea de antrenament, modelul va fi probabil supraprejucit la
date de antrenament. Modelele vor fi mai capabile să se generalizeze la datele neobservate

când un set de validare separat este folosit pentru a alege hiperparametrii.

 Instrumentele MLOps - Metrici ș i Optimizarea Modelului 33

Metrici de Validare pentru Ajustare ș i Producț ie

Metricile de validare se numesc astfel pentru că ajută la validarea
performan ț a de produc ț ie a modelului. Aceste metrici ar trebui să

reprezenta succesul modelului în timp ce este utilizat. Ele pot

reflectă cele găsite într-o clasă de ML, sau pot fi complet unice
la un caz de afaceri specific. Mai jos, oferim câteva exemple.

Consideraț i un model de clasificare a imaginilor pentru identificarea vehiculilor ca

fie biciclete, maș ini, camioane sau altceva. O metrică simplă ar putea
fii fracț ia clasificărilor corecte (adică acurateț ea de validare). Dacă
acesta este destinat să fie folosit într-un vehicul pentru a ghida ș oferul, un lucru important

metrica ar putea fi fracț iunea de clasificări greș ite ale bicicletelor (pentru ciclist
siguran ț ă). Dacă acest model este implementat într-un peaj automat, poate fi corect

clasificarea camioanelor ar fi mult mai importantă decât altele

vehicule. Dacă modelul este folosit pentru deschiderea sau închiderea unei por ț i de securitate,

poate timpul de inferenț ă al modelului ar fi foarte important.

Optimizarea metrilor ș i a luării deciziilor

Pipelinesle de produc ț ie ML necesită optimizarea hiperparametrilor,
uneori numit ajustare de model, pentru a fi efectuat eficient astfel încât
modelele pot fi implementate într-un mod oportun. Din păcate, fiecare
alegerea hiperparametrilor necesită o nouă antrenare a modelului, care poate
face ajustarea modelului foarte costisitoare. În plus, metricile de validare aproape
întotdeauna lipseș te informaț ia despre gradient, ceea ce înseamnă că uneltele standard

utilizat pentru minimizarea pierderii de antrenament nu poate fi folosit pentru optimizarea

metrici de validare.

Optimizarea bayesiană este un instrument popular pentru ajustarea modelului: necesită

fără informaț ii de gradient, poate optimiza metrici zgomotoase ș i poate funcț iona

cu parametrii categorici (cum ar fi alegerea între Adam,

Adagrad ș i RMSProp). Structura de bază implică o itera ț ie
unde sunt sugera ț i hiperparametrii, metricile de validare sunt
compute, acele valori sunt raportate la bucla de optimizare, ș i
noii hiperparametri sunt sugeraț i pe baza acestor noi rezultate (pentru
continuă iteraț ia).
34 Instrumentul MLOps - Metrici ș i optimizarea modelului

În cele mai multe medii de producț ie, multiple metrici definesc succesul.
exemplu de viziune computerizată anterior, modelul poate necesita să echilibreze înalt

precizie (un model mai mare ș i mai complicat) cu timp de inferenț ă scăzut
(un model mai mic ș i mai simplu). În situa ț ii de tranzac ț ionare financiară, modelele
ar putea fi necesar să echilibrăm un randament ridicat cu un risc scăzut ș i o lichiditate ridicată

(indiferent cum ar fi definite). Un model de detectare a fraudelor poate fi

interesat să maximizăm vânzările (permiterea mai multor tranzacț ii să continue)
ș i minimizând pierderile (refuzând mai multe tranzacț ii).

Optimizarea multimetrica explorează compromisurile între concurenț i

metrice. Acest lucru permite modelatorilor să în ț eleagă echilibrul dintre
metrice cheie ș i alege hiperparametrii care să îndeplinească nevoile lor.

În plus, pragurile metrice sau constrângerile metrice pot fi aplicate.

când anumite metrici trebuie să atingă praguri minime de performanț ă de
viability – maybe the vision model should maximize accuracy but only
pentru modele cu un timp de inferenț ă mai mic de 100 ms.

După finalizarea unei optimizări a modelului cu una sau mai multe metrici,
setul de date de test ar trebui să fie folosit pentru a reevaluea metricile pe orice

hiperparametrii fiind consideraț i pentru producț ie. Aceasta va confirma

generalizabilitatea modelului înainte de a fi folosit în lumea reală.

Key Takeaways
1. Împăr ț iț i datele disponibile în seturi de date pentru antrenament, validare ș i testare.

2. Defini ț i ș i studia ț i metricile care reprezintă succesul în produc ț ie,

nu doar în timpul antrenamentului.

3. Identifică cei mai buni hiperparametri pentru metricile tale cu cât mai pu ț in
cost de reglare cât mai mic posibil.

Acest capitol a fost scris de SigOpt. Organiza ț iile dintr-o gamă largă de
industrile au încredere în SigOpt pentru a rezolva cele mai dificile provocări de optimizare.
 Toolchain MLOps - Pipeline End-to-End 35

Producț ionalizare - Pipeline-uri End-to-End

Într-un cadru tipic, data scientistul începe cu un laptop, un static
set de date, ș i o problemă de rezolvat.

Clientul va renunț a? Există un siloz pentru rachete nucleare?

în fotografia satelitară? Ce cuvânt va fi tastat
următorul?

Pentru a rezolva problema, specialistul în date ia un caiet, începe

pentru a curăț a setul de date, îl transformă în caracteristici, instalează o duzină

biblioteci, scrie cod, ș terge cod, încearcă modele diferite, schimbă

hiperparametrii, bea multă cafea ș i, în cele din urmă, ajunge la un
un caiet uriaș care în sfârș it rezolvă problema. Pe laptopul lor. Azi.

Produț ionalizarea pentru ML constă în preluarea acelei capacităț i de rezolvare a problemelor -

numai existent în laptopul data scientist-ului astăzi - ș i rafinându-l într-un

un sistem accesibil ș i scalabil. Unul care oferă valoare la scară ș i
poate fi îngrijit pentru a continua să se actualizeze ș i să se îmbunătăț ească ani de zile.

Ciclul Manual
În fluxul de lucru manual, unde nu există o infrastructură reală, datele
cercetătorul înmânează marea agendă inginerului ML.

Adaptat din articolul Google, MLOps: Livrare continuă ș i pipeline-uri de automatizare în

învăț are automată

O dată
ML Ops

Paș i pentru experimentul manual

Extracț ia datelor ș i Antrenarea modelului

Evaluarea modelului Antrenat
Pregătirea datelor Servirea modelului
analiză ș i validare model Registrul modelului
36 Instrumentul MLOps - Pârtii End-to-End

Inginerul cură ț ă manual codul ș i îl refactorizează pentru

performanț ă ș i integrare cu mediul de producț ie. The
inginerul apoi îș i dă seama de bibliotecile ș i mediul necesare ș i
unde ș i cum să obț ii datele live, setează punctul de desfăș urare,
ș i în final împinge modelul. În acest flux de lucru, modelul este
produs.

Timpul trece, iar cineva alertează echipa că modelul ar putea

făcând năzdrăvii. Capacitatea originală de rezolvare a problemelor pare să fie
în scădere pe baza unei intuiț ii. Nimeni nu ș tie cu siguranț ă. Datele
omul de stiinta ia manual un nou lot de date offline, începe cafeaua
maș ina, iar întregul ciclu manual este gata să înceapă din nou.

Caracteristicile unui pipeline ML manual:

Modelul este produsul
• Proces manual sau condus de script
• O deconectare între data scientist ș i inginer
• Ciclu de itera ț ie lent
•Fără teste automatizate sau monitorizare a performan ț ei
• Fără control al versiunilor

Conducta Automatizată
În fluxul de lucru al conductei automate, nu construieș ti ș i nu menț ii un
model. Construieș ti ș i menț ii un pipeline. Pipeline-ul este produsul.

O conductă automată constă în componente ș i un plan de bază

pentru modul în care acestea sunt cuplate pentru a produce ș i actualiza cele mai cruciale

componenta – modelul.

În fluxul de lucru automatizat, omul de ș tiinț ă al datelor nu îș i propune un gigantic

notebook pe laptopul ei cu date offline. Deș i ar putea începe iniț ial

cu un singur caiet, ea va împărț i în cele din urmă soluț ionarea problemei
în componente mai uș or de gestionat.
 Uneltele MLOps - Pârtii de la început până la sfârș it 37

Adaptat din articolul Google, MLOps: Livrare continuă ș i pipeline-uri de automatizare în

învăț are automată

Analiza datelor Experimentare cod nou

Repository de cod

ew code updates how

conducta funcț ionează ș i
îl activează automat
Magazin de caracteristici
Registrul modelului

Conductă automatizată

Antrenat
Extracț ia datelor Validarea datelor Pregătirea datelor Antrenarea modelului Evaluarea modelului Validarea modelului
model

Servirea modelului
Magazin de metadate

Monitorizarea poate avea praguri

care activează utilizarea pipeline-ului de antrenament Monitorizarea modelului
automat

Exemple de diferite componente:

• Validarea datelor
Cură ț area datelor
• Instruire
• Evaluarea modelului
• Validarea modelului
Declan ș ator de re-învă ț are

În plus, ț eava are ș i componente statice cum ar fi:

• Magazin de caracteristici

•Punct de desfă ș urare

• Magazin de metadate
• Controlul versiunii codului sursă

Sistemul oferă capacitatea de a executa, itera ș i monitoriza un singur

component în contextul întregului pipeline cu aceeaș i uș urinț ă
ș i iteraț ie rapidă, ca ș i cum ai rula o celulă de notebook local pe un laptop. De asemenea

îț i permite să defineș ti intrările ș i ieș irile necesare, dependenț ele bibliotecii,

ș i metrici monitorizate.

Această capacitate de a împărț i rezolvarea problemelor în paș i reproducibili, predefiniț i

ș i componentele executabile forț ează echipa să se conformeze unei unite

38 Instrumentele MLOps - Procese End-to-End

Un proces asociat, la rândul său, creează un limbaj bine definit

între oamenii de ș tiinț ă în domeniul datelor ș i inginerii ș i, de asemenea, în cele din urmă

duce la o configurare automată care este echivalentul în învăț area automată al continuu

integrare (CI) – un produs capabil să se auto-actualizeze.

Caracteristici ale unui pipeline ML automatizat:

• Conducta este produsul
•Proces complet automatizat
Cooperarea între omul de ș tiinț ă de date ș i inginer
• Fast iteration cycle
Testare automată ș i monitorizarea performan ț ei
• Controlat prin versionare

Puncte cheie
1. Pipeline-ul este produsul, nu modelul. Nu desfă ș uraț i
model; desfăș uraț i pipeline-ul.

2. Pentru a construi un pipeline, împăr ț iț i sistemul în păr ț i mici bine definite

componente.

3. Precizia modelului se va degrada în cele din urmă pe măsură ce lumea se schimbă.

Pregăteș te-te pentru asta.

 Instrumentele MLOps - Magazinele de caracteristici 39

Producț ionalizare - Magazine de caracteristici

În secț iunea anterioară, am vorbit despre pipeline-urile de învăț are automată

cu un accent pe model. Caracteristicile sunt, totuș i, un alt aspect critic
piesă pentru ML în producț ie ș i sunt la fel de complexe de gestionat ca
modele.

Atunci când construiesc aplicaț ii tradiț ionale, dezvoltatorii au nevoie doar de

pentru a aduce codul în producț ie. Ș i avem uneltele DevOps mature ș i

procese pentru a face asta rapid ș i eficient. Dezvoltatorii pot acum să împingă
lansaț i cod în producț ie de mai multe ori pe zi.

Dar când vine vorba de construirea aplica ț iilor alimentate de ML, acum
de asemenea, trebuie să aducem modelele ș i caracteristicile în producț ie. Ș i asta creează

dureri de cap suplimentare. Oamenii de ș tiinț ă în date nu sunt ingineri software.

Ei construiesc modele ș i funcț ionalităț i în notiț ele lor individuale. Cum fac
aceste modele ș i caracteristici ajung apoi în producț ie?

Pentru modele, există unelte pentru construirea de pipeline-uri de învăț are automată ș i
gestionarea ciclului de viaț ă al modelului. Platformele MLOps permit oamenilor de ș tiinț ă de date

pentru a antrena modele, a rula experimente, a valida modele ș i, în final, a le implementa

să-i producă.

În ceea ce priveș te caracteristicile, oferta uneltelor a fost mult mai puț in matură. Obț inerea

implementarea caracteristicilor în producț ie este deosebit de greu deoarece trebuie să obț inem

transformările de caracteristici (sau tuburi) în produc ț ie ș i curate

valorile caracteristicilor pentru a oferi date consistente pentru antrenare ș i online
inferenț ă. Oamenii de ș tiinț ă ai datelor de obicei îș i transmit transformările de caracteristici

pentru inginerii de date pentru a re-implementa func ț ionalitatea pipeline-urilor cu

cod întărit pentru produc ț ie. Aceasta este un proces complicat care
de obicei introduce săptămâni sau luni de timp de pregătire.
40 Toolchain MLOps - Magazine de funcț ii

Construieș te un

>_

Pipeline DevOps
Dezvoltare Producț ie

Tren Evaluează Dezvoltare

Pipelines MLOps
Antrenarea modelului Servirea Modelului

Funcț ia 1 Caracteristica 1

Inginerie a caracteristicilor Servirea caracteristicilor

Instrumentele pentru gestionarea funcț ionalităț ilor sunt aproape inexistente

Magazinele de caracteristici

Aici intervin magazinele de caracteristici. Magazinele de caracteristici sunt huburi centrale.

pentru caracteristici. Ele transformă datele brute în valori de caracteristici, stochează

valori, ș i le serveș te pentru antrenarea modelului ș i predicț ii online. Prin

automatizând aceș ti paș i, magazinele de caracteristici permit oamenilor de ș tiinț ă a datelor să construiască

ș i să implementeze func ț ionalităț i în câteva ore în loc de luni. Ele permit

oamenii de ș tiinț ă ai datelor să controleze pe deplin caracteristicile lor de la dezvoltare până la

producț ie, aducând instrumente similare DevOps în ingineria caracteristicilor

proces

Magazinele de caracteristici permit oamenilor de ș tiinț ă în domeniul datelor să:

•Construi ț i o bibliotecă de caracteristici excelente în mod colaborativ. În loc să gestiona ț i

transformări ale caracteristicilor într-un notepad local, oamenii de ș tiinț ă ai datelor creează

defini ț ii standard ale caracteristicilor care sunt gestionate într-un sistem de tip Git

repository. Aceste definiț ii de caracteristici sunt apoi aplicate la caracteristică

 Toolchain-ul MLOps - Magazine de funcț ii 41

magazin. Acest lucru aduce consistenț ă în definiț iile funcț iilor ș i capacitatea
pentru a colabora la noi funcț ii.

•Implementa ț i caracteristici în produc ț ie instantaneu. Odată ce defini ț iile caracteristicii

sunt aplicate la magazinul de caracteristici, automatizează caracteristica

transformă ș i curăț ă valorile caracteristicilor. Aceste valori pot

poate fi folosit pentru a crea seturi de date pentru antrenament sau poate fi oferit online pentru

inferenț ă în timp real.

•Împărtă ș eș te, descoperă ș i reutilizează caracteristici. Caracteristicile ș i meta-datele lor,

logica de transformare ș i valorile sunt toate gestionate într-un centru

registrul caracteristicilor ș i sunt căutabile. Oamenii de ș tiinț ă de date pot să le găsească cu u ș urinț ă.

descoperiț i caracteristicile existente ș i reutilizaț i-le în cadrul modelelor.

Magazin de caracteristici

Date de streaming Antrenarea modelului

Magazin
Serve
Transformă

Date de lot Servirea modelului

Construiț i Dezvoltare Distribuie

Cercetători în domeniul datelor

Magazin de funcț ii: Interfaț a dintre modele ș i date

Magazinele de caracteristici au fost introduse pentru prima dată de echipa Uber Michelangelo.

De atunci, multe companii precum Airbnb ș i Netflix ș i-au construit propriile

store interne proprii pentru a rezolva această problemă. Dar magazinele de caracteristici

sunt de asemenea complicate de construit ș i în mare parte au rămas

inaccesibil pentru organizaț iile mai puț in avansate.

În ultima year, totuș i, am văzut introducerea mai multor open

sisteme de stocare a caracteristicilor sursă ș i comerciale. Ele se integrează cu cele existente

lacuri de date, depozite de date, platforme de streaming de evenimente, procesare

42 Uneltele MLOps - Magazina de Funcț ii

motoare, orchestratori de pipeline-uri ș i platforme ML pentru a augmenta

infrastructură cu capabilităț i de gestionare a funcț iilor.

Concluzii cheie
1. Construirea caracteristicilor ș i aducerea acestora în produc ț ie este una dintre
cele mai dificile părț i ale punerii în producț ie a învăț ării automate.

Magazinele de caracteristici permit oamenilor de ș tiinț ă în domeniul datelor să construiască, să implementeze ș i să împărtă ș ească

caracteristici rapid ș i uș or.

3. Magazinele de caracteristici completează infrastructura ML existentă pentru a aduce

Capabilităț i de tip DevOps pentru ciclul de viaț ă al caracteristicilor.

Acest capitol a fost scris de Tecton. Ei oferă o caracteristică pregătită pentru întreprinderi
magazin pentru a face învăț area automată de clasă mondială accesibilă fiecărei companii.
 Lanț ul de instrumente MLOps - Testare 43

Testare
Software-ul tradi ț ional este construit prin scrierea unor reguli fixe împotriva unor bine-

definirea presupunerilor statice ale lumii înconjurătoare. Este relativ

este direct pentru a testa fiecare regulă (test de unitate) sau grup (integrare
teste) când totul este definit dinainte.

Învă ț area automată, prin defini ț ie, este despre a găsi dinamic
reguli, bazate pe date care se schimbă constant, ceea ce face ca testarea să fie mult

mai dificil. Testarea în ML este ca ș i cum ai încerca să loveș ti o ț intă în miș care. Ceea ce

comportamentul sistemului depinde de calităț ile dinamice ale datelor ș i

varii opț iuni de configurare a modelului.

Testarea este strâns legată de explorare, deoarece ar trebui să îț i ofere informaț ii despre ce

criteriile sunt; de exemplu, în ceea ce priveș te distribuț iile statistice.

Testarea Datelor
Pentru un proiect ML, datele sunt la fel de importante (dacă nu chiar mai importante) decât codul. La fel

testele unităț ii pentru codul tău definesc ș i testează presupunerile tale despre
intrările, testele tale de validare a datelor ar trebui să facă la fel pentru antrenare
şi datele de introducere a inferenţei. Trebuie să testezi pentru valori nule, anormale

distribuț iile statistice în cadrul unei caracteristici ș i relaț iile dintre

caracteristici.

De exemplu, dacă inputul tău este aș teptat să fie în engleză aleatoare, o modalitate

a testa înseamnă a calcula că „cele” este cea mai frecvent întâlnită

cuvânt, deoarece aceasta este o presupunere cunoscută. Dacă apare un alt cuvânt

mai des decât „the”, probabil înseamnă că datele tale au câteva

bias neaș teptat, sau poate o parte din el este accidental în spaniolă.
Un alt exemplu de validare a presupunerilor tale ar putea fi că tu
asiguraț i-vă că datele de intrare au o împărț ire uniformă între bărbaț i ș i femei
date dacă aceasta este o presupunere validă pentru cazul tău.

De asemenea, trebuie să testezi relaț iile între caracteristici. Dacă două sau
mai multe caracteristici sunt foarte corelate, poate avea un efect degradant
pe performanț a ș i precizia modelului. De exemplu, dacă datele tale
44 Toolchain-ul MLOps - Testare

este despre produse ș i are două coloane similare pentru preț : taxe
inclus, iar impozitele excluse, ar trebui să declanș eze un alarm.

Model Testing
Odată ce ipotezele despre date sunt testate, putem trece la
testează modelele ș i antrenamentul lor. Nu ar trebui să le desfaci pur ș i simplu fără să te gândeș ti.

model care arată o precizie promiț ătoare pentru datele dumneavoastră offline ș i speranț ă

pentru bine.
În faza de antrenament, poț i testa impactul fiecărui hiperparametru.
Utilizarea unei căutări sistematice sau a unei strategii de căutare mai avansate poate dezvălui

probleme de fiabilitate ș i, de asemenea, îmbunătăț irea performanț ei predictive. Folosind un

set suplimentar de testare, dezmembrat de seturile de antrenament ș i validare ar trebui să

de asemenea, să fie folosit ori de câte ori este posibil.

Când implementa ț i modelul, testa ț i rela ț ia dintre dvs.

metrici offline ș i impactul real al modelului în lumea reală.
Corelaț ia între acurateț ea ta offline ș i clicurile reale
rata pe site-ul dumneavoastră poate fi măsurată într-un experiment A/B de mică amploare.

Un alt test de fum viabil poate fi testarea noului tău model strălucitor împotriva
un model de bază simplu. Curgeț i mici cantităț i de date de producț ie în timp real
a fi gestionat de noul tău model ca un test canar înainte de a te angaja complet

compromite

Testarea Infrastrukturii
Pipeline-ul tău ML ar trebui să fie cât mai reproducibil posibil de la o zi la alta

către următorul. Determinismul perfect este greu, dar ar trebui să lucrezi în direcț ia

îl.

Test the reproducibility of your training pipeline by training two

sau mai multe modele alăturate cu aceleaș i date ș i măsuraț i orice
diferenț e între metrici. De asemenea, testează lucruri precum capacitatea de a
continuă antrenamentul predictibil de la un punct de control de tip mid-crash. Nu

uită să creezi teste de fum pentru integrare pentru întreaga ta conductă, toate
drumul de la prima validare a datelor până la desfăș urarea modelului. Acestea
tipuri de teste ar trebui să ruleze continuu ș i în timpul desfăș urării unui
 Instrumentele MLOps - Testare 45

noua versiune a modelului.

Revenirea la un model stabil poate fi, de asemenea, esen ț ială în situa ț ii nea ș teptate

circumstanț e sau când apare o eroare umană. Ar trebui să continui

testează-ț i infrastructura de rollback, deoarece este ultima ta linie de apărare când
toate celelalte teste au eș uat.

Concluzii cheie
1. Din cauza caracterului dinamic al învă ț ării automate, testarea este ș i mai critică.

[Link] codului este bună; testarea datelor este primordială.

Reproducibilitatea pipeline-ului este cheia pentru desfă ș urarea în siguran ț ă.

46 Instrumentele MLOps - Implementare ș i Inferenț ă

Implementare ș i Inferenț ă
Implementarea este actul de a oferi un model ML celorlalț i din lume
prin API, aplicaț ie sau în alt mod. Inference este ceea ce face modelul,
o dată ce este implementat. Fie că face predic ț ii, clasificând
Datele de intrare sau de grupare sunt întotdeauna denumite inferenț ă.

Întrebarea pe care ar trebui să o pui întotdeauna prima este dacă vizezi un lot
inferen ț ă sau inferen ț ă online; urmată de a face clasic
infernț ă centralizată în cloud sau distribui cerinț ele de calcul către
hardware-ul clientului dvs. (inferenț ă la margine).

Inferenț ă pe loturi

Baza de date

Nume Location Date Score Nume Locaț ie Date Score

Flux de predicț ie

98

Învăț at 95
model 87

81

74

Minute în ore

Inferenț a în vrac este procesul de a face inferenț e pentru un lot

de cereri. În loc să ofere valoare instantaneu în timp real pentru fiecare
solicitare, inferenț a pe lot oferă răspunsuri la un set de întrebări ulterior.
Batch-ul este adesea procesat după un interval fix, de exemplu, o dată pe.
zi. Inferenț a în loturi, în esenț ă, este aproape de o strategie clasică de caching
în dezvoltarea software-ului.

Inferen ț a în lot se potrive ș te oricărei situa ț ii în care laten ț a nu este o problemă.

De exemplu, dacă modelul tău trebuie să evalueze toate noile lead-uri pentru
echipa de vânzări, probabil că nu contează dacă există o întârziere de 24 de ore în

scoring.
 Lanț ul de instrumente MLOps - Implementare ș i Inferenț ă 47

În contextul MLOps, valoarea inferenț ei în intervale fixe permite

inginerii să paralelizeze mai eficient ș i să folosească un considerabil
cantitatea de putere de calcul mai predictibil. Infrastructura
expus la lumea exterioară este mult mai simplu de întreț inut ș i monitorizat,
deoarece nu este necesar să conectezi modelul tău complex direct într-o
API live online cu modele de trafic imprevizibile. De asemenea, obț ineț i niș te
timpul pentru a acț iona asupra problemelor ș i a le remedia înainte ca acestea să fie arătate

client

Inferenț ă Online

Serviciu de predicț ie

Antrenat
Apel API răspuns API
model

Milisecunde

Inferenț a online este procesul de a face inferenț e în timp real.

Fiecare solicitare este gestionată de model imediat.

Inferenț a online se potriveș te oricărei situaț ii în care valoarea furnizată de

modelul este necesar imediat. De exemplu, dacă modelul ar trebui să ...
previziunea celei mai bune rute pe care să o ia o ambulanț ă sau a pieț ei de capital

volatilitate pentru următoarele zece minute, fiecare secundă contează. Predicț ia

nu are nicio valoare dacă este întârziat.

În contextul MLOps, inferenț a online este mult mai solicitantă.

Întrucât cererile sunt gestionate imediat, iar modelul este direct
conectat la traficul online live ș i imprevizibil, lucrurile pot merge
wrong, and they can go wrong fast. Any error or bias in the prediction
48 Instrumentele MLOps - Implementare ș i Inferenț ă

se scurge înapoi la client imediat. Sistemul trebuie, de asemenea, să fie

scalabil automat pentru a acomoda vârfurile de trafic. De obicei,
scalarea este gestionată prin utilizarea unui cluster scalabil automat, cum ar fi Kubernetes.

Cerinț ele pentru monitorizare sunt mult mai mari, iar timpul de reacț ie pentru
orice intervenț ie trebuie să fie aproape de zero.

Infernț ă la margine

Predicț ie pe dispozitiv
serviciu

Antrenat Bună
model

Milisecunde

Op ț iunea clasică pentru implementare ș i inferen ț ă este de a folosi un

sistem centralizat. De obicei, configurezi un cluster Kubernetes pe

unul dintre furnizorii de cloud pentru a gestiona cererile modelului tău. Un altul

opț iunea modernă este de a folosi puterea de calcul a clientului tău

hardware. Aceasta se numeș te inferenț ă la margine.

În loc să aveț i o aplicaț ie care să consume o API centrală cloud, desfăș uraț i

modelul ca parte a aplicaț iei tale direct pe dispozitivul utilizatorului sau

browser. Un bun exemplu ar fi modelul de vorbire în text care rulează
pe un telefon mobil. Audio-ul nu este trimis înapoi la un server (lăț ime de bandă mare

ș i cerinț ele de latenț ă), ci mai degrabă, modelul de pe telefon poate

transformaț i audio-ul în text imediat. Textul transcris poate fi
utilizat pentru o solicitare de text mai simplă (lăsând deoparte lăț imea de bandă ș i

latency) înapoi la un server, unde un alt model este antrenat explicit pentru a
fac sens din textul transcris input.
 Instrumentele MLOps - Implementare ș i Inferenț ă 49

Inferen ț a la margine are un avantaj evident: scalarea perfectă vine pentru

gratis, deoarece cu cât primeș ti mai multe solicitări, cu atât ai mai multe dispozitive edge

at your disposal. Often, the cloud service doesn’t even need to know
această inferenț ă a avut loc deoarece modelul de pe dispozitivul la margine poate fi

total autonom în acest sens. Parte negativă este că s-ar putea să devină
mai greu de întreț inut toate versiunile diferite care există. În funcț ie de
mecanismul tău de actualizare, s-ar putea să fie nevoie să te pregăteș ti pentru o varietate largă

a versiunilor modelului tău care rulează simultan în producț ie.

Trebuie să te confrun ț i ș i cu problema diferitelor dispozitive ș i

mediile. O mie de telefoane mobile sunt egale cu o mie de uș or
medii diferite. În funcț ie de cât de bine îț i încapsulezi
informaț ii de la mediu înconjurător, s-ar putea să ai nevoie
a investi într-o infrastructură complexă de testare atunci când se lucrează cu edge

dispozitive.

O altă potenț ială dezavantaj este securitatea. Deș i nu trimiteț i totul

datele dvs. către dispozitive externe, trimiteț i un model care este antrenat
cu acele date. Deș i de obicei este foarte greu de exploatat, este totuș i o
îngrijorare de securitate de luat în considerare.

Key Takeaways
1. Utiliza ț i inferen ț a în loturi, acolo unde este posibil. Inferen ț a online ar trebui să fie o

ultima soluț ie.

2. Folose ș te inferen ț a la margine ori de câte ori este posibil, deoarece înseamnă scalare perfectă pentru

gratuit.

Configurările complexe necesită monitorizare robustă.

50 Conclusion

Concluzie
Investiț ia în învăț area automată vă va permite să rezolvaț i cazuri de afaceri
care erau anterior imposibil de rezolvat, de exemplu, în mod automat
categorisirea imaginilor în funcț ie de conț inutul lor. Spre deosebire de ML, MLOps nu

vine cu o promisiune de a rezolva orice probleme de afaceri direct. În schimb,

vine cu promisiunea de a accelera modul în care investiț iile tale în ML
valoarea returnată.

Pentru a face o analogie cu o industrie mai tradiț ională: învăț area automată
expedierea mărfurilor în timp ce MLOps este contaierea. Ș i mult
la fel ca în cazul containerizării transportului global, MLOps este un proces ș i

infrastructură în părț i egale. MLOps nu va produce rezultate imediate,

ș i va necesita probabil angajamentul unei gamă largă de părț i interesate.
Totuș i, procesul va oferi beneficii în creș tere odată cu amploarea dvs.
eforturile de învăț are automată.

Pentru unii, practica MLOps nu este nimic nou, mai ales pentru date
oameni de ș tiinț ă cu un puternic background în inginerie software. În
eforturile colaborative, cu toate acestea, este adesea esenț ial să subliniem că
lucrăm conform celor mai bune practici.

Cele patru cele mai bune practici critice pe care vă sugerăm să le adoptaț i sunt:

Versionarea pentru a asigura reproducibilitatea modelelor

Pipelines pentru a construi mai bine sisteme în colaborare
Testare pentru a stabili standarde pentru modelele dvs. de produc ț ie

•Automatizare pentru a economisi timp ș i a construi spre sisteme auto-vindecătoare

Există multe alegeri diferite pentru uneltele MLOps disponibile pe pia ț ă.

market and many different strategies to setting up your whole MLOps

toolchain, de la construirea propriului la achiziț ionarea unei soluț ii gestionate de la început până la sfârș it

platformă. În acest eBook, am încercat să subliniem domeniile pe care ar trebui să le

Ia în considerare ș i oferă câteva concluzii cheie atunci când decizi ce ai nevoie.
 Concluzie 51

În cele din urmă, scopul MLOps este de a reduce frecarea tehnică pentru a obț ine

modelul dintr-o idee în producț ie în cel mai scurt timp posibil,

ș i apoi să ajungi pe piaț ă cu cât mai puț in risc posibil, ș i ar trebui să judeci
deciziile de instrumentare împotriva acestui obiectiv.
52 Despre autori

Despre Autori

Antrenează, Evaluează, Distribuie, Repetă. Valohai este singura platformă MLOps

care automatizează totul, de la extragerea datelor până la implementarea modelului.

Valohai este folosit de toată lumea, de la startup-uri la întreprinderi, inclusiv

PARC, LEGO Group, Twitter ș i JFrog.

Pentru mai multe, vizitaț it [Link].

SigOpt oferă cea mai completă platformă MLOps pentru experimente

managementul ș i optimizarea modelului pentru a scala modelul AI
procesul de dezvoltare.

Pentru mai multe, vizitaț it [Link].

Construit de creatorii Uber Michelangelo, Tecton oferă primul

un magazin de caracteristici pregătit pentru întreprindere care gestionează ciclul de viaț ă complet al

funcț ionalităț i - de la proiectarea de noi funcț ionalităț i până la livrarea lor online pentru

predicț ii în timp real.

Pentru mai multe, vizitaț it [Link].