Zbiory danych: dzielenie oryginalnego zbioru danych

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:

Rysunek 8. Pozioma belka podzielona na 2 części: około 80% to zbiór treningowy, a około 20% to zbiór testowy.
Rysunek 8. Nie jest to optymalny podział.

 

Ćwiczenie: sprawdź swoją intuicję

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ź.
Takie podejście jest dopuszczalne. Trenujesz na zbiorze treningowym, a oceniasz na osobnym zbiorze testowym.
To podejście jest niewydajne pod względem obliczeniowym. Po każdej rundzie testów nie zmieniaj hiperparametrów ani zestawów funkcji.
Przeprowadzenie wielu rund tej procedury może spowodować, że model będzie dopasowywać się do specyfiki zestawu testowego.

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:

Rysunek 9. Pozioma belka podzielona na 3 części: 70% to zbiór treningowy, 15% – zbiór walidacyjny, a 15% – zbiór testowy
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. Diagram przepływu pracy składający się z tych etapów:
            1. Wytrenuj model na zbiorze treningowym.
            2. Ocenić model na zbiorze danych do weryfikacji.
            3. Dostosuj model na podstawie wyników uzyskanych na zbiorze walidującym.
            4. Powtarzaj kroki 1, 2 i 3, aż wybierzesz model, który najlepiej sprawdzi się na zbiorze danych do weryfikacji.
            5. Potwierdź wyniki na zestawie testów.
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?
Zestaw testów zawierał przypadki, które model dobrze rozpoznał.
Wiele przykładów w zbiorze testowym to duplikaty przykładów w zbiorze treningowym.
Trenowanie i testowanie nie są deterministyczne. Czasami z powodu przypadku strata testowa jest bardzo niska. Przeprowadź test ponownie, aby potwierdzić wynik.

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?
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 zestawie testowym musi być większa niż liczba przykładów w zestawie do walidacji.
Każdy przykład użyty do testowania modelu to o jeden przykład mniej użyty do trenowania modelu.
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.
Ponownie przetestuj ten sam zbiór testów. Wyniki testu mogły być anomalią.
Ile przykładów powinien zawierać zestaw testów?
Co najmniej 15% pierwotnego zbioru danych.
wystarczającą liczbę przykładów, aby uzyskać istotny statystycznie wynik testu.