Est-il toujours préférable d'utiliser l'ensemble de données pour former le modèle final?

Une technique courante après la formation, la validation et le test du modèle préféré de Machine Learning consiste à utiliser l'ensemble de données complet, y compris le sous-ensemble de test, pour former un modèle final pour le déployer , par exemple un produit.

Ma question est: est-ce toujours le mieux de le faire? Et si les performances se détériorent réellement?

Par exemple, supposons un cas où le modèle obtient environ 65% dans la classification du sous-ensemble de tests. Cela pourrait signifier que le modèle n'est pas suffisamment formé OU que le sous-ensemble de tests se compose de valeurs aberrantes. Dans ce dernier cas, la formation du modèle final avec eux diminuerait ses performances et vous ne le découvrirez qu'après l'avoir déployé.

Reformulant ma question initiale:

Si vous aviez une démonstration ponctuelle d'un modèle , comme le déployer sur de l'électronique embarquée à bord d'une expérience de fusée coûteuse, feriez-vous confiance à un modèle qui a été recyclé avec le sous-ensemble de test à l'étape finale sans être retravaillé testé sur ses nouvelles performances?

Une fois que vous avez obtenu des hyperparamètres optimaux pour votre modèle, après la formation et la validation croisée, etc., en théorie, il est acceptable de former le modèle sur l'ensemble de données complet pour le déployer en production. En théorie, cela généralisera mieux.

CEPENDANT, vous ne pouvez plus faire de réclamations statistiques / de performances sur les données de test car vous n'avez plus de jeu de données de test.

Si vous déployez un modèle en production à l'aide de l'ensemble de données de formation et que vous connaissez les vraies valeurs de la variable cible des nouvelles données entrantes (c'est-à-dire les données sur lesquelles le modèle de production fait des prédictions), vous pouvez calculer des mesures de performances en temps réel comme ces nouvelles données sont comme des données de test (elles n'ont pas été vues par le modèle lors de la formation). À partir de ce processus, vous pouvez mettre à jour les hyperparamètres des modèles pour obtenir de meilleures performances.

Mais si vous connaissiez les valeurs cibles des nouvelles données, pourquoi former un modèle en premier lieu?

En général, je dirais que si vous avez suffisamment de données avec suffisamment de variété, mélangez et divisez les données 80:20 formation: le test devrait être suffisant pour former un modèle robuste et ne pas avoir à vous soucier des problèmes de généralisation (en supposant bien sûr que vous régularisez le modèle).

Question interessante. Personnellement, je n'ai pas vu cela pour les produits entrant en production, mais je comprends la logique.

Théoriquement, plus votre modèle déployé a vu de données, mieux cela devrait être généralisé. Donc, si vous avez formé le modèle sur l'ensemble complet de données dont vous disposez, il devrait mieux se généraliser qu'un modèle qui ne voit par exemple que des ensembles train / val (par exemple ~ 90%) à partir de l'ensemble de données complet.

Le problème avec cela (et la raison pour laquelle nous divisons les données en trains / val / tests en premier lieu!) Est que nous voulons être en mesure de faire des déclarations statistiques quant à l'exactitude des données invisibles. Dès que nous formons à nouveau un modèle sur toutes les données, il n'est plus possible de faire de telles réclamations.

[Modifier]

Voici une question connexe sur la validation croisée , où la réponse acceptée me fait des remarques similaires et mentionne d'autres façons de faire les choses.

Nous bouclons:

1. former un modèle
2. $\rightarrow$ si satisfaisant, passez à l'étape 5
3. changer de modèle
4. passez à l'étape 1
5. évaluer les performances sur l'ensemble de test
6. Présenter le modèle avec une précision de test trouvée à l'étape 5

Finalement, si vous parvenez à obtenir un bon score sur l'ensemble de test, vous pouvez prétendre qu'il se généralise bien. Donc, la question de savoir si le recyclage sur l'ensemble de données complet améliorera les performances des futures données invisibles n'est pas strictement quelque chose que vous pouvez tester. La preuve empirique d'une meilleure performance dans d'autres ensembles de problèmes connexes serait la seule source ou orientation au moment où vous devez prendre la décision.

Une vérification de la santé mentale consisterait à tester à nouveau le modèle final recyclé sur l'ensemble de test d'origine; s'attendant à ce qu'il obtienne un score plus élevé que jamais lorsque le modèle n'a vu que l'ensemble train / val, car il a effectivement vu l'ensemble de test pendant la formation. Cela ne me ferait pas croire à 100% que ce modèle final est supérieur dans tous les cas futurs, mais au moins il est aussi bon qu'il peut l'être avec les données fournies.

Peut-être y a-t-il des arguments plus rigoureux contre ce que vous dites (probablement motivés d'un point de vue académique), mais cela semble attrayant pour des applications pratiques!

Un point qui doit être souligné à propos de l'apprentissage automatique statistique est qu'il n'y a aucune garantie . Lorsque vous estimez les performances à l'aide d'un ensemble en attente, il ne s'agit que d'une estimation . Les estimations peuvent être fausses.

Cela prend un certain temps pour s'y habituer, mais c'est quelque chose avec lequel vous devrez vous familiariser. Lorsque vous dites «Et si les performances se détériorent réellement?», La réponse est sûre, cela pourrait arriver. Les performances réelles pourraient être pires que ce que vous avez estimé / prévu. Ça pourrait aussi être mieux. Les deux sont possibles. C'est inévitable. Il existe une incertitude inhérente et irréductible.

Lorsque vous évaluez les performances à l'aide d'un ensemble de tests en attente, vous utilisez des données du passé pour essayer de prédire les performances futures. Comme on dit, les performances passées ne garantissent pas les résultats futurs . C'est une réalité que nous devons simplement accepter.

Vous ne pouvez pas laisser cela vous immobiliser. Le fait qu'il soit possible de faire pire que ce que vous aviez prévu n'est pas une raison pour éviter de déployer en production un modèle formé sur les données. En particulier, il est également possible de mal faire si vous ne le faites pas. Il est possible qu'un modèle formé sur toutes les données (train + validation + test) soit pire qu'un modèle formé uniquement sur la partie train + validation. Il est également possible que ce soit mieux. Ainsi, plutôt que de rechercher une garantie, nous devons nous demander: qu'est-ce qui nous donne les meilleures chances de succès? Qu'est-ce qui est le plus susceptible d'être le plus efficace?

Et dans ce cas, lorsque vous souhaitez déployer en production, le mieux que vous puissiez faire est d'utiliser toutes les données à votre disposition. En termes de performances attendues, l'utilisation de toutes les données n'est pas pire que l'utilisation de certaines données, et peut-être mieux. Donc, vous pourriez aussi bien utiliser toutes les données à votre disposition pour former le modèle lorsque vous construisez le modèle de production. Les choses peuvent toujours mal se passer - il est toujours possible de ne pas avoir de chance, chaque fois que vous utilisez des méthodes statistiques - mais cela vous donne la meilleure chance possible pour que les choses se passent bien.

En particulier, la pratique standard est la suivante:

1. Réservez certaines de vos données dans un ensemble de tests en attente. Il n'y a pas de règle stricte sur la fraction à utiliser, mais par exemple, vous pouvez réserver 20% pour l'ensemble de test et conserver les 80% restants pour la formation et la validation. Normalement, toutes les divisions doivent être aléatoires.

2. Ensuite, utilisez les données de formation et de validation pour essayer plusieurs architectures et hyperparamètres, en expérimentant pour trouver le meilleur modèle possible. Prenez les 80% retenus pour la formation et la validation, divisez-les en un ensemble de formation et un ensemble de validation, et entraînez un modèle à l'aide de l'ensemble de formation, puis mesurez sa précision sur l'ensemble de validation. Si vous utilisez la validation croisée, vous effectuerez cette répartition plusieurs fois et calculerez la moyenne des résultats sur l'ensemble de validation; si vous ne l'êtes pas, vous effectuerez une seule répartition (par exemple, une répartition de 70% / 30% des 80%, ou quelque chose comme ça) et évaluerez les performances sur l'ensemble de validation. Si vous avez plusieurs hyperparamètres à essayer, faites-le une fois pour chaque paramètre d'hyperparamètre candidat. Si vous avez plusieurs architectures à essayer, faites-le pour chaque architecture candidate. Vous pouvez répéter cela en utilisant ce que vous '

3. Une fois satisfait, vous figez le choix de l'architecture, des hyperparamètres, etc. Votre expérimentation est maintenant terminée. Une fois que vous atteignez ce point, vous ne pouvez plus jamais essayer d'autres options (sans obtenir un nouvel ensemble de tests) - alors ne touchez pas ce point avant d'être sûr d'être prêt.

4. Lorsque vous êtes prêt, vous entraînez un modèle sur l'ensemble complet de formation + validation (que 80%) en utilisant l'architecture et les hyperparamètres que vous avez sélectionnés précédemment. Ensuite, mesurez sa précision sur l'ensemble de test retenu. C'est votre estimation / prédiction de la précision de cette approche de modélisation. Vous obtenez un seul numéro ici. Ce nombre est ce qu'il est: si vous n'êtes pas satisfait, vous ne pouvez pas revenir aux étapes 1 et 2 et faire plus d'expérimentation; ce serait invalide.

5. Enfin, pour une utilisation en production, vous pouvez former un modèle sur l'ensemble des données, formation + validation + ensemble de tests, et le mettre en production. Notez que vous ne mesurez jamais la précision de ce modèle de production, car il ne vous reste aucune donnée pour le faire; vous avez déjà utilisé toutes les données. Si vous voulez une estimation de la façon dont il fonctionnera, vous avez le droit d'utiliser la précision estimée de l'étape 4 comme prédiction de la façon dont cela fonctionnera en production, car c'est la meilleure prédiction disponible de ses performances futures. Comme toujours, il n'y a aucune garantie - c'est juste la meilleure estimation possible, compte tenu des informations dont nous disposons. Il est certainement possible que cela fasse pire que ce que vous aviez prévu, ou mieux que ce que vous aviez prévu - c'est toujours vrai.

L'une des raisons d'avoir un ensemble de données est d'éviter le sur-ajustement. Si vous utilisez la validation croisée, vous autorisez essentiellement l'ensemble de données à agir comme ensemble d'apprentissage, mais le recyclage ne vous permettra pas de valider s'il y a des signes de sur-ajustement. Je suppose que dans les deux cas (validation croisée ou recyclage avec l'ensemble des données) ne devrait pas changer radicalement votre résultat (de ma supposition sans instruction), mais vous ne serez pas en mesure de régler les hyperparamètres ou de valider les performances de votre modèle comme vous ne le faites pas avoir un ensemble de test. Que cela finisse par être meilleur, c'est difficile à dire, mais je suppose que la seule façon de savoir est de faire un A / B des deux modèles sur des données réelles au fil du temps.