Pe măsură ce întreprinderile adoptă învățarea automată (ML) în cadrul organizațiilor lor, fluxurile de lucru manuale pentru construirea, instruirea și implementarea modelelor ML tind să devină blocaje în calea inovației. Pentru a depăși acest lucru, întreprinderile trebuie să modeleze un model de operare clar, care să definească modul în care mai multe persoane, cum ar fi oamenii de știință de date, inginerii de date, inginerii ML, IT și părțile interesate de afaceri, ar trebui să colaboreze și să interacționeze; cum să separăm preocupările, responsabilitățile și abilitățile; și cum să utilizați serviciile AWS în mod optim. Această combinație de ML și operațiuni (MLOps) ajută companiile să-și eficientizeze ciclul de viață ML end-to-end și să mărească productivitatea oamenilor de știință de date, menținând în același timp acuratețea ridicată a modelului și îmbunătățind securitatea și conformitatea.
În această postare, aflați despre fazele cheie ale construirii unei fundații MLOps, despre modul în care mai multe persoane lucrează împreună pe această fundație și despre Amazon SageMaker instrumente special concepute și integrări încorporate cu alte servicii AWS care pot accelera adoptarea ML într-o afacere de întreprindere.
Model de maturitate MLOps
Construirea unei fundații MLOps care poate acoperi nevoile operațiunilor, oamenilor și tehnologiei clienților întreprinderii este o provocare. Prin urmare, definim următorul model de maturitate care definește capacitățile necesare ale MLOps-urilor în patru faze cheie.
- Faza initiala: În această fază, oamenii de știință de date sunt capabili să experimenteze și să construiască, să antreneze și să implementeze modele pe AWS folosind serviciile SageMaker. Mediul de dezvoltare sugerat este Amazon SageMaker Studio, în care oamenii de știință de date sunt capabili să experimenteze și să colaboreze pe baza notebook-urilor Studio.
- Faza repetabilă – Cu capacitatea de a experimenta pe AWS, următorul pas este crearea fluxurilor de lucru automate pentru a preprocesa datele și pentru a construi și a antrena modele (conducte ML). Oamenii de știință de date colaborează cu inginerii ML într-un mediu separat pentru a construi algoritmi și cod sursă robusti și pregătiți pentru producție, orchestrați folosind Pipelines Amazon SageMaker. Modelele generate sunt stocate și evaluate în registrul de modele Amazon SageMaker.
- Faza de incredere – Chiar dacă modelele au fost generate prin conductele ML, ele trebuie testate înainte de a fi promovate în producție. Prin urmare, în această fază, se introduce metodologia de testare automată, atât pentru model, cât și pentru infrastructura de declanșare, într-un mediu izolat de punere în scenă (pre-producție) care simulează producția. După o rulare cu succes a testului, modelele sunt implementate în mediul izolat de producție. Pentru a promova modelele în mediile multiple, sunt necesare evaluare manuală și aprobări.
- Faza scalabila – După producerea primei soluții ML, este necesară scalarea fundației MLOps pentru a sprijini mai multe echipe de știință a datelor pentru a colabora și a produce zeci sau sute de cazuri de utilizare ML. În această fază, introducem șablonizarea soluțiilor, ceea ce aduce viteză în valoare prin reducerea timpului de dezvoltare a noilor soluții de producție de la săptămâni la zile. În plus, automatizăm instanțiarea mediilor MLOps securizate pentru a permite mai multor echipe să opereze pe datele lor, reducând dependența și cheltuielile generale față de IT.
În următoarele secțiuni, arătăm cum să construim o fundație MLOps pe baza modelului de maturitate anterior și a următoarelor principii:
- Flexibilitate – Oamenii de știință de date sunt capabili să găzduiască orice cadru (cum ar fi TensorFlow sau PyTorch)
- reproductibilitatea - Oamenii de știință de date sunt capabili să recreeze sau să observe experimente trecute (cod, date și rezultate)
- Abilitatea de Reus – Oamenii de știință de date și inginerii ML pot reutiliza codul sursă și conductele ML, evitând inconsecvențele și costurile
- scalabilitate – Oamenii de știință de date și inginerii ML sunt capabili să scaleze resursele și serviciile la cerere
- auditării – Oamenii de știință de date, departamentele IT și juridice pot audita jurnalele, versiunile și dependențele artefactelor și datelor
- consecvență – Deoarece MLOps constă din mai multe medii, fundația trebuie să elimine variațiile dintre medii
Faza initiala
În faza inițială, scopul este de a crea un mediu de experimentare securizat în care cercetătorul de date primește instantanee ale datelor și experimente folosind notebook-uri SageMaker pentru a demonstra că ML poate rezolva o anumită problemă de afaceri. Pentru a realiza acest lucru, se recomandă un mediu Studio cu acces personalizat la servicii prin punctele finale VPC. Codul sursă al arhitecturii de referință este disponibil în exemplele furnizate de echipa SageMaker pe site-ul Securizarea științei datelor cu arhitectura de referință Amazon SageMaker Studio Repo GitHub.
În plus față de serviciile SageMaker, oamenii de știință de date pot folosi alte servicii pentru a procesa datele, cum ar fi Amazon EMR, Amazon Atena, și AWS Adeziv, cu caiete stocate și versionate în AWS CodeCommit depozite (vezi figura următoare).
Faza repetabilă
După ce oamenii de știință de date au dovedit că ML poate rezolva problema de afaceri și sunt familiarizați cu experimentarea, instruirea și implementarea modelelor SageMaker, următorul pas este să începeți producția soluției ML. Figura următoare ilustrează această arhitectură.
În această etapă, este necesară separarea preocupărilor. Împărțim mediul în mai multe conturi AWS:
- Data Lake – Stochează toate datele ingerate din local (sau alte sisteme) în cloud. Inginerii de date sunt capabili să creeze conducte de extragere, transformare și încărcare (ETL) combinând mai multe surse de date și să pregătească seturile de date necesare pentru cazurile de utilizare ML. Datele sunt catalogate prin AWS Glue Data Catalog și partajate cu alți utilizatori și conturi prin Formația lacului AWS (nivelul de guvernare a datelor). În același cont, Magazinul de caracteristici Amazon SageMaker poate fi găzduit, dar nu acoperim această postare. Pentru mai multe informații, consultați Activați reutilizarea funcțiilor între conturi și echipe folosind Amazon SageMaker Feature Store.
- Experimentare – Permite oamenilor de știință de date să își desfășoare cercetările. Singura diferență este că originea instantaneelor de date este lacul de date. Oamenii de știință de date au acces numai la anumite seturi de date, care pot fi anonimizate în cazul GDPR sau a altor constrângeri de confidențialitate a datelor. În plus, contul de experimentare poate avea acces la internet pentru a le permite oamenilor de știință de date să utilizeze noi cadre de știință a datelor sau biblioteci open-source terțe. Prin urmare, contul de experimentare este considerat ca parte a mediului de non-producție.
- Dezvoltare (dezvoltare) – Prima etapă a mediului de producție. Oamenii de știință de date trec de la notebook-uri la lumea fluxurilor de lucru automate și a SageMaker Pipelines. Ei trebuie să colaboreze cu inginerii ML pentru a-și abstra codul și pentru a asigura acoperirea testării, gestionarea erorilor și calitatea codului. Scopul este de a dezvolta conducte ML, care sunt fluxuri de lucru automate care preprocesează, antrenează, evaluează și înregistrează modele în registrul de modele SageMaker. Implementarea conductelor ML este condusă numai prin conducte CI/CD și accesul la Consola de administrare AWS este restrictionat. Conexiunea la internet nu este permisă deoarece conducta ML are acces la datele de producție din lacul de date (numai citire).
- Scule (sau automatizare) – Găzduiește depozitele CodeCommit, AWS CodePipeline Conducte CI/CD, registru model SageMaker și Amazon ECR pentru a găzdui containere personalizate. Deoarece lacul de date este singurul punct de adevăr pentru date, contul de instrumente este pentru cod, containere și artefacte produse.
Rețineți că această convenție de denumire a conturilor și strategia pentru mai multe conturi pot varia în funcție de nevoile dvs. de afaceri, dar această structură este menită să arate nivelurile recomandate de izolare. De exemplu, puteți redenumi contul de dezvoltare în contul de formare model sau de compilare.
Pentru a realiza implementarea automată, este important să înțelegeți cum să treceți de la notebook-uri la conductele ML și să standardizați depozitele de cod și structura datelor, despre care vom discuta în secțiunile următoare.
De la notebook-uri la conducte ML
Scopul mediului de dezvoltare este de a restructura, amplifica, îmbunătăți și scala codul din notebook-uri și de a-l muta în conductele ML. O conductă ML este un set de pași care sunt responsabili pentru preprocesarea datelor, antrenarea sau utilizarea modelelor și postprocesarea rezultatelor. Fiecare pas ar trebui să îndeplinească exact o sarcină (o transformare specifică) și să fie suficient de abstract (de exemplu, să treacă numele de coloane ca parametri de intrare) pentru a permite reutilizarea. Următoarea diagramă ilustrează un exemplu de conductă.
Pentru a implementa conductele ML, oamenii de știință de date (sau inginerii ML) folosesc SageMaker Pipelines. O conductă SageMaker este o serie de pași interconectați (lucrări de procesare SageMaker, instruire, HPO) care este definită de o definiție a conductei JSON folosind un SDK Python. Această definiție de conductă codifică o conductă folosind un grafic aciclic direcționat (DAG). Acest DAG oferă informații despre cerințele și relațiile dintre fiecare pas al conductei ML.
În funcție de cazul de utilizare, puteți separa conducta ML în două tipuri principale: antrenament și inferență pe lot.
Următoarea figură ilustrează fluxul conductei ML de antrenament.
Faza de preprocesare poate consta din mai mulți pași. Transformările obișnuite ale științei datelor sunt împărțirea și eșantionarea datelor (formare, validare, set de testare), codificare sau vectorizare one-hot, binning și scalare. Etapa de formare a modelului ar putea fi fie un job de formare, dacă cercetătorul de date cunoaște cea mai bună configurație a modelului, fie un job de optimizare a hiperparametrilor (HPO), în care AWS definește cei mai buni hiperparametri pentru model (metoda bayesiană) și produce artefact model. În etapa de evaluare, artefactul de model produs este utilizat pentru a efectua inferența la setul de date de validare. Apoi conducta ML verifică dacă valorile de acuratețe produse (cum ar fi F1, precizie și decile de câștig) trec pragurile necesare. Dacă acest pas are succes, artefactele modelului și metadatele sunt mutate în registrul modelului pentru producție. Rețineți că pasul de referință de export exploatează Monitor de model Amazon SageMaker funcționalitate, producând un obiect JSON cu statisticile care sunt utilizate ulterior pentru detectarea derivei modelului și care pot fi găzduite în registrul modelului SageMaker ca metadate de model.
În cazul inferenței pe lot, oamenii de știință de date sunt capabili să creeze conducte similare, așa cum este ilustrat în figura următoare.
Etapa de preprocesare a inferenței pe lot este adesea aceeași cu antrenamentul prin excluderea eșantionării datelor și a coloanei de adevăr de bază. Inferența în loturi este pasul care trimite date în loturi pentru inferență la punctul final corespunzător și poate fi implementat utilizând transformarea lotului. Etapa de postprocesare produce statistici suplimentare, cum ar fi distribuția rezultatelor sau unește rezultatele cu ID-uri externe. Apoi, un pas de monitorizare a modelului este capabil să compare statisticile de bază ale datelor utilizate pentru antrenament (metadatele modelului JSON în registrul modelului) cu noile date primite pentru inferență.
Puteți sări peste pașii de preprocesare dacă oamenii de știință de date creează modele pipeline care pot fi stocate în registrul de modele SageMaker. Pentru mai multe detalii, consultați Modele gazdă împreună cu logica de preprocesare ca conductă de inferență serială în spatele unui punct final.
Standardizarea depozitelor
Pentru a permite colaborarea dintre oamenii de știință de date și inginerii ML, este necesară standardizarea structurii depozitului de coduri. În plus, standardizarea este benefică pentru structura conductei CI/CD, permițând încorporarea etapelor de validare automată, de construire (cum ar fi construirea de containere personalizate) și de testare.
Următorul exemplu ilustrează separarea soluțiilor ML în două depozite: un depozit de construire și antrenament pentru instruire (și opțional model de conductă) și implementare pentru a promova modelele de conducte de inferență pe lot sau a instanția punctele finale în timp real:
Depozit de clădire/instruire
Depozitare de implementare
Depozitul de construire și antrenament este împărțit în trei foldere principale:
- Algoritmi – Oamenii de știință de date dezvoltă codul pentru fiecare pas al conductelor ML în folderul rădăcină al algoritmilor. Pașii pot fi grupați în preprocesare, instruire, inferență pe lot și postprocesare (evaluare). În fiecare grup, mai mulți pași pot fi definiți în subfolderele corespunzătoare, care conțin un folder pentru testele unitare (inclusiv intrări și ieșiri opționale), funcțiile principale, readme și un fișier Docker în cazul în care este nevoie de un container personalizat. În plus față de principal, mai multe fișiere de cod pot fi găzduite în același folder. Bibliotecile de ajutor comune pentru toți pașii pot fi găzduite într-un folder partajat de bibliotecă. Oamenii de știință de date sunt responsabili pentru dezvoltarea testelor unitare, deoarece dețin logica pașilor, iar inginerii ML sunt responsabili pentru îmbunătățirea gestionării erorilor și pentru recomandarea acoperirii testelor. Conducta CI/CD este responsabilă pentru rularea testelor, construirea automată a containerelor (dacă este necesar) și împachetarea mai multor fișiere de cod sursă.
- Conducte ML – După ce dezvoltați codul sursă și testele fiecărui pas, următorul pas este definirea conductelor SageMaker într-un alt folder rădăcină. Fiecare definiție a conductei ML este plasată în subfolder care conține fișierul .py și un fișier JSON sau .yaml pentru parametrii de intrare, cum ar fi intervalele de hiperparametri. Este necesar un fișier readme pentru a descrie conductele ML.
- notebook-uri – Acest folder găzduiește caietele de origine pe care cercetătorul de date le-a folosit în timpul experimentării.
Depozitul de implementare constă din trei părți principale:
- Configurație de inferență – Conține configurația punctelor finale în timp real sau inferențe în loturi per mediu de dezvoltare, cum ar fi tipurile de instanțe.
- Infrastructura aplicațiilor – Găzduiește codul sursă al infrastructurii necesare pentru a rula inferența, dacă este necesar. Acesta ar putea fi un mecanism de declanșare prin Amazon EventBridge, Gateway API Amazon, AWS Lambdas funcții sau SageMaker Pipelines.
- Teste – Constă din mai multe subfoldere, în funcție de metodologia de testare a clientului. Ca set minim de teste, sugerăm un test de integrare (execuție de la capăt la capăt al inferenței, inclusiv infrastructura aplicației), test de stres (examinarea cazurilor marginale) și teste ML (cum ar fi distribuția scorurilor de încredere sau a probabilităților).
Prin efectuarea modificărilor în depozitul de creare și antrenament, o conductă CI/CD este responsabilă pentru validarea structurii depozitului, efectuarea testelor și implementarea și rularea conductelor ML. O conductă CI/CD diferită este responsabilă pentru promovarea modelelor, pe care le examinăm în secțiunea următoare.
Standardizarea ramificării depozitelor și CI/CD
Pentru a asigura robustețea conductelor ML în contul de dezvoltare, este sugerată o strategie de depozitare cu mai multe ramuri, în timp ce implementarea este efectuată numai prin conducte CI/CD. Oamenii de știință de date ar trebui să utilizeze o ramură de caracteristici pentru a-și dezvolta noua funcționalitate (codul sursă). Când sunt gata să implementeze conductele ML corespunzătoare, pot împinge acest lucru în ramura de dezvoltare. O alternativă la această abordare este de a permite implementarea conductelor ML per ramură de caracteristică. Pentru mai multe informații, consultați Îmbunătățiți-vă fluxul de lucru pentru știința datelor cu o conductă MLOps de instruire în mai multe ramuri folosind AWS.
Următoarea figură ilustrează strategia de ramificare și pașii necesari de conductă CI/CD pe care îi rulăm în mediul de dezvoltare pentru pipeline ML și construirea modelului.
Exemplul de cod al abordării multi-ramuri este disponibil în Conductă de instruire MLOps multi-ramură. Putem stoca modelele produse de o conductă ML bazată pe ramuri de caracteristici într-un grup separat de modele de caracteristici și le putem dezafecta în timpul unei cereri de îmbinare cu ramura principală. Modelele din grupul principal de modele sunt cele care sunt promovate în producție.
Standardizarea structurii datelor
La fel de importantă pentru standardizarea codului sursă este standardizarea structurii datelor, care permite oamenilor de știință de date și inginerilor ML să depaneze, să auditeze și să monitorizeze originea și istoricul modelelor și conductelor ML. Următoarea diagramă ilustrează un astfel de exemplu.
Pentru simplitate, să presupunem că datele istorice de intrare ajung într-o găleată a contului de dezvoltare sub cheia secundară de intrare (în mod normal, aceasta este situată în lacul de date). Pentru fiecare caz de utilizare ML, trebuie creată o subcheie separată. Pentru a declanșa rularea unei noi conducte ML, cercetătorul de date ar trebui să efectueze o comitere și un push git, care declanșează conducta CI/CD. Apoi conducta CI/CD creează o subcheie prin copierea artefactelor de cod ( code
sub-cheie) și date de intrare (the input
sub-cheie) sub o sub-partiție a ID-ului build-ului. De exemplu, ID-ul build-ului csă fie o combinație de date și oră și git hash sau un ID de rulare a conductei SageMaker. Această structură permite cercetătorului de date să auditeze și să interogheze implementările și rulările anterioare. După aceasta, conducta CI/CD implementează și declanșează conducta ML. În timp ce conducta ML rulează, fiecare pas exportă rezultatele intermediare către ml-pipeline-outputs
. Este important să rețineți că diferite ramuri de caracteristici implementează și rulează o nouă instanță a ML Pipeline și fiecare trebuie să exporte rezultatele intermediare într-un subdosar diferit cu o nouă subcheie și/sau un prefix sau sufix standardizat care include ID de ramură caracteristică.
Această abordare sprijină auditabilitatea completă a fiecărei experimente. Cu toate acestea, abordarea multi-ramificată a strategiei de dezvoltare generează o cantitate mare de date. Prin urmare, este necesară o strategie pentru ciclul de viață al datelor. Vă sugerăm să ștergeți cel puțin datele fiecărei ramuri de caracteristici ale conductei ML în fiecare solicitare de extragere/combinare reușită. Dar acest lucru depinde de modelul de operare și de granularitatea auditului pe care trebuie să le suporte afacerea dvs. Puteți utiliza o abordare similară în conductele ML de inferență pe lot
Faza de incredere
După separarea inițială a preocupărilor între oamenii de știință de date, inginerii ML și inginerii de date prin utilizarea mai multor conturi, următorul pas este promovarea modelelor produse din registrul de modele într-un mediu izolat pentru a efectua inferențe. Cu toate acestea, trebuie să asigurăm robustețea modelelor implementate. Prin urmare, o simulare a modelului implementat într-un mediu oglindă de producție este obligatorie, și anume pre-producție (sau punere în scenă).
Figura următoare ilustrează această arhitectură.
Promovarea implementării unui model și a unui punct final în mediul de pre-producție se realizează folosind evenimentele de actualizare a stării registrului modelului (sau git push în depozitul de implementare), care declanșează o conductă CI/CD separată prin utilizarea evenimentelor EventBridge. Primul pas al conductei CI/CD solicită o aprobare manuală din partea savantului principal de date (și, opțional, proprietarul produsului, analist de afaceri sau alți oameni de știință de date lider). Aprobatorul trebuie să valideze KPI-urile de performanță ale modelului și QA-ul codului din depozitul de implementare. După aprobare, conducta CI/CD rulează codul de testare către depozitul de implementare (test de integrare, test de stres, test ML). Pe lângă punctul final al modelului, CI/CD testează și infrastructura de declanșare, cum ar fi EventBridge, funcțiile Lambda sau API Gateway. Următoarea diagramă arată această arhitectură actualizată.
După desfășurarea cu succes a testelor, conducta CI/CD notifică noii (sau aceiași) autorizatori că un model este gata să fie promovat în producție. În această etapă, analistul de afaceri ar putea dori să efectueze câteva teste suplimentare de ipoteză statistică asupra rezultatelor modelului. După aprobare, modelele și infrastructura de declanșare sunt implementate în producție. SageMaker acceptă mai multe metode de implementare, cum ar fi testarea albastru/verde, Canary și A/B (vezi mai multe în Balustrade de desfășurare). Dacă conducta CI/CD eșuează, un mecanism de rollback readuce sistemul la cea mai recentă stare robustă.
Următoarea diagramă ilustrează pașii principali ai conductei CI/CD pentru a promova un model și infrastructura pentru a declanșa punctul final al modelului, cum ar fi API Gateway, funcțiile Lambda și EventBridge.
Lacul de date și integrarea MLOps
În acest moment, este important să înțelegeți cerințele de date pentru fiecare etapă de dezvoltare sau cont și modul de a încorpora MLO-uri cu un lac de date centralizat. Următoarea diagramă ilustrează MLOps-urile și straturile lacului de date.
În lacul de date, inginerii de date sunt responsabili pentru alăturarea mai multor surse de date și crearea seturilor de date corespunzătoare (de exemplu, un singur tabel al datelor de structură sau un singur folder cu fișiere PDF sau imagini) pentru cazurile de utilizare ML prin construirea ETL conducte așa cum sunt definite de oamenii de știință ai datelor (în timpul fazei de analiză a datelor de explorare). Aceste seturi de date pot fi împărțite în date istorice și date pentru inferență și testare. Toate datele sunt catalogate (de exemplu, cu AWS Glue Data Catalog) și pot fi partajate cu alte conturi și utilizatori prin utilizarea Lake Formation ca strat de guvernare a datelor (pentru date structurate). În momentul scrierii acestui articol, Lake Formation este compatibil doar cu interogările Athena, joburile AWS Glue și Amazon EMR.
Pe de altă parte, mediul MLOps trebuie să iriga conductele ML cu seturi de date specifice situate în compartimente locale în dev, pre-prod și prod. Mediul de dezvoltare este responsabil pentru construirea și antrenarea modelelor la cerere folosind conductele SageMaker care extrag date din lacul de date. Prin urmare, sugerăm ca prim pas al conductei fie să existe un pas Athena, în care sunt necesare doar eșantionarea și interogarea datelor, fie un pas Amazon EMR, dacă sunt necesare transformări mai complexe. Alternativ, puteți utiliza o lucrare AWS Glue printr-un pas de apel invers, dar nu ca pas nativ încă cu SageMaker Pipelines.
Pre-prod și prod sunt responsabile fie de testare, fie de efectuarea de inferențe în timp real și pe lot. În cazul inferenței în timp real, trimiterea datelor către conturile MLOps pre-prod și prod nu este necesară, deoarece intrarea pentru inferență poate fi preluată de sarcina utilă a solicitării API Gateway. În cazul inferenței în lot (sau a datelor de intrare de dimensiuni mari), seturile de date necesare, fie date de testare, fie date pentru inferență, trebuie să ajungă în compartimentele de date locale ML (pre-prod sau prod). Aveți două opțiuni pentru a muta datele în pre-prod și prod: fie prin declanșarea Athena sau Amazon EMR și extragerea datelor din lacul de date, fie prin împingerea datelor din lacul de date în acele conturi MLOps. Prima opțiune necesită dezvoltarea unor mecanisme suplimentare în conturile MLOps, de exemplu, crearea de evenimente EventBridge programate (fără cunoașterea dacă datele din lacul de date au fost actualizate) sau sosirea pe date în evenimentele S3 EventBridge în lacul de date (pentru mai multe detalii, vezi Simplificarea accesului pe mai multe conturi cu politicile de resurse Amazon EventBridge). După capturarea evenimentului în partea MLOps, o interogare Athena sau Amazon EMR poate prelua date local și poate declanșa inferență asincronă or transformarea lotului. Acest lucru poate fi împachetat într-o conductă SageMaker pentru simplitate. A doua opțiune este să adăugați în ultimul pas al conductei ETL funcționalitatea de împingere a datelor în compartimentele MLOps. Cu toate acestea, această abordare combină responsabilitățile (lacul de date declanșează inferența) și necesită ca Lake Formation să ofere acces la lacul de date pentru a scrie în gălețile MLOps.
Ultimul pas este mutarea rezultatelor inferenței înapoi în lacul de date. Pentru a cataloga datele și a le pune la dispoziție altor utilizatori, datele ar trebui să revină ca o nouă sursă de date înapoi în compartimentul de aterizare.
Faza scalabilă
După dezvoltarea fundației MLOps și producția end-to-end a primului caz de utilizare ML, infrastructura dev, pre-prod, prod și depozitul, conducta CI/CD și structura de date au fost testate și finalizate. . Următorul pas este integrarea noilor cazuri de utilizare ML și echipe pe platformă. Pentru a asigura viteză-la-valoare, SageMaker vă permite să creați șabloane de proiect personalizate SageMaker, pe care le puteți utiliza pentru a instanția depozite de șabloane și conducte CI/CD automat. Cu astfel de șabloane de proiect SageMaker, oamenii de știință de date conducători sunt responsabili pentru instanțiarea proiectelor noi și alocarea unei echipe dedicate pentru noi cazuri de utilizare ML.
Următoarea diagramă ilustrează acest proces.
Problema devine mai complexă dacă diferite echipe de cercetători ai datelor (sau mai multe unități de afaceri care trebuie să producă ML) au acces la diferite date confidențiale și mai mulți proprietari de produse sunt responsabili pentru plata unei facturi separate pentru instruirea, implementarea și funcționarea modelelor. . Prin urmare, este necesar un set separat de conturi MLOps (experimentare, dezvoltare, pre-prod și prod) pentru fiecare echipă. Pentru a permite crearea ușoară de noi conturi MLOps, introducem un alt cont, contul de guvernanță de analiză avansată, care este accesibil membrilor IT și le permite să catalogeze, să instanțieze sau să dezafecteze conturile MLOps la cerere. Mai exact, acest cont găzduiește depozite cu codul de infrastructură al conturilor MLOps (VPC, subrețele, puncte finale, bucket-uri, Gestionarea identității și accesului AWS (IAM) roluri și politici, Formarea AWS Cloud stive), an Catalog de servicii AWS produs pentru a implementa automat stivele CloudFormation ale infrastructurii în mai multe conturi cu un singur clic și un Amazon DynamoDB metadate din tabel în catalog, cum ar fi echipa responsabilă pentru fiecare set de conturi. Cu această capacitate, echipa IT instanțiază conturi MLOps la cerere și alocă utilizatorii necesari, accesul la date per cont și constrângerile de securitate consistente.
Pe baza acestui scenariu, separăm conturile de efemere și durabile. Lacul de date și instrumentele sunt conturi durabile și joacă rolul unui singur punct de adevăr pentru date și, respectiv, codul sursă. Conturile MLOps sunt în mare parte apatride și sunt instanțiate sau dezafectate la cerere, făcându-le efemere. Chiar dacă un set de conturi MLOps este scos din funcțiune, utilizatorii sau auditorii pot verifica experimentele și rezultatele anterioare deoarece sunt stocate în medii durabile.
Dacă doriți să utilizați Studio UI pentru MLOps, contul de instrumente face parte din contul de dezvoltare, conform următoarei figure.
Dacă utilizatorul dorește să folosească Sagemaker Studio UI pentru MLOps, contul de instrumente face parte din dev.
cont conform figurii de mai sus. Exemplu de cod sursă al acestei fundații MLOPs poate fi găsit în
Fundație MLOps sigură pentru mai multe conturi bazată pe CDK.
Rețineți că Sagemaker oferă capacitatea de a înlocui CodeCommit și CodePipeline cu alte instrumente de dezvoltare terțe, cum ar fi GitHub și Jenkins (mai multe detalii pot fi găsite în Creați proiecte Amazon SageMaker folosind controlul sursei terță parte și Jenkins și Amazon SageMaker proiectează MLOps Șablon cu GitLab și GitLab Pipelines).
Rezumat de persoane, operațiuni și tehnologie
Cu modelul de maturitate MLOps, putem defini un design clar al arhitecturii și o foaie de parcurs de livrare. Cu toate acestea, fiecare persoană trebuie să aibă o vedere clară asupra conturilor și serviciilor AWS cheie cu care să interacționeze și a operațiunilor de efectuat. Următoarea diagramă rezumă acele categorii.
Concluzie
O fundație MLOps robustă, care definește în mod clar interacțiunea dintre mai multe persoane și tehnologie, poate crește viteza de raportare la valoare și poate reduce costurile și le permite oamenilor de știință de date să se concentreze pe inovații. În această postare, am arătat cum să construim o astfel de fundație în faze, ceea ce duce la un model de maturitate MLOps fluid pentru afacere și la capacitatea de a sprijini mai multe echipe de știință a datelor și cazuri de utilizare ML în producție. Am definit un model de operare format din mai multe persoane cu abilități și responsabilități multiple. În cele din urmă, am împărtășit exemple de standardizare a dezvoltării codului (depozite și conducte CI/CD), stocarea și partajarea datelor și furnizarea de infrastructură securizată MLOps pentru mediile de întreprindere. Mulți clienți de întreprindere au adoptat această abordare și sunt capabili să-și producă soluțiile ML în câteva zile, în loc de luni.
Dacă aveți orice comentarii sau întrebări, vă rugăm să le lăsați în secțiunea de comentarii.
Despre autor
Dr. Sokratis Kartakis este arhitect senior de soluții de specialitate în învățare automată pentru Amazon Web Services. Sokratis se concentrează pe a permite clienților întreprinderi să-și industrializeze soluțiile de învățare automată (ML) prin exploatarea serviciilor AWS și modelarea modelului lor de operare, adică fundația MLOps și foaia de parcurs de transformare, valorificând cele mai bune practici de dezvoltare. A petrecut peste 15 ani inventând, proiectând, conducând și implementând soluții inovatoare de ML și Internet of Things (IoT) end-to-end la nivel de producție în domeniile energiei, retailului, sănătății, finanțelor/bancarului, sporturilor cu motor etc. Lui Sokratis îi place să-și petreacă timpul liber cu familia și prietenii sau cu motocicletele.
Georgios Schinas este arhitect specializat în soluții pentru AI/ML în regiunea EMEA. Are sediul la Londra și lucrează îndeaproape cu clienții din Marea Britanie și Irlanda. Georgios îi ajută pe clienți să proiecteze și să implementeze aplicații de învățare automată în producție pe AWS, cu un interes deosebit pentru practicile MLOps și le permite clienților să efectueze învățarea automată la scară. În timpul liber, îi place să călătorească, să gătească și să petreacă timpul cu prietenii și familia.
Giuseppe Angelo Porcelli este arhitect principal de soluții de specialitate în învățare automată pentru Amazon Web Services. Cu câțiva ani în domeniul ingineriei software cu un fundal ML, el lucrează cu clienți de orice dimensiune pentru a înțelege în profunzime nevoile lor de afaceri și tehnice și pentru a proiecta soluții AI și de învățare automată care folosesc cel mai bine AWS Cloud și stiva Amazon Machine Learning. El a lucrat la proiecte în diferite domenii, inclusiv MLOps, Computer Vision, NLP și implicând un set larg de servicii AWS. În timpul liber lui Giuseppe îi place să joace fotbal.
Shelbee Eigenbrode este arhitect principal în soluții de AI și învățare automată la Amazon Web Services (AWS). Ea lucrează în tehnologie de 24 de ani, acoperind mai multe industrii, tehnologii și roluri. În prezent, ea se concentrează pe combinarea experienței sale DevOps și ML în domeniul MLOps pentru a ajuta clienții să livreze și să gestioneze sarcinile de lucru ML la scară. Cu peste 35 de brevete acordate în diverse domenii tehnologice, ea are o pasiune pentru inovarea continuă și utilizarea datelor pentru a genera rezultate în afaceri. Shelbee este co-creator și instructor al specializării Practical Data Science pe Coursera. Ea este, de asemenea, co-director al Women In Big Data (WiBD), capitolul Denver. În timpul liber, îi place să petreacă timpul cu familia, prietenii și câinii hiperactivi.
- Coinsmart. Cel mai bun schimb de Bitcoin și Crypto din Europa.
- Platoblockchain. Web3 Metaverse Intelligence. Cunoștințe amplificate. ACCES LIBER.
- CryptoHawk. Radar Altcoin. Încercare gratuită.
- Sursa: https://aws.amazon.com/blogs/machine-learning/mlops-foundation-roadmap-for-enterprises-with-amazon-sagemaker/
- "
- 100
- a
- capacitate
- Despre Noi
- REZUMAT
- accelera
- acces
- accesibil
- găzdui
- Cont
- Obține
- peste
- plus
- Suplimentar
- Adoptare
- avansat
- împotriva
- AI
- algoritmi
- TOATE
- permite
- alternativă
- Amazon
- Amazon Web Services
- printre
- sumă
- analiză
- analist
- Google Analytics
- O alta
- api
- aplicație
- aplicatii
- abordare
- arhitectură
- de audit
- automatizarea
- Automat
- în mod automat
- Automatizare
- disponibil
- evitarea
- AWS
- fundal
- De bază
- deoarece
- deveni
- înainte
- în spatele
- benefică
- CEL MAI BUN
- între
- Datele mari
- Proiect de lege
- a stimula
- construi
- Clădire
- construit-in
- afaceri
- întreprinderi
- capacități
- caz
- cazuri
- centralizat
- provocare
- Capitol
- Verificări
- clasic
- Cloud
- cod
- colabora
- colaborare
- Coloană
- combinaţie
- comentarii
- comite
- Comun
- Companii
- compatibil
- Completă
- complex
- conformitate
- calculator
- Conduce
- efectuarea
- încredere
- Configuraţie
- conexiune
- consistent
- Recipient
- Containere
- conține
- Control
- copiere
- Corespunzător
- ar putea
- acoperi
- crea
- a creat
- creează
- Crearea
- creaţie
- În prezent
- personalizat
- client
- clienţii care
- de date
- accesul la date
- analiza datelor
- confidențialitatea datelor
- știința datelor
- om de știință de date
- stocare a datelor
- Zi
- dedicat
- livrare
- Cerere
- Denver
- În funcție
- depinde de
- implementa
- dislocate
- Implementarea
- desfășurarea
- implementări
- implementează
- descrie
- Amenajări
- proiect
- detalii
- Detectare
- dev
- dezvolta
- Dezvoltare
- instrumente de dezvoltare
- diferenţă
- diferit
- discuta
- distribuire
- Docher
- domeniu
- domenii
- conduce
- condus
- în timpul
- fiecare
- Margine
- elimina
- îmbrăţişare
- permite
- permite
- permițând
- un capăt la altul
- Punct final
- energie
- Inginerie
- inginerii
- Afacere
- Companii
- Mediu inconjurator
- etc
- evalua
- evaluare
- eveniment
- evenimente
- exact
- exemplu
- exemple
- F? r?
- experiment
- exploit
- explorare
- familie
- Caracteristică
- Figura
- În cele din urmă
- First
- debit
- Concentra
- se concentrează
- concentrându-se
- următor
- Fotbal
- formare
- găsit
- Fundație
- Fundații
- Cadru
- cadre
- Gratuit
- din
- funcționalitate
- funcții
- În plus
- poartă
- GDPR
- generată
- merge
- GitHub
- scop
- guvernare
- acordate
- grup
- Manipularea
- hașiș
- Sănătate
- ajutor
- ajutor
- ajută
- Înalt
- istoric
- istorie
- găzduit
- Cum
- Cum Pentru a
- Totuși
- HTTPS
- sute
- Identitate
- imagini
- punerea în aplicare a
- implementat
- Punere în aplicare a
- important
- îmbunătăţi
- include
- Inclusiv
- Crește
- industrii
- informații
- Infrastructură
- Inovaţie
- inovații
- inovatoare
- intrare
- instanță
- integrare
- integrările
- interacţiune
- interes
- interfaţă
- Internet
- internetul Lucrurilor
- IoT
- Irlanda
- izolare
- IT
- Loc de munca
- Locuri de munca
- aderarea
- Se alătură
- A pastra
- Cheie
- cunoştinţe
- mare
- Ultimele
- strat
- conduce
- conducere
- AFLAȚI
- învăţare
- Părăsi
- Legal
- nivelurile de
- efectului de pârghie
- Bibliotecă
- încărca
- local
- la nivel local
- Londra
- maşină
- masina de învățare
- face
- Efectuarea
- administra
- administrare
- obligatoriu
- manual
- scadență
- mecanism
- Membri actuali
- Îmbina
- Metodologie
- Metode
- Metrici
- ar putea
- minte
- minim
- oglindă
- ML
- model
- Modele
- monitor
- luni
- mai mult
- Motorsports
- muta
- în mişcare
- multiplu
- și anume
- nume
- denumire
- necesar
- nevoilor
- următor
- în mod normal
- funcionar
- de operare
- Operațiuni
- optimizare
- Opțiune
- Opţiuni
- comandă
- organizații
- original
- Altele
- propriu
- proprietar
- Proprietarii
- parte
- special
- parte
- pasiune
- Brevete de inventie
- oameni
- performanță
- efectuarea
- fază
- platformă
- Joaca
- joc
- "vă rog"
- Punct
- Politicile
- Pregăti
- Principal
- intimitate
- Problemă
- proces
- prelucrare
- Produs
- Produs
- producere
- productivitate
- proiect
- Proiecte
- promova
- de promovare
- furniza
- prevăzut
- furnizează
- trăgând
- calitate
- RE
- în timp real
- reduce
- reducerea
- regiune
- Inregistreaza-te
- Relaţii
- de încredere
- depozit
- solicita
- cereri de
- necesar
- Cerinţe
- Necesită
- cercetare
- resursă
- Resurse
- responsabilităţi
- responsabil
- REZULTATE
- cu amănuntul
- reveni
- Returnează
- foaie de parcurs
- robusteţe
- Rol
- rădăcină
- Alerga
- funcţionare
- acelaşi
- scalabil
- Scară
- scalare
- programată
- Ştiinţă
- Om de stiinta
- oamenii de stiinta
- sdk
- sigur
- securitate
- de serie
- serie
- serviciu
- Servicii
- set
- configurarea
- câteva
- Modela
- comun
- partajarea
- Arăta
- asemănător
- simulare
- singur
- Mărimea
- aptitudini
- Software
- Inginerie software
- soluţie
- soluţii
- REZOLVAREA
- unele
- cod sursă
- specialist
- specific
- specific
- viteză
- petrece
- Cheltuire
- împărţi
- stivui
- Etapă
- Stadiile
- Începe
- Stat
- statistic
- statistică
- Stare
- depozitare
- stoca
- magazine
- Strategie
- simplifica
- stres
- structurat
- studio
- de succes
- a sustine
- Suportat
- Sprijină
- sistem
- sisteme
- echipă
- echipe
- Tehnic
- Tehnologii
- Tehnologia
- şabloane
- test
- Testarea
- teste
- Sursa
- lumea
- prin urmare
- lucruri
- terț
- trei
- timp
- împreună
- Unelte
- Tren
- Pregătire
- Transforma
- Transformare
- transformări
- Traveling
- Tipuri
- ui
- Uk
- în
- înţelege
- de unităţi
- Actualizează
- utilizare
- utilizatorii
- folosi
- validare
- valoare
- diverse
- Vizualizare
- viziune
- web
- servicii web
- în timp ce
- în
- fără
- Femei
- Apartamente
- a lucrat
- fluxuri de lucru
- fabrică
- lume
- scris
- ani
- Ta