Como dividir seus dados sem estragar o modelo
A maioria das pessoas faz split de treino/teste de qualquer jeito e depois fica surpreso quando o modelo performa bem no validset mas falha no mundo real. O problema não é a técnica em si, é a falta de estratégia por trás da segmentação ou clivagem dos dados. Vou começar pelo que todo mundo erra: usar random_split sem pensar na estrutura do seu dataset. Se você tem dados temporais, como vendas mensais, e joga random.shuffle no tudo, vai terminar com dados do futuro no treino e dados do passado no teste. O modelo aprende padrões que nunca vai ver em produção. Isso já me custou dois sprints inteiros num projeto de previsão de demanda onde o split aleatório deu accuracy de 94% e na homologação caímos para 61%.
Quando usar segmentação ou clivagem stratificada
Stratified split preserva a distribuição das classes em cada fold. Se sua dataset tem 80% de classe A e 20% de classe B, tanto o treino quanto o teste precisam manter essa proporção. Em Python com scikit-learn, é uma linha: train_test_split(X, y, test_size=0.2, stratify=y, random_state=42)
Mas atenção: stratified só funciona bem quando cada classe tem amostras suficientes. Se você tem uma classe minoritária com menos de 50 exemplos, o stratify vai falhar silenciosamente ou distorcer a distribuição. Nesse caso, use group_split ou simplesmente aceite que o teste terá poucos exemplos daquela classe e avalie com métricas adequadas como F1 macro em vez de accuracy. O que quase ninguém comenta é que o random_state não garante reprodutibilidade real se seu pipeline envolve operações assíncronas ou preprocessamento não-determinístico. Eu descobri isso quando três execuções do mesmo código com o mesmo seed produziram splits ligeiramente diferentes porque uma etapa de limpeza usava um set() cuja ordem de iteração depende do hash seeding do Python. A solução foi fixar o seed do numpy e do Python explicitamente antes de qualquer operação de shuffle.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O problema que ninguém conta sobre holdout simples
Holdout simples funciona para datasets grandes eIID. Para o resto dos casos, você precisa deCross-validation inteligente. K-fold padrão é ingênuo para dados dependentes. Se você tem dados agrupados por usuário, por sessão, por ID de transação, o split deve ser feito no nível do grupo, não no nível da amostra. Caso contrário, o mesmo usuário pode aparecer no treino e no teste, e o modelo simplesmente memoriza padrões individuais ao invés de aprender generalizações. No meu caso, working em churn prediction para uma operadora de telecom, tínhamos 2 milhões de linhas mas apenas 300 mil usuários únicos. Um GroupKFold com group_by=user_id foi o que fez o modelo generalizar de verdade. O gap entre CV score e produção caiu de 18 pontos percentuais para 4 pontos. Antes disso eu passava noites tentando ajustar hiperparâmetros sem entender por quê o modelo não funcionava fora do notebook.
TimeSeriesSplit é o equivalente para dados temporais. Ele garante que o teste sempre venha depois do treino cronologicamente, simulando como o modelo seria usado em produção. Mas tem uma armadilha: se seus dados têm gaps temporais grandes ou sazonalidades complexas, o número ideal de folds pode ser muito maior que os 5 padrão. Eu uso 10 folds como baseline e ajusto baseado no tamanho da janela de treinamento progressiva.
Regras práticas que economizam horas de debugging
Primeiro, separe os dados antes de qualquer preprocessamento. Vazamento de dados (data leakage) acontece quando você fit scaler, imputer ou qualquer transformador no dataset inteiro antes de split. O correto é splitar primeiro e depois ajustar os transformadores apenas no treino, aplicando-os também no teste. Um Pipeline do sklearn resolve isso automaticamente e elimina esse tipo de erro. Segundo, considere manter um holdout set blind que você nunca olha até o final do projeto. Esse conjunto simula dados de produção e evita que você ajustem o modelo indiretamente ao olhar o validset repetidamente. Sim, você pode usar o validset para tuning de hiperparâmetros com GridSearchCV, mas o holdout final deve ser consultado exatamente uma vez.
Terceiro, para datasets desbalanceados com classes muito raras, oversampling (SMOTE) deve ser aplicado apenas dentro do fold de treino durante cross-validation, nunca no dataset completo antes do split. Aplicar SMOTE antes do split vaza informações daMinority class do teste para o treino. A parte mais chata: documentar o split que você usou. Salve os índices do train/teste em arquivos separados. Se algo der errado semanas depois, você precisa conseguir reproduzir exatamente o mesmo split. Um simples np.save('train_indices.npy', train_idx) resolve esse problema e já me salvou mais de uma vez quando precisei refazer um experimento após uma atualização de biblioteca que quebrou a reprodutibilidade.
