Pracuję nad rozpoznawaniem mowy z Tensorflow i planuję trenować LSTM NN z zestawem danych masywnych fal. Ze względu na wzrost wydajności planuję używać tfrecords. Istnieje kilka przykładów w Internecie (Inception na przykład.), W których pliki tfrecords są podzielone na odłamki. Moje pytanie brzmi: jaka jest korzyść z pliku tfrecords w odłamki? Czy jest jakiś dodatkowy wzrost wydajności tego podziału?
Odpowiedzi:
Badając zalety dzielenia na wiele plików, jedyna rozsądna odpowiedź nadeszła od jednego z pracowników Google.
Powiedzieli, że wzrost wydajności jest znikomy, ale zgadzam się, że dzielenie plików może pomóc, zwłaszcza jeśli chcesz przenieść zestaw danych do innej lokalizacji.
Należy pamiętać, że teraz nie trzeba tasować przed zapisaniem, ponieważ (obecnie) zalecana metoda odczytu zastosowań TFRecords, tf.data.TFRecordDatasetktóra implementuje bardzo przydatną .shuffle()metodę.
Dla tych, którzy nadal się zastanawiają: możesz tasować swoje dane. Dzięki TFrecords w jednym pliku nie można losowo zmieniać kolejności. Jest to zwykle konieczne w przypadku SGD.
Jednak w przypadku odłamków można zmieniać kolejność odłamków, co pozwala przybliżać tasowanie danych tak, jakbyś miał dostęp do poszczególnych rekordów TFR. Jest to wyraźnie lepsze niż nic, a im więcej odłamków masz, tym lepsze jest to przybliżenie.
Alternatywą jest wstępne pomieszanie danych poprzez ich powielenie lub całkowite nieużywanie TFRecords.
Dzielenie plików TFRecord na odłamki pomaga tasować duże zestawy danych, które nie mieszczą się w pamięci.
Wyobraź sobie, że masz zapisane miliony przykładów szkoleń na dysku i chcesz je wielokrotnie przeprowadzać podczas procesu szkolenia. Ponadto załóżmy, że dla każdego powtórzenia danych treningowych (tj. Każdej epoki) chcesz załadować dane w całkowicie losowej kolejności.
Jednym z podejść jest posiadanie jednego pliku na przykład szkolenia i generowanie listy wszystkich nazw plików. Następnie na początku każdej epoki tasujesz listę nazw plików i ładujesz poszczególne pliki. Problem z tym podejściem polega na tym, że ładujesz miliony plików z losowych lokalizacji na dysku. Może to być powolne, szczególnie na dysku twardym. Nawet macierz RAID 0 nie pomoże w szybkości, jeśli ładujesz miliony małych plików z losowych lokalizacji. Problem staje się jeszcze poważniejszy, jeśli uzyskujesz dostęp do plików przez połączenie sieciowe.
Innym podejściem jest odczytywanie przykładów treningu w jednym dużym pliku TFRecord i tasowanie przykładów w pamięci za pomocą bufora losowego. Jednak bufor losowy zwykle nie może być większy niż pamięć DDR dostępna dla procesora. A jeśli bufor losowy jest znacznie mniejszy niż zestaw danych, może on nie przetasować danych w odpowiedni sposób. Dane mogą być tasowane „lokalnie”, ale nie tasowane „globalnie”. Oznacza to, że przykładów z początku zestawu danych nie można tasować z przykładami z końca zestawu danych.
Dobrym rozwiązaniem jest użycie zrównoważonej kombinacji powyższych dwóch podejść poprzez podzielenie zestawu danych na wiele plików TFRecord (zwanych odłamkami). Podczas każdej epoki możesz losowo zmieniać nazwy plików odłamków, aby uzyskać losowe tasowanie globalne, i użyć bufora losowego, aby uzyskać lokalne losowanie. Dobra równowaga sprawi, że odłamki będą wystarczająco duże, aby zapobiec problemom z prędkością dysku, ale utrzymają odłamki na tyle małe, aby umożliwić odpowiednie przetasowanie przez bufor losowy.
Oto dokładne kroki:
Dzielenie pliku TFRecords na wiele niezależnych fragmentów ma zasadniczo 3 zalety:
.shuffle()Metoda nie jest idealnym rozwiązaniem, jeśli masz jeden duży plik tfrecord. Przetasowane dane wyjściowe są nieco związane z pierwotną kolejnością, jeśli nie używasz dużego rozmiaru bufora. Myślę, że wstępne przetasowanie danych przed zapisaniem do tfrecord lub podzieleniem na odłamki jest konieczne, gdy masz duży zestaw danych.