Layanan prediksi dan pengoptimalan berdasarkan Pembelajaran Mesin menarik bagi banyak perusahaan saat ini: dari bank besar hingga toko online kecil. Memecahkan masalah berbagai klien, kami mengalami sejumlah masalah, yang berfungsi sebagai dasar untuk diskusi kami pada fitur pengujian ML. Bagi mereka yang tertarik, ini adalah posting kami berikutnya dari Sergey Agaltsov, manajer uji Jet Infosystems.
Sebelumnya, hanya perusahaan besar yang dapat memanfaatkan pembelajaran mesin, karena biayanya mahal dan sulit, dan sangat sedikit data dalam domain publik. Sekarang ini menjadi lebih mudah. Keahlian ML dapat diminta dari integrator, perusahaan khusus atau di situs tematik. Ini bagus untuk semua orang, karena dengan pertumbuhan keahlian, algoritma baru dikembangkan, dan "celengan pengalaman" di bidang pembelajaran mesin terus-menerus diperkaya.
Satu-satunya aspek yang kami tidak menemukan solusi siap pakai adalah pengujian layanan ML. Googling, Anda dapat memastikan bahwa dalam hasil pencarian tidak disebutkan kegiatan penguji dalam pengembangan layanan tersebut. Tentu saja, para ahli ilmu data sendiri menguji model mereka menggunakan berbagai metrik, dan menurut metrik ini layanan bahkan mungkin seakurat mungkin, namun kenyataannya adalah bahwa model tidak selalu dapat memperhitungkan berbagai nuansa dan hambatan produksi. Kemudian logika pembelajaran mesin mulai tumbuh menjadi hardcode.
Dalam hal ini, kami mulai menghadapi sejumlah masalah:
- Apakah model pengoptimalan kami selalu mempertimbangkan kemungkinan kendala produksi?
- Apakah model kami dapat bekerja dengan kemacetan?
- Apakah model kami mampu merespons perubahan produksi dengan benar?
Di sinilah kami memutuskan untuk memfokuskan tim pengujian.
Tugas kami adalah untuk menyatukan praktik pengujian ML agar dapat menanggapi semua masalah di atas. Saat ini, kami telah mencapai sejumlah kesimpulan, dan sekarang saya akan memberi tahu Anda yang mana.
Uji kepatuhan dengan batasan dan persyaratan produksi untuk dipertimbangkan oleh algoritma pengoptimalan
Dalam pengujian klasik, dalam pengujian apa pun kami selalu memiliki "hasil yang diharapkan". Kami benar-benar tahu apa reaksi sistem seharusnya pada satu atau yang lain dari data input. Namun, jika kita berbicara tentang ML dalam lingkungan produksi, maka hasil yang paling dinanti ini mungkin sesuai dengan dokumen peraturan, seperti GOST, instruksi teknologi, dan lembar aliran sementara, yang membatasi proses produksi itu sendiri dan kriteria kualitas produk akhir. Selama pengujian mereka, kita harus yakin bahwa semua pembatasan ini benar-benar diperhatikan, dan terlepas dari jumlahnya, kami yakin bahwa masing-masing dicakup oleh kasus uji.
Pada contoh proyek nyata untuk mengoptimalkan produksi bahan N (kami belum mengungkapkan kasus ini, oleh karena itu kami akan menggunakan nama anonim), kami memecahkan masalah ini sebagai berikut:
- Kami telah mengklasifikasikan semua tingkat campuran bahan N berdasarkan tingkat elemen kimia di dalamnya. Sebagai hasilnya, kami mendapat daftar, yang kemudian kami rencanakan untuk digunakan sebagai bantuan untuk memastikan cakupan tes yang memadai.
- Kami yakin bahwa rekomendasi yang dikeluarkan oleh model untuk semua campuran ini sebenarnya diterima tanpa syarat oleh teknologi produksi dan mencatat hasil masalah ini dalam file CSV. Dengan demikian, kami menerima rekomendasi dari sistem "standar emas" tertentu.
- Kemudian sebuah skrip ditulis yang memuat daftar campuran referensi kami melalui model dari versi ke versi dan membandingkan hasil pengirimannya dengan apa yang disimpan dalam csv "standar emas" kami.
- Jika tidak ada perubahan dalam perilaku model yang terdeteksi, maka uji regresi dapat dianggap berhasil. Jika tidak, "wawancara" dilakukan.
Dengan demikian, kami dapat menyelesaikan masalah pengujian regresi dan mendapatkan kepercayaan bahwa perubahan yang dimasukkan ke dalam model tidak mempengaruhi hasil pekerjaan kami sebelumnya.
Pengujian difokuskan pada kemacetan
Model optimasi paling baik untuk memprediksi apa yang paling sering ditemukan dalam data historis, dan, sebaliknya, model dapat "berubah menjadi labu" segera setelah ia menemukan sesuatu yang tidak biasa untuk dirinya sendiri.
Seringkali dalam kasus seperti itu, layanan optimisasi harus "meminta" model perilaku yang memadai dan ini menghasilkan hardcode yang saya tulis sebelumnya. Tetapi bagaimana cara mengidentifikasi hambatan ini dan men-debug layanan? Saya akan membicarakan hal ini pada contoh pengembangan layanan untuk rekomendasi dalam mengelola produksi materi N (kasus ini belum dapat diungkapkan, oleh karena itu, nama terselubung dirujuk di bawah).
Pertama-tama, arsitek kami mengembangkan emulator integrasi yang menghasilkan data yang mirip dengan produktif dan dengan demikian mengisi kerangka tanggal, berdasarkan model pengoptimalan yang mengeluarkan rekomendasi untuk memproses bahan N. Selanjutnya, tester menganalisis rekomendasi ini dan mengidentifikasi yang paling mencurigakan - yang tersingkir parameter yang direkomendasikan adalah aliran massa total. Sudah pada tahap ini, kami dapat mengidentifikasi banyak masalah ketika model dalam satu atau lain cara tidak dapat secara memadai memproses aliran data yang masuk. Ini memungkinkan kami untuk menstabilkan keadaan layanan dan beralih ke langkah berikutnya.
Tahap kedua adalah pengujian "Diam". Layanan dinaikkan di lingkungan produksi di latar belakang. Dia bekerja tanpa mengganggu operator pemrosesan material N dari kontrol alat berat, dan kami, pada gilirannya, mengumpulkan "solusi operator", membandingkannya dengan apa yang direkomendasikan layanan. Karena ini, kami menemukan titik-titik buta model yang tidak dapat ditangkap pada tahap sebelumnya.
Model harus mampu merespons perubahan produksi.
Kami memiliki portofolio layanan dalam portofolio proyek kami untuk mengoptimalkan produksi bahan bakar. Inti dari layanan ini adalah bahwa teknolog mentransfer stok komponen produksi ke model, menetapkan indikator pembatas kualitas produk dan menetapkan rencana produksi yang diperlukan, dan sebagai tanggapan menerima rekomendasi: dalam proporsi apa ia perlu menggunakan komponen tertentu untuk mendapatkan bahan bakar dari jumlah yang ditentukan kualitas.
Dalam proses pengembangan layanan ini, kami menemukan masalah yang tidak dapat kami perkirakan sebelumnya.
Selama beberapa tahun, perusahaan dalam produksi bahan bakar bekerja dalam kisaran tertentu revolusi agregat dan pada saat yang sama digunakan plus / minus rasio komponen yang sama.
Namun baru-baru ini, organisasi telah mengubah pasokan komponen-komponen ini dan menjadi mungkin untuk mengkompensasi fakta ini dengan meningkatkan kecepatan unit. Pelanggan berharap bahwa model akan dapat menanggapi perubahan ini, sehingga dari sudut pandang produksi teknologi - ini adalah solusi yang dapat diterima, tetapi ini tidak terjadi. Mengapa Jawabannya jelas - model dilatih pada sampel sejarah, di mana ini tidak terjadi sebelumnya. Anda dapat berbicara untuk waktu yang lama tentang topik siapa yang benar dalam situasi ini dan siapa yang harus disalahkan, tetapi di masa depan kami berencana untuk mengurangi kemungkinan situasi seperti berikut:
- Bekerja lebih dekat dengan perwakilan pelanggan dari unit produksi untuk mengidentifikasi hambatan dan potensi perubahan produk.
- Tutupi test case dengan case serupa sebelumnya.
- Tulis autotest untuk memeriksa kepatuhan dengan batasan produksi dan korelasi tanda-tanda.
Hanya beberapa kata tentang alat pengujian yang harus kami gunakan:
- bugtracking - Jira,
- sistem manajemen mutu - Uji Rel,
- sistem kontrol versi - GitLab,
- CI / CD - Jenkins,
- autotests - Java + Junit / TestNG,
- skrip untuk interaksi langsung dengan model - Python + Jupyter.
Apakah Anda menguji ML?
Bagi kami, membangun praktik pengujian ML telah menjadi tantangan, itu sebenarnya harus ditumbuhkan dari awal. Tetapi pengujian diperlukan - ini membantu mengurangi jumlah kesalahan sebelum masuk ke operasi uji coba dan mempersingkat waktu implementasi.
Hari ini, kita semua perlu berbagi dan bertukar pengalaman. Penting untuk memulai diskusi tentang pengujian di situs khusus dan forum profesional, yang, dengan cara, semakin menjadi di bidang ML. Dan jika Anda sudah memiliki praktik untuk menguji ML, saya pikir semua orang akan tertarik untuk membacanya, jadi bagikan pengalaman Anda dalam komentar.
Sergey Agaltsov, Manajer Tes, Jet Infosystems