Testing Approaches For Amazon SageMaker ML Models

Republicat de Platon

Urmaritori: 0

Această postare a fost scrisă împreună cu Tobias Wenzel, Manager de inginerie software pentru platforma Intuit Machine Learning.

Cu toții apreciem importanța unui model de învățare automată (ML) de înaltă calitate și fiabil atunci când folosim conducerea autonomă sau interacționăm cu Alexa, de exemplu. Modelele ML joacă, de asemenea, un rol important în moduri mai puțin evidente - sunt utilizate de aplicații de afaceri, de asistență medicală, instituții financiare, amazon.com, TurboTax și multe altele.

Pe măsură ce aplicațiile activate ML devin esențiale pentru multe afaceri, modelele trebuie să urmeze aceeași vigoare și disciplină ca și aplicațiile software. Un aspect important al MLOps este furnizarea unei noi versiuni a modelului ML dezvoltat anterior în producție, utilizând practici DevOps consacrate, cum ar fi testarea, versiunea, livrarea continuă și monitorizarea.

Există mai multe prescriptiv orientări despre MLOps, iar această postare oferă o privire de ansamblu asupra procesului pe care îl puteți urma și ce instrumente să utilizați pentru testare. Aceasta se bazează pe colaborări între Intui și AWS. Am lucrat împreună pentru a implementa recomandările explicate în această postare în practică și la scară. Scopul lui Intuit de a deveni un Platformă expertă bazată pe inteligență artificială depinde în mare măsură de o strategie de creștere a vitezei de dezvoltare a modelului inițial, precum și de testarea noilor versiuni.

Cerinţe

Următoarele sunt principalele domenii de luat în considerare la implementarea noilor versiuni de model:

Performanța preciziei modelului – Este important să urmărește a parametrilor de evaluare a modelului, cum ar fi acuratețea, precizia și reamintirea, și asigurați-vă că valorile obiective rămân relativ aceleași sau se îmbunătățesc cu o nouă versiune a modelului. În cele mai multe cazuri, implementarea unei noi versiuni a modelului nu are sens dacă experiența utilizatorilor finali nu se va îmbunătăți.
Testează calitatea datelor – Datele din medii care nu sunt de producție, fie că sunt simulate sau copie punct-in-time, ar trebui să fie reprezentative pentru datele pe care modelul le va primi atunci când va fi implementat complet, în ceea ce privește volumul sau distribuția. Dacă nu, procesele dvs. de testare nu vor fi reprezentative, iar modelul dvs. se poate comporta diferit în producție.
Importanța caracteristicilor și paritatea – Importanța caracteristicilor în versiunea mai nouă a modelului ar trebui să se compare relativ cu modelul mai vechi, deși ar putea fi introduse noi funcții. Acest lucru este pentru a ne asigura că modelul nu devine părtinitor.
Testarea proceselor de afaceri – Este important ca o nouă versiune a unui model să vă poată îndeplini obiectivele de afaceri solicitate în parametri acceptabili. De exemplu, una dintre valorile de afaceri poate fi că latența de la capăt la capăt pentru orice serviciu nu trebuie să depășească 100 de milisecunde sau costul pentru găzduirea și recalificarea unui anumit model nu poate fi mai mare de 10,000 USD pe an.
A costat – O abordare simplă a testării este de a replica întregul mediu de producție ca mediu de testare. Aceasta este o practică comună în dezvoltarea de software. Cu toate acestea, o astfel de abordare în cazul modelelor ML ar putea să nu producă rentabilitatea investiției potrivită, în funcție de dimensiunea datelor și poate avea un impact asupra modelului în ceea ce privește problema de afaceri pe care o abordează.
Securitate – Se așteaptă adesea ca mediile de testare să aibă date eșantioane în loc de date reale ale clienților și, în consecință, regulile de manipulare și conformitate a datelor pot fi mai puțin stricte. Totuși, la fel ca și costul, dacă pur și simplu duplicați mediul de producție într-un mediu de testare, puteți introduce riscuri de securitate și conformitate.
Scalabilitatea magazinului de caracteristici – Dacă o organizație decide să nu creeze un magazin de caracteristici de testare separat din motive de cost sau de securitate, atunci testarea modelului trebuie să aibă loc în magazinul de caracteristici de producție, ceea ce poate cauza probleme de scalabilitate, deoarece traficul este dublat în timpul perioadei de testare.
Performanța modelului online – Evaluările online diferă de evaluările offline și pot fi importante în unele cazuri, cum ar fi modelele de recomandare, deoarece măsoară satisfacția utilizatorilor în timp real, mai degrabă decât satisfacția percepută. Este greu de simulat modele reale de trafic în non-producție din cauza sezonalității sau a altor comportamente ale utilizatorilor, așa că performanța modelului online poate fi realizată numai în producție.
Performanța operațională – Pe măsură ce modelele devin mai mari și sunt implementate din ce în ce mai mult într-un mod descentralizat pe hardware diferit, este important să testați modelul pentru performanța operațională dorită, cum ar fi latența, rata de eroare și multe altele.

Majoritatea echipelor ML au o abordare pe mai multe direcții a testării modelelor. În secțiunile următoare, oferim modalități de a aborda aceste provocări în timpul diferitelor etape de testare.

Testarea modelului offline

Scopul acestei faze de testare este de a valida noi versiuni ale unui model existent din punct de vedere al preciziei. Acest lucru ar trebui făcut în mod offline pentru a nu afecta nicio predicție din sistemul de producție care oferă predicții în timp real. Asigurându-se că noul model are performanțe mai bune pentru valorile de evaluare aplicabile, această testare abordează provocarea 1 (performanța acurateței modelului). De asemenea, prin utilizarea setului de date potrivit, această testare poate aborda provocările 2 și 3 (calitatea datelor de testare, importanța caracteristicilor și paritatea), cu beneficiul suplimentar de a aborda provocarea 5 (cost).

Această fază se realizează în mediul de scenă.

Ar trebui să captați traficul de producție, pe care îl puteți folosi pentru a relua în testarea back-line offline. Este de preferat să folosiți traficul de producție trecut în loc de date sintetice. The Monitor de model Amazon SageMaker caracteristica de captare a datelor vă permite să capturați traficul de producție pentru modelele găzduite pe Amazon SageMaker. Acest lucru le permite dezvoltatorilor de modele să-și testeze modelele cu date din zilele lucrătoare de vârf sau alte evenimente semnificative. Datele capturate sunt apoi reluate împotriva versiunii noului model într-un mod de lot, folosind Transformare batch Sagemaker. Aceasta înseamnă că execuția de transformare în lot poate testa cu date care au fost colectate de-a lungul săptămânilor sau lunilor în doar câteva ore. Acest lucru poate accelera semnificativ procesul de evaluare a modelului în comparație cu rularea a două sau mai multe versiuni ale unui model în timp real una lângă alta și trimiterea cererilor de predicție duplicate către fiecare punct final. Pe lângă găsirea mai rapidă a unei versiuni mai performante, această abordare folosește și resursele de calcul pentru o perioadă mai scurtă de timp, reducând costul total.

O provocare cu această abordare a testării este că setul de caracteristici se schimbă de la o versiune de model la alta. În acest scenariu, vă recomandăm să creați un set de caracteristici cu un superset de caracteristici pentru ambele versiuni, astfel încât toate caracteristicile să poată fi interogate simultan și înregistrate prin captura de date. Fiecare apel de predicție poate funcționa apoi numai pe acele caracteristici necesare pentru versiunea curentă a modelului.

Ca bonus suplimentar, prin integrare Amazon SageMaker Clarify în testarea modelului offline, puteți verifica noua versiune a modelului pentru părtinire și, de asemenea, puteți compara atribuirea caracteristicilor cu versiunea anterioară a modelului. Cu pipeline, puteți orchestra întregul flux de lucru astfel încât, după antrenament, să poată avea loc un pas de verificare a calității pentru a efectua o analiză a valorilor modelului și a importanței caracteristicilor. Aceste valori sunt stocate în Registrul modelului SageMaker pentru comparație în următorul ciclu de antrenament.

Testare de integrare și performanță

Testarea integrării este necesară pentru a valida procesele de afaceri end-to-end din punct de vedere funcțional, precum și din punct de vedere al performanței de rulare. În cadrul acestui proces, întreaga conductă ar trebui testată, inclusiv preluarea și calcularea caracteristicilor din magazinul de caracteristici și rularea aplicației ML. Acest lucru ar trebui făcut cu o varietate de sarcini utile diferite pentru a acoperi o varietate de scenarii și solicitări și pentru a obține o acoperire ridicată pentru toate rulările posibile de cod. Aceasta abordează provocările 4 și 9 (testarea proceselor de afaceri și performanța operațională) pentru a se asigura că niciunul dintre procesele de afaceri nu este întrerupt cu noua versiune a modelului.

Această testare ar trebui făcută într-un mediu de pregătire.

Atât testarea de integrare, cât și testarea performanței trebuie să fie implementate de echipe individuale care utilizează conducta lor MLOps. Pentru testarea integrării, recomandăm metoda încercată și testată de a menține un mediu de pre-producție echivalent funcțional și de testare cu câteva sarcini utile diferite. Fluxul de lucru de testare poate fi automatizat așa cum se arată în acest atelier. Pentru testarea performanței, puteți utiliza Recomandator de inferențe Amazon SageMaker, care oferă un punct de plecare excelent pentru a determina ce tip de instanță și câte dintre acele instanțe să folosești. Pentru aceasta, va trebui să utilizați un instrument generator de încărcare, cum ar fi proiectele open-source perfsizesagemaker și perfsize pe care le-a dezvoltat Intuit. Perfsizesagemaker vă permite să testați automat configurațiile modelelor de terminale cu o varietate de sarcini utile, timpi de răspuns și tranzacții de vârf pe secundă. Acesta generează rezultate detaliate ale testelor care compară diferite versiuni de model. Perfsize este instrumentul însoțitor care încearcă diferite configurații având în vedere doar tranzacțiile de vârf pe secundă și timpul de răspuns așteptat.

A / B de testare

În multe cazuri în care este necesară reacția utilizatorului la rezultatul imediat al modelului, cum ar fi aplicațiile de comerț electronic, evaluarea funcțională a modelului offline nu este suficientă. În aceste scenarii, trebuie să testați modelele A/B în producție înainte de a lua decizia de a actualiza modelele. Testarea A/B are și riscurile sale, deoarece ar putea exista un impact real asupra clienților. Această metodă de testare servește ca validare finală a performanței ML, o verificare ușoară a ingineriei. Această metodă abordează, de asemenea, provocările 8 și 9 (performanța modelului online și excelența operațională).

Testarea A/B trebuie efectuată într-un mediu de producție.

Cu SageMaker, puteți efectua cu ușurință testarea A/B pe modele ML rulând mai multe variante de producție pe un punct final. Traficul poate fi direcționat în trepte către noua versiune pentru a reduce riscul pe care l-ar putea avea un model care se comportă prost în producție. Dacă rezultatele testului A/B arată bine, traficul este direcționat către noua versiune, preluând în cele din urmă peste 100% din trafic. Vă recomandăm să folosiți balustradele de desfășurare pentru a trece de la modelul A la B. Pentru o discuție mai completă despre testarea A/B folosind Personalizați Amazon modele ca exemplu, consultați Utilizarea testării A/B pentru a măsura eficacitatea recomandărilor generate de Amazon Personalize.

Testarea modelelor online

În acest scenariu, noua versiune a unui model este semnificativ diferită de cea care deservește deja traficul live în producție, astfel încât abordarea de testare offline nu mai este potrivită pentru a determina eficacitatea versiunii noi de model. Cel mai proeminent motiv pentru aceasta este o modificare a caracteristicilor necesare pentru a produce predicția, astfel încât tranzacțiile înregistrate anterior nu pot fi folosite pentru a testa modelul. În acest scenariu, vă recomandăm să utilizați implementări în umbră. Implementările în umbră oferă capacitatea de a implementa o umbră (sau challenger) model alături de producție (sau campion) model care servește în prezent predicții. Acest lucru vă permite să evaluați modul în care modelul umbră funcționează în traficul de producție. Predicțiile modelului umbră nu sunt furnizate aplicației solicitante; sunt înregistrați pentru evaluare offline. Cu abordarea umbră pentru testare, abordăm provocările 4, 5, 6 și 7 (testarea proceselor de afaceri, cost, securitate și scalabilitate a magazinului de caracteristici).

Testarea modelelor online ar trebui să se facă în medii de punere în scenă sau de producție.

Această metodă de testare a noilor versiuni de model ar trebui utilizată ca ultimă soluție dacă toate celelalte metode nu pot fi utilizate. Îl recomandăm ca ultimă soluție, deoarece apelurile duplex către mai multe modele generează încărcare suplimentară pentru toate serviciile din aval în producție, ceea ce poate duce la blocaje de performanță, precum și la creșterea costurilor de producție. Cel mai evident impact pe care îl are acest lucru este asupra stratului de difuzare a caracteristicilor. Pentru cazurile de utilizare care partajează caracteristici dintr-un grup comun de date fizice, trebuie să fim capabili să simulăm mai multe cazuri de utilizare care accesează simultan același tabel de date pentru a ne asigura că nu există conflicte de resurse înainte de a trece la producție. Ori de câte ori este posibil, interogările duplicate către depozitul de caracteristici ar trebui evitate, iar caracteristicile necesare pentru ambele versiuni ale modelului ar trebui să fie reutilizate pentru a doua inferență. Magazine de caracteristici bazate pe Amazon DynamoDB, așa cum a construit-o Intuit, poate implementa Acceleratorul Amazon DynamoDB(DAX) pentru a stoca în cache și pentru a evita dublarea I/O la baza de date. Acestea și alte opțiuni de stocare în cache pot atenua provocarea 7 (scalabilitate magazin de caracteristici).

Pentru a aborda provocările 5 (cost), precum și 7, propunem folosirea implementărilor umbră pentru a eșantiona traficul de intrare. Acest lucru oferă proprietarilor de modele un alt nivel de control pentru a minimiza impactul asupra sistemelor de producție.

Desfășurarea în umbră ar trebui să fie integrată în Monitor model oferte la fel ca implementările obișnuite de producție pentru a observa îmbunătățirile versiunii challenger.

Concluzie

Această postare ilustrează elementele de bază pentru a crea un set cuprinzător de procese și instrumente pentru a aborda diferite provocări cu testarea modelului. Deși fiecare organizație este unică, acest lucru ar trebui să vă ajute să începeți și să vă restrângeți considerentele atunci când implementați propria strategie de testare.

Despre autori

Tobias Wenzel este manager de inginerie software pentru platforma Intuit Machine Learning din Mountain View, California. El a lucrat la platformă încă de la înființarea acesteia în 2016 și a ajutat la proiectarea și construirea acesteia de la zero. În meseria sa, el s-a concentrat pe excelența operațională a platformei și a adus-o cu succes prin afacerile sezoniere ale Intuit. În plus, este pasionat de extinderea continuă a platformei cu cele mai noi tehnologii.

Shivanshu Upadhyay este arhitect principal de soluții în grupul AWS Business Development and Strategic Industries. În acest rol, el îi ajută pe cei mai avansați care adoptă AWS să-și transforme industria prin utilizarea eficientă a datelor și a inteligenței artificiale.

Alan Tan este Senior Product Manager la SageMaker, conducând eforturile pentru inferența modelelor mari. Este pasionat de aplicarea învățării automate în domeniul analizei. În afara serviciului, se bucură de aer liber.