🏆 🔏 👩🏾‍🏫 Mengapa kita membutuhkan DevOps di bidang data ML 🌫️ 🦆 👋🏽

Menyebarkan pembelajaran mesin (ML) dalam produksi bukanlah tugas yang mudah, tetapi pada kenyataannya, ini adalah urutan besarnya lebih sulit daripada menggunakan perangkat lunak konvensional. Akibatnya, sebagian besar proyek ML tidak akan pernah melihat cahaya hari - dan produksi - karena sebagian besar organisasi menyerah dan menyerah mencoba menggunakan ML untuk mempromosikan produk mereka dan melayani pelanggan.

Sejauh yang bisa kita lihat, kendala mendasar bagi sebagian besar tim untuk membuat dan menggunakan ML dalam produksi pada skala yang diharapkan adalah bahwa kita masih belum mampu membawa praktik DevOpsdalam pembelajaran mesin. Proses membuat dan menggunakan model ML sebagian diungkapkan oleh solusi MLOps yang telah dirilis, tetapi mereka kekurangan dukungan dari salah satu aspek yang paling sulit dari data ML:.

Dalam artikel ini, kita membahas mengapa industri membutuhkan solusi DevOps untuk data ML, dan bagaimana kesulitan unik data ML menghambat upaya untuk menerapkan ML ke dalam praktik dan menerapkannya dalam produksi. Artikel ini menjelaskan kekosongan dalam ekosistem infrastruktur ML saat ini dan menyarankan untuk mengisinya dengan Tecton, platform data terpusat untuk pembelajaran mesin. Klik di sini untuk membaca artikel dari co-founder saya Mike untuk rincian lebih lanjut tentang peluncuran Tecton.

Tecton diciptakan oleh tim insinyur yang menciptakan platform ML internal untuk perusahaan seperti Uber, Google, Facebook, Twitter, Airbnb, AdRoll, dan Quora. Investasi signifikan dari perusahaan-perusahaan ini di ML memungkinkan pengembangan proses dan alat untuk penggunaan ekstensif ML untuk organisasi dan produk mereka. Pelajaran yang disajikan dalam artikel ini, serta platform Tecton itu sendiri, sebagian besar didasarkan pada pengalaman tim penerapan ML kami dalam produksi selama beberapa tahun terakhir.

Ingat waktu ketika rilis perangkat lunak itu panjang dan menyakitkan?

Pengembangan perangkat lunak dan proses penyebaran dua puluh tahun yang lalu dan proses pengembangan aplikasi ML pada hari-hari kita memiliki banyak kesamaan: sistem umpan balik ternyata sangat panjang, dan pada saat Anda merilis produk, persyaratan awal dan desain Anda sudah usang. Dan kemudian, pada akhir masa perang, serangkaian praktik terbaik untuk pengembangan perangkat lunak dalam bentuk DevOps muncul , menyediakan metode untuk mengelola siklus hidup pengembangan dan memungkinkan kami untuk mencapai peningkatan yang berkelanjutan dan cepat.

Pendekatan DevOps memungkinkan para insinyur untuk bekerja di basis kode umum yang terdefinisi dengan baik. Setelah perubahan bertahap siap untuk ditempatkan, insinyur memvalidasinya melalui sistem kontrol versi. Proses integrasi dan pengiriman berkelanjutan (CD / CI) mengambil perubahan terbaru, melakukan pengujian unit, membuat dokumentasi, melakukan pengujian integrasi, dan sebagai hasilnya, secara terkontrol melepaskan perubahan pada produksi atau menyiapkan rilis untuk distribusi.

Ara. 1: proses DevOps yang khas

Fitur utama DevOps:

Pemrogram memiliki kode mereka dari awal hingga akhir. Mereka diberdayakan dan bertanggung jawab penuh untuk setiap baris kode dalam produksi. Rasa kepemilikan ini pada umumnya meningkatkan kualitas kode, serta ketersediaan dan keandalan program.
Tim dapat dengan cepat mengulangi proses dan tidak dibatasi oleh siklus berbulan-bulan dari model kaskade. Sebagai gantinya, mereka dapat menguji fitur baru dengan pengguna nyata dengan segera.
Masalah kinerja dan keandalan cepat terdeteksi dan dianalisis. Jika metrik kinerja turun segera setelah penerapan terakhir, rollback otomatis dipicu, dan perubahan yang menyebabkan penerapan dalam kode sangat mungkin menyebabkan metrik jatuh.

Saat ini, banyak tim pengembangan telah mengambil pendekatan terpadu sebagai basis.

... Secara umum, penyebaran ML masih panjang dan menyakitkan

Berlawanan dengan pengembangan perangkat lunak, tidak ada proses otomatis yang terdefinisi dengan baik untuk produksi cepat dalam analisis data. Proses membuat aplikasi ML dan menyebarkannya ke dalam suatu produk terdiri dari beberapa langkah:

Gambar. 2: spesialis analisis data harus mengoordinasikan pekerjaan mereka antara beberapa tim di berbagai wilayah

Penemuan dan akses ke sumber data. Spesialis ilmu data di sebagian besar perusahaan menghabiskan hingga 80% dari waktu mereka mencari sumber data untuk memodelkan masalah mereka. Ini sering membutuhkan koordinasi lintas fungsional dengan insinyur data dan tim pengawas.
. , . , , .
. . ( ).
Penempatan dan integrasi model. Langkah ini biasanya melibatkan integrasi dengan layanan yang menggunakan model untuk peramalan. Misalnya, aplikasi seluler pengecer online yang menggunakan model rekomendasi untuk memprediksi penawaran produk.
Pengaturan pemantauan. Sekali lagi, untuk memastikan bahwa model ML dan proses data bekerja dengan benar, bantuan programmer diperlukan.

Akibatnya, tim ML menghadapi masalah yang sama yang dihadapi oleh programmer dua puluh tahun yang lalu:

Pakar ilmu data tidak memiliki kepemilikan penuh atas siklus hidup model dan fungsionalitas. Untuk menerapkan suntingan dan mendukung mereka dalam produksi, mereka harus bergantung pada orang lain.
data science . . . , , data science, , , , , .

. 3: ,

. data science, . , , , .

DevOps ML . DevOps ML data

Seperti MLOps platform seperti Sagemaker Kubeflow dan bergerak ke arah yang benar dalam perjalanan ke bantuan perusahaan untuk menyederhanakan produksi ML, jadi kita bisa mengamati bagaimana MLOps memperkenalkan prinsip-prinsip dan alat-alat DevOps di ML. Untuk memulai, mereka membutuhkan investasi awal yang cukup baik, tetapi setelah integrasi yang tepat mereka dapat memperluas kemampuan spesialis ilmu data di bidang pelatihan, manajemen dan produksi model ML.

Sayangnya, sebagian besar alat MLOps cenderung berfokus pada alur kerja di sekitar model itu sendiri (pelatihan, implementasi, manajemen), yang menciptakan sejumlah kesulitan untuk ML yang ada. Aplikasi ML ditentukan oleh kode, model, dan data.. Keberhasilan mereka tergantung pada kemampuan untuk membuat data ML berkualitas tinggi dan mengirimkannya ke produksi dengan cukup cepat dan stabil ... jika tidak, ini adalah "sampah masuk, sampah keluar" lainnya. Diagram berikut, dipilih secara khusus dan diadaptasi dari karya Google tentang utang teknis dalam ML, menggambarkan elemen "data-centric" dan "model-centric" dalam sistem ML. Saat ini, platform MLOps membantu dengan banyak elemen "model-centric", tetapi hanya dengan beberapa elemen "data-centric" atau tidak memengaruhi mereka sama sekali:

Gbr. 4: Model dan elemen atacentric dari sistem ML. Saat ini, elemen model-sentris sebagian besar dicakup oleh sistem MLOps.

Bagian berikutnya menunjukkan beberapa tes paling sulit yang kami temui dalam menyederhanakan produksi ML. Itu bukan contoh komprehensif, tetapi dirancang untuk menunjukkan masalah yang kami temui selama pengelolaan siklus hidup data ML (fungsi dan label):

Akses ke sumber data sumber yang benar
Membuat Fungsi dan Label dari Sumber Data
Menggabungkan fungsi dalam data pelatihan
Perhitungan dan penerbitan fungsi dalam produksi
Pelacakan produksi

Pengingat kecil sebelum kita menyelam lebih jauh: fungsi ML adalah data yang berfungsi sebagai input ke model untuk membuat keputusan. Misalnya, layanan pengiriman makanan ingin menunjukkan waktu pengiriman yang diharapkan dalam aplikasinya. Untuk melakukan ini, perlu untuk memprediksi durasi persiapan hidangan tertentu, di restoran tertentu, pada waktu tertentu. Salah satu sinyal mudah untuk membuat ramalan seperti itu - proxy untuk seberapa sibuk restoran itu - akan menjadi "akun akhir" dari pesanan yang masuk dalam 30 menit terakhir. Fungsi dihitung berdasarkan aliran data awal dari urutan pesanan:

Gbr. 5: Data awal diubah oleh transformasi fungsi menjadi nilai fungsi

Tanggal Tes # 1: Mengakses Data Sumber Kanan

Untuk membuat fungsi atau model apa pun, seorang spesialis ilmu data pertama-tama perlu menemukan sumber data yang benar dan mendapatkan akses ke sana. Ada beberapa kendala di sepanjang jalan:

Penemuan Data: Profesional perlu tahu di mana sumber data berada. Sebuah solusi hebat adalah sistem katalogisasi data (seperti Lyft's Amundsen ), tetapi mereka belum digunakan secara universal. Seringkali data yang diperlukan tidak ada dan oleh karena itu pertama-tama harus dibuat atau di katalog.
Persetujuan akses: Seringkali berlarian di antara otoritas untuk mendapatkan izin untuk mengakses data yang akan menyelesaikan masalah adalah langkah wajib di jalur para pakar ilmu data.
: , , . , .

- #2:

Sumber data dapat berasal dari banyak sumber, masing-masing dengan sendiri, properti penting yang memengaruhi jenis fungsi yang diekstrak darinya. Properti ini termasuk dukungan sumber data untuk tipe transformasi , relevansi data , dan jumlah arsip data yang tersedia :

Gambar. 6: Sumber data yang berbeda memiliki pendekatan berbeda untuk berbagai jenis transformasi data dan menyediakan akses ke jumlah data yang berbeda tergantung pada relevansinya.

Penting untuk mempertimbangkan properti ini, karena jenis sumber data menentukan jenis fungsi yang dapat diperoleh spesialis ilmu data dari sumber data:

( Snowflake Redshift) ( ). , , « ».
( MongoDB MySQL) . , 24 .
( Kafka) ( ). . , « 30 ».
Data kueri prediksi adalah data awal peristiwa yang terjadi secara real time tepat sebelum prakiraan ML dibuat, misalnya, kueri yang baru saja dimasukkan oleh pengguna di bilah pencarian. Sekalipun data seperti itu terbatas, sering kali "segar" sebanyak mungkin dan mengandung sinyal yang mudah diprediksi. Data tersebut dilengkapi dengan permintaan prediksi dan dapat digunakan dalam perhitungan waktu nyata seperti mencari perkiraan kesamaan antara permintaan pencarian pengguna dan dokumen dalam array pencarian.

Ke depan, kami menarik perhatian untuk: menggabungkan data dari berbagai sumber dengan karakteristik yang saling melengkapi memungkinkan Anda untuk membuat fungsi yang sangat baik. Pendekatan semacam itu membutuhkan implementasi dan pengelolaan transformasi fungsi yang lebih maju.

Tanggal Tes # 3: Menggabungkan Fungsi ke dalam Data Pelatihan

Pembentukan set pelatihan atau data uji membutuhkan menggabungkan data dari fungsi yang sesuai. Dalam hal ini, perlu untuk melacak banyak detail yang dapat memiliki efek kritis pada model. Dua yang paling berbahaya adalah:

Kebocoran data: Spesialis ilmu data perlu memastikan bahwa model mereka dilatih tentang informasi yang benar dan tidak mengizinkan "kebocoran" informasi yang tidak diinginkan ke dalam data pelatihan. Data tersebut dapat berupa: data dari ruang uji, data dari kebenaran dasar, data dari masa depan, atau informasi yang melanggar proses persiapan penting (misalnya, anonimisasi).
: — . ( ). , data science , .

- #4:

Setelah model dioperasikan dalam waktu nyata, untuk membuat prakiraan yang benar dan relevan, model ini perlu secara konstan memasok data fungsi baru - seringkali dalam skala besar dan dengan waktu tunggu minimal.

Bagaimana seharusnya kita meneruskan data ini ke model? Langsung dari sumbernya? Menerima dan mentransfer data dari penyimpanan dapat berlangsung beberapa menit, berhari-hari, berjam-jam, atau bahkan berhari-hari, yang terlalu lama untuk output data secara real time dan oleh karena itu dalam banyak kasus tidak mungkin.

Dalam kasus seperti itu, perhitungan fungsi dan konsumsi fungsi harus dilepaskan. Untuk perhitungan pendahuluan (pra-perhitungan)fungsi dan pengiriman mereka ke gudang data produksi dioptimalkan untuk pengiriman, perlu menggunakan proses ETL. Proses-proses ini menciptakan kesulitan tambahan dan memerlukan biaya perawatan baru:

Mencari kompromi yang optimal antara relevansi dan profitabilitas: Membuka blokir perhitungan dan konsumsi fungsi memberi prioritas pada relevansi. Seringkali, karena kenaikan biaya, proses fungsi dapat berjalan lebih sering dan, sebagai akibatnya, menghasilkan data yang lebih relevan. Kompromi yang benar bervariasi berdasarkan fungsi dan kasus penggunaan. Misalnya, fungsi agregasi dari jendela faktur akhir pengiriman tiga puluh menit akan masuk akal jika diperbarui lebih sering daripada fungsi yang sama dengan jendela faktur akhir dua minggu.

Integrasi proses fungsi:Mempercepat pembuatan fungsi memerlukan memperoleh data dari beberapa sumber yang berbeda, dan sebagai hasilnya, menyelesaikan masalah yang terkait dengan ini lebih rumit daripada ketika bekerja dengan hanya satu sumber data, yang telah kita diskusikan sebelumnya. Koordinasi proses tersebut dan integrasi hasilnya ke dalam satu vektor fungsi memerlukan pendekatan serius dari rekayasa data.

Pencegahan distorsi dalam pelatihan ( pelatihan / penyajian miring ):Perbedaan antara hasil belajar dan proses kerja dapat menyebabkan distorsi dalam pembelajaran. Distorsi selama pelatihan agak sulit dideteksi, dan kehadiran mereka dapat membuat prediksi model tidak dapat digunakan. Model dapat berperilaku kacau ketika menggambar kesimpulan berdasarkan data yang dihasilkan berbeda dari yang dilatih. Dalam dirinya sendiri, masalah distorsi dan bekerja dengan mereka layak mendapatkan serangkaian artikel terpisah. Namun, ada baiknya menyoroti dua risiko khas:

: ( ) , . Null? ? . .

. 7 ,

́ : - ( ). , , , . , , . — , , , .

Ara. 8: Grafik menunjukkan akun akhir pesanan: pada (1) nilai fungsi yang dikeluarkan untuk perkiraan dan diperbarui setiap 10 menit ditampilkan; pada (2) data pelatihan diperlihatkan bahwa secara keliru menampilkan nilai sebenarnya lebih jelas dibandingkan dengan fungsi yang dikeluarkan untuk produksi

Tanggal Tes # 5: Fitur Pelacakan pada Produksi

Sesuatu akan pecah, meskipun semua upaya untuk benar menghindari masalah di atas. Ketika sistem ML crash, hampir selalu terjadi karena "pelanggaran integritas data". Istilah ini dapat menunjukkan banyak alasan berbeda, yang masing-masing memerlukan pelacakan. Contoh pelanggaran integritas data:

: , , . , , . , .
: , . , , (, ), .
: . , (, , ) .
Tanggung jawab yang tidak jelas untuk kualitas data: Dalam kasus di mana fungsi dapat menerima data sumber dari beberapa sumber distribusi yang berbeda, siapa yang akhirnya bertanggung jawab atas kualitas fungsi? Spesialis data-sains yang menciptakan fungsi? Spesialis data-sains yang melatih model? Pemilik saluran umpan data? Programmer yang melakukan integrasi model ke dalam produksi? Dalam kasus di mana tanggung jawab tidak jelas, masalah tetap tidak terselesaikan terlalu lama.

Tes semacam itu menciptakan rintangan yang hampir tidak dapat diatasi, bahkan untuk tim paling maju di bidang ilmu data dan teknik ML. Memecahkannya membutuhkan sesuatu yang lebih baik daripada status quo yang tidak berubah dari sebagian besar perusahaan, ketika solusi yang dibuat khusus tetap menjadi satu-satunya jawaban untuk sebagian dari masalah ini.

Memperkenalkan Tecton: Platform Pembelajaran Mesin Tanggal

Di Tecron, kami menciptakan platform tanggal untuk pembelajaran mesin untuk memberikan bantuan dengan masalah paling umum dan paling sulit di bidang ilmu data.

Pada level tinggi, platform Tecron memiliki:

Fungsi proses untuk mengubah data sumber Anda menjadi fungsi dan label
Repositori fungsi untuk menyimpan fungsi yang diarsipkan dan menandai data
Server fungsi untuk mengeluarkan nilai fungsi terbaru ke produksi
SDK untuk melatih data dan memanipulasi proses fungsi
UI Web untuk memantau dan melacak fitur, label, dan kumpulan data
Mesin pemantauan untuk menentukan kualitas data atau masalah drift, dan peringatan

Ara. 9: Menjadi platform data pusat untuk ML, Tecton menyediakan fungsi dalam lingkungan pengembangan dan produksi.

Platform ini memungkinkan tim ML untuk membawa praktik DevOps ke data ML:

Perencanaan: Fitur Tecron disimpan dalam repositori pusat. Ini memungkinkan spesialis ilmu data untuk berbagi, menemukan, dan menggunakan tenaga masing-masing.
Kode: Tecton memungkinkan pengguna untuk mengatur proses transformasi fungsi yang sederhana dan fleksibel.
Build: Tecton mengkompilasi fungsi menjadi tugas pemrosesan data berkinerja tinggi.
Pengujian: Tecton mendukung pengujian fungsional dan integrasi fungsi.
Rilis: Tecton terintegrasi erat dengan git. Semua deskripsi fungsi memiliki kontrol versi dan mudah direproduksi.
: Tecton ( Spark). Tecron.
: Tecton data science , .
: Tecton .

Tentu saja, data ML tanpa model ML tidak akan memberi Anda implementasi praktis dari ML. Oleh karena itu, Tecton menyediakan API yang fleksibel dan terintegrasi dengan platform ML yang ada. Kami mulai dengan Databricks, SageMaker, dan Kuberflow, dan terus berintegrasi dengan komponen ekosistem pelengkap.

Mengapa kita membutuhkan DevOps di bidang data ML