Panduan tambahan untuk pipeline pelatihan

Bagian ini menjelaskan pipeline pelatihan.

Mengoptimalkan pipeline input

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

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

• Perfetto untuk JAX
• TensorFlow Profiler untuk TensorFlow.

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

Berikut adalah penyebab umum pipeline terikat input:

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

Kami menyarankan intervensi berikut untuk pipeline terikat input:

• Instrument pipeline input untuk melakukan pengambilan data awal contoh (misalnya, tf.data.Dataset.prefetch).
• Hapus fitur dan metadata yang tidak digunakan dari setiap pipeline sedini mungkin.
• Tingkatkan replikasi jumlah tugas yang menghasilkan contoh untuk pipeline input, misalnya, dengan menggunakan layanan tf.data.

Mengevaluasi performa model

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

Setelan evaluasi

Anda dapat menggunakan setelan berikut untuk mengevaluasi performa model:

• Evaluasi online: Kumpulkan metrik saat model menyalurkan prediksi di lingkungan produksi. Evaluasi online umumnya memberikan penilaian kualitas model yang paling realistis karena sesuai dengan cara model akan digunakan.
• Evaluasi offline: Kumpulkan metrik saat model dijalankan pada set pelatihan, validasi, atau pengujian offline yang representatif dari lingkungan produksi. Bergantung pada masalahnya, evaluasi offline bisa cukup rumit dan memerlukan biaya komputasi yang tinggi.
• Evaluasi berkala: Kumpulkan metrik selama pelatihan model yang mungkin menjadi pengganti 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. Berusahalah untuk menggunakan proxy yang tepat untuk evaluasi offline, 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 checkpoint model retrospektif.
• Untuk memeriksa kurva pelatihan di akhir pelatihan.

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

Lakukan evaluasi berkala pada interval langkah reguler, bukan interval waktu. Evaluasi berdasarkan interval waktu dapat mempersulit penafsiran kurva pelatihan, terutama saat pelatihan mungkin mengalami gangguan tugas pelatihan, masalah latensi jaringan, dan sebagainya.

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

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

Evaluasi pada interval langkah reguler dapat mempermudah penangkapan masalah ini.

Batch parsial dapat terjadi jika set evaluasi tidak dapat dibagi dengan ukuran batch. Pastikan contoh yang diisi dengan benar diberi bobot (seperti rata-rata berbobot di atas contoh yang menghitung rata-rata kerugian di atas batch) untuk mencegah fungsi kerugian menjadi bias olehnya. Sering kali, Anda dapat memberikan bobot nol pada contoh yang diisi ini.

Simpan informasi yang memadai per evaluasi untuk mendukung analisis offline. Idealnya, simpan prediksi pada pilihan contoh individual karena prediksi tersebut sangat berharga untuk proses penelusuran bug. Membuat artefak seperti SavedModels 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 set evaluasi offline lengkap dalam waktu yang wajar. Masalah ini sering kali memerlukan pengambilan sampel data untuk evaluasi berkala. Saat membuat set data sampel, pertimbangkan masalah ukuran sampel dan masalah khusus dalam set data yang tidak seimbang.

Ukuran sampel

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

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

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

Set data tidak seimbang

Untuk set data yang tidak seimbang, performa pada kelas minoritasyang jarang sering kali tidak stabil. Untuk set data yang hanya memiliki sedikit contoh minoritas, catat jumlah contoh yang diprediksi dengan benar untuk mendapatkan lebih banyak insight tentang peningkatan akurasi. Misalnya, peningkatan sensitivitas 0,05 terdengar menarik, tetapi apakah peningkatan tersebut hanya karena satu contoh lagi yang benar?

Menyimpan checkpoint dan memilih checkpoint terbaik secara retrospektif

Ringkasan: Jalankan pelatihan untuk sejumlah langkah tetap dan pilih checkpoint terbaik dari proses tersebut secara retrospektif.

Sebagian besar framework deep learning mendukung pembuatan titik pemeriksaan model. Artinya, status model saat ini disimpan secara berkala ke disk. Checkpointing memungkinkan tugas pelatihan menjadi tangguh terhadap gangguan instance komputasi. Pos pemeriksaan terbaik sering kali bukan pos pemeriksaan terakhir, terutama jika performa set validasi tidak terus meningkat dari waktu ke waktu, tetapi berfluktuasi di sekitar nilai tertentu.

Siapkan pipeline untuk terus melacak N checkpoint terbaik yang telah dilihat sejauh ini selama pelatihan. Di akhir pelatihan, pemilihan model cukup berarti memilih checkpoint terbaik. Kami menyebut pendekatan ini sebagai pemilihan checkpoint optimal retrospektif. Biasanya tidak perlu mendukung penghentian awal prospektif, karena Anda telah menentukan anggaran uji coba sebelumnya 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 dari titik pemeriksaan dalam studi, dan deskripsi singkat tentang studi tersebut.

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

• Nama studi
• Link ke tempat penyimpanan konfigurasi untuk studi.
• Catatan atau deskripsi singkat studi.
• Jumlah uji coba yang dijalankan
• Performa pada set validasi checkpoint terbaik dalam studi.
• Perintah reproduksi spesifik atau catatan tentang perubahan yang tidak dikirimkan yang diperlukan untuk meluncurkan pelatihan.

Temukan sistem pelacakan yang mudah digunakan yang mencatat setidaknya informasi yang tercantum di atas. Eksperimen yang tidak dilacak sama saja dengan tidak ada.

Detail penerapan normalisasi batch

Ringkasan: Saat ini, Anda sering kali dapat mengganti batch normalization dengan LayerNorm, tetapi dalam kasus ketika Anda tidak dapat melakukan penggantian tersebut, ada detail rumit saat mengubah ukuran batch atau jumlah host.

Normalisasi batch menormalisasi aktivasi menggunakan mean dan variansnya di seluruh batch saat ini. Namun, dalam setelan multi-perangkat, statistik ini berbeda di setiap perangkat kecuali jika disinkronkan secara eksplisit. Laporan anekdotal (sebagian besar di ImageNet) menunjukkan bahwa menghitung statistik normalisasi ini hanya dengan menggunakan sekitar 64 contoh sebenarnya berfungsi lebih baik dalam praktiknya. (Lihat deskripsi Ghost Batch Normalization di Train longer, generalize better: closing the generalization gap in large batch training of neural networks.) Memisahkan ukuran batch total dan jumlah contoh yang digunakan untuk menghitung statistik batch norm sangat berguna untuk perbandingan ukuran batch.

Implementasi normalisasi batch hantu tidak selalu menangani dengan benar kasus saat ukuran batch per perangkat lebih besar daripada ukuran batch virtual. Dalam hal ini, Anda perlu melakukan subsampling batch di setiap perangkat untuk mendapatkan jumlah contoh statistik normalisasi batch yang tepat.

Exponential moving average (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 titik pemeriksaan. 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, pembuatan titik pemeriksaan, dan pemisahan data, pelatihan multi-host dapat mempermudah munculnya bug.

Lakukan hal berikut untuk pipeline multi-host:

• Pastikan pipeline hanya mencatat dan membuat titik pemeriksaan di satu host.
• Sinkronkan statistik normalisasi batch di seluruh host sebelum mengevaluasi atau membuat checkpoint.
• Membagi file data di seluruh host karena biasanya akan meningkatkan performa.

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