MlOps-framework (Machine Learning Operations) om de levenscyclus van machine learning te verbeteren met Azure Machine Learning

Dit klantproject hielp een Fortune 500 food company zijn vraagprognoses te verbeteren. Het bedrijf verzendt producten rechtstreeks naar meerdere winkels. Dankzij de verbetering konden ze de voorraad van hun producten in verschillende winkels in verschillende regio's van de Verenigde Staten optimaliseren. Om dit te bereiken, heeft het CSE-team (Commercial Software Engineering) van Microsoft samengewerkt met de gegevenswetenschappers van de klant aan een pilotstudie om aangepaste machine learning-modellen voor de geselecteerde regio's te ontwikkelen. Bij de modellen wordt rekening gehouden met:

• Demografische gegevens van klanten
• Historisch en voorspeld weer
• Eerdere zendingen
• Product retourneert
• Speciale gebeurtenissen

Het doel om voorraad te optimaliseren vertegenwoordigde een belangrijk onderdeel van het project en de klant realiseerde een aanzienlijke verkooplift in de vroege veldproeven. Daarnaast zag het team een vermindering van 40% in het voorspellen van gemiddelde absolute percentagefout (MAPE) in vergelijking met een historisch gemiddelde basislijnmodel.

Een belangrijk onderdeel van het project was het opschalen van de data science-werkstroom van de testfase naar een productieniveau. Voor deze werkstroom op productieniveau heeft het CSE-team het volgende nodig:

• Ontwikkel modellen voor veel regio's.
• Continu de prestaties van de modellen bijwerken en bewaken.
• Vergemakkelijken de samenwerking tussen de data- en engineeringteams.

De typische data science-werkstroom is tegenwoordig dichter bij een eenmalige testomgeving dan een productiewerkstroom. Een omgeving voor gegevenswetenschappers moet geschikt zijn om:

• Bereid de gegevens voor.
• Experimenteer met verschillende modellen.
• Hyperparameters afstemmen.
• Maak een build-test-evaluate-refine-cyclus.

De meeste hulpprogramma's die voor deze taken worden gebruikt, hebben specifieke doeleinden en zijn niet geschikt voor automatisering. In een machine learning-bewerking op productieniveau moet er meer aandacht worden besteed aan het beheer van de levenscyclus van toepassingen en DevOps.

Het CSE-team heeft de client geholpen bij het omhoog schalen van de bewerking naar productieniveaus. Ze hebben verschillende aspecten van de mogelijkheden voor continue integratie en continue levering (CI/CD) geïmplementeerd en problemen zoals waarneembaarheid en integratie met Azure-mogelijkheden opgelost. Tijdens de implementatie ontdekte het team hiaten in bestaande MLOps-richtlijnen. Deze hiaten moesten worden opgevuld, zodat MLOps beter op schaal werd begrepen en toegepast.

Door mlOps-procedures te begrijpen, kunnen organisaties ervoor zorgen dat de machine learning-modellen die het systeem produceert, kwaliteitsmodellen voor productie zijn die de bedrijfsprestaties verbeteren. Wanneer MLOps wordt geïmplementeerd, hoeft de organisatie niet langer zoveel tijd te besteden aan details op laag niveau met betrekking tot de infrastructuur- en technische werkzaamheden die nodig zijn om machine learning-modellen te ontwikkelen en uit te voeren voor bewerkingen op productieniveau. Het implementeren van MLOps helpt ook de data science- en software-engineeringcommunities om samen te werken om een productieklaar systeem te leveren.

Het CSE-team heeft dit project gebruikt om tegemoet te komen aan machine learning-communitybehoeften door problemen op te lossen, zoals het ontwikkelen van een MLOps-volwassen model. Deze inspanningen waren gericht op het verbeteren van de MLOps-acceptatie door inzicht te krijgen in de typische uitdagingen van de belangrijkste spelers in het MLOps-proces.

Betrokkenheids- en technische scenario's

In het betrokkenheidsscenario worden de echte uitdagingen besproken die het CSE-team moest oplossen. Het technische scenario definieert de vereisten voor het maken van een MLOps-levenscyclus die net zo betrouwbaar is als de gevestigde DevOps-levenscyclus.

Betrokkenheidsscenario

De klant levert producten rechtstreeks aan detailhandelswinkels volgens een regelmatig schema. Elke verkooppunt varieert in de gebruikspatronen van het product, dus de productinventaris moet variëren in elke wekelijkse levering. Het maximaliseren van de verkoop en het minimaliseren van productrendementen en verloren verkoopkansen zijn de doelstellingen van de vraagprognosemethoden die de klant gebruikt. Dit project is gericht op het gebruik van machine learning om de prognoses te verbeteren.

Het CSE-team heeft het project onderverdeeld in twee fasen. Fase 1 was gericht op het ontwikkelen van machine learning-modellen ter ondersteuning van een op het veld gebaseerde pilotstudie over de effectiviteit van machine learning-prognoses voor een geselecteerde verkoopregio. Het succes van fase 1 leidde tot fase 2, waarin het team de eerste pilotstudie uitschaalde van een minimale groep modellen die één geografische regio ondersteunde tot een set duurzame productiemodellen voor alle verkoopregio's van de klant. Een belangrijke overweging voor de opgeschaalde oplossing was de noodzaak om tegemoet te komen aan het grote aantal geografische regio's en hun lokale winkels. Het team heeft de machine learning-modellen toegewezen aan zowel grote als kleine winkels in elke regio.

In de fase 1-teststudie is vastgesteld dat een model dat is toegewezen aan de detailhandel van één regio gebruik kan maken van de lokale verkoopgeschiedenis, lokale demografische gegevens, weer en speciale gebeurtenissen om de vraagprognose voor de verkooppunten in de regio te optimaliseren. Vier ensemble machine learning-voorspellingsmodellen bedienden marktkanalen in één regio. De modellen verwerkten gegevens in wekelijkse batches. Daarnaast heeft het team twee basislijnmodellen ontwikkeld met behulp van historische gegevens ter vergelijking.

Voor de eerste versie van de opgeschaalde fase 2-oplossing heeft het CSE-team 14 geografische regio's geselecteerd om deel te nemen, met inbegrip van kleine en grote marktkanalen. Ze hebben meer dan 50 machine learning-voorspellingsmodellen gebruikt. Het team verwachtte verdere systeemgroei en verdere verfijning van de machine learning-modellen. Het werd snel duidelijk dat deze bredere machine learning-oplossing alleen duurzaam is als deze is gebaseerd op de best practice-principes van DevOps voor de machine learning-omgeving.

Omgeving	Marktregio	Notatie	Modellen	Modelindeling	Modelbeschrijving
Ontwikkelomgeving	Elke geografische markt/regio (bijvoorbeeld Noord-Texas)	Grote formaten winkels (supermarkten, grote box stores, enzovoort)	Twee ensemblemodellen	Langzaam bewegende producten	Langzaam en snel hebben beide een ensemble van een minst absolute shrinkage en selectieoperator (LASSO) lineair regressiemodel en een neuraal netwerk met categorische insluitingen
				Snel bewegende producten	Langzaam en snel hebben beide een ensemble van een LASSO lineair regressiemodel en een neuraal netwerk met categorische insluitingen
			Eén ensemblemodel	N.v.t.	Historisch gemiddelde
		Kleine formaten winkels (apotheken, gemakswinkels, enzovoort)	Twee ensemblemodellen	Langzaam bewegende producten	Langzaam en snel hebben beide een ensemble van een LASSO lineair regressiemodel en een neuraal netwerk met categorische insluitingen
				Snel bewegende producten	Langzaam en beide hebben een ensemble van een LINEAIR LASSO-regressiemodel en een neuraal netwerk met categorische insluitingen
			Eén ensemblemodel	N.v.t.	Historisch gemiddelde
	Hetzelfde als hierboven voor een extra 13 geografische regio's
Hetzelfde als hierboven voor de prod-omgeving

Het MLOps-proces biedt een framework voor het opgeschaalde systeem dat de volledige levenscyclus van de machine learning-modellen heeft aangepakt. Het framework omvat ontwikkeling, testen, implementatie, bewerking en bewaking. Het voldoet aan de behoeften van een klassiek CI/CD-proces. Vanwege de relatieve immaturiteit in vergelijking met DevOps bleek echter dat bestaande MLOps-richtlijnen hiaten hadden. Het projectteam heeft gewerkt om een aantal hiaten in te vullen. Ze wilden een functioneel procesmodel bieden dat de levensvatbaarheid van de opgeschaalde machine learning-oplossing verzekert.

Het MLOps-proces dat is ontwikkeld op basis van dit project, maakte een belangrijke echte stap om MLOps te verplaatsen naar een hoger niveau van volwassenheid en levensvatbaarheid. Het nieuwe proces is rechtstreeks van toepassing op andere machine learning-projecten. Het CSE-team heeft gebruikt wat ze hebben geleerd om een concept van een MLOps-volwassen model te bouwen dat iedereen kan toepassen op andere machine learning-projecten.

Technisch scenario

MLOps, ook wel DevOps genoemd voor machine learning, is een overkoepelende term die filosofieën, procedures en technologieën omvat die betrekking hebben op het implementeren van machine learning-levenscycluss in een productieomgeving. Het is nog steeds een relatief nieuw concept. Er zijn veel pogingen geweest om te definiëren wat MLOps is en veel mensen hebben zich afvraagd of MLOps alles kan combineren, van hoe gegevenswetenschappers gegevens voorbereiden op hoe ze uiteindelijk machine learning-resultaten leveren, bewaken en evalueren. Hoewel DevOps jaren een aantal fundamentele procedures heeft ontwikkeld, is MLOps nog vroeg in de ontwikkeling. Naarmate het zich ontwikkelt, ontdekken we de uitdagingen van het samenbrengen van twee disciplines die vaak werken met verschillende vaardighedensets en prioriteiten: software/ops engineering en data science.

Het implementeren van MLOps in echte productieomgevingen heeft unieke uitdagingen die moeten worden opgelost. Teams kan Azure gebruiken om MLOps-patronen te ondersteunen. Azure kan ook clients assetbeheer- en indelingsservices bieden voor het effectief beheren van de levenscyclus van machine learning. Azure-services vormen de basis voor de MLOps-oplossing die in dit artikel wordt beschreven.

Vereisten voor Machine Learning-modellen

Veel van het werk tijdens de testfase van fase 1 was het maken van de machine learning-modellen die het CSE-team heeft toegepast op de grote en kleine winkels in één regio. Belangrijke vereisten voor de modellen zijn:

• Gebruik van de Azure Machine Learning-service.

• Eerste experimentele modellen die zijn ontwikkeld in Jupyter-notebooks en geïmplementeerd in Python.

  Notitie

  Teams gebruikt dezelfde machine learning-benadering voor grote en kleine winkels, maar de trainings- en scoregegevens zijn afhankelijk van de grootte van het archief.

• Gegevens waarvoor voorbereiding op het modelverbruik is vereist.

• Gegevens die op batchbasis worden verwerkt in plaats van in realtime.

• Model opnieuw trainen wanneer code of gegevens worden gewijzigd, of het model verloopt verlopen.

• Weergave van modelprestaties in Power BI-dashboards.

• Modelprestaties bij scoren die als significant worden beschouwd als MAPE <= 45% in vergelijking met een historisch gemiddeld basislijnmodel.

MLOps-vereisten

Het team moest aan verschillende belangrijke vereisten voldoen om de oplossing op te schalen uit de pilotveldstudie fase 1, waarin slechts enkele modellen zijn ontwikkeld voor één verkoopregio. Fase 2 heeft aangepaste machine learning-modellen geïmplementeerd voor meerdere regio's. De implementatie omvat:

• Wekelijkse batchverwerking voor grote en kleine winkels in elke regio om de modellen opnieuw te trainen met nieuwe gegevenssets.

• Continue verfijning van de machine learning-modellen.

• Integratie van het proces development/test/package/test/deploy dat gebruikelijk is voor CI/CD in een DevOps-achtige verwerkingsomgeving voor MLOps.

  Notitie

  Dit vertegenwoordigt een verschuiving in de wijze waarop gegevenswetenschappers en data engineers in het verleden vaak hebben gewerkt.

• Een uniek model dat elke regio vertegenwoordigde voor grote en kleine winkels op basis van winkelgeschiedenis, demografische gegevens en andere belangrijke variabelen. Het model moest de volledige gegevensset verwerken om het risico op verwerkingsfouten te minimaliseren.

• De mogelijkheid om in eerste instantie omhoog te schalen ter ondersteuning van 14 verkoopregio's met plannen om verder te schalen.

• Plannen voor aanvullende modellen voor langetermijnprognoses voor regio's en andere winkelclusters.

Machine learning-modeloplossing

De levenscyclus van machine learning, ook wel bekend als de levenscyclus van data science, past ongeveer in de volgende processtroom op hoog niveau:

Implementeer model hier kan elk operationeel gebruik van het gevalideerde machine learning-model vertegenwoordigen. Vergeleken met DevOps biedt MLOps de extra uitdaging om de levenscyclus van machine learning te integreren in het typische CI/CD-proces.

De levenscyclus van data science volgt niet de typische levenscyclus van softwareontwikkeling. Het omvat het gebruik van Azure Machine Learning om de modellen te trainen en te beoordelen, dus deze stappen moesten worden opgenomen in de CI/CD-automatisering.

Batchverwerking van gegevens is de basis van de architectuur. Twee Azure Machine Learning-pijplijnen zijn centraal in het proces, één voor training en de andere voor scoren. In dit diagram ziet u de data science-methodologie die is gebruikt voor de eerste fase van het clientproject:

Het team heeft verschillende algoritmen getest. Uiteindelijk kozen ze voor een ensembleontwerp van een LASSO-lineair regressiemodel en een neuraal netwerk met categorische insluitingen. Het team heeft hetzelfde model gebruikt, gedefinieerd door het productniveau dat de client op de site kan opslaan, voor zowel grote als kleine winkels. Het team heeft het model verder onderverdeeld in snel bewegende en langzaam bewegende producten.

De gegevenswetenschappers trainen de machine learning-modellen wanneer het team nieuwe code vrijgeeft en wanneer er nieuwe gegevens beschikbaar zijn. Training vindt doorgaans wekelijks plaats. Elke verwerkingsuitvoering omvat daarom een grote hoeveelheid gegevens. Omdat het team de gegevens uit veel bronnen in verschillende indelingen verzamelt, moet de gegevens in een verbruiksbare indeling worden geplaatst voordat de gegevenswetenschappers deze kunnen verwerken. De gegevensconditionering vereist aanzienlijke handmatige inspanning en het CSE-team heeft het geïdentificeerd als een primaire kandidaat voor automatisering.

Zoals vermeld, hebben de gegevenswetenschappers de experimentele Azure Machine Learning-modellen ontwikkeld en toegepast op één verkoopregio in de testfase van fase 1 om de bruikbaarheid van deze prognosebenadering te evalueren. Het CSE-team oordeelde dat de verkooplift voor de winkels in de pilotstudie significant was. Dit succes rechtvaardigde het toepassen van de oplossing op volledige productieniveaus in fase 2, te beginnen met 14 geografische regio's en duizenden winkels. Het team kan vervolgens hetzelfde patroon gebruiken om extra regio's toe te voegen.

Het testmodel diende als basis voor de opgeschaalde oplossing, maar het CSE-team wist dat het model verdere verfijning nodig had om de prestaties te verbeteren.

MLOps-oplossing

Naarmate MLOps-concepten volwassen worden, ontdekken teams vaak uitdagingen bij het bijeenbrengen van de data science- en DevOps-disciplines. De reden hiervoor is dat de belangrijkste spelers in de disciplines, softwaretechnici en gegevenswetenschappers werken met verschillende vaardighedensets en prioriteiten.

Maar er zijn overeenkomsten om voort te bouwen. MLOps, zoals DevOps, is een ontwikkelingsproces dat wordt geïmplementeerd door een hulpprogrammaketen. De MLOps-hulpprogrammaketen bevat zaken als:

• Versiebeheer
• Codeanalyse
• Automatisering bouwen
• Continue integratie
• Frameworks en automatisering testen
• Nalevingsbeleid geïntegreerd in CI/CD-pijplijnen
• Automatisering van implementatie
• Controleren
• Herstel na noodgeval en hoge beschikbaarheid
• Pakket- en containerbeheer

Zoals hierboven vermeld, maakt de oplossing gebruik van bestaande DevOps-richtlijnen, maar is uitgebreid om een meer volwassen MLOps-implementatie te maken die voldoet aan de behoeften van de client en van de data science-community. MLOps bouwt voort op DevOps-richtlijnen met deze aanvullende vereisten:

• Versiebeheer van gegevens en modellen is niet hetzelfde als codeversiebeheer: er moet versiebeheer van gegevenssets zijn wanneer het schema en de oorspronkelijke gegevens worden gewijzigd.
• Vereisten voor digitale audittrail: alle wijzigingen bijhouden bij het verwerken van code- en clientgegevens.
• Generalisatie: modellen verschillen van code voor hergebruik, omdat gegevenswetenschappers modellen moeten afstemmen op basis van invoergegevens en scenario's. Als u een model opnieuw wilt gebruiken voor een nieuw scenario, moet u het model mogelijk verfijnen/overdragen/leren. U hebt de trainingspijplijn nodig.
• Verouderde modellen: Modellen vervalsen na verloop van tijd en u hebt de mogelijkheid nodig om ze op aanvraag opnieuw te trainen om ervoor te zorgen dat ze relevant blijven in productie.

MLOps-uitdagingen

Standaard voor onvolgroeide MLOps

Het standaardpatroon voor MLOps is nog steeds in ontwikkeling. Een oplossing is doorgaans helemaal zelf gebouwd en aangepast aan de behoeften van een bepaalde client of gebruiker. Het CSE-team herkende deze kloof en wilde devOps-best practices in dit project gebruiken. Ze hebben het DevOps-proces uitgebreid om aan de aanvullende vereisten van MLOps te voldoen. Het proces dat het team heeft ontwikkeld, is een levensvatbaar voorbeeld van hoe een MLOps-standaardpatroon eruit moet zien.

Verschillen in vaardighedensets

Softwaretechnici en gegevenswetenschappers brengen unieke vaardighedensets naar het team. Deze verschillende vaardighedensets kunnen het vinden van een oplossing die moeilijk aansluit bij de behoeften van iedereen. Het bouwen van een goed begrepen werkstroom voor modellevering van experimenten naar productie is belangrijk. Teamleden moeten inzicht hebben in hoe ze wijzigingen in het systeem kunnen integreren zonder het MLOps-proces te verbreken.

Meerdere modellen beheren

Er is vaak behoefte aan meerdere modellen om op te lossen voor moeilijke machine learning-scenario's. Een van de uitdagingen van MLOps is het beheren van deze modellen, waaronder:

• Een coherent versiebeheerschema hebben.
• Voortdurend alle modellen evalueren en bewaken.

Traceerbare herkomst van zowel code als gegevens is ook nodig om modelproblemen te diagnosticeren en reproduceerbare modellen te maken. Aangepaste dashboards kunnen zinvol zijn voor de prestaties van geïmplementeerde modellen en geven aan wanneer ze moeten ingrijpen. Het team heeft dergelijke dashboards voor dit project gemaakt.

Behoefte aan gegevensconditioner

Gegevens die met deze modellen worden gebruikt, zijn afkomstig uit veel privé- en openbare bronnen. Omdat de oorspronkelijke gegevens ongeordend zijn, is het onmogelijk voor het machine learning-model om deze in de onbewerkte staat te gebruiken. De gegevenswetenschappers moeten de gegevens voorwaarde stellen in een standaardindeling voor het gebruik van het machine learning-model.

Een groot deel van de test voor het proefveld is gericht op het conditioneren van de onbewerkte gegevens, zodat het machine learning-model het kan verwerken. In een MLOps-systeem moet het team dit proces automatiseren en de uitvoer bijhouden.

MLOps-ontwikkelingsmodel

Het doel van het MLOps-volwassen model is om de principes en procedures te verduidelijken en hiaten in een MLOps-implementatie te identificeren. Het is ook een manier om een client te laten zien hoe ze hun MLOps-capaciteit stapsgewijs kunnen vergroten in plaats van alles tegelijk te proberen. De client moet deze gebruiken als richtlijn voor het volgende:

• Schat het bereik van het werk voor het project.
• Criteria voor succes vaststellen.
• Identificeer producten.

Het MLOps-volwassen model definieert vijf niveaus van technische mogelijkheden:

Niveau	Beschrijving
0	Geen ops
1	DevOps, maar geen MLOps
2	Geautomatiseerde training
3	Geautomatiseerde modelimplementatie
4	Geautomatiseerde bewerkingen (volledige MLOps)

Zie het artikel over het MLOps-volwassen model voor de huidige versie van het MLOps-model.

MLOps-procesdefinitie

MLOps omvat alle activiteiten van het verkrijgen van onbewerkte gegevens tot het leveren van modeluitvoer, ook wel scoren genoemd:

• Gegevensconditioner
• Modeltraining
• Model testen en evalueren
• Definitie en pijplijn bouwen
• Release-pijplijn
• Implementatie
• Scoren

Eenvoudig machine learning-proces

Het eenvoudige machine learning-proces lijkt op traditionele softwareontwikkeling, maar er zijn aanzienlijke verschillen. In dit diagram ziet u de belangrijkste stappen in het machine learning-proces:

De experimentfase is uniek voor de levenscyclus van data science, die aangeeft hoe gegevenswetenschappers traditioneel hun werk doen. Het verschilt van hoe codeontwikkelaars hun werk doen. Het volgende diagram illustreert deze levenscyclus in meer detail.

Het integreren van dit proces voor gegevensontwikkeling in MLOps vormt een uitdaging. Hier ziet u het patroon dat het team heeft gebruikt om het proces te integreren in een formulier dat MLOps kan ondersteunen:

De rol van MLOps is het maken van een gecoördineerd proces dat efficiënt ondersteuning biedt voor de grootschalige CI/CD-omgevingen die gebruikelijk zijn in systemen op productieniveau. Conceptueel moet het MLOps-model alle procesvereisten van experimenten tot scoren bevatten.

Het CSE-team heeft het MLOps-proces verfijnd om aan de specifieke behoeften van de klant te voldoen. De meest opvallende behoefte was batchverwerking in plaats van realtime verwerking. Toen het team het opgeschaalde systeem ontwikkelde, hebben ze enkele tekortkomingen geïdentificeerd en opgelost. De belangrijkste van deze tekortkomingen hebben geleid tot de ontwikkeling van een brug tussen Azure Data Factory en Azure Machine Learning, die het team heeft geïmplementeerd met behulp van een ingebouwde connector in Azure Data Factory. Ze hebben deze onderdelenset gemaakt om de triggering en statusbewaking te vergemakkelijken die nodig zijn om het procesautomatisering te laten werken.

Een andere fundamentele wijziging was dat de gegevenswetenschappers de mogelijkheid nodig hebben om experimentele code uit Jupyter-notebooks te exporteren naar het MLOps-implementatieproces in plaats van rechtstreeks training en scoren te activeren.

Hier volgt het uiteindelijke concept van het MLOps-procesmodel:

MLOps-processtroom

In het volgende diagram wordt beschreven hoe u CI/CD-ontwikkel- en releasewerkstromen toepast op de machine learning-levenscyclus:

• Wanneer een pull-aanvraag (PR) wordt gemaakt op basis van een functiebranch, voert de pijplijn codevalidatietests uit om de kwaliteit van de code te valideren via eenheidstests en codekwaliteitstests. Om de kwaliteit upstream te valideren, voert de pijplijn ook eenvoudige modelvalidatietests uit om de end-to-end trainings- en scorestappen te valideren met een voorbeeldset gesimuleerde gegevens.
• Wanneer de pull-aanvraag wordt samengevoegd in de hoofdbranch, voert de CI-pijplijn dezelfde codevalidatietests en basismodelvalidatietests uit met een verhoogd tijdvak. De pijplijn verpakt vervolgens de artefacten, waaronder de code en binaire bestanden, die moeten worden uitgevoerd in de machine learning-omgeving.
• Nadat de artefacten beschikbaar zijn, wordt een CD-pijplijn voor modelvalidatie geactiveerd. De end-to-end-validatie wordt uitgevoerd in de ontwikkelomgeving voor machine learning. Er wordt een scoremechanisme gepubliceerd. Voor een batchgewijs scorescenario wordt een scorepijplijn gepubliceerd naar de machine learning-omgeving en geactiveerd om resultaten te produceren. Als u een scenario voor realtime scoren wilt gebruiken, kunt u een web-app publiceren of een container implementeren.
• Zodra een mijlpaal is gemaakt en samengevoegd in de releasebranch, worden dezelfde CI-pijplijn en modelvalidatie-CD-pijplijn geactiveerd. Deze keer worden ze uitgevoerd op de code uit de releasebranch.

U kunt de mlOps-procesgegevensstroom die hierboven wordt weergegeven, beschouwen als een archetypeframework voor projecten die vergelijkbare architectuurkeuzen maken.

Codevalidatietests

Codevalidatietests voor machine learning zijn gericht op het valideren van de kwaliteit van de codebasis. Het is hetzelfde concept als elk technisch project met codekwaliteitstests (linting), eenheidstests en metingen voor codedekking.

Basismodelvalidatietests

Modelvalidatie verwijst doorgaans naar het valideren van de volledige end-to-end processtappen die nodig zijn om een geldig machine learning-model te produceren. Het bevat stappen zoals:

• Gegevensvalidatie: zorgt ervoor dat de invoergegevens geldig zijn.
• Trainingsvalidatie: Zorgt ervoor dat het model kan worden getraind.
• Scorevalidatie: zorgt ervoor dat het team het getrainde model kan gebruiken voor scoren met de invoergegevens.

Het uitvoeren van deze volledige set stappen in de machine learning-omgeving is duur en tijdrovend. Als gevolg hiervan heeft het team basistests voor modelvalidatie lokaal uitgevoerd op een ontwikkelcomputer. De bovenstaande stappen zijn uitgevoerd en hebben het volgende gebruikt:

• Lokale testgegevensset: Een kleine gegevensset, vaak een gegevensset die verborgen is, die is ingecheckt bij de opslagplaats en wordt gebruikt als de invoergegevensbron.
• Lokale vlag: een vlag of argument in de code van het model die aangeeft dat de code de gegevensset lokaal wil uitvoeren. Met de vlag wordt aan de code aangegeven dat elke aanroep naar de machine learning-omgeving moet worden overgeslagen.

Dit doel van deze validatietests is niet om de prestaties van het getrainde model te evalueren. In plaats daarvan is het om te valideren dat de code voor het end-to-end-proces van goede kwaliteit is. Het garandeert de kwaliteit van de code die upstream wordt gepusht, zoals de integratie van modelvalidatietests in de PULL- en CI-build. Het maakt het ook mogelijk voor technici en gegevenswetenschappers om onderbrekingspunten in de code te plaatsen voor foutopsporingsdoeleinden.

CD-pijplijn voor modelvalidatie

Het doel van de modelvalidatiepijplijn is het valideren van de end-to-end modeltrainings- en scorestappen in de machine learning-omgeving met werkelijke gegevens. Elk getraind model dat wordt geproduceerd, wordt toegevoegd aan het modelregister en gelabeld om te wachten op promotie nadat de validatie is voltooid. Voor batchvoorspelling kan promotie het publiceren van een scorepijplijn zijn die gebruikmaakt van deze versie van het model. Voor realtime scoren kan het model worden getagd om aan te geven dat het is gepromoveerd.

Cd-pijplijn scoren

De score-CD-pijplijn is van toepassing op het batchdeductiescenario, waarbij dezelfde modelorchestrator die wordt gebruikt voor modelvalidatie de gepubliceerde scorepijplijn activeert.

Ontwikkeling versus productieomgevingen

Het is een goede gewoonte om de ontwikkelomgeving van de productieomgeving (prod) te scheiden. Met scheiding kan het systeem de CD-pijplijn voor modelvalidatie activeren en CD-pijplijn scoren volgens verschillende planningen. Voor de beschreven MLOps-stroom worden pijplijnen die gericht zijn op de hoofdbranch uitgevoerd in de ontwikkelomgeving en de pijplijn die is gericht op de releasebranch uitgevoerd in de prod-omgeving.

Codewijzigingen versus gegevenswijzigingen

De vorige secties hebben voornamelijk betrekking op het afhandelen van codewijzigingen van ontwikkeling tot release. Gegevenswijzigingen moeten echter hetzelfde zijn als codewijzigingen om dezelfde validatiekwaliteit en consistentie in productie te bieden. Met een trigger voor gegevenswijziging of een timertrigger kan het systeem de CD-pijplijn voor modelvalidatie en de score-CD-pijplijn van de modelortor activeren om hetzelfde proces uit te voeren dat wordt uitgevoerd voor codewijzigingen in de releasebranch-prod-omgeving.

MLOps-persona's en -rollen

Een belangrijke vereiste voor elk MLOps-proces is dat het voldoet aan de behoeften van de vele gebruikers van het proces. Voor ontwerpdoeleinden kunt u deze gebruikers beschouwen als afzonderlijke persona's. Voor dit project heeft het team deze persona's geïdentificeerd:

• Data scientist: Hiermee maakt u het machine learning-model en de bijbehorende algoritmen.
• Ingenieur
  • Data engineer: verwerkt gegevensconditioner.
  • Software engineer: verwerkt modelintegratie in het assetpakket en de CI/CD-werkstroom.
• Bewerkingen of IT: houdt toezicht op systeembewerkingen.
• Zakelijke belanghebbende: Houd zich bezig met de voorspellingen van het machine learning-model en hoe ze het bedrijf helpen.
• Eindgebruiker van gegevens: verbruikt modeluitvoer op een of andere manier die helpt bij het nemen van zakelijke beslissingen.

Het team moest drie belangrijke bevindingen uit de persona en rolstudies aanpakken:

• Gegevenswetenschappers en technici komen niet overeen met benadering en vaardigheden in hun werk. Het eenvoudig maken van de data scientist en de technicus om samen te werken, is een belangrijke overweging voor het ontwerp van de MLOps-processtroom. Het vereist nieuwe vaardigheidsaankopen door alle teamleden.
• Er is een noodzaak om alle belangrijkste persona's te samenvoegen zonder iemand te buitenaards te maken. Een manier om dit te doen, is het volgende:
  • Zorg ervoor dat ze het conceptuele model voor MLOps begrijpen.
  • Ga akkoord met de teamleden die samenwerken.
  • Werkrichtlijnen opstellen om gemeenschappelijke doelstellingen te bereiken.
• Als de zakelijke belanghebbende en de eindgebruiker van gegevens een manier nodig heeft om te communiceren met de gegevensuitvoer van de modellen, is een gebruiksvriendelijke gebruikersinterface de standaardoplossing.

Andere teams zullen zeker vergelijkbare problemen tegenkomen in andere machine learning-projecten wanneer ze omhoog worden geschaald voor productiegebruik.

MLOps-oplossingsarchitectuur

Logische architectuur

De gegevens zijn afkomstig uit veel bronnen in veel verschillende indelingen, dus deze worden geconditioneerd voordat deze in de data lake worden ingevoegd. De conditionering wordt uitgevoerd met behulp van microservices die werken als Azure Functions. De clients passen de microservices aan zodat ze passen bij de gegevensbronnen en deze transformeren in een gestandaardiseerde CSV-indeling die door de trainings- en scorepijplijnen wordt gebruikt.

Systeemarchitectuur

Architectuur voor batchverwerking

Het team heeft het architectuurontwerp ontworpen ter ondersteuning van een batchgegevensverwerkingsschema. Er zijn alternatieven, maar wat er ook wordt gebruikt, moet MLOps-processen ondersteunen. Volledig gebruik van beschikbare Azure-services was een ontwerpvereiste. In het volgende diagram ziet u de architectuur:

Overzicht van de oplossing

Azure Data Factory doet het volgende:

• Hiermee wordt een Azure-functie geactiveerd om gegevensopname en een uitvoering van de Azure Machine Learning-pijplijn te starten.
• Start een duurzame functie om de Azure Machine Learning-pijplijn te peilen voor voltooiing.

Aangepaste dashboards in Power BI geven de resultaten weer. Andere Azure-dashboards die zijn verbonden met Azure SQL, Azure Monitor en App Insights via OpenCensus Python SDK, volgen Azure-resources. Deze dashboards bieden informatie over de status van het machine learning-systeem. Ze leveren ook gegevens op die de klant gebruikt voor productorderprognoses.

Modelindeling

Modelindeling volgt deze stappen:

1. Wanneer een pull-aanvraag wordt verzonden, activeert DevOps een codevalidatiepijplijn.
2. De pijplijn voert eenheidstests, codekwaliteitstests en modelvalidatietests uit.
3. Wanneer dezelfde codevalidatietests worden samengevoegd in de hoofdbranch, worden dezelfde codevalidatietests uitgevoerd en worden de artefacten in DevOps verpakt.
4. DevOps-verzameling van artefacten activeert Azure Machine Learning om het volgende te doen:
   1. Gegevensvalidatie.
   2. Trainingsvalidatie.
   3. Scorevalidatie.
5. Nadat de validatie is voltooid, wordt de uiteindelijke scorepijplijn uitgevoerd.
6. Als u gegevens wijzigt en een nieuwe pull-aanvraag indient, wordt de validatiepijplijn opnieuw geactiveerd, gevolgd door de uiteindelijke scorepijplijn.

Experimenten inschakelen

Zoals vermeld, biedt de traditionele levenscyclus van data science machine learning geen ondersteuning voor het MLOps-proces zonder aanpassingen. Het maakt gebruik van verschillende soorten handmatige hulpprogramma's en experimenten, validatie, verpakking en modelhandoff die niet eenvoudig kunnen worden geschaald voor een effectief CI/CD-proces. MLOps vereist een hoog niveau van procesautomatisering. Of er nu een nieuw machine learning-model wordt ontwikkeld of een oud model wordt gewijzigd, het is nodig om de levenscyclus van het machine learning-model te automatiseren. In het fase 2-project heeft het team Azure DevOps gebruikt om Azure Machine Learning-pijplijnen te organiseren en opnieuw te publiceren voor trainingstaken. De langlopende hoofdvertakking voert basistests van modellen uit en pusht stabiele releases via de langlopende releasevertakking.

Broncodebeheer wordt een belangrijk onderdeel van dit proces. Git is het versiebeheersysteem dat wordt gebruikt om notebook- en modelcode bij te houden. Het biedt ook ondersteuning voor procesautomatisering. De basiswerkstroom die wordt geïmplementeerd voor broncodebeheer, past de volgende principes toe:

• Gebruik formele versiebeheer voor code en gegevenssets.
• Gebruik een vertakking voor nieuwe codeontwikkeling totdat de code volledig is ontwikkeld en gevalideerd.
• Nadat nieuwe code is gevalideerd, kan deze worden samengevoegd met de hoofdbranch.
• Voor een release wordt een permanente versie van een vertakking gemaakt die losstaat van de hoofdbranch.
• Gebruik versies en broncodebeheer voor de gegevenssets die zijn geconditioneerd voor training of verbruik, zodat u de integriteit van elke gegevensset kunt behouden.
• Gebruik broncodebeheer om uw Jupyter Notebook-experimenten bij te houden.

Integratie met gegevensbronnen

Gegevenswetenschappers gebruiken veel onbewerkte gegevensbronnen en verwerkte gegevenssets om te experimenteren met verschillende machine learning-modellen. Het volume aan gegevens in een productieomgeving kan overweldigend zijn. Voordat de gegevenswetenschappers met verschillende modellen kunnen experimenteren, moeten ze beheerhulpprogramma's zoals Azure Data Lake gebruiken. De vereiste voor formele identificatie en versiebeheer is van toepassing op alle onbewerkte gegevens, voorbereide gegevenssets en machine learning-modellen.

In het project hebben de gegevenswetenschappers de volgende gegevens geconditioneerd voor invoer in het model:

• Historische wekelijkse verzendingsgegevens sinds januari 2017
• Historische en voorspelde dagelijkse weergegevens voor elke postcode
• Gegevens van klanten voor elke winkel-id

Integratie met broncodebeheer

Om gegevenswetenschappers de best practices voor engineering te laten toepassen, is het nodig om de hulpprogramma's die ze gebruiken met broncodebeheersystemen zoals GitHub, gemakkelijk te integreren. Met deze procedure kunnen machine learning-modelversies, samenwerking tussen teamleden en herstel na noodgevallen worden uitgevoerd als de teams gegevens of een systeemstoring verliezen.

Ondersteuning voor modelensemble

Het modelontwerp in dit project was een ensemblemodel. Dat wil zeggen dat gegevenswetenschappers veel algoritmen hebben gebruikt in het uiteindelijke modelontwerp. In dit geval hebben de modellen hetzelfde basisalgoritmenontwerp gebruikt. Het enige verschil was dat ze verschillende trainingsgegevens en scoregegevens gebruikten. De modellen gebruikten de combinatie van een LINEAIR LASSO-regressie-algoritme en een neuraal netwerk.

Het team heeft verkend, maar niet geïmplementeerd, een optie om het proces door te voeren naar het punt waar het ondersteuning biedt voor het uitvoeren van veel realtime modellen die in productie worden uitgevoerd om een bepaalde aanvraag te verwerken. Deze optie is geschikt voor het gebruik van ensemblemodellen in A/B-tests en interleaved experimenten.

Interfaces voor eindgebruikers

Het team heeft UIS's voor eindgebruikers ontwikkeld voor waarneembaarheid, bewaking en instrumentatie. Zoals vermeld, geven dashboards de machine learning-modelgegevens visueel weer. Deze dashboards geven de volgende gegevens weer in een gebruiksvriendelijke indeling:

• Pijplijnstappen, waaronder het vooraf verwerken van de invoergegevens.
• De status van de machine learning-modelverwerking bewaken:
  • Welke metrische gegevens verzamelt u van uw geïmplementeerde model?
    • MAPE: gemiddelde absolute percentagefout, de belangrijkste meetwaarde die moet worden bijgehouden voor algemene prestaties. (Richt een MAPE-waarde op van <= 0,45 voor elk model.)
    • RMSE 0: Root-mean-square error (RMSE) wanneer de werkelijke doelwaarde = 0.
    • RMSE All: RMSE op de hele gegevensset.
  • Hoe evalueert u of uw model presteert zoals verwacht in productie?
  • Is er een manier om te zien of productiegegevens te veel afwijken van de verwachte waarden?
  • Presteert uw model slecht in productie?
  • Hebt u een failoverstatus?
• De kwaliteit van de verwerkte gegevens bijhouden.
• De score/voorspellingen weergeven die zijn geproduceerd door het machine learning-model.

De toepassing vult de dashboards op basis van de aard van de gegevens en hoe deze de gegevens verwerkt en analyseert. Daarom moet het team de exacte indeling van de dashboards ontwerpen voor elke use-case. Hier volgen twee voorbeelddashboards:

De dashboards zijn ontworpen om gemakkelijk bruikbare informatie te bieden voor gebruik door de eindgebruiker van de voorspellingen van het machine learning-model.

Onderdelen

• Azure Machine Learning
  • Azure Machine Learning Compute
  • Azure Machine Learning-pijplijnen
  • Azure Machine Learning-modelregister
• Azure Blob-opslag
• Azure Data Lake Storage
• Azure Pipelines
• Azure Data Factory
• Azure Functions voor Python
• Azure Monitor
  • Logbestanden
  • Application Insights
• Azure SQL-database
• Azure-dashboards
• Power BI

Overwegingen

Hier vindt u een lijst met overwegingen die u kunt verkennen. Ze zijn gebaseerd op de lessen die het CSE-team tijdens het project heeft geleerd.

Omgevingsoverwegingen

• Gegevenswetenschappers ontwikkelen de meeste machine learning-modellen met behulp van Python, vaak beginnend met Jupyter-notebooks. Het kan een uitdaging zijn om deze notebooks als productiecode te implementeren. Jupyter-notebooks zijn meer experimenteel hulpprogramma's, terwijl Python-scripts geschikter zijn voor productie. Teams moeten vaak tijd besteden aan het herstructureren van code voor het maken van modellen in Python-scripts.
• Zorg ervoor dat clients die niet bekend zijn met DevOps en machine learning zich bewust zijn van het feit dat experimenten en productie anders moeten werken, dus het is een goede gewoonte om de twee te scheiden.
• Hulpprogramma's zoals de Azure Machine Learning Visual Designer of AutoML kunnen effectief zijn om basismodellen buiten de grond te krijgen, terwijl de client zich op standaard DevOps-procedures aanmeldt om toe te passen op de rest van de oplossing.
• Azure DevOps heeft invoegtoepassingen die kunnen worden geïntegreerd met Azure Machine Learning om pijplijnstappen te activeren. De MLOpsPython-opslagplaats bevat enkele voorbeelden van dergelijke pijplijnen.
• Machine learning vereist vaak krachtige GPU-machines (Graphics Processing Unit) voor training. Als de client nog geen dergelijke hardware beschikbaar heeft, kunnen Azure Machine Learning-rekenclusters een effectief pad bieden voor het snel inrichten van rendabele krachtige hardware die automatisch wordt geschaald. Als een client geavanceerde beveiligings- of bewakingsbehoeften heeft, zijn er andere opties, zoals standaard-VM's, Databricks of lokale compute.
• Om een klant succesvol te laten zijn, moeten hun modelbouwteams (gegevenswetenschappers) en implementatieteams (DevOps-technici) een sterk communicatiekanaal hebben. Ze kunnen dit doen met dagelijkse stand-upvergaderingen of een formele online chatservice. Beide benaderingen helpen bij het integreren van hun ontwikkelingsinspanningen in een MLOps-framework.

Overwegingen voor gegevensvoorbereiding

• De eenvoudigste oplossing voor het gebruik van Azure Machine Learning is het opslaan van gegevens in een ondersteunde oplossing voor gegevensopslag. Hulpprogramma's zoals Azure Data Factory zijn effectief voor het doorsluisen van gegevens naar en van die locaties volgens een planning.

• Het is belangrijk dat clients regelmatig aanvullende hertrainingsgegevens vastleggen om hun modellen up-to-date te houden. Als ze nog geen gegevenspijplijn hebben, is het maken van een pijplijn een belangrijk onderdeel van de algehele oplossing. Het gebruik van een oplossing zoals gegevenssets in Azure Machine Learning kan handig zijn voor het versiebeheer van gegevens om te helpen bij het traceren van modellen.

Overwegingen voor modeltraining en -evaluatie

• Het is overweldigend voor een client die net aan de slag gaat met het machine learning-traject om een volledige MLOps-pijplijn te implementeren. Indien nodig kunnen ze dit eenvoudiger maken door Azure Machine Learning te gebruiken om uitvoeringen van experimenten bij te houden en door Azure Machine Learning-rekenkracht als trainingsdoel te gebruiken. Met deze opties kan een lagere toegangsbarrière ontstaan om te beginnen met het integreren van Azure-services.

• Het uitvoeren van een notebookexperiment naar herhaalbare scripts is een ruwe overgang voor veel gegevenswetenschappers. Hoe sneller ze hun trainingscode kunnen schrijven in Python-scripts, hoe eenvoudiger het is dat ze beginnen met het versiebeheer van hun trainingscode en het opnieuw trainen inschakelen.

  Dat is niet de enige mogelijke methode. Databricks ondersteunt het plannen van notebooks als taken. Maar op basis van de huidige clientervaring is deze aanpak moeilijk te instrumenteren met volledige DevOps-procedures vanwege testbeperkingen.

• Het is ook belangrijk om te begrijpen welke metrische gegevens worden gebruikt om een model een succes te overwegen. Nauwkeurigheid alleen is vaak niet goed genoeg om de algehele prestaties van het ene model te bepalen versus een ander model.

Overwegingen voor berekeningen

• Klanten moeten overwegen om containers te gebruiken om hun rekenomgevingen te standaardiseren. Bijna alle Azure Machine Learning-rekendoelen ondersteunen het gebruik van Docker. Als een container de afhankelijkheden afhandelt, kan de wrijving aanzienlijk worden verminderd, met name als het team veel rekendoelen gebruikt.

Overwegingen bij het leveren van modellen

• De Azure Machine Learning SDK biedt een optie om rechtstreeks vanuit een geregistreerd model te implementeren naar Azure Kubernetes Service, waarmee limieten worden gemaakt voor de beveiliging/metrische gegevens. U kunt proberen een eenvoudigere oplossing te vinden voor clients om hun model te testen, maar het is het beste om een robuustere implementatie voor AKS te ontwikkelen voor productieworkloads.

Volgende stappen

• Meer informatie over MLOps
• MLOps in Azure
• Azure Monitor-visualisaties
• Machine Learning-levenscyclus
• Azure DevOps Machine Learning-extensie
• Azure Machine Learning CLI
• Toepassingen, processen of CI/CD-werkstromen activeren op basis van Azure Machine Learning-gebeurtenissen
• Modeltraining en -implementatie instellen met Azure DevOps

Verwante resources

• MLOps-volwassenheidsmodel
• MLOps organiseren in Azure Databricks met behulp van Databricks Notebook
• MLOps voor Python-modellen met behulp van Azure Machine Learning
• Data science en machine learning met Azure Databricks
• Burger-AI met het Power Platform
• On-premises ai- en machine learning-computing implementeren en naar de rand