lightning mlflow hf
1.0.0
Proses dan informasi adalah jantung dari setiap bisnis. Kerentanan dan peluang saat ini adalah pertanyaan apakah bisnis Anda dapat mengotomatiskan proses Anda menggunakan AI, dan menuai hasil dari melakukannya. Chatgpt, AI tujuan umum, telah membuka mata kita terhadap apa yang bisa dilakukan AI. Yang penting sekarang adalah mengarahkan kekuatan AI ke masalah bisnis Anda dan membuka kunci nilai data hak milik Anda . Dalam dokumen ini, saya akan menunjukkan caranya.
Anda tidak ingin AI yang hanya bisa mengobrol; Yang benar-benar Anda inginkan adalah otomatisasi yang melakukan pekerjaan yang membuat bisnis Anda tetap berjalan-berkuasa melalui proses bisnis dengan akurasi dan skala yang sangat besar. Cara terbukti untuk menyesuaikan AI dengan proses bisnis Anda adalah dengan menyempurnakan LLM pada data Anda dan pada tindakan yang Anda ingin AI lakukan.
Mari kita bicara secara khusus tentang fine tuning yang akan kita lakukan dalam dokumen ini dan teknologi di baliknya. Di bawah ini adalah lima alat yang akan kami gunakan secara luas:
Pada akhirnya, Anda harus mengambil dua hal dari dokumen ini:
Saya akan menggambarkan kepada Anda masalah yang sulit dan nyata, apa yang telah dilakukan oleh peneliti pembelajaran mesin, dan perbatasan baru yang dapat kami dorong untuk menggunakan alat sota yang kuat. Kami akan melatih model di GPU di cloud. Kami juga akan menempatkan praktik MLOPS yang kuat ke dalam tindakan-menggunakan MLFLOW untuk mengatur eksperimen dan parameter kami. Dan di sepanjang jalan, saya akan menunjukkan pola desain proyek ini sehingga Anda dapat menyesuaikan basis kode untuk proyek pembelajaran mendalam Anda sendiri.
Mari kita mulai dengan latar belakang masalah.
Proses yang baik untuk menemukan masalah yang cocok untuk pembelajaran mesin dan untuk set data berkualitas adalah memulai dengan menjelajahi situs dengan tolok ukur. Benchmark memberikan kerangka referensi untuk tingkat kesulitan masalah untuk pembelajaran mesin, yang kami gunakan untuk mengukur kemajuan kami selama pengembangan model. Satu dataset tertentu dengan tolok ukur yang mapan adalah ketentuan dataset layanan yang tidak adil (tidak adil-untuk); Berikut pernyataan masalah yang menarik untuk itu: Gunakan AI untuk menemukan semua klausa yang tidak adil dalam hal kontrak layanan. Konteksnya adalah bahwa hukum konsumen Eropa tentang kontrak yang tidak adil menetapkan apa itu klausa yang tidak adil dan berbagai jenis klausa yang tidak adil. Apa yang membuat tidak adil-untuk klasifikasi teks adalah bahwa itu telah diberi label secara manual sesuai dengan apa yang ditetapkan dalam hukum Eropa.
Chalkidis et al. (2021) Menerapkan delapan metode pembelajaran mesin yang berbeda untuk tidak adil dan memperoleh makro F1 mulai dari 75 hingga 83, dan pada Gambar 1 tepat di bawah ini, kami kutipan dari hasil yang diterbitkan.
| Metode | Tidak adil-tos | |
|---|---|---|
| F1 mikro | F1 makro | |
| Tfidf-svm | 94.7 | 75.0 |
| Bert | 95.6 | 81.3 |
| Roberta | 95.2 | 79.2 |
| Deberta | 95.5 | 80.3 |
| Longformer | 95.5 | 80.9 |
| Bigbird | 95.7 | 81.3 |
| Legal-Bert | 96.0 | 83.0 |
| Caselaw-Bert | 96.0 | 82.3 |
Hal -hal menarik yang dapat kita simpulkan dari tabel ini adalah:
Melihat data, ketidakseimbangan kelas tentu ada, yang merupakan alasan bagus untuk poin pertama dan kedua di atas.
Ada delapan jenis klausa yang tidak adil. Para penulis makalah itu mengembangkan model klasifikasi multi-label untuk delapan jenis, tetapi kami hanya akan membangun model klasifikasi biner yang mengklasifikasikan klausul sebagai adil atau tidak adil.
Mari kita mendesain bagaimana kita akan melakukannya.
__init__.py memaparkan API publik dari modul di dalamnya sehingga kita dapat dengan mudah mempersingkat impor untuk fungsionalitas yang diterapkan secara mendalam seperti ini: from . fine_tune_clsify_head import TransformerModule Impor di atas dalam architectures/__init__.py memungkinkan kode architectures luar untuk mengimpor TransformerModule tanpa harus mengingat remah roti yang mengarah ke tempat fungsi ini, seperti ini:
from architectures import TransformerModuleInilah yang tampak seperti struktur proyek dari akar modul Lightning_Mlflow:
.
├── architectures
│ ├── __init__.py
│ └── fine_tune_clsify_head.py
├── config
│ ├── __init__.py
│ └── train_config.py
├── data
│ ├── __init__.py
│ └── lex_glue.py
└── train.py
Pertanyaan kuncinya adalah mengapa proyek disusun dengan cara ini. Dan jawabannya adalah bahwa pemisahan keprihatinan ditetapkan antara 3 submodul dan 1 titik masuk. Mari kita berjalan melalui masing -masing modul ini pada gilirannya:
architectures : Menentukan pada dasarnya semua yang perlu diketahui Pytorch kecuali untuk dataconfig : Memegang semua parameter dan dapat dibagi lagi menjadi train_config.py dan inference_config.py dan apa pundata : Menahan semua logika dan pengaturan pemrosesan datatrain.py : titik kontrol pusat; Ini adalah satu -satunya kode yang dapat melihat architectures , config , dan data ; MLFLOW Panggilan SDK Buka di siniDengan intro singkat ini, mari kita gulung lengan baju kita dan cobalah untuk benar -benar memahami kode di masing -masing modul. Mari kita mulai dengan arsitektur/fine_tune_clsify_head.py. Kode ini diatur seperti Gambar 3 tepat di bawah ini.
Jelas bahwa metode utama di dalam kelas ini untuk dipahami adalah: konstruktor, melewati melewati jaringan, metrik, dan langkah -langkahnya. Kami akan membahas masing -masing secara bergantian. Mari kita mulai dengan konstruktor. Cuplikan ini adalah seperti apa kodenya:
Yang benar -benar penting di sini adalah bahwa konstruktor memuat model pretrain dari memeluk wajah, dan mengatur parameter fine tuning (PEFT) parameter. PEFT adalah cara tepi pendarahan untuk menyempurnakan model bahasa besar, dan merupakan implementasi wajah qlora yang memeluk, yang merupakan kombinasi dari tiga strategi efisiensi yang berbeda: kuantisasi, peringkat rendah, dan adaptor. Kuantisasi adalah gagasan bahwa bilangan bulat byte tunggal memiliki ketepatan numerik yang cukup untuk perhitungan gradien dalam pembelajaran yang mendalam. Peringkat rendah berasal dari konsep aljabar linier bahwa peringkat matriks adalah jumlah dimensi non-redundan dari ruang vektor. Tuning adaptor dapat dipahami sebagai semacam generalisasi penyetelan kepala jaringan, dengan memfitnah sebagian bobot di banyak lapisan.
Mari kita lihat metode forward :
Sebagai pelatihan jaringan saraf melibatkan pergantian antara backprop dan umpan ke depan, ini menentukan bagian depan, dan hal yang terkenal adalah bahwa argumen forward adalah: input_ids , attention_mask , dan label . Ini adalah output dari tokenizer wajah yang memeluk, dan mereka memungkinkan kita untuk mengikat bersama memeluk wajah dan petir pytorch.
Selanjutnya, mari kita lihat metode _compute_metrics :
Ada beberapa hal yang perlu diperhatikan di sini. Pertama, amati bagaimana login dibongkar dari evaluasi fungsi maju dan kemudian dikonversi menjadi probabilitas melalui fungsi softmax. Ini, pada gilirannya, mengarah ke prediksi biner. Kami menggunakan prediksi dan aktual ( batch["label"] ) untuk menghitung akurasi, F1, presisi, dan penarikan kembali.
Akhirnya, mari kita bicara tentang training_step , validation_step , dan test_step .
Mereka terlihat hampir sama, dengan perbedaan penting adalah training_step mengembalikan outputs["loss"] bukan metrics . Ini masuk akal karena backprop secara iteratif meminimalkan kehilangan; training_step hanyalah abstraksi Pytorch Lightning dari loop pelatihan.
Oke, sekarang kita sudah selesai dengan architectures , mari selami config/train_config.py, yang terlihat seperti Gambar 7 di bawah ini.
Kode ini cukup jelas, tetapi ada beberapa pilihan untuk dihubungi. pretrained_model diatur ke roberta-base , dan jika kami mengubahnya menjadi nama model wajah pemeluk yang mendukung AutoTokenizer, semuanya harus tetap berfungsi (diuji). Akurasi model ditemukan paling sensitif terhadap max_length dan batch_size , jadi ini adalah hiperparameter utama untuk dimainkan, dan keduanya menukar antara akurasi dan beban komputasi. Pada Azure ML, saya menggunakan instance Standard_NC24ADS_A100_V4. VRAM pada GPU A100 terbukti menjadi faktor pembatas untuk dua hiperparameter ini. Apa yang saya temukan adalah bahwa 256 adalah batch_size terbesar yang tidak akan menyebabkan Cuda melakukan kesalahan di luar memori.
Menentukan max_length 128 lebih mudah karena sebagian besar klausa berada di bawah batas token ini.
Akhirnya, seperti yang akan kita lihat nanti, max_epochs dari 10 dipilih berdasarkan coba -coba karena metrik F1 validasi yang kami lacak di MLFLOW meratakan pada saat itu.
Oke, mari kita bicara tentang data. Semua yang perlu Anda ketahui ada di kelas LexGlueDataModule di data/lex_glue.py, dan ini adalah strukturnya:
Ada beberapa detail seluk-beluk di LexGlueDataModule , tetapi ide utamanya adalah bahwa metode setup mengambil data langsung dari memeluk wajah, dan kemudian semacam tokenisasi harus terjadi. Rincian tokenisasi itu ada dalam metode _shared_transform , yang hanya antarmuka tingkat tinggi untuk metode panggilan balik _preprocess .
Akhirnya, kami siap untuk train.py, titik kontrol pusat untuk semuanya. Ingat ketika kita memulai bagian ini dengan struktur direktori proyek? Struktur itu mengkomunikasikan pesan penting: bahwa dependensi diselesaikan ke bawah di pohon direktori. Dengan kata lain, kami membatasi kode untuk hanya memanggil kode lain yang berada pada level yang sama atau lebih rendah. Pembatasan ini tentu saja tidak berasal dari Python; itu dipaksakan sendiri, dan mengapa? Untuk menghilangkan dugaan. Tidak ada pertanyaan bahwa rantai ketergantungan yang membingungkan adalah masalah utama dalam basis kode besar. Apa artinya semua ini adalah bahwa train.py akan mengimpor fungsionalitas dari masing -masing modul lain dan kemudian menggerakkan pelatihan. Mari kita lihat potongan kode di jantungnya:
Kami instantiasi kelas Pytorch Lightning Trainer, menyalakan berhenti lebih awal, dan mengatur presisi berdasarkan mesin yang kami ikuti melalui precision="bf16-mixed" if torch. cuda.is_available() else "32-true" . Kami mengkonfigurasi MLFLOW untuk melacak semuanya. Untuk menyatukan semuanya, kami mengimpor fungsi dari tiga modul lain yang telah kami jelaskan sebelumnya:
from architectures . fine_tune_clsify_head import TransformerModule
from config import TrainConfig
from data import LexGlueDataModuleFungsionalitas inti dibungkus dalam subclass kami di Pytorch Lightning Superclasses, jadi kami instantiate mereka:
model = TransformerModule (
pretrained_model = config . pretrained_model , num_classes = config . num_classes ,
lr = config . lr , )
datamodule = LexGlueDataModule (
pretrained_model = config . pretrained_model , max_length = config . max_length ,
batch_size = config . batch_size , num_workers = config . num_workers ,
debug_mode_sample = config . debug_mode_sample , ) Dan akhirnya, kami memohon metode fit dan test objek trainer :
trainer . fit ( model = model , datamodule = datamodule )
best_model_path = checkpoint_callback . best_model_path
# Evaluate the last and the best models on the test sample.
trainer . test ( model = model , datamodule = datamodule )
trainer . test (
model = model , datamodule = datamodule , ckpt_path = best_model_path , ) Kami telah menelepon test dua kali sehingga kami menguji model terakhir pada waktu berhenti dan model terbaik sesuai dengan metrik kami. Ini adalah contoh sempurna dari fungsionalitas kaya yang disertai dengan Pytorch Lightning.
Dan itu membungkus walkthrough kode. Sekarang mari selami hasil model.
Inilah dasbor yang menyatukan semuanya:
Mengambil keuntungan dari integrasi yang ketat antara Azure dan MLFLOW, metrik dari pelatihan kami telah tersedia untuk konsumsi dan visualisasi yang mudah di konsol web Azure ML. MLFLOW menangkap lebih dari sekadar metrik, tetapi masuk lebih dalam ke fungsionalitas penuh dan kasus penggunaan MLOP yang lebih luas adalah untuk hari lain. Untuk saat ini, mari kita fokus pada cerita yang diungkapkan visualisasi data kita kepada kita.
Satu hal yang muncul dari grafik kiri atas adalah bahwa pelatihan tidak diragukan lagi meningkatkan kerugian pada sampel validasi. Selain itu, antara 125 dan 190 langkah, kurva mulai rata, indikasi potensial bahwa pelatihan lebih lanjut bisa tidak perlu. Tetapi menjadi monotonik, kita melihat bahwa overfitting belum terjadi, dan terlebih lagi, kurva menanjak lagi dari 190 menjadi 210, jadi mungkin kita harus membiarkannya berjalan untuk 5 zaman lagi.
Plot kanan teratas, yang menarik, menceritakan kisah serupa. Karakteristik yang paling menonjol adalah seberapa tinggi nilai akurasi, dan unit di sini adalah persentase. Bahwa garis mencapai 90% dari awal masuk akal karena dataset tidak seimbang pada rasio 1: 9 antara tidak adil dan adil. Persis mengapa metrik yang disukai adalah F1, yang kami tampilkan di grafik kiri bawah.
Kurva F1 di sini menunjukkan pola klasik di mana model meningkat dengan cepat pada awalnya tetapi akhirnya mencapai titik pengembalian yang semakin berkurang. Pertanyaan menarik yang diprovokasi oleh kurva F1 adalah bagaimana kita mendamaikan antara kehilangan dan F1, ketika seseorang menyarankan meruncing sementara yang lain meninggalkan ruang untuk melangkah lebih jauh? Sedikit teori berikut akan memecahkan teka -teki ini.
Kami mengamati dunia dalam bentuk peristiwa diskrit, tetapi konstruksi berkelanjutan (misalnya probabilitas) seringkali lebih berguna dalam matematika. Hasil dalam dataset yang tidak adil dikodekan "adil" atau "tidak adil", dan ada distribusi probabilitas laten yang menghasilkan hasil tersebut. Distribusi probabilitas laten adalah apa yang dapat dikerjakan oleh fungsi kehilangan entri-entropi. Jadi dalam pembelajaran mendalam, kami mengoptimalkan untuk metrik berkelanjutan tetapi kami menilai seberapa baik model kami dengan metrik diskrit, karena kontinu (laten) dan diskrit (diamati) adalah perkiraan satu sama lain. Itulah idenya.
Jadi ketika F1 mengisyaratkan cerita yang berbeda dari kehilangan, hanya ada dua penjelasan yang mungkin: keacakan dan ketidakseimbangan kelas. Memang, itulah sebabnya akurasi dan F1 jauh lebih fluktuatif daripada kerugian.
Keacakan juga tampaknya menjadi penjelasan yang mungkin untuk kesenjangan antara skor F1 validasi terbaik 70% dan skor tes F1 78% (dari tabel kanan bawah).
Metrik evaluasi bermain model ini dengan Metrics Model mengakhiri bagian ini. Selanjutnya, dapatkan langsung dengan membuat proyek ini milik Anda sendiri. Panduan instalasi di bawah ini akan membantu Anda memulai bermain -main dengan kode.
Langkah 1. Kloning repositori ini ke direktori kerja lokal:
$ git clone https://github.com/zjohn77/lightning-mlflow-hf.git
$ cd lightning-mlflow-hf Langkah 2. Semua dependensi proyek ada di environment.yml , dan Anda akan menciptakan lingkungan virtual untuk itu. Instruksi di bawah ini untuk conda , tetapi tidak ada dalam dependensi ini yang menghalangi venv atau poetry .
$ conda env create -n lightning-mlflow-hf -f environment.yml Langkah 3. Di akhir pelatihan, fungsi copy_dir_to_abs akan menyalin output ke Azure Blob Storage. Jika Azure juga apa yang Anda gunakan, cukup berikan kredensial ke fungsi ini dan Anda siap. Jika tidak, ganti dengan alur kerja Anda sendiri.
Langkah 4. Di lingkungan virtual Anda, Anda akan mengubah atau mengarahkan IDE Anda ke tempat train.py berada dan menjalankan:
$ python train.pyJika tidak ada bug, itu akan mencetak untuk menghibur beberapa pesan wajah memeluk dan banyak pesan petir Pytorch. Setelah beberapa menit, itu harus mulai mencetak bilah kemajuan. Duduklah dengan ketat dan biarkan itu melakukan pekerjaannya. Ketika menjalankan akhirnya selesai, tabel ASCII yang merangkum metrik evaluasi untuk model akhir akan dicetak ke konsol. Hanya itu yang ada di sana!
Kontribusi apa pun diterima. Kami menggunakan permintaan tarik gitub untuk tinjauan kode, dan kami menggunakan formatter hitam untuk memastikan konsistensi gaya kode.
Tes unit dan tes DOC juga sangat disambut.
Peta jalan sedang dalam proses. Periksa kembali segera.
Ilias Chalkidis, Abhik Jana, Dirk Hartung, Michael Bommarito, Ion Andreutsopoulos, Daniel Martin Katz, Nikolaos Aletras. (2021). LEXGLUE: Dataset tolok ukur untuk pemahaman bahasa hukum dalam bahasa Inggris . Diperoleh dari arxiv: https://arxiv.org/abs/2110.00976
