Bahkan dengan setumpuk alat MLOps yang sempurna, tim masih kesulitan menghadirkan produk ML. Jadi jika alat bukan satu-satunya bagian dari teka-teki, apa yang tersisa? Di posting terakhir saya , saya berpendapat bagian yang tersisa adalah Budaya dan Proses.

Mari selami proses MLOps — khususnya, beberapa bagian dasar yang membuat sebagian besar tim salah . Seperti apa proses MLOps yang berhasil, dan bagaimana praktisi ML individu dapat membantu membangun proses tersebut?

TL;DR

• Mulailah dengan produk, bukan model
• Survei data di produksi , bukan di gudang Anda
• Mulailah dengan sederhana — dengan data dan model
• Bermitra dengan insinyur

Mulailah dengan produk ML

Mungkin praktik terpenting yang memungkinkan proyek ML berhasil adalah mendesain produk , bukan model . Salah satu jebakan terbesar yang pernah saya lihat di lusinan perusahaan adalah menyerahkan "proyek" ke tim data, alih-alih melibatkan mereka dalam fase desain produk.

Untuk membangun produk ML yang sukses, tiga pemangku kepentingan perlu dilibatkan dalam merancang produk:

• PM / Pemangku Kepentingan Bisnis : Kesuksesan itu seperti apa?
• Orang ML : Apa yang (mungkin) mungkin dilakukan dengan ML?
• Insinyur Produk : Apa yang layak, dan apa kendalanya?

Beberapa contoh tim yang kurang selaras:

• Orang ML mengoptimalkan akurasi model (bukan hasil bisnis!)
• Proyek dimulai yang mungkin tidak layak untuk diselesaikan dengan ML
• Model tidak memenuhi batasan kinerja dalam produksi
• Fiturnya menantang atau tidak mungkin dihitung dalam produksi

• Orang ML memahami pengorbanan akurasi vs. waktu ke pasar
• Pemantauan dibangun pada hari nol untuk memastikan hasil bisnis diukur secara konsisten
• Insinyur membantu orang ML memahami lanskap data produksi
• Model SLA didefinisikan dan diukur dengan jelas

Ini adalah contoh “penyelarasan yang baik” di bagian terakhir, tetapi ini layak untuk bagiannya sendiri. Hampir semua pembuat ML yang saya lihat memulai proyek ML mereka dengan survei data yang tersedia. Masalah? Mereka biasanya mensurvei data yang tersedia untuk pelatihan , bukan data yang akan tersedia di produksi.

Beberapa orang mungkin bertanya — bukankah seharusnya semua data yang tersedia untuk pelatihan tersedia dalam sistem produksi?

Sebagian besar waktu, jawabannya adalah ya , tetapi dengan banyak tanda bintang. Seberapa cepat data itu tersedia? Seberapa segar data itu? Berapa banyak prapemrosesan yang perlu dilakukan pada data prod agar dapat dikonsumsi? Siapa yang memiliki data itu?

Begitu banyak proyek ML yang terhenti karena masalah dengan data produksi. Saya telah melihat berulang kali bahwa ada keterputusan yang sangat besar antara orang ML dan teknisi produk. Contoh dua fitur tidak berbahaya dengan persyaratan yang sangat berbeda:

• Kode pos rumah pengguna : mungkin sangat mudah digunakan dalam produksi. Meminta basis data.
• Lokasi rata-rata pengguna dalam lima menit terakhir : mungkin PITA! Data lokasi pengguna ada di Kafka Stream? Seberapa segar yang dibutuhkan? Agregasi streaming itu sulit! Mungkin melatih/menyajikan masalah miring!

Mulailah dengan sederhana

Mungkin saran ML yang paling umum, tapi itu saran yang bagus. Mulailah dengan solusi sederhana.

Tambahan saya — kebanyakan orang akan memberitahu Anda untuk memulai dengan model sederhana , tetapi sama pentingnya untuk memulai dengan data sederhana! Untuk memainkan contoh di atas:

• Lokasi rata-rata pengguna dalam lima menit terakhir: sulit
• Lokasi terbaru pengguna: mungkin jauh lebih mudah!

Anda mungkin melakukan perdagangan itu setiap saat. Anda selalu dapat membangun V2 dengan fitur yang lebih bagus, dan akan jauh lebih mudah untuk membangun peningkatan bertahap daripada mengirimkan sesuatu yang rumit untuk pertama kalinya.

Bermitra dengan insinyur

Kemungkinan besar jika Anda seorang ilmuwan data, tidak semua pertanyaan yang diajukan di atas jelas untuk dijawab. Ketika saya terakhir kali membuat model ML, saya tidak tahu apa itu data streaming (apalagi memikirkannya).

Solusinya adalah berteman dengan para insinyur dan bekerja bersama mereka selama pengembangan model ML. Membangun proyek perangkat lunak apa pun tidak dapat dilakukan dalam silo, dan ML dalam silo bahkan lebih buruk lagi. Insinyur dapat membantu dengan "data apa yang tersedia", "kendala apa yang harus saya ketahui", "SLA apa yang layak", dan banyak lagi.

Bekerja dengan seorang insinyur lebih awal dan sering. Anda akan membangun proyek jauh lebih cepat.

Kesimpulan

Langkah-langkah ini bukanlah gambaran menyeluruh dari proses MLOps — ada banyak bagian bergerak yang mengarah pada kesuksesan (peninjauan kode, CI/CD, pemantauan, …). Ini adalah titik awal. Seperti disebutkan di atas, sebagian besar kegagalan ML yang saya lihat adalah masalah penyelarasan. Pedoman proses ini terutama dimaksudkan untuk membantu Anda menyelaraskan tim Anda untuk sukses.

Anda membutuhkan fondasi yang kuat untuk membangun praktik MLOps yang luar biasa.

David Hershey adalah investor di Unusual Ventures , tempat dia berinvestasi dalam pembelajaran mesin dan infrastruktur data. David memulai karirnya di Ford Motor Company, di mana dia memulai tim infrastruktur ML mereka. Baru-baru ini, dia bekerja di Tecton dan Ditentukan AI , membantu tim MLOps mengadopsi teknologi tersebut. Jika Anda membangun perusahaan infrastruktur data atau ML, hubungi David di LinkedIn .