Karena bisnis perusahaan merangkul pembelajaran mesin (ML) di seluruh organisasi mereka, alur kerja manual untuk membangun, melatih, dan menerapkan model ML cenderung menjadi penghambat inovasi. Untuk mengatasinya, perusahaan perlu membentuk model operasi yang jelas yang mendefinisikan bagaimana banyak persona, seperti ilmuwan data, insinyur data, insinyur ML, TI, dan pemangku kepentingan bisnis, harus berkolaborasi dan berinteraksi; bagaimana memisahkan perhatian, tanggung jawab, dan keterampilan; dan bagaimana menggunakan layanan AWS secara optimal. Kombinasi ML dan operasi (MLOps) ini membantu perusahaan merampingkan siklus hidup ML end-to-end mereka dan meningkatkan produktivitas ilmuwan data sambil mempertahankan akurasi model yang tinggi serta meningkatkan keamanan dan kepatuhan.
Dalam posting ini, Anda belajar tentang fase kunci membangun fondasi MLOps, bagaimana banyak persona bekerja bersama di fondasi ini, dan Amazon SageMaker alat yang dibuat khusus dan integrasi bawaan dengan layanan AWS lain yang dapat mempercepat adopsi ML di seluruh bisnis perusahaan.
Model kedewasaan MLOps
Membangun fondasi MLOps yang dapat mencakup operasi, sumber daya manusia, dan kebutuhan teknologi pelanggan perusahaan merupakan tantangan. Oleh karena itu, kami mendefinisikan model maturitas berikut yang mendefinisikan kemampuan MLOps yang diperlukan dalam empat fase utama.
- Tahap awal: Selama fase ini, ilmuwan data dapat bereksperimen dan membangun, melatih, dan menerapkan model di AWS menggunakan layanan SageMaker. Lingkungan pengembangan yang disarankan adalah Studio Amazon SageMaker, di mana para ilmuwan data dapat bereksperimen dan berkolaborasi berdasarkan notebook Studio.
- Fase berulang โ Dengan kemampuan bereksperimen di AWS, langkah selanjutnya adalah membuat alur kerja otomatis untuk melakukan praproses data serta membangun dan melatih model (pipa ML). Ilmuwan data berkolaborasi dengan insinyur ML di lingkungan terpisah untuk membangun algoritme dan kode sumber yang tangguh dan siap produksi, yang diatur menggunakan Pipa Amazon SageMaker. Model yang dihasilkan disimpan dan dijadikan tolok ukur dalam registri model Amazon SageMaker.
- Fase yang andal โ Meskipun model telah dibuat melalui pipeline ML, model tersebut perlu diuji sebelum dipromosikan ke produksi. Oleh karena itu, dalam fase ini, metodologi pengujian otomatis diperkenalkan, baik untuk model dan infrastruktur pemicu, dalam lingkungan staging (pra-produksi) yang terisolasi yang mensimulasikan produksi. Setelah uji coba berhasil, model dikerahkan ke lingkungan produksi yang terisolasi. Untuk mempromosikan model di antara berbagai lingkungan, evaluasi dan persetujuan manual diperlukan.
- Fase terukur โ Setelah produksi solusi ML pertama, penskalaan fondasi MLOps untuk mendukung beberapa tim ilmu data untuk berkolaborasi dan memproduksi puluhan atau ratusan kasus penggunaan ML diperlukan. Pada fase ini, kami memperkenalkan templatisasi solusi, yang memberikan kecepatan ke nilai dengan mengurangi waktu pengembangan solusi produksi baru dari minggu ke hari. Selain itu, kami mengotomatiskan instantiasi lingkungan MLOps yang aman untuk memungkinkan beberapa tim beroperasi pada data mereka sehingga mengurangi ketergantungan dan overhead ke TI.
Di bagian berikut, kami menunjukkan cara membangun fondasi MLOps berdasarkan model kedewasaan sebelumnya dan prinsip berikut:
- keluwesan โ Ilmuwan data dapat mengakomodasi kerangka kerja apa pun (seperti TensorFlow atau PyTorch)
- Reproduksibilitas โ Ilmuwan data dapat membuat ulang atau mengamati eksperimen sebelumnya (kode, data, dan hasil)
- Dapat digunakan kembali โ Ilmuwan data dan insinyur ML dapat menggunakan kembali kode sumber dan saluran ML, menghindari inkonsistensi dan biaya
- Skalabilitas โ Ilmuwan data dan insinyur ML dapat menskalakan sumber daya dan layanan sesuai permintaan
- Kemampuan audit โ Ilmuwan data, TI, dan departemen hukum dapat mengaudit log, versi, dan dependensi artefak dan data
- Konsistensi โ Karena MLOps terdiri dari beberapa lingkungan, yayasan perlu menghilangkan varians antar lingkungan
Tahap awal
Pada fase awal, tujuannya adalah untuk menciptakan lingkungan eksperimen yang aman di mana ilmuwan data menerima snapshot data dan eksperimen menggunakan notebook SageMaker untuk membuktikan bahwa ML dapat memecahkan masalah bisnis tertentu. Untuk mencapai hal ini, lingkungan Studio dengan akses yang disesuaikan ke layanan melalui titik akhir VPC direkomendasikan. Kode sumber arsitektur referensi tersedia dalam contoh yang disediakan oleh tim SageMaker di Ilmu Data Aman Dengan Arsitektur Referensi Amazon SageMaker Studio Repo GitHub.
Selain layanan SageMaker, ilmuwan data dapat menggunakan layanan lain untuk memproses data, seperti Amazon ESDM, Amazon Athena, dan Lem AWS, dengan buku catatan disimpan dan diversi di Komitmen Kode AWS repositori (lihat gambar berikut).
Fase berulang
Setelah ilmuwan data membuktikan bahwa ML dapat memecahkan masalah bisnis dan terbiasa dengan eksperimen, pelatihan, dan penerapan model SageMaker, langkah selanjutnya adalah mulai memproduksi solusi ML. Gambar berikut mengilustrasikan arsitektur ini.
Pada tahap ini, pemisahan perhatian diperlukan. Kami membagi lingkungan menjadi beberapa akun AWS:
- Danau Data โ Menyimpan semua data yang diserap dari lokal (atau sistem lain) ke cloud. Insinyur data dapat membuat pipeline ekstrak, transformasi, dan pemuatan (ETL) yang menggabungkan beberapa sumber data dan menyiapkan kumpulan data yang diperlukan untuk kasus penggunaan ML. Data dikatalogkan melalui Katalog Data AWS Glue dan dibagikan dengan pengguna dan akun lain melalui Formasi Danau AWS (lapisan tata kelola data). Di akun yang sama, Toko Fitur Amazon SageMaker dapat dihosting, tetapi kami tidak membahasnya di pos ini. Untuk informasi lebih lanjut, lihat Aktifkan fitur yang digunakan kembali di seluruh akun dan tim menggunakan Amazon SageMaker Feature Store.
- Percobaan โ Memungkinkan ilmuwan data untuk melakukan penelitian mereka. Satu-satunya perbedaan adalah asal snapshot data adalah data lake. Ilmuwan data hanya memiliki akses dalam kumpulan data tertentu, yang dapat dianonimkan jika terjadi GDPR atau kendala privasi data lainnya. Selain itu, akun eksperimen mungkin memiliki akses ke internet untuk memungkinkan ilmuwan data menggunakan kerangka kerja ilmu data baru atau perpustakaan sumber terbuka pihak ketiga. Oleh karena itu, akun eksperimen dianggap sebagai bagian dari lingkungan non-produksi.
- Pengembangan (pengembangan) โ Tahap pertama dari lingkungan produksi. Ilmuwan data berpindah dari notebook ke dunia alur kerja otomatis dan SageMaker Pipelines. Mereka perlu berkolaborasi dengan insinyur ML untuk mengabstraksi kode mereka dan memastikan cakupan pengujian, penanganan kesalahan, dan kualitas kode. Tujuannya adalah untuk mengembangkan pipeline ML, yang merupakan alur kerja otomatis yang melakukan praproses, melatih, mengevaluasi, dan mendaftarkan model ke registri model SageMaker. Penerapan pipeline ML hanya didorong melalui pipeline CI/CD, dan akses ke Konsol Manajemen AWS dibatasi. Koneksi internet tidak diperbolehkan karena pipeline ML memiliki akses ke data produksi di data lake (hanya-baca).
- Perkakas (atau otomatisasi) โ Menghosting repositori CodeCommit, Pipa Kode AWS Pipeline CI/CD, registry model SageMaker, dan Amazon ECR untuk menghosting container kustom. Karena data lake adalah satu-satunya titik kebenaran untuk data, akun perkakas adalah untuk kode, wadah, dan artefak yang dihasilkan.
Perhatikan bahwa konvensi penamaan akun dan strategi multi-akun ini dapat bervariasi tergantung pada kebutuhan bisnis Anda, tetapi struktur ini dimaksudkan untuk menunjukkan tingkat isolasi yang disarankan. Misalnya, Anda dapat mengganti nama akun pengembangan menjadi akun pelatihan model atau akun build.
Untuk mencapai penerapan otomatis, penting untuk memahami cara berpindah dari notebook ke pipeline ML dan menstandardisasi repositori kode dan struktur data, yang akan kita bahas di bagian berikut.
Dari notebook hingga pipeline ML
Tujuan dari lingkungan pengembangan adalah untuk merestrukturisasi, menambah, meningkatkan, dan menskalakan kode di notebook dan memindahkannya ke pipeline ML. Pipeline ML adalah serangkaian langkah yang bertanggung jawab untuk pra-pemrosesan data, pelatihan atau penggunaan model, dan pascapemrosesan hasilnya. Setiap langkah harus melakukan satu tugas dengan tepat (transformasi spesifik) dan cukup abstrak (misalnya, meneruskan nama kolom sebagai parameter input) untuk memungkinkan penggunaan kembali. Diagram berikut mengilustrasikan contoh pipa.
Untuk mengimplementasikan pipeline ML, ilmuwan data (atau engineer ML) menggunakan Pipeline SageMaker. Pipeline SageMaker adalah serangkaian langkah yang saling berhubungan (pekerjaan pemrosesan SageMaker, pelatihan, HPO) yang ditentukan oleh definisi pipeline JSON menggunakan Python SDK. Definisi pipa ini mengkodekan pipa menggunakan Directed Acyclic Graph (DAG). DAG ini memberikan informasi tentang persyaratan dan hubungan antara setiap langkah pipeline ML Anda.
Bergantung pada kasus penggunaan, Anda dapat memisahkan pipeline ML menjadi dua jenis utama: pelatihan dan inferensi batch.
Gambar berikut mengilustrasikan alur pipeline ML pelatihan.
Fase preprocessing mungkin terdiri dari beberapa langkah. Transformasi ilmu data yang umum adalah pemisahan dan pengambilan sampel data (pelatihan, validasi, set pengujian), enkode atau vektorisasi satu-panas, binning, dan penskalaan. Langkah pelatihan model dapat berupa satu tugas pelatihan, jika ilmuwan data mengetahui konfigurasi model terbaik, atau tugas pengoptimalan hiperparameter (HPO), di mana AWS mendefinisikan hiperparameter terbaik untuk model (metode Bayesian) dan menghasilkan yang sesuai artefak model. Pada tahap evaluasi, artefak model yang dihasilkan digunakan untuk melakukan inferensi terhadap dataset validasi. Kemudian pipeline ML memeriksa apakah metrik akurasi yang dihasilkan (seperti F1, presisi, dan desil gain) melewati ambang batas yang diperlukan. Jika langkah ini berhasil, artefak model dan metadata dipindahkan ke registri model untuk produksi. Perhatikan bahwa langkah dasar ekspor mengeksploitasi Monitor Model Amazon SageMaker fungsionalitas, menghasilkan objek JSON dengan statistik yang digunakan nanti untuk deteksi penyimpangan model dan dapat dihosting di registri model SageMaker sebagai metadata model.
Dalam kasus inferensi batch, para ilmuwan data dapat membuat saluran pipa serupa, seperti yang diilustrasikan pada gambar berikut.
Langkah pra-pemrosesan inferensi batch seringkali sama dengan pelatihan dengan mengecualikan pengambilan sampel data dan kolom kebenaran dasar. Inferensi batch adalah langkah yang mengirimkan data dalam batch untuk inferensi ke titik akhir yang sesuai, dan dapat diimplementasikan dengan menggunakan transformasi batch. Langkah pascapemrosesan menghasilkan statistik tambahan, seperti distribusi hasil, atau menggabungkan hasil dengan ID eksternal. Kemudian, langkah monitor model dapat membandingkan statistik dasar dari data yang digunakan untuk pelatihan (metadata model JSON dalam registri model) dengan data baru yang masuk untuk inferensi.
Anda dapat melewati langkah-langkah prapemrosesan jika ilmuwan data membuat model saluran yang dapat disimpan di registri model SageMaker. Untuk lebih jelasnya, lihat Model host bersama dengan logika pra-pemrosesan sebagai saluran inferensi serial di belakang satu titik akhir.
Standarisasi repositori
Untuk memungkinkan kolaborasi antara ilmuwan data dan insinyur ML, diperlukan standarisasi struktur repositori kode. Selain itu, standardisasi bermanfaat untuk struktur pipa CI/CD, memungkinkan penggabungan validasi otomatis, pembangunan (seperti pembuatan kontainer kustom), dan langkah-langkah pengujian.
Contoh berikut mengilustrasikan pemisahan solusi ML menjadi dua repositori: repositori bangunan dan pelatihan untuk pelatihan (dan secara opsional model pipeline), dan penerapan untuk mempromosikan model pipeline inferensi batch atau membuat instance titik akhir waktu nyata:
Gudang Bangunan/Pelatihan
Repositori Penerapan
Repositori gedung dan pelatihan dibagi menjadi tiga folder utama:
- Algoritma โ Ilmuwan data mengembangkan kode untuk setiap langkah pipeline ML di folder root algoritme. Langkah-langkah tersebut dapat dikelompokkan dalam preprocessing, training, batch inference, dan postprocessing (evaluasi). Di setiap grup, beberapa langkah dapat ditentukan dalam subfolder yang sesuai, yang berisi folder untuk pengujian unit (termasuk input dan output opsional), fungsi utama, readme, dan file Docker jika diperlukan wadah khusus. Selain utama, beberapa file kode dapat di-host di folder yang sama. Pustaka pembantu umum untuk semua langkah dapat di-host di folder pustaka bersama. Ilmuwan data bertanggung jawab atas pengembangan pengujian unit karena mereka memiliki logika langkah-langkahnya, dan insinyur ML bertanggung jawab atas peningkatan penanganan kesalahan dan rekomendasi cakupan pengujian. Pipeline CI/CD bertanggung jawab untuk menjalankan pengujian, membuat container secara otomatis (jika perlu), dan mengemas beberapa file kode sumber.
- Pipa ML โ Setelah Anda mengembangkan kode sumber dan menguji setiap langkah, langkah selanjutnya adalah menentukan saluran pipa SageMaker di folder akar lain. Setiap definisi pipeline ML ditempatkan di subfolder yang berisi file .py dan file JSON atau .yaml untuk parameter input, seperti rentang hyperparameter. File readme untuk menjelaskan pipeline ML diperlukan.
- notebook โ Folder ini menampung buku catatan asal yang digunakan ilmuwan data selama eksperimen.
Repositori penyebaran terdiri dari tiga bagian utama:
- Konfigurasi inferensi โ Berisi konfigurasi titik akhir waktu nyata atau inferensi batch per lingkungan pengembangan, seperti jenis instans.
- Infrastruktur aplikasi โ Menghosting kode sumber infrastruktur yang diperlukan untuk menjalankan inferensi, jika perlu. Ini mungkin mekanisme pemicu melalui Jembatan Acara Amazon, Gerbang API Amazon, AWS Lambda fungsi, atau Pipeline SageMaker.
- Tes โ Terdiri dari beberapa subfolder tergantung pada metodologi pengujian pelanggan. Sebagai rangkaian pengujian minimum, kami menyarankan pengujian integrasi (penjalanan inferensi secara menyeluruh termasuk infrastruktur aplikasi), uji stres (periksa kasus tepi), dan pengujian ML (seperti distribusi skor keyakinan atau probabilitas).
Dengan melakukan perubahan pada repositori pembangunan dan pelatihan, pipeline CI/CD bertanggung jawab untuk memvalidasi struktur repositori, melakukan pengujian, dan men-deploy serta menjalankan pipeline ML. Pipeline CI/CD yang berbeda bertanggung jawab untuk mempromosikan model, yang akan kita bahas di bagian berikut.
Standarisasi percabangan repositori dan CI/CD
Untuk memastikan kekokohan pipeline ML di akun dev, disarankan strategi repositori multi-cabang, sementara penerapan hanya dilakukan melalui pipeline CI/CD. Ilmuwan data harus memanfaatkan cabang fitur untuk mengembangkan fungsionalitas baru mereka (kode sumber). Saat mereka siap untuk men-deploy pipeline ML yang sesuai, mereka dapat mendorong ini ke cabang develop. Alternatif untuk pendekatan ini adalah mengizinkan penerapan pipeline ML per cabang fitur. Untuk informasi lebih lanjut, lihat Tingkatkan alur kerja ilmu data Anda dengan alur MLOps pelatihan multi-cabang menggunakan AWS.
Gambar berikut mengilustrasikan strategi percabangan dan langkah-langkah pipeline CI/CD yang kami jalankan di lingkungan dev untuk pipeline ML dan pembuatan model.
Contoh kode pendekatan multi-cabang tersedia di Jalur pelatihan MLOps Multi-Cabang. Kami dapat menyimpan model yang dihasilkan oleh pipeline ML berbasis cabang fitur dalam grup model fitur terpisah dan menonaktifkannya selama permintaan penggabungan dengan cabang utama. Model dalam kelompok model utama adalah orang-orang yang dipromosikan ke produksi.
Standarisasi struktur data
Sama pentingnya dengan standarisasi kode sumber adalah standarisasi struktur data, yang memungkinkan ilmuwan data dan insinyur ML untuk men-debug, mengaudit, dan memantau asal dan riwayat model dan pipeline ML. Diagram berikut menggambarkan contoh seperti itu.
Untuk mempermudah, mari kita asumsikan bahwa input data historis masuk ke dalam bucket akun pengembangan di bawah sub-kunci input (biasanya ini terletak di data lake). Untuk setiap kasus penggunaan ML, sub-kunci terpisah perlu dibuat. Untuk memicu agar pipeline ML baru berjalan, ilmuwan data harus melakukan git commit dan push, yang memicu pipeline CI/CD. Kemudian pipa CI/CD membuat sub-kunci dengan menyalin artefak kode (the code
sub-kunci) dan input data (the input
sub-key) di bawah sub-partisi ID build. Sebagai contoh, ID build csebuah kombinasi dari tanggal-waktu dan git hash, atau ID run pipeline SageMaker. Struktur ini memungkinkan ilmuwan data untuk mengaudit dan menanyakan penerapan dan proses sebelumnya. Setelah ini, pipeline CI/CD men-deploy dan memicu pipeline ML. Saat pipeline ML berjalan, setiap langkah mengekspor hasil antara ke ml-pipeline-outputs
. Penting untuk diingat bahwa cabang fitur yang berbeda menerapkan dan menjalankan instance baru dari ML Pipeline dan masing-masing perlu mengekspor hasil antara ke sub-folder yang berbeda dengan sub-kunci baru dan/atau awalan atau akhiran standar yang menyertakan fitur id cabang.
Pendekatan ini mendukung kemampuan audit yang lengkap dari setiap eksperimen. Namun, pendekatan multi-cabang dari strategi pengembangan menghasilkan sejumlah besar data. Oleh karena itu, strategi siklus hidup data diperlukan. Sebaiknya hapus setidaknya data setiap pipeline ML cabang fitur di setiap permintaan tarik/gabung yang berhasil. Tetapi ini tergantung pada model operasi dan perincian audit yang perlu didukung oleh bisnis Anda. Anda dapat menggunakan pendekatan serupa dalam pipeline ML inferensi batch
Fase yang andal
Setelah pemisahan awal kekhawatiran antara ilmuwan data, insinyur ML, dan insinyur data dengan menggunakan beberapa akun, langkah selanjutnya adalah mempromosikan model yang dihasilkan dari registri model ke lingkungan yang terisolasi untuk melakukan inferensi. Namun, kita perlu memastikan kekokohan model yang digunakan. Oleh karena itu, simulasi model yang dikerahkan ke lingkungan produksi cermin adalah wajib, yaitu pra-produksi (atau pementasan).
Gambar berikut mengilustrasikan arsitektur ini.
Promosi model dan penyebaran titik akhir di lingkungan pra-produksi dilakukan menggunakan peristiwa pembaruan status registri model (atau git push pada repositori penyebaran), yang memicu pipa CI/CD terpisah dengan menggunakan peristiwa EventBridge. Langkah pertama dari pipeline CI/CD meminta persetujuan manual oleh ilmuwan data utama (dan secara opsional, pemilik produk, analis bisnis, atau ilmuwan data utama lainnya). Pemberi persetujuan perlu memvalidasi KPI kinerja model dan QA kode dalam repositori penerapan. Setelah persetujuan, pipeline CI/CD menjalankan kode pengujian ke repositori penerapan (uji integrasi, uji stres, uji ML). Selain titik akhir model, CI/CD juga menguji infrastruktur pemicu, seperti EventBridge, fungsi Lambda, atau API Gateway. Diagram berikut menunjukkan arsitektur yang diperbarui ini.
Setelah sukses menjalankan pengujian, pipeline CI/CD memberi tahu pemberi persetujuan baru (atau yang sama) bahwa model siap untuk dipromosikan ke produksi. Pada tahap ini, analis bisnis mungkin ingin melakukan beberapa uji hipotesis statistik tambahan pada hasil model. Setelah persetujuan, model dan infrastruktur pemicu dikerahkan dalam produksi. Beberapa metode penerapan didukung oleh SageMaker, seperti pengujian biru/hijau, Canary, dan A/B (lihat selengkapnya di Pemasangan pagar pembatas). Jika pipa CI/CD gagal, mekanisme rollback mengembalikan sistem ke status kuat terbaru.
Diagram berikut mengilustrasikan langkah-langkah utama pipeline CI/CD untuk mempromosikan model dan infrastruktur untuk memicu titik akhir model, seperti API Gateway, fungsi Lambda, dan EventBridge.
Data lake dan integrasi MLOps
Pada titik ini, penting untuk memahami persyaratan data per tahap atau akun pengembangan, dan cara menggabungkan MLOps dengan data lake terpusat. Diagram berikut mengilustrasikan MLOps dan lapisan data lake.
Di data lake, para insinyur data bertanggung jawab untuk menggabungkan beberapa sumber data dan membuat kumpulan data yang sesuai (misalnya, satu tabel dari data struktur, atau satu folder dengan file atau gambar PDF) untuk kasus penggunaan ML dengan membangun ETL pipa seperti yang didefinisikan oleh para ilmuwan data (selama fase analisis data eksplorasi). Kumpulan data tersebut dapat dibagi menjadi data historis dan data untuk inferensi dan pengujian. Semua data dikatalogkan (misalnya, dengan Katalog Data AWS Glue), dan dapat dibagikan dengan akun dan pengguna lain dengan menggunakan Lake Formation sebagai lapisan tata kelola data (untuk data terstruktur). Pada tulisan ini, Lake Formation hanya kompatibel dengan kueri Athena, tugas AWS Glue, dan Amazon EMR.
Di sisi lain, lingkungan MLOps perlu mengairi pipeline ML dengan set data spesifik yang terletak di bucket lokal di dev, pre-prod, dan prod. Lingkungan pengembang bertanggung jawab untuk membangun dan melatih model sesuai permintaan menggunakan pipeline SageMaker yang menarik data dari data lake. Oleh karena itu, kami menyarankan sebagai langkah pertama dari pipeline untuk memiliki langkah Athena, di mana hanya pengambilan sampel data dan kueri yang diperlukan, atau langkah Amazon EMR, jika diperlukan transformasi yang lebih kompleks. Atau, Anda dapat menggunakan pekerjaan AWS Glue melalui langkah panggilan balik, tetapi belum sebagai langkah asli dengan SageMaker Pipelines.
Pra-prod dan prod bertanggung jawab untuk menguji atau melakukan inferensi real-time dan batch. Dalam kasus inferensi real-time, pengiriman data ke akun pre-prod dan prod MLOps tidak diperlukan karena input untuk inferensi dapat mendukung muatan permintaan API Gateway. Dalam kasus inferensi batch (atau data input ukuran besar), set data yang diperlukan, baik data uji atau data untuk inferensi, perlu masuk ke bucket data ML lokal (pra-prod atau prod). Anda memiliki dua opsi untuk memindahkan data ke pra-prod dan prod: baik dengan memicu Athena atau Amazon EMR dan menarik data dari data lake, atau mendorong data dari data lake ke akun MLOps tersebut. Opsi pertama memerlukan pengembangan mekanisme tambahan di akun MLOps, misalnya, membuat acara EventBridge terjadwal (tanpa sepengetahuan jika data di data lake telah diperbarui) atau kedatangan data di acara S3 EventBridge di data lake (untuk lebih jelasnya, lihat Menyederhanakan akses lintas-akun dengan kebijakan sumber daya Amazon EventBridge). Setelah menangkap acara di sisi MLOps, kueri Athena atau Amazon EMR dapat mengambil data secara lokal dan memicu inferensi asinkron or transformasi batch. Ini dapat dimasukkan ke dalam pipa SageMaker untuk kesederhanaan. Opsi kedua adalah menambahkan pada langkah terakhir dari pipeline ETL fungsionalitas mendorong data ke bucket MLOps. Namun, pendekatan ini mencampuradukkan tanggung jawab (data lake memicu inferensi) dan membutuhkan Lake Formation untuk menyediakan akses ke data lake untuk menulis di ember MLOps.
Langkah terakhir adalah memindahkan hasil inferensi kembali ke data lake. Untuk membuat katalog data dan membuatnya tersedia untuk pengguna lain, data harus dikembalikan sebagai sumber data baru kembali ke keranjang pendaratan.
Fase yang Dapat Diskalakan
Setelah pengembangan fondasi MLOps dan produksi end-to-end dari use case ML pertama, infrastruktur dev, pre-prod, prod, dan repositori, pipeline CI/CD, dan struktur data telah diuji dan diselesaikan . Langkah selanjutnya adalah memasukkan kasus penggunaan dan tim ML baru ke platform. Untuk memastikan kecepatan-ke-nilai, SageMaker memungkinkan Anda membuat templat proyek SageMaker khusus, yang dapat Anda gunakan untuk membuat instance repositori templat dan saluran CI/CD secara otomatis. Dengan templat proyek SageMaker seperti itu, ilmuwan data utama bertanggung jawab untuk membuat instance proyek baru dan mengalokasikan tim khusus per kasus penggunaan ML baru.
Diagram berikut menggambarkan proses ini.
Masalahnya menjadi lebih kompleks jika tim ilmuwan data yang berbeda (atau beberapa unit bisnis yang perlu memproduksi ML) memiliki akses ke data rahasia yang berbeda, dan beberapa pemilik produk bertanggung jawab untuk membayar tagihan terpisah untuk pelatihan, penerapan, dan pengoperasian model . Oleh karena itu, satu set akun MLOps yang terpisah (eksperimen, dev, pre-prod, dan prod) per tim diperlukan. Untuk memudahkan pembuatan akun MLOps baru, kami memperkenalkan akun lain, akun tata kelola analitik lanjutan, yang dapat diakses oleh anggota TI dan memungkinkan mereka untuk membuat katalog, membuat instance, atau menonaktifkan akun MLOps sesuai permintaan. Secara khusus, akun ini menghosting repositori dengan kode infrastruktur akun MLOps (VPC, subnet, endpoint, bucket, Identitas AWS dan Manajemen Akses (IAM) peran dan kebijakan, Formasi AWS Cloud tumpukan), dan Katalog Layanan AWS produk untuk secara otomatis menyebarkan tumpukan infrastruktur CloudFormation ke beberapa akun dengan satu klik, dan Amazon DynamoDB tabel ke metadata katalog, seperti tim mana yang bertanggung jawab untuk setiap set akun. Dengan kemampuan ini, tim TI membuat akun MLOps sesuai permintaan dan mengalokasikan pengguna yang diperlukan, akses data per akun, dan batasan keamanan yang konsisten.
Berdasarkan skenario ini, kami memisahkan akun menjadi fana dan tahan lama. Data lake dan perkakas adalah akun yang tahan lama dan masing-masing memainkan peran satu titik kebenaran untuk data dan kode sumber. Akun MLOps sebagian besar tidak memiliki kewarganegaraan dan digunakan atau dinonaktifkan sesuai permintaan, menjadikannya bersifat sementara. Bahkan jika satu set akun MLOps dinonaktifkan, pengguna atau auditor dapat memeriksa eksperimen dan hasil sebelumnya karena disimpan di lingkungan yang tahan lama.
Jika Anda ingin menggunakan UI Studio untuk MLOps, akun perkakas adalah bagian dari akun dev, sesuai gambar berikut.
Jika pengguna ingin menggunakan UI Sagemaker Studio untuk MLOps, akun perkakas adalah bagian dari dev
akun sesuai gambar di atas. Contoh kode sumber yayasan MLOP ini dapat ditemukan di
Pondasi MLOps multi-akun yang aman berdasarkan CDK.
Perhatikan bahwa Sagemaker menyediakan kemampuan untuk menggantikan CodeCommit dan CodePipeline dengan alat pengembangan pihak ketiga lainnya, seperti GitHub dan Jenkins (detail lebih lanjut dapat ditemukan di Buat proyek Amazon SageMaker menggunakan kontrol sumber pihak ketiga dan Jenkins dan Amazon SageMaker Memproyeksikan MLOps Template dengan GitLab dan GitLab Pipelines).
Persona, operasi, dan ringkasan teknologi
Dengan model kematangan MLOps, kita dapat menentukan desain arsitektur dan roadmap pengiriman yang jelas. Namun, setiap persona harus memiliki pandangan yang jelas tentang akun dan layanan utama AWS untuk berinteraksi dan operasi yang harus dilakukan. Diagram berikut merangkum kategori-kategori tersebut.
Kesimpulan
Fondasi MLOps yang kuat, yang dengan jelas mendefinisikan interaksi di antara banyak persona dan teknologi, dapat meningkatkan kecepatan-untuk-nilai dan mengurangi biaya, dan memungkinkan ilmuwan data untuk fokus pada inovasi. Dalam postingan ini, kami menunjukkan cara membangun fondasi semacam itu secara bertahap, yang mengarah ke model kematangan MLOps yang mulus untuk bisnis dan kemampuan untuk mendukung beberapa tim ilmu data dan kasus penggunaan ML dalam produksi. Kami mendefinisikan model operasi yang terdiri dari banyak persona dengan berbagai keterampilan dan tanggung jawab. Terakhir, kami membagikan contoh cara menstandarisasi pengembangan kode (repositori dan saluran CI/CD), penyimpanan dan berbagi data, dan penyediaan infrastruktur aman MLOps untuk lingkungan perusahaan. Banyak pelanggan perusahaan telah mengadopsi pendekatan ini dan mampu memproduksi solusi ML mereka dalam hitungan hari, bukan bulan.
Jika Anda memiliki komentar atau pertanyaan, silakan tinggalkan di bagian komentar.
tentang Penulis
Sokratis Kartakis adalah Arsitek Solusi Spesialis Pembelajaran Mesin Senior untuk Amazon Web Services. Sokratis berfokus pada memungkinkan pelanggan perusahaan untuk mengindustrialisasikan solusi Machine Learning (ML) mereka dengan memanfaatkan layanan AWS dan membentuk model operasi mereka, yaitu fondasi MLOps, dan peta jalan transformasi yang memanfaatkan praktik pengembangan terbaik. Dia telah menghabiskan lebih dari 15 tahun untuk menciptakan, merancang, memimpin, dan menerapkan solusi ML dan Internet of Things (IoT) tingkat produksi ujung-ke-ujung yang inovatif dalam domain energi, ritel, kesehatan, keuangan/perbankan, olahraga motor, dll. Sokratis suka menghabiskan waktu luangnya bersama keluarga dan teman, atau mengendarai sepeda motor.
Georgios Schinas adalah Arsitek Solusi Spesialis untuk AI/ML di wilayah EMEA. Dia berbasis di London dan bekerja sama dengan pelanggan di Inggris dan Irlandia. Georgios membantu pelanggan merancang dan menerapkan aplikasi pembelajaran mesin dalam produksi di AWS dengan minat khusus pada praktik MLOps dan memungkinkan pelanggan melakukan pembelajaran mesin dalam skala besar. Di waktu luangnya, ia senang bepergian, memasak, dan menghabiskan waktu bersama teman dan keluarga.
Giuseppe Angelo Porcelli adalah Arsitek Solusi Spesialis Pembelajaran Mesin Utama untuk Amazon Web Services. Dengan latar belakang ML selama beberapa tahun sebagai rekayasa perangkat lunak, ia bekerja dengan pelanggan dari berbagai ukuran untuk memahami secara mendalam kebutuhan bisnis dan teknis mereka serta merancang solusi AI dan Pembelajaran Mesin yang memanfaatkan AWS Cloud dan tumpukan Amazon Machine Learning dengan sebaik-baiknya. Dia telah mengerjakan proyek di berbagai domain, termasuk MLOps, Computer Vision, NLP, dan melibatkan serangkaian luas layanan AWS. Di waktu luangnya, Giuseppe menikmati bermain sepak bola.
Shelbee Eigenbrode adalah Arsitek Solusi Spesialis AI dan Pembelajaran Mesin Utama di Amazon Web Services (AWS). Dia telah berkecimpung dalam teknologi selama 24 tahun yang mencakup berbagai industri, teknologi, dan peran. Dia saat ini berfokus untuk menggabungkan latar belakang DevOps dan ML-nya ke dalam domain MLOps untuk membantu pelanggan memberikan dan mengelola beban kerja ML dalam skala besar. Dengan lebih dari 35 paten yang diberikan di berbagai domain teknologi, dia memiliki semangat untuk terus berinovasi dan menggunakan data untuk mendorong hasil bisnis. Shelbee adalah co-creator dan instruktur spesialisasi Ilmu Data Praktis di Coursera. Dia juga Co-Direktur Women In Big Data (WiBD), Denver chapter. Di waktu luangnya, dia suka menghabiskan waktu bersama keluarga, teman, dan anjingnya yang terlalu aktif.
- "
- 100
- a
- kemampuan
- Tentang Kami
- ABSTRAK
- mempercepat
- mengakses
- dapat diakses
- menampung
- Akun
- Mencapai
- di seluruh
- tambahan
- Tambahan
- Adopsi
- maju
- terhadap
- AI
- algoritma
- Semua
- memungkinkan
- alternatif
- Amazon
- Amazon Web Services
- antara
- jumlah
- analisis
- analis
- analisis
- Lain
- api
- Aplikasi
- aplikasi
- pendekatan
- arsitektur
- Audit
- mengotomatisasikan
- secara otomatis
- secara otomatis
- Otomatisasi
- tersedia
- menghindari
- AWS
- latar belakang
- Dasar
- karena
- menjadi
- sebelum
- di belakang
- bermanfaat
- TERBAIK
- antara
- Big data
- tagihan
- mendorong
- membangun
- Bangunan
- built-in
- bisnis
- bisnis
- kemampuan
- kasus
- kasus
- terpusat
- menantang
- Bab
- Cek
- klasik
- awan
- kode
- Berkolaborasi
- kolaborasi
- Kolom
- kombinasi
- komentar
- melakukan
- Umum
- Perusahaan
- cocok
- lengkap
- kompleks
- pemenuhan
- komputer
- Mengadakan
- melakukan
- kepercayaan
- konfigurasi
- koneksi
- konsisten
- Wadah
- Wadah
- mengandung
- kontrol
- penyalinan
- Sesuai
- bisa
- menutupi
- membuat
- dibuat
- menciptakan
- membuat
- penciptaan
- Sekarang
- adat
- pelanggan
- pelanggan
- data
- akses data
- analisis data
- privasi data
- ilmu data
- ilmuwan data
- penyimpanan data
- Hari
- dedicated
- pengiriman
- Permintaan
- Denver
- Tergantung
- tergantung
- menyebarkan
- dikerahkan
- penggelaran
- penyebaran
- penyebaran
- menyebarkan
- menggambarkan
- Mendesain
- merancang
- rincian
- Deteksi
- dev
- mengembangkan
- Pengembangan
- alat pengembangan
- perbedaan
- berbeda
- membahas
- distribusi
- Buruh pelabuhan
- domain
- domain
- mendorong
- didorong
- selama
- setiap
- Tepi
- menghapuskan
- merangkul
- aktif
- memungkinkan
- memungkinkan
- ujung ke ujung
- Titik akhir
- energi
- Teknik
- Insinyur
- Enterprise
- perusahaan
- Lingkungan Hidup
- dll
- mengevaluasi
- evaluasi
- Acara
- peristiwa
- persis
- contoh
- contoh
- tidak termasuk
- eksperimen
- eksploitasi
- eksplorasi
- keluarga
- Fitur
- Angka
- Akhirnya
- Pertama
- aliran
- Fokus
- berfokus
- berfokus
- berikut
- sepak bola
- pembentukan
- ditemukan
- Prinsip Dasar
- Foundations
- Kerangka
- kerangka
- Gratis
- dari
- fungsi
- fungsi
- Selanjutnya
- pintu gerbang
- GDPR
- dihasilkan
- pergi
- GitHub
- tujuan
- pemerintahan
- diberikan
- Kelompok
- Penanganan
- hash
- Kesehatan
- membantu
- membantu
- membantu
- High
- historis
- sejarah
- host
- Seterpercayaapakah Olymp Trade? Kesimpulan
- How To
- Namun
- HTTPS
- Ratusan
- identitas
- gambar
- melaksanakan
- diimplementasikan
- mengimplementasikan
- penting
- memperbaiki
- termasuk
- Termasuk
- Meningkatkan
- industri
- informasi
- Infrastruktur
- Innovation
- inovasi
- inovatif
- memasukkan
- contoh
- integrasi
- integrasi
- interaksi
- bunga
- Antarmuka
- Internet
- internet hal-hal
- idiot
- Irlandia
- isolasi
- IT
- Pekerjaan
- Jobs
- bergabung
- Bergabung
- Menjaga
- kunci
- pengetahuan
- besar
- Terbaru
- lapisan
- memimpin
- terkemuka
- BELAJAR
- pengetahuan
- Meninggalkan
- Informasi
- adalah ide yang bagus
- leveraging
- Perpustakaan
- memuat
- lokal
- lokal
- London
- mesin
- Mesin belajar
- membuat
- Membuat
- mengelola
- pengelolaan
- wajib
- panduan
- kematangan
- mekanisme
- Anggota
- Bergabung
- Metodologi
- metode
- Metrik
- mungkin
- keberatan
- minimum
- cermin
- ML
- model
- model
- Memantau
- bulan
- lebih
- Motorsports
- pindah
- bergerak
- beberapa
- yaitu
- nama
- penamaan
- perlu
- kebutuhan
- berikutnya
- biasanya
- beroperasi
- operasi
- Operasi
- optimasi
- pilihan
- Opsi
- urutan
- organisasi
- asli
- Lainnya
- sendiri
- pemilik
- pemilik
- bagian
- tertentu
- pihak
- gairah
- Paten
- Konsultan Ahli
- prestasi
- melakukan
- tahap
- Platform
- Bermain
- bermain
- silahkan
- Titik
- Kebijakan
- Mempersiapkan
- Utama
- pribadi
- Masalah
- proses
- pengolahan
- Diproduksi
- Produk
- Produksi
- produktifitas
- proyek
- memprojeksikan
- mendorong
- promosi
- memberikan
- disediakan
- menyediakan
- menarik
- kualitas
- RE
- real-time
- menurunkan
- mengurangi
- wilayah
- daftar
- Hubungan
- dapat diandalkan
- gudang
- permintaan
- permintaan
- wajib
- Persyaratan
- membutuhkan
- penelitian
- sumber
- Sumber
- tanggung jawab
- tanggung jawab
- Hasil
- eceran
- kembali
- Pengembalian
- peta jalan
- kesegaran
- Peran
- akar
- Run
- berjalan
- sama
- terukur
- Skala
- skala
- dijadwalkan
- Ilmu
- ilmuwan
- ilmuwan
- SDK
- aman
- keamanan
- serial
- Seri
- layanan
- Layanan
- set
- penyiapan
- beberapa
- Bentuknya
- berbagi
- berbagi
- Menunjukkan
- mirip
- simulasi
- tunggal
- Ukuran
- keterampilan
- Perangkat lunak
- rekayasa Perangkat Lunak
- larutan
- Solusi
- MEMECAHKAN
- beberapa
- kode sumber
- spesialis
- tertentu
- Secara khusus
- kecepatan
- menghabiskan
- Pengeluaran
- membagi
- tumpukan
- Tahap
- magang
- awal
- Negara
- statistik
- statistika
- Status
- penyimpanan
- menyimpan
- toko
- Penyelarasan
- mempersingkat
- tekanan
- tersusun
- studio
- sukses
- mendukung
- Didukung
- Mendukung
- sistem
- sistem
- tim
- tim
- Teknis
- Teknologi
- Teknologi
- template
- uji
- pengujian
- tes
- Grafik
- Sumber
- Dunia
- karena itu
- hal
- pihak ketiga
- tiga
- waktu
- bersama
- alat
- Pelatihan VE
- Pelatihan
- Mengubah
- Transformasi
- transformasi
- Perjalanan
- jenis
- ui
- Uk
- bawah
- memahami
- unit
- Memperbarui
- menggunakan
- Pengguna
- Penggunaan
- pengesahan
- nilai
- berbagai
- View
- penglihatan
- jaringan
- layanan web
- sementara
- dalam
- tanpa
- Wanita
- Kerja
- bekerja
- Alur kerja
- bekerja
- dunia
- penulisan
- tahun
- Anda