Testmetoder for Amazon SageMaker ML-modeller

Genudgivet af Platon

Abonnenter: 0

Dette indlæg blev skrevet sammen med Tobias Wenzel, Software Engineering Manager for Intuit Machine Learning Platform.

Vi sætter alle pris på vigtigheden af en højkvalitets og pålidelig machine learning (ML) model, når du bruger autonom kørsel eller interagerer med Alexa, for eksempel. ML-modeller spiller også en vigtig rolle på mindre indlysende måder - de bruges af forretningsapplikationer, sundhedspleje, finansielle institutioner, amazon.com, TurboTax og mere.

Da ML-aktiverede applikationer bliver kernen i mange virksomheder, skal modeller følge samme handlekraft og disciplin som softwareapplikationer. Et vigtigt aspekt af MLOps er at levere en ny version af den tidligere udviklede ML-model i produktion ved at bruge etablerede DevOps-praksis såsom test, versionering, kontinuerlig levering og overvågning.

Der er flere foreskrivende retningslinjer omkring MLOps, og dette indlæg giver et overblik over den proces, du kan følge, og hvilke værktøjer du skal bruge til test. Dette er baseret på samarbejder mellem Intuit og AWS. Vi har arbejdet sammen om at implementere anbefalingerne, der er forklaret i dette indlæg, i praksis og i omfang. Intuits mål om at blive en AI-drevet ekspertplatform er stærkt afhængig af en strategi med at øge hastigheden af den indledende modeludvikling samt test af nye versioner.

Krav

Følgende er de vigtigste områder, der tages i betragtning ved implementering af nye modelversioner:

Model nøjagtighed ydeevne – Det er vigtigt at holde styr på af modelevalueringsmetrikker som nøjagtighed, præcision og genkaldelse, og sikre, at de objektive metrics forbliver relativt de samme eller forbedres med en ny version af modellen. I de fleste tilfælde giver det ikke mening at implementere en ny version af modellen, hvis slutbrugernes oplevelse ikke bliver bedre.
Test datakvalitet – Data i ikke-produktionsmiljøer, uanset om de er simulerede eller punkt-i-tidskopier, bør være repræsentative for de data, som modellen vil modtage, når den er fuldt implementeret, hvad angår volumen eller distribution. Hvis ikke, vil dine testprocesser ikke være repræsentative, og din model kan opføre sig anderledes i produktionen.
Funktionens betydning og paritet – Betydningen af funktioner i den nyere version af modellen bør sammenlignes med den ældre model, selvom der kan være introduceret nye funktioner. Dette er for at sikre, at modellen ikke bliver partisk.
Afprøvning af forretningsprocesser – Det er vigtigt, at en ny version af en model kan opfylde dine påkrævede forretningsmål inden for acceptable parametre. For eksempel kan en af forretningsmålingerne være, at ende-til-ende-forsinkelsen for enhver tjeneste ikke må være mere end 100 millisekunder, eller omkostningerne til at hoste og genoptræne en bestemt model kan ikke være mere end $10,000 om året.
Koste – En simpel tilgang til test er at replikere hele produktionsmiljøet som et testmiljø. Dette er en almindelig praksis inden for softwareudvikling. Imidlertid vil en sådan tilgang i tilfælde af ML-modeller muligvis ikke give det rigtige ROI afhængigt af størrelsen af data og kan påvirke modellen i forhold til det forretningsproblem, den adresserer.
Sikkerhed – Testmiljøer forventes ofte at have prøvedata i stedet for rigtige kundedata, og som et resultat kan reglerne for datahåndtering og compliance være mindre strenge. Ligesom omkostningerne dog, hvis du blot duplikerer produktionsmiljøet til et testmiljø, kan du introducere sikkerheds- og overholdelsesrisici.
Funktionsbutik skalerbarhed – Hvis en organisation beslutter sig for ikke at oprette en separat testfunktionsbutik på grund af omkostnings- eller sikkerhedsårsager, skal modeltestning ske på produktionsfunktionslageret, hvilket kan forårsage problemer med skalerbarhed, da trafikken fordobles i testperioden.
Online model ydeevne – Onlineevalueringer adskiller sig fra offlineevalueringer og kan være vigtige i nogle tilfælde som anbefalingsmodeller, fordi de måler brugertilfredshed i realtid frem for opfattet tilfredshed. Det er svært at simulere reelle trafikmønstre i ikke-produktion på grund af sæsonbestemte eller anden brugeradfærd, så online modelydelse kan kun udføres i produktionen.
Operationel ydeevne – Efterhånden som modeller bliver større og i stigende grad implementeres på en decentral måde på forskellig hardware, er det vigtigt at teste modellen for din ønskede operationelle ydeevne såsom latens, fejlrate og mere.

De fleste ML-hold har en flerstrenget tilgang til modeltestning. I de følgende afsnit giver vi måder at løse disse udfordringer på under forskellige teststadier.

Offline modeltest

Målet med denne testfase er at validere nye versioner af en eksisterende model ud fra et nøjagtighedssynspunkt. Dette bør gøres offline for ikke at påvirke nogen forudsigelser i produktionssystemet, der serverer forudsigelser i realtid. Ved at sikre, at den nye model præsterer bedre for relevante evalueringsmetrikker, løser denne test udfordring 1 (modelpræcisionspræstation). Ved at bruge det rigtige datasæt kan denne test også løse udfordringer 2 og 3 (testdatakvalitet, funktionsvigtighed og paritet) med den ekstra fordel ved at tackle udfordring 5 (omkostninger).

Denne fase udføres i iscenesættelsesmiljøet.

Du bør fange produktionstrafik, som du kan bruge til at afspille i offline back-test. Det er at foretrække at bruge tidligere produktionstrafik i stedet for syntetiske data. Det Amazon SageMaker Model Monitor indfangningsdatafunktion giver dig mulighed for at fange produktionstrafik for modeller, der hostes på Amazon SageMaker. Dette giver modeludviklere mulighed for at teste deres modeller med data fra spidsbelastningsdage eller andre væsentlige begivenheder. De opsamlede data afspilles derefter mod den nye modelversion på en batch-måde vha Sagemaker batch transformation. Det betyder, at batchtransformationskørslen kan teste med data, der er blevet indsamlet over uger eller måneder på få timer. Dette kan fremskynde modelevalueringsprocessen betydeligt sammenlignet med at køre to eller flere versioner af en realtidsmodel side om side og sende duplikerede forudsigelsesanmodninger til hvert slutpunkt. Ud over at finde en version med bedre ydeevne hurtigere, bruger denne tilgang også computerressourcerne i kortere tid, hvilket reducerer de samlede omkostninger.

En udfordring med denne tilgang til test er, at funktionssættet skifter fra en modelversion til en anden. I dette scenarie anbefaler vi at oprette et funktionssæt med et supersæt af funktioner for begge versioner, så alle funktioner kan forespørges på én gang og registreres gennem datafangsten. Hvert forudsigelseskald kan derefter kun fungere på de funktioner, der er nødvendige for den aktuelle version af modellen.

Som en ekstra bonus ved at integrere Amazon SageMaker Clarify i din offline modeltestning kan du tjekke den nye version af modellen for bias og også sammenligne funktionstilskrivning med den tidligere version af modellen. Med pipelines kan du orkestrere hele arbejdsgangen, således at der efter træning kan et kvalitetstjek finde sted for at udføre en analyse af modellens metrikker og funktioners betydning. Disse målinger er gemt i SageMaker modelregistrering til sammenligning i næste træningsløb.

Integration og præstationstest

Integrationstest er nødvendig for at validere end-to-end forretningsprocesser fra et funktionelt såvel som et runtime-performanceperspektiv. Inden for denne proces bør hele pipelinen testes, inklusive hentning og beregning af funktioner i funktionslageret og kørsel af ML-applikationen. Dette bør gøres med en række forskellige nyttelaster for at dække en række scenarier og anmodninger og opnå høj dækning for alle mulige kodekørsler. Dette løser udfordringer 4 og 9 (forretningsprocestest og operationel ydeevne) for at sikre, at ingen af forretningsprocesserne er brudt med den nye version af modellen.

Denne test bør udføres i et iscenesættelsesmiljø.

Både integrationstest og præstationstest skal implementeres af individuelle teams ved hjælp af deres MLOps-pipeline. Til integrationstesten anbefaler vi den afprøvede metode til at opretholde et funktionelt ækvivalent præproduktionsmiljø og teste med nogle få forskellige nyttelaster. Testens arbejdsgang kan automatiseres som vist i denne workshop. Til præstationstesten kan du bruge Amazon SageMaker Inference Recommender, som giver et godt udgangspunkt for at bestemme, hvilken instanstype og hvor mange af disse instanser der skal bruges. Til dette skal du bruge et belastningsgeneratorværktøj, såsom open source-projekter perfsizesagemaker , perfsize som Intuit har udviklet. Perfsizesagemaker giver dig mulighed for automatisk at teste modelslutpunktskonfigurationer med en række forskellige nyttelaster, responstider og peak-transaktioner pr. sekund krav. Det genererer detaljerede testresultater, der sammenligner forskellige modelversioner. Perfsize er det ledsagende værktøj, der prøver forskellige konfigurationer kun givet peak-transaktioner pr. sekund og den forventede responstid.

A / B-test

I mange tilfælde, hvor brugerreaktion på modellens umiddelbare output er påkrævet, såsom e-handelsapplikationer, er offline-modellens funktionelle evaluering ikke tilstrækkelig. I disse scenarier skal du A/B-teste modeller i produktion, før du træffer beslutningen om at opdatere modeller. A/B-test har også sine risici, fordi der kan være reel kundepåvirkning. Denne testmetode tjener som den endelige validering af ML-ydeevne, et letvægts-teknisk sundhedstjek. Denne metode løser også udfordringer 8 og 9 (onlinemodelydelse og operationel ekspertise).

A/B-test skal udføres i et produktionsmiljø.

Med SageMaker kan du nemt udføre A/B-test på ML-modeller ved at køre flere produktionsvarianter på et endepunkt. Trafik kan dirigeres i trin til den nye version for at reducere risikoen for, at en dårligt opfører sig model kan have på produktionen. Hvis resultaterne af A/B-testen ser gode ud, dirigeres trafikken til den nye version og overtager til sidst 100 % af trafikken. Vi anbefaler at bruge udrulningsværn til overgang fra model A til B. For en mere komplet diskussion om A/B-test ved hjælp af Amazon Tilpas modeller som eksempel, se Brug af A/B-test til at måle effektiviteten af anbefalinger genereret af Amazon Personalize.

Online model test

I dette scenarie er den nye version af en model væsentligt anderledes end den, der allerede betjener live trafik i produktionen, så offline-testmetoden er ikke længere egnet til at bestemme effektiviteten af den nye modelversion. Den mest fremtrædende årsag til dette er en ændring i funktioner, der kræves for at producere forudsigelsen, så tidligere registrerede transaktioner ikke kan bruges til at teste modellen. I dette scenarie anbefaler vi at bruge skyggeimplementeringer. Shadow-implementeringer giver mulighed for at implementere en skygge (eller udfordrer) model ved siden af produktionen (eller champion) model, der i øjeblikket betjener forudsigelser. Dette giver dig mulighed for at evaluere, hvordan skyggemodellen klarer sig i produktionstrafik. Forudsigelserne af skyggemodellen leveres ikke til den anmodende applikation; de er logget til offline evaluering. Med skyggetilgangen til test løser vi udfordringer 4, 5, 6 og 7 (forretningsprocestest, omkostninger, sikkerhed og skalerbarhed af funktionsbutikker).

Online modeltest bør udføres i scene- eller produktionsmiljøer.

Denne metode til at teste nye modelversioner bør bruges som en sidste udvej, hvis alle de andre metoder ikke kan bruges. Vi anbefaler det som en sidste udvej, fordi duplex-opkald til flere modeller genererer yderligere belastning på alle downstream-tjenester i produktionen, hvilket kan føre til ydeevneflaskehalse samt øgede omkostninger i produktionen. Den mest åbenlyse indvirkning, dette har, er på funktionsserveringslaget. For use cases, der deler funktioner fra en fælles pulje af fysiske data, skal vi være i stand til at simulere flere use cases samtidig med at få adgang til den samme datatabel for at sikre, at der ikke eksisterer nogen ressourcepåstand før overgang til produktion. Hvor det er muligt, bør duplikerede forespørgsler til feature-lageret undgås, og funktioner, der er nødvendige for begge versioner af modellen, bør genbruges til den anden slutning. Feature butikker baseret på Amazon DynamoDB, som den Intuit har bygget, kan implementere Amazon DynamoDB Accelerator(DAX) for at cache og undgå at fordoble I/O til databasen. Disse og andre cacheindstillinger kan afbøde udfordring 7 (skalerbarhed af funktionslager).

For at løse udfordring 5 (omkostninger) såvel som 7, foreslår vi at bruge skyggeimplementeringer til at sample den indgående trafik. Dette giver modelejere endnu et lag af kontrol for at minimere indvirkningen på produktionssystemerne.

Shadow-implementering skal være ombord på Model skærm tilbud ligesom de almindelige produktionsinstallationer for at observere forbedringerne af udfordrerversionen.

Konklusion

Dette indlæg illustrerer byggestenene til at skabe et omfattende sæt af processer og værktøjer til at løse forskellige udfordringer med modeltestning. Selvom enhver organisation er unik, bør dette hjælpe dig i gang og indsnævre dine overvejelser, når du implementerer din egen teststrategi.

Om forfatterne

Tobias Wenzel er Software Engineering Manager for Intuit Machine Learning Platform i Mountain View, Californien. Han har arbejdet på platformen siden dens start i 2016 og har hjulpet med at designe og bygge den fra bunden. I sit job har han fokuseret på platformens operationelle ekspertise og at bringe den med succes gennem Intuits sæsonbestemte forretning. Derudover brænder han for løbende at udvide platformen med de nyeste teknologier.

Shivanshu Upadhyay er en Principal Solutions Architect i AWS Business Development and Strategic Industries-gruppen. I denne rolle hjælper han de fleste avancerede brugere af AWS med at transformere deres industri ved effektivt at bruge data og AI.

Alan Tan er en Senior Product Manager hos SageMaker, der leder indsatsen inden for store modelslutninger. Han brænder for at anvende maskinlæring til analyseområdet. Uden for arbejdet nyder han udendørslivet.