Dlaczego tylko trzy partycje? (szkolenie, walidacja, test)

Gdy próbujesz dopasować modele do dużego zestawu danych, powszechną wskazówką jest podzielenie danych na trzy części: szkolenie, sprawdzanie poprawności i testowanie zestawu danych.

Wynika to z faktu, że modele zwykle mają trzy „poziomy” parametrów: pierwszy „parametr” to klasa modelu (np. SVM, sieć neuronowa, losowy las), drugi zestaw parametrów to parametry „regularyzacji” lub „hiperparametry” ( np. współczynnik kar lasso, wybór jądra, struktura sieci neuronowej) i trzeci zestaw są zwykle uważane za „parametry” (np. współczynniki dla zmiennych towarzyszących).

Biorąc pod uwagę klasę modelu i wybór hiperparametrów, wybiera się parametry, wybierając parametry, które minimalizują błąd w zestawie treningowym. Biorąc pod uwagę klasę modelu, dostraja się hiperparametry, minimalizując błąd w zestawie sprawdzania poprawności. Jeden wybiera klasę modelu na podstawie wydajności w zestawie testowym.

Ale dlaczego nie więcej partycji? Często można podzielić hiperparametry na dwie grupy i użyć „walidacji 1”, aby dopasować pierwszą i „walidacji 2”, aby dopasować drugą. Lub można nawet traktować rozmiar podzielonych danych treningowych / danych walidacyjnych jako hiperparametr, który należy dostroić.

Czy jest to już powszechna praktyka w niektórych aplikacjach? Czy są jakieś prace teoretyczne dotyczące optymalnego partycjonowania danych?

machine-learning model-selection data-mining charles.y.zheng
źródło

Odpowiedzi:

Po pierwsze, myślę, że mylisz się co do tych trzech partycji. Nie dokonuje się żadnych wyborów na podstawie danych testowych. Twoje algorytmy dostosowują swoje parametry na podstawie danych treningowych. Następnie uruchamiasz je na danych walidacyjnych, aby porównać algorytmy (i ich wyuczone parametry) i wybrać zwycięzcę. Następnie uruchamiasz zwycięzcę na danych testowych, aby uzyskać prognozę tego, jak dobrze sobie poradzi w prawdziwym świecie.

Nie sprawdzasz poprawności danych treningowych, ponieważ pasowałyby one do twoich modeli. Nie poprzestajesz na wyniku zwycięzcy kroku walidacji, ponieważ iteracyjnie dostosowujesz rzeczy, aby uzyskać zwycięzcę na etapie walidacji, a zatem potrzebujesz niezależnego testu (do którego specjalnie się nie dostosowywałeś), aby dać ci pomysł, jak sobie poradzisz poza bieżącą areną.

Po drugie, sądzę, że jednym z czynników ograniczających jest tutaj ilość posiadanych danych. Przez większość czasu nie chcemy nawet dzielić danych na stałe partycje, stąd CV.

Wayne
źródło

Problem koncepcyjny, jaki miałem, polega na tym, że jeśli porównujesz wystarczającą liczbę modeli, skutecznie dopasowujesz dane walidacyjne, kiedy „decydujesz o zwycięzcy” przy użyciu danych walidacyjnych. Dlatego nadal może być sens dzielenia danych sprawdzania poprawności.

charles.y.zheng

Myślę, że warstwa walidacji szkolenia i warstwa testowania walidacji służą w pewnym sensie innym celom i że ostatecznie musisz porównać modele na wspólnym zestawie walidacji, jeśli chcesz ogłosić zwycięzcę. Nie jestem więc pewien, czy dodatkowe warstwy pomagają. (Chociaż moja wiedza nie jest wystarczająco głęboka, aby naprawdę wiedzieć.) Najbliższą rzeczą, jaka przychodzi mi do głowy, jest sposób przeprowadzenia konkursu Netflix. Myślę, że użyli częściowych zestawów testowych, aby powstrzymać zespoły przed wspinaniem się na gradient zestawu testów, ale myślę, że jest inaczej.

Wayne,

@ user10882, twój komentarz jest niepoprawny, podobnie jak Firebugs. Zarówno (1) parametry modelu (wagi, progi), jak i (2) tak zwane parametry „hiper” (liczba ukrytych warstw, liczba drzew decyzyjnych) mogą mieć znacznie różną interpretację i odczucia, ale wszystkie są tylko parametrami rozróżniającymi różne modele . Użyj danych treningowych, aby je zoptymalizować, użyj danych walidacyjnych, aby uniknąć nadmiernego dopasowania i użyj weryfikacji krzyżowej, aby upewnić się, że wyniki są stabilne. Dane testowe służą jedynie do określenia oczekiwanej wydajności twojego modelu, nie używaj go do akceptowania / odrzucania.

Ytsen de Boer

n

$n$

@YtsendeBoer: Wystarczająco sprawiedliwe - jeśli użyjesz czegoś takiego jak wczesne zatrzymanie oparte na sprawdzaniu poprawności, zgadzam się, że granice się zacierają, przynajmniej w zakresie procedury optymalizacji. Moim zdaniem nie łączy to jednak w pełni pojęcia „hiperparametru” z pojęciem zwykłego. Nadal istnieje wiele sytuacji, w których są one traktowane inaczej, a także myślę o nich inaczej pod względem ich roli w definiowaniu modelu. W każdym razie mam nadzieję, że ta dyskusja była przydatna dla innych, aby zilustrować (subtelne) różnice i podobieństwa między tymi pojęciami =).

Ruben van Bergen

To interesujące pytanie, które okazało się pomocne przy odpowiedzi z @Wayne.

Z mojego zrozumienia, dzielenie zestawu danych na różne partycje zależy od celu autora i wymagań modelu w rzeczywistej aplikacji.

Zwykle mamy dwa zestawy danych: szkolenie i testowanie. Trening służy do znalezienia parametrów modeli lub dopasowania modeli. Testowy służy do oceny wydajności modelu w niewidzialnych danych (lub danych rzeczywistych).

Jeśli zrobimy tylko jeden krok w szkoleniu, oczywiste jest, że istnieje proces szkolenia i testowania (lub zatwierdzania).

Jednak w ten sposób może pojawić się problem nadmiernego dopasowania, gdy model jest trenowany z jednym zestawem danych, jednorazowo. Może to prowadzić do niestabilności modelu w rzeczywistym świecie. Jednym ze sposobów rozwiązania tego problemu jest weryfikacja krzyżowa (CV) modelu w zbiorze danych szkoleniowych. Oznacza to, że dzielimy zestaw danych treningowych na różne fałdy, zachowujemy jeden pas, aby przetestować model, który jest trenowany z innymi fałdami. Zwycięzcą jest teraz ten, który daje minimalną stratę (w oparciu o naszą własną funkcję celu) w całym procesie CV. W ten sposób możemy zagwarantować, że zminimalizujemy szansę na zbyt duże dopasowanie się do procesu treningowego i wybierzemy odpowiedniego zwycięzcę. Zestaw testowy jest ponownie używany do oceny zwycięzcy w niewidzialnych danych.

Dao Vu Hoang
źródło