By Harun Soellinger & Akankah Kunzo

Saat merancang tumpukan MLOps untuk proyek kami, kami membutuhkan solusi yang memungkinkan penyesuaian dan fleksibilitas tingkat tinggi untuk berkembang sesuai dengan eksperimen kami. Kami mempertimbangkan platform besar yang mencakup banyak fungsi, tetapi ternyata membatasi di beberapa area utama. Akhirnya kami memutuskan pendekatan di mana alat khusus yang terpisah diterapkan untuk pelabelan, versi data, dan integrasi berkelanjutan. Artikel ini mendokumentasikan pengalaman kami dalam membangun pendekatan MLOps kustom ini.

Foto oleh Menemukan Dan | Dan Grinwis on Unsplash

NBDEV

(Diambil dari https://github.com/fastai/nbdev)

Masalah klasik menggunakan Jupyter untuk pengembangan adalah berpindah dari prototipe ke produksi yang memerlukan kode salin/tempel dari notebook ke modul python. NBDEV mengotomatiskan transisi antara notebook dan modul, sehingga memungkinkan notebook Jupyter menjadi bagian resmi dari jalur produksi. NBDEV memungkinkan pengembang untuk menyatakan modul mana yang harus dibuat oleh notebook, sel notebook mana yang akan didorong ke modul dan sel notebook mana yang akan diuji. Kemampuan utama NBDEV adalah pendekatannya terhadap pengujian di dalam notebook, dan template NBDEV bahkan menyediakan Github Action dasar untuk mengimplementasikan pengujian dalam kerangka kerja CI/CD. Modul Python yang dihasilkan tidak memerlukan pengeditan oleh pengembang, dan dapat dengan mudah diintegrasikan ke dalam notebook lain atau proyek pada umumnya menggunakan fungsionalitas impor python bawaan.

Iteratif.ai: DVC/CML

(Diambil dari https://iterative.ai/)

File yang digunakan dalam alur pembelajaran mesin seringkali merupakan arsip besar file biner/terkompresi, yang tidak dapat diakses atau mahal untuk solusi kontrol versi yang ada seperti git. DVC memecahkan versi data dengan mewakili kumpulan data besar sebagai hash dari konten file yang memungkinkan DVC untuk melacak perubahan. Ia bekerja mirip dengan git (misalnya dvc add, dvc push). Saat kamu berlari dvc add pada dataset Anda, itu akan ditambahkan ke .gitignore dan dilacak untuk perubahan oleh dvc. CML adalah proyek yang menyediakan fungsionalitas untuk memublikasikan artefak model dari alur kerja Tindakan Github ke dalam komentar terlampir Masalah Github, Permintaan Tarik, dll... Itu penting karena membantu kita mulai mengisi kesenjangan dalam Permintaan Tarik yang memperhitungkan perubahan data pelatihan dan hasil akurasi dan efektivitas model.

Tindakan Github

(Diambil dari https://github.com/features/actions)

Kami menginginkan pengujian kode otomatis, termasuk membangun model dalam jalur pengujian otomatis. Github Actions bersaing dengan CircleCI, Travis, Jenkins, yang mengotomatiskan pengujian di sekitar kode push, commit, pull request, dll. Karena kami sudah menggunakan Github untuk menghosting repo kami, kami menghindari aplikasi pihak ketiga lainnya dengan menggunakan Actions. Dalam proyek ini kita perlu menggunakan runner yang dihosting sendiri oleh Github untuk menjalankan pekerjaan di kluster GPU lokal.

Studio Label

(Diambil dari https://labelstud.io/)

Kami melakukan penyelaman mendalam tentang bagaimana kami menggunakan Label Studio yang ditemukan di sini. Label Studio adalah solusi untuk pelabelan data. Ia bekerja dengan baik, dan fleksibel untuk dijalankan di berbagai lingkungan.

Mengapa menggunakannya bersama-sama?

 
 
Penyiapan dirancang untuk menerapkan model lebih cepat. Artinya, lebih banyak ilmuwan data yang bekerja secara paralel secara harmonis, transparansi dalam repositori, dan waktu orientasi yang lebih cepat untuk orang-orang baru. Tujuannya adalah untuk membakukan jenis kegiatan yang perlu dilakukan oleh ilmuwan data dalam proyek dan memberikan instruksi yang jelas untuk mereka.

Berikut ini adalah daftar tugas yang ingin kami sederhanakan dengan desain sistem ini:

1. Otomatiskan penyerapan dari Label Studio dan berikan satu poin untuk menyerapnya ke dalam aktivitas pelatihan dan evaluasi model.
2. Pengujian otomatis pada kode pipa data, yaitu pengujian unit dan penyebaran ulang wadah yang digunakan oleh proses.
3. Pengujian otomatis pada kode model, yaitu pengujian unit dan penyebaran ulang wadah yang digunakan oleh proses.
4. Aktifkan pengujian otomatis untuk menyertakan pelatihan ulang model dan kriteria evaluasi. Ketika kode model berubah, latih model dengan kode baru dan bandingkan dengan model lama yang ada.
5. Memicu pelatihan ulang model saat data pelatihan berubah.

Di bawah ini adalah deskripsi pipeline untuk setiap tugas.

Pipa CI/CD Tradisional

 
 
Pipeline ini mengimplementasikan umpan balik pengujian otomatis untuk setiap permintaan tarikan yang mencakup evaluasi sintaks, unit, regresi, dan pengujian integrasi. Hasil dari proses ini adalah gambar buruh pelabuhan yang diuji secara fungsional ke repositori pribadi kami. Proses ini memaksimalkan kemungkinan bahwa kode terbaik terbaru ada dalam gambar yang diuji sepenuhnya yang tersedia di repositori untuk tugas-tugas hilir. Berikut cara kerja siklus hidup developer dalam konteks fitur baru:

Di sini kami menunjukkan bagaimana alur kerja berfungsi saat mengedit kode. Menggunakan NBDEV memungkinkan kami untuk bekerja langsung dari notebook Jupyter termasuk menulis tes langsung di notebook. NBDEV mengharuskan semua sel di notebook berjalan tanpa kecuali (kecuali sel ditandai untuk tidak dijalankan). (Gambar oleh Penulis)

Pipa data

 
 
Label Studio saat ini tidak memiliki kait peristiwa yang memungkinkan pembaruan pada perubahan pada data label yang disimpan. Jadi kita ambil cron pendekatan yang dipicu, memperbarui dataset setiap jam. Selain itu, meskipun kumpulan data pelatihan studio label cukup kecil, pembaruan juga dapat dilakukan sebagai bagian dari alur pelatihan. Kami memiliki kemampuan untuk memicu penyegaran pipa data sesuai permintaan menggunakan antarmuka Tindakan Github.

Pipeline data diumpankan dari Label Studio, dan mempertahankan setiap versi set data dan input yang relevan ke cache DVC yang disimpan di AWS S3. (Gambar oleh Penulis)

Model Pipa

 
 
Pipeline pemodelan mengintegrasikan pelatihan model ke dalam pipeline CI/CD untuk repositori. Hal ini memungkinkan setiap permintaan tarik untuk mengevaluasi sintaks, unit, integrasi, dan uji regresi yang dikonfigurasi pada basis kode, tetapi juga dapat memberikan umpan balik yang mencakup evaluasi model baru yang dihasilkan

Alur kerja dalam hal ini, jalankan eksperimen pelatihan model yang ditentukan dalam file konfigurasi (model_params.yaml) dan perbarui artefak model (model terbaik.pth) (Gambar oleh Penulis)

Pipa Evaluasi Tolok Ukur

 
 
Pipa benchmarking membentuk proses "pengajuan resmi" untuk memastikan semua aktivitas pemodelan diukur terhadap metrik proyek.

Model yang baru dilatih di best-model.pth dievaluasi berdasarkan kumpulan data benchmark dan hasilnya ditandai dengan hash komit terbaru dan bertahan di AWS S3. (Gambar oleh Penulis)

Workflow

 
 
Berikut adalah file definisi DAG yang digunakan oleh DVC. Ini menangkap langkah-langkah alur kerja dan inputnya, dan memungkinkan reproduktifitas di seluruh pengguna dan mesin.

stages: labelstudio_export_trad: cmd: python pipelines/1_labelstudio_export.py --config_fp pipelines/traditional_pipeline.yaml --ls_token *** --proj_root "." params: - pipelines/traditional_pipeline.yaml: - src.host - src.out_fp - src.proj_id dataset_create_trad: cmd: python pipelines/2_labelstudio_todataset.py --config_fp pipelines/create_traditional.yaml --proj_root "." deps: - data/raw_labels/traditional.json params: - pipelines/create_traditional.yaml: - dataset.bmdata_fp - dataset.labels_map - dataset.out_fp - dataset.rawdata_dir train_model_trad: cmd: python pipelines/3_train_model.py --config_fp pipelines/model_params.yaml --proj_root "." deps: - data/traditional_labeling params: - pipelines/model_params.yaml: - dataloader.bs - dataloader.size - dataloader.train_fp - dataloader.valid_fp - learner.backbone - learner.data_dir - learner.in_checkpoint - learner.metrics - learner.n_out - learner.wandb_project_name - train.cycles labelstudio_export_bench: cmd: python pipelines/1_labelstudio_export.py --config_fp pipelines/benchmark_pipeline.yaml --ls_token *** --proj_root "." params: - pipelines/benchmark_pipeline.yaml: - src.host - src.out_fp - src.proj_id dataset_create_bench: cmd: python pipelines/2_labelstudio_todataset.py --config_fp pipelines/create_benchmark.yaml --proj_root "." deps: - data/raw_labels/benchmark.json params: - pipelines/create_benchmark.yaml: - dataset.bmdata_fp - dataset.labels_map - dataset.out_fp - dataset.rawdata_dir eval_model_trad: cmd: python pipelines/4_eval_model.py --config_fp pipelines/bench_eval.yaml --proj_root "." deps: - data/models/best-model.pth params: - pipelines/bench_eval.yaml: - eval.bench_fp - eval.label_config - eval.metrics_fp - eval.model_conf - eval.overlay_dir

Temuan

1. Alur kerja Tindakan Github cron pemicu tidak terlalu dapat diandalkan. Itu tidak menjamin waktu.
2. DVC tidak bekerja dengan jelas di dalam alur kerja Github Action yang dipicu saat push. Ini akan mengubah pelacak yang dikendalikan oleh sumber dan ketika itu dilakukan, itu akan membuat tindakan Github lain.
3. Orkestrasi Github Actions sebagai mekanisme untuk menjalankan model membutuhkan runner yang dihosting sendiri untuk menggunakan GPU. Ini berarti menghubungkan ke instans GPU di cloud atau lokal, dan ini menimbulkan masalah dengan kontrol akses. Misalnya, kami tidak dapat membuka sumber repo yang tepat tanpa menghapus konfigurasi runner yang dihosting sendiri dari repo atau orang lain secara acak akan dapat menjalankan beban kerja di server pelatihan kami dengan mendorong kode ke proyek.
4. Alur kerja bawaan NBDEV sedang menguji kode di tempat yang salah. Ini menguji notebook alih-alih paket yang dikompilasi. Di satu sisi, senang bisa mengatakan bahwa "tes dapat ditulis langsung ke dalam buku catatan". Di sisi lain, pengujian notebook secara langsung membuka kemungkinan bahwa paket kode yang dibuat oleh NBDEV gagal meskipun notebook dijalankan. Yang kami butuhkan adalah kemampuan untuk menguji paket yang dikompilasi NBDEV secara langsung
5. NBDEV tidak beroperasi dengan pengembangan Python "tradisional" dalam arti bahwa NBDEV adalah jalan satu arah. Ini hanya memungkinkan proyek untuk dikembangkan dalam gaya notebook Jupyter interaktif. Itu membuat tidak mungkin untuk mengembangkan modul Python secara langsung. Jika suatu saat, proyek ingin dikonversi ke pengujian pengembangan Python "tradisional" perlu dilakukan dengan cara lain.
6. Pada awalnya, kami menggunakan Bobot & Bias sebagai dasbor pelacakan eksperimen kami, namun ada masalah saat menerapkannya ke dalam Tindakan Github. Apa yang dapat kami katakan adalah bahwa pengalaman pengguna untuk mengimplementasikan wandb mencapai cegukan pertamanya di Action Workflow. Menghapus Bobot & Bias segera menyelesaikan masalah. Sebelum itu, wandb menonjol sebagai pengalaman pengguna terbaik di MLOps.

Kesimpulan

 
 
Pada akhirnya, butuh satu minggu untuk menyelesaikan implementasi alat ini untuk mengelola kode kami dengan Tindakan Github, alat Iterative.ai (DVC & CML) dan NBDEV. Ini memberi kami kemampuan berikut:

1. Bekerja dari notebook Jupyter sebagai sistem pencatatan kode. Kami menyukai Jupyter. Kasus penggunaan utama yang diselesaikannya adalah memungkinkan kami untuk bekerja secara langsung pada perangkat keras apa pun yang dapat kami gunakan untuk SSH dengan meng-hosting server Jupyter di sana dan meneruskannya ke desktop. Untuk lebih jelasnya, kami akan melakukan ini bahkan jika kami tidak menggunakan NBDev karena alternatifnya adalah menggunakan Vim atau alat semacam itu yang tidak terlalu kami sukai. Eksperimen sebelumnya untuk terhubung ke server jarak jauh dengan VS Code atau Pycharm gagal. Jadi itu Jupyter.
2. Menguji kode, dan menguji model yang dibuatnya. Sekarang sebagai bagian dari pipa CI/CD kita dapat mengevaluasi apakah model yang dihasilkan dari perubahan repo membuat model lebih baik, lebih buruk atau tetap sama. Ini semua tersedia dalam permintaan tarik sebelum digabungkan menjadi main.
3. Menggunakan server Github Actions sebagai orkestra untuk menjalankan pelatihan mulai memungkinkan beberapa ilmuwan data untuk bekerja secara bersamaan dengan cara yang lebih jelas. Ke depannya, kita akan melihat keterbatasan penyiapan ini untuk mengatur proses ilmu data kolaboratif.

 
Harun Soellinger sebelumnya bekerja sebagai ilmuwan data dan insinyur perangkat lunak yang memecahkan masalah di bidang keuangan, pemeliharaan prediktif, dan olahraga. Dia saat ini bekerja sebagai konsultan sistem pembelajaran mesin dengan Hoplabs yang mengerjakan aplikasi visi komputer multi-kamera.

Akankah Kunzo adalah pengembang perangkat lunak back-end, membawa sikap bisa-lakukan dan tekad teguh untuk tantangan. Tidak masalah apakah itu melacak bug yang sulit dipahami atau beradaptasi dengan cepat ke teknologi baru. Jika ada solusi, Will ingin menemukannya.

Original. Diposting ulang dengan izin.

Terkait:

• Praktik Terbaik MLOps
• MLOps adalah Disiplin Teknik: Gambaran Umum Pemula
• Peta Jalan MLOps Dan Pembelajaran Mesin