Pourquoi seulement trois partitions? (formation, validation, test)

Lorsque vous essayez d'adapter des modèles à un jeu de données volumineux, il est généralement conseillé de partitionner les données en trois parties: le jeu de données d'apprentissage, de validation et de test.

En effet, les modèles ont généralement trois "niveaux" de paramètres: le premier "paramètre" est la classe du modèle (par exemple, SVM, réseau de neurones, forêt aléatoire), le second ensemble de paramètres est constitué des paramètres de "régularisation" ou "hyperparamètres" ( par exemple le coefficient de pénalité de lasso, le choix du noyau, la structure du réseau neuronal) et le troisième ensemble sont ce qui est généralement considéré comme les "paramètres" (par exemple les coefficients pour les covariables).

A partir d'une classe de modèle et d'un choix d'hyperparamètres, on sélectionne les paramètres en choisissant les paramètres minimisant les erreurs sur le set d'apprentissage. Avec une classe de modèle, on règle les hyperparamètres en minimisant les erreurs sur le jeu de validation. On sélectionne la classe de modèle en fonction des performances sur l'ensemble de test.

Mais pourquoi pas plus de partitions? Souvent, on peut diviser les hyperparamètres en deux groupes et utiliser une "validation 1" pour s’adapter au premier et une "validation 2" pour s’adapter au second. On pourrait même considérer la taille des données d’entraînement / de validation divisée comme un hyperparamètre à ajuster.

Est-ce déjà une pratique courante dans certaines applications? Existe-t-il des travaux théoriques sur le partitionnement optimal des données?

machine-learning model-selection data-mining

— charles.y.zheng
source

Réponses:

Premièrement, je pense que vous vous trompez sur le rôle des trois partitions. Vous ne faites aucun choix en fonction des données de test. Vos algorithmes ajustent leurs paramètres en fonction des données d'apprentissage. Vous les exécutez ensuite sur les données de validation pour comparer vos algorithmes (et leurs paramètres formés) et choisir un gagnant. Vous exécutez ensuite le gagnant sur vos données de test pour vous donner une prévision de son efficacité dans le monde réel.

Vous ne validez pas les données d’entraînement car cela surchargerait vos modèles. Vous ne vous arrêtez pas au score du vainqueur de l'étape de validation car vous avez ajusté les choses de manière itérative pour obtenir un gagnant dans l'étape de validation. Vous avez donc besoin d'un test indépendant idée de comment vous allez faire en dehors de l'arène actuelle.

Deuxièmement, je pense que l’un des facteurs limitants est la quantité de données dont vous disposez. La plupart du temps, nous ne voulons même pas scinder les données en partitions fixes, d'où CV.

— Wayne
source

Le problème conceptuel que j’avais, c’est que si vous comparez suffisamment de modèles, vous vous adaptez effectivement aux données de validation lorsque vous "choisissez un gagnant" à l’aide des données de validation. Par conséquent, il peut encore être un point de partitionnement des données de validation.

— charles.y.zheng

Je pense que la couche de validation de la formation et la couche de test de validation ont des finalités différentes, et que vous devez éventuellement comparer des modèles sur un ensemble de validation commun si vous voulez déclarer un gagnant. Donc, je ne suis pas sûr que les couches supplémentaires aident. (Bien que mes connaissances ne soient pas assez approfondies pour vraiment savoir.) La suggestion la plus proche de votre suggestion est de savoir comment s'est déroulé le concours Netflix. Je crois qu'ils ont utilisé des ensembles de tests partiels pour empêcher les équipes de gravir la pente des ensembles de tests, mais je pense que c'est différent.

— Wayne

@ user10882, votre commentaire n'est pas correct, pas plus que Firebugs. Les paramètres (1) du modèle (poids, seuils) et (2) les paramètres "hyper" (nombre de couches masquées, nombre d'arbres de décision) peuvent avoir des interprétations et des sensations très différentes, mais ne sont que des paramètres distinguant différentes modèles . Utilisez les données de formation pour toutes les optimiser, utilisez les données de validation pour éviter tout sur-ajustement et utilisez la validation croisée pour vous assurer que vos résultats sont stables. Les données de test servent uniquement à spécifier les performances attendues de votre modèle, ne les utilisez pas pour l'accepter / le rejeter.

— Ytsen de Boer

@RubenvanBergen: Je comprends ce que vous dites et il est bon et utile de le signaler à user10882. Mais je soutiens toujours que c'est finalement une technicité. Supposons que vous utilisiez un algorithme de descente de gradient qui utilise les données d'apprentissage pour déduire le sens des étapes (y compris le degré polynomial ), ainsi qu'une procédure de validation ajoutant la perte de validation à la perte d'apprentissage de chaque étape de l'algorithme de descente de gradient (similaire à arrêt). Maintenant, la différence entre "normal" et "hyper" n'est plus pertinente: cela dépend de la procédure.

n

$n$

— Ytsen de Boer

@YtsendeBoer: Assez bien - si vous utilisez sth comme un arrêt précoce basé sur la validation, je suis d'accord pour dire que les limites deviennent floues, du moins en ce qui concerne la procédure d'optimisation. À mon avis, cela ne fusionne cependant pas complètement le concept d'un "hyperparamètre" avec celui d'un "normal". Il existe encore de nombreuses situations dans lesquelles ils sont traités différemment, et je les considère également différemment en termes de rôles dans la définition d'un modèle. Quoi qu’il en soit, j’espère que cette discussion a été utile à d’autres pour illustrer les différences et les similitudes (subtiles) entre ces concepts =).

— Ruben van Bergen le

C'est une question intéressante, et j'ai trouvé que c'était utile avec la réponse de @Wayne.

A ma connaissance, la division du jeu de données en une partition différente dépend du but de l'auteur et des exigences du modèle dans les applications du monde réel.

Normalement, nous avons deux problèmes: la formation et les tests. La formation est utilisée pour trouver les paramètres des modèles ou pour s’adapter aux modèles. Le test est utilisé pour évaluer les performances du modèle dans une donnée invisible (ou réelle).

Si nous ne faisons qu'une étape dans la formation, il est évident qu'il existe un processus de formation et de test (ou de validation).

Cependant, cette façon de procéder risque de poser un problème de sur-adaptation lorsque le modèle est formé avec un seul jeu de données, une fois. Cela peut entraîner une instabilité du modèle dans le problème du monde réel. Un moyen de résoudre ce problème consiste à valider le modèle dans le jeu de données d'apprentissage. Cela signifie que nous divisons le datset d'entraînement en différents plis et en gardons un pour tester le modèle formé avec d'autres plis. Le gagnant est maintenant celui qui donne le minimum de pertes (basé sur notre propre fonction objective) dans le processus de CV complet. De cette manière, nous pouvons nous assurer de minimiser les risques de sur-adaptation dans le processus de formation et de sélectionner le bon gagnant. L'ensemble de test est à nouveau utilisé pour évaluer le gagnant dans les données invisibles.

— Dao Vu Hoang
source