Zbiory danych: dzielenie oryginalnego zbioru danych
Wszystkie dobre projekty inżynierii oprogramowania poświęcają dużo czasu na testowanie aplikacji. Podobnie zalecamy przetestowanie modelu ML, aby sprawdzić poprawność 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 kilku rundach. 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.
To podejście jest odpowiednie. Trenujesz przecież 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 rozwiązaniem 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.
Na końcu tego procesu wybierasz model, który najlepiej sprawdza się na zbiorze testowym.
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 „zużywają się” 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. Zacząć 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 zaskakują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.
Trening i testowanie są niedeterministyczne. 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 treningowy, testowy i służący do walidacji usuń z zespołu testowego lub walidacyjnego wszystkie przykłady, 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 części 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 dane rzeczywistego stanu
mają tendencję do zmian w czasie. Chociaż zestaw testowy pasował do zestawu treningowego na tyle dobrze, że można było przypuszczać, że model jest dobrej jakości, to 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.
