Ensembles de données: diviser l'ensemble de données d'origine
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Tous les bons projets d'ingénierie logicielle consacrent une énergie considérable aux tests de leurs applications. De même, nous vous recommandons vivement de tester votre modèle ML pour déterminer l'exactitude de ses prédictions.
Ensembles d'entraînement, de validation et de test
Vous devez tester un modèle sur un ensemble d'exemples différent de celui utilisé pour l'entraîner. Comme vous le découvrirez un peu plus tard, les tests sur différents exemples sont une preuve plus solide de l'adéquation de votre modèle que les tests sur le même ensemble d'exemples.
D'où tenez-vous ces différents exemples ? Traditionnellement, en machine learning, vous obtenez ces différents exemples en divisant l'ensemble de données d'origine. Vous pouvez donc supposer que vous devez diviser l'ensemble de données d'origine en deux sous-ensembles:
Supposons que vous vous entraîniez sur l'ensemble d'entraînement et que vous évaluiez sur l'ensemble de test sur plusieurs séries. À chaque tour, vous utilisez les résultats de l'ensemble de test pour déterminer comment mettre à jour les hyperparamètres et l'ensemble de fonctionnalités. Voyez-vous un problème avec cette approche ? Choisissez une seule réponse.
En suivant cette procédure de nombreuses fois, le modèle risquerait de finir par se conformer implicitement aux particularités de l'ensemble de test.
Oui. Plus vous utilisez le même ensemble de test, plus le modèle est susceptible de s'adapter étroitement à l'ensemble de test.
Comme un enseignant qui "enseigne pour le test", le modèle s'adapte involontairement à l'ensemble de test, ce qui peut rendre plus difficile l'adaptation du modèle aux données réelles.
Cette approche est acceptable. Après tout, vous entraînez le modèle avec l'ensemble d'entraînement et l'évaluez avec un ensemble de test distinct.
À vrai dire, cette approche présente un petit problème. Réfléchissez à ce qui pourrait progressivement mal tourner.
Cette approche est inefficace en termes de calcul. Ne modifiez pas les hyperparamètres ni les ensembles de fonctionnalités après chaque série de tests.
Les tests fréquents sont coûteux, mais essentiels. Toutefois, les tests fréquents sont beaucoup moins coûteux que la formation supplémentaire. L'optimisation des hyperparamètres et de l'ensemble de fonctionnalités peut considérablement améliorer la qualité du modèle. Prévoyez donc toujours du temps et des ressources de calcul pour travailler sur ces éléments.
Diviser l'ensemble de données en deux ensembles est une bonne idée, mais une meilleure approche consiste à le diviser en trois sous-ensembles.
En plus de l'ensemble d'entraînement et de l'ensemble de test, le troisième sous-ensemble est le suivant:
Un ensemble de validation effectue les tests initiaux sur le modèle pendant son entraînement.
Figure 9 C'est beaucoup mieux.
Utilisez l'ensemble de validation pour évaluer les résultats de l'ensemble d'entraînement.
Une fois que l'utilisation répétée de l'ensemble de validation suggère que votre modèle effectue de bonnes prédictions, utilisez l'ensemble de test pour vérifier votre modèle.
La figure suivante suggère ce workflow.
Dans l'image, "Modifier le modèle" signifie ajuster n'importe quel aspect du modèle, qu'il s'agisse de modifier le taux d'apprentissage, d'ajouter ou de supprimer des fonctionnalités, ou de concevoir un tout nouveau modèle à partir de zéro.
Figure 10. Un bon workflow de développement et de test.
Le workflow illustré à la figure 10 est optimal, mais même avec ce workflow, les ensembles de test et les ensembles de validation perdent de leur efficacité lorsqu'ils sont utilisés de manière récurrente.
Autrement dit, plus vous utilisez les mêmes données pour prendre des décisions concernant les paramètres des hyperparamètres ou d'autres améliorations du modèle, moins vous pouvez être sûr que le modèle effectuera de bonnes prédictions sur de nouvelles données.
C'est pourquoi il est conseillé de collecter davantage de données afin d'actualiser les ensembles de test et de validation. Recommencer à zéro est un excellent moyen de repartir du bon pied.
Exercice: Vérifier votre intuition
Vous avez mélangé tous les exemples de l'ensemble de données et les avez répartis en ensembles d'entraînement, de validation et de test. Cependant, la valeur de perte de votre ensemble de test est si incroyablement faible que vous soupçonnez une erreur. D'où venait le problème ?
De nombreux exemples de l'ensemble de test sont des doublons d'exemples de l'ensemble d'entraînement.
Oui. Cela peut poser problème dans un ensemble de données contenant de nombreux exemples redondants. Nous vous recommandons vivement de supprimer les exemples en double de l'ensemble de test avant de le tester.
L'entraînement et les tests ne sont pas déterministes. Parfois, par hasard, votre perte de test est incroyablement faible. Exécutez à nouveau le test pour confirmer le résultat.
Bien que la perte varie un peu à chaque exécution, elle ne doit pas varier tellement que vous pensiez avoir gagné la loterie du machine learning.
Par hasard, l'ensemble de test contenait des exemples pour lesquels le modèle a obtenu de bons résultats.
Les exemples ont été bien mélangés, ce qui est extrêmement improbable.
Autres problèmes liés aux ensembles de tests
Comme l'illustre la question précédente, les exemples en double peuvent affecter l'évaluation du modèle.
Après avoir divisé un ensemble de données en ensembles d'entraînement, de validation et de test, supprimez tous les exemples de l'ensemble de validation ou de test qui sont des doublons d'exemples de l'ensemble d'entraînement. Le seul test équitable d'un modèle est celui qui porte sur de nouveaux exemples, et non sur des doublons.
Prenons l'exemple d'un modèle qui prédit si un e-mail est du spam, en utilisant la ligne d'objet, le corps de l'e-mail et l'adresse e-mail de l'expéditeur comme caractéristiques.
Supposons que vous diviez les données en ensembles d'entraînement et de test, selon un rapport 80-20.
À l'issue de l'entraînement, le modèle atteint une précision de 99% pour l'ensemble d'entraînement et l'ensemble de test. Vous vous attendez probablement à une précision plus faible pour l'ensemble de test. Vous examinez donc à nouveau les données et découvrez que de nombreux exemples de l'ensemble de test sont des doublons d'exemples de l'ensemble d'entraînement. Le problème est que vous avez négligé de supprimer les entrées en double pour le même e-mail de spam de votre base de données d'entrée avant de diviser les données. Vous avez effectué par inadvertance l'entraînement sur certaines de vos données de test.
En résumé, un bon ensemble de test ou d'évaluation répond à tous les critères suivants:
suffisamment important pour générer des résultats de test statistiquement pertinents ;
Représentatif de l'ensemble de données dans son ensemble. Autrement dit, ne choisissez pas un ensemble de test dont les caractéristiques sont différentes de celles de l'ensemble d'entraînement.
Représentatif des données réelles que le modèle rencontrera dans le cadre de son objectif commercial.
Aucun exemple en double dans l'ensemble d'entraînement.
Exercices: Testez vos connaissances
Étant donné un seul ensemble de données avec un nombre fixe d'exemples, laquelle des affirmations suivantes est vraie ?
Chaque exemple utilisé pour tester le modèle est un exemple de moins utilisé pour l'entraîner.
La division des exemples en ensembles d'entraînement, de test et de validation est un jeu à somme nulle.
C'est le compromis central.
Le nombre d'exemples dans l'ensemble de test doit être supérieur au nombre d'exemples dans l'ensemble de validation.
En théorie, l'ensemble de validation et l'ensemble de test doivent contenir le même nombre d'exemples, ou presque.
Le nombre d'exemples dans l'ensemble de test doit être supérieur au nombre d'exemples dans l'ensemble de validation ou d'entraînement.
Le nombre d'exemples dans l'ensemble d'entraînement est généralement supérieur au nombre d'exemples dans l'ensemble de validation ou d'entraînement. Toutefois, il n'existe aucune exigence de pourcentage pour les différents ensembles.
Supposons que votre ensemble de test contienne suffisamment d'exemples pour effectuer un test statistiquement significatif. De plus, les tests sur l'ensemble de test génèrent une faible perte. Cependant, le modèle a été peu performant dans le monde réel. Que devez-vous faire ?
Déterminez en quoi l'ensemble de données d'origine diffère des données réelles.
Oui. Même les meilleurs ensembles de données ne sont qu'un instantané des données réelles. La réalité de référence sous-jacente tend à changer au fil du temps. Bien que votre ensemble de test corresponde suffisamment à votre ensemble d'entraînement pour suggérer une bonne qualité de modèle, votre ensemble de données ne correspond probablement pas suffisamment aux données réelles.
Vous devrez peut-être réentraîner et réessayer avec un nouvel ensemble de données.
Réexécutez le test sur le même ensemble de test. Les résultats du test peuvent être une anomalie.
Bien que le nouveau test puisse donner des résultats légèrement différents, cette tactique n'est probablement pas très utile.
Combien d'exemples l'ensemble de test doit-il contenir ?
Assez d'exemples pour obtenir un test statistiquement pertinent.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/01/03 (UTC).
[null,null,["Dernière mise à jour le 2025/01/03 (UTC)."],[[["\u003cp\u003eMachine learning models should be tested against a separate dataset, called the test set, to ensure accurate predictions on unseen data.\u003c/p\u003e\n"],["\u003cp\u003eIt's recommended to split the dataset into three subsets: training, validation, and test sets, with the validation set used for initial testing during training and the test set used for final evaluation.\u003c/p\u003e\n"],["\u003cp\u003eThe validation and test sets can "wear out" with repeated use, requiring fresh data to maintain reliable evaluation results.\u003c/p\u003e\n"],["\u003cp\u003eA good test set is statistically significant, representative of the dataset and real-world data, and contains no duplicates from the training set.\u003c/p\u003e\n"],["\u003cp\u003eIt's crucial to address discrepancies between the dataset used for training and testing and the real-world data the model will encounter to achieve satisfactory real-world performance.\u003c/p\u003e\n"]]],[],null,["# Datasets: Dividing the original dataset\n\nAll good software engineering projects devote considerable energy to\n*testing* their apps. Similarly, we strongly recommend testing your\nML model to determine the correctness of its predictions.\n\nTraining, validation, and test sets\n-----------------------------------\n\nYou should test a model against a *different* set of examples than those\nused to train the model. As you'll learn\n[a little later](#additional_problems_with_test_sets), testing\non different examples is stronger proof of your model's fitness than testing\non the same set of examples.\nWhere do you get those different examples? Traditionally in machine learning,\nyou get those different examples by splitting the original dataset. You might\nassume, therefore, that you should split the original dataset into two subsets:\n\n- A [**training set**](/machine-learning/glossary#training-set) that the model trains on.\n- A [**test set**](/machine-learning/glossary#test-set) for evaluation of the trained model.\n\n**Figure 8.** Not an optimal split.\n\n### Exercise: Check your intuition\n\nSuppose you train on the training set and evaluate on the test set over multiple rounds. In each round, you use the test set results to guide how to update hyperparameters and the feature set. Can you see anything wrong with this approach? Pick only one answer. \nDoing many rounds of this procedure might cause the model to implicitly fit the peculiarities of the test set. \nYes! The more often you use the same test set, the more likely the model closely fits the test set. Like a teacher \"teaching to the test,\" the model inadvertently fits the test set, which might make it harder for the model to fit real-world data. \nThis approach is fine. After all, you're training on the training set and evaluating on a separate test set. \nActually, there's a subtle issue here. Think about what might gradually go wrong. \nThis approach is computationally inefficient. Don't change hyperparameters or feature sets after each round of testing. \nFrequent testing is expensive but critical. However, frequent testing is far less expensive than additional training. Optimizing hyperparameters and the feature set can dramatically improve model quality, so always budget time and computational resources to work on these.\n\nDividing the dataset into two sets is a decent idea, but\na better approach is to divide the dataset into *three* subsets.\nIn addition to the training set and the test set, the third subset is:\n\n- A [**validation set**](/machine-learning/glossary#validation-set) performs the initial testing on the model as it is being trained.\n\n**Figure 9.** A much better split.\n\nUse the **validation set** to evaluate results from the training set.\nAfter repeated use of the validation set suggests that your model is\nmaking good predictions, use the test set to double-check your model.\n\nThe following figure suggests this workflow.\nIn the figure, \"Tweak model\" means adjusting anything about the model\n---from changing the learning rate, to adding or removing\nfeatures, to designing a completely new model from scratch.\n**Figure 10.** A good workflow for development and testing. **Note:** When you transform a feature in your training set, you must make the *same* transformation in the validation set, test set, and real-world dataset.\n\nThe workflow shown in Figure 10 is optimal, but even with that workflow,\ntest sets and validation sets still \"wear out\" with repeated use.\nThat is, the more you use the same data to make decisions about\nhyperparameter settings or other model improvements, the less confidence\nthat the model will make good predictions on new data.\nFor this reason, it's a good idea to collect more data to \"refresh\" the test\nset and validation set. Starting anew is a great reset.\n\n### Exercise: Check your intuition\n\nYou shuffled all the examples in the dataset and divided the shuffled examples into training, validation, and test sets. However, the loss value on your test set is so staggeringly low that you suspect a mistake. What might have gone wrong? \nMany of the examples in the test set are duplicates of examples in the training set. \nYes. This can be a problem in a dataset with a lot of redundant examples. We strongly recommend deleting duplicate examples from the test set before testing. \nTraining and testing are nondeterministic. Sometimes, by chance, your test loss is incredibly low. Rerun the test to confirm the result. \nAlthough loss does vary a little on each run, it shouldn't vary so much that you think you won the machine learning lottery. \nBy chance, the test set just happened to contain examples that the model performed well on. \nThe examples were well shuffled, so this is extremely unlikely.\n\nAdditional problems with test sets\n----------------------------------\n\nAs the previous question illustrates, duplicate examples can affect model evaluation.\nAfter splitting a dataset into training, validation, and test sets,\ndelete any examples in the validation set or test set that are duplicates of\nexamples in the training set. The only fair test of a model is against\nnew examples, not duplicates.\n\nFor example, consider a model that predicts whether an email is spam, using\nthe subject line, email body, and sender's email address as features.\nSuppose you divide the data into training and test sets, with an 80-20 split.\nAfter training, the model achieves 99% precision on both the training set and\nthe test set. You'd probably expect a lower precision on the test set, so you\ntake another look at the data and discover that many of the examples in the test\nset are duplicates of examples in the training set. The problem is that you\nneglected to scrub duplicate entries for the same spam email from your input\ndatabase before splitting the data. You've inadvertently trained on some of\nyour test data.\n\nIn summary, a good test set or validation set meets all of the\nfollowing criteria:\n\n- Large enough to yield statistically significant testing results.\n- Representative of the dataset as a whole. In other words, don't pick a test set with different characteristics than the training set.\n- Representative of the real-world data that the model will encounter as part of its business purpose.\n- Zero examples duplicated in the training set.\n\n### Exercises: Check your understanding\n\nGiven a single dataset with a fixed number of examples, which of the following statements is true? \nEvery example used in testing the model is one less example used in training the model. \nDividing examples into train/test/validation sets is a zero-sum game. This is the central trade-off. \nThe number of examples in the test set must be greater than the number of examples in the validation set. \nIn theory, the validation set and test test should contain the same number of examples or nearly so. \nThe number of examples in the test set must be greater than the number of examples in the validation set or training set. \nThe number of examples in the training set is usually greater than the number of examples in the validation set or test set; however, there are no percentage requirements for the different sets. \nSuppose your test set contains enough examples to perform a statistically significant test. Furthermore, testing against the test set yields low loss. However, the model performed poorly in the real world. What should you do? \nDetermine how the original dataset differs from real-life data. \nYes. Even the best datasets are only a snapshot of real-life data; the underlying [ground truth](/machine-learning/glossary#ground-truth) tends to change over time. Although your test set matched your training set well enough to suggest good model quality, your dataset probably doesn't adequately match real-world data. You might have to retrain and retest against a new dataset. \nRetest on the same test set. The test results might have been an anomaly. \nAlthough retesting might yield slightly different results, this tactic probably isn't very helpful. \nHow many examples should the test set contain? \nEnough examples to yield a statistically significant test. \nYes. How many examples is that? You'll need to experiment. \nAt least 15% of the original dataset. \n15% may or may not be enough examples.\n| **Key terms:**\n|\n| - [Test set](/machine-learning/glossary#test-set)\n| - [Training set](/machine-learning/glossary#training-set)\n- [Validation set](/machine-learning/glossary#validation_set) \n[Help Center](https://support.google.com/machinelearningeducation)"]]