Deployment

Dalam rekayasa perangkat lunak, menempatkan kode dalam produksi memerlukan uji tuntas, karena kode mungkin berperilaku tidak terduga, perilaku pengguna yang tidak terduga dapat merusak perangkat lunak, dan kasus tepi yang tidak terduga dapat ditemukan. Insinyur dan DevOps insinyur perangkat lunak biasanya menggunakan pengujian unit dan strategi rollback untuk mengurangi risiko ini. Dengan ML, menempatkan model dalam produksi membutuhkan lebih banyak perencanaan, karena lingkungan nyata diperkirakan akan melayang, dan pada banyak kesempatan, model divalidasi pada metrik yang merupakan proxy untuk metrik bisnis nyata yang mereka coba tingkatkan.

Ikuti praktik terbaik di bagian ini untuk membantu mengatasi tantangan ini.

Otomatiskan siklus penerapan

Proses pelatihan dan penerapan harus sepenuhnya otomatis untuk mencegah kesalahan manusia dan untuk memastikan bahwa pemeriksaan build dijalankan secara konsisten. Pengguna tidak boleh memiliki izin akses tulis ke lingkungan produksi.

Amazon SageMaker Pipelines dan AWS CodePipelinemembantu membuat CI/CD pipelines for ML projects. One of the advantages of using a CI/CD pipeline adalah bahwa semua kode yang digunakan untuk menyerap data, melatih model, dan melakukan pemantauan dapat dikontrol versi dengan menggunakan alat seperti Git. Terkadang Anda harus melatih ulang model dengan menggunakan algoritma dan hyperparameter yang sama, tetapi data yang berbeda. Satu-satunya cara untuk memverifikasi bahwa Anda menggunakan versi algoritma yang benar adalah dengan menggunakan kontrol sumber dan tag. Anda dapat menggunakan templat proyek default yang disediakan oleh SageMaker sebagai titik awal untuk MLOps latihan Anda.

Saat Anda membuat pipeline CI/CD untuk menerapkan model Anda, pastikan untuk menandai artefak build Anda dengan pengenal build, versi kode atau komit, dan versi data. Praktik ini membantu Anda memecahkan masalah penerapan apa pun. Penandaan juga terkadang diperlukan untuk model yang membuat prediksi di bidang yang sangat diatur. Kemampuan untuk bekerja mundur dan mengidentifikasi data, kode, pembuatan, pemeriksaan, dan persetujuan yang tepat yang terkait dengan model ML dapat membantu meningkatkan tata kelola secara signifikan.

Bagian dari tugas pipa CI/CD adalah melakukan tes pada apa yang sedang dibangun. Meskipun pengujian unit data diharapkan terjadi sebelum data dicerna oleh feature store, pipeline masih bertanggung jawab untuk melakukan pengujian pada input dan output model tertentu dan untuk memeriksa metrik kunci. Salah satu contoh pemeriksaan tersebut adalah untuk memvalidasi model baru pada set validasi tetap dan untuk mengkonfirmasi bahwa kinerjanya mirip dengan model sebelumnya dengan menggunakan ambang batas yang ditetapkan. Jika kinerja secara signifikan lebih rendah dari yang diharapkan, build akan gagal dan model tidak boleh diproduksi.

Penggunaan pipa CI/CD yang ekstensif juga mendukung permintaan tarik, yang membantu mencegah kesalahan manusia. Saat Anda menggunakan permintaan tarik, setiap perubahan kode harus ditinjau dan disetujui oleh setidaknya satu anggota tim lainnya sebelum dapat diproduksi. Permintaan tarik juga berguna untuk mengidentifikasi kode yang tidak mematuhi aturan bisnis dan untuk menyebarkan pengetahuan dalam tim.

Pilih strategi penerapan

MLOpsstrategi penyebaran termasuk blue/green, canary, shadow, and A/B pengujian.

Biru/hijau

Blue/green deployments are very common in software development. In this mode, two systems are kept running during development: blue is the old environment (in this case, the model that is being replaced) and green is the newly released model that is going to production. Changes can easily be rolled back with minimum downtime, because the old system is kept alive. For more in-depth information about blue/greenpenerapan dalam konteks SageMaker, lihat posting blog Menyebarkan dan memantau SageMaker titik akhir Amazon dengan aman dengan AWS CodePipeline dan di blog AWS CodeDeploy Machine Learning AWS .

Kenari

Penerapan Canary mirip dengan blue/green deployments in that both keep two models running together. However, in canary deployments, the new model is rolled out to users incrementally, until all traffic eventually shifts over to the new model. As in blue/green penerapan, risiko dikurangi karena model baru (dan berpotensi rusak) dipantau secara ketat selama peluncuran awal, dan dapat dibatalkan jika terjadi masalah. Di SageMaker, Anda dapat menentukan distribusi lalu lintas awal dengan menggunakan InitialVariantWeightAPI.

Bayangan

Anda dapat menggunakan penerapan bayangan untuk membawa model ke produksi dengan aman. Dalam mode ini, model baru bekerja bersama model lama atau proses bisnis, dan melakukan kesimpulan tanpa mempengaruhi keputusan apa pun. Mode ini dapat berguna sebagai pemeriksaan akhir atau eksperimen kesetiaan yang lebih tinggi sebelum Anda mempromosikan model ke produksi.

Mode bayangan berguna saat Anda tidak memerlukan umpan balik inferensi pengguna. Anda dapat menilai kualitas prediksi dengan melakukan analisis kesalahan dan membandingkan model baru dengan model lama, dan Anda dapat memantau distribusi output untuk memverifikasi bahwa itu seperti yang diharapkan. Untuk melihat cara melakukan penyebaran bayangan dengan SageMaker, lihat posting blog Menerapkan model shadow HTML SageMaker di Amazon di blog AWS Machine Learning.

Pengujian A/B

Ketika praktisi ML mengembangkan model di lingkungan mereka, metrik yang mereka optimalkan seringkali merupakan proxy untuk metrik bisnis yang benar-benar penting. Hal ini membuat sulit untuk mengetahui dengan pasti apakah model baru benar-benar akan meningkatkan hasil bisnis, seperti pendapatan dan rasio klik-tayang, dan mengurangi jumlah keluhan pengguna.

Pertimbangkan kasus situs web e-commerce di mana tujuan bisnisnya adalah menjual produk sebanyak mungkin. Tim peninjau tahu bahwa penjualan dan kepuasan pelanggan berkorelasi langsung dengan ulasan yang informatif dan akurat. Seorang anggota tim mungkin mengusulkan algoritma peringkat tinjauan baru untuk meningkatkan penjualan. Dengan menggunakan pengujian A/B, mereka dapat meluncurkan algoritme lama dan baru ke grup pengguna yang berbeda tetapi serupa, dan memantau hasilnya untuk melihat apakah pengguna yang menerima prediksi dari model yang lebih baru lebih cenderung melakukan pembelian.

Pengujian A/B juga membantu mengukur dampak bisnis dari model staleness dan drift. Tim dapat menempatkan model baru dalam produksi dengan beberapa pengulangan, melakukan pengujian A/B dengan masing-masing model, dan membuat bagan usia versus kinerja. Ini akan membantu tim memahami volatilitas drift data dalam data produksi mereka.

Untuk informasi selengkapnya tentang cara melakukan pengujian A/B dengan SageMaker, lihat posting blog model A/B Testing ML dalam produksi menggunakan Amazon SageMaker di blog AWS Machine Learning.

Pertimbangkan persyaratan inferensi Anda

Dengan SageMaker, Anda dapat memilih infrastruktur yang mendasari untuk menerapkan model Anda dengan cara yang berbeda. Kemampuan pemanggilan inferensi ini mendukung kasus penggunaan dan profil biaya yang berbeda. Opsi Anda mencakup inferensi waktu nyata, inferensi asinkron, dan transformasi batch, seperti yang dibahas di bagian berikut.

Inferensi waktu nyata

Inferensi waktu nyata sangat ideal untuk beban kerja inferensi di mana Anda memiliki persyaratan real-time, interaktif, latensi rendah. Anda dapat menerapkan model Anda ke layanan SageMaker hosting dan mendapatkan titik akhir yang dapat digunakan untuk inferensi. Titik akhir ini dikelola sepenuhnya, mendukung penskalaan otomatis (lihat SageMakerModel Amazon skala otomatis), dan dapat digunakan di beberapa Availability Zone.

Jika Anda memiliki model pembelajaran mendalam yang dibuat dengan ApacheMXNet,, atau PyTorch TensorFlow, Anda juga dapat menggunakan Amazon SageMaker Elastic Inference (EI). Dengan EI, Anda dapat melampirkan fraksional GPUs ke SageMaker instance apa pun untuk mempercepat inferensi. Anda dapat memilih instance klien untuk menjalankan aplikasi Anda dan melampirkan akselerator EI untuk menggunakan jumlah GPU akselerasi yang benar untuk kebutuhan inferensi Anda.

Pilihan lain adalah menggunakan titik akhir multi-model, yang memberikan solusi yang dapat diskalakan dan hemat biaya untuk menerapkan sejumlah besar model. Titik akhir ini menggunakan wadah penyajian bersama yang diaktifkan untuk meng-host beberapa model. Titik akhir multi-model mengurangi biaya hosting dengan meningkatkan pemanfaatan titik akhir dibandingkan dengan menggunakan titik akhir model tunggal. Mereka juga mengurangi overhead penerapan, karena SageMaker mengelola pemuatan model dalam memori dan menskalakannya berdasarkan pola lalu lintas.

Untuk praktik terbaik tambahan untuk menerapkan model ML SageMaker, lihat Praktik terbaik penerapan dalam dokumentasi. SageMaker

Inferensi asinkron

Amazon SageMaker Asynchronous Inference adalah kemampuan yang mengantrekan permintaan yang masuk dan SageMaker memprosesnya secara asinkron. Opsi ini sangat ideal untuk permintaan dengan ukuran muatan besar hingga 1 GB, waktu pemrosesan yang lama, dan persyaratan latensi mendekati waktu nyata. Inferensi asinkron memungkinkan Anda menghemat biaya dengan secara otomatis menskalakan jumlah instans ke nol saat tidak ada permintaan untuk diproses, jadi Anda hanya membayar saat titik akhir memproses permintaan.

Transformasi Batch

Gunakan transformasi batch saat Anda ingin melakukan hal berikut:

• Preprocess dataset untuk menghilangkan noise atau bias yang mengganggu pelatihan atau inferensi dari dataset Anda.

• Dapatkan kesimpulan dari kumpulan data besar.

• Jalankan inferensi saat Anda tidak membutuhkan titik akhir yang persisten.

• Kaitkan catatan input dengan kesimpulan untuk membantu interpretasi hasil.