Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Bei allen guten Softwareentwicklungsprojekten wird viel Energie darauf verwendet, die Apps zu testen. Wir empfehlen außerdem dringend, Ihr ML-Modell zu testen, um die Richtigkeit seiner Vorhersagen zu bestimmen.
Trainings-, Validierungs- und Testsätze
Sie sollten ein Modell mit anderen Beispielen testen als denjenigen, die zum Trainieren des Modells verwendet wurden. Wie Sie etwas später erfahren, ist ein Test mit verschiedenen Beispielen ein stärkerer Nachweis für die Eignung Ihres Modells als ein Test mit denselben Beispielen.
Woher bekommen Sie diese verschiedenen Beispiele? Beim herkömmlichen maschinellen Lernen werden diese verschiedenen Beispiele durch Aufteilen des ursprünglichen Datasets gewonnen. Sie könnten daher davon ausgehen, dass Sie den ursprünglichen Datensatz in zwei Teilmengen aufteilen sollten:
Ein Trainingssatz, mit dem das Modell trainiert wird.
Einen Testsatz zur Bewertung des trainierten Modells.
Abbildung 8 Nicht optimal aufgeteilt.
Übung: Intuition überprüfen
Angenommen, Sie trainieren mit dem Trainings- und bewerten mit dem Test-Dataset über mehrere Runden hinweg. In jeder Runde verwenden Sie die Ergebnisse des Testsatzes, um die Hyperparameter und die Funktionsgruppe zu aktualisieren. Sehen Sie etwas Falsches an diesem Ansatz? Wählen Sie nur eine Antwort aus.
Wenn Sie dieses Verfahren mehrmals wiederholen, kann das Modell implizit an die Besonderheiten des Test-Datasets angepasst werden.
Ja! Je öfter Sie denselben Testsatz verwenden, desto wahrscheinlicher ist es, dass das Modell dem Testsatz genau entspricht.
Ähnlich wie ein Lehrer, der „auf den Test hinlernt“, passt das Modell versehentlich an den Testsatz an, was es für das Modell schwieriger machen kann, sich an reale Daten anzupassen.
Dieser Ansatz ist in Ordnung. Schließlich trainieren Sie mit dem Trainingssatz und bewerten mit einem separaten Testsatz.
Es gibt hier ein kleines Problem. Überlegen Sie, was nach und nach schiefgehen könnte.
Dieser Ansatz ist rechenintensiv. Ändern Sie die Hyperparameter oder Funktionsgruppen nicht nach jeder Testrunde.
Häufige Tests sind teuer, aber entscheidend. Häufige Tests sind jedoch weitaus kostengünstiger als zusätzliche Schulungen. Die Optimierung der Hyperparameter und des Funktionsumfangs kann die Modellqualität erheblich verbessern. Planen Sie daher immer Zeit und Rechenressourcen für diese Arbeit ein.
Die Aufteilung des Datasets in zwei Sets ist eine gute Idee, aber es ist besser, den Datensatz in drei Teilmengen aufzuteilen.
Zusätzlich zum Trainings- und Testsatz gibt es einen dritten Teilsatz:
Mit einem Validierungs-Dataset werden die ersten Tests am Modell durchgeführt, während es trainiert wird.
Abbildung 9 Eine viel bessere Aufteilung.
Verwenden Sie den Validierungssatz, um die Ergebnisse aus dem Trainingssatz zu bewerten.
Wenn der Validierungssatz wiederholt gute Vorhersagen liefert, können Sie Ihr Modell mit dem Testsatz noch einmal überprüfen.
Die folgende Abbildung zeigt diesen Workflow.
In der Abbildung bedeutet „Modell optimieren“, dass alle Aspekte des Modells angepasst werden, z. B. die Lernrate, das Hinzufügen oder Entfernen von Funktionen oder das Entwerfen eines komplett neuen Modells.
Abbildung 10: Ein guter Workflow für Entwicklung und Tests.
Der in Abbildung 10 dargestellte Workflow ist optimal, aber selbst bei diesem Workflow „verschleißen“ Test- und Validierungssätze bei wiederholter Verwendung.
Je häufiger Sie dieselben Daten verwenden, um Entscheidungen über Hyperparametereinstellungen oder andere Modellverbesserungen zu treffen, desto geringer ist die Wahrscheinlichkeit, dass das Modell gute Vorhersagen für neue Daten trifft.
Aus diesem Grund ist es empfehlenswert, mehr Daten zu erheben, um den Test- und Validierungssatz zu „aktualisieren“. Ein Neustart ist eine gute Möglichkeit, einen Neuanfang zu machen.
Übung: Ihre Intuition überprüfen
Sie haben alle Beispiele im Dataset zufällig gemischt und die gemischten Beispiele in Trainings-, Validierungs- und Testsätze aufgeteilt. Der Verlustwert in Ihrem Test-Dataset ist jedoch so unglaublich niedrig, dass Sie einen Fehler vermuten. Was könnte das Problem sein?
Viele der Beispiele im Testsatz sind Duplikate von Beispielen im Trainingssatz.
Ja. Das kann bei einem Datensatz mit vielen redundanten Beispielen ein Problem sein. Wir empfehlen dringend, doppelte Beispiele vor dem Test aus dem Testsatz zu löschen.
Training und Tests sind nicht deterministisch. Manchmal ist der Testverlust zufällig sehr gering. Wiederholen Sie den Test, um das Ergebnis zu bestätigen.
Die Verluste variieren zwar bei jedem Durchlauf ein wenig, sollten aber nicht so stark schwanken, dass Sie glauben, die Lotterie des maschinellen Lernens gewonnen zu haben.
Der Testsatz enthielt zufällig Beispiele, bei denen das Modell eine gute Leistung erbrachte.
Die Beispiele wurden gut gemischt, daher ist dies äußerst unwahrscheinlich.
Weitere Probleme mit Testgruppen
Wie die vorherige Frage zeigt, können doppelte Beispiele die Modellbewertung beeinträchtigen.
Nachdem Sie ein Dataset in Trainings-, Validierungs- und Test-Datasets aufgeteilt haben, löschen Sie alle Beispiele im Validierungs- oder Test-Dataset, die Duplikate von Beispielen im Trainings-Dataset sind. Der einzige faire Test eines Modells ist der Test mit neuen Beispielen, nicht mit Duplikaten.
Angenommen, Sie haben ein Modell, das vorhersagt, ob eine E-Mail Spam ist. Als Features werden die Betreffzeile, der E-Mail-Text und die E-Mail-Adresse des Absenders verwendet.
Angenommen, Sie teilen die Daten in Trainings- und Testsätze mit einer 80:20-Aufteilung auf.
Nach dem Training erreicht das Modell eine Genauigkeit von 99% sowohl für das Trainings- als auch für das Test-Set. Sie würden wahrscheinlich eine geringere Genauigkeit für den Testsatz erwarten. Sie sehen sich die Daten noch einmal an und stellen fest, dass viele der Beispiele im Testsatz Duplikate von Beispielen im Trainingssatz sind. Das Problem ist, dass Sie vor dem Aufteilen der Daten keine doppelten Einträge für dieselbe Spam-E-Mail aus Ihrer Eingabedatenbank entfernt haben. Sie haben versehentlich einige Ihrer Testdaten für das Training verwendet.
Zusammenfassend erfüllt ein guter Test- oder Validierungssatz alle folgenden Kriterien:
Sie muss groß genug sein, um statistisch signifikante Testergebnisse zu liefern.
Repräsentativ für den gesamten Datensatz. Mit anderen Worten: Wählen Sie kein Test-Dataset mit anderen Merkmalen als das Trainings-Dataset aus.
Sie repräsentieren die realen Daten, die dem Modell im Rahmen seines Geschäftszwecks begegnen werden.
Im Trainingssatz sind keine duplizierten Beispiele vorhanden.
Übungen: Wissen testen
Welche der folgenden Aussagen ist für einen einzelnen Datensatz mit einer festen Anzahl von Beispielen richtig?
Jedes Beispiel, das zum Testen des Modells verwendet wird, ist ein Beispiel weniger, das zum Trainieren des Modells verwendet wird.
Die Aufteilung von Beispielen in Trainings-, Test- und Validierungs-Datasets ist ein Nullsummenspiel.
Das ist der zentrale Kompromiss.
Die Anzahl der Beispiele im Testsatz muss größer als die Anzahl der Beispiele im Validierungssatz sein.
Theoretisch sollten der Validierungssatz und der Testsatz dieselbe oder nahezu dieselbe Anzahl von Beispielen enthalten.
Die Anzahl der Beispiele im Testsatz muss größer sein als die Anzahl der Beispiele im Validierungs- oder Trainingssatz.
Die Anzahl der Beispiele im Trainingssatz ist in der Regel größer als die Anzahl der Beispiele im Validierungs- oder Testsatz. Es gibt jedoch keine Prozentanforderungen für die verschiedenen Sets.
Angenommen, Ihr Testsatz enthält genügend Beispiele, um einen statistisch signifikanten Test durchzuführen. Außerdem führt das Testen mit dem Testsatz zu geringen Verlusten. In der Praxis funktionierte das Modell jedoch nicht gut. Was solltest du tun?
Ermitteln Sie, inwiefern sich der ursprüngliche Datensatz von realen Daten unterscheidet.
Ja. Selbst die besten Datensätze sind nur ein Snapshot der realen Daten. Die zugrunde liegende Ground Truth ändert sich im Laufe der Zeit. Obwohl Ihr Test-Dataset mit Ihrem Trainings-Dataset gut genug übereinstimmt, um eine gute Modellqualität zu vermuten, entspricht Ihr Dataset wahrscheinlich nicht hinreichend den Realdaten.
Möglicherweise müssen Sie das Modell neu trainieren und mit einem neuen Datenpool noch einmal testen.
Testen Sie noch einmal mit demselben Test-Dataset. Die Testergebnisse könnten eine Anomalie sein.
Auch wenn ein erneuter Test zu leicht abweichenden Ergebnissen führen kann, ist diese Taktik wahrscheinlich nicht sehr hilfreich.
Wie viele Beispiele sollte der Testsatz enthalten?
Ausreichend Beispiele, um einen statistisch signifikanten Test durchzuführen.
Ja. Wie viele Beispiele sind das? Sie müssen experimentieren.
[null,null,["Zuletzt aktualisiert: 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)"]]
