Membangun pipeline MLOps end-to-end untuk pemeriksaan kualitas visual di edge – Bagian 1 | Layanan Web Amazon

Keberhasilan penerapan model pembelajaran mesin (ML) di lingkungan produksi sangat bergantung pada pipeline ML end-to-end. Meskipun mengembangkan saluran pipa semacam itu bisa menjadi suatu tantangan, hal ini menjadi lebih rumit lagi ketika berhadapan dengan masalah kasus penggunaan edge ML. Pembelajaran mesin di edge adalah konsep yang menghadirkan kemampuan menjalankan model ML secara lokal ke perangkat edge. Untuk menerapkan, memantau, dan memelihara model-model ini di edge, diperlukan pipeline MLOps yang kuat. Pipeline MLOps memungkinkan untuk mengotomatiskan siklus hidup ML penuh mulai dari pelabelan data hingga pelatihan dan penerapan model.

Penerapan pipeline MLOps di edge menimbulkan kompleksitas tambahan yang membuat proses otomatisasi, integrasi, dan pemeliharaan menjadi lebih menantang karena adanya peningkatan overhead operasional. Namun, menggunakan layanan yang dibuat khusus seperti Amazon SageMaker dan Rumput Hijau AWS IoT memungkinkan Anda mengurangi upaya ini secara signifikan. Dalam seri ini, kami memandu Anda melalui proses merancang dan membangun pipeline MLOps end-to-end yang terintegrasi untuk kasus penggunaan visi komputer di edge menggunakan SageMaker, AWS IoT Greengrass, dan Kit Pengembangan AWS Cloud (AWS-CDK).

Posting ini berfokus pada perancangan arsitektur pipeline MLOps secara keseluruhan; bagian 2 dan bagian 3 seri ini fokus pada implementasi masing-masing komponen. Contoh penerapannya telah kami sediakan pada lampiran Repositori GitHub untuk Anda coba sendiri. Jika Anda baru memulai dengan MLOps di edge di AWS, lihat MLOps di tepi dengan Amazon SageMaker Edge Manager dan AWS IoT Greengrass untuk ikhtisar dan arsitektur referensi.

Kasus penggunaan: Memeriksa kualitas tag logam

Sebagai seorang insinyur ML, penting untuk memahami kasus bisnis yang sedang Anda kerjakan. Jadi sebelum kita mendalami arsitektur pipeline MLOps, mari kita lihat contoh kasus penggunaan untuk postingan ini. Bayangkan lini produksi pabrikan yang mengukir label logam untuk membuat label bagasi yang disesuaikan. Proses jaminan kualitas mahal karena label logam mentah perlu diperiksa secara manual untuk mengetahui adanya cacat seperti goresan. Untuk membuat proses ini lebih efisien, kami menggunakan ML untuk mendeteksi tag yang salah di awal proses. Hal ini membantu menghindari cacat yang mahal pada tahap selanjutnya dari proses produksi. Model harus mengidentifikasi kemungkinan cacat seperti goresan hampir secara real-time dan menandainya. Di lingkungan pabrik manufaktur, Anda sering kali harus berurusan dengan tidak adanya konektivitas atau bandwidth yang terbatas dan peningkatan latensi. Oleh karena itu, kami ingin menerapkan solusi ML on-edge untuk pemeriksaan kualitas visual yang dapat menjalankan inferensi secara lokal di lantai produksi dan mengurangi persyaratan terkait konektivitas. Agar contoh kami tetap jelas, kami melatih model yang menandai goresan yang terdeteksi dengan kotak pembatas. Gambar berikut adalah contoh tag dari dataset kami yang diberi tanda tiga goresan.

Mendefinisikan arsitektur pipa

Kami kini telah mendapatkan kejelasan mengenai kasus penggunaan kami dan masalah spesifik ML yang ingin kami atasi, yang berkisar pada deteksi objek di edge. Sekarang saatnya merancang arsitektur untuk pipeline MLOps kita. Pada tahap ini, kami belum melihat teknologi atau layanan tertentu, melainkan komponen tingkat tinggi dari saluran kami. Untuk melatih kembali dan menerapkan dengan cepat, kita perlu mengotomatiskan seluruh proses end-to-end: mulai dari pelabelan data, pelatihan, hingga inferensi. Namun, ada beberapa tantangan yang membuat penyiapan pipeline untuk kasus edge menjadi sangat sulit:

• Membangun bagian yang berbeda dari proses ini memerlukan keahlian yang berbeda. Misalnya, pelabelan dan pelatihan data memiliki fokus ilmu data yang kuat, penerapan edge memerlukan spesialis Internet of Things (IoT), dan otomatisasi seluruh proses biasanya dilakukan oleh seseorang yang memiliki keahlian DevOps.
• Bergantung pada organisasi Anda, seluruh proses ini bahkan mungkin diterapkan oleh banyak tim. Untuk kasus penggunaan kami, kami bekerja dengan asumsi bahwa tim terpisah bertanggung jawab atas pelabelan, pelatihan, dan penerapan.
• Lebih banyak peran dan keahlian berarti persyaratan yang berbeda dalam hal peralatan dan proses. Misalnya, data scientist mungkin ingin memantau dan bekerja dengan lingkungan notebook yang mereka kenal. Insinyur MLOps ingin bekerja menggunakan alat infrastruktur sebagai kode (IaC) dan mungkin lebih familiar dengannya Konsol Manajemen AWS.

Apa dampaknya bagi arsitektur saluran pipa kita?

Pertama, penting untuk mendefinisikan dengan jelas komponen utama sistem end-to-end yang memungkinkan tim berbeda bekerja secara independen. Kedua, antarmuka antar tim yang terdefinisi dengan baik harus ditentukan untuk meningkatkan efisiensi kolaborasi. Antarmuka ini membantu meminimalkan gangguan antar tim, memungkinkan mereka mengubah proses internal sesuai kebutuhan selama mereka mematuhi antarmuka yang ditentukan. Diagram berikut mengilustrasikan tampilan pipeline visi komputer kita.

Mari kita periksa keseluruhan arsitektur pipeline MLOps secara mendetail:

1. Prosesnya dimulai dengan kumpulan gambar mentah tag logam, yang ditangkap menggunakan perangkat kamera edge di lingkungan produksi untuk membentuk kumpulan data pelatihan awal.
2. Langkah selanjutnya melibatkan pelabelan gambar-gambar ini dan menandai cacat menggunakan kotak pembatas. Penting untuk membuat versi kumpulan data berlabel, memastikan ketertelusuran dan akuntabilitas untuk data pelatihan yang digunakan.
3. Setelah kita memiliki kumpulan data berlabel, kita dapat melanjutkan dengan pelatihan, penyesuaian, evaluasi, dan pembuatan versi model kita.
4. Jika kami puas dengan performa model kami, kami dapat menerapkan model tersebut ke perangkat edge dan menjalankan inferensi langsung di edge.
5. Saat model beroperasi dalam produksi, perangkat kamera edge menghasilkan data gambar berharga yang berisi cacat dan kasus edge yang sebelumnya tidak terlihat. Kami dapat menggunakan data ini untuk lebih meningkatkan performa model kami. Untuk mencapai hal ini, kami menyimpan gambar yang modelnya memprediksi dengan keyakinan rendah atau membuat prediksi yang salah. Gambar-gambar ini kemudian ditambahkan kembali ke kumpulan data mentah kami, memulai seluruh proses lagi.

Penting untuk diperhatikan bahwa data gambar mentah, kumpulan data berlabel, dan model terlatih berfungsi sebagai antarmuka yang terdefinisi dengan baik di antara saluran yang berbeda. Insinyur MLOps dan ilmuwan data memiliki fleksibilitas untuk memilih teknologi yang akan mereka gunakan selama mereka secara konsisten menghasilkan artefak ini. Yang paling penting, kami telah membentuk lingkaran umpan balik yang tertutup. Prediksi yang salah atau berkeyakinan rendah yang dibuat dalam produksi dapat digunakan untuk menambah kumpulan data kami secara berkala dan secara otomatis melatih ulang dan menyempurnakan model.

Arsitektur sasaran

Kini arsitektur tingkat tinggi telah ditetapkan, saatnya melangkah lebih dalam dan melihat bagaimana kita dapat membangunnya dengan layanan AWS. Perhatikan bahwa arsitektur yang ditunjukkan dalam postingan ini mengasumsikan Anda ingin mengambil kendali penuh atas keseluruhan proses ilmu data. Namun, jika Anda baru memulai pemeriksaan kualitas, kami merekomendasikannya Amazon Lookout untuk Visi. Ini memberikan cara untuk melatih model pemeriksaan kualitas Anda sendiri tanpa harus membuat, memelihara, atau memahami kode ML. Untuk informasi lebih lanjut, lihat Amazon Lookout for Vision kini mendukung inspeksi visual terhadap cacat produk di bagian edge.

Namun, jika Anda ingin mengambil kendali penuh, diagram berikut menunjukkan seperti apa sebuah arsitektur.

Mirip dengan sebelumnya, mari kita telusuri alur kerja langkah demi langkah dan mengidentifikasi layanan AWS mana yang sesuai dengan kebutuhan kita:

1. Layanan Penyimpanan Sederhana Amazon (Amazon S3) digunakan untuk menyimpan data gambar mentah karena menyediakan solusi penyimpanan berbiaya rendah.
2. Alur kerja pelabelan diatur menggunakan Fungsi Langkah AWS, mesin alur kerja tanpa server yang memudahkan pengaturan langkah-langkah alur kerja pelabelan. Sebagai bagian dari alur kerja ini, kami menggunakan Kebenaran Dasar Amazon SageMaker untuk sepenuhnya mengotomatiskan pelabelan menggunakan pekerjaan pelabelan dan tenaga kerja manusia yang dikelola. AWS Lambda digunakan untuk menyiapkan data, memulai pekerjaan pelabelan, dan menyimpan label Toko Fitur Amazon SageMaker.
3. SageMaker Feature Store menyimpan label. Hal ini memungkinkan kami mengelola dan berbagi fitur secara terpusat dan memberi kami kemampuan pembuatan versi data bawaan, yang menjadikan pipeline kami lebih tangguh.
4. Kami mengatur pembuatan model dan alur pelatihan menggunakan Pipa Amazon SageMaker. Ini terintegrasi dengan fitur SageMaker lain yang diperlukan melalui langkah-langkah bawaan. Pekerjaan Pelatihan SageMaker digunakan untuk mengotomatiskan pelatihan model, dan Pekerjaan Pemrosesan SageMaker digunakan untuk menyiapkan data dan mengevaluasi kinerja model. Dalam contoh ini, kami menggunakan Ultralitik YOLOv8 Paket Python dan arsitektur model untuk melatih dan mengekspor model deteksi objek ke ONNX Format model ML untuk portabilitas.
5. Jika performanya dapat diterima, model yang dilatih akan didaftarkan Registri Model Amazon SageMaker dengan nomor versi tambahan terlampir. Ini bertindak sebagai antarmuka kami antara pelatihan model dan langkah-langkah penerapan edge. Kami juga mengelola status persetujuan model di sini. Mirip dengan layanan lain yang digunakan, layanan ini terkelola sepenuhnya, jadi kami tidak perlu mengurus infrastruktur kami sendiri.
6. Alur kerja penerapan edge diotomatiskan menggunakan Step Functions, mirip dengan alur kerja pelabelan. Kita dapat menggunakan integrasi API Step Functions untuk dengan mudah memanggil berbagai API layanan AWS yang diperlukan seperti AWS IoT Greengrass untuk membuat komponen model baru dan kemudian menerapkan komponen tersebut ke perangkat edge.
7. AWS IoT Greengrass digunakan sebagai lingkungan runtime perangkat edge. Ini mengelola siklus hidup penerapan model dan komponen inferensi kami di edge. Hal ini memungkinkan kami menerapkan versi baru model dan komponen inferensi dengan mudah menggunakan panggilan API sederhana. Selain itu, model ML di edge biasanya tidak berjalan secara terpisah; kita bisa menggunakan berbagai macamnya AWS dan masyarakat menyediakan komponen AWS IoT Greengrass untuk terhubung ke layanan lain.

Arsitektur yang diuraikan menyerupai arsitektur tingkat tinggi yang ditunjukkan sebelumnya. Amazon S3, SageMaker Feature Store, dan SageMaker Model Registry bertindak sebagai antarmuka antara pipeline yang berbeda. Untuk meminimalkan upaya dalam menjalankan dan mengoperasikan solusi, kami menggunakan layanan terkelola dan tanpa server jika memungkinkan.

Penggabungan ke dalam sistem CI/CD yang kuat

Langkah-langkah pelabelan data, pelatihan model, dan penerapan edge adalah inti dari solusi kami. Oleh karena itu, perubahan apa pun yang terkait dengan kode atau data yang mendasari di salah satu bagian tersebut akan memicu proses orkestrasi keseluruhan yang baru. Untuk mencapai hal ini, kita perlu mengintegrasikan pipeline ini ke dalam sistem CI/CD yang memungkinkan kita menerapkan perubahan kode dan infrastruktur secara otomatis dari repositori kode berversi ke dalam produksi. Mirip dengan arsitektur sebelumnya, otonomi tim merupakan aspek penting di sini. Diagram berikut menunjukkan seperti apa penggunaan layanan AWS.

Mari kita telusuri arsitektur CI/CD:

1. Komitmen Kode AWS bertindak sebagai repositori Git kami. Demi kesederhanaan, dalam sampel yang kami sediakan, kami memisahkan bagian-bagian yang berbeda (pelabelan, pelatihan model, penerapan edge) melalui subfolder dalam satu repositori git. Dalam skenario dunia nyata, setiap tim mungkin menggunakan repositori berbeda untuk setiap bagian.
2. Penerapan infrastruktur diotomatisasi menggunakan AWS CDK dan setiap bagian (pelabelan, pelatihan, dan edge) mendapatkan aplikasi AWS CDK sendiri untuk memungkinkan penerapan independen.
3. Fitur pipa AWS CDK menggunakan Pipa Kode AWS untuk mengotomatiskan infrastruktur dan penerapan kode.
4. AWS CDK men-deploy dua pipeline kode untuk setiap langkah: pipeline aset dan pipeline alur kerja. Kami memisahkan alur kerja dari penerapan aset untuk memungkinkan kami memulai alur kerja secara terpisah jika tidak ada perubahan aset (misalnya, ketika ada gambar baru yang tersedia untuk pelatihan).
   • Alur kode aset menyebarkan semua infrastruktur yang diperlukan agar alur kerja dapat berjalan dengan sukses, seperti Identitas AWS dan Manajemen Akses Peran (IAM), fungsi Lambda, dan gambar kontainer yang digunakan selama pelatihan.
   • Alur kode alur kerja menjalankan alur kerja pelabelan, pelatihan, atau penerapan edge yang sebenarnya.
5. Alur aset secara otomatis dipicu saat penerapan serta saat alur alur kerja sebelumnya selesai.
6. Seluruh proses dipicu sesuai jadwal menggunakan Jembatan Acara Amazon aturan untuk pelatihan ulang reguler.

Dengan integrasi CI/CD, seluruh rantai end-to-end kini sepenuhnya otomatis. Pipeline dipicu setiap kali kode berubah di repositori git kami serta sesuai jadwal untuk mengakomodasi perubahan data.

Berpikir ke depan

Arsitektur solusi yang dijelaskan mewakili komponen dasar untuk membangun pipeline MLOps end-to-end di edge. Namun, bergantung pada kebutuhan Anda, Anda mungkin mempertimbangkan untuk menambahkan fungsionalitas tambahan. Berikut beberapa contohnya:

Kesimpulan

Dalam postingan ini, kami menguraikan arsitektur kami untuk membangun pipeline MLOps end-to-end untuk inspeksi kualitas visual di edge menggunakan layanan AWS. Arsitektur ini menyederhanakan seluruh proses, mencakup pelabelan data, pengembangan model, dan penerapan edge, memungkinkan kami melatih dan mengimplementasikan versi model baru dengan cepat dan andal. Dengan layanan tanpa server dan terkelola, kami dapat mengarahkan fokus kami untuk memberikan nilai bisnis dibandingkan mengelola infrastruktur.

In bagian 2 Dalam seri ini, kita akan mempelajari satu tingkat lebih dalam dan melihat implementasi arsitektur ini secara lebih rinci, khususnya pelabelan dan pembuatan model. Jika Anda ingin langsung ke kodenya, Anda dapat melihat yang terlampir GitHub repo.

---

Tentang penulis

Michael Roth adalah Arsitek Solusi Senior di AWS yang mendukung pelanggan Manufaktur di Jerman untuk memecahkan tantangan bisnis mereka melalui teknologi AWS. Selain pekerjaan dan keluarga, dia tertarik dengan mobil sport dan menikmati kopi Italia.

Jörg Wöhrle adalah Arsitek Solusi di AWS, yang bekerja dengan pelanggan manufaktur di Jerman. Dengan minat terhadap otomatisasi, Joerg telah bekerja sebagai pengembang perangkat lunak, insinyur DevOps, dan Insinyur Keandalan Situs sebelum kehidupannya di AWS. Selain cloud, dia adalah pelari yang ambisius dan menikmati waktu berkualitas bersama keluarganya. Jadi, jika Anda memiliki tantangan DevOps atau ingin mencoba: beri tahu dia.

Johannes Langer adalah Arsitek Solusi Senior di AWS, yang bekerja dengan pelanggan perusahaan di Jerman. Johannes bersemangat menerapkan pembelajaran mesin untuk memecahkan masalah bisnis nyata. Dalam kehidupan pribadinya, Johannes senang mengerjakan proyek perbaikan rumah dan menghabiskan waktu di luar ruangan bersama keluarganya.

• Konten Bertenaga SEO & Distribusi PR. Dapatkan Amplifikasi Hari Ini.
• PlatoData.Jaringan Vertikal Generatif Ai. Berdayakan Diri Anda. Akses Di Sini.
• PlatoAiStream. Intelijen Web3. Pengetahuan Diperkuat. Akses Di Sini.
• PlatoESG. Karbon, teknologi bersih, energi, Lingkungan Hidup, Tenaga surya, Penanganan limbah. Akses Di Sini.
• PlatoHealth. Kecerdasan Uji Coba Biotek dan Klinis. Akses Di Sini.
• Sumber: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-1/