Saat Fitur “Keren” Justru Bikin Modelmu Makin Buruk

Saat Fitur “Keren” Justru Bikin Modelmu Makin Buruk

Kamu tahu nggak sih rasanya? Kamu habis berhari-hari bikin fitur baru yang keliatan canggih banget. Fiturnya nangkep sinyal yang persis kamu mau. Kamu train, evaluasi, dan F1 Class 2 naik dari 0.72 ke 0.78. Kamu senyum-senyum sendiri. Eh, begitu submit ke leaderboard, skor malah turun. Ada apa? Selamat, kamu baru aja bertemu dengan yang namanya *feature engineering trade-off*.

Ini jebakan yang hampir semua data scientist pernah alami, minimal sekali. Gue sendiri ngalamin beberapa bulan lalu, dan gue habis seminggu buat debugging. Jadi, gue bakal jelasin apa yang sebenarnya terjadi di balik layar, kenapa fitur manual yang keliatan cerdas bisa berbalik arah, dan gimana caranya bikin workflow evaluasi fitur yang nggak ngecoh kamu.

Jebakan Klasik: Kemenangan Satu Metrik adalah Kekalahan Metrik Lain

Gue kasih gambaran persisnya. Gue lagi bikin model klasifikasi multi-kelas untuk klien. Baseline-nya oke. Terus gue tambah dua fitur yang gue buat manual: **Impact Severity** dan **Energy Ratio**. Dua-duanya turunan dari data sensor mentah, dirancang buat nangkep kelas fault yang jarang muncul. Secara fisika masuk akal. Di validasi, F1 Class 2 naik dari 0.72 ke 0.78. Bagus, kan?

Nggak semudah itu. Pas gue lihat gambaran penuh, F1 Class 0 dan Class 1 sama-sama turun. Leaderboard—yang pakai rata-rata tertimbang di semua kelas—jadinya lebih rendah daripada baseline. Modelnya secara efektif belajar buat ngorbanin kelas mayoritas biar kelas minoritas keliatan bagus.

Ini bukan nasib buruk. Ini realitas matematis dari *probability budget* yang dipakai bareng-bareng. Di kebanyakan model multi-kelas, kalau confidence satu kelas naik, kelas lain turun. Kalau fitur barumu berkorelasi tinggi dengan fitur yang sudah ada, kamu sebenarnya nggak nambah informasi—kamu cuma ngeramein noise dan bikin miring.

Kenapa Fitur Manual Justru Bikin Model Ambyar?

Multikolinearitas Itu Pembunuh Senyap

Saat fitur barumu berkorelasi dengan dua atau tiga fitur yang sudah ada, modelnya bagi-bagi kredit di antara mereka. Di model berbasis tree, ini bisa nyembunyiin split yang penting. Di model linear, ini bikin koefisien membengkak. Hasilnya? Prediksi jadi kurang stabil, apalagi di data yang belum pernah dilihat.

Yang paling parah, multikolinearitas nggak selalu bikin training accuracy turun. Justru bisa bantu model ngafalin noise. Tapi begitu distribusi test-nya berubah dikit aja, fitur kerenmu itu jadi beban.

Precision/Recall Trade-Off

Kalau kamu bikin fitur buat nemuin Class 2, kemungkinan besar kamu nambah recall Class 2 tapi ngancurin precision Class 1. Anggap aja threshold-nya geser. Makin banyak contoh yang diklasifikasin jadi Class 2, padahal banyak yang sebenarnya Class 1 atau Class 0. Macro score-mu turun meskipun “kelas target” kamu keliatan lebih oke.

Gue sering lihat ini di dunia fraud detection. Ada orang bikin fitur yang bisa nangkep lebih banyak fraud, tapi juga nge-flag banyak transaksi valid. Recall fraud-nya naik, tapi false positive rate-nya double. Di dunia nyata, artinya pelanggan marah-marah dan tim support stres.

Metrik Leaderboard Biasanya Agregat

Kebanyakan leaderboard pakai satu angka: accuracy, macro-F1, weighted kappa, atau log loss. Angka tunggal itu nyembunyiin breakdown per kelas. Kalau kamu optimalisasi di satu irisan, kamu nggak optimalisasi buat keseluruhan. Naik lima poin di F1 Class 2 bisa hilang gara-gara turun tiga poin di dua kelas lain, tergantung class weight-nya.

Nah, makanya sekarang hal pertama yang gue lakuin adalah baca metrik kompetisi atau proyek dengan teliti banget. Kalau pakai weighted F1, perbaikan di kelas yang jarang muncul pengaruhnya kecil. Kalau pakai macro-F1, setiap kelas setara, termasuk kelas yang nggak kamu peduliin.

Studi Kasus Pertama: Data Sensor

Gue kasih contoh konkret. Bayangin pabrik dengan sensor yang ngukur temperatur, vibrasi, dan tekanan. Baseline model: 0.85 macro-F1 di tiga kelas fault.

Gue bikin **energy ratio** = amplitudo vibrasi / varian tekanan. Secara fisika masuk akal. Impact berenergi tinggi harusnya nandain fault yang parah. Di training set, F1 Class 2 naik ke 0.81. Tapi di cross-validation, gain-nya nggak bertahan. Kenapa? Energy ratio-nya berkorelasi tinggi sama vibrasi dan tekanan mentah—multikolinearitas lagi. Di data test, noise sensor di tekanan rendah bikin ratio-nya meledak, dan model jadi salah ngeprediksi Class 2.

Solusinya justru counterintuitive: daripada nambahin ratio mentah, gue pakai fitur residual—bagian dari vibrasi yang *tidak* bisa dijelasin oleh tekanan. Sinyal yang orthogonal ini bener-bener nambah informasi baru, dan skor leaderboard naik di semua kelas. Pelajarannya: jangan tanya “fitur gue masuk akal nggak?” Tapi “fitur gue ngasih informasi yang belum dimiliki model gue nggak?”

Contoh Kedua: Prediksi Churn E-Commerce

Gue pernah kerja sama perusahaan subscription box. Tim marketing pengen bikin **customer engagement score** yang gabungin frekuensi login, tiket support, dan mention media sosial. Kedengerannya oke. Tapi skor itu cuma weighted sum dari fitur yang sudah ada. Pas gue tambahin ke model, ranking feature importance acak-acakan, tapi AUC flat. Lebih parah lagi, kalibrasi jadi makin buruk buat user dengan engagement rendah karena skor itu mendominasi loss.

Kita akhirnya ganti skor buatan tangan itu dengan hitungan sederhana: jumlah kategori fitur unik yang dikontak dalam tujuh hari terakhir. Fitur kecil yang korelasinya rendah ini ngasih peningkatan nyata. Pelajarannya berulang: kadang fitur yang paling nggak menarik justru yang terbaik.

Cara Evaluasi Fitur Tanpa Tertipu

1. Bikin Multi-Metric Scorecard

Jangan cuma pantau F1 Class 2. Bikin scorecard yang berisi:

- Macro-F1 dan weighted-F1
- Precision dan recall tiap kelas
- Log loss atau Brier score (buat kalibrasi)
- Catatan apakah metrik per kelas bergerak searah

Ini yang biasanya gue cetak setelah setiap eksperimen:

| Metric | Baseline | New Feature | Verdict |
|---|---|---|---|
| Class 0 F1 | 0.88 | 0.84 | Bad |
| Class 1 F1 | 0.82 | 0.79 | Bad |
| Class 2 F1 | 0.72 | 0.78 | Good |
| Macro-F1 | 0.81 | 0.80 | Bad |

Sekali lihat, ceritanya kebaca. Fitur baru yang mengkilap ini bantu satu kelas tapi nyakitin kelas lainnya. Tanpa scorecard, gue bakal submit model dan dapat kejutan yang nggak enak.

2. Lakukan Korelasi Audit

Sebelum nambah fitur manual, cek korelasinya dengan fitur yang ada. Pakai pandas `df.corr()` dan lihat nilai absolut di atas 0.7. Kalau fitur barumu terlalu dekat sama fitur yang ada, pertimbangkan:

- Buang salah satu fitur yang redundan
- Pakai residualization (regres fitur baru terhadap fitur lama, ambil residual-nya)
- Pakai feature selection dari scikit-learn `SelectKBest` atau `RFECV`

Panduan resmi scikit-learn soal feature selection banyak berisi pendekatan praktis: https://scikit-learn.org/stable/modules/feature_selection.html

3. Pakai SHAP untuk Ngerti Efek Directional

Setelah training, hitung SHAP values buat lihat gimana fitur barumu memengaruhi tiap kelas. Kadang fitur berguna buat Class 2 tapi aktif ngerugiin Class 1. SHAP summary plot bakal langsung nunjukin ini. Library-nya open-source dan terawat di https://github.com/shap/shap.

Gue udah beberapa kali nangkep fitur “keren” yang punya SHAP positif kuat buat satu kelas, tapi nilai negatifnya lebih kuat buat kelas lain. Nah, trade-off kayak gini yang harus kamu lihat sebelum submit.

4. Coba Ablasi

Ablasi itu ngilangin fitur dan liat apa yang terjadi. Jarang banget dilakukan di feature engineering manual. Gue selalu jalanin tiga eksperimen:

- Baseline dengan fitur lama
- Baseline + fitur baru
- Baseline + fitur baru, minus satu fitur lama yang berkorelasi

Kalau eksperimen ketiga lebih bagus dari yang kedua, berarti kamu nyelesaiin masalah multikolinearitas. Kalau yang kedua lebih jelek dari yang pertama, buang fitur itu. Kalau yang kedua lebih bagus tapi evaluasi leaderboard bilang sebaliknya, cek lagi validasi kamu.

Contoh Ketiga: Klasifikasi Triage Medis

Gue pernah kerja di prototipe symptom-checker. Tujuannya buat triase pasien ke tiga tingkat urgensi. Gue bikin **comorbidity score** dengan ngejumlahin kondisi bawaan. Ini ngebaikin deteksi pasien urgensi tinggi, tapi bikin model ngelupain tingkat keparahan gejala saat ini. Pasien dengan satu gejala ringan dan satu komorbiditas diklasifikasin urgensi tinggi, padahal risiko aslinya rendah.

Masalahnya fitur gue terlalu dominan. Model nempel ke fitur itu karena gampang di-split, dan ngabaikan fitur teks yang lebih kaya dan nuanced. Ini trade-off penting lainnya: **feature dominance**. Fitur handcrafted yang kuat bisa nyingkirin fitur lain yang lebih lemah tapi lebih informatif. Regularisasi dan interaksi fitur bisa bantu, tapi biasanya yang sederhana justru lebih baik.

Pelajaran Besar: Fitur Itu Nggak Gratis

Setiap fitur yang kamu tambah nambah kompleksitas model, waktu training, dan peluang overfitting. Regularisasi bisa bantu, tapi nggak bisa nyelesaiin fitur yang fundamental redundan. Kamu harus anggap setiap fitur itu taruhan: fitur harus nyumbang sinyal baru yang stabil di banyak metrik.

Gue juga belajar bahwa kalau leaderboard turun setelah nambah fitur, akar masalahnya hampir nggak pernah “metriknya salah.” Justru karena gue lagi ngejar optimum lokal. Model nggak bodoh—dia ngelakuin persis apa yang gue minta. Masalahnya gue minta hal yang salah.

FAQ

Kenapa F1 naik di satu kelas tapi skor leaderboard total turun?

Karena leaderboard biasanya pakai rata-rata tertimbang atau macro. Model kamu mungkin ngorbanin precision/recall di kelas lain demi naik di kelas yang kamu fokusin. Selalu evaluasi confusion matrix lengkap sebelum senang dulu.

Apa cara terbaik buat nanganin fitur multikolinear?

Cek korelasi dulu. Kalau dua fitur berkorelasi tinggi, buang salah satu atau pakai versi residual dari fitur baru. Regularisasi seperti L1 atau L2 bisa bantu stabilkan model, tapi ngilangin redundansi biasanya lebih efektif daripada muter-muter nambahi penalty.

Apakah feature engineering manual masih berguna di machine learning modern?

Iya, tapi cuma kalau fitur itu meng-encode domain knowledge yang belum ada di model. Kalau fitur cuma kombinasi matematis dari fitur yang sudah ada, biasanya nggak ngebantu. Kalau fitur itu nangkep sinyal yang bener-bener baru, bisa powerful. Kuncinya memverifikasi bahwa fitur itu bener-bener nambah informasi independen.

Gimana cara tahu apakah fitur bener-bener ngebantu?

Bandingin model baseline dan model dengan fitur menggunakan banyak metrik dan cross-validation. Lakuin ablasi. Liat feature importance dan SHAP values. Kalau peningkatannya nggak konsisten antar fold atau metrik, kemungkinan besar itu overfitting noise.

Penutup

Gue ngerti banget serunya bikin fitur yang sempurna. Rasanya kayak nge-crack kode. Tapi leaderboard adalah wasit terakhir. Makin cepet kamu bangun evaluasi multi-metrik di workflow-mu, makin sedikit waktu yang kebuang buat fitur yang cuma ngebantu satu irisan masalah.

Lain kali kalau kamu mau submit fitur “impact severity” yang canggih itu, berhenti. Tanya ke diri sendiri: “Ini nambah informasi baru, atau cuma ngeramein sinyal yang udah gue punya?” Diri kamu di masa depan—dan ranking leaderboard-mu—bakal berterima kasih.