Benaderingen testen voor Amazon SageMaker ML-modellen

Heruitgegeven door Plato

volgers: 0

Dit bericht is geschreven in samenwerking met Tobias Wenzel, Software Engineering Manager voor het Intuit Machine Learning Platform.

We waarderen allemaal het belang van een hoogwaardig en betrouwbaar model voor machine learning (ML) bij bijvoorbeeld autonoom rijden of interactie met Alexa. ML-modellen spelen ook een belangrijke rol op minder voor de hand liggende manieren: ze worden gebruikt door zakelijke toepassingen, gezondheidszorg, financiële instellingen, amazon.com, TurboTax en meer.

Aangezien ML-toepassingen de kern van veel bedrijven worden, moeten modellen dezelfde kracht en discipline volgen als softwaretoepassingen. Een belangrijk aspect van MLOps is om een nieuwe versie van het eerder ontwikkelde ML-model in productie te brengen door gebruik te maken van gevestigde DevOps-praktijken zoals testen, versiebeheer, continue levering en monitoring.

Er zijn verschillende voorschrijvend richtlijnen rond MLOps, en dit bericht geeft een overzicht van het proces dat je kunt volgen en welke tools je moet gebruiken voor het testen. Dit is gebaseerd op samenwerkingen tussen Intuit en AWS. We hebben samengewerkt om de aanbevelingen die in dit bericht worden uitgelegd in de praktijk en op grote schaal te implementeren. Intuit's doel om een AI-gestuurd expertplatform is sterk afhankelijk van een strategie van toenemende snelheid van initiële modelontwikkeling en het testen van nieuwe versies.

Voorwaarden

Dit zijn de belangrijkste aandachtspunten bij het implementeren van nieuwe modelversies:

Prestaties van modelnauwkeurigheid - Het is belangrijk om bijhouden van modelevaluatiestatistieken zoals nauwkeurigheid, precisie en terugroepactie, en ervoor te zorgen dat de objectieve metrieken relatief hetzelfde blijven of verbeteren met een nieuwe versie van het model. In de meeste gevallen heeft het geen zin om een nieuwe versie van het model te implementeren als de ervaring van eindgebruikers niet verbetert.
Kwaliteit van testgegevens – Gegevens in niet-productieomgevingen, of ze nu gesimuleerd zijn of een kopie op een bepaald tijdstip, moeten representatief zijn voor de gegevens die het model zal ontvangen wanneer het volledig is geïmplementeerd, in termen van volume of distributie. Als dit niet het geval is, zijn uw testprocessen niet representatief en kan uw model zich tijdens de productie anders gedragen.
Functiebelang en pariteit – Het belang van functies in de nieuwere versie van het model moet relatief vergelijkbaar zijn met het oudere model, hoewel er mogelijk nieuwe functies zijn geïntroduceerd. Dit is om ervoor te zorgen dat het model niet bevooroordeeld wordt.
Testen van bedrijfsprocessen – Het is belangrijk dat een nieuwe versie van een model binnen acceptabele parameters aan uw vereiste bedrijfsdoelstellingen kan voldoen. Een van de bedrijfsstatistieken kan bijvoorbeeld zijn dat de end-to-end latentie voor een service niet meer dan 100 milliseconden mag zijn, of dat de kosten voor het hosten en opnieuw trainen van een bepaald model niet meer dan $ 10,000 per jaar mogen zijn.
Kosten – Een eenvoudige benadering van testen is om de hele productieomgeving te repliceren als een testomgeving. Dit is een gangbare praktijk bij softwareontwikkeling. Een dergelijke benadering in het geval van ML-modellen levert mogelijk niet de juiste ROI op, afhankelijk van de grootte van de gegevens, en kan van invloed zijn op het model in termen van het zakelijke probleem dat het aanpakt.
Security – Van testomgevingen wordt vaak verwacht dat ze voorbeeldgegevens hebben in plaats van echte klantgegevens en als gevolg daarvan kunnen de gegevensverwerking en complianceregels minder streng zijn. Net als de kosten, zou je, als je de productieomgeving gewoon dupliceert naar een testomgeving, beveiligings- en compliancerisico's kunnen introduceren.
Schaalbaarheid van functieopslag – Als een organisatie besluit om om kosten- of veiligheidsredenen geen aparte testfunctieopslag te maken, moeten modeltests plaatsvinden in de productiefunctieopslag, wat schaalbaarheidsproblemen kan veroorzaken omdat het verkeer tijdens de testperiode wordt verdubbeld.
Prestaties van online modellen – Online evaluaties verschillen van offline evaluaties en kunnen in sommige gevallen belangrijk zijn, zoals aanbevelingsmodellen, omdat ze de gebruikerstevredenheid in realtime meten in plaats van de waargenomen tevredenheid. Het is moeilijk om echte verkeerspatronen in niet-productie te simuleren vanwege seizoensinvloeden of ander gebruikersgedrag, dus online modelprestaties kunnen alleen in productie worden gedaan.
Operationele prestatie – Naarmate modellen groter worden en steeds meer gedecentraliseerd op verschillende hardware worden ingezet, is het belangrijk om het model te testen op de door u gewenste operationele prestaties, zoals latentie, foutenpercentage en meer.

De meeste ML-teams hebben een meervoudige benadering voor het testen van modellen. In de volgende secties bieden we manieren om deze uitdagingen aan te pakken tijdens verschillende testfasen.

Offline model testen

Het doel van deze testfase is om nieuwe versies van een bestaand model te valideren vanuit het oogpunt van nauwkeurigheid. Dit moet op een offline manier worden gedaan om geen invloed te hebben op voorspellingen in het productiesysteem die realtime voorspellingen dienen. Door ervoor te zorgen dat het nieuwe model beter presteert voor toepasselijke evaluatiestatistieken, lost deze test uitdaging 1 (modelnauwkeurigheidsprestaties) op. Door de juiste dataset te gebruiken, kan deze test ook uitdagingen 2 en 3 (testgegevenskwaliteit, functiebelang en pariteit) aanpakken, met als bijkomend voordeel dat ze uitdaging 5 (kosten) aanpakken.

Deze fase wordt uitgevoerd in de staging-omgeving.

U moet productieverkeer vastleggen, dat u kunt gebruiken om opnieuw af te spelen in offline back-tests. Het verdient de voorkeur om eerdere productieverkeer te gebruiken in plaats van synthetische gegevens. De Amazon SageMaker-modelmonitor functie voor het vastleggen van gegevens stelt u in staat om productieverkeer vast te leggen voor modellen die worden gehost op Amazon Sage Maker. Hierdoor kunnen modelontwikkelaars hun modellen testen met gegevens van piekwerkdagen of andere belangrijke gebeurtenissen. De vastgelegde gegevens worden vervolgens in batch opnieuw afgespeeld tegen de nieuwe modelversie met behulp van Sagemaker batch-transformatie. Dit betekent dat de batchtransformatierun in slechts een paar uur kan testen met gegevens die over weken of maanden zijn verzameld. Dit kan het modelevaluatieproces aanzienlijk versnellen in vergelijking met het naast elkaar uitvoeren van twee of meer versies van een realtime model en het verzenden van dubbele voorspellingsverzoeken naar elk eindpunt. Naast het sneller vinden van een beter presterende versie, gebruikt deze aanpak ook de rekenresources voor een kortere tijd, waardoor de totale kosten worden verlaagd.

Een uitdaging bij deze benadering van testen is dat de functieset van de ene modelversie naar de andere verandert. In dit scenario raden we aan een functieset te maken met een superset van functies voor beide versies, zodat alle functies tegelijk kunnen worden opgevraagd en vastgelegd via het vastleggen van gegevens. Elke voorspellingsaanroep kan dan alleen werken aan die functies die nodig zijn voor de huidige versie van het model.

Als een toegevoegde bonus, door te integreren Amazon SageMaker verduidelijken in uw offline modeltests kunt u de nieuwe versie van het model controleren op vooringenomenheid en ook de kenmerktoewijzing vergelijken met de vorige versie van het model. Met pijplijnen kunt u de gehele workflow zo orkestreren dat na de training een kwaliteitscontrolestap kan plaatsvinden om een analyse uit te voeren van de modelstatistieken en het belang van functies. Deze statistieken worden opgeslagen in de SageMaker-modelregister ter vergelijking bij de volgende training.

Integratie en prestatietesten

Integratietesten zijn nodig om end-to-end bedrijfsprocessen te valideren vanuit zowel functioneel als runtime prestatieperspectief. Binnen dit proces moet de hele pijplijn worden getest, inclusief het ophalen en berekenen van functies in de feature store en het uitvoeren van de ML-toepassing. Dit moet worden gedaan met een verscheidenheid aan verschillende payloads om een verscheidenheid aan scenario's en verzoeken te dekken en een hoge dekking te bereiken voor alle mogelijke coderuns. Hiermee worden uitdagingen 4 en 9 (testen van bedrijfsprocessen en operationele prestaties) aangepakt om ervoor te zorgen dat geen van de bedrijfsprocessen wordt verbroken met de nieuwe versie van het model.

Deze test moet worden gedaan in een staging-omgeving.

Zowel integratietesten als prestatietests moeten worden geïmplementeerd door individuele teams met behulp van hun MLOps-pijplijn. Voor de integratietests raden we de beproefde methode aan om een functioneel gelijkwaardige preproductieomgeving te onderhouden en te testen met een paar verschillende payloads. De testworkflow kan worden geautomatiseerd zoals weergegeven in deze workshop. Voor de prestatietests kunt u gebruik maken van: Amazon SageMaker Inferentie-aanbeveler, wat een goed startpunt biedt om te bepalen welk instantietype en hoeveel van die instanties moeten worden gebruikt. Hiervoor moet je een tool voor het genereren van belasting gebruiken, zoals de open-sourceprojecten perfsizesagemaker en prestatiemaat dat Intuit heeft ontwikkeld. Met Perfsizesagemaker kunt u automatisch modeleindpuntconfiguraties testen met een verscheidenheid aan payloads, responstijden en piektransacties per seconde. Het genereert gedetailleerde testresultaten die verschillende modelversies vergelijken. Perfsize is de begeleidende tool die verschillende configuraties uitprobeert, alleen gegeven de piektransacties per seconde en de verwachte responstijd.

A / B-testen

In veel gevallen waar gebruikersreacties op de onmiddellijke uitvoer van het model vereist zijn, zoals bij e-commercetoepassingen, is de functionele evaluatie van het offline model niet voldoende. In deze scenario's moet u modellen in productie A/B-testen voordat u de beslissing neemt om modellen bij te werken. A/B-testen heeft ook zijn risico's, omdat er een echte impact op de klant kan zijn. Deze testmethode dient als de laatste ML-prestatievalidatie, een lichtgewicht technische sanity check. Deze methode gaat ook in op uitdagingen 8 en 9 (online modelprestaties en operationele uitmuntendheid).

A/B-testen moeten worden uitgevoerd in een productieomgeving.

Met SageMaker kunt u eenvoudig A/B-testen uitvoeren op ML-modellen door te draaien meerdere productievarianten op een eindpunt. Verkeer kan stapsgewijs naar de nieuwe versie worden geleid om het risico te verkleinen dat een slecht gedragend model bij de productie zou kunnen hebben. Als de resultaten van de A/B-test er goed uitzien, wordt het verkeer naar de nieuwe versie geleid, waardoor uiteindelijk 100% van het verkeer wordt overgenomen. We raden aan om vangrails te gebruiken voor de overgang van model A naar B. Voor een meer complete discussie over A/B-testen met: Amazon personaliseren modellen als voorbeeld, zie: A / B-tests gebruiken om de doeltreffendheid te meten van aanbevelingen die zijn gegenereerd door Amazon Personalize.

Online model testen

In dit scenario verschilt de nieuwe versie van een model aanzienlijk van de versie die al live verkeer in productie bedient, dus de offline testbenadering is niet langer geschikt om de doeltreffendheid van de nieuwe modelversie te bepalen. De meest prominente reden hiervoor is een wijziging in functies die nodig zijn om de voorspelling te produceren, zodat eerder geregistreerde transacties niet kunnen worden gebruikt om het model te testen. In dit scenario raden we aan om schaduwimplementaties te gebruiken. Schaduwimplementaties bieden de mogelijkheid om een schaduw (of uitdager) model naast de productie (of kampioen) model dat momenteel voorspellingen dient. Hiermee kunt u evalueren hoe het schaduwmodel presteert in productieverkeer. De voorspellingen van het schaduwmodel worden niet geleverd aan de aanvragende applicatie; ze zijn aangemeld voor offline evaluatie. Met de schaduwaanpak voor testen pakken we uitdagingen 4, 5, 6 en 7 aan (testen van bedrijfsprocessen, kosten, beveiliging en schaalbaarheid van featurestores).

Het online testen van modellen moet worden gedaan in staging- of productieomgevingen.

Deze methode voor het testen van nieuwe modelversies moet als laatste redmiddel worden gebruikt als alle andere methoden niet kunnen worden gebruikt. We raden het aan als laatste redmiddel, omdat het duplexen van oproepen naar meerdere modellen extra belasting genereert voor alle downstream-services in productie, wat kan leiden tot prestatieknelpunten en tot hogere productiekosten. De meest voor de hand liggende impact die dit heeft, is op de functieweergavelaag. Voor use-cases die functies delen uit een gemeenschappelijke pool van fysieke gegevens, moeten we in staat zijn om meerdere use-cases te simuleren die gelijktijdig toegang hebben tot dezelfde gegevenstabel om ervoor te zorgen dat er geen resourceconflict bestaat voordat we overgaan op productie. Waar mogelijk moeten dubbele zoekopdrachten naar de feature store worden vermeden, en functies die nodig zijn voor beide versies van het model moeten opnieuw worden gebruikt voor de tweede inferentie. Feature stores op basis van Amazon DynamoDB, zoals degene die Intuit heeft gebouwd, kan implementeren Amazon DynamoDB-versneller(DAX) om te cachen en te voorkomen dat de I/O naar de database wordt verdubbeld. Deze en andere caching-opties kunnen uitdaging 7 (schaalbaarheid van functiewinkels) verminderen.

Om zowel uitdaging 5 (kosten) als 7 aan te pakken, stellen we voor om schaduwimplementaties te gebruiken om het inkomende verkeer te samplen. Dit geeft modeleigenaren een extra controlelaag om de impact op de productiesystemen te minimaliseren.

Schaduwimplementatie moet aan boord zijn van de Modelmonitor aanbod net als de reguliere productie-implementaties om de verbeteringen van de challenger-versie te observeren.

Conclusie

Dit bericht illustreert de bouwstenen om een uitgebreide set processen en tools te creëren om verschillende uitdagingen met modeltests aan te pakken. Hoewel elke organisatie uniek is, zou dit u moeten helpen om aan de slag te gaan en uw overwegingen te verfijnen bij het implementeren van uw eigen teststrategie.

Over de auteurs

Tobias Wenzel is een Software Engineering Manager voor het Intuit Machine Learning Platform in Mountain View, Californië. Hij werkt sinds de oprichting in 2016 aan het platform en heeft het vanaf de grond af ontworpen en opgebouwd. In zijn werk heeft hij zich gericht op de operationele uitmuntendheid van het platform en dit met succes door de seizoensactiviteiten van Intuit te brengen. Daarnaast is hij gepassioneerd om het platform continu uit te breiden met de nieuwste technologieën.

Shivanshu Upadhyay is Principal Solutions Architect in de AWS Business Development and Strategic Industries-groep. In deze rol helpt hij de meest geavanceerde gebruikers van AWS om hun branche te transformeren door effectief gebruik te maken van data en AI.

Alan Tan is Senior Product Manager bij SageMaker en leidt inspanningen op het gebied van grote modelinferentie. Hij heeft een passie voor het toepassen van machine learning op het gebied van analytics. Buiten zijn werk geniet hij van het buitenleven.