Unit 7 / 11

MLOps dan Deployment: Memindahkan Model dari Makmal ke Pengeluaran

Keuntungan:

  • Keupayaan untuk mengenali cabaran khas ML yang berkaitan dengan trio dan pakej kod-data-model dan mempersembahkan model dalam talian atau dalam kelompok mengikut keperluan perniagaan.
  • Keupayaan untuk melaksanakan corak penggunaan secara beransur-ansur dan rollback (bayangan, kenari, A/B, rollback) dan menambah pelan rollback yang diuji pada setiap penggunaan
  • Keupayaan untuk memastikan pautan data-kod-metrik model dimasukkan ke dalam pengeluaran boleh dikesan dengan CI/CD terkawal ambang penilaian dan pendaftaran model

Mendapatkan model untuk mencapai ketepatan 95% dalam buku nota hanyalah separuh daripada cerita. Separuh lagi—selalunya bahagian yang sukar—memperoleh model itu kepada pengguna sebenar dengan cara yang boleh dipercayai, berskala dan boleh diselenggara. MLOps (Operasi Pembelajaran Mesin: disiplin meletakkan, mengendalikan dan mengekalkan model ML ke dalam pengeluaran) menggabungkan amalan DevOps kejuruteraan perisian dengan cabaran unik ML. Dalam unit ini, kami merangkumi langkah-langkah mengalihkan model kepada pengeluaran dan cara kecerdasan buatan membantu dalam proses ini.

Mengapa ML berbeza daripada perisian biasa?

Dalam perisian biasa, tingkah laku adalah dalam kod; Jika kod tidak berubah, tingkah laku tidak berubah. Dalam ML, tingkah laku bergantung pada kedua-dua kod, data dan model. Tiga dimensi ini mewujudkan cabaran tambahan MLOps:

  • Data drift: Data dalam pengeluaran bergerak menjauhi data dalam latihan dari semasa ke semasa; model menjadi usang.
  • Anda perlu membuat versi tiga perkara: Kod, data dan model—ketiganya.
  • Kegagalan senyap: Model boleh gagal tanpa ranap, tanpa memberikan ralat, hanya dengan menghasilkan ramalan yang salah. Menangkap ini memerlukan pemantauan.

Itulah sebabnya terdapat perbezaan besar antara "model kerja" dan "model sedia pengeluaran".

Pembungkusan dan pembentangan model

Langkah pertama dalam meletakkan model ke dalam pengeluaran ialah membungkusnya: fail model, perpustakaan yang diperlukan, kod prapemprosesan dan maklumat versi bersama-sama sebagai keseluruhan yang boleh diterbitkan semula. Kontena (cth. Docker: meletakkan aplikasi dalam kotak terpencil dengan semua kebergantungannya) adalah standard di sini; Ia menghapuskan masalah "ia berfungsi pada mesin saya".

Dua corak asas penyajian model:

  • Dalam talian/masa nyata (dalam talian): Model terletak di belakang API, mengembalikan ramalan segera untuk setiap permintaan masuk. Latensi rendah adalah kritikal.
  • Kelompok: Model memproses set data yang besar secara berkala (mis. menjana skor untuk semua pelanggan pada waktu malam). Latensi tidak relevan, kecekapan adalah penting.

Mana satu yang betul bergantung pada keperluan perniagaan: pengesyoran segera dalam talian, skor risiko bulanan dalam kelompok.

Petua: "Masa nyata" ialah kos, bukan kos lalai. Batch jauh lebih murah dan mudah jika hasilnya akan digunakan dalam masa beberapa jam. Adakah anda benar-benar memerlukan jawapan segera? Tanya itu dulu.

Strategi pengedaran selamat

Membuka model baharu secara terus kepada semua trafik adalah berisiko; Kalau salah, semua kena. Corak pengedaran selamat:

  • Arahan bayangan: Model baharu menerima trafik pengeluaran, tetapi ramalannya tidak ditunjukkan kepada pengguna, hanya dilog. Ia dibandingkan dengan model lama untuk melihat sama ada ia selamat dalam data sebenar.
  • Penggunaan Canary: Model baharu mula-mula dilancarkan kepada peratusan kecil trafik (mis. 5%); Sekiranya tiada masalah, ia meningkat secara beransur-ansur.
  • Ujian A/B: Dua model dibentangkan kepada pengguna sebenar secara selari dan metrik perniagaan (penukaran, klik) dibandingkan.
  • Rollback: Keupayaan untuk kembali dengan cepat kepada versi lama jika model baharu ternyata buruk. Setiap pengerahan harus mempunyai pelan rollback.
Awas: Penggunaan tanpa pelan rollback tidak lengkap. Keupayaan untuk kembali kepada versi lama dalam beberapa minit melindungi pengguna apabila model baharu berkelakuan di luar jangkaan dalam pengeluaran. Uji ini sebelum penggunaan.

Pendekatan yang lemah / Pendekatan yang kuat

Lemah: "Model itu bagus dalam ujian, kami menyiarkannya secara langsung, kami membukanya kepada semua orang."

Güçlü: "Kami membekalkan model itu, melabelkannya sebagai versi. Mula-mula, kami menjalankannya dalam mod bayangan dengan trafik pengeluaran selama 3 hari, membandingkan ramalan dengan model lama — sisihan boleh diterima. Kemudian kami membukanya dengan 5% kenari, memantau metrik pemprosesan dan kependaman. Apabila tiada masalah, kami secara beransur-ansur meningkatkannya kepada 100% arahan.

Perbezaannya: pendekatan yang kukuh adalah secara beransur-ansur, diukur dan boleh diterbalikkan. Risiko terhad pada setiap langkah.

CI/CD dan automasi

CI/CD (Integrasi Berterusan / Penerapan Berterusan: saluran paip menguji dan mengeluarkan perubahan kod secara automatik) dalam ML merangkumi bukan sahaja kod tetapi juga data dan langkah model. Saluran paip ML CI/CD yang baik: menjalankan ujian apabila kod berubah, melaksanakan pengesahan data, melatih semula model (jika perlu), menyemak ambang penilaian dan hanya memajukan penggunaan jika ambang itu kekal. Prinsip "latihan adalah automatik, penggunaan adalah berasaskan ambang" menghalang model buruk daripada bocor secara senyap ke dalam pengeluaran.

AI sangat membantu semasa menyediakan saluran paip ini: menulis draf fail konfigurasi (YAML), kes ujian, skrip penggunaan. Tetapi anda menentukan ambang pengedaran (apa-apa metrik melebihi nilai yang diterbitkan) dan dasar pemulangan; ini adalah keputusan risiko perniagaan.

Infrastruktur kebolehulangan

Untuk menghasilkan semula gelagat model dalam pengeluaran, pendaftaran model: rekod yang menyimpan model yang dilatih dengan data dan kod yang mana dan metrik yang diterima. Untuk setiap model pengeluaran, perkara berikut harus boleh dijejaki: versi data latihan, versi kod (git commit), hiperparameter, skor penilaian dan tarikh penggunaan. Apabila masalah timbul, anda sepatutnya dapat menjawab soalan "model mana yang menghasilkan ramalan ini, dengan data yang mana?" dalam beberapa minit. Kami akan mendalami perkara ini dalam unit 11.

tiga kes mini

Kes 1 - Masalah ditangkap oleh pengedaran bayang-bayang. Model pengesyoran mengalahkan model lama dalam ujian. Menjalankannya dengan trafik pengeluaran dalam mod bayangan didapati menghasilkan pengesyoran yang sangat lemah untuk segmen pengguna tertentu (pengguna baharu) — data ujian kurang mewakili segmen ini. Model telah ditetapkan tanpa pernah dipaparkan kepada pengguna. Jika ia dibuka terus, pengalaman pengguna baharu akan terganggu.

Kes 2 - Pengedaran tidak boleh ditarik balik. Satu pasukan melancarkan model harga baharu kepada semua trafik, tanpa rancangan pemulangan semula. Model itu secara tidak dijangka meletakkan harga beberapa produk dengan sangat murah. Berbalik kepada versi lama mengambil masa berjam-jam kerana prosesnya belum siap. Terdapat kehilangan pendapatan yang serius. Selepas itu, ujian balik semula mandatori telah ditambahkan pada setiap penggunaan.

Kes 3 - Hanyutan data senyap. Corak penipuan muncul selama berbulan-bulan tanpa sebarang ralat. Tetapi taktik penipu berubah (data drift) dan penarikan balik model secara senyap menurun. Tiada siapa yang perasan kerana tiada pemantauan. Sebaik sahaja panel pemantauan pengedaran ramalan diwujudkan, hanyut dapat dilihat lebih awal. Kami akan meliputi pemantauan dalam unit 8.

Templat yang boleh disalin

Tulis draf rancangan penggunaan untuk model ini. Model: [apa yang dilakukannya], penggunaan: [dalam talian atau kelompok?] Harus termasuk:1) Pembungkusan (bekas, versi)2) Strategi penggunaan tambahan (bayangan/kenari/A-B) dan sebab3) Metrik untuk dijejaki (perniagaan + teknikal + kependaman)4) Pelan gulung balik dan cara menguji5) Ambang penggunaan (metrik yang mana) harus melebihi nilai tertentu

Semak saluran paip ML CI/CD ini:1) Adakah pengesahan data dalam baris?2) Bolehkah penggunaan diteruskan tanpa memegang ambang penilaian (sepatutnya tidak)?3) Adakah rollback automatik?4) Adakah data+kod+metrik dijejaki dalam pendaftaran model? Konfigurasi garisan: [config]

Bantu saya memutuskan sama ada pembentangan dalam talian atau kelompok sesuai untuk model ini. Berapa lama keputusan akan digunakan: [segera / minit / jam / hari]Jumlah permintaan yang dijangkakan: [nombor]Adakah terdapat kekangan kelewatan: [ms]Yang manakah anda akan cadangkan dari segi kos dan kerumitan dan mengapa?

Tulis prosedur pemulangan semula untuk model ini.- Apakah metrik/ambang yang mencetuskan prestasi yang lemah?- Apakah langkah pemulangan semula?- Berapa lama pemulangan perlu diambil (sasaran)?- Bagaimanakah cara untuk menguji prosedur ini sebelum pengeluaran?

Jadual corak persembahan

kriteria

Dalam talian (masa nyata)

Kumpulan

kelewatan

Kritikal (ms)

tidak penting

Penggunaan

Respons segera diperlukan

Skor berkala

kos

tinggi

rendah

kerumitan

tinggi

rendah

contoh

Pengesyoran langsung, penipuan

Skor risiko bulanan

Kesilapan biasa

  • Edarkan tanpa rancangan mendapatkan semula. Model yang salah mengenai keseluruhan pengguna.
  • Membuka terus kepada 100% trafik. Hadkan risiko dengan pengedaran berperingkat.
  • Tidak mewujudkan pemantauan. Model menghasilkan ralat secara senyap, tanpa ralat.
  • Persembahan masa nyata yang berlebihan. Walaupun batching mencukupi, kos dan kerumitan meningkat.
  • Tidak memautkan versi model-data-kod. Anda tidak boleh menghasilkan semula masalah itu.
  • Keluaran automatik tanpa ambang pengedaran. Model jahat menyelinap masuk secara senyap.

Secara ringkasnya

Memindahkan model ke pengeluaran adalah tugas kejuruteraan yang berbeza dan selalunya lebih sukar daripada melatihnya. ML memerlukan disiplin tambahan kerana ia bergantung pada trio model kod-data: pembungkusan dan versi, corak penghantaran (dalam talian/kelompok) yang sesuai dengan keperluan perniagaan, penggunaan secara beransur-ansur dan boleh diterbalikkan, CI/CD terkawal ambang dan pendaftaran model. Kecerdasan buatan ialah bantuan yang berkuasa dalam menjana kod dan konfigurasi infrastruktur ini; tetapi ambang pengedaran, dasar cakar balik dan keputusan risiko adalah milik anda. Pengedaran tanpa pelan rollback tidak lengkap.

Tugasan permohonan

Containerize (Docker) model dan labelkan versi. Tentukan sama ada anda akan menawarkan dalam talian atau kelompok berdasarkan keperluan perniagaan anda dan tulis justifikasi anda. Dokumentasikan pelan penggunaan berperingkat (bayangan atau kenari) dan prosedur rollback yang diuji. Pastikan untuk merekodkan versi data, komit kod dan skor penilaian dalam daftar model.

senarai semak

  • [ ] Model dibungkus dan versi (bekas + label).
  • [ ] Corak persembahan (online/batch) dipilih mengikut keperluan perniagaan.
  • [ ] Strategi penggunaan berperingkat (bayangan/kenari) dilaksanakan.
  • [ ] Prosedur pemulangan ditulis dan diuji.
  • [ ] CI/CD tidak memajukan penggunaan sebelum ambang penilaian dipenuhi.
  • [ ] Pendaftaran model memegang pautan data+kod+metrik.