Delen via

Machine learning-bewerkingen

  • Artikel

In dit artikel worden drie Azure-architecturen beschreven voor machine learning-bewerkingen met end-to-end CI/CD-pijplijnen (continue integratie en continue levering) en hertraining van pijplijnen. De architecturen zijn voor deze AI-toepassingen:

  • Klassieke machine learning
  • Computer Vision (CV)
  • Natuurlijke taalverwerking

Deze architecturen zijn het product van het MLOps v2-project. Ze bevatten best practices die oplossingsarchitecten hebben geïdentificeerd tijdens het ontwikkelen van verschillende machine learning-oplossingen. Het resultaat is implementeerbare, herhaalbare en onderhoudbare patronen. Alle drie de architecturen maken gebruik van de Azure Machine Learning-service.

Zie de GitHub-opslagplaats van Azure MLOps v2 voor een implementatie met voorbeeldimplementatiesjablonen voor MLOps v2.

Potentiële gebruikscases

  • Klassieke machine learning: tijdreeksprognoses, regressie en classificatie voor gestructureerde gegevens in tabelvorm zijn de meest voorkomende use cases in deze categorie. Voorbeelden zijn:

    • Binaire en multilabelclassificatie.

    • Lineaire, polynomiale, ridge, lasso, quantile en Bayesiaanse regressie.

    • ARIMA, autoregressief, SARIMA, VAR, SES, LSTM.

  • CV: Het MLOps-framework in dit artikel richt zich voornamelijk op de CV-use cases van segmentatie en afbeeldingsclassificatie.

  • Verwerking van natuurlijke taal: u kunt dit MLOps-framework gebruiken om het volgende te implementeren:

    • Herkenning van benoemde entiteiten:

    • Tekstclassificatie

    • Tekst genereren

    • Sentimentanalyse

    • Vertaling

    • Vragen beantwoorden

    • Samenvatting

    • Zinsdetectie

    • Taaldetectie

    • Woordsoorten taggen

AI-simulaties, deep reinforcement learning en andere vormen van AI worden niet beschreven in dit artikel.

Architectuur

Het architectuurpatroon MLOps v2 heeft vier belangrijke modulaire onderdelen of fasen van de MLOps-levenscyclus:

  • Gegevensdomein
  • Beheer en installatie
  • Modelontwikkeling of de binnenste lusfase
  • Modelimplementatie of de fase van de buitenste lus

De voorgaande onderdelen, de verbindingen tussen deze onderdelen en de typische persona's zijn standaard voor alle MLOps v2-scenarioarchitecturen. Variaties in de details van elk onderdeel zijn afhankelijk van het scenario.

De basisarchitectuur voor MLOps v2 voor Machine Learning is het klassieke machine learning-scenario voor gegevens in tabelvorm. De CV- en NLP-architecturen bouwen voort op deze basisarchitectuur en passen deze basisarchitectuur aan.

MLOps v2 behandelt de volgende architecturen die in dit artikel worden beschreven:

Klassieke machine learning-architectuur

Diagram met de klassieke machine learning-architectuur.

Een Visio-bestand van deze architectuur downloaden.

Werkstroom voor de klassieke machine learning-architectuur

  1. Gegevensdomein

    Dit onderdeel illustreert het gegevensdomein van de organisatie en mogelijke gegevensbronnen en doelen voor een data science-project. Data engineers zijn de primaire eigenaren van dit onderdeel van de mlOps v2-levenscyclus. De Azure-gegevensplatforms in dit diagram zijn niet volledig of prescriptief. Een groen vinkje geeft de gegevensbronnen en doelen aan die aanbevolen aanbevolen procedures vertegenwoordigen die zijn gebaseerd op de use-case van de klant.

  2. Beheer en installatie

    Dit onderdeel is de eerste stap in de implementatie van de MLOps v2-oplossing. Het bestaat uit alle taken met betrekking tot het maken en beheren van resources en rollen die aan het project zijn gekoppeld. Het infrastructuurteam kan bijvoorbeeld het volgende doen:

    1. Maak opslagplaatsen voor projectbroncode.
    2. Gebruik Bicep of Terraform om Machine Learning-werkruimten te maken.
    3. Gegevenssets en rekenresources maken of wijzigen voor modelontwikkeling en -implementatie.
    4. Definieer projectteamgebruikers, hun rollen en toegangsbeheer voor andere resources.
    5. CI/CD-pijplijnen maken.
    6. Maak bewakingsonderdelen voor het verzamelen en maken van waarschuwingen voor metrische gegevens van modellen en infrastructuur.

    De primaire persona die aan deze fase is gekoppeld, is het infrastructuurteam, maar een organisatie kan ook gegevenstechnici, machine learning-engineers of gegevenswetenschappers hebben.

  3. Modelontwikkeling (interne lusfase)

    De binnenste lusfase bestaat uit een iteratieve data science-werkstroom die werkt binnen een toegewezen en beveiligde Machine Learning-werkruimte. In het voorgaande diagram ziet u een typische werkstroom. Het proces begint met gegevensopname, gaat door verkennende gegevensanalyse, experimenten, modelontwikkeling en -evaluatie en registreert vervolgens een model voor productiegebruik. Dit modulaire onderdeel is agnostisch en kan worden aangepast aan het proces dat uw data science-team gebruikt om modellen te ontwikkelen.

    Persona's die aan deze fase zijn gekoppeld, zijn gegevenswetenschappers en machine learning-engineers.

  4. Machine Learning-registers

    Nadat het data science-team een model heeft ontwikkeld dat ze in productie kunnen implementeren, registreren ze het model in het machine learning-werkruimteregister. CI-pijplijnen die automatisch worden geactiveerd door modelregistratie of door gated human-in-the-loop goedkeuring, promoveren het model en eventuele andere modelafhankelijkheden naar de fase van de modelimplementatie.

    Persona's die aan deze fase zijn gekoppeld, zijn doorgaans machine learning-technici.

  5. Modelimplementatie (fase buitenste lus)

    De modelimplementatie, of de buitenste lusfase, bestaat uit fasering en testen van preproductie, productie-implementatie en bewaking van het model, de gegevens en de infrastructuur. Wanneer het model voldoet aan de criteria van de organisatie en use-case, promoten CD-pijplijnen het model en gerelateerde assets via productie, bewaking en potentiële hertraining.

    Persona's die aan deze fase zijn gekoppeld, zijn voornamelijk machine learning-technici.

  6. Fasering en test

    De faserings- en testfase varieert afhankelijk van de klantprocedures. Deze fase omvat doorgaans bewerkingen zoals opnieuw trainen en testen van de modelkandidaat op productiegegevens, testimplementaties voor eindpuntprestaties, controles van gegevenskwaliteit, eenheidstests en verantwoorde AI-controles op model- en gegevensvooroordelen. Deze fase vindt plaats in een of meer toegewezen en beveiligde Machine Learning-werkruimten.

  7. Productie-implementatie

    Nadat een model de faserings- en testfase heeft doorgegeven, kunnen machine learning-technici goedkeuring door mensen in de lus gebruiken om deze te promoveren naar productie. Modelimplementatieopties omvatten een beheerd batch-eindpunt voor batchscenario's of een beheerd online-eindpunt of Kubernetes-implementatie die gebruikmaakt van Azure Arc voor online, bijna realtime scenario's. De productie vindt doorgaans plaats in een of meer toegewezen en beveiligde Machine Learning-werkruimten.

  8. Controleren

    Machine learning-technici bewaken onderdelen in fasering, testen en productie om metrische gegevens te verzamelen met betrekking tot wijzigingen in de prestaties van het model, de gegevens en de infrastructuur. Ze kunnen deze metrische gegevens gebruiken om actie te ondernemen. Model- en gegevensbewaking kan bestaan uit het controleren op model- en gegevensdrift, modelprestaties op nieuwe gegevens en verantwoorde AI-problemen. Infrastructuurbewaking kan duiden op trage eindpuntreacties, onvoldoende rekencapaciteit of netwerkproblemen.

  9. Bewaking van gegevens en modellen: gebeurtenissen en acties

    Op basis van model- en gegevenscriteria, zoals metrische drempelwaarden of planningen, kunnen geautomatiseerde triggers en meldingen de juiste acties implementeren die moeten worden uitgevoerd. Een trigger kan bijvoorbeeld een model opnieuw trainen om nieuwe productiegegevens te gebruiken en vervolgens loopback van het model naar fasering en testen voor een preproductie-evaluatie. Of een model- of gegevensprobleem kan een actie activeren waarvoor een loopback naar de fase voor modelontwikkeling is vereist, waarbij gegevenswetenschappers het probleem kunnen onderzoeken en mogelijk een nieuw model kunnen ontwikkelen.

  10. Bewaking van infrastructuur: gebeurtenissen en acties

    Geautomatiseerde triggers en meldingen kunnen de juiste acties implementeren die moeten worden uitgevoerd op basis van infrastructuurcriteria, zoals een vertraging van een eindpuntreactie of onvoldoende rekenkracht voor de implementatie. Automatische triggers en meldingen kunnen een loopback activeren naar de installatie- en beheerfase, waarbij het infrastructuurteam het probleem kan onderzoeken en de reken- en netwerkresources mogelijk opnieuw kan configureren.

Machine Learning CV-architectuur

Diagram met de computer vision-architectuur.

Een Visio-bestand van deze architectuur downloaden.

Werkstroom voor de CV-architectuur

De Machine Learning CV-architectuur is gebaseerd op de klassieke machine learning-architectuur, maar heeft wijzigingen die specifiek zijn voor CV-scenario's onder supervisie.

  1. Gegevensdomein

    Dit onderdeel demonstreert het gegevensdomein van de organisatie en mogelijke gegevensbronnen en doelen voor een data science-project. Data engineers zijn de primaire eigenaren van dit onderdeel in de levenscyclus van MLOps v2. De Azure-gegevensplatforms in dit diagram zijn niet volledig of prescriptief. Afbeeldingen voor CV-scenario's kunnen afkomstig zijn van verschillende gegevensbronnen. Voor efficiëntie bij het ontwikkelen en implementeren van CV-modellen met Machine Learning raden we Azure Blob Storage en Azure Data Lake Storage aan.

  2. Beheer en installatie

    Dit onderdeel is de eerste stap in de MLOps v2-implementatie. Het bestaat uit alle taken met betrekking tot het maken en beheren van resources en rollen die aan het project zijn gekoppeld. Voor CV-scenario's is het beheer en de installatie van de MLOps v2-omgeving grotendeels hetzelfde als voor klassieke machine learning, maar bevat een extra stap. Het infrastructuurteam maakt gebruik van de labelfunctie van Machine Learning of een ander hulpprogramma voor het maken van afbeeldingslabels en aantekeningenprojecten.

  3. Modelontwikkeling (interne lusfase)

    De binnenste lusfase bestaat uit een iteratieve data science-werkstroom die wordt uitgevoerd in een toegewezen en beveiligde Machine Learning-werkruimte. Het belangrijkste verschil tussen deze werkstroom en het klassieke machine learning-scenario is dat het labelen en aantekenen van afbeeldingen een belangrijk onderdeel van deze ontwikkelingslus is.

  4. Machine Learning-registers

    Nadat het data science-team een model heeft ontwikkeld dat ze in productie kunnen implementeren, registreren ze het model in het machine learning-werkruimteregister. CI-pijplijnen die automatisch worden geactiveerd door modelregistratie of door gated human-in-the-loop goedkeuring bevorderen het model en eventuele andere modelafhankelijkheden voor de implementatiefase van het model.

  5. Modelimplementatie (fase buitenste lus)

    De fase van de modelimplementatie of buitenste lus bestaat uit fasering en testen van preproductie, productie-implementatie en bewaking van het model, de gegevens en de infrastructuur. Wanneer het model voldoet aan de criteria van de organisatie en use-case, promoten CD-pijplijnen het model en gerelateerde assets via productie, bewaking en potentiële hertraining.

  6. Fasering en test

    De faserings- en testfase varieert afhankelijk van de klantprocedures. Deze fase omvat doorgaans bewerkingen zoals testimplementaties voor eindpuntprestaties, controles van gegevenskwaliteit, eenheidstests en verantwoorde AI-controles op model- en gegevensvooroordelen. Voor CV-scenario's hoeven machine learning-technici de modelkandidaat niet opnieuw te trainen op productiegegevens vanwege resource- en tijdbeperkingen. Het data science-team kan in plaats daarvan productiegegevens gebruiken voor modelontwikkeling. Het kandidaatmodel dat is geregistreerd vanuit de ontwikkelingslus, wordt geëvalueerd voor productie. Deze fase vindt plaats in een of meer toegewezen en beveiligde Machine Learning-werkruimten.

  7. Productie-implementatie

    Nadat een model de faserings- en testfase heeft doorgegeven, kunnen machine learning-technici goedkeuring door mensen in de lus gebruiken om deze te promoveren naar productie. Modelimplementatieopties omvatten een beheerd batch-eindpunt voor batchscenario's of een beheerd online-eindpunt of Kubernetes-implementatie die gebruikmaakt van Azure Arc voor online, bijna realtime scenario's. De productie vindt doorgaans plaats in een of meer toegewezen en beveiligde Machine Learning-werkruimten.

  8. Controleren

    Machine learning-technici bewaken onderdelen in fasering, testen en productie om metrische gegevens te verzamelen met betrekking tot wijzigingen in de prestaties van het model, de gegevens en de infrastructuur. Ze kunnen deze metrische gegevens gebruiken om actie te ondernemen. Model- en gegevensbewaking kan bestaan uit het controleren op modelprestaties op nieuwe installatiekopieën. Infrastructuurbewaking kan duiden op trage eindpuntreacties, onvoldoende rekencapaciteit of netwerkproblemen.

  9. Bewaking van gegevens en modellen: gebeurtenissen en acties

    De gegevens- en modelbewakings- en gebeurtenis- en actiefasen van MLOps voor verwerking in natuurlijke taal zijn de belangrijkste verschillen van klassieke machine learning. Automatische hertraining wordt doorgaans niet uitgevoerd in CV-scenario's wanneer prestatievermindering van modellen op nieuwe installatiekopieën wordt gedetecteerd. In dit geval is een human-in-the-loop-proces nodig om nieuwe tekstgegevens te controleren en aantekeningen te maken voor het model dat slecht presteert. De volgende actie gaat vaak terug naar de ontwikkelingslus van het model om het model bij te werken met de nieuwe installatiekopieën.

  10. Bewaking van infrastructuur: gebeurtenissen en acties

    Geautomatiseerde triggers en meldingen kunnen de juiste acties implementeren die moeten worden uitgevoerd op basis van infrastructuurcriteria, zoals een vertraging van een eindpuntreactie of onvoldoende rekenkracht voor de implementatie. Automatische triggers en meldingen kunnen een loopback activeren naar de installatie- en beheerfase, waar het infrastructuurteam het probleem kan onderzoeken en mogelijk de omgeving, berekening en netwerkresources opnieuw kan configureren.

Architectuur voor verwerking van natuurlijke taal in Machine Learning

Diagram voor de architectuur voor verwerking van natuurlijke taal.

Een Visio-bestand van deze architectuur downloaden.

Werkstroom voor de verwerkingsarchitectuur voor natuurlijke taal

De machine learning-architectuur voor verwerking van natuurlijke taal is gebaseerd op de klassieke machine learning-architectuur, maar er zijn enkele wijzigingen die specifiek zijn voor NLP-scenario's.

  1. Gegevensdomein

    Dit onderdeel demonstreert de gegevens van de organisatie en mogelijke gegevensbronnen en doelen voor een data science-project. Data engineers zijn de primaire eigenaren van dit onderdeel in de levenscyclus van MLOps v2. De Azure-gegevensplatforms in dit diagram zijn niet volledig of prescriptief. Een groen vinkje geeft bronnen en doelen aan die aanbevolen best practices vertegenwoordigen die zijn gebaseerd op de use-case van de klant.

  2. Beheer en installatie

    Dit onderdeel is de eerste stap in de MLOps v2-implementatie. Het bestaat uit alle taken met betrekking tot het maken en beheren van resources en rollen die aan het project zijn gekoppeld. Voor scenario's voor verwerking van natuurlijke taal is het beheer en de installatie van de MLOps v2-omgeving grotendeels hetzelfde als voor klassieke machine learning, maar met een extra stap: het maken van afbeeldingslabels en aantekeningenprojecten met behulp van de labelfunctie van Machine Learning of een ander hulpprogramma.

  3. Modelontwikkeling (interne lusfase)

    De binnenste lusfase bestaat uit een iteratieve data science-werkstroom die wordt uitgevoerd in een toegewezen en beveiligde Machine Learning-werkruimte. De typische ontwikkelingslus voor NLP-modellen verschilt van het klassieke machine learning-scenario, omdat de typische ontwikkelingsstappen voor dit scenario annotators voor zinnen en tokenisatie, normalisatie en insluitingen voor tekstgegevens bevatten.

  4. Machine Learning-registers

    Nadat het data science-team een model heeft ontwikkeld dat ze in productie kunnen implementeren, registreren ze het model in het machine learning-werkruimteregister. CI-pijplijnen die automatisch worden geactiveerd door modelregistratie of door gated human-in-the-loop goedkeuring bevorderen het model en eventuele andere modelafhankelijkheden voor de implementatiefase van het model.

  5. Modelimplementatie (fase buitenste lus)

    De fase van de modelimplementatie of buitenste lus bestaat uit fasering en testen van preproductie, productie-implementatie en bewaking van het model, de gegevens en de infrastructuur. Wanneer het model voldoet aan de criteria van de organisatie en use-case, promoten CD-pijplijnen het model en gerelateerde assets via productie, bewaking en potentiële hertraining.

  6. Fasering en test

    De faserings- en testfase varieert afhankelijk van de klantprocedures. Deze fase omvat doorgaans bewerkingen zoals opnieuw trainen en testen van de modelkandidaat op productiegegevens, testimplementaties voor eindpuntprestaties, controles van gegevenskwaliteit, eenheidstests en verantwoorde AI-controles op model- en gegevensvooroordelen. Deze fase vindt plaats in een of meer toegewezen en beveiligde Machine Learning-werkruimten.

  7. Productie-implementatie

    Nadat een model de faserings- en testfase heeft doorgegeven, kunnen machine learning-technici goedkeuring door mensen in de lus gebruiken om deze te promoveren naar productie. Modelimplementatieopties omvatten een beheerd batch-eindpunt voor batchscenario's of een beheerd online-eindpunt of Kubernetes-implementatie die gebruikmaakt van Azure Arc voor online, bijna realtime scenario's. De productie vindt doorgaans plaats in een of meer toegewezen en beveiligde Machine Learning-werkruimten.

  8. Controleren

    Machine learning-technici bewaken onderdelen in fasering, testen en productie om metrische gegevens te verzamelen met betrekking tot wijzigingen in de prestaties van het model, de gegevens en de infrastructuur. Ze kunnen deze metrische gegevens gebruiken om actie te ondernemen. Model- en gegevensbewaking kan bestaan uit het controleren op model- en gegevensdrift, modelprestaties voor nieuwe tekstgegevens en verantwoorde AI-problemen. Infrastructuurbewaking kan problemen identificeren, zoals trage reactie op eindpunten, onvoldoende rekencapaciteit en netwerkproblemen.

  9. Bewaking van gegevens en modellen: gebeurtenissen en acties

    Net als bij de CV-architectuur zijn de gegevens- en modelbewakings- en gebeurtenis- en actiefasen van MLOps voor verwerking in natuurlijke taal de belangrijkste verschillen van klassieke machine learning. Geautomatiseerde hertraining wordt meestal niet uitgevoerd in scenario's voor verwerking van natuurlijke taal wanneer modelprestaties worden gedetecteerd voor nieuwe tekst. In dit geval is een human-in-the-loop-proces nodig om nieuwe tekstgegevens te controleren en aantekeningen te maken voor het model dat slecht presteert. Vaak gaat de volgende actie terug naar de ontwikkelingslus van het model om het model bij te werken met de nieuwe tekstgegevens.

  10. Bewaking van infrastructuur: gebeurtenissen en acties

    Geautomatiseerde triggers en meldingen kunnen de juiste acties implementeren die moeten worden uitgevoerd op basis van infrastructuurcriteria, zoals een vertraging van een eindpuntreactie of onvoldoende rekenkracht voor de implementatie. Automatische triggers en meldingen kunnen een loopback activeren naar de installatie- en beheerfase, waar het infrastructuurteam het probleem kan onderzoeken en reken- en netwerkresources mogelijk opnieuw kan configureren.

Onderdelen

  • Machine Learning is een cloudservice die u kunt gebruiken om machine learning-modellen op schaal te trainen, beoordelen, implementeren en beheren.

  • Azure Pipelines is een build-and-testsysteem dat is gebaseerd op Azure DevOps en wordt gebruikt voor build- en release-pijplijnen. Met Azure Pipelines worden deze pijplijnen gesplitst in logische stappen die taken worden genoemd.

  • GitHub is een platform voor het hosten van code voor versiebeheer, samenwerking en CI/CD-werkstromen.

  • Azure Arc is een platform dat Gebruikmaakt van Azure Resource Manager voor het beheren van Azure-resources en on-premises resources. De resources kunnen virtuele machines, Kubernetes-clusters en databases bevatten.

  • Kubernetes is een opensource-systeem dat u kunt gebruiken om de implementatie, schaalaanpassing en het beheer van toepassingen in containers te automatiseren.

  • Azure Data Lake Storage is een met Hadoop compatibel bestandssysteem. Het heeft een geïntegreerde hiërarchische naamruimte en de enorme schaal en economie van Blob Storage.

  • Azure Synapse Analytics is een onbeperkte analyseservice die gegevensintegratie, zakelijke datawarehousing en big data-analyses combineert.

  • Azure Event Hubs is een service die gegevensstromen opneemt die clienttoepassingen genereren. Vervolgens worden streaminggegevens opgenomen en opgeslagen, waardoor de volgorde van ontvangen gebeurtenissen behouden blijft. Klanten kunnen verbinding maken met de hub-eindpunten om berichten op te halen voor verwerking. Deze architectuur maakt gebruik van Data Lake Storage-integratie.

Andere overwegingen

Het voorgaande architectuurpatroon van MLOps v2 heeft verschillende essentiële onderdelen, waaronder op rollen gebaseerd toegangsbeheer (RBAC) dat overeenkomt met zakelijke belanghebbenden, efficiënt pakketbeheer en robuuste bewakingsmechanismen. Deze onderdelen dragen gezamenlijk bij aan de succesvolle implementatie en het beheer van machine learning-werkstromen.

Op persona gebaseerde RBAC

Het is van cruciaal belang dat u de toegang tot machine learning-gegevens en -resources beheert. RBAC biedt een robuust framework om u te helpen bij het beheren wie specifieke acties kan uitvoeren en toegang kan krijgen tot specifieke gebieden binnen uw oplossing. Ontwerp uw identiteitssegmentatiestrategie om te voldoen aan de levenscyclus van machine learning-modellen in Machine Learning en de persona's die in het proces zijn opgenomen. Elke persona heeft een specifieke set verantwoordelijkheden die worden weerspiegeld in hun RBAC-rollen en groepslidmaatschap.

Voorbeeld van persona's

Als u de juiste segmentatie in een machine learning-workload wilt ondersteunen, moet u rekening houden met de volgende algemene persona's die het op identiteit gebaseerde RBAC-groepsontwerp informeren.

Data scientist en machine learning-engineer

Gegevenswetenschappers en machine learning-engineers voeren verschillende machine learning- en data science-activiteiten uit in de levenscyclus van softwareontwikkeling van een project. Hun taken omvatten verkennende gegevensanalyse en voorverwerking van gegevens. Gegevenswetenschappers en machine learning-engineers zijn verantwoordelijk voor het trainen, evalueren en implementeren van modellen. De verantwoordelijkheden van deze rollen omvatten ook break-fix-activiteiten voor machine learning-modellen, pakketten en gegevens. Deze taken vallen buiten het bereik van het technische ondersteuningsteam van het platform.

Type: Persoon
Projectspecifiek: Ja

Gegevensanalist

Gegevensanalisten bieden de benodigde invoer voor data science-activiteiten, zoals het uitvoeren van SQL-query's voor business intelligence. De verantwoordelijkheden van deze rol omvatten het werken met gegevens, het uitvoeren van gegevensanalyse en het ondersteunen van modelontwikkeling en modelimplementatie.

Type: Persoon
Projectspecifiek: Ja

Modeltester

Modeltesters voeren tests uit in test- en faseringsomgevingen. Deze rol biedt functionele scheiding van de CI/CD-processen.

Type: Persoon
Projectspecifiek: Ja

Zakelijke belanghebbenden

Zakelijke belanghebbenden zijn gekoppeld aan het project, zoals een marketingmanager.

Type: Persoon
Projectspecifiek: Ja

Projectleider of data science-lead

De data science-lead is een projectbeheerrol voor de Machine Learning-werkruimte. Deze rol voert ook break-fix-activiteiten uit voor de machine learning-modellen en -pakketten.

Type: Persoon
Projectspecifiek: Ja

Project- of producteigenaar (bedrijfseigenaar)

Zakelijke belanghebbenden zijn verantwoordelijk voor de Machine Learning-werkruimte op basis van het eigendom van gegevens.

Type: Persoon
Projectspecifiek: Ja

Technische ondersteuning voor platform

De technische ondersteuning van het platform is het technische ondersteuningspersoneel dat verantwoordelijk is voor break-fix-activiteiten op het platform. Deze rol heeft betrekking op infrastructuur of service, maar niet op de machine learning-modellen, -pakketten of -gegevens. Deze onderdelen blijven onder de rol data scientist of machine learning-engineer en zijn de verantwoordelijkheid van de projectmanager.

Type: Persoon
Projectspecifiek: Nee

Eindgebruiker modelleren

Eindgebruikers van modellen zijn de eindgebruikers van het machine learning-model.

Type: Persoon of proces
Projectspecifiek: Ja

CI/CD-processen

CI/CD-processen brengen wijzigingen in platformomgevingen vrij of terugdraaien.

Type: Proces
Projectspecifiek: Nee

Werkruimte voor Machine Learning

Machine Learning-werkruimten gebruiken beheerde identiteiten om te communiceren met andere onderdelen van Azure. Deze persona vertegenwoordigt de verschillende services waaruit een Machine Learning-implementatie bestaat. Deze services communiceren met andere onderdelen van het platform, zoals de ontwikkelwerkruimte die verbinding maakt met het ontwikkelingsgegevensarchief.

Type: Proces
Projectspecifiek: Nee

Bewakingsprocessen

Bewakingsprocessen zijn rekenprocessen die bewaken en waarschuwen op basis van platformactiviteiten.

Type: Proces
Projectspecifiek: Nee

Processen voor gegevensbeheer

Processen voor gegevensbeheer scannen het machine learning-project en gegevensarchieven op gegevensbeheer.

Type: Proces
Projectspecifiek: Nee

Microsoft Entra-groepslidmaatschap

Wanneer u RBAC implementeert, bieden Microsoft Entra-groepen een flexibele en schaalbare manier om toegangsmachtigingen voor verschillende persona's te beheren. U kunt Microsoft Entra-groepen gebruiken om gebruikers te beheren die dezelfde toegang en machtigingen nodig hebben voor resources, zoals mogelijk beperkte apps en services. In plaats van speciale machtigingen toe te voegen aan afzonderlijke gebruikers, maakt u een groep die de speciale machtigingen toepast op elk lid van die groep.

In dit architectuurpatroon kunt u deze groepen koppelen aan de installatie van een Machine Learning-werkruimte, zoals een project, team of afdeling. U kunt gebruikers koppelen aan specifieke groepen om gedetailleerd toegangsbeleid te definiëren. Het beleid verleent of beperkt machtigingen aan verschillende Machine Learning-werkruimten op basis van taakfuncties, projectvereisten of andere criteria. U kunt bijvoorbeeld een groep hebben die alle gegevenswetenschappers toegang verleent tot een ontwikkelwerkruimte voor een specifieke use-case.

Identiteits-RBAC

Overweeg hoe u de volgende ingebouwde Azure RBAC-rollen kunt gebruiken om RBAC toe te passen op productie- en preproductieomgevingen. Voor de architectuur in dit artikel bevatten de productieomgevingen fasering, testen en productieomgevingen. De preproductieomgevingen omvatten ontwikkelomgevingen. De volgende RBAC-rollen zijn gebaseerd op de persona's die eerder in dit artikel zijn beschreven.

Standaardrollen

Onderdelenspecifieke rollen

Deze afkortingen van Azure RBAC-rollen komen overeen met de volgende tabellen.

Productieomgeving
Persona Werkruimte voor Machine Learning Azure Key Vault Container Registry Azure Storage-account Azure DevOps Azure Artifacts Log Analytics-werkruimte Azure Monitor
Data scientist R LAR NAAMWIJZIGING
Gegevensanalist
Modeltester
Zakelijke belanghebbenden NAAMWIJZIGING
Projectleider (data science lead) R R, KVR R LAR NAAMWIJZIGING
Project-/producteigenaar NAAMWIJZIGING
Technische ondersteuning voor platform O O, KVA DOPCA O O O
Eindgebruiker modelleren
CI/CD-processen O O, KVA AcrPush DOPCA O O O
Werkruimte voor Machine Learning R C C
Bewakingsprocessen R LAR NAAMWIJZIGING
Processen voor gegevensbeheer R R R R R
Preproductieomgeving
Persona Werkruimte voor Machine Learning Key Vault Container Registry Opslagaccount Azure DevOps Azure Artifacts Log Analytics-werkruimte Azure Monitor
Data scientist ADVERTENTIES R, KVA C C C C LAC MC
Gegevensanalist R C LAR MC
Modeltester R R, KVR R R R R LAR NAAMWIJZIGING
Zakelijke belanghebbenden R R R R R
Projectleider (data science lead) E C, KVA C C C C LAC MC
Project-/producteigenaar R R NAAMWIJZIGING
Technische ondersteuning voor platform O O, KVA O O DOPCA O O O
Eindgebruiker modelleren
CI/CD-processen O O, KVA AcrPush O DOPCA O O O
Werkruimte voor Machine Learning R, KVR C C
Bewakingsprocessen R R R R R R LAC
Processen voor gegevensbeheer R R R

Notitie

Elke persona behoudt toegang tot de duur van het project, behalve de technische ondersteuning van het platform, met tijdelijke of just-in-time toegang tot Microsoft Entra Privileged Identity Management (PIM).

RBAC speelt een belangrijke rol bij het beveiligen en stroomlijnen van MLOps-werkstromen. RBAC beperkt de toegang op basis van toegewezen rollen en voorkomt dat onbevoegde gebruikers toegang krijgen tot gevoelige gegevens, waardoor beveiligingsrisico's worden beperkt. Gevoelige gegevens omvatten trainingsgegevens of modellen en kritieke infrastructuur, zoals productiepijplijnen. U kunt RBAC gebruiken om te zorgen voor naleving van privacyvoorschriften voor gegevens. RBAC biedt ook een duidelijk overzicht van toegang en machtigingen, wat de controle vereenvoudigt, maakt het gemakkelijk om beveiligingsproblemen te identificeren en gebruikersactiviteiten bij te houden.

Pakketbeheer

Afhankelijkheden van verschillende pakketten, bibliotheken en binaire bestanden zijn gebruikelijk gedurende de levenscyclus van MLOps. Deze afhankelijkheden, vaak door de gemeenschap ontwikkelde en snel veranderende, vereisen deskundige kennis van onderwerpen voor goed gebruik en begrip. U moet ervoor zorgen dat de juiste personen beveiligde toegang hebben tot diverse assets, zoals pakketten en bibliotheken, maar u moet ook beveiligingsproblemen voorkomen. Gegevenswetenschappers ondervinden dit probleem bij het samenstellen van gespecialiseerde bouwstenen voor machine learning-oplossingen. Traditionele benaderingen voor softwarebeheer zijn kostbaar en inefficiënt. Andere benaderingen bieden meer waarde.

Als u deze afhankelijkheden wilt beheren, kunt u een beveiligd, selfserviceproces voor pakketbeheer gebruiken op basis van het quarantainepatroon. U kunt dit proces ontwerpen zodat gegevenswetenschappers zichzelf kunnen bedienen vanuit een gecureerde lijst met pakketten en ervoor zorgen dat de pakketten veilig zijn en voldoen aan de organisatiestandaarden.

Deze benadering omvat drie standaard machine learning-pakketopslagplaatsen voor de industrie: Microsoft-artefactregister, Python Package Index (PyPI) en Conda. Veilige vermelding maakt selfservice mogelijk vanuit afzonderlijke Machine Learning-werkruimten. Gebruik vervolgens een geautomatiseerd testproces tijdens de implementatie om de resulterende oplossingscontainers te scannen. Fouten sluiten het implementatieproces elegant af en verwijderen de container. In het volgende diagram en de processtroom ziet u dit proces:

Diagram met de benadering van het beveiligde Machine Learning-pakket.

Processtroom

  1. Gegevenswetenschappers die werken in een Machine Learning-werkruimte met een netwerkconfiguratie , kunnen machine learning-pakketten op aanvraag zelf bedienen vanuit de opslagplaatsen van machine learning-pakketten. Een uitzonderingsproces is vereist voor al het andere met behulp van het privéopslagpatroon , dat wordt gezaaid en onderhouden met behulp van een gecentraliseerde functie.

  2. Machine Learning levert machine learning-oplossingen als Docker-containers. Naarmate deze oplossingen zijn ontwikkeld, worden ze geüpload naar Container Registry. Microsoft Defender for Containers genereert evaluaties van beveiligingsproblemen voor de containerinstallatiekopie.

  3. Implementatie van oplossingen vindt plaats via een CI/CD-proces. Microsoft Defender voor DevOps wordt overal in de stack gebruikt om beveiligingspostuurbeheer en bedreigingsbeveiliging te bieden.

  4. De oplossingscontainer wordt alleen geïmplementeerd als deze elk van de beveiligingsprocessen doorgeeft. Als de oplossingscontainer een beveiligingsproces mislukt, mislukt de implementatie met foutmeldingen en volledige audittrails. De oplossingscontainer wordt verwijderd.

De vorige processtroom biedt een veilig, selfserviceproces voor pakketbeheer voor gegevenswetenschappers en zorgt ervoor dat de pakketten veilig zijn en voldoen aan de organisatiestandaarden. Als u innovatie en beveiliging wilt verdelen, kunt u gegevenswetenschappers selfservicetoegang verlenen tot algemene machine learning-pakketten, bibliotheken en binaire bestanden in preproductieomgevingen. Uitzonderingen vereisen voor minder gangbare pakketten. Deze strategie zorgt ervoor dat gegevenswetenschappers productief kunnen blijven tijdens de ontwikkeling, waardoor een groot knelpunt tijdens de levering wordt voorkomen.

Om uw releaseprocessen te stroomlijnen, kunt u omgevingen in containers opslaan voor gebruik in productieomgevingen. In containers geplaatste omgevingen verminderen toil en zorgen voor continue beveiliging door middel van scannen op beveiligingsproblemen. Deze processtroom biedt een herhaalbare benadering die u in gebruiksscenario's kunt gebruiken tot het tijdstip van levering. Het vermindert de totale kosten voor het bouwen en implementeren van machine learning-oplossingen binnen uw onderneming.

Controleren

In MLOps is bewaking van cruciaal belang voor het onderhouden van de status en prestaties van machine learning-systemen en ervoor te zorgen dat modellen effectief en afgestemd blijven op bedrijfsdoelen. Bewaking ondersteunt governance, beveiliging en kostencontroles tijdens de binnenste lusfase. En het biedt waarneembaarheid in de prestaties, modeldegradatie en gebruik bij het implementeren van oplossingen tijdens de buitenste lusfase. Bewakingsactiviteiten zijn relevant voor persona's zoals Datawetenschapper s, zakelijke belanghebbenden, projectleiders, projecteigenaren, platform technische ondersteuning, CI/CD-processen en bewakingsprocessen.

Kies uw bewakings- en verificatieplatform, afhankelijk van de installatie van uw Machine Learning-werkruimte, zoals een project, team of afdeling.

Modelprestaties

Bewaak de modelprestaties om modelproblemen en prestatievermindering vroeg te detecteren. Houd de prestaties bij om ervoor te zorgen dat modellen nauwkeurig, betrouwbaar en afgestemd blijven op bedrijfsdoelstellingen.

Gegevensdrift

Gegevensdrift houdt wijzigingen in de distributie van de invoergegevens van een model bij door deze te vergelijken met de trainingsgegevens van het model of recente eerdere productiegegevens. Deze wijzigingen zijn het gevolg van wijzigingen in marktdynamiek, wijzigingen in functietransformatie of upstream-gegevenswijzigingen. Dergelijke wijzigingen kunnen de prestaties van het model verminderen, dus het is belangrijk om te controleren op drift om ervoor te zorgen dat het tijdig herstel wordt gegarandeerd. Voor het uitvoeren van een vergelijking zijn recente productiegegevenssets en -uitvoer nodig om gegevensdrift te herstructureren.

Omgeving: Productie
Azure-facilitering: Machine Learning - Modelbewaking

Voorspellingsdrift

Voorspellingsdrift houdt wijzigingen in de distributie van de voorspellingsuitvoer van een model bij door deze te vergelijken met validatie, testlabel of recente productiegegevens. Voor het uitvoeren van een vergelijking zijn recente productiegegevenssets en -uitvoer nodig om gegevensdrift te herstructureren.

Omgeving: Productie
Azure-facilitering: Machine Learning - Modelbewaking

Bron

Gebruik verschillende metrische gegevens voor eindpunten om kwaliteit en prestaties aan te geven, zoals CPU- of geheugengebruik. Deze aanpak helpt u bij het leren van productie om toekomstige investeringen of veranderingen te stimuleren.

Omgeving: alle
Azure-facilitering: Bewaken - Metrische gegevens van online-eindpunten

Metrische gebruiksgegevens

Bewaak het gebruik van eindpunten om ervoor te zorgen dat u voldoet aan organisatiespecifieke of workloadspecifieke key performance indicators, gebruikspatronen bijhouden en problemen vaststellen en oplossen die uw gebruikers ervaren.

Aanvragen van clients

Houd het aantal clientaanvragen bij naar het modeleindpunt om inzicht te hebben in het actieve gebruiksprofiel van de eindpunten, wat van invloed kan zijn op het schalen of optimaliseren van kosten.

Omgeving: Productie
Azure-facilitering: Bewaken - Metrische gegevens voor online-eindpunten, zoals RequestsPerMinute. Opmerkingen:

  • U kunt acceptabele drempelwaarden uitlijnen op de grootte of afwijkingen van t-shirt die zijn afgestemd op de behoeften van uw workload.
  • Modellen buiten gebruik stellen die niet meer worden gebruikt vanuit productie.
Vertraging beperken

Vertragingen bij bandbreedtebeperking zijn vertragingen in de aanvraag en reactie van gegevensoverdracht. Beperking vindt plaats op Resource Manager-niveau en op serviceniveau. Metrische gegevens bijhouden op beide niveaus.

Omgeving: Productie
Azure-facilitering:

  • Monitor - Resource Manager, som van RequestThrottlingDelayMs, ResponseThrottlingDelayMs.
  • Machine Learning: als u informatie wilt controleren over de aanvragen van uw eindpunten, kunt u online verkeerslogboeken voor eindpunten inschakelen. U kunt een Log Analytics-werkruimte gebruiken om logboeken te verwerken.

Opmerkingen: aanvaardbare drempelwaarden afstemmen op de serviceniveaudoelstellingen (SLO's) van uw workload of sla's (service level agreements) en de niet-functionele vereisten (NFR's) van de oplossing.

Fouten gegenereerd

Houd responscodefouten bij om de betrouwbaarheid van de service te meten en ervoor te zorgen dat serviceproblemen vroegtijdig worden gedetecteerd. Een plotselinge toename in 500 serverfoutreacties kan bijvoorbeeld duiden op een kritiek probleem dat onmiddellijk aandacht nodig heeft.

Omgeving: Productie
Azure-facilitering: Machine Learning : schakel logboeken voor online-eindpuntverkeer in om informatie over uw aanvraag te controleren. U kunt bijvoorbeeld het aantal XRequestId controleren met behulp van ModelStatusCode of ModelStatusReason. U kunt een Log Analytics-werkruimte gebruiken om logboeken te verwerken.
Opmerkingen:

  • Alle HTTP-antwoordcodes in het bereik 400 en 500 worden geclassificeerd als een fout.

Kostenoptimalisatie

Kostenbeheer en optimalisatie in een cloudomgeving zijn van cruciaal belang omdat ze workloads helpen bij het beheren van kosten, het efficiënt toewijzen van resources en het maximaliseren van de waarde van hun cloudservices.

Rekenkracht van werkruimte

Wanneer maandelijkse operationele uitgaven een vooraf gedefinieerd bedrag bereiken of overschrijden, genereert u waarschuwingen om relevante belanghebbenden, zoals projectleiders of projecteigenaren, te informeren op basis van de grenzen van de werkruimte-instelling. U kunt de instellingen van uw werkruimte bepalen op basis van project-, team- of afdelingsgrenzen.

Omgeving: alle
Azure-facilitering: Microsoft Cost Management - Budgetwaarschuwingen
Opmerkingen:

  • Budgetdrempels instellen op basis van de eerste NFR's en kostenramingen.
  • Gebruik meerdere drempelwaarden. Meerdere drempelwaarden zorgen ervoor dat belanghebbenden de juiste waarschuwing krijgen voordat het budget wordt overschreden. Deze belanghebbenden kunnen zakelijke leads, projecteigenaren of projectleiders omvatten, afhankelijk van de organisatie of workload.
  • Consistente budgetwaarschuwingen kunnen ook een trigger zijn voor het herstructureren om grotere vraag te ondersteunen.
Werkruimte staleness

Als in een Machine Learning-werkruimte geen tekenen van actief gebruik worden weergegeven op basis van het bijbehorende rekengebruik voor de beoogde use-case, kan een projecteigenaar de werkruimte buiten gebruik stellen als deze niet meer nodig is voor een bepaald project.

Omgeving: Preproductie
Azure-facilitering:

Opmerkingen:

  • Actieve kernen moeten gelijk zijn aan nul met de aggregatie van het aantal.
  • Datumdrempels uitlijnen op de projectplanning.

Beveiliging

Bewaak om afwijkingen van de juiste beveiligingscontroles en basislijnen te detecteren om ervoor te zorgen dat Machine Learning-werkruimten voldoen aan het beveiligingsbeleid van uw organisatie. U kunt een combinatie van vooraf gedefinieerde en aangepaste beleidsregels gebruiken.

Omgeving: alle
Azure-facilitering: Azure Policy voor Machine Learning

Eindpuntbeveiliging

Als u inzicht wilt krijgen in bedrijfskritieke API's, implementeert u gerichte beveiligingsbewaking van alle Machine Learning-eindpunten. U kunt uw API-beveiligingspostuur onderzoeken en verbeteren, oplossingen voor beveiligingsproblemen prioriteren en snel actieve realtime bedreigingen detecteren.

Omgeving: Productie
Azure-facilitering: Microsoft Defender voor API's biedt uitgebreide levenscyclusbeveiliging, detectie en responsdekking voor API's. Opmerkingen: Defender voor API's biedt beveiliging voor API's die zijn gepubliceerd in Azure API Management. U kunt Defender voor API's onboarden in de Microsoft Defender voor Cloud-portal of in het API Management-exemplaar in Azure Portal. U moet Online-eindpunten van Machine Learning integreren met API Management.

Implementatiebewaking

Implementatiebewaking zorgt ervoor dat alle eindpunten die u maakt voldoen aan uw workload- of organisatiebeleid en vrij zijn van beveiligingsproblemen. Voor dit proces moet u nalevingsbeleid afdwingen voor uw Azure-resources vóór en na de implementatie, zorgen voor continue beveiliging via scannen op beveiligingsproblemen en ervoor zorgen dat de service voldoet aan SLO's terwijl deze wordt uitgevoerd.

Standaarden en governance

Bewaak om afwijkingen van de juiste standaarden te detecteren en ervoor te zorgen dat uw workload voldoet aan de kaders.

Omgeving: alle
Azure-facilitering:

  • Beheerde beleidstoewijzing en levenscyclus via Azure Pipelines om beleid als code te behandelen.
  • PSRule voor Azure biedt een testframework voor Azure-infrastructuur als code.
  • U kunt Enterprise Azure Policy gebruiken als code in op CI/CD gebaseerd systeem implementeren beleidsregels, beleidssets, toewijzingen, beleidsvrijstellingen en roltoewijzingen.

Opmerkingen: Zie Azure-richtlijnen voor naleving van machine learning-regelgeving voor meer informatie.

Beveiligingsscans

Implementeer geautomatiseerde beveiligingsscans als onderdeel van de geautomatiseerde integratie- en implementatieprocessen.

Omgeving: alle
Azure-facilitering: Defender for DevOps
Opmerkingen: U kunt apps in Azure Marketplace gebruiken om dit proces voor niet-Microsoft-beveiligingstestmodules uit te breiden.

Doorlopende service

Bewaak de doorlopende service van een API voor prestatieoptimalisatie, beveiliging en resourcegebruik. Zorg voor tijdige foutdetectie, efficiënte probleemoplossing en naleving van standaarden.

Omgeving: Productie
Azure-facilitering:

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen