Conjuntos de treino, validação e teste em Machine Learning.
Nesse pequeno artigo tratarei sobre os conceitos de dados de treino, validação e teste, e como são aplicados no Kaggle.
Introdução
No curso Introduction to Machine Learning for Coders disponibilizado pela fast.ai, Jeremy Howard afirma que generalização é a chave para o Machine Learning. Generalização se refere o quão bem o aprendizado do modelo se aplica em dados não vistos em treinamento. Logo se o modelo não generaliza não temos de fato um modelo de predição, por isso é fundamental o uso de um conjunto de teste com dados que não são utilizados no treinamento.
Como dividir os dados?
Podemos dividir os dados disponíveis em:
- Dados de treinamento: usado para treinar o modelo.
- Dados de validação: usado para comparação de diferentes modelos e hiperparâmetros.
- Dados de teste: usado para comprovar que aquele modelo realmente funciona. São dados ignorados no treinamento e no processo de escolha de hiperparâmetros.
Aleatoriedade nos conjuntos de dados
Nem sempre um conjunto de dados aleatórios é o melhor. No caso de dados temporais, se aleatoriamente fosse selecionado para o conjunto de treino dados do dia 1°, 2°, 4° e 5° e para teste dados do dia 3° não teríamos uma representação do futuro. Nesse caso o ideal é utilizar para o conjunto de validação e teste dados mais recentes.
Um exemplo básico de como poderíamos dividir um histórico de seis meses de dados:
- Dados de treino (1° mês a 4° mês)
- Dados de validação (5° mês)
- Dados de teste (6° mês) — Aqui até podemos usar os dados de validação para treinar o modelo.
Fique atento! O conjunto de validação deve ser representativo do conjunto de teste. Se no 5° mês acontecesse algum evento raro estaríamos criando um modelo enviesado para aquele acontecimento, o qual não se repetiria no futuro.
Kaggle
Geralmente no Kaggle são disponibilizados dados de treino, que contém as variáveis de independentes e a variável dependente (nosso alvo para predição), e dados de teste, que possuem somente as variáveis independentes, estes dados podem ser submetidos com nossa previsão para recebermos a pontuação do nosso modelo.
Neste caso podemos separar os dados de treino do Kaggle para criar os nossos próprios conjuntos de treino e validação. Isso é interessante por que nas competições os dados de teste são divididos em dois, um usado no cálculo da sua pontuação pública e outro para sua pontuação privada, que é apenas revelado no final da competição. Se focarmos apenas nos resultados da nossa pontuação pública podemos estar caindo em overfitting, essa é uma das razões para usar um conjunto de validação.
Além disso, com um conjunto de validação é possível realizar vários experimentos no modelo e testá-lo, coisa que não poderíamos fazer com a nossa submissão no Kaggle pois é limitada.
Porém é importante verificar se você selecionou um bom conjunto de validação, isto é, um conjunto que seja representativo do conjunto de teste. Para analisar se temos um bom conjunto de validação podemos usar a técnica que Jeremy Howard descreve na Lição 5 do Introduction to Machine Learning for Coders, seria:
- Criar n modelos com diferentes parâmetros e dados de treinamento;
- Plotar a pontuação desses modelos nos dados de teste (resultado da submissão no Kaggle) em uma coordenada e nos dados de validação na outra;
- Caso os pontos formem uma reta teremos um bom conjunto de validação, isso é uma garantia de que seu modelo funcionará bem nos dados de teste tão quanto funcionou no conjunto de validação. Caso você não tenha encontrado essa relação linear tente outro conjunto de validação.
Nem sempre a escolha de um conjunto de validação é trivial. Jeremy comenta um exemplo onde os dados de testes da competição iriam do dia 15 até 30 agosto, poderíamos pensar em conjuntos de validação que fossem de 15 de julho até 15 de agosto; 1 de julho até 15 de agosto; 15 até 30 de julho (um mês atrás). Através da análise verificou-se que o melhor conjunto era o de 15 a 30 de julho.
Entender esses conceitos é fundamental não só para competições no Kaggle mas também para problemas reais, onde perceber no final do desenvolvimento que seu modelo não generaliza pode custar muito.
Deixe comentários e sugestões para as próximas publicações!
Conexões via LinkedIn, Github.
