Structuring Machine Learning Projects
Introduction to ML Strategy
Ketika kita membangun model untuk project ML, katakanlah model yang kita bangun sudah mencapai akurasi 90% namun hal tersebut belum cukup baik maka dibutuhkan pengembangan lainnya seperti:
- Mengumpulkan data yang lebih banyak
- Data latih yang lebih beragam / diverse
- Melatih algoritma lebih lama dengan gradient descent
- Mencoba Adam untuk menggantikan gradient descent
- Menggunakan network yang lebih besar atau lebih kecil
- Menggunakan dropout layer
- Menambahkan $L_{2}$ regularization
- Mengubah arsitektur jaringan, seperti:
- Fungsi aktivasi
- Jumlah hidden units
- dan lainnya
Masalahnya, kita tidak bisa mencoba semua kemungkinan diatas karena ada pertimbangan waktu. Oleh karena itu kita harus menyusun strategi dalam membangun model machine learning.
Orthogonalization
Orthogonalization adalah proses mencari parameter apa yang perlu di-tune dan bagaimanakah efeknya.
Chain of assumptions in ML
- Fit training set well on cost function
- Fit dev set well on cost function
- Fit test set well on cost function
- Performs well in real world
Setting up your goal
Single number evaluation metric
Penggunaan evaluation metric tunggal mempermudah dalam mengukur performa dalam mengambil keputusan pengembangan model.
Satisficing and optimizing metrics
Kadang kita memiliki dua atau lebih metrics. Untuk bekompromi dengan hal tersebut, kita dapat menentukan satu metric untuk dioptimasi (optimizing metric) sedang metric lainnya dapat ditentukan batas toleransinya (satisficing metric).
Train/dev/test distributions
Pengelompokan data untuk menjadi data latih/validasi/tes menjadi sangat penting karena berrpengaruh pada progress pembuatan model machine learning.
Satu hal yang direkomendasikan adalah menggunakan dataset dev(validasi) dan tes dengan distribusi yang sama.
Choose a dev set and test set to reflect data you expect to get in the future and consider important to do well on.
Size of dev and test sets
Panduan dalam era deeplearning untuk membagi jumlah data latih dan data tes telah banyak berubah. Dulu ada rule of thumb untuk membagi data latih dan tes dengan perbandingan 70:30 atau dengan perbandingan data latih, dev dan tes sebesar 60:20:20. Zaman sekarang bisa digunakan 98% data untuk data latih, 1% untuk dev dan 1% lainnya untuk tes. Hal ini dikarenakan jumlah data yang sangat melimpah.
Pastikan bahwa data tes yang digunakan cukup besar untuk memberikan confidence pada overall performance pada sistem.
When to change dev/test sets and metrics
ποΈ Orthogonalization for cat pictures
If doing well on your metric + dev/test set does not correspond to doing well on your application, change your metric and/or dev/test set.
Comparing to human-level performance
Why human-level performance
- Advances in deep learning machine learning algorithms are suddenly working much better and so it has become much more feasible in a lot of application areas for machine learning algorithms to actually become competitive with human-level performance.
- It turns out that the workflow of designing and building a machine learning system, the workflow is much more efficient when you’re trying to do something that humans can also do.
Selama ML lebih buruk dibandingkan performa manusia, hal yang bisa dilakukan:
- Mendapatkan data berlabel dari manusia
- Mengambil insight dari analisis kesalahan yang dilakukan secara manual
- Analisis yang lebih baik untuk bias/variance
Avoidable bias
ποΈ Cat classification example
Understanding human-level performance
ποΈHuman-level error as a proxy for Bayes error
Error analysis example
Case A
Human Error: 1 - 0.5% Training Error: 5% Dev Error: 6% so, avoidable bias: 4 - 4.5% and variance 1%. Thus focus on reducing bias.
Case B
Human Error: 1 - 0.5% Training Error: 1% Dev Error: 5% so, avoidable bias: 0 - 0.5% and variance 4%. Thus focus on reducing variance.
Surpassing human-level performance
Improving your model performance
The two fundamental assumptions of supervised learning
- You can fit the training set pretty well -> Avoidable bias
- The training set performance generalizes pretty well to dev/test set -> varriance
Reducing (avoidable) bias and variance
-
Avoidable bias
- Train bigger model
- Train longer/better optimization algorithms
- moment, RRRMSprrop, Adam
- NN Architecture/hyperparameters search
-
Variance
-
More data
-
Regularization
- L2, dropout, data augmentation
-
NN Architecture/hyperparameters search
-
Error Analysis
ποΈ Carrying out error analysis
Cleaning up Incorectly labeled data
DL algorithms are quite robust to random errors in the training data.
Correcting incorrect dev/test set example
- Apply same process to your dev and test ets to make sure they continue to come from the same distribution
- Consider examining examples your algorithm got right as well as ones it got wrong
- Train and dev/test data may now come from slightly different distributions
Build your first system quickly, then iterate
Mismatched training and dev/test data
Training and testing on different distributions
Setting up your ML Application
Bias/Variance
High variance: train set error < dev set error
High bias: train set error ~ dev set error
Basic “recipe” for machine learning
High bias? (check training data performance) -> Bigger network, train longer, NN architecture search
High variance? (dev set performance) -> Morde data, regularization, NN architecture search
Normalizing Input
Regularizing your neural network
Regularization
Logistic regression
$L_{2}$ regularization $||w||_{2}^{2}$
ποΈ Neural Network
Frobenius norm