Zbiory danych: dzielenie oryginalnego zbioru danych
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Wszystkie dobre projekty inżynierii oprogramowania poświęcają dużo czasu na testowanie aplikacji. Podobnie zdecydowanie zalecamy przetestowanie modelu ML w celu sprawdzenia poprawności jego prognoz.
Zbiory treningowe, walidacyjne i testowe
Model należy przetestować na innym zestawie przykładów niż te, które posłużyły do jego wytrenowania. Jak się dowiesz trochę później, testowanie na różnych przykładach jest lepszym dowodem na przydatność modelu niż testowanie na tym samym zbiorze przykładów.
Skąd pochodzą te przykłady? W systemach uczenia maszynowego tradycyjnie uzyskuje się te różne przykłady przez podział oryginalnego zbioru danych. Możesz więc założyć, że pierwotny zbiór danych należy podzielić na 2 podzbiory:
Załóżmy, że trenujesz na zbiorze treningowym, a ocenianie przeprowadzasz na zbiorze testowym w ciągu kilku rund. W każdej rundzie używasz wyników zbioru testowego, aby dowiedzieć się, jak zaktualizować hiperparametry i zbiór cech. Czy widzisz jakieś problemy z tym podejściem? Wybierz tylko jedną odpowiedź.
Przeprowadzenie wielu rund tej procedury może spowodować, że model będzie dopasowywać się do specyfiki zestawu testowego.
Tak. Im częściej używasz tego samego zbioru testowego,
tym bardziej prawdopodobne, że model będzie ściśle do niego pasował.
Podobnie jak nauczyciele, którzy przygotowują uczniów do testu, model nieświadomie dopasowuje się do zbioru testowego, co może utrudnić mu dopasowanie do danych rzeczywistych.
Takie podejście jest dopuszczalne. Trenujesz na zbiorze treningowym, a oceniasz na osobnym zbiorze testowym.
Właściwie jest tu drobny problem. Zastanów się, co może się stopniowo psuć.
To podejście jest niewydajne pod względem obliczeniowym. Po każdej rundzie testów nie zmieniaj hiperparametrów ani zestawów funkcji.
Częste testowanie jest kosztowne, ale niezbędne. Częste testowanie jest jednak znacznie tańsze niż dodatkowe szkolenie. Optymalizacja hiperparametrów i zestawu funkcji może znacznie poprawić jakość modelu, dlatego zawsze planuj czas i zasoby obliczeniowe na ich użycie.
Podział zbioru danych na 2 podzbiory jest dobrym pomysłem, ale lepszym podejściem jest podział zbioru danych na 3 podzbiory.
Oprócz zbioru treningowego i testowego trzecim podzbiorem jest:
Zbiór walidacyjny służy do wstępnego testowania modelu podczas jego trenowania.
Rysunek 9. znacznie lepszy podział.
Do oceny wyników ze zbioru treningowego użyj zbioru testowego.
Jeśli po wielokrotnym użyciu zestawu walidacyjnego okaże się, że model dobrze prognozuje, użyj zestawu testowego, aby jeszcze raz sprawdzić model.
Ten schemat przedstawia ten proces.
Na rysunku „dostrajanie modelu” oznacza dostosowanie dowolnego elementu modelu – od zmiany szybkości uczenia się po dodawanie i usuwanie funkcji czy projektowanie zupełnie nowego modelu od podstaw.
Rysunek 10. Dobry przepływ pracy na potrzeby programowania i testowania.
Proces pokazany na rysunku 10 jest optymalny, ale nawet w jego przypadku zbiory testowe i walidacyjne nadal się „zużywają” przy wielokrotnym użyciu.
Oznacza to, że im częściej używasz tych samych danych do podejmowania decyzji dotyczących ustawień hiperparametrów lub innych ulepszeń modelu, tym mniejsze masz przekonanie, że model będzie dobrze prognozować na podstawie nowych danych.
Dlatego warto zebrać więcej danych, aby „odświeżyć” zestaw testowy i zestaw weryfikacyjny. Początek od nowa to świetny sposób na reset.
Ćwiczenie: sprawdź swoją intuicję
Wszystkie przykłady w zbiorze zostały pomieszane i podzielone na zbiory do trenowania, walidacji i testowania. Jednak wartość utraty w przypadku zbioru testowego jest tak zdumiewająco niska, że podejrzewasz błąd. Co mogło pójść nie tak?
Wiele przykładów w zbiorze testowym to duplikaty przykładów w zbiorze treningowym.
Tak. Może to być problem w przypadku zbioru danych zawierającego wiele przykładów z dużą ilością redundancji. Zalecamy usunięcie duplikatów przykładów z zbioru danych testowych przed rozpoczęciem testowania.
Trenowanie i testowanie nie są deterministyczne. Czasami z powodu przypadku strata testowa jest bardzo niska. Przeprowadź test ponownie, aby potwierdzić wynik.
Chociaż strata może się nieco różnić przy każdym uruchomieniu, nie powinna się zmieniać tak bardzo, że będziesz mieć wrażenie, że wygrałeś los na loterii uczenia maszynowego.
Zestaw testów zawierał przypadki, które model dobrze rozpoznał.
Przykłady zostały dobrze pomieszane, więc jest to bardzo mało prawdopodobne.
Dodatkowe problemy z zestawami testów
Jak wynika z poprzedniego pytania, duplikaty przykładów mogą wpływać na ocenę modelu.
Po podzieleniu zbioru danych na zbiory do trenowania, walidacji i testowania usuń wszystkie przykłady ze zbioru do walidacji lub testowego, które są duplikatami przykładów ze zbioru treningowego. Jedynym sprawiedliwym testem modelu jest testowanie na nowych przykładach, a nie na duplikatach.
Rozważmy na przykład model, który przewiduje, czy e-mail jest spamem, wykorzystując jako cechy temat, treść e-maila i adres e-mail nadawcy.
Załóżmy, że dzielisz dane na zbiory treningowy i testowy w proporcjach 80/20.
Po trenowaniu model osiąga dokładność 99% zarówno w przypadku zbioru treningowego, jak i zbioru testowego. Prawdopodobnie oczekujesz niższej dokładności w przypadku zbioru testowego, więc ponownie analizujesz dane i odkrywasz, że wiele przykładów w tym zbiorze to duplikaty przykładów ze zbioru treningowego. Problem polega na tym, że przed podziałem danych nie usunięto z bazy danych wejściowych podwójnych wpisów dotyczących tego samego spamu. Nieumyślnie wytrenowałeś/wytrenowałaś model na niektórych danych testowych.
Podsumowując, dobry zbiór testów lub walidacji spełnia wszystkie te kryteria:
wystarczająco duży, aby uzyskać istotne statystycznie wyniki testów;
reprezentować cały zbiór danych; Innymi słowy, nie wybieraj zbioru testowego o innych właściwościach niż zbiór treningowy.
Dane reprezentatywne dla danych ze świata rzeczywistego, z którymi model będzie się spotykać w ramach swojego zastosowania biznesowego.
Brak duplikatów przykładów w zbiorze treningowym.
Ćwiczenia: sprawdź swoją wiedzę
Które z tych stwierdzeń jest prawdziwe w przypadku pojedynczego zbioru danych z ustaloną liczbą przykładów?
Każdy przykład użyty do testowania modelu to o jeden przykład mniej użyty do trenowania modelu.
Dzielenie przykładów na zestawy treningowe, testowe i walidacyjne to gra o sumie równej 0.
To jest główna kwestia.
Liczba przykładów w zestawie testowym musi być większa niż liczba przykładów w zestawie do walidacji.
Teoretycznie zbiór walidacyjny i testowy powinny zawierać mniej więcej taką samą liczbę przykładów.
Liczba przykładów w zbiorze testów musi być większa niż liczba przykładów w zbiorze do walidacji lub w zbiorze do trenowania.
Liczba przykładów w zbiorze treningowym jest zwykle większa niż liczba przykładów w zbiorze do walidacji lub testów, ale w przypadku różnych zbiorów nie ma żadnych wymagań dotyczących odsetka.
Załóżmy, że Twój zestaw testowy zawiera wystarczającą liczbę przykładów do przeprowadzenia istotnego statystycznie testu. Ponadto testowanie na zbiorze testowym daje niewielkie straty. Jednak w rzeczywistych warunkach model działał słabo. Co musisz zrobić?
Określ, na czym polega różnica między pierwotnym zbiorem danych a rzeczywistymi danymi.
Tak. Nawet najlepsze zbiory danych są tylko zbiorem informacji o rzeczywistych danych.
Podstawowe
informacje
mają tendencję do zmiany w czasie. Chociaż zestaw testowy pasował do zestawu treningowego na tyle dobrze, że sugeruje dobrą jakość modelu, Twój zbiór danych prawdopodobnie nie pasuje do rzeczywistych danych.
Być może konieczne będzie ponowne przeszkolenie modelu i przetestowanie go na nowym zbiorze danych.
Ponownie przetestuj ten sam zbiór testów. Wyniki testu mogły być anomalią.
Chociaż ponowne przetestowanie może przynieść nieco inne wyniki, ta taktyka prawdopodobnie nie będzie zbyt przydatna.
Ile przykładów powinien zawierać zestaw testów?
wystarczającą liczbę przykładów, aby uzyskać istotny statystycznie wynik testu.
Tak. Ile to przykładów? Musisz przeprowadzić eksperyment.
[null,null,["Ostatnia aktualizacja: 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)"]]
