Como você usa o conjunto de dados 'test' após a validação cruzada?

Em algumas palestras e tutoriais que eu já vi, eles sugerem dividir seus dados em três partes: treinamento, validação e teste. Mas não está claro como o conjunto de dados de teste deve ser usado, nem como essa abordagem é melhor do que a validação cruzada de todo o conjunto de dados.

Digamos que economizamos 20% de nossos dados como um conjunto de testes. Depois, pegamos o resto, dividimos em k dobras e, usando a validação cruzada, encontramos o modelo que faz a melhor previsão sobre dados desconhecidos desse conjunto de dados. Digamos que o melhor modelo encontrado tenha uma precisão de 75% .

Vários tutoriais e muitas perguntas em vários sites de perguntas e respostas dizem que agora podemos verificar nosso modelo em um conjunto de dados salvo (teste). Mas ainda não consigo entender exatamente como isso é feito, nem qual é o objetivo disso.

Digamos que tenhamos uma precisão de 70% no conjunto de dados de teste. Então, o que faremos a seguir? Tentamos outro modelo, e depois outro, até obtermos uma pontuação alta em nosso conjunto de dados de teste? Mas, nesse caso, parece que apenas encontraremos o modelo que se encaixa em nosso conjunto de testes limitado (apenas 20%) . Isso não significa que vamos encontrar o modelo que é melhor em geral.

Além disso, como podemos considerar esse escore como uma avaliação geral do modelo, se ele é calculado apenas em um conjunto de dados limitado? Se essa pontuação for baixa, talvez tenhamos sido azarados e selecionados dados de teste "ruins".

Por outro lado, se usarmos todos os dados que temos e escolhermos o modelo usando a validação cruzada com dobras k, encontraremos o modelo que faz a melhor previsão sobre dados desconhecidos de todo o conjunto de dados que temos.

Isso é semelhante a outra pergunta que respondi sobre validação cruzada e conjuntos de testes . O conceito principal a ser entendido aqui são conjuntos de dados independentes . Considere apenas dois cenários:

1. Se você possui muitos recursos, idealmente colecionaria um conjunto de dados e treinaria seu modelo via validação cruzada. Em seguida, você coletaria outro conjunto de dados completamente independente e testaria seu modelo. No entanto, como eu disse anteriormente, isso geralmente não é possível para muitos pesquisadores.

Agora, se eu sou um pesquisador que não tem tanta sorte, o que devo fazer? Bem, você pode tentar imitar esse cenário exato:

2. Antes de qualquer treinamento em modelo, você deve dividir seus dados e deixá-los de lado ( para nunca serem tocados durante a validação cruzada ). Isso é para simular o mesmo conjunto de dados independente mencionado no cenário ideal acima. Mesmo que provenha do mesmo conjunto de dados, o treinamento do modelo não obterá nenhuma informação dessas amostras (onde, com validação cruzada, todos os dados são usados). Depois de treinar seu modelo, você o aplicará ao seu conjunto de testes , novamente nunca visto durante o treinamento, e obterá seus resultados. Isso é feito para garantir que seu modelo seja mais generalizável e não tenha apenas aprendido seus dados.

Para resolver suas outras preocupações:

Digamos que tenhamos uma precisão de 70% no conjunto de dados de teste, então o que faremos a seguir? Tentamos outro modelo, e depois outro, até obtermos alta pontuação em nosso conjunto de dados de teste?

Mais ou menos, a idéia é que você esteja criando o melhor modelo possível a partir de seus dados e, em seguida, avaliando-o em mais alguns dados nunca antes vistos. Você pode reavaliar seu esquema de validação cruzada, mas depois de ter um modelo ajustado (por exemplo, hiper parâmetros), você está avançando com esse modelo porque foi o melhor que pôde fazer. A chave é NUNCA USAR OS DADOS DO SEU TESTE PARA AJUSTAR . Seu resultado dos dados de teste é o desempenho do seu modelo em dados 'gerais'. Replicar esse processo removeria a independência dos conjuntos de dados (que era o ponto inteiro). Isso também é abordado em outra pergunta sobre dados de teste / validação .

E também, como podemos considerar essa pontuação como uma avaliação geral do modelo, se calculada em um conjunto de dados limitado? Se essa pontuação for baixa, talvez tenhamos tido azar de selecionar dados de teste "ruins".

Isso é improvável se você tiver dividido seus dados corretamente. Você deve dividir seus dados aleatoriamente (embora potencialmente estratificados para balanceamento de classe). Se o conjunto de dados for grande o suficiente para dividir seus dados em três partes, o subconjunto de teste deverá ser grande o suficiente para que haja uma chance muito baixa de você escolher dados ruins. É mais provável que seu modelo tenha sido super ajustado.

Se tudo o que você vai fazer é treinar um modelo com configurações padrão no conjunto de dados brutos ou minimamente pré-processados ​​(por exemplo, codificação de um ponto quente e / ou remoção de NAs), você não precisa de um conjunto de testes separado, basta treinar treine o conjunto e teste no seu conjunto de validação ou, melhor ainda, treine o conjunto inteiro usando a validação cruzada para estimar seu desempenho.

No entanto, assim que seu conhecimento sobre os dados fizer com que você faça alterações em sua estratégia original, você "maculará" o resultado. Alguns exemplos incluem:

• Escolha do modelo: você testou as máquinas de logística, laço, floresta aleatória, XGBoost e de vetores de suporte e escolheu o melhor modelo

• Ajuste de parâmetros: você ajustou um XGBoost para encontrar os melhores parâmetros

• Seleção de recursos: você usou seleção reversa, algoritmo genético, boruta, etc. para escolher um subconjunto ideal de recursos para incluir em seu modelo

• Imputação ausente: você atribuiu variáveis ​​ausentes à média ou a um modelo simples baseado nas outras variáveis

• Transformação de recurso: você centralizou e dimensionou suas variáveis ​​numéricas para substituí-las por um escore z (número de desvios padrão da média)

Em todos os casos acima, o uso de um único conjunto de validação, ou mesmo a validação cruzada, não fornecerá uma estimativa realista do desempenho no mundo real, porque você está usando informações que não terá em dados futuros em sua decisão. Em vez disso, você está escolhendo o melhor modelo, os melhores hiperparâmetros, o melhor conjunto de recursos etc. para seus dados e é provável que esteja "super adaptando" sua estratégia aos dados. Para obter uma estimativa honesta do desempenho no mundo real, você precisa pontuá-lo em dados que não entraram no processo de decisão, portanto, a prática comum de usar um conjunto de testes independente, separado do seu treinamento (modelagem) e validação ( escolha de um modelo, recursos, hiperparâmetros etc.)

Como alternativa à realização de um conjunto de testes, você pode usar uma técnica chamada validação cruzada aninhada. Isso requer que você codifique toda a sua estratégia de modelagem (transformação, imputação, seleção de recurso, seleção de modelo, ajuste de hiperparâmetro) como uma função não paramétrica e, em seguida, execute a validação cruzada em toda essa função como se fosse simplesmente uma função de ajuste do modelo. Isso é difícil de fazer na maioria dos pacotes de ML, mas pode ser implementado facilmente no R com o pacote mlr usando wrappers para definir sua estratégia de treinamento e, em seguida, reamostrando seu aluno embrulhado:

https://mlr.mlr-org.com/articles/tutorial/nested_resampling.html

Estou assumindo que você está fazendo a classificação.

Pegue seus dados e divida-os em 70/30 em subconjuntos trainingData / testData. Pegue o subconjunto trainingData e divida-o novamente em subgrupos trainingData / validateData. Agora você tem 3 subconjuntos de seus dados originais - trainingData (.7 * .7), validateData (.7 * .3) e testData (.3).

Você treina seu modelo com trainingData. Em seguida, você verifica o desempenho desse modelo usando validateData, que podemos considerar independentes do trainingData e, portanto, uma boa avaliação de quão bem o modelo está generalizando. Vamos fingir que você alcança 75% de precisão.

Agora você treina seu modelo várias vezes arbitrariamente. A cada treinamento, você está avaliando um conjunto diferente de hiperparâmetros (os parâmetros que estão sendo alimentados no seu modelo em primeiro lugar versus os para os quais o modelo está otimizando), mas ainda usando o subconjunto trainingData. A cada reciclagem, você também verifica novamente a generalidade do novo modelo, verificando o desempenho em validateData.

Depois de verificar todas as combinações de hiperparâmetros que você deseja avaliar, você escolhe o conjunto de hiperparâmetros que oferece o melhor desempenho em validateData - vamos fingir que seu melhor desempenho em validateData foi de 80% de precisão. Esses são seus hiperparâmetros finais e o modelo definido por esses hiperparâmetros é o que você usará para esta próxima etapa.

Agora você pega o modelo que usa seus hiperparâmetros finais e avalia testData. É a primeira vez que testData é tocado desde que todo esse processo foi iniciado! Se você obtiver um desempenho testData comparável ao desempenho em validateData (embora geralmente seja um pouco menor), você poderá sentir-se confiante de que seu modelo funciona conforme o esperado e se generaliza bem! Se isso acontecer, este é o seu modelo final!

Por que tudo isso? Você está tentando evitar o excesso de ajustes. Sempre existe o risco de você ajustar demais os dados que usa ao treinar e ajustar (também conhecido como validar) seu modelo. Se você treinar, ajustar (validar) e testar usando apenas um conjunto de dados, há uma boa chance de você superestimar esses dados e eles não generalizarão bem. Ao separar os conjuntos de dados de treinamento e teste (e assumindo que você os ajusta usando os dados de teste), você tem a chance de verificar a si mesmo internamente, mas ainda há a chance de que você esteja apenas ajustando demais os dados de teste agora. É por isso que dividimos um terceiro conjunto de dados, validamos, para termos uma camada adicional de nos mantermos honestos internamente. Ajustar com validateData nos impede de sobreajustar para trainingData. O teste final com testData nos impede de realizar ajustes excessivos para validar os dados.

Vejamos da seguinte maneira

1. Prática comum

   a) Dados de treinamento - usados ​​para escolher os parâmetros do modelo.

    i) E.g., finding intercept and slope parameters for an ordinary linear 
       regression model. 
   
    ii) The noise in the training data-set is used in some extent 
        in over-fitting model parameters. 
   

   b) Dados de validação - utilizados para a escolha de hiper parâmetros.

    i)  E.g., we may want to test three different models at step 1.a, say 
        linear model with one, two or three variables.   
   
    ii) The validation data-set is independent from training data, and thus, they provide 
        'unbiased' evaluation to the models, which help to decide which 
        hyper-parameter to use. 
   
    iii) We note that, a model trained in 1.a, say y = b_0+b_1*x_1, does 
        not learn anything from this data-set. So, the noise in this data- 
        set is not used to over-fit the parameters (b_0, b_1), but, over- 
        fit exists in choosing which linear model to use (in terms of 
        number of variables). 
   

   c) Dados de teste - usados ​​para obter confiança na saída das duas etapas acima

   i) Used once a model is completely trained
   

2. Outra maneira de ver a parte 1

   a) Nosso pool de candidatos modelo é um conjunto de 5-dimenson, ou seja,

   i) Dimension 1: number of variables to keep in the regression model, 
      e.g., [1, 2, 3].
   
   ii) Dimension 2-5: (b_0, b_1, b_2, b_3). 
   

   b) A etapa 1a reduz os candidatos ao modelo de 5 dimensões para 1 dimensão.

   c) A Etapa 1b reduz os candidatos ao modelo de 1-dimensão para 0-dimensão, que é um modelo único.

   d) No entanto, o OP pode achar que a saída 'final' acima não está funcionando bem o suficiente no conjunto de dados de teste e, assim, refazer todo o processo novamente, digamos, usando regressão de crista em vez de regressão linear comum. Em seguida, o conjunto de dados de teste é usado várias vezes e, portanto, o ruído nesses dados pode produzir algum ajuste excessivo na decisão de usar regressão linear ou de crista.

   e) Para lidar com um conjunto de modelos de alta dimensão com parâmetros, hiperparâmetros, tipos de modelos e métodos de pré-processamento, qualquer divisão nos dados disponíveis para nós está essencialmente definindo um processo de tomada de decisão que

   i)  Sequentially reducing the model pool to zero-dimension.
   
   ii) Allocating data noise overfitting to different steps of dimension 
       reductions (overfitting the noise in the data is not avoidable but 
       could be allocated smartly). 
   

3. Conclusão e respostas à pergunta do OP

   a) Dividir duas divisões (treinamento e teste), três divisões (treinamento, validação e teste) ou maior número de divisões significa essencialmente reduzir a dimensionalidade e alocar os dados (especialmente o ruído e o risco de sobreposição).

   b) Em algum momento, você pode criar um pool de candidatos modelo 'final' e, em seguida, pode pensar em como projetar o processo de redução sequencial da dimensão, de modo que

   i) At each step of reducing the dimensions, the output is satisfactory, 
     e.g., not using just 10 data points with large noise to estimate a 
     six-parameter liner model. 
   
   ii) There are enough data for you to reduce the dimension to zero 
      finally. 
   

   c) E se você não conseguir alcançar b

   i) Use model and data insight to reduce the overall dimensionality of 
     your model pool. E.g., liner regression is sensitive to outliers thus 
     not good for data with many large outliers. 
   
   ii) Choose robust non-parametric models or models with less number of 
      parameter if possible. 
   
   iii) Smartly allocating the data available at each step of reducing the 
       dimensionality. There is some goodness of fit tests to help us decide 
       whether the data we use to train the model is enough or not.