Pendekatan Pengujian Untuk Model ML Amazon SageMaker

Diterbitkan Ulang Oleh Plato

Followers: 0

Posting ini ditulis bersama dengan Tobias Wenzel, Manajer Rekayasa Perangkat Lunak untuk Platform Pembelajaran Mesin Intuit.

Kita semua menghargai pentingnya model pembelajaran mesin (ML) berkualitas tinggi dan andal saat menggunakan mengemudi otonom atau berinteraksi dengan Alexa, misalnya. Model ML juga memainkan peran penting dalam cara yang tidak terlalu mencolok—model tersebut digunakan oleh aplikasi bisnis, perawatan kesehatan, lembaga keuangan, amazon.com, TurboTax, dan banyak lagi.

Karena aplikasi berkemampuan ML menjadi inti bagi banyak bisnis, model harus mengikuti kekuatan dan disiplin yang sama seperti aplikasi perangkat lunak. Aspek penting dari MLOps adalah menghadirkan versi baru dari model ML yang dikembangkan sebelumnya dalam produksi dengan menggunakan praktik DevOps yang sudah mapan seperti pengujian, pembuatan versi, pengiriman berkelanjutan, dan pemantauan.

Ada beberapa bersifat menentukan pedoman seputar MLOps, dan posting ini memberikan gambaran umum tentang proses yang dapat Anda ikuti dan alat mana yang digunakan untuk pengujian. Hal ini didasarkan pada kerjasama antara Intuit dan AWS. Kami telah bekerja sama untuk menerapkan rekomendasi yang dijelaskan dalam posting ini dalam praktik dan dalam skala. Tujuan Intuit untuk menjadi seorang Platform ahli yang digerakkan oleh AI sangat bergantung pada strategi peningkatan kecepatan pengembangan model awal serta pengujian versi baru.

Persyaratan

Berikut ini adalah area pertimbangan utama saat men-deploy versi model baru:

Performa akurasi model – Penting untuk melacak metrik evaluasi model seperti akurasi, presisi, dan ingatan, dan memastikan bahwa metrik objektif tetap relatif sama atau ditingkatkan dengan versi model baru. Dalam kebanyakan kasus, menerapkan versi baru model tidak masuk akal jika pengalaman pengguna akhir tidak meningkat.
Uji kualitas data – Data di lingkungan non-produksi, baik yang disimulasikan atau disalin secara tepat waktu, harus mewakili data yang akan diterima model saat digunakan sepenuhnya, dalam hal volume atau distribusi. Jika tidak, proses pengujian Anda tidak akan representatif, dan model Anda mungkin berperilaku berbeda dalam produksi.
Pentingnya fitur dan paritas – Pentingnya fitur dalam versi model yang lebih baru harus relatif dibandingkan dengan model yang lebih lama, meskipun mungkin ada fitur baru yang diperkenalkan. Hal ini untuk memastikan bahwa model tidak menjadi bias.
Pengujian proses bisnis – Sangat penting bahwa model versi baru dapat memenuhi tujuan bisnis Anda yang diperlukan dalam parameter yang dapat diterima. Misalnya, salah satu metrik bisnis dapat berupa latensi ujung ke ujung untuk layanan apa pun tidak boleh lebih dari 100 milidetik, atau biaya untuk menghosting dan melatih kembali model tertentu tidak boleh lebih dari $10,000 per tahun.
Biaya – Pendekatan sederhana untuk pengujian adalah dengan mereplikasi seluruh lingkungan produksi sebagai lingkungan pengujian. Ini adalah praktik umum dalam pengembangan perangkat lunak. Namun, pendekatan seperti itu dalam kasus model ML mungkin tidak menghasilkan ROI yang tepat tergantung pada ukuran data dan dapat memengaruhi model dalam hal masalah bisnis yang ditanganinya.
Security – Lingkungan pengujian sering kali diharapkan memiliki data sampel alih-alih data pelanggan nyata dan akibatnya, penanganan data dan aturan kepatuhan dapat menjadi kurang ketat. Sama seperti biaya, jika Anda hanya menduplikasi lingkungan produksi ke dalam lingkungan pengujian, Anda dapat menimbulkan risiko keamanan dan kepatuhan.
Skalabilitas toko fitur – Jika organisasi memutuskan untuk tidak membuat penyimpanan fitur pengujian terpisah karena alasan biaya atau keamanan, maka pengujian model perlu dilakukan di penyimpanan fitur produksi, yang dapat menyebabkan masalah skalabilitas karena lalu lintas berlipat ganda selama periode pengujian.
Performa model online – Evaluasi online berbeda dari evaluasi offline dan dapat menjadi penting dalam beberapa kasus seperti model rekomendasi karena mereka mengukur kepuasan pengguna secara real time daripada kepuasan yang dirasakan. Sulit untuk mensimulasikan pola lalu lintas nyata di non-produksi karena musim atau perilaku pengguna lainnya, sehingga kinerja model online hanya dapat dilakukan dalam produksi.
Kinerja operasional – Karena model semakin besar dan semakin banyak digunakan secara terdesentralisasi pada perangkat keras yang berbeda, penting untuk menguji model untuk kinerja operasional yang Anda inginkan seperti latensi, tingkat kesalahan, dan banyak lagi.

Sebagian besar tim ML memiliki pendekatan multi-cabang untuk pengujian model. Di bagian berikut, kami menyediakan cara untuk mengatasi tantangan ini selama berbagai tahap pengujian.

Pengujian model offline

Tujuan dari fase pengujian ini adalah untuk memvalidasi versi baru dari model yang ada dari sudut pandang akurasi. Ini harus dilakukan secara offline agar tidak memengaruhi prediksi apa pun dalam sistem produksi yang menyajikan prediksi waktu nyata. Dengan memastikan bahwa model baru berperforma lebih baik untuk metrik evaluasi yang berlaku, pengujian ini menjawab tantangan 1 (kinerja akurasi model). Selain itu, dengan menggunakan kumpulan data yang tepat, pengujian ini dapat mengatasi tantangan 2 dan 3 (kualitas data pengujian, kepentingan fitur, dan paritas), dengan manfaat tambahan mengatasi tantangan 5 (biaya).

Tahap ini dilakukan di lingkungan pementasan.

Anda harus menangkap lalu lintas produksi, yang dapat Anda gunakan untuk memutar ulang dalam pengujian ulang offline. Lebih baik menggunakan lalu lintas produksi sebelumnya daripada data sintetis. Itu Monitor Model Amazon SageMaker fitur pengambilan data memungkinkan Anda menangkap lalu lintas produksi untuk model yang dihosting di Amazon SageMaker. Hal ini memungkinkan pengembang model untuk menguji model mereka dengan data dari hari kerja puncak atau peristiwa penting lainnya. Data yang diambil kemudian diputar ulang terhadap versi model baru secara batch menggunakan Transformasi batch Sagemaker. Ini berarti bahwa proses transformasi batch dapat menguji dengan data yang telah dikumpulkan selama berminggu-minggu atau berbulan-bulan hanya dalam beberapa jam. Ini dapat secara signifikan mempercepat proses evaluasi model dibandingkan dengan menjalankan dua atau lebih versi model real-time secara berdampingan dan mengirimkan permintaan prediksi duplikat ke setiap titik akhir. Selain menemukan versi yang berkinerja lebih baik lebih cepat, pendekatan ini juga menggunakan sumber daya komputasi untuk waktu yang lebih singkat, sehingga mengurangi biaya keseluruhan.

Tantangan dengan pendekatan pengujian ini adalah bahwa kumpulan fitur berubah dari satu versi model ke versi lainnya. Dalam skenario ini, kami menyarankan untuk membuat kumpulan fitur dengan superset fitur untuk kedua versi sehingga semua fitur dapat ditanyakan sekaligus dan direkam melalui pengambilan data. Setiap panggilan prediksi kemudian dapat bekerja hanya pada fitur-fitur yang diperlukan untuk versi model saat ini.

Sebagai bonus tambahan, dengan mengintegrasikan Memperjelas Amazon SageMaker dalam pengujian model offline, Anda dapat memeriksa versi baru model untuk bias dan juga membandingkan atribusi fitur dengan versi model sebelumnya. Dengan pipeline, Anda dapat mengatur seluruh alur kerja sehingga setelah pelatihan, langkah pemeriksaan kualitas dapat dilakukan untuk melakukan analisis metrik model dan kepentingan fitur. Metrik ini disimpan di Registri model SageMaker untuk perbandingan pada pelatihan berikutnya.

Integrasi dan pengujian kinerja

Pengujian integrasi diperlukan untuk memvalidasi proses bisnis end-to-end dari perspektif kinerja fungsional serta runtime. Dalam proses ini, seluruh pipeline harus diuji, termasuk mengambil, dan menghitung fitur di penyimpanan fitur dan menjalankan aplikasi ML. Ini harus dilakukan dengan berbagai muatan yang berbeda untuk mencakup berbagai skenario dan permintaan dan mencapai cakupan tinggi untuk semua kemungkinan menjalankan kode. Ini mengatasi tantangan 4 dan 9 (pengujian proses bisnis dan kinerja operasional) untuk memastikan tidak ada proses bisnis yang rusak dengan model versi baru.

Pengujian ini harus dilakukan di lingkungan pementasan.

Pengujian integrasi dan pengujian kinerja perlu diterapkan oleh masing-masing tim menggunakan saluran MLOps mereka. Untuk pengujian integrasi, kami merekomendasikan metode yang telah dicoba dan diuji untuk mempertahankan lingkungan pra-produksi yang setara secara fungsional dan pengujian dengan beberapa muatan yang berbeda. Alur kerja pengujian dapat diotomatisasi seperti yang ditunjukkan pada bengkel ini. Untuk pengujian kinerja, Anda dapat menggunakan Rekomendasi Inferensi Amazon SageMaker, yang menawarkan titik awal yang bagus untuk menentukan jenis instans mana dan berapa banyak instans yang akan digunakan. Untuk ini, Anda harus menggunakan alat pembangkit beban, seperti proyek sumber terbuka pembuat perfsizesage dan ukuran sempurna yang telah dikembangkan oleh Intuit. Perfsizesagemaker memungkinkan Anda menguji konfigurasi titik akhir model secara otomatis dengan berbagai persyaratan muatan, waktu respons, dan transaksi puncak per detik. Ini menghasilkan hasil tes rinci yang membandingkan versi model yang berbeda. Perfsize adalah alat pendamping yang mencoba konfigurasi berbeda yang diberikan hanya transaksi puncak per detik dan waktu respons yang diharapkan.

Pengujian A / B

Dalam banyak kasus di mana reaksi pengguna terhadap keluaran langsung dari model diperlukan, seperti aplikasi e-niaga, evaluasi fungsional model offline tidak cukup. Dalam skenario ini, Anda perlu menguji model A/B dalam produksi sebelum membuat keputusan untuk memperbarui model. Pengujian A/B juga memiliki risiko karena mungkin ada dampak nyata bagi pelanggan. Metode pengujian ini berfungsi sebagai validasi kinerja ML akhir, pemeriksaan kewarasan rekayasa ringan. Metode ini juga menjawab tantangan 8 dan 9 (kinerja model online dan keunggulan operasional).

Pengujian A/B harus dilakukan di lingkungan produksi.

Dengan SageMaker, Anda dapat dengan mudah melakukan pengujian A/B pada model ML dengan menjalankan beberapa varian produksi pada sebuah titik akhir. Lalu lintas dapat dialihkan secara bertahap ke versi baru untuk mengurangi risiko model yang berperilaku buruk pada produksi. Jika hasil pengujian A/B terlihat bagus, lalu lintas dialihkan ke versi baru, yang pada akhirnya mengambil alih 100% lalu lintas. Kami merekomendasikan penggunaan pagar pembatas penerapan untuk transisi dari model A ke B. Untuk diskusi yang lebih lengkap tentang pengujian A/B menggunakan Amazon Personalisasi model sebagai contoh, lihat Menggunakan pengujian A / B untuk mengukur efektivitas rekomendasi yang dihasilkan oleh Amazon Personalize.

Pengujian model online

Dalam skenario ini, versi baru model sangat berbeda dengan versi yang sudah menayangkan lalu lintas langsung dalam produksi, sehingga pendekatan pengujian offline tidak lagi cocok untuk menentukan keefektifan versi model baru. Alasan paling menonjol untuk ini adalah perubahan fitur yang diperlukan untuk menghasilkan prediksi, sehingga transaksi yang dicatat sebelumnya tidak dapat digunakan untuk menguji model. Dalam skenario ini, sebaiknya gunakan penerapan bayangan. Penempatan bayangan menawarkan kemampuan untuk menyebarkan bayangan (atau penantang) model di samping produksi (atau juara) model yang saat ini menyajikan prediksi. Ini memungkinkan Anda mengevaluasi kinerja model bayangan dalam lalu lintas produksi. Prediksi model bayangan tidak disajikan ke aplikasi yang meminta; mereka masuk untuk evaluasi offline. Dengan pendekatan bayangan untuk pengujian, kami mengatasi tantangan 4, 5, 6, dan 7 (pengujian proses bisnis, biaya, keamanan, dan skalabilitas toko fitur).

Pengujian model online harus dilakukan di lingkungan pementasan atau produksi.

Metode pengujian versi model baru ini harus digunakan sebagai upaya terakhir jika semua metode lain tidak dapat digunakan. Kami merekomendasikannya sebagai upaya terakhir karena panggilan dupleks ke beberapa model menghasilkan beban tambahan pada semua layanan hilir dalam produksi, yang dapat menyebabkan kemacetan kinerja serta peningkatan biaya dalam produksi. Dampak yang paling jelas adalah pada lapisan penyajian fitur. Untuk kasus penggunaan yang berbagi fitur dari kumpulan data fisik yang sama, kita harus dapat mensimulasikan beberapa kasus penggunaan secara bersamaan mengakses tabel data yang sama untuk memastikan tidak ada pertikaian sumber daya sebelum beralih ke produksi. Jika memungkinkan, kueri duplikat ke penyimpanan fitur harus dihindari, dan fitur yang diperlukan untuk kedua versi model harus digunakan kembali untuk inferensi kedua. Fitur toko berdasarkan Amazon DynamoDB, seperti yang telah dibangun oleh Intuit, dapat diimplementasikan Akselerator Amazon DynamoDB(DAX) ke cache dan menghindari penggandaan I/O ke database. Opsi ini dan opsi caching lainnya dapat mengurangi tantangan 7 (skalabilitas penyimpanan fitur).

Untuk mengatasi tantangan 5 (biaya) serta 7, kami mengusulkan penggunaan penerapan bayangan untuk mengambil sampel lalu lintas masuk. Ini memberi pemilik model lapisan kontrol lain untuk meminimalkan dampak pada sistem produksi.

Penempatan bayangan harus diarahkan ke Monitor Model penawaran seperti penyebaran produksi reguler untuk mengamati peningkatan versi penantang.

Kesimpulan

Posting ini mengilustrasikan blok bangunan untuk membuat serangkaian proses dan alat yang komprehensif untuk mengatasi berbagai tantangan dengan pengujian model. Meskipun setiap organisasi unik, ini akan membantu Anda memulai dan mempersempit pertimbangan Anda saat menerapkan strategi pengujian Anda sendiri.

Tentang penulis

Tobias Wenzel adalah Manajer Rekayasa Perangkat Lunak untuk Platform Pembelajaran Mesin Intuit di Mountain View, California. Dia telah mengerjakan platform ini sejak didirikan pada tahun 2016 dan telah membantu merancang dan membangunnya dari bawah ke atas. Dalam pekerjaannya, ia berfokus pada keunggulan operasional platform dan membawanya dengan sukses melalui bisnis musiman Intuit. Selain itu, ia bersemangat untuk terus memperluas platform dengan teknologi terbaru.

Shivanshu Upadhyay adalah Arsitek Solusi Utama di grup Pengembangan Bisnis dan Industri Strategis AWS. Dalam peran ini, dia membantu sebagian besar pengadopsi AWS tingkat lanjut mengubah industri mereka dengan menggunakan data dan AI secara efektif.

Alan Tan adalah Manajer Produk Senior dengan SageMaker, memimpin upaya pada inferensi model besar. Dia bersemangat menerapkan pembelajaran mesin ke bidang analitik. Di luar pekerjaan, dia menikmati alam bebas.