Amazon MLA-C01: MLOps e Gerenciamento do Ciclo de Vida do Modelo — Guia de estudos
Faz parte do AWS Machine Learning Engineer Associate MLA-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.
Conceito principal
O gerenciamento do ciclo de vida de modelos na AWS se concentra em tratar modelos como artefatos versionados com linhagem auditada, gates de promoção automatizados e pipelines reproduzíveis. O Amazon SageMaker fornece as primitivas: SageMaker Pipelines para orquestração, o SageMaker Model Registry (ModelPackage/ModelPackageGroup) para versionamento e estado de aprovação, SageMaker Projects e CodePipeline para CI/CD, e Model Monitor/Clarify para verificações contínuas de qualidade e viés. Um ciclo de vida robusto começa com entradas reproduzíveis — dados de treinamento imutáveis no S3 com criptografia do lado do servidor com KMS e políticas de bucket restritas ou controles do Lake Formation, código versionado em um repositório de origem e o ambiente de treinamento declarado em URIs de imagem de contêiner e tipos de instância passados para o
undefined
ou para o
undefined
do SDK do sagemaker.
Os controles operacionais incluem isolamento de rede via
undefined
(
undefined
e
undefined
) e
undefined
para impedir o tráfego de saída (egress), e roles do IAM com escopo de privilégio mínimo (
undefined
com
undefined
,
undefined
para o bucket específico). Quando um trabalho de treinamento é concluído, registre o artefato no Model Registry usando o
undefined
ou a chamada
undefined
do SDK com um
undefined
e defina o
undefined
como “PendingManualApproval” para acionar gates de aprovação manual. Metadados de linhagem — hiperparâmetros de treinamento, imagem Docker, URIs de dados de entrada do S3, commit do Git — devem ser anexados como metadados do pacote do modelo para que o CI/CD downstream e as auditorias possam rastrear do endpoint de produção de volta ao código e ao conjunto de dados.
O CI/CD para ML difere do CI/CD tradicional porque os artefatos (modelos, baselines, monitores) são grandes e têm saídas não determinísticas. Implemente o CI/CD com os templates do SageMaker Projects, além do AWS CodePipeline e do CodeBuild. Use o CodeBuild para executar testes de unidade, smoke tests do treinamento do modelo (por exemplo, épocas curtas ou um subconjunto de dados) e testes de integração. Use o CodePipeline para orquestrar as etapas de origem → build → registro do modelo, e incorpore uma ação de aprovação manual (ManualApproval) ou uma ação personalizada baseada em Lambda para alterar o
undefined
do
undefined
via
undefined
. Para promoção automatizada, o CodePipeline pode chamar as APIs
undefined
e
undefined
do SageMaker, ou usar stacks do CloudFormation geradas pelo SageMaker Projects para implantar com infraestrutura como código (infrastructure-as-code) previsível.
Principais serviços e configuração
O SageMaker Pipelines é a camada de orquestração: declare os objetos de etapa
undefined
,
undefined
,
undefined
,
undefined
e
undefined
em Python. Use o
undefined
nas etapas (
undefined
) para que as etapas reutilizem as saídas quando as entradas e os parâmetros não tiverem mudado; isso evita o provisionamento desnecessário de instâncias. Para o
undefined
, use
undefined
com
undefined
e
undefined
definidos como “PendingManualApproval” para integrar gates de aprovação no grafo do pipeline. Use a API
undefined
para iniciar as execuções e
undefined
ou o console para inspecionar o status da execução e a linhagem.
O SageMaker Model Registry armazena pacotes de modelo sob um
undefined
e atribui identificadores
undefined
. As APIs relevantes são
undefined
,
undefined
,
undefined
e
undefined
para alterar o
undefined
para “Approved” ou “Rejected”. Os objetos
undefined
devem incluir campos de metadados como
undefined
(
undefined
,
undefined
,
undefined
) e
undefined
. Ao implantar, chame o
undefined
com
undefined
e
undefined
usando o ARN do pacote do modelo e, em seguida, o
undefined
com
undefined
(
undefined
,
undefined
,
undefined
) para habilitar a captura de inferência.
Para monitoramento e detecção de viés (bias), use o SageMaker Model Monitor e o SageMaker Clarify. O Model Monitor requer uma baseline criada via
undefined
, que chama o
undefined
para obter estatísticas e restrições da baseline; essas baselines são armazenadas no S3 e referenciadas no
undefined
. Os agendamentos de monitoramento (monitoring schedules) são criados com o
undefined
e podem ser iniciados/parados via
undefined
/
undefined
. Para verificações de viés ad hoc em um endpoint em tempo real, execute um job do SageMaker Processing com o contêiner do Clarify (via
undefined
ou
undefined
) usando os logs de inferência capturados como entrada; o Clarify oferece suporte a verificações de viés do modelo (Model Bias) e retorna relatórios para o S3.
Para agregar fontes de dados heterogêneas com segurança, use o AWS Glue e o Lake Formation para descobrir, catalogar e fazer o ETL de dados do S3, de fontes JDBC (MySQL on-premises via conector JDBC do AWS Glue e, opcionalmente, o DataSync para movimentação em massa) e de fontes de streaming. Jobs do AWS Glue (PySpark) podem gravar conjuntos de dados curados em um data lake S3 criptografado com controle de acesso refinado do Lake Formation. Para detecção automatizada de anomalias com visualização, escolha entre os serviços gerenciados: o Amazon Lookout for Metrics realiza a detecção automatizada de anomalias em séries temporais, enquanto o SageMaker Data Wrangler fornece exploração visual rápida e transformações, e pode exportar pipelines de pré-processamento de volta para o SageMaker Processing ou Pipelines. Para detecção contínua de anomalias com painéis de visualização, combine o Lookout for Metrics para detecção com o Amazon QuickSight para visualização e análise detalhada (drill-down).
Padrões de design e trade-offs
Um padrão comum é o pipeline-first: criar um SageMaker Pipeline que inclua pré-processamento de dados (ProcessingStep), treinamento (TrainingStep), avaliação de modelo (ProcessingStep ou ClarifyProcessor), registro de modelo (RegisterModel) e implantação (ModelStep ou uma promoção manual). Use o cache de etapas para minimizar a computação redundante e acelerar o desenvolvimento iterativo. Para uma promoção segura, defina model_approval_status como “PendingManualApproval” e integre uma ação ManualApproval do CodePipeline ou uma função Lambda de aprovação que atualize o pacote do modelo. Esse design fornece um caminho auditável desde os dados e o código até a produção, ao mesmo tempo que permite uma governança com intervenção humana (human-in-the-loop).
Para CI/CD, escolha entre dois trade-offs: promoção totalmente automatizada com base em portões de métricas (rápido, menos etapas manuais) versus fluxos de trabalho de aprovação manual (conformidade). Implemente o controle baseado em métricas (metric-based gating) com o CodeBuild executando um pequeno evaluate.py que chama o SageMaker Runtime ou carrega o pacote do modelo, calcula métricas e emite um artefato consumido pelo CodePipeline para decidir entre aprovar/reprovar. Se a conformidade exigir aprovação humana, insira uma ManualApprovalAction do AWS CodePipeline que dispare um e-mail via SNS e exija que um aprovador nomeado prossiga, ou use o estado do Model Registry como a fonte canônica da verdade e permita implantações somente quando ModelApprovalStatus for igual a “Approved”.
Reduzir a latência de inicialização do job de treinamento geralmente envolve evitar o provisionamento completo e repetido. Se muitas execuções de pipeline retreinarem com entradas idênticas, habilite o CacheConfig do Pipeline para que o TrainingStep seja pulado quando as entradas não forem alteradas. Para iterações que precisam treinar a cada execução, mas exigem baixa latência, use tipos de instância menores para prototipagem rápida no SageMaker Studio, ou execute múltiplos experimentos em uma instância Amazon EC2 persistente ou em um orquestrador de treinamento personalizado baseado em EKS para evitar cold starts de contêineres — trocando sobrecarga operacional por menor latência. Para escalabilidade de nível de produção, aceite algum atraso na inicialização e, em vez disso, automatize a reprodutibilidade.
Armadilhas comuns e critérios de decisão
Um erro frequente é confiar apenas nos logs do endpoint para detecção de drift sem habilitar o DataCaptureConfig no momento da implantação; sem a captura, o Model Monitor e o Clarify não conseguem analisar as entradas de inferência reais. Sempre configure o CreateEndpointConfig com DataCaptureConfig (EnableCapture=true, DestinationS3Uri, CaptureOptions e InitialSamplingPercentage) e estabeleça um cronograma de monitoramento via CreateMonitoringSchedule, vinculando-o às estatísticas da linha de base (baseline).
Outra armadilha é a segurança inadequada do S3 e da rede. Jobs de treinamento que precisam permanecer isolados devem usar VpcConfig no CreateTrainingJob e habilitar a criptografia KMS para objetos S3. Não confie em controles de acesso público; em vez disso, use políticas de bucket S3, VPC endpoints (com.amazonaws.region.s3) e escopo de roles do IAM. Por fim, evite um CI/CD frágil incorporando métricas de avaliação e metadados do “model card” no pacote do modelo e usando versionamento imutável (ModelPackageVersion) em vez de sobrescrever artefatos.
Problema Prático: Cenário de Caso de Uso
AcmePay — detecção de fraudes para fluxos de transações. O desafio é construir um ciclo de vida seguro e auditável que agregue logs de transação do S3, perfis de clientes e tabelas MySQL on-premises, treine um classificador de fraudes XGBoost, mantenha um registro de modelos central com aprovação manual antes da produção, detecte desvio (drift) de dados e de viés (bias) sob demanda e minimize a sobrecarga operacional para versionamento e execuções iterativas.
Centralizar dados: use o AWS Glue para fazer o “crawl” dos logs de transação do S3 e do MySQL on-premises através do conector JDBC do AWS Glue (com uma transferência segura pelo DataSync ou VPC peering para acesso à rede). Catalogue os conjuntos de dados no Glue Data Catalog e imponha o acesso via AWS Lake Formation. Armazene os conjuntos de treinamento curados em um prefixo S3 criptografado (KMS CMK) e use políticas de bucket mais VpcEndpoint para impedir o acesso público.
Construir pipelines reprodutíveis: crie um SageMaker Pipeline com um ProcessingStep para engenharia de features (Data Wrangler ou exportação de ETL do Glue), um TrainingStep executando o contêiner integrado do XGBoost com hiperparâmetros, e um passo RegisterModel que chama RegisterModel com model_package_group_name=“acmepay-fraud-group” e model_approval_status=“PendingManualApproval”. Habilite o CacheConfig nos passos de pré-processamento e treinamento para reutilizar as saídas quando as entradas/código não mudarem, reduzindo o provisionamento repetido de instâncias.
CI/CD e aprovação: crie um SageMaker Project que gere a estrutura (scaffold) de um AWS CodePipeline. O pipeline executa testes unitários no CodeBuild, aciona o SageMaker Pipeline e, após o RegisterModel, inclui uma ação de CodePipeline ManualApproval. A ação de aprovação manual, quando aprovada, invoca uma função Lambda que chama UpdateModelPackage para definir ModelApprovalStatus=“Approved” e, em seguida, aciona CreateEndpointConfig e CreateEndpoint para fazer a implantação. Use os recursos do CloudFormation gerados pelos SageMaker Projects para manter a infraestrutura reprodutível.
Treinamento e implantação seguros: submeta os jobs de treinamento com CreateTrainingJob VpcConfig (SubnetIds, SecurityGroupIds) e EnableNetworkIsolation=true; garanta que a role de execução do SageMaker tenha a permissão kms:Decrypt na chave KMS e s3:GetObject apenas para o prefixo do conjunto de dados curado. Para os endpoints, crie o CreateEndpointConfig com DataCaptureConfig (EnableCapture=true, SamplingPercentage=100, DestinationS3Uri=s3://acmepay-prod/capture) para que os dados de inferência sejam retidos para monitoramento.
Verificações de drift e bias sob demanda: use o SageMaker Clarify em um ProcessingJob sobre os dados de inferência capturados e os rótulos de “ground truth” (se disponíveis) para executar análises de ModelBias e ModelExplainability sob demanda; invoque através da API ClarifyProcessor.run() a partir de uma função Lambda ou Step Functions quando a equipe de ciência de dados solicitar uma avaliação. Para alertas contínuos de drift, crie uma linha de base (baseline) do Model Monitor via DefaultModelMonitor.suggest_baseline e um MonitoringSchedule; use o CreateMonitoringSchedule para executar verificações periódicas e configure notificações do SNS para violações.
Justificativa da AWS: O Glue + Lake Formation centraliza e protege fontes heterogêneas com o mínimo de código ETL personalizado. O SageMaker Pipelines + CacheConfig minimiza a rotatividade (churn) de infraestrutura para execuções iterativas. O Model Registry fornece versionamento imutável e metadados (ModelPackageGroupName e ModelPackageVersion) e se integra nativamente com fluxos de trabalho de aprovação via ModelApprovalStatus. O SageMaker Clarify mais o Model Monitor fornecem tanto avaliações de viés (bias) sob demanda quanto detecção de desvio (drift) agendada. O uso de SageMaker Projects e CodePipeline padroniza o CI/CD e impõe uma promoção auditável e repetível de “PendingManualApproval” para “Approved” antes da implantação em produção.
← Implantação e Inferência de Modelos · Todos os domínios · Monitoramento e Observabilidade de Modelos →
Pratique estas questões → · Prática cronometrada no 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.
Passe no seu exame →