Seleção de modelos
Um modelo adequado para uma tarefa é um que é expressivo o suficiente para englobar o conceito sendo aprendido, mas não expressivo demais a ponto de gerar sobreajustes sobre os dados disponíveis. Infelizmente, não há uma forma geral de decidir de antemão por um modelo ideal e usualmente precisamos avaliar empiricamente vários modelos e diferentes algoritmos de treinamento.
Mesmo quando decidimos por um único modelo base (e.g. redes neurais, árvores de decisão), este tipicamente terá um conjunto de hiperparâmetros que podem ser ajustados. Um hiperparâmetro é um ajuste no processo de treinamento de um modelo, em contraste aos parâmetros do modelo em si. Por exemplo, em uma árvore de decisão os parâmetros do modelo são os atributos em cada nó da árvore; hiperparâmetros são e.g. a execução ou não de poda, o tamanho máximo da árvore e a métrica de seleção de atributos (e.g. entropia vs gini).
Assim, seja por que queremos avaliar abordagens radicalmente diferentes ou por que queremos encontrar bons hiperparâmetros para um único modelo, ou ambos, precisamos de técnicas para nos ajudar a decidir pela melhor opção.
Naturalmente, precisamos decidir primeiro o que significa dizer “melhor”. Primariamente queremos modelos capazes de generalizar bem a partir dos exemplos — isto é, capazes de ter um bom desempenho segundo alguma métrica em novos exemplos. Iremos focar nesta definição, mas múltiplos outros fatores podem compor o que faz um modelo ser bom, como interpretabilidade, velocidade de treinamento ou inferência, uso de memória, ou facilidade de implementação.
A tarefa de seleção de modelos é uma extensão da tarefa de avaliação de modelos, mas possui nuances que precisam ser levadas em conta. Na forma mais simples de avaliação de um modelo, separamos um conjunto de teste disjunto do conjunto de treinamento para efetuar a avaliação. Isto é feito para obter uma melhor estimativa do desempenho do modelo, simulando a situação onde o modelo será apresentado a novos exemplos diferentes daqueles usados no treinamento. Assim, se o modelo obtiver 90% de acurácia no conjunto de teste, podemos esperar cerca de 90% de acurácia ao colocar o modelo em produção — claro, desde que o conjunto de teste seja grande o suficiente e que represente bem a distribuição de exemplos reais.
Porém, imagine que treinamos nosso modelo e obtivemos um resultado ruim no conjunto de teste. Insatisfeitos, podemos mexer nos hiperparâmetros do modelo ou do algoritmo de treinamento, talvez reduzindo o tamanho máximo da árvore ou aumentnado o número de árvores na Floresta Aleatória. Para saber se a modificação teve o efeito desejado, treinamos novamente o modelo e aplicamos no conjunto de teste. Podemos ir além e realizar uma busca por hiperparâmetros, onde testamos múltiplos valores para os hiperparâmetros. Ao final, encontramos um conjunto de hiperparâmetros que maximiza a métrica de interesse no conjunto de teste; digamos, 95% de acurácia. Podemos nos sentir tentados agora a declarar que esperamos 95% de acurácia quando colocarmos o modelo em produção, mas estaríamos errados.
A principal motivação de ter um conjunto de teste separado é garantir que a avaliação ocorre em um conjunto sem vícios, que o modelo não teve acesso durante o treinamento. Porém, se ajustamos os hiperparâmetros ou escolhemos um modelo diferente em função do conjunto de teste, estamos gerando sobreajuste neste conjunto, pelo mesmo motivo pelo qual os parâmetros do modelo se sobreajustam ao conjunto de treinamento. Neste caso, o ciclo de ajuste de modelo é maior e envolve todos modelos sendo treinados e avaliados. Apesar de nenhum modelo ter acesso aos dados de teste durante o treinamento, o processo como um todo tem este acesso.
Uma analogia que pode ajudar a compreender este fenômeno é um “campeonato de jogar moeda”. Imagine um grupo de 100 pessoas, cada uma com uma moeda não-viciada. O objetivo de cada um é obter o maior número de “coroas” lançando a moeda para cima e deixando ela cair sobre a mesa. Cada pessoa fará 10 lançamentos e anotaremos o número de coroas que cada um obteve. Com alta probabilidade, alguém obterá um número próximo de ou igual a 10 coroas. Isso significa que esta pessoa é uma melhor lançadora de moedas que os demais? Como será o desempenho dela se ela agora lançar mais 10 vezes? Devemos esperar que ela obtenha um bom desempenho novamente? Claramente não, e o problema aqui é o vício de seleção — estamos selecionando padrões originados de ruídos e que não são persistentes.
Isto significa que precisamos separar o processo de seleção do processo de avaliação do modelo. Para tanto, a maneira mais comum é criar uma divisão extra no conjunto de dados, gerando conjuntos de treinamento, validação e teste. Por vezes se chama este conjunto de validação de conjunto de desenvolvimento, ou dev.
Utiliza-se o conjunto de validação para fazer a seleção dos modelos, incluindo ajuste de hiperparâmetros. Ao fim, o modelo selecionado é aplicado ao conjunto de teste e seu desempenho então é avaliado. O desempenho obtido no conjunto de teste será o esperado em produção. Idealmente, este conjunto de teste será utilizado uma única vez por um único modelo. Múltiplos usos aumentam a contaminação incrementalmente, reduzindo nossa confiança na avaliação. O problema tende a ser maior quanto menor for o conjunto de testes.
Como ocorre na separação apenas treino-teste, temos uma troca entre dados disponíveis para treinamento (e portanto melhores modelos) e dados disponíveis para teste (e portanto uma melhor avaliação do modelo). O problema agora é exarcebado pela necessidade de separar dois conjuntos de tamanhos razoáveis. Valores comuns típicos para esta separação incluem, em percentagem, 70/15/15 ou 60/20/20. Quando se trabalha com poucos dados, retirar 30% ou 40% do treinamento pode ter um impacto considerável.
No lugar da separação treino-validação, podemos aplicar bootstraping ou K-folds, mantendo o conjunto de teste separado para avaliação. Uma alternativa é utilizar validação cruzada aninhada (nested cross-validation). A ideia é ter duas camadas de validação cruzada. Na mais interna, fazemos a seleção de modelos e, na mais externa, fazemos a avaliação.
Em resumo, o método de avaliação treino-teste é suficiente apenas se estamos treinando e avaliando um único modelo, sem qualquer ajuste de hiperparâmetro. Se desejamos ajustar hiperparâmetros, ou selecionar um entre múltiplos modelos, ou ambos, precisamos utilizar pelo menos um conjunto de validação ou, se há poucos dados, utilizar validação cruzada aninhada.
