Testmetoder för Amazon SageMaker ML-modeller

Det här inlägget skrevs tillsammans med Tobias Wenzel, Software Engineering Manager för Intuit Machine Learning Platform.

Vi uppskattar alla vikten av en högkvalitativ och pålitlig maskininlärningsmodell (ML) när vi använder autonom körning eller interagerar med Alexa, till exempel. ML-modeller spelar också en viktig roll på mindre uppenbara sätt – de används av affärsapplikationer, hälsovård, finansiella institutioner, amazon.com, TurboTax och mer.

Eftersom ML-aktiverade applikationer blir kärnan i många företag måste modeller följa samma kraft och disciplin som mjukvaruapplikationer. En viktig aspekt av MLOps är att leverera en ny version av den tidigare utvecklade ML-modellen i produktion genom att använda etablerade DevOps-praxis som testning, versionshantering, kontinuerlig leverans och övervakning.

Det finns flera normativ riktlinjer kring MLOps, och det här inlägget ger en översikt över processen som du kan följa och vilka verktyg du ska använda för att testa. Detta bygger på samarbeten mellan Intuit och AWS. Vi har arbetat tillsammans för att implementera rekommendationerna som förklaras i detta inlägg i praktiken och i stor skala. Intuits mål att bli en AI-driven expertplattform är starkt beroende av en strategi för att öka hastigheten för initial modellutveckling samt testning av nya versioner.

Krav

Följande är de viktigaste områdena att tänka på när nya modellversioner distribueras:

1. Modellnoggrannhet prestanda – Det är viktigt att hålla reda på av modellutvärderingsmått som noggrannhet, precision och återkallande, och se till att de objektiva mätvärdena förblir relativt desamma eller förbättras med en ny version av modellen. I de flesta fall är det inte meningsfullt att implementera en ny version av modellen om slutanvändarnas upplevelse inte förbättras.
2. Testa datakvalitet – Data i icke-produktionsmiljöer, oavsett om den är simulerad eller punkt-i-tid kopia, bör vara representativ för den data som modellen kommer att få när den är fullt utplacerad, vad gäller volym eller distribution. Om inte kommer dina testprocesser inte att vara representativa, och din modell kan bete sig annorlunda i produktionen.
3. Funktionens betydelse och paritet – Funktionens betydelse i den nyare versionen av modellen bör relativt sett jämföras med den äldre modellen, även om det kan finnas nya funktioner som introduceras. Detta för att säkerställa att modellen inte blir partisk.
4. Test av affärsprocesser – Det är viktigt att en ny version av en modell kan uppfylla dina önskade affärsmål inom acceptabla parametrar. Till exempel kan en av affärsmåtten vara att fördröjningen från slut till ände för någon tjänst inte får vara mer än 100 millisekunder, eller så kan kostnaden för att vara värd och omskola en viss modell inte vara mer än 10,000 XNUMX USD per år.
5. Pris – Ett enkelt sätt att testa är att replikera hela produktionsmiljön som en testmiljö. Detta är en vanlig praxis inom mjukvaruutveckling. Men ett sådant tillvägagångssätt i fallet med ML-modeller kanske inte ger rätt avkastning beroende på storleken på data och kan påverka modellen när det gäller det affärsproblem som den åtgärdar.
6. Säkerhet – Testmiljöer förväntas ofta ha exempeldata istället för riktiga kunddata och som ett resultat kan reglerna för datahantering och efterlevnad vara mindre strikta. Men precis som kostnaden, om du helt enkelt duplicerar produktionsmiljön till en testmiljö, kan du införa säkerhets- och efterlevnadsrisker.
7. Funktionsbutikens skalbarhet – Om en organisation bestämmer sig för att inte skapa en separat testfunktionsbutik på grund av kostnads- eller säkerhetsskäl, måste modelltestning ske på produktionsfunktionsbutiken, vilket kan orsaka skalbarhetsproblem eftersom trafiken fördubblas under testperioden.
8. Online modellprestanda – Onlineutvärderingar skiljer sig från offlineutvärderingar och kan vara viktiga i vissa fall som rekommendationsmodeller eftersom de mäter användarnöjdhet i realtid snarare än upplevd tillfredsställelse. Det är svårt att simulera verkliga trafikmönster i icke-produktion på grund av säsongsvariationer eller annat användarbeteende, så onlinemodellprestanda kan bara göras i produktion.
9. Operativ prestanda – När modellerna blir större och alltmer distribueras på ett decentraliserat sätt på olika hårdvara, är det viktigt att testa modellen för önskad operativ prestanda som latens, felfrekvens och mer.

De flesta ML-team har en mångsidig metod för modelltestning. I följande avsnitt ger vi sätt att hantera dessa utmaningar under olika teststeg.

Offline modelltestning

Målet med denna testfas är att validera nya versioner av en befintlig modell utifrån en noggrannhetssynpunkt. Detta bör göras offline för att inte påverka några förutsägelser i produktionssystemet som betjänar realtidsförutsägelser. Genom att säkerställa att den nya modellen presterar bättre för tillämpliga utvärderingsmått, löser denna testning utmaning 1 (modellens noggrannhet). Genom att använda rätt datauppsättning kan denna testning också hantera utmaningar 2 och 3 (testdatakvalitet, funktionsviktighet och paritet), med den extra fördelen att ta itu med utmaning 5 (kostnad).

Denna fas görs i iscensättningsmiljön.

Du bör fånga produktionstrafik, som du kan använda för att spela upp i offline-backtestning. Det är att föredra att använda tidigare produktionstrafik istället för syntetisk data. De Amazon SageMaker modellmonitor fånga datafunktion låter dig fånga produktionstrafik för modeller som finns på Amazon SageMaker. Detta gör att modellutvecklare kan testa sina modeller med data från toppdagar eller andra viktiga händelser. Den infångade datan spelas sedan upp mot den nya modellversionen på ett batchsätt med hjälp av Sagemaker batch transformation. Detta innebär att batchtransformeringskörningen kan testa med data som har samlats in under veckor eller månader på bara några timmar. Detta kan avsevärt påskynda modellutvärderingsprocessen jämfört med att köra två eller flera versioner av en realtidsmodell sida vid sida och skicka dubbla prediktionsförfrågningar till varje slutpunkt. Förutom att hitta en bättre presterande version snabbare, använder detta tillvägagångssätt också beräkningsresurserna under en kortare tid, vilket minskar den totala kostnaden.

En utmaning med denna metod för testning är att funktionsuppsättningen ändras från en modellversion till en annan. I det här scenariot rekommenderar vi att du skapar en funktionsuppsättning med en superset av funktioner för båda versionerna så att alla funktioner kan frågas på en gång och registreras genom datafångsten. Varje förutsägelseanrop kan då endast fungera på de funktioner som är nödvändiga för den aktuella versionen av modellen.

Som en extra bonus, genom att integrera Amazon SageMaker Clarify i din offlinemodelltestning kan du kontrollera den nya versionen av modellen för bias och även jämföra funktionstillskrivning med den tidigare versionen av modellen. Med pipelines kan du orkestrera hela arbetsflödet så att efter träningen kan en kvalitetskontroll utföras för att utföra en analys av modellens mätvärden och funktionsvikt. Dessa mätvärden lagras i SageMaker-modellregister för jämförelse i nästa träningspass.

Integration och prestandatestning

Integrationstestning behövs för att validera end-to-end affärsprocesser ur ett funktionellt såväl som ett körtidsperspektiv. Inom denna process bör hela pipelinen testas, inklusive hämtning och beräkning av funktioner i funktionslagret och körning av ML-applikationen. Detta bör göras med en mängd olika nyttolaster för att täcka en mängd olika scenarier och förfrågningar och uppnå hög täckning för alla möjliga kodkörningar. Detta tar upp utmaningarna 4 och 9 (tester av affärsprocesser och operativ prestanda) för att säkerställa att ingen av affärsprocesserna bryts med den nya versionen av modellen.

Denna testning bör göras i en iscensättningsmiljö.

Både integrationstestning och prestandatestning måste implementeras av individuella team som använder deras MLOps-pipeline. För integrationstestningen rekommenderar vi den beprövade metoden att upprätthålla en funktionellt likvärdig förproduktionsmiljö och testa med några olika nyttolaster. Testarbetsflödet kan automatiseras som visas i denna verkstad. För prestandatestning kan du använda Amazon SageMaker Inference Recommender, vilket ger en bra utgångspunkt för att avgöra vilken instanstyp och hur många av dessa instanser som ska användas. För detta måste du använda ett lastgeneratorverktyg, till exempel projekt med öppen källkod perfsizesagemaker och perfsize som Intuit har utvecklat. Perfsizesagemaker låter dig automatiskt testa modellslutpunktskonfigurationer med en mängd olika nyttolaster, svarstider och krav på topptransaktioner per sekund. Den genererar detaljerade testresultat som jämför olika modellversioner. Perfsize är det kompletterande verktyget som provar olika konfigurationer med tanke på endast de högsta transaktionerna per sekund och den förväntade svarstiden.

A / B-testning

I många fall där användarreaktion på modellens omedelbara resultat krävs, såsom e-handelsapplikationer, räcker det inte med en funktionell utvärdering av offlinemodellen. I dessa scenarier måste du A/B-testa modeller i produktion innan du fattar beslut om att uppdatera modeller. A/B-testning har också sina risker eftersom det kan bli verklig kundpåverkan. Den här testmetoden fungerar som den slutliga valideringen av ML-prestanda, en lättviktskontroll för teknisk förnuft. Denna metod hanterar även utmaningarna 8 och 9 (onlinemodellprestanda och operationell excellens).

A/B-tester bör utföras i en produktionsmiljö.

Med SageMaker kan du enkelt utföra A/B-tester på ML-modeller genom att köra flera produktionsvarianter på en slutpunkt. Trafiken kan dirigeras i steg till den nya versionen för att minska risken för att en modell som fungerar dåligt kan ha i produktionen. Om resultaten av A/B-testet ser bra ut, dirigeras trafiken till den nya versionen och tar så småningom över 100 % av trafiken. Vi rekommenderar att du använder skyddsräcken för att övergå från modell A till B. För en mer fullständig diskussion om A/B-testning med Amazon Anpassa modeller som exempel, se Använda A / B-tester för att mäta effektiviteten av rekommendationer genererade av Amazon Personalize.

Online modelltestning

I det här scenariot skiljer sig den nya versionen av en modell avsevärt från den som redan betjänar trafik i produktion, så offlinetestmetoden är inte längre lämplig för att fastställa effektiviteten av den nya modellversionen. Den mest framträdande orsaken till detta är en förändring i funktioner som krävs för att producera förutsägelsen, så att tidigare inspelade transaktioner inte kan användas för att testa modellen. I det här scenariot rekommenderar vi att du använder skuggdistributioner. Shadow-distributioner erbjuder möjligheten att distribuera en skugga (eller utmanare) modell vid sidan av produktionen (eller champion) modell som för närvarande betjänar förutsägelser. Detta låter dig utvärdera hur skuggmodellen presterar i produktionstrafik. Skuggmodellens förutsägelser skickas inte till den begärande applikationen; de loggas för offlineutvärdering. Med skuggmetoden för testning tar vi oss an utmaningarna 4, 5, 6 och 7 (tester av affärsprocesser, kostnad, säkerhet och skalbarhet för funktionsbutiker).

Online modelltestning bör göras i scener eller produktionsmiljöer.

Denna metod för att testa nya modellversioner bör användas som en sista utväg om alla andra metoder inte kan användas. Vi rekommenderar det som en sista utväg eftersom dubbelsidiga samtal till flera modeller genererar ytterligare belastning på alla nedströmstjänster i produktionen, vilket kan leda till prestandaflaskhalsar samt ökade produktionskostnader. Den mest uppenbara effekten detta har är på funktionslagret. För användningsfall som delar funktioner från en gemensam pool av fysisk data, måste vi kunna simulera flera användningsfall samtidigt som åtkomst till samma datatabell för att säkerställa att inget resurskonflikt existerar innan vi går över till produktion. När det är möjligt bör duplicerade frågor till funktionslagret undvikas, och funktioner som behövs för båda versionerna av modellen bör återanvändas för den andra slutsatsen. Feature butiker baserat på Amazon DynamoDB, som den som Intuit har byggt, kan implementera Amazon DynamoDB Accelerator(DAX) för att cache och undvika att dubbla I/O till databasen. Dessa och andra cachningsalternativ kan mildra utmaning 7 (skalbarhet för funktionslagring).

För att hantera utmaning 5 (kostnad) såväl som 7, föreslår vi att du använder skuggdistributioner för att ta prov på den inkommande trafiken. Detta ger modellägare ytterligare ett lager av kontroll för att minimera påverkan på produktionssystemen.

Shadow-distribution bör vara ombord på Modellmonitor erbjudanden precis som de vanliga produktionsinstallationerna för att observera förbättringarna av utmanarversionen.

Slutsats

Det här inlägget illustrerar byggstenarna för att skapa en omfattande uppsättning processer och verktyg för att hantera olika utmaningar med modelltestning. Även om varje organisation är unik bör detta hjälpa dig att komma igång och begränsa dina överväganden när du implementerar din egen teststrategi.

---

Om författarna

Tobias Wenzel är en Software Engineering Manager för Intuit Machine Learning Platform i Mountain View, Kalifornien. Han har arbetat på plattformen sedan starten 2016 och har hjälpt till att designa och bygga den från grunden. I sitt jobb har han fokuserat på plattformens operativa excellens och att lyckas med den genom Intuits säsongsbetonade verksamhet. Dessutom brinner han för att kontinuerligt utöka plattformen med de senaste teknologierna.

Shivanshu Upadhyay är en Principal Solutions Architect i AWS Business Development and Strategic Industries-gruppen. I den här rollen hjälper han de flesta avancerade användare av AWS att förändra sin bransch genom att effektivt använda data och AI.

Alan Tan är en Senior Product Manager hos SageMaker, som leder arbetet med att slutföra stora modeller. Han brinner för att tillämpa maskininlärning på analysområdet. Utanför jobbet tycker han om att vara utomhus.