Delen via

Machine learning-bewerkingen (MLOps) v2

  • Artikel

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

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

De architecturen zijn het product van het MLOps v2-project. Ze bevatten de best practices die de oplossingsarchitecten hebben ontdekt tijdens het maken van meerdere machine learning-oplossingen. Het resultaat is implementeerbare, herhaalbare en onderhoudbare patronen, zoals hier wordt beschreven.

Alle architecturen maken gebruik van de Azure Machine Learning-service.

Zie de Oplossingsversneller azure MLOps (v2) op GitHub voor een implementatie met voorbeeldimplementatiesjablonen voor MLOps v2.

Potentiële gebruikscases

  • Klassieke machine learning: Tijdreeksprognoses, regressie en classificatie op gestructureerde gegevens in tabelvorm zijn de meest voorkomende use cases in deze categorie. Voorbeelden zijn:
    • Binaire classificatie en classificatie met meerdere labels
    • Lineaire, polynomiale, ridge, lasso, kwantiel en Bayesiaanse regressie
    • ARIMA, autoregressive (AR), SARIMA, VAR, SES, LSTM
  • CV: Het MLOps-framework dat hier wordt gepresenteerd, is voornamelijk gericht op de CV-use cases van segmentatie en afbeeldingsclassificatie.
  • NLP: Dit MLOps-framework kan elk van deze use cases implementeren, en andere niet vermeld:
    • Herkenning van genoemde entiteiten
    • Tekstclassificatie
    • Tekst genereren
    • Sentimentanalyse
    • Vertaling
    • Vragen beantwoorden
    • Samenvatting
    • Zinsdetectie
    • Taaldetectie
    • Woordsoorten taggen

Simulaties, deep reinforcement learning en andere vormen van AI vallen niet onder dit artikel.

Architectuur

Het architectuurpatroon MLOps v2 bestaat uit vier belangrijke modulaire elementen die deze fasen van de MLOps-levenscyclus vertegenwoordigen:

  • Gegevensdomein
  • Beheer beheer en installatie
  • Modelontwikkeling (interne lus)
  • Modelimplementatie (buitenste lus)

Deze elementen, de relaties tussen deze elementen en de persona's die er doorgaans aan zijn gekoppeld, zijn gebruikelijk voor alle MLOps v2-scenarioarchitecturen. Er kunnen variaties zijn in de details van elk, 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.

Huidige architecturen

De architecturen die momenteel worden behandeld door MLOps v2 en die in dit artikel worden besproken, zijn:

Klassieke machine learning-architectuur

Diagram voor de klassieke machine learning-architectuur.

Een Visio-bestand van deze architectuur downloaden.

Werkstroom voor de klassieke machine learning-architectuur

  1. Gegevensdomein

    Dit element illustreert het gegevensdomein van de organisatie en mogelijke gegevensbronnen en doelen voor een data science-project. Data engineers zijn de primaire eigenaren van dit element van de MLOps v2-levenscyclus. De Azure-gegevensplatforms in dit diagram zijn niet volledig of prescriptief. De gegevensbronnen en doelen die aanbevolen best practices vertegenwoordigen op basis van de use-case van de klant, worden aangegeven met een groen vinkje.

  2. Beheer beheer en installatie

    Dit element is de eerste stap in de implementatie van de MLOps v2-accelerator. Het bestaat uit alle taken met betrekking tot het maken en beheren van resources en rollen die aan het project zijn gekoppeld. Dit kunnen de volgende taken zijn, en misschien andere:

    1. Het maken van opslagplaatsen voor projectbroncode
    2. Machine Learning-werkruimten maken met Bicep of Terraform
    3. Gegevenssets en rekenresources maken of wijzigen die worden gebruikt voor het ontwikkelen en implementeren van modellen
    4. Definitie van projectteamgebruikers, hun rollen en toegangsbeheer voor andere resources
    5. CI/CD-pijplijnen maken
    6. Monitors maken voor het verzamelen en melden van metrische gegevens van modellen en infrastructuur

    De primaire persona die aan deze fase is gekoppeld, is het infrastructuurteam, maar er kunnen ook data engineers, machine learning-engineers en gegevenswetenschappers zijn.

  3. Modelontwikkeling (interne lus)

    Het binnenste luselement bestaat uit uw iteratieve data science-werkstroom die werkt binnen een toegewezen, beveiligde Machine Learning-werkruimte. Een typische werkstroom wordt geïllustreerd in het diagram. Het gaat over gegevensopname, verkennende gegevensanalyse, experimenten, modelontwikkeling en -evaluatie, tot registratie van een kandidaatmodel voor productie. Dit modulaire element, zoals geïmplementeerd in de MLOps v2-accelerator, is agnostisch en aanpasbaar 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 een kandidaat is voor implementatie in productie, kan het model worden geregistreerd 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 (buitenste lus)

    De fase van de modelimplementatie of buitenste lus bestaat uit fasering en testen van preproductie, productie-implementatie en bewaking van model, gegevens en infrastructuur. CD-pijplijnen beheren de promotie van het model en gerelateerde assets via productie, bewaking en mogelijke hertraining, omdat aan criteria die geschikt zijn voor uw organisatie en use-case worden voldaan.

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

  6. Fasering en test

    De faserings- en testfase kan variëren met klantprocedures, maar omvat meestal 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, beveiligde Machine Learning-werkruimten.

  7. Productie-implementatie

    Nadat een model de faserings- en testfase heeft doorgegeven, kan het worden gepromoveerd naar productie met behulp van een door de mens in de lus beperkte goedkeuring. Modelimplementatieopties omvatten een beheerd batch-eindpunt voor batchscenario's of, voor online, bijna realtime scenario's, ofwel een beheerd online-eindpunt of Kubernetes-implementatie met behulp van Azure Arc. Productie vindt doorgaans plaats in een of meer toegewezen, beveiligde Machine Learning-werkruimten.

  8. Controleren

    Door te bewaken in fasering, testen en productie kunt u metrische gegevens verzamelen voor en actie ondernemen, wijzigingen in de prestaties van het model, gegevens en infrastructuur. Model- en gegevensbewaking kan bestaan uit het controleren op model- en gegevensdrift, modelprestaties op nieuwe gegevens en verantwoorde AI-problemen. Infrastructuurbewaking kan controleren op trage eindpuntrespons, onvoldoende rekencapaciteit of netwerkproblemen.

  9. Bewaking van gegevens en modellen: gebeurtenissen en acties

    Op basis van criteria voor model- en gegevenskwesties van belang, zoals metrische drempelwaarden of planningen, kunnen geautomatiseerde triggers en meldingen passende acties implementeren om te ondernemen. Dit kan regelmatig worden gepland voor automatische hertraining van het model op nieuwere productiegegevens en een loopback naar fasering en test voor preproductie-evaluatie. Het kan ook worden veroorzaakt door triggers voor model- of gegevensproblemen waarvoor een loopback naar de fase voor modelontwikkeling is vereist, waarbij gegevenswetenschappers een nieuw model kunnen onderzoeken en mogelijk ontwikkelen.

  10. Bewaking van infrastructuur: gebeurtenissen en acties

    Op basis van criteria voor de infrastructuur die van belang zijn, zoals vertraging van eindpuntreacties of onvoldoende rekenkracht voor de implementatie, kunnen geautomatiseerde triggers en meldingen de juiste acties implementeren die moeten worden uitgevoerd. Ze activeren een loopback naar de installatie- en beheerfase waar het infrastructuurteam de reken- en netwerkresources kan onderzoeken en mogelijk opnieuw configureren.

Machine Learning CV-architectuur

Diagram voor 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 element illustreert het gegevensdomein van de organisatie en potentiële gegevensbronnen en doelen voor een data science-project. Data engineers zijn de primaire eigenaren van dit element van de MLOps v2-levenscyclus. De Azure-gegevensplatforms in dit diagram zijn niet volledig of prescriptief. Afbeeldingen voor CV-scenario's kunnen afkomstig zijn van veel verschillende gegevensbronnen. Voor efficiëntie bij het ontwikkelen en implementeren van CV-modellen met Machine Learning zijn aanbevolen Azure-gegevensbronnen voor installatiekopieën Azure Blob Storage en Azure Data Lake Storage.

  2. Beheer beheer en installatie

    Dit element is de eerste stap in de implementatie van de MLOps v2-accelerator. 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 met een extra stap: afbeeldingslabels en aantekeningenprojecten maken met behulp van de labelfunctie van Machine Learning of een ander hulpprogramma.

  3. Modelontwikkeling (interne lus)

    Het binnenste luselement bestaat uit uw iteratieve data science-werkstroom die wordt uitgevoerd in een toegewezen, 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 element van deze ontwikkelingslus is.

  4. Machine Learning-registers

    Nadat het data science-team een model heeft ontwikkeld dat een kandidaat is voor implementatie in productie, kan het model worden geregistreerd 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 (buitenste lus)

    De fase van de modelimplementatie of buitenste lus bestaat uit fasering en testen van preproductie, productie-implementatie en bewaking van model, gegevens en infrastructuur. CD-pijplijnen beheren de promotie van het model en de gerelateerde assets via productie, bewaking en potentiële hertraining als aan uw organisatie en gebruiksscenario is voldaan.

  6. Fasering en test

    De faserings- en testfase kan variëren met klantprocedures, maar omvat meestal bewerkingen zoals testimplementaties voor eindpuntprestaties, controles van gegevenskwaliteit, eenheidstests en verantwoorde AI-controles voor model- en gegevensvooroordelen. Voor CV-scenario's kan het opnieuw trainen van de modelkandidaat op productiegegevens worden weggelaten vanwege resource- en tijdsbeperkingen. In plaats daarvan kan het data science-team productiegegevens gebruiken voor modelontwikkeling en het kandidaatmodel dat is geregistreerd bij de ontwikkelingslus, is het model dat wordt geëvalueerd voor productie. Deze fase vindt plaats in een of meer toegewezen, beveiligde Machine Learning-werkruimten.

  7. Productie-implementatie

    Nadat een model de faserings- en testfase heeft doorgegeven, kan het worden gepromoveerd naar productie via door de mens in de lus gated goedkeuringen. Modelimplementatieopties omvatten een beheerd batch-eindpunt voor batchscenario's of, voor online, bijna realtime scenario's, ofwel een beheerd online-eindpunt of Kubernetes-implementatie met behulp van Azure Arc. Productie vindt doorgaans plaats in een of meer toegewezen, beveiligde Machine Learning-werkruimten.

  8. Controleren

    Door te bewaken in fasering, testen en productie kunt u metrische gegevens verzamelen voor en reageren op wijzigingen in de prestaties van het model, de gegevens en de infrastructuur. Model- en gegevensbewaking kan bestaan uit het controleren op modelprestaties op nieuwe installatiekopieën. Infrastructuurbewaking kan controleren op trage eindpuntrespons, onvoldoende rekencapaciteit of netwerkproblemen.

  9. Bewaking van gegevens en modellen: gebeurtenissen en acties

    De gegevens- en modelbewakings- en gebeurtenis- en actiefasen van MLOps voor NLP 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 moeten nieuwe installatiekopieën waarvoor het model slecht presteert, worden beoordeeld en geannoteerd door een human-in-the-loop-proces, en vaak gaat de volgende actie terug naar de ontwikkelingslus van het model voor het bijwerken van het model met de nieuwe afbeeldingen.

  10. Bewaking van infrastructuur: gebeurtenissen en acties

    Op basis van criteria voor de infrastructuur die van belang zijn, zoals vertraging van eindpuntreacties of onvoldoende rekenkracht voor de implementatie, kunnen geautomatiseerde triggers en meldingen de juiste acties implementeren die moeten worden uitgevoerd. Hierdoor wordt een loopback geactiveerd naar de installatie- en beheerfase, waar het infrastructuurteam omgevingen, berekeningen en netwerkresources kan onderzoeken en mogelijk opnieuw kan configureren.

Machine Learning NLP-architectuur

Diagram voor de N L P-architectuur.

Een Visio-bestand van deze architectuur downloaden.

Werkstroom voor de NLP-architectuur

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

  1. Gegevensdomein

    Dit element illustreert het gegevensdomein van de organisatie en mogelijke gegevensbronnen en doelen voor een data science-project. Data engineers zijn de primaire eigenaren van dit element van de MLOps v2-levenscyclus. De Azure-gegevensplatforms in dit diagram zijn niet volledig of prescriptief. Gegevensbronnen en doelen die aanbevolen best practices vertegenwoordigen op basis van de use-case van de klant, worden aangegeven met een groen vinkje.

  2. Beheer beheer en installatie

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

  3. Modelontwikkeling (interne lus)

    Het binnenste luselement bestaat uit uw iteratieve data science-werkstroom die wordt uitgevoerd in een toegewezen, beveiligde Machine Learning-werkruimte. De typische ontwikkelingslus voor NLP-modellen kan aanzienlijk verschillen van het klassieke machine learning-scenario in dat aantekeningen voor zinnen en tokenisatie, normalisatie en insluitingen voor tekstgegevens de typische ontwikkelingsstappen voor dit scenario zijn.

  4. Machine Learning-registers

    Nadat het data science-team een model heeft ontwikkeld dat een kandidaat is voor implementatie in productie, kan het model worden geregistreerd 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 (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. CD-pijplijnen beheren de promotie van het model en gerelateerde assets via productie, bewaking en mogelijke hertraining, aangezien aan criteria voor uw organisatie en gebruiksscenario wordt voldaan.

  6. Fasering en test

    De faserings- en testfase kan variëren met klantprocedures, maar omvat meestal 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, beveiligde Machine Learning-werkruimten.

  7. Productie-implementatie

    Nadat een model de faserings- en testfase heeft doorgegeven, kan het worden gepromoveerd naar productie door een door de mens in de lus gesloten goedkeuring. Modelimplementatieopties omvatten een beheerd batch-eindpunt voor batchscenario's of, voor online, bijna realtime scenario's, ofwel een beheerd online-eindpunt of Kubernetes-implementatie met behulp van Azure Arc. Productie vindt doorgaans plaats in een of meer toegewezen, beveiligde Machine Learning-werkruimten.

  8. Controleren

    Met controle in fasering, test en productie kunt u wijzigingen in de prestaties van het model, de gegevens en de infrastructuur verzamelen en er actie op ondernemen. Model- en gegevensbewaking kan bestaan uit het controleren op model- en gegevensdrift, modelprestaties voor nieuwe tekstgegevens en verantwoorde AI-problemen. Infrastructuurbewaking kan controleren op problemen zoals trage eindpuntrespons, 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 NLP de belangrijkste verschillen van klassieke machine learning. Geautomatiseerde hertraining wordt doorgaans niet uitgevoerd in NLP-scenario's wanneer de prestatievermindering van het model op nieuwe tekst wordt gedetecteerd. In dit geval moeten nieuwe tekstgegevens waarvoor het model slecht presteert, worden beoordeeld en geannoteerd door een human-in-the-loop-proces. 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

    Op basis van criteria voor de infrastructuur die van belang zijn, zoals vertraging van eindpuntreacties of onvoldoende rekenkracht voor de implementatie, kunnen geautomatiseerde triggers en meldingen de juiste acties implementeren die moeten worden uitgevoerd. Ze activeren een loopback naar de installatie- en beheerfase waar het infrastructuurteam de reken- en netwerkresources kan onderzoeken en mogelijk opnieuw configureren.

Onderdelen

  • Machine Learning: een cloudservice voor training, scoren, implementeren en beheren van machine learning-modellen op schaal.
  • Azure Pipelines: dit build- en testsysteem is gebaseerd op Azure DevOps en wordt gebruikt voor de build- en release-pijplijnen. Met Azure Pipelines worden deze pijplijnen gesplitst in logische stappen die taken worden genoemd.
  • GitHub: een hostingplatform voor code voor versiebeheer, samenwerking en CI/CD-werkstromen.
  • Azure Arc: een platform voor het beheren van Azure- en on-premises resources met behulp van Azure Resource Manager. De resources kunnen virtuele machines, Kubernetes-clusters en databases bevatten.
  • Kubernetes: een opensource-systeem voor het automatiseren van implementatie, schaalaanpassing en beheer van toepassingen in containers.
  • Azure Data Lake: een hadoop-compatibel bestandssysteem. Het heeft een geïntegreerde hiërarchische naamruimte en de enorme schaal en economie van Blob Storage.
  • Azure Synapse Analytics: een onbeperkte analyseservice die gegevensintegratie, zakelijke datawarehousing en big data-analyses combineert.
  • Azure Event Hubs. Een service die gegevensstromen opneemt die worden gegenereerd door clienttoepassingen. Vervolgens worden streaminggegevens opgenomen en opgeslagen, waarbij de volgorde van ontvangen gebeurtenissen behouden blijft. Consumenten kunnen verbinding maken met de hub-eindpunten om berichten op te halen voor verwerking. Hier profiteren we van de integratie met Data Lake Storage.

Medewerkers

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

Belangrijkste auteurs:

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

Volgende stappen