Registrera sig
AI

Styr ML-livscykeln i stor skala, del 4: Skala MLO:er med säkerhets- och styrningskontroller

Tycka om
Gillade
Återutgiven av Platon
Återutgiven av Platon

Datum:

Visningar: 202
Lästid: min

Datavetenskapsteam möter ofta utmaningar när de flyttar över modeller från utvecklingsmiljön till produktionen. Dessa inkluderar svårigheter med att integrera datavetenskapsteamets modeller i IT-teamets produktionsmiljö, behovet av att eftermontera datavetenskaplig kod för att möta företagssäkerhets- och styrningsstandarder, få tillgång till produktionskvalitetsdata och bibehålla repeterbarhet och reproducerbarhet i pipelines för maskininlärning (ML), vilket kan vara svårt utan en ordentlig plattformsinfrastruktur och standardiserade mallar.

Det här inlägget, en del av serien "Governing the ML lifecycle at scale" (del 1, del 2, del 3), förklarar hur man konfigurerar och styr en ML-plattform för flera konton som hanterar dessa utmaningar. Plattformen tillhandahåller självbetjäningsförsörjning av säkra miljöer för ML-team, accelererad modellutveckling med fördefinierade mallar, ett centraliserat modellregister för samarbete och återanvändning samt standardiserade processer för modellgodkännande och implementering.

Ett företag kan ha följande roller involverade i ML-livscyklerna. Funktionerna för varje roll kan variera från företag till företag. I det här inlägget tilldelar vi funktionerna i termer av ML-livscykeln till varje roll enligt följande:

  • Ledande dataforskare – Tillhandahålla konton för ML-utvecklingsteam, styra åtkomst till konton och resurser och främja standardiserad modellutveckling och godkännandeprocess för att eliminera upprepad ingenjörsarbete. Vanligtvis finns det en ledande dataforskare för en datavetenskapsgrupp i en affärsenhet, till exempel marknadsföring.
  • Datavetare – Utföra dataanalys, modellutveckling, modellutvärdering och registrering av modellerna i ett modellregister.
  • ML ingenjörer – Utveckla pipelines för modellimplementering och kontrollera modellinstallationsprocesserna.
  • Styrelseansvarig – Granska modellens prestanda inklusive dokumentation, noggrannhet, partiskhet och åtkomst, och ge slutligt godkännande för modeller som ska distribueras.
  • Plattformsingenjörer – Definiera en standardiserad process för att skapa utvecklingskonton som överensstämmer med företagets säkerhets-, övervaknings- och styrningsstandarder; skapa mallar för modellutveckling; och hantera infrastrukturen och mekanismerna för att dela modellartefakter.

Denna ML-plattform ger flera viktiga fördelar. För det första gör det det möjligt för varje steg i ML-livscykeln att överensstämma med organisationens säkerhets-, övervaknings- och styrningsstandarder, vilket minskar den totala risken. För det andra ger plattformen datavetenskapsteam autonomi att skapa konton, tillhandahålla ML-resurser och få tillgång till ML-resurser efter behov, vilket minskar resursbegränsningar som ofta hindrar deras arbete.

Dessutom automatiserar plattformen många av de repetitiva manuella stegen i ML-livscykeln, vilket gör att datavetare kan fokusera sin tid och ansträngningar på att bygga ML-modeller och upptäcka insikter från data snarare än att hantera infrastruktur. Det centraliserade modellregistret främjar också samarbete mellan team, möjliggör centraliserad modellstyrning, ökar insynen i modeller utvecklade i hela organisationen och minskar dubbelarbete.

Slutligen standardiserar plattformen processen för företagsintressenter att granska och konsumera modeller, vilket gör samarbetet mellan datavetenskap och affärsteam smidigare. Detta säkerställer att modeller snabbt kan testas, godkännas och distribueras till produktion för att leverera värde till organisationen.

Sammantaget ger detta holistiska tillvägagångssätt för att styra ML-livscykeln i stor skala betydande fördelar när det gäller säkerhet, smidighet, effektivitet och tvärfunktionell anpassning.

I nästa avsnitt ger vi en översikt över multi-account ML-plattformen och hur de olika rollerna samarbetar för att skala MLOps.

Lösningsöversikt

Följande arkitekturdiagram illustrerar lösningarna för en multi-account ML-plattform och hur olika personer samarbetar inom denna plattform.

Det finns fem konton illustrerade i diagrammet:

  • ML Shared Services-konto – Det här är plattformens centrala nav. Detta konto hanterar mallar för att skapa nya ML Dev-konton, samt SageMaker-projekt mallar för modellutveckling och distribution, i AWS servicekatalog. Det är också värd för ett modellregister för att lagra ML-modeller utvecklade av datavetenskapsteam, och tillhandahåller en enda plats för att godkänna modeller för implementering.
  • ML Dev-konto – Det är här datavetare utför sitt arbete. På det här kontot kan datavetare skapa nya SageMaker anteckningsböcker utifrån behoven koppla till datakällor som t.ex Amazon enkel lagringstjänst (Amazon S3) samlar in, analyserar data, bygger modeller och skapar modellartefakter (till exempel en containerbild) och mer. SageMaker-projekten, som tillhandahålls med hjälp av mallarna i ML Shared Services-kontot, kan påskynda modellutvecklingsprocessen eftersom den har konfigurerade steg (som att ansluta till en S3-hink). Diagrammet visar ett ML Dev-konto, men det kan finnas flera ML Dev-konton i en organisation.
  • ML testkonto – Detta är testmiljön för nya ML-modeller, där intressenter kan granska och godkänna modeller innan de distribueras till produktion.
  • ML Prod-konto – Det här är produktionskontot för nya ML-modeller. Efter att intressenterna har godkänt modellerna i ML-testkontot distribueras modellerna automatiskt till detta produktionskonto.
  • Datastyrningskonto – Detta konto är värd för datastyrningstjänster för datasjö, central funktionslagring och finkornig dataåtkomst.

Nyckelaktiviteter och åtgärder är numrerade i föregående diagram. Vissa av dessa aktiviteter utförs av olika personer, medan andra automatiskt utlöses av AWS-tjänster.

  1. ML-ingenjörer skapar pipelines i Github-förråd, och plattformsingenjören omvandlar dem till två olika Service Catalog-portföljer: ML Admin Portfolio och SageMaker Project Portfolio. ML Admin Portfolio kommer att användas av den ledande dataforskaren för att skapa AWS-resurser (till exempel SageMaker-domäner). SageMaker Project Portfolio har SageMaker-projekt som datavetare och ML-ingenjörer kan använda för att påskynda modellutbildning och implementering.
  2. Plattformsingenjören delar de två Service Catalog-portföljerna med arbetsbelastningskonton i organisationen.
  3. Dataingenjör förbereder och styr datauppsättningar med hjälp av tjänster som Amazon S3, AWS Lake Formation och Amazon DataZone for ML.
  4. Den ledande dataforskaren använder ML Admin Portfolio för att konfigurera SageMaker-domäner och SageMaker Project Portfolio för att sätta upp SageMaker-projekt för sina team.
  5. Dataforskare prenumererar på datauppsättningar och använder SageMaker-anteckningsböcker för att analysera data och utveckla modeller.
  6. Dataforskare använder SageMaker-projekten för att bygga modellutbildningspipelines. Dessa SageMaker-projekt registrerar automatiskt modellerna i modellregistret.
  7. Den ledande dataforskaren godkänner modellen lokalt i ML Dev Account.
  8. Detta steg består av följande understeg:
    1.  Efter att dataforskarna har godkänt modellen utlöser den en händelsebuss i Amazon EventBridge som skickar händelsen till ML Shared Services-kontot.
    2. Händelsen i EventBridge utlöser AWS Lambda-funktionen som kopierar modellartefakter (hanteras av SageMaker eller Docker-bilder) från ML Dev-kontot till ML Shared Services-kontot, skapar ett modellpaket i ML Shared Services-kontot och registrerar den nya modellen i modellregistret i ML Shared Services-kontot.
  9. ML-ingenjörer granskar och godkänner den nya modellen i ML Shared Services-kontot för testning och driftsättning. Denna åtgärd utlöser en pipeline som konfigurerades med ett SageMaker-projekt.
  10. De godkända modellerna distribueras först till ML-testkontot. Integrationstester kommer att köras och endpoint valideras innan de godkänns för produktionsinstallation.
  11. Efter testning godkänner förvaltningsansvarig den nya modellen i CodePipeline.
  12. Efter att modellen har godkänts fortsätter pipelinen att distribuera den nya modellen i ML Prod-kontot och skapar en SageMaker-slutpunkt.

Följande avsnitt ger information om nyckelkomponenterna i detta diagram, hur man ställer in dem och exempelkod.

Konfigurera ML Shared Services-kontot

ML Shared Services-kontot hjälper organisationen att standardisera hanteringen av artefakter och resurser mellan datavetenskapsteam. Denna standardisering hjälper också till att upprätthålla kontroller över resurser som konsumeras av datavetenskapsteam.

ML Shared Services-kontot har följande funktioner:

Servicekatalogportföljer – Detta inkluderar följande portföljer:

  • ML Admin Portfolio – Detta är avsett att användas av projektadministratörerna för arbetsbelastningskontona. Det används för att skapa AWS-resurser för deras team. Dessa resurser kan inkludera SageMaker-domäner, Amazon Redshift-kluster och mer.
  • SageMaker Projects Portfolio – Den här portföljen innehåller SageMaker-produkterna som ska användas av ML-teamen för att påskynda utvecklingen av deras ML-modeller samtidigt som de följer organisationens bästa praxis.
  • Centralt modellregister – Det här är den centraliserade platsen för ML-modeller utvecklade och godkända av olika team. För detaljer om hur du ställer in detta, se del 2 i denna serie.

Följande diagram illustrerar denna arkitektur.

Som första steg ställer molnadministratören upp ML Shared Services-kontot genom att använda en av ritningarna för anpassningar i AWS kontrolltorn kontoförsäljning, som beskrivs i del 1.

I följande avsnitt går vi igenom hur du ställer in ML Admin Portfolio. Samma steg kan användas för att ställa in SageMaker Projects Portfolio.

Starta infrastrukturen för två portföljer

Efter att ML Shared Services-kontot har konfigurerats kan ML-plattformsadministratören starta upp infrastrukturen för ML Admin Portfolio med exempelkod i GitHub-förvaret. Koden innehåller AWS molnformation mallar som senare kan distribueras för att skapa SageMaker Projects Portfolio.

Följ följande steg:

  1. Klona GitHub-repor till en lokal katalog: 
    git clone https://github.com/aws-samples/data-and-ml-governance-workshop.git

  2. Ändra katalogen till portföljkatalogen: 
    cd data-and-ml-governance-workshop/module-3/ml-admin-portfolio

  3. Installera beroenden i en separat Python-miljö med din föredragna Python-pakethanterare: 
    python3 -m venv env
source env/bin/activate pip 
install -r requirements.txt

  4. Bootstrap ditt distributionsmålkonto med följande kommando: 
    cdk bootstrap aws://<target account id>/<target region> --profile <target account profile>

    Om du redan har en roll och AWS-region från kontoinställningen kan du använda följande kommando istället:

    cdk bootstrap

  5. Till sist, distribuera stacken: 
    cdk deploy --all --require-approval never

När det är klart kan du se MLAdminServicesCatalogPipeline pipeline i AWS CloudFormation.

Navigera till AWS CodeStar Connections på tjänstekatalogsidan, du kan se att det finns en anslutning som heter "codeconnection-service-catalog". Om du klickar på anslutningen kommer du att märka att vi måste ansluta den till GitHub för att du ska kunna integrera den med dina pipelines och börja trycka kod. Klicka på "Uppdatera väntande anslutning" för att integrera med ditt GitHub-konto.

När det är gjort måste du skapa tomma GitHub-förråd för att börja trycka kod till. Till exempel kan du skapa ett arkiv som heter "ml-admin-portfolio-repo". Varje projekt du distribuerar kommer att behöva ett arkiv skapat i GitHub i förväg.

Trigga CodePipeline för att distribuera ML Admin Portfolio

Slutför följande steg för att trigga pipelinen för att distribuera ML Admin Portfolio. Vi rekommenderar att du skapar en separat mapp för de olika arkiven som kommer att skapas i plattformen.

  1. Gå ut ur det klonade förvaret och skapa en parallell mapp som heter plattformsförråd: 
    cd ../../.. # (as many .. as directories you have moved in)
mkdir platform-repositories

  2. Klona och fyll det tomma skapade arkivet: 
    cd platform-repositories
git clone https://github.com/example-org/ml-admin-service-catalog-repo.git
cd ml-admin-service-catalog-repo
cp -aR ../../ml-platform-shared-services/module-3/ml-admin-portfolio/. .

  3. Tryck koden till Github-förvaret för att skapa Service Catalog-portföljen: 
    git add .
git commit -m "Initial commit"
git push -u origin main

Efter att den har pushats är Github-förvaret som vi skapade tidigare inte längre tomt. Den nya kodpushen utlöser pipelinen som heter cdk-service-catalog-pipeline för att bygga och distribuera artefakter till Service Catalog.

Det tar cirka 10 minuter för pipelinen att slutföras. När den är klar kan du hitta en portfölj med namnet ML Admin Portfolio på Portfolios-sidan på Service Catalog-konsolen.

Upprepa samma steg för att ställa in SageMaker Projects Portfolio, se till att du använder exempelkoden (sagemaker-projects-portfolio) och skapa ett nytt kodlager (med ett namn som sm-projects-service-catalog-repo).

Dela portföljerna med arbetsbelastningskonton

Du kan dela portföljerna med arbetsbelastningskonton i Service Catalog. Återigen använder vi ML Admin Portfolio som exempel.

  1. På Service Catalog-konsolen väljer du Portföljer i navigeringsfönstret.
  2. Välj ML Admin Portfolio.
  3. På Dela fliken, välj Dela.
  4. I Konto information avsnittet, ge följande information:
    1. För Välj hur du vill dela, Välj Organisationsnod.
    2. Välj organisationsenhet och ange sedan organisationsenhetens ID för arbetsbelastningsenheten.
  5. I Dela inställningar avsnitt, välj Huvuddeldelning.
  6. Välja Dela.
    Väljer Huvuddeldelning alternativet låter dig ange AWS identitets- och åtkomsthantering (IAM) roller, användare eller grupper efter namn som du vill ge behörigheter för i de delade kontona.
  7. På portföljinformationssidan, på Tillgång fliken, välj Ge tillgång.
  8. För Välj hur du ska bevilja åtkomst, Välj Huvudnamn.
  9. I Huvudnamn avsnitt väljer roll/ för Typ och ange namnet på rollen som ML-administratören ska ta på sig i arbetsbelastningskontona Namn .
  10. Välja Ge tillgång.
  11. Upprepa dessa steg för att dela SageMaker Projects Portfolio med arbetsbelastningskonton.

Bekräfta tillgängliga portföljer i arbetsbelastningskonton

Om delningen lyckades bör du se båda portföljerna tillgängliga på Service Catalog-konsolen, på Portföljer sida under Importerade portföljer.

Nu när tjänstekatalogerna i ML Shared Services-kontot har delats med arbetsbelastningens OU kan datavetenskapsteamet tillhandahålla resurser som SageMaker-domäner med hjälp av mallarna och ställa in SageMaker-projekt för att påskynda utvecklingen av ML-modeller samtidigt som de följer organisationens bästa praxis.

Vi visade hur man skapar och delar portföljer med arbetsbelastningskonton. Resan stannar dock inte här. ML-ingenjören kan fortsätta att utveckla befintliga produkter och utveckla nya baserat på organisationens krav.

Följande avsnitt beskriver processerna som är involverade i att konfigurera ML-utvecklingskonton och köra ML-experiment.

Konfigurera ML Development Account

Kontokonfigurationen för ML Development består av följande uppgifter och intressenter:

  1. Teamledaren ber molnadministratören att tillhandahålla ML-utvecklingskontot.
  2. Molnadministratören tillhandahåller kontot.
  3. Teamledaren använder delade Service Catalog-portföljer för att tillhandahålla SageMaker-domäner, ställa in IAM-roller och ge åtkomst och få tillgång till data i Amazon S3, eller Amazon DataZone eller AWS Lake Formation, eller en central funktionsgrupp, beroende på vilken lösning organisationen bestämmer sig för att använda.

Kör ML-experiment

del 3 i den här serien beskrivs flera sätt att dela data över organisationen. Den nuvarande arkitekturen tillåter dataåtkomst med följande metoder:

  • Alternativ 1: Träna en modell med Amazon DataZone – Om organisationen har Amazon DataZone i det centrala förvaltningskontot eller datahubben kan en datautgivare skapa ett Amazon DataZone-projekt för att publicera data. Då kan dataforskaren prenumerera på Amazon DataZone publicerade datamängder från Amazon SageMaker Studio, och använd datauppsättningen för att bygga en ML-modell. Se till Exempelkod för detaljer om hur man använder prenumererade data för att träna en ML-modell.
  • Alternativ 2: Träna en modell med Amazon S3 – Se till att användaren har tillgång till datasetet i S3-hinken. Följ exempelkoden för att köra en ML-experimentpipeline med data lagrade i en S3-hink.
  • Alternativ 3: Träna en modell med hjälp av en datasjö med Athena – Del 2 introducerade hur man ställer upp en datasjö. Följ exempelkoden för att köra en ML-experimentpipeline med data lagrade i en datasjö med Amazon Athena.
  • Alternativ 4: Träna en modell med hjälp av en central funktionsgrupp – Del 2 introducerade hur man skapar en central funktionsgrupp. Följ exempelkoden för att köra en ML-experimentpipeline med data lagrade i en central funktionsgrupp.

Du kan välja vilket alternativ du vill använda beroende på din inställning. För alternativ 2, 3 och 4 tillhandahåller SageMaker Projects Portfolio projektmallar för att köra ML-experimentpipelines, steg inklusive dataintag, modellträning och registrering av modellen i modellregistret.

I följande exempel använder vi alternativ 2 för att demonstrera hur man bygger och kör en ML-pipeline med ett SageMaker-projekt som delades från ML Shared Services-kontot.

  1. På SageMaker Studio-domänen, under implementeringar välj i navigeringsfönstret Projekt
  2. Välja Skapa projekt.
  3. Det finns en lista över projekt som tjänar olika syften. Eftersom vi vill komma åt data lagrade i en S3-hink för att träna ML-modellen, välj projektet som använder data i en S3-hink på Organisationsmallar fliken.
  4. Följ stegen för att tillhandahålla nödvändig information, såsom namn, verktygskonto (ML Shared Services-konto-id), S3-bucket (för MLOPS) och skapa sedan projektet.

Det tar några minuter att skapa projektet.

Efter att projektet har skapats utlöses en SageMaker-pipeline för att utföra de steg som anges i SageMaker-projektet. Välja Rörledningar i navigeringsrutan för att se pipeline. Du kan välja pipeline för att se den riktade acykliska grafen (DAG) för pipelinen. När du väljer ett steg visas dess detaljer i den högra rutan.

Det sista steget i pipelinen är att registrera modellen i det aktuella kontots modellregister. Som nästa steg kommer den ledande dataforskaren att granska modellerna i modellregistret och besluta om en modell ska godkännas för att främjas till ML Shared Services-kontot.

Godkänn ML-modeller

Den ledande dataforskaren bör granska de utbildade ML-modellerna och godkänna kandidatmodellen i modellregistret för utvecklingskontot. Efter att en ML-modell har godkänts utlöser den en lokal händelse, och händelsebussarna i EventBridge kommer att skicka modellgodkännandehändelser till ML Shared Services-kontot, och artefakterna från modellerna kommer att kopieras till det centrala modellregistret. Ett modellkort kommer att skapas för modellen om det är ett nytt, eller så kommer det befintliga modellkortet att uppdatera versionen.

Följande arkitekturdiagram visar flödet av modellgodkännande och modellbefordran.

Modelldistribution

Efter föregående steg är modellen tillgänglig i det centrala modellregistret i ML Shared Services-kontot. ML-ingenjörer kan nu distribuera modellen.

Om du hade använt Exempelkod för att starta SageMaker Projects-portföljen kan du använda Distribuera realtidsslutpunkt från ModelRegistry – Cross account, test and prod alternativet i SageMaker Projects för att skapa ett projekt för att skapa en pipeline för att distribuera modellen till måltestkontot och produktionskontot.

  1. Välj på SageMaker Studio-konsolen Projekt i navigeringsfönstret.
  2. Välja Skapa projekt.
  3. På Organisationsmallar fliken kan du se mallarna som fylldes i tidigare från Service Catalog när domänen skapades.
  4. Välj mallen Distribuera realtidsslutpunkt från ModelRegistry - Cross account, test och prod Och välj Välj projektmall.
  5. Fyll i mallen:
    1. Smakämnen SageMakerModelPackageGroupName är modellgruppens namn på modellen som marknadsfördes från ML Dev-kontot i föregående steg.
    2. Ange distributionstestkonto-ID för PreProdAccount, och Distributions Prod Account ID för ProdAccount.

Pipelinjen för utplacering är klar. ML-ingenjören kommer att granska den nyligen marknadsförda modellen i ML Shared Services-kontot. Om ML-ingenjören godkänner modellen kommer det att utlösa distributionspipeline. Du kan se pipelinen på CodePipeline-konsolen.

Pipelinen kommer först att distribuera modellen till testkontot och sedan pausa för manuellt godkännande för att distribuera till produktionskontot. ML-ingenjör kan testa prestandan och förvaltningsansvarig kan validera modellresultaten i testkontot. Om resultaten är tillfredsställande kan förvaltningsansvarig godkänna i CodePipeline att distribuera modellen till produktionskonto.

Slutsats

Det här inlägget gav detaljerade steg för att ställa in nyckelkomponenterna i en ML-plattform för flera konton. Detta inkluderar konfigurering av ML Shared Services-kontot, som hanterar de centrala mallarna, modellregistret och distributionspipelines; dela ML Admin- och SageMaker-projektportföljerna från den centrala tjänstekatalogen; och sätta upp de individuella ML Development Accounts där datavetare kan bygga och träna modeller.

Inlägget täckte också processen med att köra ML-experiment med hjälp av SageMaker Projects-mallarna, såväl som modellgodkännande och implementeringsarbetsflöden. Dataforskare kan använda de standardiserade mallarna för att påskynda sin modellutveckling, och ML-ingenjörer och intressenter kan granska, testa och godkänna de nya modellerna innan de marknadsförs till produktion.

Denna multi-konto ML-plattformsdesign följer en federerad modell, med ett centraliserat ML Shared Services-konto som tillhandahåller styrning och återanvändbara komponenter, och en uppsättning utvecklingskonton som hanteras av enskilda branscher. Detta tillvägagångssätt ger datavetenskapsteam den autonomi de behöver för att förnya, samtidigt som det tillhandahåller företagsomfattande säkerhet, styrning och samarbete.

Vi uppmuntrar dig att testa den här lösningen genom att följa AWS Multi-Account Data & ML Governance Workshop att se plattformen i aktion och lära dig hur du implementerar den i din egen organisation.

Om författarna

Jia (Vivian) Li är Senior Solutions Architect inom AWS, med specialisering inom AI/ML. Hon stödjer för närvarande kunder inom finansbranschen. Innan hon började på AWS 2022 hade hon sju års erfarenhet av att stödja företagskunder med att använda AI/ML i molnet för att driva affärsresultat. Vivian har en kandidatexamen från Peking University och en doktorsexamen från University of Southern California. På fritiden njuter hon av alla vattenaktiviteter och att vandra i de vackra bergen i sin hemstat, Colorado.

Ram Vittal är Principal ML Solutions Architect på AWS. Han har över 3 decennier av erfarenhet av att bygga och bygga distribuerade, hybrid- och molnapplikationer. Han brinner för att bygga säkra, skalbara, pålitliga AI/ML- och big data-lösningar för att hjälpa företagskunder med deras molnintroduktion och optimeringsresa för att förbättra deras affärsresultat. På fritiden gillar han att köra motorcykel och promenera med sina hundar.

Dr Alessandro Cerè är en GenAI-utvärderingsspecialist och lösningsarkitekt på AWS. Han hjälper kunder över branscher och regioner att operationalisera och styra deras generativa AI-system i stor skala, för att säkerställa att de uppfyller de högsta standarderna för prestanda, säkerhet och etiska överväganden. Alessandro ger ett unikt perspektiv till området AI och har en bakgrund inom kvantfysik och forskningserfarenhet inom kvantkommunikation och kvantminnen. På fritiden utövar han sin passion för landskaps- och undervattensfotografering.

Alberto Menendez är DevOps-konsult inom professionella tjänster på AWS. Han hjälper till att påskynda kundernas resor till molnet och uppnå deras digitala transformationsmål. På fritiden tycker han om att spela sport, särskilt basket och padel, umgås med familj och vänner och lära sig om teknik.

Sovik Kumar Nath är senior lösningsarkitekt för AI/ML och Generativ AI med AWS. Han har lång erfarenhet av att designa end-to-end maskininlärning och affärsanalyslösningar inom ekonomi, drift, marknadsföring, hälsovård, supply chain management och IoT. Han har dubbla magisterexamen från University of South Florida, University of Fribourg, Schweiz, och en kandidatexamen från Indian Institute of Technology, Kharagpur. Utanför jobbet tycker Sovik om att resa, åka färja och titta på film.

Viktor Malesevic är en Senior Machine Learning Engineer inom AWS Professional Services, som leder team för att bygga avancerade maskininlärningslösningar i molnet. Han brinner för att göra AI effektiv och övervakar hela processen från modellering till produktion. På fritiden tycker han om att surfa, cykla och resa.

Relaterade artiklar

plats_img

Senaste artiklar

plats_img
Premium innehåll

Copyright @ 2025 Core Flow Intelligence.