Menjelajahi arsitektur solusi
Mari kita revisi arsitektur operasi pembelajaran mesin (MLOps) untuk memahami tujuan apa yang ingin kita capai.
Bayangkan bahwa bersama dengan tim pengembangan ilmu data dan perangkat lunak, Anda telah menyetujui arsitektur berikut untuk melatih, menguji, dan menyebarkan model klasifikasi diabetes:
Catatan
Diagram adalah representasi sederhana dari arsitektur MLOps. Untuk melihat arsitektur yang lebih rinci, jelajahi berbagai kasus penggunaan di akselerator solusi MLOps (v2).
Arsitektur tersebut meliputi:
- Penyiapan: Buat semua sumber daya Azure yang diperlukan untuk solusi.
- Pengembangan model (perulangan dalam): Jelajahi dan proses data untuk melatih dan mengevaluasi model.
- Integrasi berkelanjutan: Mengemas dan mendaftarkan model.
- Penyebaran model (siklus luar): Sebarkan model.
- Penyebaran berkelanjutan: Uji model dan promosikan ke lingkungan produksi.
- Pemantauan: Memantau model dan performa titik akhir.
Tim ilmu data bertanggung jawab atas pengembangan model. Tim pengembangan perangkat lunak bertanggung jawab untuk mengintegrasikan model yang disebarkan dengan aplikasi web yang digunakan oleh praktisi untuk menilai apakah pasien mengalami diabetes. Anda bertanggung jawab untuk mengambil model dari pengembangan model ke penyebaran model.
Anda mengharapkan tim ilmu data untuk terus mengusulkan perubahan pada skrip yang digunakan untuk melatih model. Setiap kali ada perubahan pada skrip pelatihan, Anda perlu melatih kembali model dan menyebarkan ulang model ke titik akhir yang ada.
Anda ingin mengizinkan tim ilmu data untuk bereksperimen, tanpa menyentuh kode yang siap untuk produksi. Anda juga ingin memastikan bahwa kode baru atau yang diperbarui secara otomatis melewati pemeriksaan kualitas yang disepakati. Setelah memverifikasi kode untuk melatih model, Anda akan menggunakan skrip pelatihan yang diperbarui untuk melatih model baru dan menyebarkannya.
Untuk melacak perubahan dan memverifikasi kode Anda sebelum memperbarui kode produksi, perlu bekerja dengan cabang. Anda telah setuju dengan tim ilmu data bahwa setiap kali mereka ingin membuat perubahan, mereka akan membuat cabang fitur untuk membuat salinan kode dan membuat perubahannya pada salinan.
Setiap ilmuwan data dapat membuat cabang fitur dan bekerja di sana. Setelah memperbarui kode dan ingin kode tersebut menjadi kode produksi baru, mereka harus membuat permintaan pull. Dalam permintaan pull, itu akan terlihat bagi orang lain apa perubahan yang diusulkan, memberi orang lain kesempatan untuk meninjau dan mendiskusikan perubahan.
Setiap kali permintaan pull dibuat, Anda ingin secara otomatis memeriksa apakah kode berfungsi dan kualitas kode sesuai dengan standar organisasi Anda. Setelah kode melewati pemeriksaan kualitas, ilmuwan data utama perlu meninjau perubahan dan menyetujui pembaruan sebelum permintaan pull dapat digabungkan, dan kode di cabang utama dapat diperbarui.
Penting
Tidak ada yang boleh diizinkan untuk mendorong perubahan ke cabang utama. Untuk melindungi kode Anda, terutama kode produksi, Anda harus memberlakukan bahwa cabang utama hanya dapat diperbarui melalui permintaan pull yang perlu disetujui.