Selama satu setengah tahun, saya telah memegang posisi pengembang ML utama di perusahaan saya. Enam bulan saya mengelola tim kecil. Saya mendapatkan pengalaman yang ingin saya bagikan. Saya akan melakukan ini dalam format kesalahan teratas dan potensi kesulitan.
Kami menginginkan jaringan saraf!
Banyak orang telah mendengar setidaknya sesuatu tentang kecerdasan buatan dan pencapaian jaringan saraf. Beberapa orang ingin menggunakan jaringan saraf dalam bisnis hanya karena itu populer. Jadi, Anda telah menyelesaikan beberapa tugas kecil analisis teks dan Anda dapat dengan aman menyatakan kepada semua orang bahwa bisnis Anda menggunakan teknologi kecerdasan buatan paling modern.
Selain itu, hampir tidak ada yang memahami kekuatan dan kelemahan jaringan saraf. Memang, karena konsumsi sumber daya yang tinggi, mereka jauh dari model yang optimal.
Cukup sering, algoritma seperti meningkatkan, tetangga terdekat atau svm dapat menunjukkan indikator kualitas yang lebih tinggi dalam memecahkan masalah bisnis (jika kita berbicara tentang fitur skrip klasik -> nilai) daripada jaringan saraf. Ini terlepas dari kenyataan bahwa mereka jauh lebih ringan.
Jika klien memberi tahu Anda: "Kami membutuhkan jaringan saraf untuk menyelesaikan masalah ini dan itu," maka kemungkinan besar ia tidak tahu alat apa yang terbaik untuk menyelesaikan masalah ini. Tetapi tampaknya baginya bahwa beberapa algoritma rumit diperlukan di sini dan satu-satunya hal yang terlintas di benaknya adalah jaringan saraf.
Jadi Anda dapat memecahkan masalah melalui beberapa model yang lebih ringan.
Kedengarannya jelas, tetapi pada kenyataannya, setelah permintaan seperti itu dari klien, Anda dapat menghabiskan waktu memilah berbagai arsitektur jaringan saraf sebelum Anda menyadari bahwa tugas itu dapat diselesaikan dengan lebih mudah.
Data pagi, perkiraan malam
Cukup sering, Anda akan diminta untuk memberikan tenggat waktu untuk melakukan percobaan / meluncurkan solusi di prod. Selain itu, karena dasar untuk estimasi tersebut hanya dapat memberikan deskripsi abstrak dari masalah. Sebagai contoh: “Kami ingin jaringan saraf yang, menurut gambar medis, mendiagnosis seseorang dengan penyakit. Berapa lama? ” Orang yang tidak bekerja dengan ML (dan kadang-kadang bekerja) memiliki sedikit pemahaman tentang konsep eksperimen. Banyak pendekatan pengembangan solusi ML sebagai pengembangan perangkat lunak standar. Tapi ini semua adalah kesalahan. Pengembangan ML lebih dekat dengan sains daripada pengembangan (terutama pada tahap awal). Sebagian besar waktu diperlukan untuk analisis data dan eksperimen. Dan orang jarang mengerti hal ini.
Jika Anda beruntung dan Anda memiliki, misalnya, manajer proyek yang berpengalaman, maka Anda tidak perlu berurusan dengan masalah seperti itu. Dia sendiri akan menjelaskan semuanya kepada pelanggan. Tapi itu terjadi sebaliknya - ketika manajer sendiri kurang memahami spesifikasi ML, membungkuk di bawah klien dan mulai menendang Anda bersamanya, menuntut tenggat waktu beberapa hari atau seminggu setelah menerima permintaan dari klien. Terkadang bahkan sebelum menerima data. Kemudian, Anda kemungkinan besar harus menyebutkan beberapa tanggal (baik, atau mengubah tempat kerja, yang juga merupakan pilihan yang baik dalam situasi ini). Tapi hati-hati jika Anda memutuskan untuk membuat perkiraan garis waktu tanpa informasi yang cukup. Luangkan waktu untuk bereksperimen dengan margin.
Akurasi model dalam percobaan pendahuluan 99,99999%
Bahkan jika Anda menerima metrik tinggi dalam percobaan awal atau saat menguji prototipe, ini bukan alasan untuk segera mengomunikasikannya kepada klien. Tapi semua yang Anda katakan bisa digunakan untuk melawan Anda.
Jika Anda mendapatkan nilai tinggi estimasi kualitas model dalam percobaan awal, Anda dapat memberi tahu klien bahwa masalahnya unik dipecahkan, tetapi Anda tidak boleh membuatnya senang dengan angka di muka, yang mungkin tidak begitu baik pada potongan data baru. Atau Anda dapat memanggil metrik, tetapi dengan reservasi wajib yang Anda tidak dapat menjamin bahwa dalam kondisi lain kualitasnya akan tetap sama. Ini dapat meningkatkan dan memperburuk. Selalu ada opsi bahwa Anda salah kaprah ketika melakukan percobaan (misalnya generator tidak ditulis dengan benar, dan beberapa data bocor dari pelatihan hingga pengujian).
Atau, Anda dapat memperbaiki pembayaran yang berbeda dalam kontrak untuk kualitas akhir yang berbeda dari model Anda.
Secara umum, orang biasanya lebih mempercayai contoh nyata daripada angka abstrak. Demonstrasi kecil model Anda akan memberi klien lebih percaya diri daripada pernyataan tentang akurasi 99%.
Jika Anda memecahkan masalah, misalnya, deteksi / klasifikasi menggunakan metode saraf konvolusional dan sekarang saatnya untuk menulis laporan tentang keberhasilan tim untuk periode bersyarat, habiskan 30 menit tambahan dan buat beberapa gambar indah: bermain dengan visualisasi filter konvolusional pada abstraksi tingkat tinggi atau lapisan yang terhubung sepenuhnya, buat memanaskan peta kelas, dll.
Tidak akan ada masalah dengan server
Pada titik tertentu saya mulai memperhatikan bahwa karya model sering bertumpu pada ukurannya. Misalnya, ketika Anda perlu membuat classifier untuk 5 juta kelas, bahkan model paling sederhana pun mungkin terlalu banyak sumber daya. Kemudian muncul pertanyaan secara spesifik dari spesifikasi server, yang dapat ditolak oleh klien dengan sesuatu seperti: "Tidak akan ada masalah dengan server - kami akan memilih sesuatu pada layanan cloud."
Masalahnya adalah bahwa itu mungkin tidak mewakili skala model sama sekali. Sebagai contoh, sebuah dataset akan memiliki berat 2 terabyte, dan matriks bobot dari model yang dilatih adalah 500 gigabytes lainnya. Untuk menggunakan model seperti itu, Anda membutuhkan 68-128 GB RAM. Untuk menyewa mobil seperti itu, klien dapat dikenai biaya mulai beberapa ribu hingga beberapa puluh ribu dolar per bulan (jika diperlukan lebih banyak GPU). Dan di sini, tidak banyak yang setuju untuk membayar server semacam itu.