Testingsmetoder for Amazon SageMaker ML-modeller

Dette innlegget ble skrevet sammen med Tobias Wenzel, Software Engineering Manager for Intuit Machine Learning Platform.

Vi setter alle pris på viktigheten av en høykvalitets og pålitelig maskinlæringsmodell (ML) når du bruker autonom kjøring eller samhandler med Alexa, for eksempel. ML-modeller spiller også en viktig rolle på mindre åpenbare måter – de brukes av forretningsapplikasjoner, helsevesen, finansinstitusjoner, amazon.com, TurboTax og mer.

Ettersom ML-aktiverte applikasjoner blir kjernen i mange virksomheter, må modeller følge samme kraft og disiplin som programvareapplikasjoner. Et viktig aspekt ved MLOps er å levere en ny versjon av den tidligere utviklede ML-modellen i produksjon ved å bruke etablert DevOps-praksis som testing, versjonering, kontinuerlig levering og overvåking.

Det finnes flere normative retningslinjer rundt MLOps, og dette innlegget gir en oversikt over prosessen du kan følge og hvilke verktøy du skal bruke for testing. Dette er basert på samarbeid mellom Intuit og AWS. Vi har jobbet sammen for å implementere anbefalingene som er forklart i dette innlegget i praksis og i stor skala. Intuits mål om å bli en AI-drevet ekspertplattform er sterkt avhengig av en strategi for å øke hastigheten på innledende modellutvikling samt testing av nye versjoner.

Krav

Følgende er hovedområdene du bør vurdere når du distribuerer nye modellversjoner:

1. Modellnøyaktighet ytelse – Det er viktig å holde styr på av modellevalueringsberegninger som nøyaktighet, presisjon og tilbakekalling, og sikre at de objektive beregningene forblir relativt de samme eller forbedres med en ny versjon av modellen. I de fleste tilfeller gir det ikke mening å distribuere en ny versjon av modellen hvis opplevelsen til sluttbrukere ikke blir bedre.
2. Test datakvalitet – Data i ikke-produksjonsmiljøer, enten simulert eller punkt-i-tidskopi, bør være representative for dataene som modellen vil motta når den er fullstendig distribuert, når det gjelder volum eller distribusjon. Hvis ikke, vil ikke testprosessene dine være representative, og modellen din kan oppføre seg annerledes i produksjonen.
3. Funksjons betydning og paritet – Betydningen av funksjoner i den nyere versjonen av modellen bør sammenlignes med den eldre modellen, selv om det kan være nye funksjoner introdusert. Dette er for å sikre at modellen ikke blir partisk.
4. Forretningsprosesstesting – Det er viktig at en ny versjon av en modell kan oppfylle dine nødvendige forretningsmål innenfor akseptable parametere. For eksempel kan en av forretningsberegningene være at ende-til-ende-forsinkelsen for en tjeneste ikke må være mer enn 100 millisekunder, eller kostnaden for å være vert for og omskolere en bestemt modell kan ikke være mer enn $10,000 XNUMX per år.
5. Kostnad – En enkel tilnærming til testing er å replikere hele produksjonsmiljøet som et testmiljø. Dette er en vanlig praksis innen programvareutvikling. Imidlertid vil en slik tilnærming i tilfelle av ML-modeller kanskje ikke gi riktig avkastning avhengig av datastørrelsen og kan påvirke modellen med tanke på forretningsproblemet den adresserer.
6. Sikkerhet – Testmiljøer forventes ofte å ha prøvedata i stedet for ekte kundedata, og som et resultat kan regler for datahåndtering og samsvar være mindre strenge. Akkurat som kostnad, men hvis du bare dupliserer produksjonsmiljøet til et testmiljø, kan du introdusere sikkerhets- og samsvarsrisikoer.
7. Funksjonsbutikkskalerbarhet – Hvis en organisasjon bestemmer seg for å ikke opprette en egen testfunksjonsbutikk på grunn av kostnads- eller sikkerhetsårsaker, må modelltesting skje i produksjonsfunksjonsbutikken, noe som kan forårsake skalerbarhetsproblemer ettersom trafikken dobles i løpet av testperioden.
8. Nettmodellytelse – Evalueringer på nettet skiller seg fra offline-evalueringer og kan være viktige i noen tilfeller som anbefalingsmodeller fordi de måler brukertilfredshet i sanntid i stedet for opplevd tilfredshet. Det er vanskelig å simulere ekte trafikkmønstre i ikke-produksjon på grunn av sesongvariasjoner eller annen brukeratferd, så online modellytelse kan bare gjøres i produksjon.
9. Operasjonell ytelse – Etter hvert som modellene blir større og i økende grad distribueres på en desentralisert måte på forskjellig maskinvare, er det viktig å teste modellen for ønsket driftsytelse som ventetid, feilfrekvens og mer.

De fleste ML-team har en flerstrenget tilnærming til modelltesting. I de følgende delene gir vi måter å møte disse utfordringene på under ulike teststadier.

Frakoblet modelltesting

Målet med denne testfasen er å validere nye versjoner av en eksisterende modell fra et nøyaktighetssynspunkt. Dette bør gjøres på en offline måte for ikke å påvirke noen spådommer i produksjonssystemet som serverer sanntidsprediksjoner. Ved å sikre at den nye modellen gir bedre resultater for gjeldende evalueringsmålinger, adresserer denne testingen utfordring 1 (modellnøyaktighetsytelse). Ved å bruke det riktige datasettet kan denne testingen også håndtere utfordring 2 og 3 (testdatakvalitet, funksjonsviktighet og paritet), med den ekstra fordelen ved å takle utfordring 5 (kostnad).

Denne fasen gjøres i scenemiljøet.

Du bør fange opp produksjonstrafikk, som du kan bruke til å spille av i offline tilbaketesting. Det er å foretrekke å bruke tidligere produksjonstrafikk i stedet for syntetiske data. De Amazon SageMaker modellmonitor fange datafunksjon lar deg fange opp produksjonstrafikk for modeller som er vert på Amazon SageMaker. Dette gjør at modellutviklere kan teste modellene sine med data fra høye arbeidsdager eller andre viktige hendelser. De fangede dataene spilles deretter av mot den nye modellversjonen på en batch-måte ved hjelp av Sagemaker batch transformasjon. Dette betyr at batchtransformasjonskjøringen kan teste med data som er samlet inn over uker eller måneder på bare noen få timer. Dette kan fremskynde modellevalueringsprosessen betydelig sammenlignet med å kjøre to eller flere versjoner av en sanntidsmodell side om side og sende dupliserte prediksjonsforespørsler til hvert endepunkt. I tillegg til å finne en versjon med bedre resultater raskere, bruker denne tilnærmingen også dataressursene i kortere tid, noe som reduserer de totale kostnadene.

En utfordring med denne tilnærmingen til testing er at funksjonssettet endres fra en modellversjon til en annen. I dette scenariet anbefaler vi at du oppretter et funksjonssett med et supersett av funksjoner for begge versjoner, slik at alle funksjoner kan spørres på en gang og registreres gjennom datafangst. Hvert prediksjonsanrop kan da fungere på bare de funksjonene som er nødvendige for den gjeldende versjonen av modellen.

Som en ekstra bonus, ved å integrere Amazon SageMaker Clarify i offline modelltesting kan du sjekke den nye versjonen av modellen for skjevhet og også sammenligne funksjonsattribusjon med den forrige versjonen av modellen. Med rørledninger kan du orkestrere hele arbeidsflyten slik at etter trening kan et kvalitetssjekktrinn finne sted for å utføre en analyse av modellberegningene og funksjonens betydning. Disse beregningene er lagret i SageMaker modellregister for sammenligning i neste treningsøkt.

Integrasjon og ytelsestesting

Integrasjonstesting er nødvendig for å validere ende-til-ende forretningsprosesser fra et funksjonelt så vel som et kjøretidsytelsesperspektiv. Innenfor denne prosessen bør hele pipelinen testes, inkludert henting og beregning av funksjoner i funksjonslageret og kjøring av ML-applikasjonen. Dette bør gjøres med en rekke forskjellige nyttelaster for å dekke en rekke scenarier og forespørsler og oppnå høy dekning for alle mulige kodekjøringer. Dette tar opp utfordring 4 og 9 (forretningsprosesstesting og operasjonell ytelse) for å sikre at ingen av forretningsprosessene brytes med den nye versjonen av modellen.

Denne testingen bør gjøres i et iscenesettelsesmiljø.

Både integrasjonstesting og ytelsestesting må implementeres av individuelle team som bruker deres MLOps-pipeline. For integrasjonstestingen anbefaler vi den velprøvde metoden for å opprettholde et funksjonelt ekvivalent preproduksjonsmiljø og teste med noen få forskjellige nyttelaster. Testarbeidsflyten kan automatiseres som vist i dette verkstedet. For ytelsestesten kan du bruke Amazon SageMaker Inference Recommender, som gir et flott utgangspunkt for å bestemme hvilken forekomsttype og hvor mange av disse forekomstene som skal brukes. For dette må du bruke et lastgeneratorverktøy, for eksempel åpen kildekode-prosjekter perfsizesagemaker og perfsize som Intuit har utviklet. Perfsizesagemaker lar deg automatisk teste modellendepunktkonfigurasjoner med en rekke nyttelaster, responstider og topptransaksjoner per sekund krav. Den genererer detaljerte testresultater som sammenligner ulike modellversjoner. Perfsize er følgeverktøyet som prøver forskjellige konfigurasjoner gitt bare topptransaksjoner per sekund og forventet responstid.

A / B-testing

I mange tilfeller der brukerreaksjoner på den umiddelbare produksjonen av modellen er nødvendig, for eksempel e-handelsapplikasjoner, er funksjonell evaluering av offline-modellen ikke tilstrekkelig. I disse scenariene må du A/B-teste modeller i produksjon før du bestemmer deg for å oppdatere modeller. A/B-testing har også sine risikoer fordi det kan være reell kundepåvirkning. Denne testmetoden fungerer som den endelige valideringen av ML-ytelse, en lettvektsteknisk fornuftssjekk. Denne metoden tar også opp utfordring 8 og 9 (online modellytelse og operasjonell fortreffelighet).

A/B-testing bør utføres i et produksjonsmiljø.

Med SageMaker kan du enkelt utføre A/B-testing på ML-modeller ved å kjøre flere produksjonsvarianter på et endepunkt. Trafikk kan rutes i trinn til den nye versjonen for å redusere risikoen for at en dårlig oppfører seg modell kan ha på produksjon. Hvis resultatene av A/B-testen ser bra ut, rutes trafikken til den nye versjonen, og tar til slutt over 100 % av trafikken. Vi anbefaler å bruke utplasseringsrekkverk for overgang fra modell A til B. For en mer fullstendig diskusjon om A/B-testing ved å bruke Amazon Tilpasse modeller som eksempel, se Bruke A / B-testing for å måle effekten av anbefalingene generert av Amazon Personalize.

Online modelltesting

I dette scenariet er den nye versjonen av en modell vesentlig forskjellig fra den som allerede betjener direktetrafikk i produksjon, så den frakoblede testmetoden er ikke lenger egnet til å bestemme effektiviteten til den nye modellversjonen. Den mest fremtredende årsaken til dette er en endring i funksjoner som kreves for å produsere prediksjonen, slik at tidligere registrerte transaksjoner ikke kan brukes til å teste modellen. I dette scenariet anbefaler vi å bruke skyggedistribusjoner. Shadow-implementeringer tilbyr muligheten til å distribuere en skygge (eller challenger) modell ved siden av produksjonen (eller Champion) modell som for øyeblikket betjener spådommer. Dette lar deg evaluere hvordan skyggemodellen presterer i produksjonstrafikk. Forutsigelsene til skyggemodellen blir ikke levert til applikasjonen som ber om; de er logget for offline evaluering. Med skyggetilnærmingen for testing tar vi tak i utfordringene 4, 5, 6 og 7 (forretningsprosesstesting, kostnad, sikkerhet og skalerbarhet av funksjonsbutikker).

Online modelltesting bør gjøres i scene- eller produksjonsmiljøer.

Denne metoden for å teste nye modellversjoner bør brukes som en siste utvei hvis alle de andre metodene ikke kan brukes. Vi anbefaler det som en siste utvei fordi dobbeltsidige anrop til flere modeller genererer ekstra belastning på alle nedstrømstjenester i produksjonen, noe som kan føre til flaskehalser i ytelsen samt økte kostnader i produksjonen. Den mest åpenbare innvirkningen dette har er på funksjonsserveringslaget. For brukstilfeller som deler funksjoner fra en felles gruppe med fysiske data, må vi kunne simulere flere brukstilfeller som samtidig får tilgang til samme datatabell for å sikre at det ikke eksisterer noen ressurskonflikt før vi går over til produksjon. Der det er mulig, bør dupliserte spørringer til funksjonslageret unngås, og funksjoner som trengs for begge versjoner av modellen bør gjenbrukes for den andre slutningen. Feature butikker basert på Amazon DynamoDB, som den Intuit har bygget, kan implementere Amazon DynamoDB Accelerator(DAX) for å cache og unngå å doble I/O til databasen. Disse og andre hurtigbufringsalternativer kan redusere utfordring 7 (skalerbarhet av funksjoner).

For å løse utfordring 5 (kostnad) så vel som 7, foreslår vi å bruke skyggedistribusjoner for å prøve den innkommende trafikken. Dette gir modelleiere et nytt lag med kontroll for å minimere innvirkningen på produksjonssystemene.

Shadow-distribusjon bør være ombord på Modellmonitor tilbud akkurat som de vanlige produksjonsdistribusjonene for å observere forbedringene til utfordrerversjonen.

konklusjonen

Dette innlegget illustrerer byggeklossene for å lage et omfattende sett med prosesser og verktøy for å møte ulike utfordringer med modelltesting. Selv om hver organisasjon er unik, bør dette hjelpe deg med å komme i gang og begrense vurderingene dine når du implementerer din egen teststrategi.

---

Om forfatterne

Tobias Wenzel er Software Engineering Manager for Intuit Machine Learning Platform i Mountain View, California. Han har jobbet på plattformen siden oppstarten i 2016 og har vært med på å designe og bygge den fra grunnen av. I jobben sin har han fokusert på plattformens operasjonelle fortreffelighet og å bringe den med suksess gjennom Intuits sesongbaserte virksomhet. I tillegg brenner han for kontinuerlig å utvide plattformen med de nyeste teknologiene.

Shivanshu Upadhyay er en hovedløsningsarkitekt i AWS Business Development and Strategic Industries-gruppen. I denne rollen hjelper han de mest avanserte brukerne av AWS med å transformere industrien ved å effektivt bruke data og AI.

Alan Tan er en senior produktsjef hos SageMaker, og leder innsatsen for store modellslutninger. Han brenner for å bruke maskinlæring på analyseområdet. Utenom jobben liker han å være ute.