Pengarang: Ori Abramovsky
Awalnya diterbitkan di Towards AI the World’s Leading AI and Technology News and Media Company. Jika Anda sedang membangun produk atau layanan terkait AI, kami mengundang Anda untuk mempertimbangkan untuk menjadi sponsor AI. Di Towards AI, kami membantu menskalakan AI dan startup teknologi. Biarkan kami membantu Anda melepaskan teknologi Anda kepada massa.
Langkah Menuju Penelitian MLOps — Rekayasa Perangkat Lunak AI Anda
Ilmuwan data satu menit setelah model mereka dikerahkan ke lingkungan produksi. Foto oleh Artem Beliaikin di Unsplash
MLOps adalah persyaratan lama untuk bidang baru; dunia Pembelajaran Mesin berkembang, dari topik khusus di latar belakang paling gelap menjadi warga kelas satu dalam berbagai kasus penggunaan. Tetapi dengan kekuatan besar datang tanggung jawab besar; selain menambahkan persyaratan khusus domain baru (seperti — Penjelasan Model, berkolaborasi dalam penelitian, dan membuatnya dapat dibaca), juga kebutuhan pengembangan perangkat lunak umum yang lebih tradisional (seperti — pemantauan, penyajian API, dan Manajemen Rilis) menjadi semakin banyak penting untuk aplikasi AI juga. Prosedur-prosedur ini dirumuskan dengan baik di dunia pengembangan perangkat lunak umum tetapi cukup baru dalam domain Pembelajaran Mesin dan, oleh karena itu, akan memakan waktu hingga diadopsi sepenuhnya. Tapi sementara itu, ada banyak yang bisa dilakukan; langkah awalnya adalah merangkul konsep pengembangan perangkat lunak umum dan memasukkannya ke dalam dunia Pembelajaran Mesin. Perubahan kecil pada cara kami berinteraksi dan mengelola proyek AI kami. Di bawah ini adalah poin-poin penting menuju target tersebut. Sederhana tetapi pada saat yang sama penting untuk kebutuhan itu.
Ilmuwan data satu menit setelah mereka menyadari model mereka harus ditangani pada produksi juga. Foto oleh Darius Bashar di Unsplash
Penelitian yang dapat direproduksi — simpan set data kereta
Salah satu fenomena utama yang paling mengganggu kita di dunia Machine Learning adalah makalah Penelitian yang Tidak Dapat Direproduksi; yang menunjukkan hasil ekstrem tetapi pada saat yang sama tidak membagikan kode, data, atau cara untuk mereproduksi hasil. Sekarang perbesar ke organisasi Anda; mari kita asumsikan kami memiliki model yang berjalan untuk sementara waktu, melayani pelanggan kami dan menunjukkan kinerja X. Seiring waktu berlalu sejak pertama kali dikembangkan, kami memutuskan untuk meninjau kembali kinerjanya untuk menemukan apakah penyetelan ulang diperlukan. Masalahnya adalah orang yang membuat model telah pergi/ sedang mengerjakan proyek yang berbeda, dan sekarang kita perlu meneliti ulang model untuk memahami angka-angkanya dengan lebih baik. Biasanya selama proses tersebut, kami akan menemukan kasus tepi seperti potongan data anomali, fitur potensial baru, nilai yang hilang, atau hanya memiliki sudut pandang unik kami tentang masalah yang dihadapi. Masing-masing poin ini dapat mengirim kita dalam perjalanan panjang hanya untuk menjawab pertanyaan seperti; apakah pembuat model mengenalnya? Dan jika mereka melakukannya, apakah mereka melakukan hal-hal yang berbeda?. Masalahnya adalah itu dapat dengan mudah berubah menjadi buang-buang waktu, mengejar hantu tanpa mengetahui bahwa ini adalah jalan buntu. Tetapi bagaimana jika kita dapat melompat kembali ke masa ketika model awalnya dilatih dan memvalidasi pertanyaan-pertanyaan ini? Ketika para pemikir hebat berpikir sama, kemungkinan besar, banyak dari ide-ide ‘baru yang menarik’ kami telah dievaluasi!. Tetapi sampai seseorang mengembangkan mesin waktu yang bekerja, yang terbaik yang dapat kita lakukan adalah menyelamatkan populasi kereta asli yang menjadi tempat model dilatih, memungkinkan kita untuk memvalidasi pertanyaan-pertanyaan itu dengan mudah. Menyimpan snapshot kumpulan data kereta secara sistematis akan memudahkan banyak persyaratan di kemudian hari.
Penelitian yang dapat dijelaskan — catat apa dan apa yang tidak boleh dilakukan
Melanjutkan poin kami sebelumnya, untuk beberapa kasus menyimpan snapshot dari dataset pelatihan tidak cukup karena akan kekurangan beberapa poin konteks penting. Menjawab pertanyaan seperti “mengapa model tidak menggunakan fitur X untuk prediksinya?” Atau “bukankah lebih baik merepresentasikan data dengan cara yang berbeda?” tidak layak dengan hanya memiliki snapshot set data kereta. Kekurangan kami adalah konteks yang menyebabkan beberapa keputusan ini, yang biasanya tidak terlihat oleh data itu sendiri. Solusi super penting untuk kebutuhan ini adalah memiliki metode penelitian yang lebih terstruktur; menggunakan alat seperti notebook iPython memungkinkan kita memahami apa yang dilakukan dengan mudah, mengapa, dan bagaimana. Alat semacam itu penting bahkan bagi ilmuwan data tunggal yang bekerja sendirian di organisasi R&D yang lebih luas. Menyimpan buku catatan yang terdokumentasi dengan baik dan diperbarui yang menjelaskan penelitian yang kami buat dan keputusan yang kami ambil dapat memungkinkan kami untuk dengan mudah menangani pertanyaan dan masalah yang mungkin muncul di masa mendatang. Menjadi buku terbuka dari penelitian kami, bahkan dapat membuat model yang kami hasilkan menjelaskan sendiri masalah masa depan tersebut.
Penelitian pengembangan perangkat lunak — jadikan ini sebagai proyek dan GIT
Sekarang kami memutuskan untuk menggunakan notebook iPython sebagai alat penelitian utama kami, dan setelah kami berupaya membuatnya lebih terstruktur dan mudah dibaca, kami tergoda untuk memindahkan semua pengembangan kami ke ekosistem tersebut, untuk membuat bahkan skrip produksi kami dikelola dan dipicu sebagai notebook. Secara pribadi, saya menemukan notebook iPython sangat bermanfaat selama penelitian awal dan fase POCing tetapi juga sangat berlawanan dengan intuisi dan rawan kesalahan begitu penelitian dilakukan. Proses pengembangan kode biasanya mencakup versi, cacat, cerita pengguna, dokumentasi, dan banyak fitur rekayasa perangkat lunak modern lainnya. Semua sangat cocok untuk penggunaan alat hosting kode sumber seperti GIT, memungkinkan kami untuk mengelola status pengembangan kode kami dengan mudah. Menjaga versi notebook kami menggunakan sistem Kontrol Versi adalah langkah pertama ke arah itu. Tapi ini tidak cukup. Setelah fase penelitian selesai, penting untuk memperlakukan notebook kami sebagai proyek pengembangan perangkat lunak biasa dan untuk menangani persyaratan relevan yang ditambahkannya. Salah satu contohnya adalah memastikan kode kami dapat direproduksi, kebutuhan yang sangat penting untuk dua tempat utama — fase pembuatan data (memungkinkan kami untuk dengan mudah menyelidiki dan memperbaiki cacat data dengan membuat kode terkait lebih jelas dan terlihat, juga memungkinkan mudah penelitian untuk mengembangkan transisi) dan fase Produksi (memungkinkan pandangan yang jelas tentang persyaratan aplikasi seperti cara mendukung inferensi online serta titik konteks umum seperti latensi yang diproyeksikan). Fitur-fitur tersebut kurang terlihat ketika kode kami dikelola di seluruh notebook yang berbeda. Selain itu, pengembangan berbasis notebook dapat dengan mudah mentolerir anti-pola kode seperti Duplikasi Kode. Setelah visualisasi, keterbacaan, dan penelitian kurang penting, saatnya untuk memindahkan cuplikan notebook iPython kami untuk dikelola sebagai proyek kode umum.
Penelitian perangkat lunak dev— konteks notebook
Sekarang setelah kita mempelajari betapa pentingnya memindahkan kode kita ke proyek umum secepat mungkin, kita harus menyoroti lagi mengapa kita memutuskan untuk menggunakan notebook iPython; melihat perkembangan AI secara singkat memiliki dua fase utama — fase eksplorasi/penelitian umum dan tindak lanjut yang lebih spesifik, ketika kita tahu apa yang harus dilakukan dan mulai mengimplementasikannya. Dengan mengaktifkan visualisasi dan kemampuan menjelaskan dengan mudah, notebook iPython jelas merupakan alat terbaik untuk fase penelitian. Sementara sebelumnya kami menjelaskan mengapa penting untuk tidak terlalu bergantung pada notebook, pencerminan tidak terlalu bergantung pada proyek kode umum; serupa dengan sebelumnya, akan ada kecenderungan untuk memindahkan semua perkembangan kita keluar dari ekosistem notebook. Langkah umum seperti itu akan mencakup pemfaktoran ulang buku catatan, memindahkan cuplikan kode untuk di-host di proyek kode, dan menggunakan impornya (bukan kode biasa) di buku catatan kita. Namun peringatan tersembunyi adalah fakta bahwa notebook dan proyek kode umum memiliki proses kemajuan dan rilis yang berbeda — mengunjungi kembali notebook kami beberapa bulan kemudian dapat menyembunyikan fakta bahwa sementara notebook dibuat dengan impor kode versi X, basis kode saat ini berada di versi X+m, yang tidak relevan lagi dengan status notebook yang kita lihat (cacat telah diperbaiki, API rusak, dll.). Yang kurang dari kami adalah proyek kode gabungan ke status notebook. Ada beberapa solusi yang mungkin untuk itu, seperti meletakkan buku catatan ke bagian dari proyek kode, yang dapat memungkinkan penyelidikan lebih lanjut untuk memahami versi kode apa yang mereka andalkan. Tetapi pendekatan yang lebih mudah adalah dengan memperjelas dalam buku catatan eksplorasi apa yang mereka coba selidiki dan aset, status, dan versi apa yang mereka andalkan. Dalam beberapa kasus, bahkan (maafkan saya, Tuhan) hanya menyalin kode yang relevan bisa masuk akal.
Pemantauan penelitian — kinerja model
Poin penting yang cenderung dilupakan banyak dari kita adalah kenyataan bahwa pekerjaan kita tidak berakhir setelah penelitian selesai, pengembangan selesai, dan bahkan ketika penerapan selesai. Dalam beberapa aspek, ini hanya dimulai setelah pengguna mulai berinteraksi dengan model yang kami buat. Umumnya penelitian yang kami lakukan mencakup kebutuhan dan tesis yang relevan. Misalnya, untuk meningkatkan kepuasan pelanggan (kebutuhan), kami akan berusaha meningkatkan layanan kami, memastikan permintaan pelanggan ditangani dan diselesaikan tepat waktu, dengan asumsi itu meningkatkan kepuasan mereka (tesis). Mari kita asumsikan kita membuat model untuk tim dukungan perusahaan kita yang menyoroti permintaan pelanggan yang berisiko tidak dapat diselesaikan tepat waktu. Setelah pengguna (karyawan pendukung) mulai menggunakan aplikasi kami, ada beberapa metrik yang harus kami perhatikan; pertama, jika permintaan pelanggan sekarang tidak ditangani dengan lebih baik, maka diperlukan debug lebih lanjut; mungkin ada masalah dengan UX, data yang kami gunakan atau model yang kami hasilkan. Maka penting untuk memverifikasi bahwa tesis kami menyatakan bahwa sekali lagi permintaan ditangani dengan benar, kepuasan akan meningkat. Dari POV operasi, penting untuk terus memverifikasi karakteristik ini. Metrik umum yang harus diperhatikan adalah distribusi kelas — mencari perubahan mendadak (yang dapat mengindikasikan masalah) dan membandingkannya dengan angka dasar penelitian kami (mengingat bahwa model kami memprediksi X% positif pada pemisahan validasi dan sekarang 3*X% atau X /3%, ini dapat menunjukkan masalah). Untuk beberapa kasus, model kami akan berkala, menurut definisi, diperlukan untuk dilatih ulang sesekali. Untuk kasus ini, kami ingin membuat model menggunakan kode (dan bukan di notebook satu kali). Kode tersebut dapat menjadi bagian dari proses penyebaran CI-CD umum dan harus mencakup tes otomatis untuk memverifikasi apakah model baru yang dihasilkan harus menggantikan yang sudah ada. Tes semacam itu mungkin akan menganalisis metrik yang sama seperti yang kami sebutkan dan, oleh karena itu, dapat digunakan kembali untuk kebutuhan itu.
Pengujian penelitian — verifikasi data
Sekarang setelah kita mulai memantau model kita, kita harus meninjau tes lain yang mungkin untuk diterapkan; Selain metrik operasional reguler (seperti latensi, memori yang digunakan, kegagalan permintaan, dll.) dan metrik kinerja intuitif (tingkat akurasi), kami ingin menggunakan pengujian yang lebih klasik seperti pengujian unit, fungsional, dan integrasi. Mengingat pentingnya data yang tinggi untuk keberhasilan aplikasi AI, area pertama yang menerapkan tes ini adalah domain data. Selain itu, seperti dalam banyak kasus, kami adalah konsumen data (akan diproduksi di tempat lain), dan kami ingin menguji unit dan memantau properti utama data kami. Pendekatan naif adalah memverifikasi properti seperti definisi data pada umumnya. Ini naif bukan karena kurangnya kepentingan tetapi karena fakta ini adalah upaya yang tidak pernah berakhir — setiap bidang data dapat dijelaskan dan dianalisis lebih lanjut dalam berbagai aspek (nilai nol, kepadatan, rentang, dll.). Menguji semua kasus ini akan sulit dipertahankan dan dapat dengan mudah menghasilkan banyak peringatan FP. Solusi yang lebih masuk akal dapat dibangun dengan cara yang berlawanan; pertama, anggap semuanya berfungsi dengan benar dan mulailah dengan memverifikasi hanya kasus 911 (seperti data baru tiba sama sekali). Kemudian, buat pengujian data baru hanya setelah identifikasi cacat data (untuk memverifikasinya di masa mendatang). Menggunakan pendekatan itu akan memastikan Anda tidak memiliki terlalu banyak tes, dan untuk tes yang Anda miliki, akan ada motivasi yang jelas untuk memastikannya bekerja dengan baik.
Penelitian pengembangan perangkat lunak dan sebaliknya
Penelitian AI hanya dapat mengambil manfaat dari konsep pengembangan perangkat lunak umum. Mengingat tingginya peningkatan AI, insinyur ML, dan alat seperti notebook iPython, wajar untuk berasumsi bahwa sebaliknya akan terjadi juga, dan pengembangan perangkat lunak umum juga akan menemukan konsep AI untuk diuntungkan. Misalnya, mulai gunakan buku catatan sebagai alat DevOps untuk mendeskripsikan properti lingkungan yang ada. Hari-hari yang menyenangkan ada di depan.
Langkah-langkah menuju penelitian MLOps — Rekayasa Perangkat Lunak AI Anda awalnya diterbitkan di Towards AI on Medium, di mana orang-orang melanjutkan percakapan dengan menyoroti dan menanggapi cerita ini.
Diterbitkan melalui Menuju AI
