Banyak orang menganggap rilis model itu terlalu sederhana: selesai training, upload file, tulis deskripsi, tugas selesai.
Tapi yang benar-benar pernah mengerjakan produk tahu, bagian yang paling merepotkan dari model seringkali dimulai setelah go-live.
Data diperbarui, harus training ulang; parameter diubah, perlu rilis versi baru; umpan balik pengguna menunjukkan hasilnya menurun, harus cari tahu langkah mana yang diubah. Di sini ada kontradiksi yang sering diabaikan: semua orang ingin model diperbarui dengan cepat, tapi takut sekali pembaruan bisa merusak fitur yang sebelumnya berfungsi.
Jadi, saya selalu berpikir, pengelolaan model tidak bisa sekadar jadi tempat penyimpanan. Platform yang benar-benar berguna, setidaknya harus membuat pengembang tahu setiap versi apa yang diubah, siapa yang masih menggunakan versi lama, dan apakah versi baru bisa diuji sebelum di-launch.
OpenGradient's Model Hub di sini, lebih mirip dengan sistem rilis model.
Sebuah model bisa dibuat terlebih dahulu di gudang yang independen, lalu dirilis dalam cara seperti v1.00, v1.01, v2.00 untuk berbagai rilis. Setiap versi dapat menyimpan file model, konfigurasi, dan penjelasan, bukan sekadar mengupload file baru yang langsung menimpa model lama.
Alur kerja sebenarnya juga cukup lancar.
Pengembang melatih model prediksi risiko, lalu mengekspor dalam format ONNX, membuat gudang di Model Hub dan mengupload v1.00. Kemudian bisa langsung mencoba di Playground web, memastikan input dan hasil tidak ada masalah yang mencolok, sebelum aplikasi mulai mengandalkan versi ini.
Kemudian, data training diperbarui, bisa lanjut rilis v1.01, jelaskan perubahan, dan biarkan sebagian aplikasi menguji terlebih dahulu. Versi lama tetap dipertahankan, tidak akan membuat semua produk yang menggunakannya gagal bersamaan karena satu pembaruan. Tim juga bisa menggunakan Python SDK dan CLI untuk mengupload model ke dalam alur training atau rilis mereka sendiri.
Tentu saja, seberapa bagus pun nomor versi ditulis, itu tidak bisa membuktikan bahwa model itu pasti handal. Konversi ONNX mungkin membawa perbedaan, data baru juga bisa membuat hasilnya menurun, akhirnya tetap harus bergantung pada pengujian dan hasil penggunaan yang nyata.
Tapi setidaknya, ini menyelesaikan masalah yang sangat nyata: model bukanlah file sekali pakai, melainkan perangkat lunak yang perlu dirawat dalam jangka panjang. Bisa menjelaskan setiap perubahan sering kali lebih penting daripada keramaian saat rilis pertama.
$OPG @OpenGradient #OPG
Tapi yang benar-benar pernah mengerjakan produk tahu, bagian yang paling merepotkan dari model seringkali dimulai setelah go-live.
Data diperbarui, harus training ulang; parameter diubah, perlu rilis versi baru; umpan balik pengguna menunjukkan hasilnya menurun, harus cari tahu langkah mana yang diubah. Di sini ada kontradiksi yang sering diabaikan: semua orang ingin model diperbarui dengan cepat, tapi takut sekali pembaruan bisa merusak fitur yang sebelumnya berfungsi.
Jadi, saya selalu berpikir, pengelolaan model tidak bisa sekadar jadi tempat penyimpanan. Platform yang benar-benar berguna, setidaknya harus membuat pengembang tahu setiap versi apa yang diubah, siapa yang masih menggunakan versi lama, dan apakah versi baru bisa diuji sebelum di-launch.
OpenGradient's Model Hub di sini, lebih mirip dengan sistem rilis model.
Sebuah model bisa dibuat terlebih dahulu di gudang yang independen, lalu dirilis dalam cara seperti v1.00, v1.01, v2.00 untuk berbagai rilis. Setiap versi dapat menyimpan file model, konfigurasi, dan penjelasan, bukan sekadar mengupload file baru yang langsung menimpa model lama.
Alur kerja sebenarnya juga cukup lancar.
Pengembang melatih model prediksi risiko, lalu mengekspor dalam format ONNX, membuat gudang di Model Hub dan mengupload v1.00. Kemudian bisa langsung mencoba di Playground web, memastikan input dan hasil tidak ada masalah yang mencolok, sebelum aplikasi mulai mengandalkan versi ini.
Kemudian, data training diperbarui, bisa lanjut rilis v1.01, jelaskan perubahan, dan biarkan sebagian aplikasi menguji terlebih dahulu. Versi lama tetap dipertahankan, tidak akan membuat semua produk yang menggunakannya gagal bersamaan karena satu pembaruan. Tim juga bisa menggunakan Python SDK dan CLI untuk mengupload model ke dalam alur training atau rilis mereka sendiri.
Tentu saja, seberapa bagus pun nomor versi ditulis, itu tidak bisa membuktikan bahwa model itu pasti handal. Konversi ONNX mungkin membawa perbedaan, data baru juga bisa membuat hasilnya menurun, akhirnya tetap harus bergantung pada pengujian dan hasil penggunaan yang nyata.
Tapi setidaknya, ini menyelesaikan masalah yang sangat nyata: model bukanlah file sekali pakai, melainkan perangkat lunak yang perlu dirawat dalam jangka panjang. Bisa menjelaskan setiap perubahan sering kali lebih penting daripada keramaian saat rilis pertama.
$OPG @OpenGradient #OPG
