Transformação e atributos: o defeito que nenhum ajuste de modelo conserta
- ⬜🗄️ Ingestão e armazenamento: onde o dado mora decide o custo do treino(AWS ML Engineer Associate (MLA-C01))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
O defeito que nenhum ajuste de modelo conserta
Vazamento de dado é quando um atributo do treinamento carrega informação que não existiria no momento da previsão. O modelo aprende a resposta em vez do padrão, atinge acurácia excelente na validação e desaba em produção. É o defeito mais caro do domínio 1 porque ele não parece um defeito: parece um modelo muito bom.
| Forma de vazamento | Como entra | Como se detecta |
|---|---|---|
| Atributo do futuro | Coluna preenchida DEPOIS do evento que se quer prever | Acurácia alta demais; um atributo domina a importância |
| Vazamento na normalização | Média e desvio calculados sobre o conjunto inteiro, antes de separar | Validação boa, teste real pior — diferença estável e inexplicada |
| Duplicata entre partições | O mesmo registro no treino e na validação | Validação quase perfeita desde a primeira época |
| Vazamento temporal | Separação aleatória em dado com ordem no tempo | Modelo prevê o passado usando o futuro |
A regra que previne as duas mais comuns
Separe ANTES de transformar. Média, desvio, codificação de categoria e imputação de faltante devem ser calculados só no conjunto de treino e depois APLICADOS ao de validação e teste. Inverter a ordem contamina a validação com estatística do conjunto inteiro, e o número que você usa para decidir passa a ser otimista de forma silenciosa.
from sklearn.compose import ColumnTransformer
from sklearn.impute import SimpleImputer
from sklearn.model_selection import train_test_split
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import OneHotEncoder, StandardScaler
# 1. Separar PRIMEIRO. Qualquer estatística calculada antes desta linha
# contamina a validação — é o vazamento mais fácil de cometer sem perceber.
X_tr, X_val, y_tr, y_val = train_test_split(X, y, test_size=0.2, random_state=42)
prep = ColumnTransformer([
("num", Pipeline([("imp", SimpleImputer(strategy="median")),
("esc", StandardScaler())]), colunas_numericas),
# `handle_unknown="ignore"`: categoria vista só na validação não quebra a
# transformação — sem isso, o pipeline estoura em produção no primeiro valor novo.
("cat", OneHotEncoder(handle_unknown="ignore"), colunas_categoricas),
])
# 2. `fit` SÓ no treino; a validação apenas recebe a transformação.
prep.fit(X_tr)
X_tr_t, X_val_t = prep.transform(X_tr), prep.transform(X_val)
# Em dado com ordem no tempo, troque `train_test_split` por corte por data:
# embaralhar série temporal treina no futuro e testa no passado.Os serviços de transformação, e o critério de escolha
| Serviço | Feito para | Escolha quando |
|---|---|---|
| SageMaker Data Wrangler | Exploração e transformação visual | A etapa é exploratória e você quer ver o efeito de cada passo |
| SageMaker Processing | Trabalho de transformação em contêiner | A transformação é código seu e roda como etapa de pipeline |
| AWS Glue | ETL sem servidor com catálogo | O dado precisa ser catalogado e a transformação é de dado, não de ML |
| Amazon EMR | Spark e Hadoop gerenciados | Volume muito grande e você já tem trabalho Spark escrito |
A prova raramente pergunta qual é tecnicamente capaz — todos são. Ela pergunta qual tem o menor esforço operacional para o cenário descrito. Glue quando a palavra "catálogo" ou "sem servidor" aparece; EMR quando aparece "Spark existente" ou "controle fino do cluster"; Processing quando a transformação é passo de um fluxo de ML; Data Wrangler quando o cenário fala em exploração ou em pouca escrita de código.
Um modelo de previsão de inadimplência atinge 99,4% de acurácia na validação e 61% em produção. A auditoria mostra que o atributo `valor_recuperado` é o de maior importância. Qual é o problema?
Codificação, escala e faltante
- Categoria de baixa cardinalidade: codificação um-de-N. Simples e sem ordem implícita, ao custo de uma coluna por valor.
- Categoria de alta cardinalidade: codificação por alvo ou por frequência, com a ressalva de que codificação por alvo VAZA se calculada antes da separação — é o caso de vazamento mais sutil que existe.
- Escala: padronização quando o algoritmo assume distribuição centrada; normalização para faixa fixa quando há limite conhecido. Árvores não precisam de nenhuma das duas, e normalizar antes de uma árvore é esforço sem efeito.
- Faltante: imputar pela mediana é o padrão seguro para numérico; para categórico, tratar a ausência como categoria própria costuma render mais do que preencher com a moda, porque o fato de faltar muitas vezes é informação.
A última linha é contraintuitiva e cai na prova
Preencher o faltante com o valor mais comum apaga um sinal real. Se o campo "renda declarada" falta com muito mais frequência em um grupo, essa ausência prevê algo — e substituí-la pela moda joga fora exatamente isso. Criar uma categoria "ausente", ou um atributo binário indicando a ausência, preserva o sinal.
Você vai treinar um modelo baseado em árvores de decisão sobre atributos numéricos em escalas muito diferentes. O que fazer?
Você vai usar codificação por alvo numa categoria de alta cardinalidade. Qual cuidado evita o defeito mais sutil dessa técnica?
Próximo passo
Transformação bem feita gera atributos, e atributo bom é caro de produzir. O passo seguinte trata do problema que aparece quando o mesmo atributo precisa existir no treino e na hora da previsão — e das duas maneiras de calcular ele acabar divergindo.
Perguntas frequentes
❓ O que é vazamento de dados em machine learning e como detectar?
❓ Glue, EMR, SageMaker Processing ou Data Wrangler: qual usar para transformar dados?
❓ Preciso normalizar os atributos antes de treinar um modelo de árvore?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…