Verbetering van de stabiliteit en flexibiliteit van ML-pijplijnen bij Amazon Packaging Innovation met Amazon SageMaker Pipelines

Om klanten tevreden te stellen en verpakkingsafval te minimaliseren, moet Amazon het optimale verpakkingstype selecteren voor miljarden pakketten die elk jaar worden verzonden. Als er te weinig bescherming wordt gebruikt voor een kwetsbaar item zoals een koffiemok, komt het item beschadigd aan en riskeert Amazon het vertrouwen van hun klant. Het gebruik van te veel bescherming zal leiden tot hogere kosten en overvolle recyclingbakken. Met honderden miljoenen producten die beschikbaar zijn, is een schaalbaar beslissingsmechanisme nodig om continu te leren van producttests en feedback van klanten.

Om deze problemen op te lossen, heeft het Amazon Packaging Innovation-team modellen voor machine learning (ML) ontwikkeld die classificeren of producten geschikt zijn voor Amazon-verpakkingen zoals mailers, tassen of dozen, of zelfs zonder extra verpakking kunnen worden verzonden. Eerder ontwikkelde het team een ​​aangepaste pijplijn op basis van: AWS Stap Functies om wekelijkse training en dagelijkse of maandelijkse gevolgtrekkingen uit te voeren. Na verloop van tijd bood de pijplijn echter niet voldoende flexibiliteit om modellen met nieuwe architecturen te lanceren. De ontwikkeling van de nieuwe pijplijnen bracht overhead met zich mee en vereiste coördinatie tussen datawetenschappers en ontwikkelaars. Om deze moeilijkheden te overwinnen en de snelheid van de implementatie van nieuwe modellen en architecturen te verbeteren, koos het team ervoor om modeltraining en inferentie te orkestreren met Amazon SageMaker-pijpleidingen.

In dit bericht bespreken we de eerdere orkestratie-architectuur op basis van Step Functions, schetsen we training en inferentie-architecturen met behulp van Pipelines en benadrukken we de flexibiliteit die het Amazon Packaging Innovation-team heeft bereikt.

Uitdagingen van de voormalige ML-pijplijn bij Amazon Packaging Innovation

Om continue feedback over de prestaties van verpakkingen op te nemen, wordt elke week een nieuw model getraind met behulp van een groeiend aantal labels. De inferentie voor de gehele productvoorraad wordt maandelijks uitgevoerd, en een dagelijkse inferentie wordt uitgevoerd om just-in-time voorspellingen te leveren voor de nieuw toegevoegde voorraad.

Om het proces van het trainen van meerdere modellen te automatiseren en voorspellingen te doen, had het team een ​​aangepaste pijplijn ontwikkeld op basis van Step Functions om de volgende stappen te orkestreren:

• Gegevensvoorbereiding voor trainings- en inferentietaken en het laden van voorspellingen in de database (Amazon roodverschuiving) Met AWS lijm.
• Modeltraining en gevolgtrekking met Amazon Sage Maker.
• Berekening van modelprestatiestatistieken op de validatieset met AWS-batch.
• gebruik Amazon DynamoDB om modelconfiguraties op te slaan (zoals de gegevenssplitsingsratio voor training en validatie, de locatie van het modelartefact, het modeltype en het aantal instanties voor training en inferentie), modelprestatiestatistieken en de nieuwste succesvol getrainde modelversie.
• Berekening van de verschillen in de prestatiescores van het model, veranderingen in de distributie van de trainingslabels en het vergelijken van de grootte van de invoergegevens tussen de vorige en de nieuwe modelversies met AWS Lambda functies.
• Gezien het grote aantal stappen vereiste de pijplijn ook een betrouwbaar alarmsysteem bij elke stap om de belanghebbenden op de hoogte te stellen van eventuele problemen. Dit werd bereikt door een combinatie van Amazon Simple Queue-service (Amazon SQS) en Amazon eenvoudige meldingsservice (Amazon SNS). De alarmen zijn gemaakt om de zakelijke belanghebbenden, datawetenschappers en ontwikkelaars op de hoogte te stellen van mislukte stappen en grote afwijkingen in het model en de gegevensstatistieken.

Na bijna 2 jaar deze oplossing te hebben gebruikt, realiseerde het team zich dat deze implementatie alleen goed werkte voor een typische ML-workflow waarbij een enkel model werd getraind en gescoord op een validatiedataset. De oplossing was echter niet flexibel genoeg voor complexe modellen en was niet bestand tegen storingen. De architectuur was bijvoorbeeld niet gemakkelijk geschikt voor sequentiële modeltraining. Het was moeilijk om een ​​stap toe te voegen of te verwijderen zonder de hele pijplijn te dupliceren en de infrastructuur aan te passen. Zelfs eenvoudige wijzigingen in de gegevensverwerkingsstappen, zoals het aanpassen van de gegevenssplitsingsratio of het selecteren van een andere set functies, vereisten coördinatie van zowel een datawetenschapper als een ontwikkelaar. Wanneer de pijplijn bij welke stap dan ook faalde, moest deze vanaf het begin opnieuw worden opgestart, wat resulteerde in herhaalde runs en hogere kosten. Om herhaalde runs te voorkomen en opnieuw te moeten starten vanaf de mislukte stap, zou het team een ​​nieuwe kopie maken van een verkorte toestandsmachine. Deze probleemoplossing leidde tot een wildgroei van de staatsmachines, elk beginnend met de vaak falende stappen. Ten slotte, als een trainingstaak een afwijking tegenkwam in de distributie van labels, modelscore of aantal labels, moest een datawetenschapper het model en de bijbehorende metrieken handmatig beoordelen. Vervolgens zou een datawetenschapper toegang krijgen tot een DynamoDB-tabel met de modelversies en de tabel bijwerken om ervoor te zorgen dat het juiste model werd gebruikt voor de volgende inferentietaak.

Het onderhoud van deze architectuur vereiste ten minste één toegewijde resource en een extra fulltime resource voor ontwikkeling. Gezien de moeilijkheden bij het uitbreiden van de pijplijn om nieuwe gebruiksscenario's mogelijk te maken, waren de datawetenschappers begonnen met het ontwikkelen van hun eigen workflows, wat op zijn beurt had geleid tot een groeiende codebasis, meerdere datatabellen met vergelijkbare dataschema's en gedecentraliseerde modelmonitoring. De opeenstapeling van deze problemen had geleid tot een lagere teamproductiviteit en meer overhead.

Om deze uitdagingen aan te gaan, heeft het Amazon Packaging Innovation-team andere bestaande oplossingen voor MLOps geëvalueerd, waaronder SageMaker Pipelines (Release-aankondiging december 2020). Pipelines is een mogelijkheid van SageMaker voor het bouwen, beheren, automatiseren en schalen van end-to-end ML-workflows. Met pijplijnen kunt u het aantal stappen in de gehele ML-workflow verminderen en is het flexibel genoeg om datawetenschappers in staat te stellen een aangepaste ML-workflow te definiëren. Het zorgt voor het monitoren en loggen van de stappen. Het wordt ook geleverd met een modelregister dat automatisch nieuwe modellen versiert. Het modelregister heeft ingebouwde goedkeuringsworkflows om modellen te selecteren voor inferentie in productie. Met pijplijnen kunnen ook caching-stappen worden aangeroepen met dezelfde argumenten. Als een eerdere run wordt gevonden, wordt een cache gemaakt, die een gemakkelijke herstart mogelijk maakt in plaats van de met succes voltooide stappen opnieuw te berekenen.

In het evaluatieproces onderscheidde Pipelines zich van de andere oplossingen vanwege de flexibiliteit en beschikbaarheid van functies voor het ondersteunen en uitbreiden van huidige en toekomstige workflows. Door over te schakelen naar Pipelines hebben ontwikkelaars tijd vrijgemaakt van platformonderhoud en probleemoplossing en werd de aandacht verlegd naar de toevoeging van de nieuwe functies. In dit bericht presenteren we het ontwerp voor trainings- en inferentieworkflows bij het Amazon Packaging Innovation-team met behulp van Pipelines. Ook bespreken we de voordelen en de kostenbesparingen die het team realiseerde door over te stappen op Pipelines.

Trainingspijplijn

Het Amazon Packaging Innovation-team traint modellen voor elk type verpakking met behulp van een groeiend aantal labels. Het volgende schema geeft het hele proces weer.

De workflow begint met het extraheren van labels en functies uit een Amazon Redshift-database en het ontladen van de gegevens naar Amazon eenvoudige opslagservice (Amazon S3) via een geplande taak voor extraheren, transformeren en laden (ETL). Samen met de invoergegevens wordt een bestandsobject met het modeltype en de parameters in de S3-bucket geplaatst. Dit bestand dient als de pijplijntrigger via een Lambda-functie.

De volgende stappen zijn volledig aanpasbaar en worden volledig gedefinieerd door een datawetenschapper die de SageMaker Python SDK for Pipelines gebruikt. In het scenario dat we in dit bericht presenteren, worden de invoergegevens opgesplitst in trainings- en validatiesets en weer opgeslagen in een S3-bucket door een SageMaker Processing-taak te starten.

Wanneer de gegevens gereed zijn in Amazon S3, begint een SageMaker-trainingstaak. Nadat het model met succes is getraind en gemaakt, wordt de modelevaluatiestap uitgevoerd op de validatiegegevens via een batchtransformatietaak van SageMaker. De modelstatistieken worden vervolgens vergeleken met de modelstatistieken van de vorige week met behulp van een SageMaker Processing-taak. Het team heeft meerdere aangepaste criteria gedefinieerd voor het evalueren van afwijkingen in de modelprestaties. Op basis van deze criteria wordt het model afgewezen of goedgekeurd. Als het model wordt afgewezen, wordt het vorige goedgekeurde model gebruikt voor de volgende inferentietaken. Als het model wordt goedgekeurd, wordt de versie ervan geregistreerd en wordt dat model gebruikt voor inferentietaken. De stakeholders krijgen bericht over de uitkomst via Amazon Cloud Watch alarmen.

De volgende schermafbeelding van Amazon SageMaker Studio toont de stappen van de trainingspijplijn.

Met pijplijnen wordt elke pijplijnuitvoering bijgehouden, die u kunt controleren in Studio. Als alternatief kunt u de voortgang van de run opvragen met Boto3 of de AWS-opdrachtregelinterface (AWS CLI). U kunt de modelstatistieken in Studio visualiseren en verschillende modelversies vergelijken.

Inferentie pijplijn

Het Amazon Packaging Innovation-team ververst maandelijks de voorspellingen voor de volledige productvoorraad. Dagelijkse voorspellingen worden gegenereerd om just-in-time verpakkingsaanbevelingen te geven voor nieuw toegevoegde voorraad met behulp van het nieuwste getrainde model. Dit vereist dat de inferentiepijplijn dagelijks wordt uitgevoerd met verschillende gegevensvolumes. Het volgende diagram illustreert deze workflow.

Net als bij de trainingspijplijn begint de gevolgtrekking met het lossen van de gegevens van Amazon Redshift naar een S3-bucket. Een bestandsobject dat in Amazon S3 is geplaatst, activeert de Lambda-functie die de inferentiepijplijn initieert. De functies zijn voorbereid op gevolgtrekking en de gegevens worden gesplitst in bestanden van de juiste grootte met behulp van een SageMaker Processing-taak. Vervolgens identificeert de pijplijn het nieuwste goedgekeurde model om de voorspellingen uit te voeren en deze in een S3-bucket te laden. Ten slotte worden de voorspellingen teruggeladen naar Amazon Redshift met behulp van de boto3-data API binnen de SageMaker Processing-taak.

De volgende schermafbeelding van Studio toont de details van de inferentiepijplijn.

Voordelen van kiezen om ML-workflows te ontwerpen met SageMaker Pipelines

In deze sectie bespreken we de voordelen die het Amazon Packaging Innovation-team realiseerde door over te schakelen naar Pipelines voor modeltraining en inferentie.

Kant-en-klare MLOps-functies op productieniveau

Tijdens het vergelijken van verschillende interne en externe oplossingen voor de volgende ML-pipeline-oplossing, kon een enkele datawetenschapper in minder dan 3 weken een prototype maken en ontwikkelen van een volledige versie van een ML-workflow met Pipelines in een Studio Jupyter-omgeving. Zelfs in de prototypingfase werd het duidelijk dat Pipelines alle noodzakelijke infrastructuurcomponenten leverde die nodig zijn voor een workflow op productieniveau: modelversiebeheer, caching en alarmen. De onmiddellijke beschikbaarheid van deze functies betekende dat er geen extra tijd zou worden besteed aan het ontwikkelen en aanpassen ervan. Dit was een duidelijke demonstratie van waarde, die het Amazon Packaging Innovation-team ervan overtuigde dat Pipelines de juiste oplossing was.

Flexibiliteit bij het ontwikkelen van ML-modellen

De grootste winst voor de datawetenschappers in het team was de mogelijkheid om gemakkelijk te experimenteren en verschillende modellen te doorlopen. Ongeacht welk framework ze de voorkeur gaven voor hun ML-werk en het aantal stappen en functies dat het met zich meebracht, Pipelines kwam tegemoet aan hun behoeften. De datawetenschappers kregen de mogelijkheid om te experimenteren zonder te hoeven wachten op de sprint voor softwareontwikkeling om een ​​extra functie of stap toe te voegen.

Lagere kosten

De Pipelines-mogelijkheid van SageMaker is: gratis: u betaalt alleen voor de rekenbronnen en de opslag die is gekoppeld aan training en inferentie. Als u echter over de kosten nadenkt, moet u niet alleen rekening houden met de kosten van de gebruikte services, maar ook met de ontwikkeluren die nodig zijn om de workflow te onderhouden, te debuggen en te patchen. Het orkestreren met Pipelines is eenvoudiger omdat het uit minder stukken en vertrouwde infrastructuur bestaat. Voorheen waren er voor het toevoegen van een nieuwe functie minimaal twee mensen (datawetenschapper en software-engineer) bij het Amazon Packaging Innovation-team nodig om deze te implementeren. Met de opnieuw ontworpen pijplijn zijn de technische inspanningen nu gericht op aanvullende aangepaste infrastructuur rond de pijplijn, zoals het creëren van een enkele opslagplaats voor het volgen van de machine learning-code, vereenvoudiging van de modelimplementatie over AWS-accounts, ontwikkeling van de geïntegreerde ETL-taken en gemeenschappelijke herbruikbare functies.

De mogelijkheid om de stappen met een vergelijkbare invoer te cachen, droeg ook bij aan de kostenverlaging, omdat de teams minder snel de hele pijplijn opnieuw zouden uitvoeren. In plaats daarvan zouden ze het gemakkelijk kunnen starten vanaf het punt van falen.

Conclusie

Het Amazon Packaging Innovation-team traint maandelijks ML-modellen en werkt regelmatig voorspellingen bij voor de aanbevolen productverpakkingstypes. Deze aanbevelingen hielpen hen om meerdere team- en bedrijfsbrede doelen te bereiken door verspilling te verminderen en klanten blij te maken met elke bestelling. De trainings- en inferentiepijplijnen moeten regelmatig betrouwbaar werken, maar moeten de modellen constant kunnen verbeteren.

Door over te stappen op Pipelines kon het team vier nieuwe multimodale modelarchitecturen in productie nemen in minder dan 2 maanden. Het implementeren van een nieuw model met de vorige architectuur zou 5 dagen (met dezelfde modelarchitectuur) tot 1 maand (met een nieuwe modelarchitectuur) hebben gekost. Door hetzelfde model te implementeren met behulp van Pipelines, kon het team de ontwikkelingstijd verkorten tot 4 uur met dezelfde modelarchitectuur en tot 5 dagen met een nieuwe modelarchitectuur. Dat komt neer op een besparing van bijna 80% van de werkuren.

Extra middelen

Raadpleeg de volgende bronnen voor meer informatie:

---

Over de auteurs

Ankur Shukla is een Principal Data Scientist bij AWS-ProServe in Palo Alto. Ankur heeft meer dan 15 jaar advieservaring door rechtstreeks met de klant samen te werken en hen te helpen bij het oplossen van zakelijke problemen met technologie. Hij leidt meerdere wereldwijde toegepaste wetenschappelijke en ML-Ops-initiatieven binnen AWS. In zijn vrije tijd leest hij graag en brengt hij tijd door met het gezin.

Akasha Singla is een Sr. System Dev Engineer bij het Amazon Packaging Innovation-team. Hij heeft meer dan 17 jaar ervaring met het oplossen van kritieke bedrijfsproblemen door middel van technologie voor verschillende bedrijfsverticalen. Hij richt zich momenteel op het upgraden van de NAWS-infrastructuur voor verschillende verpakkingsgerichte toepassingen om ze beter te schalen.

Vitalina Komashko is een datawetenschapper bij AWS Professional Services. Ze is gepromoveerd in farmacologie en toxicologie, maar stapte over naar datawetenschap van experimenteel werk omdat ze "eigendom wilde worden van het genereren van gegevens en de interpretatie van de resultaten". Eerder in haar carrière werkte ze met biotech- en farmaceutische bedrijven. Bij AWS vindt ze het leuk om problemen voor klanten uit verschillende sectoren op te lossen en te leren over hun unieke uitdagingen.

Prasanth Meiyappan is al meer dan 4 jaar Sr. Applied Scientist bij Amazon Packaging Innovation. Hij heeft meer dan 6 jaar ervaring in de branche op het gebied van machine learning en heeft producten geleverd om de klantervaring bij het zoeken en de verpakkingservaring van klanten te verbeteren. Prasanth is gepassioneerd door duurzaamheid en heeft een doctoraat in statistische modellering van klimaatverandering.

Matthijs Bales is een Sr. Research Scientist die werkt aan het optimaliseren van de selectie van pakkettypes met behulp van feedback van klanten en machine learning. Voordat hij bij Amazon kwam, werkte Matt als postdoc die simulaties van deeltjesfysica uitvoerde in Duitsland en in een vorig leven als productiemanager van radioactieve medische implantaten in een startup. Hij heeft een Ph.D. in natuurkunde aan de Universiteit van Michigan.