Muitas respostas erradas no MLA-C01 não vêm de desconhecer um conceito, mas de escolher o serviço parecido. Só de ferramentas de preparação de dados são quatro ou cinco, as ferramentas para olhar dentro de um modelo se dividem entre Clarify, Debugger e Model Monitor, e há várias opções de inferência e configurações de endpoint. Quando duas opções aparecem em par, como Data Wrangler e Glue DataBrew, não basta conhecer cada definição; é preciso conseguir dizer em uma frase o critério que as separa.
Este artigo é a parte de revisão da série de estudos do MLA-C01. Dos serviços explicados separadamente nos artigos de cada domínio, ele escolhe só os grupos que costumam aparecer como resposta errada um do outro e os reorganiza pelos critérios que os separam e pelas pistas das questões. No final, também reúne os serviços e recursos que mudaram de nome ou fecharam para novos cadastros.
---
Três Perguntas que Separam os Serviços que se Confundem
Diante de dois serviços parecidos, fazer estas três perguntas em ordem resolve a maioria dos casos.
| Pergunta | O que separa | Exemplo | |------|------|------| | Quando é usado? | A etapa do ciclo de vida de ML (antes, durante ou depois do treinamento) | Clarify para viés antes e depois do treinamento, Debugger durante o treinamento, Model Monitor depois da implantação | | Quem escreve o código? | Ferramentas sem código vs. ferramentas com código | DataBrew com cliques, Glue ETL com código Spark | | Com que rapidez e em que escala? | Tempo real vs. lote, tamanho e latência | O endpoint em tempo real responde na hora, a transformação em lote processa grandes volumes de uma vez |
---
Domínio 1: Pares que se Confundem na Preparação de Dados
Data Wrangler vs. Glue DataBrew vs. Glue ETL vs. SageMaker Processing
| Aspecto | Data Wrangler | Glue DataBrew | Glue ETL | SageMaker Processing | |------|------|------|------|------| | Abordagem | Preparação visual de dados para ML (agora dentro do SageMaker Canvas) | Limpeza e normalização de dados sem código | ETL com código Spark sem servidor | Executa seus próprios scripts em contêineres gerenciados | | Usuários principais | Profissionais de ML | Analistas e responsáveis por preparar dados | Engenheiros de dados | Engenheiros de ML | | Pista na questão | "criar atributos de ML de forma visual e ir direto ao treinamento" | "limpar a qualidade dos dados sem código" | "transformar muitas origens em escala, Catálogo de Dados" | "uma etapa de pré-processamento ou avaliação dentro de um pipeline do SageMaker" |
Quando é preciso controlar diretamente grandes clusters Spark ou Hadoop ou reduzir custos com instâncias Spot, a resposta é o Amazon EMR.
!Espectro de ferramentas de preparação de dados, do Data Wrangler e DataBrew sem código até Glue ETL, SageMaker Processing e EMR
Como o Treinamento Lê os Dados: Modos File, FastFile e Pipe, FSx for Lustre e EFS
| Método | Características | Pista na questão | |------|------|------| | Modo File do S3 | Copia todos os dados para a instância antes de começar o treinamento | Dados pequenos, o padrão | | Modo FastFile do S3 | Parecem arquivos, mas são lidos do S3 sob demanda, então o treinamento começa rápido | Dados grandes, início rápido sem mudar o código | | Modo Pipe do S3 | Lê do S3 como um fluxo | A abordagem antiga, hoje em grande parte substituída pelo FastFile | | FSx for Lustre | Sistema de arquivos paralelo de alto desempenho ligado ao S3 | Treinamento distribuído grande, leituras rápidas e repetidas dos mesmos dados por muitas épocas | | EFS | Sistema de arquivos compartilhado por várias instâncias | Os dados já estão no EFS |
Armazenamento Online vs. Offline do Feature Store
O armazenamento online é para inferência e lê os valores mais recentes dos atributos em milissegundos, enquanto o armazenamento offline é para treinamento e guarda todo o histórico no S3. Gravar os mesmos atributos nos dois mantém consistentes os atributos de treinamento e de serviço.
Posts relacionados: Ingestão e Armazenamento de Dados, Pipelines de ML em Streaming e Orientados a Eventos, Engenharia de Features e Qualidade de Dados
---
Domínio 2: Pares que se Confundem no Desenvolvimento de Modelos
JumpStart vs. Bedrock vs. Autopilot (Canvas) vs. Algoritmos Integrados
| Aspecto | SageMaker JumpStart | Amazon Bedrock | Autopilot (Canvas) | Algoritmos integrados | |------|------|------|------|------| | Núcleo | Implantar e ajustar modelos e soluções pré-treinados no seu próprio ambiente do SageMaker | Usar e personalizar modelos de base por uma API sem servidor | Você entrega os dados e ele busca e treina modelos automaticamente (AutoML) | Treinar diretamente com algoritmos como o XGBoost | | Gestão de infraestrutura | Escolher e gerenciar as instâncias do endpoint | Nenhuma | Quase nenhuma | Escolher instâncias de treinamento e implantação | | Pista na questão | "um modelo aberto em instâncias da nossa VPC" | "uma API de IA generativa sem infraestrutura" | "o melhor modelo a partir de dados tabulares sem especialistas em ML" | "controlar diretamente o algoritmo e os hiperparâmetros" |
Clarify vs. Debugger vs. Model Monitor vs. MLflow
| Aspecto | Clarify | Debugger | Model Monitor | MLflow (antes Experiments) | |------|------|------|------|------| | Quando | Antes e depois do treinamento | Durante o treinamento | Depois da implantação | Enquanto você experimenta | | O que faz | Métricas de viés, explicações com SHAP | Observa tensores e perda, detecta problemas de convergência, para automaticamente | Desvio de qualidade dos dados, qualidade do modelo, viés e atribuição de atributos | Registra e compara parâmetros, métricas e artefatos dos experimentos | | Pista na questão | "equidade", "qual atributo influenciou" | "desaparecimento do gradiente", "a perda não diminui" | "a distribuição de entrada mudou em produção" | "reproduzir e comparar vários experimentos" |
Clarify, Debugger e Model Monitor não aceitam novos clientes desde 30 de julho de 2026, mas no MLA-C01 continuam sendo a resposta para essas situações.
Registro de Modelos vs. Rastreamento de Experimentos com MLflow, Ground Truth vs. A2I
O registro de modelos gerencia as versões e o status de aprovação dos modelos que serão implantados, enquanto o rastreamento de experimentos registra qual configuração produziu qual resultado. O Ground Truth rotula os dados antes do treinamento, e o A2I faz pessoas revisarem os resultados depois da inferência.
Posts relacionados: Escolha da Abordagem de Modelagem, Como Escolher Serviços de IA da AWS, Métricas de Avaliação na Prática e Desbalanceamento de Classes
---
Domínio 3: Pares que se Confundem na Implantação e na Orquestração
Tempo Real vs. Sem Servidor vs. Assíncrona vs. Transformação em Lote
| Aspecto | Tempo real | Sem servidor | Assíncrona | Transformação em lote | |------|------|------|------|------| | Carga e tempo de processamento | Até 25 MB, 60 segundos | Até 4 MB, 60 segundos | Até 1 GB, 1 hora | Conjuntos de dados de GB, até dias | | Chegar a zero | Não (sim com componentes de inferência) | Automático | Sim | As instâncias terminam quando o trabalho acaba | | Pista na questão | "respostas em milissegundos, tráfego constante" | "tráfego intermitente, partidas a frio aceitáveis" | "arquivos grandes, minutos de processamento, uma fila" | "pontuar todos os dados toda noite" |
Multimodelo vs. Multicontêiner vs. Pipeline de Inferência vs. Componentes de Inferência
| Aspecto | O que faz | Pista na questão | |------|------|------| | Endpoint multimodelo (MME) | Mantém milhares de modelos do mesmo framework em um endpoint e os carrega na memória quando invocados | "milhares de modelos por cliente, menor custo, latência da primeira chamada aceitável" | | Endpoint multicontêiner | Invoca separadamente vários contêineres de frameworks diferentes em um endpoint | "um modelo TensorFlow e um PyTorch em um endpoint" | | Pipeline de inferência | Executa de 2 a 15 contêineres em sequência (pré-processamento → modelo → pós-processamento) | "aplicar na inferência exatamente o mesmo pré-processamento do treinamento" | | Componentes de inferência | Atribui recursos separadamente a vários modelos de um endpoint e os escala separadamente | "dividir CPU e memória por modelo e chegar a zero" |
Estratégias de Implantação: Azul/Verde, Canário, Linear, Sombra e A/B
Azul/verde cria um ambiente novo e transfere o tráfego para ele, canário envia primeiro uma pequena parte e depois tudo, e linear transfere o tráfego em etapas iguais. As três podem fazer reversão automática com alarmes do CloudWatch. O teste em sombra avalia um modelo novo sem entregar as respostas dele aos usuários, e o teste A/B divide o tráfego pelos pesos das variantes de produção para comparar resultados reais.
Orquestração: SageMaker Pipelines vs. Step Functions vs. MWAA vs. CodePipeline
O SageMaker Pipelines serve para fluxos feitos só de etapas de ML, o Step Functions para fluxos gerais que unem muitos serviços da AWS, o MWAA para DAGs existentes do Airflow, e o CodePipeline para CI/CD que parte de uma mudança de código (origem → build → teste → implantação).
Posts relacionados: Infraestrutura de implantação e estratégias de escalabilidade, Escalabilidade Automática de Endpoints do SageMaker a Fundo e Escolha do Destino de Implantação, Construindo pipelines MLOps e CI/CD
---
Domínio 4: Pares que se Confundem em Monitoramento, Custos e Segurança
CloudWatch vs. CloudTrail vs. X-Ray vs. AWS Config
| Ferramenta | Pergunta que responde | |------|------| | CloudWatch | O desempenho está normal agora? (métricas, logs, alarmes, painéis) | | CloudTrail | Quem chamou qual API e quando? | | X-Ray | Onde uma solicitação ficou lenta ao passar por vários serviços? | | AWS Config | A configuração dos recursos segue as regras? |
Cost Explorer vs. Budgets vs. Trusted Advisor vs. Compute Optimizer vs. Inference Recommender
| Ferramenta | O que faz | |------|------| | Cost Explorer | Analisa os custos passados