MLA-C01 Domínio: Desenvolvimento de Modelo de ML (26% do exame)

Resumo de estudo de desenvolvimento de modelos para a MLA-C01: seleção de algoritmos, treinamento, hiperparâmetros, métricas de avaliação e mitigação de overfitting.

Por Leonardo Chiarelli · Atualizado em 21/06/2026 · 1 min de leitura

O que é o domínio Desenvolvimento de Modelo de ML?

O domínio Desenvolvimento de Modelo de ML representa 26% do exame MLA-C01, o segundo maior peso entre os quatro domínios. Ele cobre o ciclo central de construção de um modelo: escolher o algoritmo certo, treinar com os recursos adequados, ajustar hiperparâmetros, medir o desempenho com as métricas corretas e corrigir os problemas de generalização (overfitting e underfitting).

A MLA-C01 é uma certificação de nível Associate. As questões deste domínio não são teóricas: elas apresentam cenários reais de engenharia de ML e exigem que você escolha a abordagem correta dado um conjunto de restrições (latência, custo, volume de dados, tipo de problema). Conhecer o nome do algoritmo não é suficiente; você precisa saber quando cada um vence e quais são suas trocas.

Specs do exame para referência: 65 questões em 130 minutos, nota de corte 720 em 1000, nível Associate, USD 150.

Subtopic 1: Seleção de algoritmo e abordagem

A prova começa pela escolha certa: dado um problema de negócio, qual tipo de ML aplicar e qual família de algoritmo usar?

Categorias de problema

O primeiro passo é classificar o problema:

Classificação: prever a categoria de uma instância. Binária (fraude ou não fraude) ou multiclasse (categoria de produto). Métricas: accuracy, precision, recall, F1, AUC-ROC.
Regressão: prever um valor contínuo (preço, demanda, tempo de falha). Métricas: RMSE, MAE, R².
Clustering: agrupar dados sem rótulo (segmentação de clientes, detecção de anomalias não supervisionada). Não há rótulo de treino.
Ranking e recomendação: ordenar itens por relevância para um usuário.
Detecção de anomalia: identificar desvios de comportamento esperado.

Algoritmos nativos do Amazon SageMaker

O exame cobra os algoritmos built-in do SageMaker diretamente. Você não precisa implementar nada: o SageMaker disponibiliza esses algoritmos como contêineres gerenciados, escaláveis e otimizados para rodar em instâncias AWS.

| Algoritmo | Tipo de problema | Quando usar | |---|---|---| | XGBoost | Classificação, regressão | Dados tabulares, alta performance, referência em competições | | Linear Learner | Classificação binária, regressão | Grande volume, interpretabilidade, baseline rápido | | Random Cut Forest | Detecção de anomalia | Streams de dados, sem rótulo de anomalia | | K-Means | Clustering | Segmentação, número de clusters conhecido | | Factorization Machines | Recomendação, classificação | Dados esparsos, sistemas de recomendação | | Object Detection, Image Classification | Visão computacional | Imagens, fine-tuning de modelos pré-treinados | | BlazingText | NLP, classificação de texto, embeddings | Dados de texto em PT-BR ou qualquer idioma | | DeepAR | Previsão de séries temporais | Múltiplas séries relacionadas (demanda, estoque) | | IP Insights | Detecção de anomalia em rede | Comportamento de endereços IP suspeitos |

Pegadinha frequente: a prova apresenta um cenário de detecção de anomalia em logs de rede e lista "K-Means" e "Random Cut Forest" como alternativas. K-Means é não supervisionado, mas requer definir o número de clusters e não é projetado para anomalia em stream. Random Cut Forest é a resposta correta porque detecta anomalias em dados contínuos sem definição de clusters.

SageMaker JumpStart para modelos pré-treinados

Quando o problema envolve texto, imagem ou visão e você não tem dados suficientes para treinar do zero, SageMaker JumpStart oferece modelos pré-treinados prontos para fine-tuning. A decisão de usar JumpStart vs. algoritmo built-in vs. script próprio depende do tipo de dado e do volume de labels disponíveis.

Subtopic 2: Treinamento e tuning de hiperparâmetros

Configuração do job de treinamento

No SageMaker, o treinamento acontece em Training Jobs: você especifica o algoritmo (ou imagem de contêiner), os dados no S3, o tipo de instância e os hiperparâmetros. O SageMaker provisiona, executa e derruba a infraestrutura automaticamente.

Pontos que a prova cobra:

Instâncias de treinamento: ml.m5, ml.c5 para CPU; ml.p3, ml.p4d, ml.g4dn para GPU (deep learning). Escolher GPU sem necessidade eleva custo sem benefício: a prova explora isso.
Dados distribuídos: para datasets grandes, o SageMaker oferece SageMaker Distributed Training com dois modos: data parallelism (mesmo modelo, subsets de dados diferentes em cada instância) e model parallelism (modelo grande demais para uma GPU, particionado entre instâncias). A prova diferencia os dois cenários.
Spot Training: usar instâncias EC2 Spot para reduzir custo de treinamento em até 90%. Exige checkpoints no S3 para retomar de onde parou se a instância for interrompida. A prova pergunta como reduzir custo de treinamento e a resposta envolve Spot + checkpoint.

SageMaker Automatic Model Tuning (HPO)

Hiperparâmetros controlam o comportamento do treino (taxa de aprendizado, profundidade de árvore, número de estimadores) e não são aprendidos pelos dados. Escolher mal um hiperparâmetro degrada o modelo; testá-los manualmente é inviável em escala.

O SageMaker Automatic Model Tuning executa múltiplos jobs com diferentes combinações e encontra a mais promissora. Três estratégias:

Grid search: testa todas as combinações do espaço definido. Exaustivo e caro para muitos hiperparâmetros.
Random search: amostra aleatória do espaço. Mais eficiente que grid para espaços grandes, mas não usa resultados anteriores.
Bayesian optimization: usa probabilidade condicional para decidir qual combinação testar a seguir, baseada nos resultados anteriores. Reduz o número de jobs necessários. É a estratégia padrão recomendada quando o objetivo é minimizar jobs.

Questão típica: "Um engenheiro precisa otimizar os hiperparâmetros de um modelo XGBoost no SageMaker minimizando o número de jobs de treinamento. Qual estratégia usar?" Resposta: Bayesian optimization via SageMaker Automatic Model Tuning.

Warm start: o HPO do SageMaker permite iniciar um novo job de tuning aproveitando os resultados de um job anterior, acelerando ainda mais a convergência.

Subtopic 3: Avaliação de métricas (precision, recall, AUC)

Treinar o modelo sem medir corretamente é o erro mais comum de quem tem prática técnica mas não sabe o que a prova cobra. Este subtopic representa uma fração significativa das questões de domínio.

Matriz de confusão e derivadas

Toda métrica de classificação parte da matriz de confusão:

True Positive (TP): modelo previu positivo, era positivo.
False Positive (FP): modelo previu positivo, era negativo. (Alarme falso.)
False Negative (FN): modelo previu negativo, era positivo. (Miss.)
True Negative (TN): modelo previu negativo, era negativo.

Métricas derivadas:

Precision = TP / (TP + FP). Das previsões positivas, quantas eram corretas. Relevante quando falso positivo tem custo alto (spam marcado incorretamente).
Recall = TP / (TP + FN). Dos positivos reais, quantos o modelo capturou. Relevante quando falso negativo tem custo alto (câncer não detectado, fraude não detectada).
F1 = 2 * (Precision * Recall) / (Precision + Recall). Média harmônica dos dois. Útil quando as classes são desbalanceadas e você precisa de equilíbrio.
Accuracy = (TP + TN) / total. Enganosa com classes desbalanceadas (99% de não-fraude: um modelo que diz "nunca fraude" tem 99% de accuracy e recall 0 para fraude).

Pegadinha de precision vs. recall: a prova descreve um cenário de detecção de doenças raras e pergunta qual métrica priorizar. Recall vence porque perder um positivo real (FN) é muito mais custoso que um alarme falso (FP).

AUC-ROC

A curva ROC plota a taxa de verdadeiros positivos (recall) contra a taxa de falsos positivos para todos os limiares de classificação. A AUC (Area Under the Curve) resume essa curva em um número:

AUC = 1.0: modelo perfeito.
AUC = 0.5: modelo aleatório (sem poder preditivo).
AUC > 0.8: geralmente considerado bom para classificação binária.

O SageMaker reporta AUC nos metadados de avaliação do job de treinamento para o algoritmo XGBoost e Linear Learner. A prova pergunta como comparar dois modelos de classificação binária de forma independente do limiar: a resposta é AUC-ROC.

Métricas para regressão

RMSE (Root Mean Squared Error): penaliza erros grandes mais que pequenos. Útil quando outliers são problemáticos.
MAE (Mean Absolute Error): penaliza todos os erros linearmente. Mais robusto a outliers.
R²: proporção da variância explicada pelo modelo. Varia de 0 a 1 (ou negativo para modelos péssimos).

Avaliação no SageMaker

O SageMaker Experiments registra métricas de treinamento automaticamente quando você configura metric_definitions no estimador. O SageMaker Model Card documenta o desempenho em diferentes cortes de dados (bias por grupo, por período). Esse fluxo aparece em perguntas de governança e conformidade de ML.

Subtopic 4: Mitigação de overfitting e underfitting

Este é um dos subtopics com mais questões de cenário na MLA-C01 porque testa raciocínio, não memorização.

Diagnóstico

Underfitting: o modelo não aprende nem os dados de treino. Erro alto em treino e em validação. O modelo é simples demais para o problema.
Overfitting: o modelo decora os dados de treino mas não generaliza. Erro baixo em treino, erro alto em validação. O modelo é complexo demais ou os dados são insuficientes.

A curva de aprendizado é o diagnóstico visual: plote o erro de treino e o de validação em função do número de exemplos ou epochs. O gap entre as duas curvas indica overfitting; ambas altas indicam underfitting.

Técnicas de mitigação de overfitting

| Técnica | O que faz | Quando usar | |---|---|---| | Regularização L1 (Lasso) | Adiciona penalidade proporcional ao valor absoluto dos pesos; pode zerar features | Features com ruído; seleção automática | | Regularização L2 (Ridge) | Penalidade proporcional ao quadrado dos pesos; distribui o peso | Features correlacionadas | | Dropout | Desativa neurônios aleatoriamente durante treino (redes neurais) | Deep learning | | Early stopping | Interrompe o treino quando o erro de validação começa a subir | Gradient boosting, redes neurais | | Mais dados | Aumenta o sinal disponível, reduz o efeito do ruído | Qualquer cenário; mais eficaz que qualquer regularização | | Data augmentation | Gera variações sintéticas dos dados de treino (rotação de imagem, etc.) | Visão computacional, NLP com pouco dado | | Cross-validation (k-fold) | Avalia o modelo em k partições diferentes para estimar erro real | Validação robusta com poucos dados |

O XGBoost no SageMaker tem parâmetros de regularização nativos (alpha para L1, lambda para L2) e suporte a early_stopping_rounds. A prova cobra a combinação correta desses hiperparâmetros no cenário de overfitting.

Técnicas de mitigação de underfitting

Aumentar a complexidade do modelo (mais camadas, mais estimadores, mais profundidade de árvore).
Reduzir a regularização (se estava muito alta).
Treinar por mais epochs (se o modelo ainda estava convergindo).
Engenharia de features para fornecer informação mais rica ao modelo.

SageMaker Debugger

O SageMaker Debugger monitora o treino em tempo real e emite alertas quando detecta problemas: gradientes explodindo, overfitting precoce, vanishing gradients, e outras anomalias de treino. Para a MLA-C01, o Debugger aparece em perguntas de "como detectar overfitting durante o treinamento sem esperar o job terminar".

Serviços AWS centrais deste domínio

Amazon SageMaker Studio: ambiente unificado de ML (notebooks, experiments, pipelines, model registry).
SageMaker Training Jobs: executa o treino em infraestrutura gerenciada com os algoritmos built-in ou imagens customizadas.
SageMaker Automatic Model Tuning: HPO com busca bayesiana, grid ou random.
SageMaker Debugger: monitoramento de treino em tempo real.
SageMaker Experiments: rastreamento de runs, hiperparâmetros e métricas para comparação.
SageMaker JumpStart: modelos pré-treinados para fine-tuning (texto, imagem, código).
SageMaker Clarify: avaliação de bias e explicabilidade de modelos (aparece também no domínio de monitoramento).

Pegadinhas mais comuns na prova

Accuracy em dados desbalanceados: a prova descreve um dataset com 95% da classe negativa e pergunta qual métrica usar. Accuracy não serve; a resposta é F1 ou AUC-ROC.
Spot Training sem checkpoint: a prova descreve um job Spot que foi interrompido e os dados foram perdidos. A causa é ausência de checkpoint no S3. Sempre associar Spot a checkpoint.
Grid search vs. bayesian quando o objetivo é minimizar jobs: a resposta é sempre bayesian, não grid.
Overfitting vs. underfitting a partir de curva de aprendizado: lembre que erro baixo em treino + erro alto em validação = overfitting; ambos altos = underfitting.
L1 vs. L2: L1 zera features (seleção de features implícita); L2 distribui pesos sem zerar. Use L1 quando suspeitar que muitas features são irrelevantes.
Early stopping: é mitigação de overfitting, não de underfitting. A prova troca os dois.

O que estudar a seguir

Pronto para testar o domínio?

Simulado focado nos 4 subtopics: seleção de algoritmo, HPO, métricas e overfitting. Questões no estilo real da MLA-C01, em PT-BR, com explicação por alternativa.

Começar simulado MLA-C01

Preparar para a certificação (trial grátis)