Dela via

MLOps (Machine Learning Operations)

  • Artikel

Den här artikeln beskriver tre Azure-arkitekturer för maskininlärningsåtgärder som har ci/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans) från slutpunkt till slutpunkt och omträningspipelines. Arkitekturerna gäller för dessa AI-program:

  • Klassisk maskininlärning
  • Visuellt innehåll (CV)
  • Bearbetning av naturligt språk

Dessa arkitekturer är produkten av MLOps v2-projektet. De innehåller metodtips som lösningsarkitekter har identifierat i processen med att utveckla olika maskininlärningslösningar. Resultatet är distributionsbara, repeterbara och underhållsbara mönster. Alla tre arkitekturerna använder Azure Machine Learning-tjänsten.

En implementering med exempeldistributionsmallar för MLOps v2 finns i Azure MLOps v2 GitHub-lagringsplats.

Potentiella användningsfall

  • Klassisk maskininlärning: Prognostisering i tidsserier, regression och klassificering av tabellstrukturerade data är de vanligaste användningsfallen i den här kategorin. Exempel:

    • Binär klassificering och klassificering med flera etiketter.

    • Linjär, polynom, ås, lasso, quantil och bayesisk regression.

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

  • CV: MLOps-ramverket i den här artikeln fokuserar främst på cv-användningsfallen för segmentering och bildklassificering.

  • Bearbetning av naturligt språk: Du kan använda det här MLOps-ramverket för att implementera:

    • Namngiven entitetsigenkänning:

    • Textklassificering

    • Textgenerering

    • Attitydanalys

    • Översättning

    • Frågor och svar

    • Summering

    • Meningsidentifiering

    • Språkidentifiering

    • Del av tal-märkning

AI-simuleringar, djup förstärkningsinlärning och andra former av AI beskrivs inte i den här artikeln.

Arkitektur

Arkitekturmönstret MLOps v2 har fyra huvudsakliga modulära komponenter, eller faser, i MLOps-livscykeln:

  • Dataegendom
  • Administration och installation
  • Modellutveckling eller den inre loopfasen
  • Modelldistribution eller den yttre loopfasen

De föregående komponenterna, anslutningarna mellan dem och de vanliga personas som ingår är standard i alla MLOps v2-scenarioarkitekturer. Variationer i information om varje komponent beror på scenariot.

Basarkitekturen för MLOps v2 för Machine Learning är det klassiska maskininlärningsscenariot för tabelldata. CV- och NLP-arkitekturerna bygger på och ändrar den här basarkitekturen.

MLOps v2 omfattar följande arkitekturer som beskrivs i den här artikeln:

Klassisk maskininlärningsarkitektur

Diagram som visar den klassiska maskininlärningsarkitekturen.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde för den klassiska maskininlärningsarkitekturen

  1. Dataegendom

    Den här komponenten illustrerar organisationens dataegendom och potentiella datakällor och mål för ett datavetenskapsprojekt. Datatekniker är de främsta ägarna till den här komponenten i MLOps v2-livscykeln. Azure-dataplattformarna i det här diagrammet är inte uttömmande eller normativa. En grön bockmarkering anger de datakällor och mål som representerar rekommenderade metodtips som baseras på kundens användningsfall.

  2. Administration och installation

    Den här komponenten är det första steget i distributionen av MLOps v2-lösningen. Den består av alla uppgifter som rör skapande och hantering av resurser och roller som är associerade med projektet. Infrastrukturteamet kan till exempel:

    1. Skapa lagringsplatser för projektkällans källkod.
    2. Använd Bicep eller Terraform för att skapa Machine Learning-arbetsytor.
    3. Skapa eller ändra datauppsättningar och beräkningsresurser för modellutveckling och distribution.
    4. Definiera projektteamanvändare, deras roller och åtkomstkontroller till andra resurser.
    5. Skapa CI/CD-pipelines.
    6. Skapa övervakningskomponenter för att samla in och skapa aviseringar för modell- och infrastrukturmått.

    Den primära persona som är associerad med den här fasen är infrastrukturteamet, men en organisation kan också ha datatekniker, maskininlärningstekniker eller dataforskare.

  3. Modellutveckling (inre loopfas)

    Den inre loopfasen består av ett iterativt datavetenskapsarbetsflöde som fungerar inom en dedikerad och säker Machine Learning-arbetsyta. Föregående diagram visar ett typiskt arbetsflöde. Processen börjar med datainmatning, går igenom undersökande dataanalys, experimentering, modellutveckling och utvärdering och registrerar sedan en modell för produktionsanvändning. Den här modulära komponenten är agnostisk och anpassningsbar till den process som ditt datavetenskapsteam använder för att utveckla modeller.

    Bland de personer som är associerade med den här fasen finns dataforskare och maskininlärningstekniker.

  4. Maskininlärningsregister

    När datavetenskapsteamet har utvecklat en modell som de kan distribuera till produktion registrerar de modellen i Machine Learning-arbetsyteregistret. CI-pipelines som utlöses, antingen automatiskt av modellregistrering eller av gated human-in-the-loop-godkännande, höjer upp modellen och eventuella andra modellberoenden till modelldistributionsfasen.

    Personer som är associerade med den här fasen är vanligtvis maskininlärningstekniker.

  5. Modelldistribution (yttre loopfas)

    Modelldistributionen, eller den yttre loopfasen, består av mellanlagring och testning av förproduktion, produktionsdistribution och övervakning av modellen, data och infrastruktur. När modellen uppfyller kriterierna för organisationen och användningsfallet höjer CD-pipelines upp modellen och relaterade tillgångar genom produktion, övervakning och potentiell omträning.

    Personer som är associerade med den här fasen är främst maskininlärningstekniker.

  6. Mellanlagring och test

    Mellanlagrings- och testfasen varierar beroende på kundpraxis. Den här fasen omfattar vanligtvis åtgärder som omträning och testning av modellkandidaten på produktionsdata, testdistributioner för slutpunktsprestanda, datakvalitetskontroller, enhetstestning och ansvarsfulla AI-kontroller för modell- och datafördomar. Den här fasen äger rum på en eller flera dedikerade och säkra Machine Learning-arbetsytor.

  7. Produktionsdistribution

    När en modell har klarat mellanlagrings- och testfasen kan maskininlärningstekniker använda in-the-loop-gated godkännande för att befordra den till produktion. Alternativen för modelldistribution omfattar en hanterad batchslutpunkt för batchscenarier eller antingen en hanterad onlineslutpunkt eller Kubernetes-distribution som använder Azure Arc för onlinescenarier i nära realtid. Produktionen sker vanligtvis på en eller flera dedikerade och säkra Machine Learning-arbetsytor.

  8. Övervakning

    Maskininlärningstekniker övervakar komponenter i mellanlagring, testning och produktion för att samla in mått relaterade till ändringar i prestanda för modellen, data och infrastruktur. De kan använda dessa mått för att vidta åtgärder. Modell- och dataövervakning kan omfatta kontroll av modell- och dataavvikelser, modellprestanda för nya data och ansvarsfulla AI-problem. Infrastrukturövervakning kan identifiera långsamma svar på slutpunkter, otillräcklig beräkningskapacitet eller nätverksproblem.

  9. Data- och modellövervakning: händelser och åtgärder

    Baserat på modell- och datakriterier, till exempel måtttrösklar eller scheman, kan automatiserade utlösare och meddelanden implementera lämpliga åtgärder att vidta. En utlösare kan till exempel träna om en modell för att använda nya produktionsdata och sedan loopa tillbaka modellen till mellanlagring och testning för en förproduktionsutvärdering. Eller så kan ett modell- eller dataproblem utlösa en åtgärd som kräver en loopback till modellutvecklingsfasen där dataforskare kan undersöka problemet och eventuellt utveckla en ny modell.

  10. Infrastrukturövervakning: händelser och åtgärder

    Automatiserade utlösare och meddelanden kan implementera lämpliga åtgärder som ska utföras baserat på infrastrukturkriterier, till exempel svarsfördröjning för slutpunkter eller otillräcklig beräkning för distributionen. Automatiska utlösare och meddelanden kan utlösa en loopback till installations- och administrationsfasen där infrastrukturteamet kan undersöka problemet och eventuellt konfigurera om beräknings- och nätverksresurserna.

Machine Learning CV-arkitektur

Diagram som visar arkitekturen för visuellt innehåll.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde för CV-arkitekturen

Machine Learning CV-arkitekturen baseras på den klassiska maskininlärningsarkitekturen, men den har ändringar som är specifika för övervakade CV-scenarier.

  1. Dataegendom

    Den här komponenten visar organisationens dataegendom och potentiella datakällor och mål för ett datavetenskapsprojekt. Datatekniker är de främsta ägarna till den här komponenten i LIVSCYKELN MLOps v2. Azure-dataplattformarna i det här diagrammet är inte uttömmande eller normativa. Bilder för CV-scenarier kan komma från olika datakällor. För effektivitet när du utvecklar och distribuerar CV-modeller med Machine Learning rekommenderar vi Azure Blob Storage och Azure Data Lake Storage.

  2. Administration och installation

    Den här komponenten är det första steget i MLOps v2-distributionen. Den består av alla uppgifter som rör skapande och hantering av resurser och roller som är associerade med projektet. För CV-scenarier är administration och installation av MLOps v2-miljön i stort sett densamma som för klassisk maskininlärning, men innehåller ett extra steg. Infrastrukturteamet använder märkningsfunktionen i Machine Learning eller ett annat verktyg för att skapa bildetiketter och anteckningsprojekt.

  3. Modellutveckling (inre loopfas)

    Den inre loopfasen består av ett iterativt datavetenskapsarbetsflöde som utförs på en dedikerad och säker Machine Learning-arbetsyta. Den främsta skillnaden mellan det här arbetsflödet och det klassiska maskininlärningsscenariot är att bildetiketter och anteckningar är en viktig komponent i den här utvecklingsloopen.

  4. Maskininlärningsregister

    När datavetenskapsteamet har utvecklat en modell som de kan distribuera till produktion registrerar de modellen i Machine Learning-arbetsyteregistret. CI-pipelines som utlöses automatiskt av modellregistrering eller av gated human-in-the-loop-godkännande höjer upp modellen och eventuella andra modellberoenden till modelldistributionsfasen.

  5. Modelldistribution (yttre loopfas)

    Modelldistributionen eller den yttre loopfasen består av mellanlagring och testning av förproduktion, produktionsdistribution och övervakning av modellen, data och infrastruktur. När modellen uppfyller kriterierna för organisationen och användningsfallet höjer CD-pipelines upp modellen och relaterade tillgångar genom produktion, övervakning och potentiell omträning.

  6. Mellanlagring och test

    Mellanlagrings- och testfasen varierar beroende på kundpraxis. Den här fasen omfattar vanligtvis åtgärder som testdistributioner för slutpunktsprestanda, datakvalitetskontroller, enhetstestning och ansvarsfulla AI-kontroller för modell- och datafördomar. För CV-scenarier behöver maskininlärningstekniker inte träna om modellkandidaten för produktionsdata på grund av resurs- och tidsbegränsningar. Data science-teamet kan i stället använda produktionsdata för modellutveckling. Den kandidatmodell som registrerats från utvecklingsloopen utvärderas för produktion. Den här fasen äger rum på en eller flera dedikerade och säkra Machine Learning-arbetsytor.

  7. Produktionsdistribution

    När en modell har klarat mellanlagrings- och testfasen kan maskininlärningstekniker använda in-the-loop-gated godkännande för att befordra den till produktion. Alternativen för modelldistribution omfattar en hanterad batchslutpunkt för batchscenarier eller antingen en hanterad onlineslutpunkt eller Kubernetes-distribution som använder Azure Arc för onlinescenarier i nära realtid. Produktionen sker vanligtvis på en eller flera dedikerade och säkra Machine Learning-arbetsytor.

  8. Övervakning

    Maskininlärningstekniker övervakar komponenter i mellanlagring, testning och produktion för att samla in mått relaterade till ändringar i prestanda för modellen, data och infrastruktur. De kan använda dessa mått för att vidta åtgärder. Modell- och dataövervakning kan omfatta kontroll av modellprestanda på nya avbildningar. Infrastrukturövervakning kan identifiera långsamma svar på slutpunkter, otillräcklig beräkningskapacitet eller nätverksproblem.

  9. Data- och modellövervakning: händelser och åtgärder

    Data- och modellövervaknings- och händelse- och åtgärdsfaserna i MLOps för bearbetning av naturligt språk är de viktigaste skillnaderna från klassisk maskininlärning. Automatiserad omträning görs vanligtvis inte i CV-scenarier när modellprestandaförsämring på nya bilder identifieras. I det här fallet är en process som är mänsklig i loopen nödvändig för att granska och kommentera nya textdata för modellen som presterar dåligt. Nästa åtgärd går ofta tillbaka till modellutvecklingsloopen för att uppdatera modellen med de nya bilderna.

  10. Infrastrukturövervakning: händelser och åtgärder

    Automatiserade utlösare och meddelanden kan implementera lämpliga åtgärder som ska utföras baserat på infrastrukturkriterier, till exempel svarsfördröjning för slutpunkter eller otillräcklig beräkning för distributionen. Automatiska utlösare och meddelanden kan utlösa en loopback till installations- och administrationsfasen där infrastrukturteamet kan undersöka problemet och eventuellt konfigurera om miljö-, beräknings- och nätverksresurser.

Bearbetningsarkitektur för naturligt språk i Machine Learning

Diagram över arkitekturen för bearbetning av naturligt språk.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde för arkitekturen för bearbetning av naturligt språk

Maskininlärningsarkitekturen för bearbetning av naturligt språk baseras på den klassiska maskininlärningsarkitekturen, men den har vissa ändringar som är specifika för NLP-scenarier.

  1. Dataegendom

    Den här komponenten visar organisationens dataegendom och potentiella datakällor och mål för ett datavetenskapsprojekt. Datatekniker är de främsta ägarna till den här komponenten i LIVSCYKELN MLOps v2. Azure-dataplattformarna i det här diagrammet är inte uttömmande eller normativa. En grön bockmarkering anger källor och mål som representerar rekommenderade metodtips som baseras på kundens användningsfall.

  2. Administration och installation

    Den här komponenten är det första steget i MLOps v2-distributionen. Den består av alla uppgifter som rör skapande och hantering av resurser och roller som är associerade med projektet. För scenarier med bearbetning av naturligt språk är administration och installation av MLOps v2-miljön i stort sett densamma som för klassisk maskininlärning, men med ett extra steg: skapa bildetiketter och anteckningsprojekt med hjälp av märkningsfunktionen i Machine Learning eller något annat verktyg.

  3. Modellutveckling (inre loopfas)

    Den inre loopfasen består av ett iterativt datavetenskapsarbetsflöde som utförs på en dedikerad och säker Machine Learning-arbetsyta. Den typiska NLP-modellutvecklingsloopen skiljer sig från det klassiska maskininlärningsscenariot eftersom de typiska utvecklingsstegen för det här scenariot inkluderar anteckningar för meningar och tokenisering, normalisering och inbäddningar för textdata.

  4. Maskininlärningsregister

    När datavetenskapsteamet har utvecklat en modell som de kan distribuera till produktion registrerar de modellen i Machine Learning-arbetsyteregistret. CI-pipelines som utlöses automatiskt av modellregistrering eller av gated human-in-the-loop-godkännande höjer upp modellen och eventuella andra modellberoenden till modelldistributionsfasen.

  5. Modelldistribution (yttre loopfas)

    Modelldistributionen eller den yttre loopfasen består av mellanlagring och testning av förproduktion, produktionsdistribution och övervakning av modellen, data och infrastruktur. När modellen uppfyller kriterierna för organisationen och användningsfallet höjer CD-pipelines upp modellen och relaterade tillgångar genom produktion, övervakning och potentiell omträning.

  6. Mellanlagring och test

    Mellanlagrings- och testfasen varierar beroende på kundpraxis. Den här fasen omfattar vanligtvis åtgärder som omträning och testning av modellkandidaten på produktionsdata, testdistributioner för slutpunktsprestanda, datakvalitetskontroller, enhetstestning och ansvarsfulla AI-kontroller för modell- och datafördomar. Den här fasen äger rum på en eller flera dedikerade och säkra Machine Learning-arbetsytor.

  7. Produktionsdistribution

    När en modell har klarat mellanlagrings- och testfasen kan maskininlärningstekniker använda in-the-loop-gated godkännande för att befordra den till produktion. Alternativen för modelldistribution omfattar en hanterad batchslutpunkt för batchscenarier eller antingen en hanterad onlineslutpunkt eller Kubernetes-distribution som använder Azure Arc för onlinescenarier i nära realtid. Produktionen sker vanligtvis på en eller flera dedikerade och säkra Machine Learning-arbetsytor.

  8. Övervakning

    Maskininlärningstekniker övervakar komponenter i mellanlagring, testning och produktion för att samla in mått relaterade till ändringar i prestanda för modellen, data och infrastruktur. De kan använda dessa mått för att vidta åtgärder. Modell- och dataövervakning kan omfatta kontroll av modell- och dataavvikelser, modellprestanda för nya textdata och ansvarsfulla AI-problem. Infrastrukturövervakning kan identifiera problem, till exempel långsamma slutpunktssvar, otillräcklig beräkningskapacitet och nätverksproblem.

  9. Data- och modellövervakning: händelser och åtgärder

    Precis som med CV-arkitekturen är data- och modellövervaknings- och händelse- och åtgärdsfaserna i MLOps för bearbetning av naturligt språk de viktigaste skillnaderna från klassisk maskininlärning. Automatiserad omträning utförs vanligtvis inte i scenarier med bearbetning av naturligt språk när modellprestandaförsämring på ny text identifieras. I det här fallet är en process som är mänsklig i loopen nödvändig för att granska och kommentera nya textdata för modellen som presterar dåligt. Nästa åtgärd är ofta att gå tillbaka till modellutvecklingsloopen för att uppdatera modellen med nya textdata.

  10. Infrastrukturövervakning: händelser och åtgärder

    Automatiserade utlösare och meddelanden kan implementera lämpliga åtgärder som ska utföras baserat på infrastrukturkriterier, till exempel svarsfördröjning för slutpunkter eller otillräcklig beräkning för distributionen. Automatiska utlösare och meddelanden kan utlösa en loopback till installations- och administrationsfasen där infrastrukturteamet kan undersöka problemet och eventuellt konfigurera om beräknings- och nätverksresurser.

Komponenter

  • Machine Learning är en molntjänst som du kan använda för att träna, poängsätta, distribuera och hantera maskininlärningsmodeller i stor skala.

  • Azure Pipelines är ett bygg- och testsystem som baseras på Azure DevOps och används för bygg- och versionspipelines. Azure Pipelines delar upp dessa pipelines i logiska steg som kallas uppgifter.

  • GitHub är en kodvärdplattform för arbetsflöden för versionskontroll, samarbete och CI/CD.

  • Azure Arc är en plattform som använder Azure Resource Manager för att hantera Azure-resurser och lokala resurser. Resurserna kan innehålla virtuella datorer, Kubernetes-kluster och databaser.

  • Kubernetes är ett system med öppen källkod som du kan använda för att automatisera distribution, skalning och hantering av containerbaserade program.

  • Azure Data Lake Storage är ett Hadoop-kompatibelt filsystem. Den har ett integrerat hierarkiskt namnområde och bloblagringens enorma skala och ekonomi.

  • Azure Synapse Analytics är en obegränsad analystjänst som sammanför dataintegrering, lagring av företagsdata och stordataanalys.

  • Azure Event Hubs är en tjänst som matar in dataströmmar som klientprogram genererar. Den matar sedan in och lagrar strömmande data, vilket bevarar sekvensen med mottagna händelser. Kunder kan ansluta till hubbslutpunkterna för att hämta meddelanden för bearbetning. Den här arkitekturen använder Data Lake Storage-integrering.

Övriga beaktanden

Det föregående arkitekturmönstret MLOps v2 har flera viktiga komponenter, inklusive rollbaserad åtkomstkontroll (RBAC) som överensstämmer med affärsintressenter, effektiv pakethantering och robusta övervakningsmekanismer. Dessa komponenter bidrar tillsammans till en lyckad implementering och hantering av maskininlärningsarbetsflöden.

Persona-baserad RBAC

Det är viktigt att du hanterar åtkomsten till maskininlärningsdata och resurser. RBAC tillhandahåller ett robust ramverk som hjälper dig att hantera vem som kan utföra specifika åtgärder och få åtkomst till specifika områden i din lösning. Utforma din strategi för identitetssegmentering så att den överensstämmer med livscykeln för maskininlärningsmodeller i Machine Learning och de personer som ingår i processen. Varje persona har en specifik uppsättning ansvarsområden som återspeglas i deras RBAC-roller och gruppmedlemskap.

Exempelpersonas

För att stödja lämplig segmentering i en maskininlärningsarbetsbelastning bör du överväga följande vanliga personer som informerar den identitetsbaserade RBAC-gruppdesignen .

Dataforskare och maskininlärningstekniker

Dataforskare och maskininlärningstekniker utför olika maskininlärnings- och datavetenskapsaktiviteter under ett projekts livscykel för programvaruutveckling. Deras uppgifter omfattar undersökande dataanalys och förbearbetning av data. Dataforskare och maskininlärningstekniker ansvarar för utbildning, utvärdering och distribution av modeller. Dessa rollers ansvarsområden omfattar även break-fix-aktiviteter för maskininlärningsmodeller, paket och data. Dessa uppgifter ligger utanför omfånget för plattformens tekniska supportteam.

Typ: Person
Projektspecifikt: Ja

Dataanalytiker

Dataanalytiker tillhandahåller nödvändiga indata för datavetenskapsaktiviteter, till exempel att köra SQL-frågor för Business Intelligence. Den här rollens ansvarsområden omfattar att arbeta med data, utföra dataanalys och stödja modellutveckling och modelldistribution.

Typ: Person
Projektspecifikt: Ja

Modelltestare

Modelltestare utför tester i test- och mellanlagringsmiljöer. Den här rollen ger funktionell uppdelning från CI/CD-processerna.

Typ: Person
Projektspecifikt: Ja

Affärsintressenter

Affärsintressenter är associerade med projektet, till exempel en marknadschef.

Typ: Person
Projektspecifikt: Ja

Projektledare eller datavetenskapsledare

Data science-ledningen är en projektadministrationsroll för Machine Learning-arbetsytan. Den här rollen utför även break-fix-aktiviteter för maskininlärningsmodeller och -paket.

Typ: Person
Projektspecifikt: Ja

Projekt- eller produktägare (företagsägare)

Företagsintressenter ansvarar för Machine Learning-arbetsytan enligt dataägarskapet.

Typ: Person
Projektspecifikt: Ja

Teknisk plattformssupport

Plattforms teknisk support är den tekniska supportpersonal som ansvarar för break-fix-aktiviteter över hela plattformen. Den här rollen omfattar infrastruktur eller tjänst, men inte maskininlärningsmodeller, paket eller data. Dessa komponenter förblir under rollen datavetare eller maskininlärningstekniker och är projektledningens ansvar.

Typ: Person
Projektspecifikt: Nej

Modellslutanvändare

Modellslutanvändare är slutanvändare av maskininlärningsmodellen.

Typ: Person eller process
Projektspecifikt: Ja

CI/CD-processer

CI/CD-processer släpper eller återställer ändringar i plattformsmiljöer.

Typ: Process
Projektspecifikt: Nej

Machine Learning-arbetsyta

Machine Learning-arbetsytor använder hanterade identiteter för att interagera med andra delar av Azure. Den här persona representerar de olika tjänster som utgör en Machine Learning-implementering. Dessa tjänster interagerar med andra delar av plattformen, till exempel den utvecklingsarbetsyta som ansluter till datalagret för utveckling.

Typ: Process
Projektspecifikt: Nej

Övervakningsprocesser

Övervakningsprocesser är beräkningsprocesser som övervakar och aviserar baserat på plattformsaktiviteter.

Typ: Process
Projektspecifikt: Nej

Processer för datastyrning

Datastyrningsprocesser söker igenom maskininlärningsprojektet och datalager för datastyrning.

Typ: Process
Projektspecifikt: Nej

Microsoft Entra-gruppmedlemskap

När du implementerar RBAC tillhandahåller Microsoft Entra-grupper ett flexibelt och skalbart sätt att hantera åtkomstbehörigheter för olika personer. Du kan använda Microsoft Entra-grupper för att hantera användare som behöver samma åtkomst och behörigheter till resurser, till exempel potentiellt begränsade appar och tjänster. I stället för att lägga till särskilda behörigheter för enskilda användare skapar du en grupp som tillämpar de särskilda behörigheterna för varje medlem i gruppen.

I det här arkitekturmönstret kan du koppla ihop dessa grupper med en machine learning-arbetsyta, till exempel ett projekt, ett team eller en avdelning. Du kan associera användare med specifika grupper för att definiera detaljerade åtkomstprinciper. Principerna beviljar eller begränsar behörigheter till olika Machine Learning-arbetsytor baserat på jobbfunktioner, projektkrav eller andra kriterier. Du kan till exempel ha en grupp som ger alla dataforskare åtkomst till en utvecklingsarbetsyta för ett specifikt användningsfall.

Identitets-RBAC

Fundera på hur du kan använda följande inbyggda Azure RBAC-roller för att tillämpa RBAC på produktions- och förproduktionsmiljöer. För arkitekturen i den här artikeln omfattar produktionsmiljöerna mellanlagring, testning och produktionsmiljöer. Förproduktionsmiljöerna omfattar utvecklingsmiljöer. Följande RBAC-roller baseras på de personas som beskrevs tidigare i den här artikeln.

Standardroller

Komponentspecifika roller

Dessa Azure RBAC-rollförkortningar motsvarar följande tabeller.

Produktionsmiljö
Persona Machine Learning-arbetsyta Azure Key Vault Container Registry Azure-lagringskonto Azure DevOps Azure Artifacts Log Analytics-arbetsyta Azure Monitor
Dataexpert R LAR MR
Dataanalytiker
Modelltestare
Affärsintressenter MR
Projektledare (datavetenskapsledare) R R, KVR R LAR MR
Projekt-/produktägare MR
Teknisk plattformssupport O O, KVA DOPCA O O O
Modellslutanvändare
CI/CD-processer O O, KVA AcrPush DOPCA O O O
Machine Learning-arbetsyta R C C
Övervakningsprocesser R LAR MR
Processer för datastyrning R R R R R
Förproduktionsmiljö
Persona Machine Learning-arbetsyta Key Vault Container Registry Lagringskonto Azure DevOps Azure Artifacts Log Analytics-arbetsyta Azure Monitor
Dataexpert ANNONSER R, KVA C C C C GUMMILACKA MC
Dataanalytiker R C LAR MC
Modelltestare R R, KVR R R R R LAR MR
Affärsintressenter R R R R R
Projektledare (datavetenskapsledare) C C, KVA C C C C GUMMILACKA MC
Projekt-/produktägare R R MR
Teknisk plattformssupport O O, KVA O O DOPCA O O O
Modellslutanvändare
CI/CD-processer O O, KVA AcrPush O DOPCA O O O
Machine Learning-arbetsyta R, KVR C C
Övervakningsprocesser R R R R R R GUMMILACKA
Processer för datastyrning R R R

Kommentar

Varje persona behåller åtkomsten under projektets varaktighet utom teknisk plattformssupport, som har tillfällig eller just-in-time-åtkomst till Microsoft Entra Privileged Identity Management (PIM).

RBAC spelar en viktig roll för att skydda och effektivisera MLOps-arbetsflöden. RBAC begränsar åtkomsten baserat på tilldelade roller och förhindrar obehöriga användare från att komma åt känsliga data, vilket minskar säkerhetsriskerna. Känsliga data omfattar träningsdata eller modeller och kritisk infrastruktur, till exempel produktionspipelines. Du kan använda RBAC för att säkerställa efterlevnad av datasekretessregler. RBAC ger också en tydlig post med åtkomst och behörigheter, vilket förenklar granskning, gör det enkelt att identifiera säkerhetsluckor och spåra användaraktivitet.

Pakethantering

Beroenden för olika paket, bibliotek och binärfiler är vanliga under hela MLOps-livscykeln. Dessa beroenden, ofta samhällsutvecklade och snabbt föränderliga, kräver ämnesexpertkunskaper för korrekt användning och förståelse. Du måste se till att rätt personer har säker åtkomst till olika tillgångar, till exempel paket och bibliotek, men du måste också förhindra sårbarheter. Dataexperter stöter på det här problemet när de monterar specialiserade byggstenar för maskininlärningslösningar. Traditionella metoder för programvaruhantering är kostsamma och ineffektiva. Andra metoder ger mer värde.

Om du vill hantera dessa beroenden kan du använda en säker pakethanteringsprocess med självbetjäning baserat på karantänmönstret. Du kan utforma den här processen så att dataforskare kan självbetjäna från en kuraterad lista över paket och se till att paketen är säkra och kompatibla med organisationens standarder.

Den här metoden omfattar säker lista över tre lagringsplatser för maskininlärningspaket av branschstandard: Microsofts artefaktregister, Python Package Index (PyPI) och Conda. Säker lista möjliggör självbetjäning från enskilda Machine Learning-arbetsytor. Använd sedan en automatiserad testprocess under distributionen för att skanna de resulterande lösningscontainrarna. Fel avslutar distributionsprocessen elegant och tar bort containern. Följande diagram och processflöde visar den här processen:

Diagram som visar den säkra metoden för Machine Learning-paket.

Processflöde

  1. Dataforskare som arbetar på en Machine Learning-arbetsyta som har en nätverkskonfiguration kan självbetjäna maskininlärningspaket på begäran från lagringsplatserna för maskininlärningspaketet. En undantagsprocess krävs för allt annat med hjälp av det privata lagringsmönstret , som är seedat och underhålls med hjälp av en centraliserad funktion.

  2. Machine Learning levererar maskininlärningslösningar som Docker-containrar. När de här lösningarna har utvecklats laddas de upp till Container Registry. Microsoft Defender för containrar genererar sårbarhetsbedömningar för containeravbildningen.

  3. Lösningsdistribution sker via en CI/CD-process. Microsoft Defender för DevOps används i hela stacken för att tillhandahålla hantering av säkerhetsstatus och skydd mot hot.

  4. Lösningscontainern distribueras endast om den passerar var och en av säkerhetsprocesserna. Om lösningscontainern misslyckas med en säkerhetsprocess misslyckas distributionen med felmeddelanden och fullständiga spårningsloggar. Lösningscontainern tas bort.

Det tidigare processflödet ger en säker pakethanteringsprocess med självbetjäning för dataforskare och säkerställer att paketen är säkra och kompatibla med organisationens standarder. För att balansera innovation och säkerhet kan du ge datavetare självbetjäningsåtkomst till vanliga maskininlärningspaket, bibliotek och binärfiler i förproduktionsmiljöer. Kräv undantag för mindre vanliga paket. Den här strategin säkerställer att dataexperter kan förbli produktiva under utvecklingen, vilket förhindrar en stor flaskhals under leveransen.

För att effektivisera dina lanseringsprocesser, containerisera miljöer för användning i produktionsmiljöer. Containerbaserade miljöer minskar slitet och säkerställer fortsatt säkerhet genom sårbarhetsgenomsökning. Det här processflödet ger en repeterbar metod som du kan använda i olika användningsfall fram till leveranstiden. Det minskar den totala kostnaden för att skapa och distribuera maskininlärningslösningar i företaget.

Övervakning

I MLOps är övervakning avgörande för att upprätthålla hälsa och prestanda för maskininlärningssystem och se till att modellerna förblir effektiva och anpassade till affärsmålen. Övervakning stöder styrnings-, säkerhets- och kostnadskontroller under den inre loopfasen. Och det ger observerbarhet i prestanda, modellförsämring och användning när du distribuerar lösningar under den yttre loopfasen. Övervakningsaktiviteter är relevanta för personer som Dataforskare, affärsintressenter, projektledare, projektägare, teknisk plattformssupport, CI/CD-processer och övervakningsprocesser.

Välj din övervaknings- och verifieringsplattform beroende på konfigurationen av Machine Learning-arbetsytan, till exempel ett projekt, ett team eller en avdelning.

Modellprestanda

Övervaka modellprestanda för att identifiera modellproblem och prestandaförsämring tidigt. Spåra prestanda för att säkerställa att modellerna förblir korrekta, tillförlitliga och i linje med affärsmålen.

Dataavvikelse

Dataavvikelse spårar ändringar i fördelningen av en modells indata genom att jämföra dem med modellens träningsdata eller tidigare produktionsdata. Dessa ändringar är ett resultat av förändringar i marknadsdynamiken, ändringar i funktionstransformeringen eller överordnad dataändringar. Sådana ändringar kan försämra modellens prestanda, så det är viktigt att övervaka driften för att säkerställa en åtgärd i tid. För att kunna göra en jämförelse kräver refaktorisering av dataavvikelser de senaste produktionsdatauppsättningarna och utdata.

Miljö: Produktion
Azure-underlättande: Machine Learning – modellövervakning

Förutsägelseavvikelse

Förutsägelseavvikelse spårar ändringar i fördelningen av en modells förutsägelseutdata genom att jämföra den med validering, testetiketter eller nya produktionsdata. För att kunna göra en jämförelse kräver refaktorisering av dataavvikelser de senaste produktionsdatauppsättningarna och utdata.

Miljö: Produktion
Azure-underlättande: Machine Learning – modellövervakning

Resurs

Använd flera modell som betjänar slutpunktsmått för att ange kvalitet och prestanda, till exempel PROCESSOR- eller minnesanvändning. Den här metoden hjälper dig att lära dig från produktion för att driva framtida investeringar eller förändringar.

Miljö: Alla
Azure-underlättande: Övervaka – Mått för onlineslutpunkter

Användningsstatistik

Övervaka användningen av slutpunkter för att säkerställa att du uppfyller organisationsspecifika eller arbetsbelastningsspecifika nyckelprestandaindikatorer, spårar användningsmönster och diagnostiserar och åtgärdar problem som användarna upplever.

Klientbegäranden

Spåra antalet klientbegäranden till modellslutpunkten för att förstå slutpunkternas aktiva användningsprofil, vilket kan påverka skalnings- eller kostnadsoptimeringsarbetet.

Miljö: Produktion
Azure-underlättande: Övervaka – Mått för onlineslutpunkter, till exempel RequestsPerMinute. Anteckningar:

  • Du kan justera acceptabla tröskelvärden efter storleksändring av t-shirt eller avvikelser som är skräddarsydda för din arbetsbelastnings behov.
  • Dra tillbaka modeller som inte längre används från produktion.
Fördröjningar för begränsning

Begränsningsfördröjningar är långsammare i begäran och svar för dataöverföringar. Begränsning sker på Resource Manager-nivå och servicenivå. Spåra mått på båda nivåerna.

Miljö: Produktion
Azure-underlättande:

  • Övervaka – Resource Manager, summan av RequestThrottlingDelayMs, ResponseThrottlingDelayMs.
  • Machine Learning – Om du vill kontrollera information om dina slutpunkters begäranden kan du aktivera onlineslutpunktstrafikloggar. Du kan använda en Log Analytics-arbetsyta för att bearbeta loggar.

Anmärkningar: Justera godtagbara tröskelvärden till arbetsbelastningens servicenivåmål (SLO) eller serviceavtal (SLA) och lösningens icke-funktionella krav (NFR).

Fel som genererats

Spåra fel med svarskoden för att mäta tjänstens tillförlitlighet och säkerställa tidig identifiering av tjänstproblem. En plötslig ökning av 500 serverfelsvar kan till exempel tyda på ett kritiskt problem som behöver omedelbar uppmärksamhet.

Miljö: Produktion
Azure-underlättande: Machine Learning – Aktivera trafikloggar för slutpunkter online för att kontrollera information om din begäran. Du kan till exempel kontrollera antalet XRequestId med hjälp av ModelStatusCode eller ModelStatusReason. Du kan använda en Log Analytics-arbetsyta för att bearbeta loggar.
Anteckningar:

  • Alla HTTP-svarskoder i intervallet 400 och 500 klassificeras som ett fel.

Kostnadsoptimering

Kostnadshantering och optimering i en molnmiljö är avgörande eftersom de hjälper arbetsbelastningar att kontrollera utgifter, allokera resurser effektivt och maximera värdet från sina molntjänster.

Beräkning av arbetsyta

När de månatliga driftskostnaderna når eller överskrider ett fördefinierat belopp genererar du aviseringar för att meddela relevanta intressenter, till exempel projektledare eller projektägare, baserat på arbetsytans konfigurationsgränser. Du kan bestämma konfigurationen av arbetsytan baserat på projekt-, team- eller avdelningsrelaterade gränser.

Miljö: Alla
Azure-underlättande: Microsoft Cost Management – budgetaviseringar
Anteckningar:

  • Ange budgettrösklar baserat på de ursprungliga NFR:erna och kostnadsuppskattningarna.
  • Använd flera tröskelvärdesnivåer. Flera tröskelvärdesnivåer ser till att intressenterna får lämplig varning innan budgeten överskrids. Dessa intressenter kan vara företagsleas, projektägare eller projektledarorganisationer beroende på organisation eller arbetsbelastning.
  • Konsekventa budgetaviseringar kan också vara en utlösare för refaktorisering för att stödja större efterfrågan.
Inaktuell arbetsyta

Om en Machine Learning-arbetsyta inte visar några tecken på aktiv användning baserat på den associerade beräkningsanvändningen för det avsedda användningsfallet kan en projektägare inaktivera arbetsytan om den inte längre behövs för ett visst projekt.

Miljö: Förproduktion
Azure-underlättande:

Anteckningar:

  • Aktiva kärnor ska vara lika med noll med aggregering av antal.
  • Justera datumtrösklar till projektschemat.

Säkerhet

Övervaka för att identifiera avvikelser från lämpliga säkerhetskontroller och baslinjer för att säkerställa att Machine Learning-arbetsytor är kompatibla med organisationens säkerhetsprinciper. Du kan använda en kombination av fördefinierade och anpassade principer.

Miljö: Alla
Azure-underlättande: Azure Policy for Machine Learning

Slutpunktssäkerhet

För att få insyn i affärskritiska API:er implementerar du riktad säkerhetsövervakning av alla Machine Learning-slutpunkter. Du kan undersöka och förbättra din API-säkerhetsstatus, prioritera sårbarhetskorrigeringar och snabbt identifiera aktiva realtidshot.

Miljö: Produktion
Azure-underlättande: Microsoft Defender för API:er erbjuder omfattande livscykelskydd, identifiering och svarstäckning för API:er. Anmärkningar: Defender för API:er ger säkerhet för API:er som publiceras i Azure API Management. Du kan registrera Defender för API:er i Microsoft Defender för molnet-portalen eller i API Management-instansen i Azure Portal. Du måste integrera Machine Learning-slutpunkter online med API Management.

Distributionsövervakning

Distributionsövervakning säkerställer att alla slutpunkter som du skapar följer dina arbetsbelastnings- eller organisationsprinciper och är fria från sårbarheter. Den här processen kräver att du tillämpar efterlevnadsprinciper på dina Azure-resurser före och efter distributionen, ger fortsatt säkerhet genom sårbarhetsgenomsökning och ser till att tjänsten uppfyller SLO:er under drift.

Standarder och styrning

Övervaka för att identifiera avvikelser från lämpliga standarder och se till att din arbetsbelastning följer skyddsräcken.

Miljö: Alla
Azure-underlättande:

  • Hanterad principtilldelning och livscykel via Azure Pipelines för att behandla principen som kod.
  • PSRule för Azure tillhandahåller ett testramverk för Azure-infrastruktur som kod.
  • Du kan använda Enterprise Azure-principen som kod i CI/CD-baserade systemdistributionsprinciper, principuppsättningar, tilldelningar, principundantag och rolltilldelningar.

Anmärkningar: Mer information finns i Azure-vägledning för regelefterlevnad i Machine Learning.

Säkerhetsgenomsökning

Implementera automatiserade säkerhetsgenomsökningar som en del av de automatiserade integrerings- och distributionsprocesserna.

Miljö: Alla
Azure-underlättande: Defender för DevOps
Anmärkningar: Du kan använda appar på Azure Marketplace för att utöka den här processen för säkerhetstestmoduler som inte kommer från Microsoft.

Löpande tjänst

Övervaka den pågående tjänsten för ett API för prestandaoptimering, säkerhet och resursanvändning. Säkerställ felidentifiering i tid, effektiv felsökning och efterlevnad av standarder.

Miljö: Produktion
Azure-underlättande:

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg