Ich arbeite an der Spracherkennung mit Tensorflow und plane, LSTM NN mit einem Datensatz für massive Wellen zu trainieren. Aufgrund der Leistungssteigerungen plane ich, tfrecords zu verwenden. Im Internet gibt es mehrere Beispiele (z. B. Inception), in denen tfrecords-Dateien in Shards aufgeteilt sind. Meine Frage ist: Was ist der Vorteil von tfrecords-Dateien in Shards? Gibt es einen zusätzlichen Leistungsgewinn dieser Aufteilung?
Antworten:
Bei der Untersuchung der Vorteile des Aufteilens in mehrere Dateien kam die einzige vernünftige Antwort von einem der Google-Mitarbeiter.
Sie sagten, Leistungssteigerungen seien vernachlässigbar, aber ich stimme zu, dass das Teilen von Dateien hilfreich sein kann, insbesondere, wenn Sie den Datensatz an einen anderen Speicherort übertragen möchten.
Denken Sie daran, dass Sie jetzt vor dem Speichern nicht mischen müssen, da die (derzeit) empfohlene Methode zum Lesen von TFRecords eine tf.data.TFRecordDatasetsehr nützliche .shuffle()Methode implementiert .
Für diejenigen, die sich noch fragen: Es ist so, dass Sie Ihre Daten mischen können. Mit Ihren TFrecords in einer Datei können Sie die Bestellung nicht mischen. Dies ist normalerweise bei SGD erforderlich.
Mit Shards können Sie jedoch die Reihenfolge der Shards mischen, sodass Sie die Daten ungefähr so mischen können, als hätten Sie Zugriff auf die einzelnen TFRecords. Dies ist eindeutig besser als nichts, und je mehr Scherben Sie haben, desto besser ist diese Annäherung.
Die Alternative besteht darin, Ihre Daten durch Duplizieren vorab zu mischen oder TFRecords überhaupt nicht zu verwenden.
Durch das Aufteilen von TFRecord-Dateien in Shards können Sie große Datasets mischen, die nicht in den Arbeitsspeicher passen.
Stellen Sie sich vor, Sie haben Millionen von Trainingsbeispielen auf der Festplatte gespeichert und möchten sie wiederholt durch einen Trainingsprozess führen. Angenommen, Sie möchten die Daten für jede Wiederholung der Trainingsdaten (dh für jede Epoche) in einer völlig zufälligen Reihenfolge laden.
Ein Ansatz ist, eine Datei pro Trainingsbeispiel zu haben und eine Liste aller Dateinamen zu generieren. Dann mischen Sie zu Beginn jeder Epoche die Liste der Dateinamen und laden die einzelnen Dateien. Das Problem bei diesem Ansatz ist, dass Sie Millionen von Dateien von zufälligen Speicherorten auf Ihrer Festplatte laden. Dies kann insbesondere auf einer Festplatte langsam sein. Selbst ein RAID 0-Array hilft nicht bei der Geschwindigkeit, wenn Sie Millionen kleiner Dateien von zufälligen Speicherorten laden. Das Problem wird noch schlimmer, wenn Sie über eine Netzwerkverbindung auf die Dateien zugreifen.
Ein anderer Ansatz besteht darin, die Trainingsbeispiele nacheinander aus einer großen TFRecord-Datei zu lesen und die Beispiele mit einem Zufallspuffer im Speicher zu mischen. Der Zufallspuffer kann jedoch normalerweise nicht größer sein als der DDR-Speicher, der Ihrer CPU zur Verfügung steht. Wenn der Zufallspuffer erheblich kleiner ist als Ihr Dataset, werden die Daten möglicherweise nicht ausreichend gemischt. Die Daten können "lokal", aber nicht "global" gemischt werden. Das heißt, Beispiele vom Anfang des Datensatzes werden möglicherweise nicht mit Beispielen vom Ende des Datensatzes gemischt.
Eine gute Lösung besteht darin, eine ausgewogene Kombination der beiden oben genannten Ansätze zu verwenden, indem Sie Ihr Dataset in mehrere TFRecord-Dateien (so genannte Shards) aufteilen. Während jeder Epoche können Sie die Shard-Dateinamen mischen, um ein globales Mischen zu erhalten, und einen Shuffle-Puffer verwenden, um ein lokales Mischen zu erhalten. Eine gute Balance sorgt dafür, dass die Shards groß genug sind, um Probleme mit der Festplattengeschwindigkeit zu vermeiden, hält sie jedoch klein genug, um ein angemessenes Mischen durch einen Shuffle-Puffer zu ermöglichen.
Hier sind die genauen Schritte:
Das Aufteilen einer TFRecords-Datei in mehrere Shards bietet im Wesentlichen drei Vorteile:
.shuffle()Methode ist keine ideale Lösung, wenn Sie eine große tfrecord-Datei haben. Die gemischte Ausgabe hat etwas mit der ursprünglichen Reihenfolge zu tun, wenn Sie keine große Puffergröße verwenden. Ich denke, die Daten müssen vor dem Speichern auf tfrecord oder dem Aufteilen in Shards gemischt werden, wenn Sie einen großen Datensatz haben.