Misturar dados de treino e teste (leakage)

Esse é o erro mais traiçoeiro: o desempenho fica “perfeito” durante a avaliação e despenca na prática.
Normalmente, acontece quando informações do futuro entram no passado — por exemplo, quando algum pré-processamento
usa estatísticas calculadas no conjunto inteiro.

Como evitar: aplique o pré-processamento apenas com o treino e replique o mesmo transformador no teste.
Para dados dependentes, use splits por tempo ou por entidade (ex.: usuário, sessão, região).

Avaliar com a métrica errada (ou sem refletir custos)

Escolher uma métrica “bonita” sem alinhamento com o objetivo é um caminho rápido para decisões ruins.
A curva pode melhorar, mas o resultado operacional piora — especialmente em classificação desbalanceada.

• Acurácia costuma enganar quando classes são desbalanceadas.
• Log-loss pode penalizar excesso de confiança, mas você precisa entender se isso representa seu custo real.
• F1-score esconde trade-offs: qual erro você aceita mais (falso positivo vs falso negativo)?
• RMSE/MAE ignoram assimetria do problema quando superestimar e subestimar têm impactos diferentes.

Um bom sinal: você consegue explicar o que acontece com o sistema quando a métrica melhora — e isso é consistente com o uso real.

Pré-processamento inconsistente entre treino e produção

Um projeto “funciona” no notebook e falha depois por causa de divergência de transformações:
encoding diferente, ordem de colunas alterada, tratamento de valores ausentes ausente, escalonamento calculado errado.

• Normalização baseada em estatísticas do treino não é reaplicada do mesmo jeito.
• Campos categóricos: valores novos surgem e você não define fallback.
• Datas/horários: timezone e granularidade mudam sem controle.
• Imputação: estratégia muda (ou é diferente entre treino/teste).

Não controlar o procedimento experimental (reprodutibilidade)

Mesmo com dados bons e métricas corretas, você pode “perder” o que funcionou por falta de rastreabilidade.
Isso aparece como: variações silenciosas de seed, splits diferentes a cada execução, e hiperparâmetros ajustados sem registro.

• Seeds inconsistentes tornam comparações injustas.
• Splits recalculados sem fixar critério dificultam depuração.
• Configurações espalhadas: cada ajuste vira uma versão diferente do pipeline.
• Critérios de parada frágeis: você para quando “parece bom”, não quando está claro.

# Exemplo (Python): split honesto + pré-processamento aplicado só no treino
# Observação: ajuste para seu caso (classificação/regressão, numéricos/categóricos).

from sklearn.model_selection import train_test_split
from sklearn.compose import ColumnTransformer
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import OneHotEncoder, StandardScaler
from sklearn.impute import SimpleImputer
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import roc_auc_score
import numpy as np

RANDOM_SEED = 42

X = ...  # features em DataFrame
y = ...  # target

num_cols = ["idade", "renda"]            # exemplo
cat_cols = ["cidade", "canal"]          # exemplo

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, random_state=RANDOM_SEED, stratify=y
)

numeric_tf = Pipeline(steps=[
    ("imputer", SimpleImputer(strategy="median")),
    ("scaler", StandardScaler())
])

categorical_tf = Pipeline(steps=[
    ("imputer", SimpleImputer(strategy="most_frequent")),
    ("onehot", OneHotEncoder(handle_unknown="ignore"))
])

preprocess = ColumnTransformer(
    transformers=[
        ("num", numeric_tf, num_cols),
        ("cat", categorical_tf, cat_cols),
    ],
    remainder="drop"
)

model = LogisticRegression(max_iter=2000, random_state=RANDOM_SEED)

clf = Pipeline(steps=[
    ("preprocess", preprocess),
    ("model", model)
])

clf.fit(X_train, y_train)

# Métrica em teste: sem ajustes após fit
proba = clf.predict_proba(X_test)[:, 1]
auc = roc_auc_score(y_test, proba)

print({"roc_auc_test": float(auc)})

Esse padrão força consistência: o pré-processamento “aprende” no treino e só transforma o teste com o mesmo criterio.