Panduan tambahan untuk pipeline pelatihan

Bagian ini menjelaskan pipeline pelatihan.

Mengoptimalkan pipeline input

Ringkasan: Penyebab dan intervensi pipeline terikat input sangat bergantung pada tugas. Gunakan profiler dan perhatikan masalah umum.

Gunakan profiler yang sesuai, seperti salah satu dari yang berikut, untuk mendiagnosis pipeline terikat input:

• Perfetto untuk JAX
• TensorFlow profiler untuk TensorFlow.

Pada akhirnya, penyebab dan intervensi spesifik sangat bergantung pada tugas. Pertimbangan rekayasa yang lebih luas (misalnya, meminimalkan jejak disk) dapat mengganggu performa pipeline input.

Berikut adalah penyebab umum pipeline terikat input:

• Data tidak digabungkan dengan proses pelatihan, yang menyebabkan latensi I/O. Misalnya, membaca data pelatihan melalui jaringan dapat menyebabkan latensi I/O.
• Pra-pemrosesan data online yang mahal. Pertimbangkan untuk melakukan pra-proses setelah offline dan menyimpan hasilnya.
• Batasan sinkronisasi yang tidak disengaja yang mengganggu pengambilan data pipeline data. Misalnya, saat menyinkronkan metrik antara perangkat dan host di CommonLoopUtils.

Kami menyarankan intervensi berikut untuk pipeline terikat input:

• Instrumentasi input instrumen untuk contoh pengambilan data (misalnya, tf.data.Dataset.prefetch).
• Hapus fitur dan metadata yang tidak digunakan dari setiap tahap sejak awal dalam pipeline.
• Tingkatkan replikasi jumlah tugas yang menghasilkan contoh untuk pipeline input, misalnya, dengan menggunakan layanan tf.data.

Mengevaluasi performa model

Ringkasan: Jalankan evaluasi pada ukuran batch yang lebih besar daripada pelatihan. Jalankan evaluasi pada interval langkah yang teratur, bukan interval waktu yang teratur.

Setelan evaluasi

Anda dapat menggunakan setelan berikut untuk mengevaluasi performa model Anda:

• Evaluasi online: Mengumpulkan metrik saat model menampilkan prediksi di lingkungan produksi. Evaluasi online umumnya memberikan penilaian kualitas model yang paling realistis karena cocok dengan cara model akan digunakan.
• Evaluasi offline: Mengumpulkan metrik saat model dijalankan di pelatihan offline, validasi, atau set pengujian yang mewakili lingkungan produksi. Bergantung pada masalahnya, evaluasi offline bisa jadi cukup perlu dilibatkan dan memerlukan komputasi yang mahal.
• Evaluasi berkala: Mengumpulkan metrik selama pelatihan model yang dapat menjadi proxy untuk evaluasi offline, dan/atau pada subset data yang digunakan dalam evaluasi offline. Evaluasi berkala adalah pilihan yang paling praktis dan ekonomis, tetapi mungkin tidak sepenuhnya mewakili lingkungan produksi. Usahakan untuk menggunakan proxy evaluasi offline yang sesuai, tanpa mengorbankan keandalan sinyal yang diterima selama pelatihan.

Menyiapkan evaluasi berkala

Sebaiknya jalankan evaluasi berkala selama pelatihan karena alasan berikut:

• Untuk memantau progres pelatihan secara real time.
• Untuk memfasilitasi pemilihan pos pemeriksaan model retrospektif.
• Untuk memeriksa kurva pelatihan di akhir pelatihan.

Konfigurasi yang paling sederhana adalah melakukan pelatihan dan evaluasi berkala dalam instance komputasi yang sama, secara berkala bergantian antara pelatihan dan evaluasi. Dalam hal ini, ukuran tumpukan yang digunakan untuk melakukan evaluasi setidaknya harus sebesar ukuran tumpukan yang digunakan untuk pelatihan. Ini karena Anda tidak perlu mempertahankan aktivasi model selama evaluasi, yang menurunkan persyaratan komputasi per contoh.

Lakukan evaluasi berkala dengan interval langkah teratur, bukan interval waktu. Mengevaluasi berdasarkan interval waktu dapat mempersulit interpretasi kurva pelatihan, terutama saat pelatihan dapat mengalami preemption tugas pelatihan, masalah latensi jaringan, dan sebagainya.

Periodisitas dalam metrik validasi dan pengujian (saat menggunakan set pelatihan yang diacak, set validasi, pemisahan set pengujian) dapat menunjukkan bug penerapan seperti:

• Data pengujian tumpang tindih dengan data pelatihan.
• Data pelatihan tidak diacak dengan benar.

Mengevaluasi pada interval langkah teratur dapat membuat masalah ini lebih mudah dilihat.

Batch parsial dapat terjadi saat kumpulan evaluasi tidak habis dibagi oleh ukuran batch. Pastikan contoh padding memiliki bobot yang benar (seperti pada rata-rata tertimbang dibandingkan contoh yang menghitung kerugian rata-rata selama batch) untuk mencegah fungsi kerugian bias. Sering kali, Anda dapat memberikan contoh bernilai nol.

Simpan informasi yang memadai per evaluasi untuk mendukung analisis offline. Idealnya, simpan prediksi pada pilihan masing-masing contoh karena sangat berharga untuk proses debug. Membuat artefak seperti SavedModels akan menyederhanakan pemeriksaan model ad hoc setelah tugas evaluasi selesai.

Memilih sampel untuk evaluasi berkala

Tugas evaluasi berkala mungkin tidak berjalan cukup cepat untuk menghitung metrik pada evaluasi offline penuh yang ditetapkan dalam jangka waktu yang wajar. Masalah ini sering kali memerlukan data pengambilan sampel untuk evaluasi berkala. Saat membuat set data sampel, pertimbangkan masalah dengan ukuran sampel dan masalah khusus dalam set data yang tidak seimbang.

Ukuran sampel

Periksa apakah performa yang dihitung di set data sampel yang digunakan oleh tugas berkala cocok dengan performa di seluruh set evaluasi offline; yaitu, pastikan bahwa tidak ada kemiringan antara set data sampel dan set data lengkap.

Set data yang Anda gunakan untuk evaluasi berkala harus berupa hal berikut:

• Cukup kecil untuk dengan mudah menghasilkan prediksi model secara keseluruhan.
• Cukup besar untuk melakukan kedua hal berikut:
  • Mengukur peningkatan model secara akurat; yaitu, pengukuran tidak boleh dipenuhi oleh derau label.
  • Dukung beberapa evaluasi tersebut di seluruh uji coba secara berurutan, dan tetap menghasilkan perkiraan yang akurat. Artinya, cukup besar untuk menghindari "pas" secara adaptif ke set validasi dari waktu ke waktu dengan cara yang tidak digeneralisasi ke set pengujian yang ditahan. Namun, pertimbangan ini jarang menjadi perhatian praktis.

Set data tidak seimbang

Untuk set data yang tidak seimbang, performa pada class minoritas yang langka biasanya memiliki banyak derau. Untuk set data yang hanya memiliki sedikit contoh minor, catat jumlah contoh yang diprediksi dengan benar untuk mendapatkan lebih banyak data terkait peningkatan akurasi. Misalnya, peningkatan sensitivitas .05 terdengar menarik, tetapi apakah peningkatan hanya karena satu contoh lagi sudah benar?

Menyimpan checkpoint dan memilih checkpoint terbaik secara retrospektif

Ringkasan: Jalankan pelatihan untuk jumlah langkah tetap dan secara retrospektif pilih checkpoint terbaik dari berlari.

Sebagian besar framework deep learning mendukung pemeriksaan model. Artinya, status model saat ini disimpan secara berkala ke disk. Checkpointing memungkinkan tugas pelatihan lebih tahan terhadap gangguan instance. Checkpoint terbaik sering kali bukan merupakan checkpoint terakhir, terutama saat performa set validasi tidak terus meningkat seiring waktu, tetapi mengalami fluktuasi terkait nilai tertentu.

Menyiapkan pipeline untuk melacak N pos pemeriksaan terbaik yang dilihat sejauh ini selama pelatihan. Di akhir pelatihan, pemilihan model berarti memilih checkpoint terbaik. Kami menyebut pendekatan ini pemilihan checkpoint optimal yang retrospektif. Mendukung calon penghentian awal biasanya tidak diperlukan, karena Anda telah menentukan anggaran uji coba dan mempertahankan N pos pemeriksaan terbaik yang terlihat sejauh ini.

Menyiapkan pelacakan eksperimen

Ringkasan: Saat melacak berbagai eksperimen, lacak sejumlah hal penting, seperti performa terbaik suatu checkpoint dalam studi, dan deskripsi singkat tentang studi tersebut.

Sebaiknya lacak hasil eksperimen di spreadsheet. Spreadsheet kami sering kali berisi kolom berikut:

• Nama studi
• Link ke mana pun konfigurasi studi disimpan.
• Catatan atau deskripsi singkat studi.
• Jumlah uji coba yang dijalankan
• Performa di kumpulan validasi checkpoint terbaik dalam studi ini.
• Perintah atau catatan reproduksi spesifik tentang perubahan yang belum dikirimkan diperlukan untuk meluncurkan pelatihan.

Temukan sistem pelacakan yang nyaman yang dapat menangkap setidaknya informasi di atas. Eksperimen yang tidak terlacak mungkin juga tidak ada.

Detail penerapan normalisasi batch

Ringkasan: Saat ini, Anda sering kali dapat mengganti normalisasi batch dengan LayerNorm. Namun, jika Anda tidak dapat melakukan penggantian tersebut, ada detail yang sulit saat mengubah ukuran batch atau jumlah host.

Normalisasi batch menormalkan aktivasi menggunakan rerata dan variannya di atas batch saat ini. Namun, dalam setelan multi-perangkat, statistik ini berbeda di setiap perangkat kecuali jika disinkronkan secara eksplisit. Laporan anekdot (sebagian besar di ImageNet) menunjukkan bahwa penghitungan statistik yang melakukan normalisasi ini hanya menggunakan ~64 contoh sebenarnya lebih efektif. (Lihat deskripsi Normalisasi Batch Ghost di Melatih lebih lama, menggeneralisasi lebih baik: menutup kesenjangan umumisasi dalam pelatihan batch besar jaringan neural.) Memisahkan total ukuran batch dan jumlah contoh yang digunakan untuk menghitung statistik norma batch sangat berguna untuk perbandingan ukuran tumpukan.

Penerapan normalisasi batch bayangan tidak selalu menangani dengan benar jika ukuran batch per perangkat lebih besar dari ukuran batch virtual. Dalam hal ini, Anda harus membuat subsampel batch pada setiap perangkat untuk mendapatkan jumlah contoh statistik norma batch yang tepat.

Rata-rata pergerakan eksponensial (EMA) yang digunakan dalam normalisasi batch mode pengujian hanyalah kombinasi linear dari statistik pelatihan. Oleh karena itu, Anda hanya perlu menyinkronkan EMA ini sebelum menyimpannya di checkpoint. Namun, beberapa penerapan umum normalisasi batch tidak menyinkronkan EMA ini dan hanya menyimpan EMA dari perangkat pertama.

Pertimbangan untuk pipeline multi-host

Ringkasan: untuk logging, evaluasi, RNG, checkpoint, dan sharding data, pelatihan multi-host dapat mempermudah munculnya bug.

Lakukan hal berikut untuk pipeline multi-host:

• Pastikan pipeline hanya melakukan logging dan checkpoint di satu host.
• Menyinkronkan statistik normalisasi batch di seluruh host sebelum mengevaluasi atau checkpoint.
• Lakukan sharding file data di seluruh host karena biasanya dapat meningkatkan performa.

Penting: Pastikan Anda memiliki seed RNG yang sama di seluruh host (untuk inisialisasi model), dan seed yang berbeda di seluruh host (untuk shuffling/prapemrosesan data). Oleh karena itu, pastikan untuk menandainya dengan tepat.