Amazon MLA-C01: MLOps e gestione del ciclo di vita del modello — Guida allo studio
Fa parte della AWS Machine Learning Engineer Associate MLA-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.
Concetto fondamentale
La gestione del ciclo di vita del modello (model lifecycle management) in AWS si concentra sul trattamento dei modelli come artefatti versionati con una lineage verificata, gate di promozione automatizzati e pipeline riproducibili. Amazon SageMaker fornisce le primitive necessarie: SageMaker Pipelines per l’orchestrazione, SageMaker Model Registry (ModelPackage/ModelPackageGroup) per il versionamento e lo stato di approvazione, SageMaker Projects e CodePipeline per la CI/CD, e Model Monitor/Clarify per i controlli continui di qualità e bias. Un ciclo di vita robusto inizia con input riproducibili: dati di training immutabili in S3 con crittografia lato server tramite KMS e policy dei bucket restrittive o controlli di Lake Formation, codice versionato in un repository sorgente e l’ambiente di training dichiarato negli URI delle immagini container e nei tipi di istanza passati a CreateTrainingJob o allo TrainingStep dell’SDK di sagemaker.
I controlli operativi includono l’isolamento di rete tramite VpcConfig di CreateTrainingJob (Subnets e SecurityGroupIds) e EnableNetworkIsolation per impedire il traffico in uscita (egress), e ruoli IAM configurati con il principio del privilegio minimo (least privilege) (SageMakerExecutionRole con s3:GetObject, kms:Decrypt per il bucket specifico). Al termine di un processo di training, l’artefatto viene registrato nel Model Registry utilizzando CreateModelPackage o la chiamata SDK register_model con un ModelPackageGroupName e impostando ModelApprovalStatus su “PendingManualApproval” per attivare i gate di approvazione manuale. I metadati di lineage — iperparametri di training, immagine Docker, URI S3 dei dati di input, commit Git — dovrebbero essere allegati come metadati del pacchetto del modello, in modo che la CI/CD a valle e gli audit possano tracciare a ritroso dall’endpoint di produzione fino al codice e al set di dati.
La CI/CD per il ML si differenzia dalla CI/CD tradizionale perché gli artefatti (modelli, baseline, monitor) sono di grandi dimensioni e hanno output non deterministici. La CI/CD si implementa con i template di SageMaker Projects insieme ad AWS CodePipeline e CodeBuild. Si usa CodeBuild per eseguire unit test, smoke test per il training del modello (ad esempio, con epoche brevi o un sottoinsieme di dati) e test di integrazione. Si usa CodePipeline per orchestrare i passaggi source → build → register-model e per incorporare un’azione di ManualApproval o un’azione personalizzata basata su Lambda per modificare il ModelApprovalStatus del ModelPackage tramite UpdateModelPackage. Per la promozione automatizzata, CodePipeline può chiamare le API SageMaker CreateEndpointConfig e CreateEndpoint, oppure utilizzare stack CloudFormation generati da SageMaker Projects per effettuare il deploy con un’infrastruttura come codice (infrastructure-as-code) prevedibile.
Servizi e configurazioni chiave
SageMaker Pipelines è il livello di orchestrazione: si dichiarano gli oggetti ProcessingStep, TrainingStep, ModelStep, TransformStep e RegisterModel in Python. Si utilizza CacheConfig sugli step (CacheConfig(enable_caching=True, expire_after=timedelta(days=1))) in modo che riutilizzino gli output quando gli input e i parametri non sono cambiati; questo evita il provisioning non necessario di istanze. Per RegisterModel, si usa sagemaker.workflow.steps.RegisterModel con model_package_group_name e model_approval_status impostati su “PendingManualApproval” per integrare i gate di approvazione nel grafo della pipeline. Si utilizza l’API pipeline.start() per avviare le esecuzioni e pipeline.get_steps() o la console per ispezionare lo stato dell’esecuzione e la lineage.
SageMaker Model Registry memorizza i pacchetti di modelli (model package) sotto un ModelPackageGroupName e assegna identificatori ModelPackageVersion. Le API pertinenti sono CreateModelPackageGroup, CreateModelPackage, DescribeModelPackage e UpdateModelPackage per modificare il ModelApprovalStatus in “Approved” o “Rejected”. Gli oggetti ModelPackage dovrebbero includere campi di metadati come InferenceSpecification (Containers, SupportedContentTypes, SupportedResponseMIMETypes) e ModelApprovalStatus. In fase di deploy, si chiama CreateModel con ModelName e PrimaryContainer usando l’ARN del pacchetto del modello e poi CreateEndpointConfig con DataCaptureConfig (EnableCapture=true, SamplingPercentage, DestinationS3Uri) per abilitare la cattura delle inferenze (inference capture).
Per il monitoraggio e il rilevamento del bias, si usano SageMaker Model Monitor e SageMaker Clarify. Model Monitor richiede una baseline creata tramite DefaultModelMonitor.suggest_baseline, che chiama CreateProcessingJob per generare statistiche e vincoli di baseline; queste baseline sono memorizzate in S3 e referenziate in CreateMonitoringSchedule. Le pianificazioni di monitoraggio (monitoring schedule) sono create con CreateMonitoringSchedule e possono essere avviate/arrestate tramite StartMonitoringSchedule/StopMonitoringSchedule. Per controlli di bias ad hoc su un endpoint in tempo reale, si esegue un job di SageMaker Processing con il container di Clarify (tramite sagemaker.processing.ScriptProcessor o ClarifyProcessor) utilizzando i log di inferenza catturati come input; Clarify supporta i controlli di Model Bias e restituisce i report in S3.
Per aggregare in modo sicuro fonti di dati eterogenee, si usano AWS Glue e Lake Formation per individuare, catalogare ed eseguire l’ETL dei dati da S3, sorgenti JDBC (MySQL on-premise tramite il connettore JDBC di AWS Glue e opzionalmente DataSync per lo spostamento massivo) e sorgenti di streaming. I job di AWS Glue (PySpark) possono scrivere set di dati curati in un data lake S3 crittografato con il controllo degli accessi granulare di Lake Formation. Per il rilevamento automatico delle anomalie con visualizzazione, si può scegliere tra servizi gestiti: Amazon Lookout for Metrics esegue il rilevamento automatico delle anomalie nelle serie temporali, mentre SageMaker Data Wrangler offre un’esplorazione visiva rapida e trasformazioni, e può esportare le pipeline di pre-elaborazione verso SageMaker Processing o Pipelines. Per un rilevamento continuo delle anomalie con dashboard di visualizzazione, si combina Lookout for Metrics per il rilevamento con Amazon QuickSight per la visualizzazione e il drill-down.
Pattern di progettazione e compromessi
Un pattern comune è quello “pipeline-first”: creare una SageMaker Pipeline che includa la pre-elaborazione dei dati (ProcessingStep), il training (TrainingStep), la valutazione del modello (ProcessingStep o ClarifyProcessor), la registrazione del modello (RegisterModel) e il deployment (ModelStep o una promozione manuale). Utilizzare il caching degli step per minimizzare il calcolo ridondante e accelerare lo sviluppo iterativo. Per una promozione sicura, impostare model_approval_status su “PendingManualApproval” e integrare un’azione ManualApproval di CodePipeline o una Lambda di approvazione che aggiorni il pacchetto del modello. Questo design fornisce un percorso auditabile dai dati e dal codice fino alla produzione, abilitando al contempo una governance con intervento umano (human-in-the-loop).
Per la CI/CD, si può scegliere tra due compromessi: promozione completamente automatizzata basata su gate di metriche (veloce, meno passaggi manuali) oppure flussi di lavoro di approvazione manuale (conformità). Implementare il gating basato su metriche con CodeBuild che esegue un piccolo script
undefined
, il quale chiama SageMaker Runtime o carica il pacchetto del modello, calcola le metriche ed emette un artefatto consumato da CodePipeline per decidere il successo/fallimento (pass/fail). Se la conformità richiede un’approvazione umana, inserire una AWS CodePipeline ManualApprovalAction che invii un’email tramite SNS e richieda l’intervento di un approvatore designato per procedere, oppure utilizzare lo stato del Model Registry come fonte di verità canonica e consentire i deployment solo quando ModelApprovalStatus è uguale a “Approved”.
La riduzione della latenza di avvio dei processi di training consiste spesso nell’evitare il provisioning completo e ripetuto. Se molte esecuzioni della pipeline ri-addestrano su input identici, abilitare Pipeline CacheConfig in modo che lo TrainingStep venga saltato quando gli input rimangono invariati. Per le iterazioni che devono eseguire il training a ogni esecuzione ma richiedono bassa latenza, utilizzare tipi di istanza più piccoli per una prototipazione rapida in SageMaker Studio, oppure eseguire esperimenti multipli su un’istanza Amazon EC2 persistente o su un orchestratore di training personalizzato basato su EKS per evitare gli avvii a freddo (cold start) dei container, scambiando l’overhead operativo con una latenza inferiore. Per una scalabilità a livello di produzione, è preferibile accettare un certo ritardo di avvio e automatizzare invece la riproducibilità.
Insidie comuni e criteri decisionali
Un errore frequente è fare affidamento esclusivamente sui log degli endpoint per il rilevamento del drift senza abilitare DataCaptureConfig al momento del deployment; senza l’acquisizione, Model Monitor e Clarify non possono analizzare gli input di inferenza reali. Configurare sempre CreateEndpointConfig con DataCaptureConfig (EnableCapture=true, DestinationS3Uri, CaptureOptions e InitialSamplingPercentage) e impostare una schedulazione di monitoraggio tramite CreateMonitoringSchedule, collegandola alle statistiche di baseline.
Un’altra insidia è la sicurezza inadeguata di S3 e della rete. I job di addestramento che devono rimanere isolati dovrebbero usare VpcConfig in CreateTrainingJob e abilitare la crittografia KMS per gli oggetti S3. Non fare affidamento sui controlli di accesso pubblico; usare invece policy dei bucket S3, endpoint VPC (com.amazonaws.region.s3) e uno scoping mirato dei ruoli IAM. Infine, evitare una CI/CD fragile incorporando le metriche di valutazione e i metadati della model card nel pacchetto del modello e utilizzando un versionamento immutabile (ModelPackageVersion) invece di sovrascrivere gli artefatti.
Problema pratico: scenario d’uso
AcmePay — rilevamento di frodi per flussi di transazioni. La sfida è costruire un ciclo di vita sicuro e verificabile che aggreghi i log delle transazioni da S3, i profili dei clienti e le tabelle MySQL on-premise, addestri un classificatore di frodi XGBoost, mantenga un registro centrale dei modelli con approvazione manuale prima della produzione, rilevi on-demand il drift dei dati e del bias, e minimizzi l’overhead operativo per il versionamento e le esecuzioni iterative.
Centralizzare i dati: usare AWS Glue per eseguire il crawling dei log delle transazioni su S3 e del database MySQL on-premise tramite il connettore JDBC di AWS Glue (con un trasferimento sicuro tramite DataSync o VPC peering per l’accesso di rete). Catalogare i dataset nel Glue Data Catalog e imporre l’accesso tramite AWS Lake Formation. Archiviare i training set curati in un prefisso S3 crittografato (KMS CMK) e usare policy del bucket più un VpcEndpoint per impedire l’accesso pubblico.
Costruire pipeline riproducibili: creare una SageMaker Pipeline con un ProcessingStep per la feature engineering (esportazione da Data Wrangler o Glue ETL), un TrainingStep che esegue il container predefinito di XGBoost con gli iperparametri, e uno step RegisterModel che chiama RegisterModel con model_package_group_name=“acmepay-fraud-group” e model_approval_status=“PendingManualApproval”. Abilitare CacheConfig sugli step di pre-elaborazione e addestramento per riutilizzare gli output quando input e codice non cambiano, riducendo il provisioning ripetuto di istanze.
CI/CD e approvazione: creare un SageMaker Project che genera lo scaffolding di una AWS CodePipeline. La pipeline esegue gli unit test in CodeBuild, avvia la SageMaker Pipeline e, dopo RegisterModel, include un’azione di CodePipeline ManualApproval. L’azione di approvazione manuale, una volta approvata, invoca una funzione Lambda che chiama UpdateModelPackage per impostare ModelApprovalStatus=“Approved” e quindi avvia CreateEndpointConfig e CreateEndpoint per il deployment. Usare le risorse CloudFormation generate da SageMaker Projects per mantenere l’infrastruttura riproducibile.
Addestramento e deployment sicuri: sottomettere i job di addestramento con VpcConfig in CreateTrainingJob (SubnetIds, SecurityGroupIds) e EnableNetworkIsolation=true; assicurarsi che il ruolo di esecuzione di SageMaker abbia i permessi kms:Decrypt sulla chiave KMS e s3:GetObject solo per il prefisso del dataset curato. Per gli endpoint, creare CreateEndpointConfig con DataCaptureConfig (EnableCapture=true, SamplingPercentage=100, DestinationS3Uri=s3://acmepay-prod/capture) in modo che i dati di inferenza vengano conservati per il monitoraggio.
Controlli on-demand di drift e bias: usare SageMaker Clarify in un ProcessingJob sui dati di inferenza acquisiti e sulle etichette di ground truth (se disponibili) per eseguire analisi di ModelBias e ModelExplainability on-demand; invocarlo tramite l’API ClarifyProcessor.run() da una funzione Lambda o da Step Functions quando il team di data science richiede una valutazione. Per avvisi continui sul drift, creare una baseline di Model Monitor tramite DefaultModelMonitor.suggest_baseline e una MonitoringSchedule; usare CreateMonitoringSchedule per eseguire controlli periodici e configurare notifiche SNS per le violazioni.
Razionale di AWS: Glue + Lake Formation centralizzano e proteggono sorgenti eterogenee con un codice ETL personalizzato minimo, SageMaker Pipelines + CacheConfig minimizzano il churn dell’infrastruttura per le esecuzioni iterative, il Model Registry fornisce versionamento immutabile e metadati (ModelPackageGroupName e ModelPackageVersion) e si integra nativamente con i flussi di lavoro di approvazione tramite ModelApprovalStatus, e SageMaker Clarify più Model Monitor forniscono sia valutazioni di bias on-demand sia il rilevamento pianificato del drift. L’uso di SageMaker Projects e CodePipeline standardizza la CI/CD e impone una promozione verificabile e ripetibile da “PendingManualApproval” ad “Approved” prima del deployment in produzione.
← Deployment del modello e inferenza · Tutti i domini · Monitoraggio del modello e osservabilità →
Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Supera l'esame →