Comment utilisez-vous l'ensemble de données «test» après la validation croisée?

Dans certaines conférences et tutoriels que j'ai vus, ils suggèrent de diviser vos données en trois parties: formation, validation et test. Mais il n'est pas clair comment le jeu de données de test doit être utilisé, ni comment cette approche est meilleure que la validation croisée sur l'ensemble des données.

Disons que nous avons enregistré 20% de nos données sous forme de test. Ensuite, nous prenons le reste, le divisons en k plis et, en utilisant la validation croisée, nous trouvons le modèle qui fait la meilleure prédiction sur les données inconnues de cet ensemble de données. Disons que le meilleur modèle que nous avons trouvé nous donne une précision de 75% .

Divers didacticiels et de nombreuses questions sur divers sites Web de questions et réponses indiquent que nous pouvons maintenant vérifier notre modèle sur un ensemble de données (test) enregistré. Mais je ne sais toujours pas comment cela se fait exactement, ni à quoi ça sert.

Disons que nous avons une précision de 70% sur l'ensemble de données de test. Alors, que faisons-nous ensuite? Essayons-nous un autre modèle, puis un autre, jusqu'à ce que nous obtenions un score élevé sur notre ensemble de données de test? Mais dans ce cas, il semble vraiment que nous ne trouverons que le modèle qui correspond à notre ensemble de tests limité (seulement 20%) . Cela ne signifie pas que nous trouverons le modèle qui est le mieux en général.

De plus, comment considérer ce score comme une évaluation générale du modèle, s'il n'est calculé que sur un ensemble de données limité? Si ce score est faible, nous avons peut-être été malchanceux et avons sélectionné de «mauvaises» données de test.

D'un autre côté, si nous utilisons toutes les données dont nous disposons et choisissons ensuite le modèle en utilisant la validation croisée k-fold, nous trouverons le modèle qui fait la meilleure prédiction sur les données inconnues de l' ensemble de données que nous avons.

Ceci est similaire à une autre question à laquelle j'ai répondu concernant la validation croisée et les ensembles de tests . Le concept clé à comprendre ici est des ensembles de données indépendants . Considérez seulement deux scénarios:

1. Si vous avez beaucoup de ressources, vous devriez idéalement collecter un ensemble de données et former votre modèle via une validation croisée. Ensuite, vous collecteriez un autre ensemble de données complètement indépendant et testeriez votre modèle. Cependant, comme je l'ai dit précédemment, cela n'est généralement pas possible pour de nombreux chercheurs.

Maintenant, si je suis un chercheur qui n'a pas autant de chance, que dois-je faire? Eh bien, vous pouvez essayer d'imiter ce scénario exact:

2. Avant de faire une formation sur un modèle, vous devez prendre une fraction de vos données et les laisser de côté ( pour ne jamais être touché lors de la validation croisée ). Il s'agit de simuler le même ensemble de données indépendant mentionné dans le scénario idéal ci-dessus. Même si elle provient du même ensemble de données, la formation sur le modèle ne prendra aucune information de ces échantillons (où, avec validation croisée, toutes les données sont utilisées). Une fois que vous avez formé votre modèle, vous l'appliqueriez à votre ensemble de test , encore une fois cela n'a jamais été vu pendant la formation, et obtenez vos résultats. Cela est fait pour vous assurer que votre modèle est plus généralisable et n'a pas seulement appris vos données.

Pour répondre à vos autres préoccupations:

Disons que nous avons une précision de 70% sur l'ensemble de données de test, alors que faisons-nous ensuite? Essayons-nous un autre modèle, puis un autre, jusqu'à ce que nous obtenions un score élevé sur notre ensemble de données de test?

En quelque sorte, l'idée est que vous créez le meilleur modèle possible à partir de vos données, puis que vous l'évaluez sur d'autres données qu'il n'a jamais vues auparavant. Vous pouvez réévaluer votre schéma de validation croisée, mais une fois que vous avez un modèle réglé (c.-à-d. Hyper paramètres), vous allez de l'avant avec ce modèle parce que c'était le meilleur que vous puissiez faire. La clé est de NE JAMAIS UTILISER VOS DONNÉES DE TEST POUR L'ACCORD . Votre résultat à partir des données de test est la performance de votre modèle sur les données «générales». La réplication de ce processus supprimerait l'indépendance des ensembles de données (ce qui était tout l'intérêt). Ceci est également abordé dans une autre question sur les données de test / validation .

Et aussi, comment peut-on considérer ce score comme une évaluation générale du modèle, s'il est calculé sur un ensemble de données limité? Si ce score est faible, nous n'avons peut-être pas eu de chance de sélectionner de «mauvaises» données de test.

Cela est peu probable si vous avez correctement divisé vos données. Vous devez fractionner vos données de manière aléatoire (bien que potentiellement stratifiées pour l'équilibrage des classes). Si votre ensemble de données est suffisamment grand pour que vous divisez vos données en trois parties, votre sous-ensemble de test doit être suffisamment grand pour que les chances soient très faibles de choisir des données incorrectes. Il est plus probable que votre modèle soit sur-équipé.

Si tout ce que vous allez faire est de former un modèle avec des paramètres par défaut sur l'ensemble de données brut ou prétraité au minimum (par exemple, un codage à chaud et / ou la suppression des NA), vous n'avez pas besoin d'un ensemble de test séparé, vous pouvez simplement vous entraîner sur votre entraînez-vous et testez sur votre ensemble de validation, ou mieux encore, entraînez-vous sur l'ensemble en utilisant la validation croisée pour estimer vos performances.

Cependant, dès que votre connaissance des données vous amène à apporter des modifications à votre stratégie d'origine, vous avez maintenant "entaché" votre résultat. Quelques exemples:

• Choix du modèle: Vous avez testé la logistique, le lasso, la forêt aléatoire, XGBoost et les machines à vecteurs de support et choisissez le meilleur modèle

• Réglage des paramètres: vous avez réglé un XGBoost pour trouver les hyperparamètres optimaux

• Sélection des fonctionnalités: vous avez utilisé la sélection vers l'arrière, l'algorithme génétique, le boruta, etc. pour choisir un sous-ensemble optimal de fonctionnalités à inclure dans votre modèle

• Imputation manquante: vous avez imputé des variables manquantes avec la moyenne ou avec un modèle simple basé sur les autres variables

• Transformation d'entités: vous avez centré et mis à l'échelle vos variables numériques pour les remplacer par un z-score (nombre d'écarts-types par rapport à la moyenne)

Dans tous les cas ci-dessus, l'utilisation d'un seul ensemble d'exclusion, ou même la validation croisée, ne vous donnera pas une estimation réaliste des performances réelles car vous utilisez des informations que vous n'aurez pas sur les données futures dans votre décision. Au lieu de cela, vous choisissez le meilleur modèle, les meilleurs hyperparamètres, le meilleur ensemble de fonctionnalités, etc. pour vos données, et vous risquez d'être un peu «sur-adaptant» votre stratégie à vos données. Pour obtenir une estimation honnête des performances dans le monde réel, vous devez les évaluer sur des données qui ne sont pas du tout entrées dans le processus de décision, d'où la pratique courante d'utiliser un ensemble de tests indépendant, distinct de votre formation (modélisation) et de votre validation ( choix d'un modèle, de fonctions, d'hyperparamètres, etc.).

Au lieu de proposer un ensemble de tests, vous pouvez utiliser à la place une technique appelée validation croisée imbriquée. Cela vous oblige à coder l'intégralité de votre stratégie de modélisation (transformation, imputation, sélection d'entités, sélection de modèle, réglage d'hyperparamètre) en tant que fonction non paramétrique, puis effectuer une validation croisée sur cette fonction entière comme s'il s'agissait simplement d'une fonction d'ajustement de modèle. Ceci est difficile à faire dans la plupart des packages ML, mais peut être implémenté assez facilement dans R avec le package mlr en utilisant des wrappers pour définir votre stratégie de formation, puis en rééchantillonnant votre apprenant encapsulé:

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

Je suppose que vous faites la classification.

Prenez vos données et divisez-les 70/30 en sous-ensembles trainingData / testData. Prenez le sous-ensemble trainingData et divisez-le à nouveau 70/30 en sous-ensembles trainingData / validateData. Vous disposez maintenant de 3 sous-ensembles de vos données d'origine: trainingData (.7 * .7), validateData (.7 * .3) et testData (.3).

Vous entraînez votre modèle avec trainingData. Ensuite, vous vérifiez les performances de ce modèle à l'aide de validateData, que nous pouvons considérer comme indépendant de trainingData et donc une bonne évaluation de la façon dont le modèle se généralise. Imaginons que vous atteigniez une précision de 75%.

Vous devez maintenant recycler votre modèle un nombre arbitraire de fois. À chaque reconversion, vous évaluez un ensemble différent d'hyperparamètres (les paramètres fournis à votre modèle en premier lieu par rapport à ceux que votre modèle optimise), mais vous utilisez toujours le sous-ensemble trainingData. À chaque recyclage, vous vérifiez également à nouveau dans quelle mesure le nouveau modèle se généralise en vérifiant les performances sur validateData.

Une fois que vous avez vérifié toutes les combinaisons d'hyperparamètres que vous souhaitez évaluer, vous choisissez l'ensemble d'hyperparamètres qui vous a donné les meilleures performances sur validateData - supposons que vos meilleures performances sur validateData étaient de 80% de précision. Ce sont vos hyperparamètres finaux et le modèle défini par ces hyperparamètres est celui que vous utiliserez pour cette prochaine étape.

Maintenant, prenez le modèle qui utilise vos hyperparamètres finaux et évaluez testData. C'est la première fois que testData est touché depuis que tout ce processus a commencé! Si vous obtenez des performances testData comparables à vos performances sur validateData (bien qu'elles soient généralement légèrement inférieures), vous pouvez être sûr que votre modèle fonctionne comme prévu et se généralise bien! Si cela se produit, c'est votre modèle final!

Pourquoi tout ça? Vous essayez d'éviter le sur-ajustement. Il y a toujours un risque que vous suradaptiez les données que vous utilisez lorsque vous vous entraînez et ajustez (ou validez) votre modèle. Si vous vous entraînez, ajustez (validez) et testez en utilisant un seul ensemble de données, il y a de fortes chances que vous surajustiez ces données et elles ne se généraliseront pas bien. En séparant les ensembles de données de formation et de test (et en supposant que vous syntonisez à l'aide des données de test), vous avez la possibilité de vous vérifier en interne, mais il y a toujours la possibilité que vous surévaluez simplement les données de test maintenant. C'est pourquoi nous séparons un troisième ensemble de données, validons, nous avons donc une couche supplémentaire pour nous garder honnêtes en interne. Le réglage avec validateData nous empêche de sur-adapter à trainingData. Les tests finaux avec testData nous empêchent de sur-adapter pour validerData.

Voyons cela de la façon suivante

1. Pratique courante

   a) Données d'apprentissage - utilisées pour choisir les paramètres du modèle.

    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) Données de validation - utilisées pour choisir les hyper-paramètres.

    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) Données de test - utilisées pour obtenir la confiance des résultats des deux étapes ci-dessus

   i) Used once a model is completely trained
   

2. Une autre façon de voir la partie 1

   a) Notre bassin de candidats modèles est un ensemble de 5 dimenson, c.-à-d.

   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) L'étape 1a réduit les candidats modèles de 5 dimensions à 1 dimension.

   c) L'étape 1b réduit les candidats modèles de 1 dimension à 0 dimension, ce qui correspond à un seul modèle.

   d) Cependant, le PO peut penser que la sortie «finale» ci-dessus ne fonctionne pas assez bien sur l'ensemble de données de test, et donc recommencer tout le processus, par exemple en utilisant la régression de crête au lieu de la régression linéaire ordinaire. Ensuite, l'ensemble de données de test est utilisé plusieurs fois et, par conséquent, le bruit dans ces données peut produire un surajustement pour décider d'utiliser une régression linéaire ou une régression de crête.

   e) Pour gérer un pool de modèles de grande dimension avec des paramètres, des hyperparamètres, des types de modèles et des méthodes de prétraitement, toute répartition des données à notre disposition définit essentiellement un processus décisionnel qui

   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. Conclusion et réponses à la question d'OP

   a) Deux divisions (formation et test), trois divisions (formation, validation et test) ou un nombre plus élevé de divisions visent essentiellement à réduire la dimensionnalité et à répartir les données (en particulier le bruit et le risque de sur-ajustement).

   b) À un certain stade, vous pouvez créer un pool de candidats modèle «final», puis vous pouvez réfléchir à la façon de concevoir le processus de réduction séquentielle de la dimension de telle sorte 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) Et si vous ne pouvez pas atteindre 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.