AWS Certified AI Practitioner

Anatomia de um pipeline de ML

As etapas que levam um modelo dos dados brutos até a produção monitorada: coleta de dados, EDA, pré-processamento, engenharia de features, treinamento, ajuste, avaliação, implantação e monitoramento, e por que o pipeline é um ciclo, não uma linha reta.

Iniciante 18 minutos 4 Objetivos de aprendizado
  1. Listar as etapas de um pipeline de ML em ordem, da coleta de dados ao monitoramento
  2. Distinguir EDA, pré-processamento e engenharia de features, que os alunos confundem com frequência
  3. Explicar por que a implantação não é a linha de chegada e como o monitoramento fecha o ciclo de volta aos dados
  4. Associar uma atividade descrita à etapa do pipeline a que ela pertence

Um modelo com 95% de acurácia num notebook no seu laptop não é um produto. Entre esse resultado promissor e um sistema em que seus usuários confiam existe uma sequência de etapas que a maioria dos iniciantes subestima: conseguir os dados certos, limpá-los, moldá-los, treinar, testar, publicar e depois acompanhar o modelo solto no mundo para que ele não apodreça em silêncio. Essa sequência é o pipeline de ML, e o exame espera que você nomeie as etapas, separe as que se confundem e entenda por que ele nunca termina de verdade. Esta lição percorre o caminho inteiro uma vez, de ponta a ponta.

Fixe um objetivo concreto para ancorar cada etapa: um banco quer um modelo que preveja quais clientes estão prestes a encerrar a conta, para abordá-los antes que saiam. Vamos seguir esse modelo de churn dos dados brutos até a produção.

O pipeline em visão geral

O pipeline tem uma ordem natural, e a ordem importa: cada etapa depende da anterior, e você não consegue pular adiante.

Leia em três blocos. Primeiro você prepara os dados (coleta, EDA, pré-processamento, engenharia de features). Depois constrói o modelo (treinamento, ajuste, avaliação). Então roda em produção (implantação, monitoramento). E o monitoramento volta ao início. Agora vamos percorrer cada etapa com o modelo de churn em mãos.

Preparar os dados

A coleta de dados vem primeiro porque um modelo só aprende com o que você dá a ele. Para o modelo de churn, isso significa reunir histórico de conta, registros de transações, tickets de suporte e atividade de login, e juntar tudo num só lugar. A regra que governa toda essa fase: lixo entra, lixo sai. Nenhuma etapa posterior salva um modelo treinado com dados errados ou faltando.

A análise exploratória de dados (EDA) é a etapa de olhar antes de agir. Antes de mudar um único valor, você explora o que os dados de fato contêm: quantas contas você tem, quais campos estão faltando, se o "saldo" às vezes é negativo, se clientes que saíram são raros (costumam ser). A EDA não transforma os dados. Ela constrói o seu entendimento sobre eles, e esse entendimento molda cada decisão seguinte.

O pré-processamento de dados é a etapa de limpeza. Dados reais são bagunçados: valores ausentes, linhas duplicadas, formatos inconsistentes ("Brasil" vs "BR" vs "brasil"), erros óbvios como uma idade de 200 anos. O pré-processamento corrige isso para que os dados fiquem consistentes e utilizáveis. Você preenche ou descarta valores ausentes, padroniza formatos e remove registros ruins.

A engenharia de features é onde você constrói as entradas que o modelo vai aprender, chamadas features. Isso não é limpeza; é criação. De um timestamp bruto de "último login" você pode derivar "dias desde o último login". De um ano de transações você pode calcular "gasto médio mensal" e "tendência de gasto nos últimos 3 meses". Boas features costumam ser o que separa um modelo medíocre de um forte, porque entregam o sinal ao algoritmo num formato que ele consegue usar.

Essas três etapas de dados são confundidas o tempo todo, então fixe a distinção agora. EDA é entender, pré-processamento é limpar, engenharia de features é criar. Um valor ausente: a EDA percebe, o pré-processamento preenche, a engenharia de features não tem nada a ver com ele. Esse exemplo mínimo separa os três.

Construir o modelo

O treinamento do modelo é a etapa que a maioria imagina quando pensa em machine learning, embora a essa altura você já veja que é só um passo entre muitos. Você alimenta o algoritmo com os dados preparados e ele aprende os padrões que ligam as features ao resultado (aqui, as features a "saiu ou ficou"). A saída é um modelo treinado.

O ajuste de hiperparâmetros regula as configurações que controlam como o treinamento acontece. Elas não são aprendidas dos dados; você as define. Pense no número de camadas de uma rede ou na velocidade com que o modelo se ajusta durante o treinamento. O ajuste testa combinações diferentes para achar as que produzem o melhor modelo, muitas vezes de forma automática. É girar os botões do processo de treinamento, não dos dados.

A avaliação é a prova de honestidade. Você mede o modelo em dados que ele nunca viu durante o treinamento, um conjunto de teste separado, porque um modelo que decorou os dados de treino pode parecer perfeito e ainda assim falhar com clientes reais. Se o modelo de churn captura só 40% dos clientes que de fato saem, a avaliação é onde você descobre isso antes dos seus usuários. A lição sobre métricas aprofunda esse ponto; por ora, saiba que a avaliação é o portão entre "treinado" e "confiável".

Rodar em produção

A implantação coloca o modelo para trabalhar. Você o disponibiliza para que os outros sistemas do banco enviem um cliente e recebam de volta uma pontuação de churn, seja por um endpoint sempre ligado respondendo em tempo real, seja por um job noturno que pontua todas as contas de uma vez. A próxima lição cobre essas escolhas em detalhe.

O monitoramento é a etapa que os iniciantes esquecem, e é onde modelos falham em silêncio. Um modelo de churn treinado no comportamento do ano passado pode perder acurácia devagar conforme os clientes mudam, a economia se move ou o banco lança produtos novos. Isso se chama drift. O monitoramento acompanha o modelo em produção, então você detecta a degradação e age, normalmente coletando dados novos e retreinando. Essa é a seta que volta ao início.

Aqui está a ideia errada que precisa morrer: a de que publicar o modelo é a linha de chegada. Não é. Um modelo implantado é um ativo perecível. O pipeline é um ciclo, não uma linha, porque o mundo que o modelo descreve continua se movendo, e um modelo que nunca é retreinado é um modelo que vai ficando desatualizado aos poucos.

Dicas para o exame

  • Saiba a ordem das etapas e esteja pronto para encaixar uma atividade nela. "Plotar distribuições para entender os dados" é EDA; "preencher valores ausentes" é pré-processamento; "criar um campo de dias desde a última compra" é engenharia de features.
  • A armadilha mais comum é embaralhar EDA, pré-processamento e engenharia de features. Fixe pelos verbos: entender, limpar, criar. Um enunciado que descreve limpeza é pré-processamento, mesmo que use a palavra "preparar".
  • "A acurácia do modelo caiu três meses depois do lançamento" é um cenário de monitoramento e drift, e a correção é retreinar, não reimplantar o mesmo modelo.
  • Desconfie de respostas que tratam a implantação como a última etapa. O monitoramento vem depois, e o pipeline volta aos dados.

Leve uma imagem desta lição: dados entram, modelo sai, produção, e de volta aos dados. Cada serviço da AWS das próximas lições se encaixa numa dessas etapas, e MLOps (mais adiante neste tópico) é a disciplina de rodar esse ciclo inteiro de forma confiável e repetível. A seguir você vai ver de onde vêm os modelos e como de fato colocá-los em produção.