Keuntungan:
- Kemampuan untuk mengenali tantangan khusus ML terkait dengan trio dan paket kode-data-model dan menyajikan model secara online atau dalam batch sesuai dengan kebutuhan bisnis.
- Kemampuan untuk menerapkan pola penerapan bertahap dan rollback (shadow, canary, A/B, rollback) dan menambahkan rencana rollback yang teruji ke setiap penerapan
- Kemampuan untuk menjaga tautan data-kode-metrik model yang dimasukkan ke dalam produksi dapat dilacak dengan CI/CD dan registri model yang dikontrol ambang batas evaluasi
Mendapatkan model yang mencapai akurasi 95% di notebook hanyalah setengah dari cerita. Bagian kedua—yang sering kali merupakan bagian tersulit—adalah menghadirkan model tersebut kepada pengguna sebenarnya dengan cara yang andal, terukur, dan dapat dipelihara. MLOps (Operasi Pembelajaran Mesin: disiplin dalam memasukkan, mengoperasikan, dan memelihara model ML ke dalam produksi) menggabungkan praktik DevOps dalam rekayasa perangkat lunak dengan tantangan unik ML. Dalam unit ini, kami membahas langkah-langkah memindahkan model ke produksi dan bagaimana kecerdasan buatan membantu proses ini.
Mengapa ML berbeda dengan software biasa?
Dalam perangkat lunak biasa, perilakunya ada dalam kode; Jika kodenya tidak berubah, perilakunya tidak berubah. Dalam ML, perilaku bergantung pada kode, data, dan model. Ketiga dimensi ini menciptakan tantangan ekstra bagi MLOps:
- Penyimpangan data: Data dalam produksi berpindah dari data dalam pelatihan seiring waktu; model tersebut menjadi usang.
- Anda perlu membuat versi tiga hal: Kode, data, dan model—ketiganya.
- Kegagalan senyap: Sebuah model bisa gagal tanpa mengalami error, tanpa memberikan kesalahan, hanya dengan menghasilkan prediksi yang salah. Menangkapnya memerlukan pemantauan.
Itu sebabnya ada perbedaan besar antara "model kerja" dan "model siap produksi".
Pengemasan dan penyajian model
Langkah pertama dalam memasukkan model ke dalam produksi adalah mengemasnya: file model, pustaka yang diperlukan, kode prapemrosesan, dan informasi versi bersama-sama sebagai satu kesatuan yang dapat direproduksi. Kontainerisasi (misalnya Docker: meletakkan aplikasi dalam kotak terisolasi dengan semua dependensinya) adalah standar di sini; Ini menghilangkan masalah "itu berfungsi pada mesin saya".
Dua pola dasar penyajian model:
- Online/real-time (online): Model berada di belakang API, mengembalikan prediksi instan untuk setiap permintaan masuk. Latensi rendah sangat penting.
- Batch: Model memproses kumpulan data besar secara berkala (misalnya menghasilkan skor untuk semua pelanggan di malam hari). Latensi tidak relevan, efisiensi itu penting.
Mana yang benar bergantung pada kebutuhan bisnis: rekomendasi instan online, skor risiko bulanan secara batch.
Tip: "Real-time" adalah biaya, bukan default. Batch jauh lebih murah dan sederhana jika hasilnya dapat digunakan dalam hitungan jam. Apakah Anda benar-benar membutuhkan jawaban instan? Tanyakan itu dulu.
Strategi distribusi yang aman
Membuka model baru secara langsung ke semua lalu lintas adalah hal yang berisiko; Jika salah, semua orang akan terkena dampaknya. Pola distribusi yang aman:
- Penerapan bayangan: Model baru menerima lalu lintas produksi, namun prediksinya tidak ditampilkan kepada pengguna, hanya dicatat dalam log. Ini dibandingkan dengan model lama untuk melihat apakah aman dalam data nyata.
- Penerapan Canary: Model baru pertama kali diluncurkan ke sebagian kecil lalu lintas (misalnya 5%); Jika tidak ada masalah, maka ditingkatkan secara bertahap.
- Pengujian A/B: Dua model disajikan kepada pengguna sebenarnya secara paralel dan metrik bisnis (konversi, klik) dibandingkan.
- Rollback: Kemampuan untuk kembali dengan cepat ke versi lama jika model baru ternyata buruk. Setiap penerapan harus memiliki rencana pengembalian.
Perhatian: Penerapan tanpa rencana rollback tidak akan selesai. Kemampuan untuk kembali ke versi lama dalam hitungan menit akan melindungi pengguna ketika model baru berperilaku tidak terduga dalam produksi. Uji ini sebelum penerapan.
Pendekatan lemah / Pendekatan kuat
Lemah: "Modelnya bagus dalam pengujian, kami ditayangkan, kami membukanya untuk semua orang."
Güçlü: "Kami memasukkan model ke dalam container, memberi label sebagai versi. Pertama, kami menjalankannya dalam mode bayangan dengan lalu lintas produksi selama 3 hari, membandingkan prediksi dengan model lama — deviasi dapat diterima. Kemudian kami membukanya dengan canary 5%, memantau metrik throughput dan latensi. Ketika tidak ada masalah, kami secara bertahap meningkatkannya hingga 100%. Kami telah menguji perintah rollback sebelumnya."
Bedanya: pendekatan kuat bersifat bertahap, terukur, dan dapat dibalik. Risiko terbatas pada setiap langkah.
CI/CD dan otomatisasi
CI/CD (Integrasi Berkelanjutan / Penerapan Berkelanjutan: jalur pengujian otomatis dan merilis perubahan kode) di ML tidak hanya mencakup kode tetapi juga langkah-langkah data dan model. Pipeline ML CI/CD yang baik: menjalankan pengujian ketika kode berubah, melakukan validasi data, melatih ulang model (jika perlu), memeriksa ambang batas evaluasi, dan hanya memajukan penerapan jika ambang batas tersebut bertahan. Prinsip “pelatihan bersifat otomatis, penerapan berbasis ambang batas” mencegah model buruk bocor secara diam-diam ke dalam produksi.
AI sangat membantu saat menyiapkan saluran ini: menulis draf file konfigurasi (YAML), kasus pengujian, skrip penerapan. Namun Anda menentukan ambang batas distribusi (metrik apa pun yang melebihi nilai yang dipublikasikan) dan kebijakan rollback; ini adalah keputusan risiko bisnis.
Infrastruktur reproduksibilitas
Untuk mereproduksi perilaku model dalam produksi, registri model: catatan yang menyimpan model mana yang dilatih dengan data dan kode apa, dan metrik apa yang diterimanya. Untuk setiap model produksi, hal-hal berikut harus dapat dilacak: versi data pelatihan, versi kode (git commit), hyperparameter, skor evaluasi, dan tanggal penerapan. Ketika masalah muncul, Anda harus bisa menjawab pertanyaan "model mana yang menghasilkan prediksi ini, dengan data yang mana?" dalam beberapa menit. Kita akan memperdalamnya di unit 11.
tiga kasus mini
Kasus 1 - Masalah tertangkap oleh distribusi bayangan. Model rekomendasi mengalahkan model lama dalam pengujian. Menjalankannya dengan lalu lintas produksi dalam mode bayangan ternyata menghasilkan rekomendasi yang sangat buruk untuk segmen pengguna tertentu (pengguna baru) — data pengujian kurang mewakili segmen ini. Model telah diperbaiki tanpa pernah ditampilkan kepada pengguna. Jika dibuka langsung, pengalaman pengguna baru akan terganggu.
Kasus 2 - Distribusi yang tidak dapat dibatalkan. Sebuah tim meluncurkan model penetapan harga baru untuk semua lalu lintas, tanpa rencana pengembalian. Model tersebut secara tidak terduga memberi harga pada beberapa produk dengan sangat murah. Mengembalikan ke versi lama memakan waktu berjam-jam karena prosesnya belum siap. Terjadi kehilangan pendapatan yang serius. Setelah itu, pengujian rollback wajib ditambahkan ke setiap penerapan.
Kasus 3 - Aliran data senyap. Pola penipuan muncul selama berbulan-bulan tanpa kesalahan apa pun. Namun taktik para penipu berubah (data drift) dan penarikan kembali model tersebut secara diam-diam menurun. Tidak ada yang memperhatikan karena tidak ada pengawasan. Setelah panel pemantauan distribusi prakiraan dibentuk, penyimpangan tersebut menjadi terlihat lebih awal. Kami akan membahas pemantauan di unit 8.
Templat yang dapat disalin
Tulis rancangan rencana penerapan untuk model ini. Model: [apa fungsinya], penggunaan: [online atau batch?] Harus mencakup:1) Pengemasan (kontainer, pembuatan versi)2) Strategi penerapan bertahap (shadow/canary/A-B) dan alasannya3) Metrik yang harus dilacak (bisnis + teknis + latensi)4) Rencana rollback dan cara mengujinya5) Ambang batas penerapan (metrik mana yang harus melebihi nilai berapa)
Periksa pipeline ML CI/CD ini:1) Apakah validasi data sudah sesuai?2) Dapatkah penerapan dilanjutkan tanpa menahan ambang batas evaluasi (bukankah seharusnya)?3) Apakah rollback otomatis?4) Apakah data+kode+metrik dilacak dalam registri model?Konfigurasi pline: [config]
Bantu saya memutuskan apakah presentasi online atau batch cocok untuk model ini. Berapa lama hasilnya akan digunakan: [instan / menit / jam / hari]Volume permintaan yang diharapkan: [angka]Apakah ada batasan penundaan: [ms]Manakah yang akan Anda rekomendasikan dalam hal biaya dan kompleksitas dan mengapa?
Tulis prosedur rollback untuk model ini.- Metrik/ambang batas apa yang memicu kinerja buruk?- Apa saja langkah rollbacknya?- Berapa lama waktu yang dibutuhkan untuk rollback (target)?- Bagaimana cara menguji prosedur ini sebelum produksi?
Tabel pola presentasi
kriteria
Daring (waktu nyata)
kumpulan
penundaan
Kritis (ms)
tidak signifikan
Penggunaan
Diperlukan respons instan
Skor berkala
Biaya
tinggi
rendah
kompleksitas
tinggi
rendah
contoh
Rekomendasi langsung, penipuan
Skor risiko bulanan
Kesalahan umum
- Distribusikan tanpa rencana pengambilan. Model yang salah berdampak pada seluruh pengguna.
- Membuka langsung ke lalu lintas 100%. Batasi risiko dengan distribusi bertahap.
- Tidak melakukan pemantauan. Model menghasilkan kesalahan secara diam-diam, tanpa kesalahan.
- Presentasi real-time yang berlebihan. Meskipun pengelompokan sudah mencukupi, biaya dan kompleksitas membengkak.
- Tidak menautkan versi kode data model. Anda tidak dapat mereproduksi masalahnya.
- Rilis otomatis tanpa ambang batas distribusi. Model jahat itu menyelinap masuk secara diam-diam.
Singkatnya
Memindahkan model ke produksi adalah tugas teknik yang berbeda dan seringkali lebih sulit dibandingkan melatihnya. ML memerlukan disiplin ekstra karena bergantung pada trio model kode-data: pengemasan dan pembuatan versi, pola pengiriman (online/batch) yang sesuai dengan kebutuhan bisnis, penerapan bertahap dan dapat dibalik, CI/CD yang dikontrol ambang batas, dan registrasi model. Kecerdasan buatan merupakan bantuan yang ampuh dalam menghasilkan kode dan konfigurasi infrastruktur ini; namun batasan distribusi, kebijakan pengembalian, dan keputusan risiko ada di tangan Anda. Distribusi tanpa rencana rollback tidaklah lengkap.
Tugas aplikasi
Masukkan (Docker) model ke dalam container dan beri label versinya. Putuskan apakah Anda akan menawarkan secara online atau batch berdasarkan kebutuhan bisnis Anda dan tuliskan alasan Anda. Dokumentasikan rencana penerapan bertahap (shadow atau canary) dan prosedur rollback yang telah diuji. Pastikan untuk mencatat versi data, penerapan kode, dan skor evaluasi di registri model.
daftar periksa
- [ ] Model dikemas dan diberi versi (wadah + label).
- [ ] Pola presentasi (online/batch) dipilih sesuai kebutuhan bisnis.
- [ ] Strategi penerapan bertahap (shadow/canary) diterapkan.
- [ ] Prosedur rollback ditulis dan diuji.
- [ ] CI/CD tidak memajukan penerapan sebelum ambang batas evaluasi terpenuhi.
- [ ] Registri model menyimpan tautan data+kode+metrik.