Zbiory danych: dzielenie oryginalnego zbioru danych
Wszystkie dobre projekty inżynierii oprogramowania poświęcają dużo energii
testowania swoich aplikacji. I podobnie, zdecydowanie zalecamy przetestowanie
modelu ML do określania poprawności jego prognoz.
Zbiory treningowe, walidacji i testowe
Przetestuj model dla innego zbioru przykładów niż model
używanego do trenowania modelu. Za chwilę dowiesz się,
nieco później,
na różnych przykładach są silniejszym dowodem sprawności modelu niż testowanie
na tym samym zestawie przykładów.
Skąd pochodzą te różne przykłady? Tradycyjnie
w systemach uczących się
aby dostać różne przykłady, dzieląc pierwotny zbiór danych. Możesz
Załóżmy, że pierwotny zbiór danych należy podzielić na 2 podzbiory:
Załóżmy, że trenujesz na zbiorze treningowym i oceniasz go na zbiorze testowym
w kilku rundach. W każdej rundzie należy użyć wyników z zestawu testowego.
znajdziesz wskazówki, jak aktualizować hiperparametry i zestaw funkcji. Czy możesz
nie dostrzegają Państwo problemu
w takim podejściu? Wybierz tylko jedną odpowiedź.
Wykonanie wielu powtórzeń tej procedury może spowodować, że model
aby w niej pośrednio uwzględnić specyfikę zbioru testowego.
Tak. Im częściej będziesz korzystać z tego samego zestawu testowego,
tym większe prawdopodobieństwo, że model będzie ściślej dopasowany do zbioru testowego.
Tak jak nauczyciel „prowadzący do testu” model przez nieumyślne działanie.
pasuje do zestawu testowego, co może utrudnić modelowi
aby dostosować je do rzeczywistych danych.
Takie podejście jest dobre. Przecież trenujesz na
do trenowania i oceny na osobnym zbiorze testowym.
Właściwie to jest tu drobny problem. Zastanów się, co mogłoby
stopniowo pójść nie tak.
Takie podejście jest nieefektywne pod względem obliczeniowym. Nie zmieniaj
do hiperparametrów lub zestawów cech po każdej rundzie testów.
Częste testowanie jest kosztowne, ale ma kluczowe znaczenie. Jednak często
jest znacznie tańsze niż dodatkowe szkolenie. Optymalizacja w toku
hiperparametrów i zestawu cech mogą
znacznie poprawić wydajność
jakość modelu, a przez to poświęcać czas i zasoby obliczeniowe
nad tymi kwestiami.
Podzielenie zbioru danych na 2 zbiory to dobry pomysł,
lepiej podzielić zbiór danych na 3 podzbiory.
Oprócz zbioru treningowego i testowego, trzeci podzbiór to:
zestaw do walidacji,
przeprowadza wstępne testy modelu podczas jego trenowania.
.
Rysunek 9. Znacznie lepszy podział.
Użyj zestawu do walidacji, aby ocenić wyniki ze zbioru treningowego.
Po wielokrotnym użyciu zestawu do weryfikacji sugeruje, że model został
że masz dobre prognozy, użyj zestawu testowego, aby dokładnie sprawdzić model.
Poniższy rysunek sugeruje taki przepływ pracy.
Na ilustracji „Dostosowywanie modelu” oznacza dostosowywanie obiektu
– od zmiany tempa uczenia się po dodawanie i usuwanie
funkcje, aż po zaprojektowanie od zera zupełnie nowego modelu.
Na końcu przepływu pracy wybierasz model, który radzi sobie najlepiej w zbiorze testowym.
Rysunek 10. Dobry przepływ pracy przy programowaniu i testowaniu.
Optymalny przepływ pracy pokazany na rys. 10
zestawy testowe i zestawy do walidacji nadal się zużywają do wielokrotnego użytku.
Im częściej będziesz wykorzystywać te same dane przy podejmowaniu decyzji
ustawienia hiperparametrów lub inne ulepszenia modelu, tym mniejsza pewność
że będzie on
generował dobre prognozy na podstawie nowych danych.
Dlatego warto zebrać więcej danych do „odświeżenia”. test
i zestawu do walidacji. Zacznij od nowa.
Ćwiczenie: sprawdź intuicję
Wszystkie przykłady w zbiorze danych zostały przemieszane i podzielić
pomieszane przykłady do trenowania, walidacji i testów,
zestawów. Jednak wartość straty w Twoim zestawie testowym jest tak zaskakująco niska
że podejrzewam, że jest błędem. 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 zbiorze danych z dużą ilością nadmiarowych elementów,
przykłady. Zdecydowanie zalecamy usunięcie zduplikowanych przykładów z
do zbioru testowego przed rozpoczęciem testów.
Trenowanie i testy nie mają charakteru deterministycznego. Czasami przez przypadek
Wasz test jest bardzo niski. Ponownie uruchom test, aby potwierdzić
wynik.
Choć straty mogą być różne przy każdym uruchomieniu, wartość powinna być inna,
że nie udało Ci się wygrać
na loterii z systemami uczącymi się.
Przypadkowo zestaw testowy właśnie zawiera przykłady,
model miał dobre wyniki.
Przykłady zostały dobrze pomieszane, więc jest to bardzo mało prawdopodobne.
Dodatkowe problemy z zestawami testowymi
Jak widać w poprzednim pytaniu, na ocenę modelu mogą wpływać zduplikowane przykłady.
Po podzieleniu zbioru danych na zbiory do trenowania, walidacji i testowania
usuń wszystkie przykłady z zbioru do walidacji lub zbioru testowego, które są duplikatami
w zbiorze treningowym. Jedynym sprawiedliwym testem modelu jest
nowe przykłady, a nie duplikaty.
Rozważmy na przykład model, który prognozuje, czy e-mail jest spamem, wykorzystując do tego celu
tematu, treści e-maila i adresu e-mail nadawcy.
Załóżmy, że dzielisz dane na zbiory treningowe i testowe w podziale 80-20.
Po wytrenowaniu model osiąga precyzję na poziomie 99% zarówno w zbiorze treningowym, jak i
do zbioru testowego. W zbiorze testowym można się spodziewać mniejszej dokładności,
jeszcze raz przyjrzyj się danym i przekonaj się, że wiele przykładów w teście
są duplikatami przykładów w zbiorze treningowym. Problem polega na tym,
zaniedbanie usunięcia zduplikowanych wpisów pod kątem tego samego spamerskiego e-maila z wprowadzonych przez Ciebie danych
w bazie danych przed podziałem. Przypadkowo masz za sobą przeszkolenie dotyczące
danych testowych.
Podsumowując, dobry zestaw testowy lub zestaw do walidacji spełnia wszystkie
następujące kryteria:
Wystarczająco duże, aby można było uzyskać statystycznie istotne wyniki testów.
Reprezentatywny zbiór danych jako całości. Innymi słowy, nie wybieraj
zbiór testowy o innych cechach niż zbiór treningowy.
Przedstawiciel rzeczywistych danych, z którymi model będzie miał do czynienia
jako część jej celu biznesowego.
0 przykładów powielonych w zbiorze treningowym.
Ćwiczenia: sprawdź swoją wiedzę
Biorąc pod uwagę pojedynczy zbiór danych ze stałą liczbą przykładów,
Które z tych stwierdzeń jest prawdziwe?
Każdy przykład użyty w testowaniu modelu to o 1 przykład mniej.
podczas trenowania modelu.
Dzielenie przykładów na zbiory do trenowania, testów i walidacji to gra o sumie zerowej.
To jest kluczowy kompromis.
Liczba przykładów w zbiorze testowym musi być większa niż
liczby przykładów w zestawie do walidacji.
Teoretycznie zestaw do walidacji i test testowy powinny zawierać takie same wartości
jest bardzo duża.
Liczba przykładów w zbiorze testowym musi być większa niż
liczbę przykładów w zbiorze do walidacji lub w zbiorze treningowym.
Liczba przykładów w zbiorze treningowym jest zwykle większa niż
liczbę przykładów w zbiorze do walidacji lub testów; jednak
nie ma wymagań procentowych dla różnych zestawów.
Załóżmy, że Twój zestaw testowy zawiera wystarczającą liczbę przykładów, aby wykonać
testu istotnego statystycznie. Ponadto testowanie pod kątem
zbiór testowy generuje małą stratę. Model wyniósł jednak
co nie jest zgodne z rzeczywistością. Co musisz zrobić?
Ustal, czym różni się oryginalny zbiór danych od danych rzeczywistych.
Tak. Nawet najlepsze zbiory danych są tylko odzwierciedleniem rzeczywistych danych.
bazowego
dane podstawowe
zmienia się z czasem. Chociaż Twój zestaw testowy pasuje do
zestaw treningowy na tyle dobrze, aby sugerować dobrą jakość modelu,
prawdopodobnie nie pasuje do prawdziwych danych.
Może być konieczne ponowne wytrenowanie i przetestowanie z użyciem nowego zbioru danych.
Sprawdź ponownie ten sam zbiór testowy. Wyniki testu mogły mieć
anomalię.
Ponowne testowanie może dać nieco inne wyniki,
ta taktyka prawdopodobnie nie jest zbyt przydatna.
Ile przykładów powinien zawierać zestaw testowy?
wystarczającej liczby przykładów do przeprowadzenia testu istotnego statystycznie.
