Dela via

Maskininlärningsåtgärder (MLOps) v2

  • Artikel

I den här artikeln beskrivs tre Azure-arkitekturer för maskininlärningsåtgärder. De har alla kontinuerlig integrering från slutpunkt till slutpunkt (CI), kontinuerlig leverans (CD) och omträningspipelines. Arkitekturerna gäller för dessa AI-program:

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

Arkitekturerna är produkten av MLOps v2-projektet. De innehåller metodtips som lösningsarkitekterna upptäckte i processen att skapa flera maskininlärningslösningar. Resultatet är distributionsbara, repeterbara och underhållsbara mönster enligt beskrivningen här.

Alla arkitekturer använder Azure Machine Learning-tjänsten.

En implementering med exempeldistributionsmallar för MLOps v2 finns i Lösningsacceleratorn Azure MLOps (v2) på GitHub.

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 är:
    • Binär klassificering och klassificering med flera etiketter
    • Linjär, polynom, ås, lasso, kvantil och bayesisk regression
    • ARIMA, autoregressiv (AR), SARIMA, VAR, SES, LSTM
  • CV: MLOps-ramverket som presenteras här fokuserar främst på cv-användningsfallen för segmentering och bildklassificering.
  • NLP: Det här MLOps-ramverket kan implementera något av dessa användningsfall och andra som inte finns med i listan:
    • Igenkänning av namngiven entitet
    • Textklassificering
    • Textgenerering
    • Attitydanalys
    • Översättning
    • Frågor och svar
    • Summering
    • Meningsidentifiering
    • Språkidentifiering
    • Del av tal-märkning

Simuleringar, djup förstärkningsinlärning och andra former av AI omfattas inte av den här artikeln.

Arkitektur

Arkitekturmönstret MLOps v2 består av fyra huvudsakliga modulära element som representerar dessa faser i MLOps-livscykeln:

  • Dataegendom
  • Administration och installation
  • Modellutveckling (inre loop)
  • Modelldistribution (yttre loop)

Dessa element, relationerna mellan dem och de personas som vanligtvis är associerade med dem är vanliga för alla MLOps v2-scenarioarkitekturer. Det kan finnas variationer i informationen för var och en, beroende 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.

Aktuella arkitekturer

De arkitekturer som för närvarande omfattas av MLOps v2 och som beskrivs i den här artikeln är:

Klassisk maskininlärningsarkitektur

Diagram över den klassiska maskininlärningsarkitekturen.

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

Arbetsflöde för den klassiska maskininlärningsarkitekturen

  1. Dataegendom

    Det här elementet illustrerar organisationens dataegendom och potentiella datakällor och mål för ett datavetenskapsprojekt. Datatekniker är de främsta ägarna till det här elementet i LIVSCYKELN MLOps v2. Azure-dataplattformarna i det här diagrammet är varken uttömmande eller normativa. De datakällor och mål som representerar rekommenderade metodtips baserat på kundens användningsfall anges med en grön bockmarkering.

  2. Administration och installation

    Det här elementet är det första steget i mlOps v2-acceleratorns distribution. Den består av alla uppgifter som rör skapande och hantering av resurser och roller som är associerade med projektet. Dessa kan omfatta följande uppgifter, och kanske andra:

    1. Skapa lagringsplatser för projektkällans källkod
    2. Skapa Machine Learning-arbetsytor med hjälp av Bicep eller Terraform
    3. Skapande eller ändring av datauppsättningar och beräkningsresurser som används för modellutveckling och distribution
    4. Definition av projektteamanvändare, deras roller och åtkomstkontroller till andra resurser
    5. Skapa CI/CD-pipelines
    6. Skapa övervakare för insamling och meddelande av modell- och infrastrukturmått

    Den primära persona som är associerad med den här fasen är infrastrukturteamet, men det kan också finnas datatekniker, maskininlärningstekniker och dataforskare.

  3. Modellutveckling (inre loop)

    Det inre loopelementet består av ditt iterativa datavetenskapsarbetsflöde som fungerar inom en dedikerad och säker Machine Learning-arbetsyta. Ett typiskt arbetsflöde illustreras i diagrammet. Den fortsätter från datainmatning, undersökande dataanalys, experimentering, modellutveckling och utvärdering till registrering av en kandidatmodell för produktion. Det här modulära elementet som implementeras i MLOps v2-acceleratorn ä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 är en kandidat för distribution till produktion kan modellen registreras 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 loop)

    Modelldistributionen eller den yttre loopfasen består av mellanlagring och testning före produktion, produktionsdistribution och övervakning av modell, data och infrastruktur. CD-pipelines hanterar befordran av modellen och relaterade tillgångar via produktion, övervakning och potentiell omträning, eftersom kriterier som är lämpliga för din organisation och användningsfall uppfylls.

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

  6. Mellanlagring och test

    Mellanlagrings- och testfasen kan variera med kundpraxis, men omfattar vanligtvis åtgärder som omträning och testning av modellkandidaten för 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, säkra Machine Learning-arbetsytor.

  7. Produktionsdistribution

    När en modell har klarat mellanlagrings- och testfasen kan den befordras till produktion med hjälp av ett gated-godkännande från människa i loopen. Alternativen för modelldistribution omfattar en hanterad batchslutpunkt för batchscenarier eller, för scenarier i nära realtid, antingen en hanterad onlineslutpunkt eller Kubernetes-distribution med hjälp av Azure Arc. Produktionen sker vanligtvis på en eller flera dedikerade, säkra Machine Learning-arbetsytor.

  8. Övervakning

    Övervakning i mellanlagring, testning och produktion gör det möjligt för dig att samla in mått för och agera på ändringar i prestanda för modellen, data och infrastruktur. Modell- och dataövervakning kan omfatta kontroll av modell- och dataavvikelser, modellprestanda för nya data och ansvarsfulla AI-problem. Infrastrukturövervakning kan övervaka långsamma slutpunktssvar, otillräcklig beräkningskapacitet eller nätverksproblem.

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

    Baserat på kriterier för modell- och datafrågor, till exempel måtttrösklar eller scheman, kan automatiserade utlösare och meddelanden implementera lämpliga åtgärder att vidta. Detta kan schemaläggas regelbundet automatisk omträning av modellen på nyare produktionsdata och en loopback till mellanlagring och test för förproduktionsutvärdering. Eller så kan det bero på utlösare på modell- eller dataproblem som kräver en loopback till modellutvecklingsfasen där dataforskare kan undersöka och potentiellt utveckla en ny modell.

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

    Baserat på kriterier för infrastrukturfrågor, till exempel svarsfördröjning för slutpunkter eller otillräcklig beräkning för distributionen, kan automatiserade utlösare och meddelanden implementera lämpliga åtgärder att vidta. De utlöser en loopback till installations- och administrationsfasen där infrastrukturteamet kan undersöka och eventuellt konfigurera om beräknings- och nätverksresurserna.

Machine Learning CV-arkitektur

Diagram över 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

    Det här elementet illustrerar organisationens dataegendom och potentiella datakällor och mål för ett datavetenskapsprojekt. Datatekniker är de främsta ägarna till det här elementet i LIVSCYKELN MLOps v2. Azure-dataplattformarna i det här diagrammet är varken uttömmande eller normativa. Bilder för CV-scenarier kan komma från många olika datakällor. För effektivitet vid utveckling och distribution av CV-modeller med Machine Learning rekommenderar vi att Azure-datakällor för avbildningar är Azure Blob Storage och Azure Data Lake Storage.

  2. Administration och installation

    Det här elementet är det första steget i mlOps v2-acceleratorns distribution. 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 med ytterligare ett steg: skapa bildetiketter och anteckningsprojekt med hjälp av märkningsfunktionen i Machine Learning eller ett annat verktyg.

  3. Modellutveckling (inre loop)

    Det inre loopelementet består av ditt iterativa 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 del av den här utvecklingsloopen.

  4. Maskininlärningsregister

    När datavetenskapsteamet har utvecklat en modell som är en kandidat för distribution till produktion kan modellen registreras 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 loop)

    Modelldistributionen eller den yttre loopfasen består av mellanlagring och testning före produktion, produktionsdistribution och övervakning av modell, data och infrastruktur. CD-pipelines hanterar befordran av modellen och relaterade tillgångar via produktion, övervakning och potentiell omträning efter kriterier som är lämpliga för din organisation och användningsfallet uppfylls.

  6. Mellanlagring och test

    Mellanlagrings- och testfasen kan variera med kundpraxis, men 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 kan omträning av modellkandidaten för produktionsdata utelämnas på grund av resurs- och tidsbegränsningar. I stället kan datavetenskapsteamet använda produktionsdata för modellutveckling, och den kandidatmodell som registreras från utvecklingsloopen är den modell som utvärderas för produktion. Den här fasen äger rum på en eller flera dedikerade, säkra Machine Learning-arbetsytor.

  7. Produktionsdistribution

    När en modell har klarat mellanlagrings- och testfasen kan den befordras till produktion via gated-godkännanden för människa i loopen. Alternativen för modelldistribution omfattar en hanterad batchslutpunkt för batchscenarier eller, för scenarier i nära realtid, antingen en hanterad onlineslutpunkt eller Kubernetes-distribution med hjälp av Azure Arc. Produktionen sker vanligtvis på en eller flera dedikerade, säkra Machine Learning-arbetsytor.

  8. Övervakning

    Övervakning i mellanlagring, testning och produktion gör det möjligt för dig att samla in mått för och agera på ändringar i prestanda för modellen, data och infrastruktur. Modell- och dataövervakning kan omfatta kontroll av modellprestanda på nya avbildningar. Infrastrukturövervakning kan övervaka långsamma slutpunktssvar, 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 NLP ä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 måste nya bilder som modellen presterar dåligt för granskas och kommenteras av en process som är mänsklig i loopen, och ofta går nästa åtgärd tillbaka till modellutvecklingsloopen för att uppdatera modellen med de nya bilderna.

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

    Baserat på kriterier för infrastrukturfrågor, till exempel svarsfördröjning för slutpunkter eller otillräcklig beräkning för distributionen, kan automatiserade utlösare och meddelanden implementera lämpliga åtgärder att vidta. Detta utlöser en loopback till installations- och administrationsfasen där infrastrukturteamet kan undersöka och eventuellt konfigurera om miljö-, beräknings- och nätverksresurser.

NLP-arkitektur för Machine Learning

Diagram för N L P-arkitekturen.

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

Arbetsflöde för NLP-arkitekturen

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

  1. Dataegendom

    Det här elementet illustrerar organisationens dataegendom och potentiella datakällor och mål för ett datavetenskapsprojekt. Datatekniker är de främsta ägarna till det här elementet i LIVSCYKELN MLOps v2. Azure-dataplattformarna i det här diagrammet är varken uttömmande eller normativa. Datakällor och mål som representerar rekommenderade metodtips baserat på kundens användningsfall anges med en grön bockmarkering.

  2. Administration och installation

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

  3. Modellutveckling (inre loop)

    Det inre loopelementet består av ditt iterativa datavetenskapsarbetsflöde som utförs på en dedikerad och säker Machine Learning-arbetsyta. Den typiska NLP-modellutvecklingsloopen kan skilja sig avsevärt från det klassiska maskininlärningsscenariot i det att anteckningar för meningar och tokenisering, normalisering och inbäddningar för textdata är de typiska utvecklingsstegen för det här scenariot.

  4. Maskininlärningsregister

    När datavetenskapsteamet har utvecklat en modell som är en kandidat för distribution till produktion kan modellen registreras 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 loop)

    Modelldistributionen eller den yttre loopfasen består av mellanlagring och testning före produktion, produktionsdistribution och övervakning av modellen, data och infrastruktur. CD-pipelines hanterar befordran av modellen och relaterade tillgångar via produktion, övervakning och potentiell omträning, eftersom kriterierna för din organisation och användningsfall uppfylls.

  6. Mellanlagring och test

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

  7. Produktionsdistribution

    När en modell har klarat mellanlagrings- och testfasen kan den befordras till produktion av ett gated-godkännande från människan i loopen. Alternativen för modelldistribution omfattar en hanterad batchslutpunkt för batchscenarier eller, för scenarier i nära realtid, antingen en hanterad onlineslutpunkt eller Kubernetes-distribution med hjälp av Azure Arc. Produktionen sker vanligtvis på en eller flera dedikerade, säkra Machine Learning-arbetsytor.

  8. Övervakning

    Övervakning i mellanlagring, testning och produktion gör det möjligt för dig att samla in och agera på ändringar i prestanda för modellen, data och infrastruktur. Modell- och dataövervakning kan omfatta kontroll av modell- och dataavvikelser, modellprestanda för nya textdata och ansvarsfulla AI-problem. Infrastrukturövervakning kan övervaka problem som 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 NLP de viktigaste skillnaderna från klassisk maskininlärning. Automatisk omträning görs vanligtvis inte i NLP-scenarier när modellprestandaförsämring på ny text identifieras. I det här fallet måste nya textdata som modellen fungerar dåligt för granskas och kommenteras av en process som är mänsklig i loopen. 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

    Baserat på kriterier för infrastrukturfrågor, till exempel svarsfördröjning för slutpunkter eller otillräcklig beräkning för distributionen, kan automatiserade utlösare och meddelanden implementera lämpliga åtgärder att vidta. De utlöser en loopback till installations- och administrationsfasen där infrastrukturteamet kan undersöka och eventuellt konfigurera om beräknings- och nätverksresurserna.

Komponenter

  • Machine Learning: En molntjänst för träning, bedömning, distribution och hantering av maskininlärningsmodeller i stor skala.
  • Azure Pipelines: Det här bygg- och testsystemet 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: En kodvärdplattform för arbetsflöden för versionskontroll, samarbete och CI/CD.
  • Azure Arc: En plattform för att hantera Azure och lokala resurser med hjälp av Azure Resource Manager. Resurserna kan innehålla virtuella datorer, Kubernetes-kluster och databaser.
  • Kubernetes: Ett system med öppen källkod för att automatisera distribution, skalning och hantering av containerbaserade program.
  • Azure Data Lake: Ett Hadoop-kompatibelt filsystem. Den har ett integrerat hierarkiskt namnområde och bloblagringens enorma skala och ekonomi.
  • Azure Synapse Analytics: En gränslös analystjänst som sammanför dataintegrering, lagring av företagsdata och stordataanalys.
  • Azure Event Hubs. En tjänst som matar in dataströmmar som genereras av klientprogram. Den matar sedan in och lagrar strömmande data, vilket bevarar sekvensen med mottagna händelser. Konsumenter kan ansluta till hubbslutpunkterna för att hämta meddelanden för bearbetning. Här utnyttjar vi integreringen med Data Lake Storage.

Deltagare

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

Huvudsakliga författare:

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

Nästa steg