Métodos De Separação

Separação de dados é onde os projetos costumam quebrar

A maioria das pessoas trata a separação dos dados como uma formalidade. Dividem o dataset, passam para o modelo e comemoram quando o cross-validation parece razoável. O problema é que, na prática, esses métodos de separação determinam se você vai ter um modelo que generaliza ou só um que memorizou ruído. E identificar isso depois do treinamento já não adianta.

Vou explicar os métodos mais usados no dia a dia, mas também quero falar de uma coisa que quase ninguém menciona: o vazamento de informação entre train e test. Já vi gente usar StandardScaler antes da separação, o que distorce completamente a avaliação. O scaler calcula média e desvio-padrão com todos os dados, incluindo os que supostamente deveriam ficar invisíveis durante o treino. O resultado é um score inflado que não reflete performance real em produção. A correção é simples — aplica-se o scaler apenas sobre os dados de treino e depois se faz transform nos dados de teste, nunca fit. Isso é padrão, mas ainda vejo erro frequente em códigos de iniciantes e até em repositórios com boa circulação.

Conhecendo os principais métodos de separação

O train-test split é o mais básico. Você define uma proporção, geralmente 70-80% para treino e o resto para teste, e pronto. Funciona bem quando o dataset é grande e homogêneo. Se você tem menos de mil amostras, esse método já começa a apresentar instabilidade porque o conjunto de teste fica pequeno demais para ser representativo. Nesse caso, a variância da métrica de avaliação pode ser alta simplesmente por sorte ou azar na divisão. O k-fold cross-validation resolve parte desse problema. Você divide os dados em k partes iguais, treina k vezes, cada vez usando uma parte diferente como teste e o restante como treino. A média dos resultados dá uma estimativa muito mais confiável do desempenho. O valor de k geralmente fica entre 5 e 10. Para datasets pequenos, usar 10-fold é uma boa escolha. Para datasets grandes, 5-fold já entrega o mesmo nível de confiança com custo computacional menor.

O leave-one-out é um caso extremo do cross-validation onde k é igual ao número de amostras. Cada iteração usa uma única observação como teste. É preciso demais para datasets pequenos, mas se torna impraticável rapidamente — treinar 10.000 vezes para um dataset de 10 mil linhas não é algo que você faz no dia a dia. Além disso, a variância entre as folds pode ser alta porque o treino e o teste são muito parecidos em tamanho e composição. Para dados temporais, existe a time-series split. Nesse método, o conjunto de treino sempre antecede cronologicamente o conjunto de teste. Você nunca deve fazer uma separação aleatória quando trabalha com séries temporais porque isso cria vazamento de informação do futuro para o passado. Modelos treinados dessa forma parecem excelentes em backtesting e falham miseravelmente ao serem implantados. Já perdi horas tentando entender por que um modelo de previsão de demanda performava tão mal em produção até perceber que a separação aleatória estava permitindo que o modelo "visse" padrões futuros durante o treino.

Outro método útil, especialmente em classificação desbalanceada, é o stratified split. Ele preserva a proporção das classes tanto no treino quanto no teste. Se 80% dos seus dados pertencem à classe A e 20% à classe B, ambas as folds manterão essa razão. Sem isso, é comum que o conjunto de teste fique com zero ou muito poucos exemplos de uma classe rara, tornando a avaliação inviável.

Onde os métodos de separação costumam falhar

O maior problema não é escolher o método errado, mas sim aplicar o método certo aos dados errados. Grupos correlacionados dentro do dataset — múltiplas amostras da mesma pessoa, fotos do mesmo local, transações da mesma conta — precisam ser mantidos juntos nas folds. Se você separa aleatoriamente e uma pessoa aparece no treino e no teste, o modelo está sendo avaliado de forma inflada porque basicamente está reconhecendo indivíduos, não aprendendo padrões gerais. A solução é usar group-aware splitting, disponível em bibliotecas como o scikit-learn através do GroupKFold. Outro ponto cego é a separação geográfica ou por fonte de dados. Dados vindos de diferentes sensores, regiões ou plataformas podem ter distribuições ligeiramente distintas. Um modelo treinado com dados de uma fonte e testado em outra pode ter performance significativamente pior do que o esperado. Nesse cenário, o ideal é fazer uma separação por fonte, tratando cada fonte como uma fold independente.

Datasets com duplicatas ou quasi-duplicatas também exigem atenção. Antes de qualquer separação, é recomendável verificar e remover cópias exatas ou quase exatas. Modelos treinados com dados duplicados no treino e testados com versões ligeiramente modificadas dessas mesmas cópias no teste dão uma imagem distorcida da real capacidade de generalização.

Métodos avançados para cenários específicos

O Monte Carlo cross-validation, também chamado de repeated random sub-sampling, faz divisões aleatórias múltiplas e computa a média. É mais flexível que o k-fold porque permite controlar exatamente o tamanho do treino e do teste em cada repetição. Quando o dataset é muito grande e o k-fold é custoso, essa abordagem com 30 ou 50 repetições costuma ser suficiente para estabilizar a estimativa de performance. Para problemas de anomaly detection, a separação tradicional não funciona bem porque a classe minoritária (as anomalias) pode ser inteiramente ausente no conjunto de teste se a proporção for muito baixa. Nesse caso, o recomendado é usar prevalence-based splitting ou garantir, via estratificação agressiva, que pelo menos algumas anomalias estejam presentes no teste. Senão, métricas como accuracy se tornam completamente inúteis.

O temporal blind test é um método que muitos engenheiros de ML usam em produção. Em vez de usar dados passados para validar, espera-se coletar dados de um período posterior ao treino e avalia-se o modelo apenas neles. Essa é a prova mais realista, mas exige planejamento porque você não tem controle sobre quando os dados futuros estarão disponíveis. O modelo que passa no temporal blind test é, na prática, o que sobrevive em produção.

Checklist prático antes de aplicar os métodos de separação

Verifique se existem grupos lógicos no seu dados — pessoas, dispositivos, contas — e confirme que eles não serão partidos entre treino e teste. Confirme que nenhuma transformação que dependa dos dados de teste está sendo aplicada antes da separação. Remova cópias exatas ou quasi-exatas. Mantenha a proporção de classes se o problema é desbalanceado. Para séries temporais, use sempre separação cronológica. Se tiver dados de múltiplas fontes, separe por fonte e não aleatoriamente. Documente o método escolhido e os parâmetros exatos utilizados — a reprodutibilidade importa tanto quanto a precisão. A escolha do método certo de separação não garante um bom modelo, mas garante que você está medindo algo real. Métodos de separação mal aplicados produzem métricas que parecem boas mas que não significam nada fora do ambiente de desenvolvimento. O custo de descobrir isso depois da implantação é sempre maior do que o tempo gasto fazendo a separação corretamente desde o início.