Model machine learning tidak hanya bergantung pada algoritma yang bagus. Kualitas prediksi juga sangat dipengaruhi oleh bagaimana fitur dihitung, disimpan, dan diberikan kepada model.
Masalah muncul ketika logika feature engineering saat training ternyata berbeda dengan proses yang berjalan ketika inference.
Di sinilah Menggunakan Feature Store menjadi relevan. Feature store membantu tim memusatkan definisi fitur, menyediakan data historis untuk training, serta melayani nilai terbaru untuk prediksi.
Dengan arsitektur yang tepat, tim dapat mengurangi training-serving skew sekaligus membuat feature engineering lebih mudah digunakan kembali.
1. Pahami Masalah Training-Serving Skew
Bayangkan model fraud menggunakan fitur transaction_count_24h.
Saat training, data engineer menghitung jumlah transaksi dalam rolling window 24 jam menggunakan SQL. Namun ketika model masuk production, backend menghitungnya menggunakan logic berbeda dan hanya melihat data sejak pukul 00.00.
Nama fiturnya sama, tetapi nilainya tidak sama.
Inilah salah satu bentuk training-serving skew.
AWS menjelaskan bahwa Feature Store dapat membantu menjaga proses pembuatan fitur tetap konsisten dan mengurangi perbedaan antara data yang digunakan saat training dan serving.
Fitur dapat diproses kemudian disimpan untuk kebutuhan training maupun inference melalui mekanisme yang lebih terpusat.
Masalah seperti ini berbahaya karena model bisa terlihat bagus saat evaluasi offline tetapi mengalami penurunan performa begitu masuk production.
Feature store membantu menjadikan definisi fitur sebagai artefak yang dikelola, bukan sekadar potongan query yang tersebar di berbagai service.
2. Jadikan Feature Definition sebagai Source of Truth
Feature sebaiknya tidak hanya memiliki nama.
Definisikan source data, tipe data, entity, transformation logic, timestamp, owner, serta versi jika diperlukan.
Contohnya fitur customer_total_orders_30d perlu menjelaskan bahwa nilainya adalah jumlah pesanan sukses pelanggan selama 30 hari terakhir, tidak termasuk pesanan yang dibatalkan.
Azure Machine Learning Managed Feature Store memungkinkan feature set didefinisikan bersama transformation logic dan versioning.
Microsoft menjelaskan bahwa feature set yang versioned dan immutable membantu model baru menggunakan versi fitur baru tanpa mengganggu model lama.
Ini penting ketika definisi bisnis berubah.
Misalnya tim awalnya mendefinisikan active customer sebagai pengguna yang bertransaksi dalam 90 hari, kemudian mengubahnya menjadi 60 hari.
Jangan diam-diam mengubah logic lama. Buat versi baru sehingga model sebelumnya tetap reproducible.
Dengan begitu, reproduksibilty model tidak hanya berlaku pada file model, tetapi juga feature pipeline yang menghasilkan inputnya.
3. Pisahkan Offline Store dan Online Store
Kebutuhan feature retrieval saat training dan inference biasanya berbeda.
Training dapat membutuhkan ratusan juta baris data historis dan tidak selalu membutuhkan latency rendah. Sebaliknya, real-time prediction mungkin hanya membutuhkan beberapa fitur terbaru untuk satu customer dalam hitungan milidetik.
Karena itu, banyak feature store menggunakan dua lapisan.
AWS SageMaker Feature Store menyediakan offline store untuk data historis yang digunakan pada training dan batch inference, serta online store untuk lookup real-time dengan latency rendah.
Ketika keduanya digunakan bersama pada konfigurasi yang didukung, feature data dapat dijaga tetap sinkron untuk mengurangi perbedaan antara training dan serving.
Contohnya pada fraud detection.
Offline store menyimpan histori fitur transaksi untuk membangun training dataset. Online store menyimpan nilai terbaru seperti jumlah transaksi satu jam terakhir atau rata-rata nominal transaksi pelanggan.
Model memperoleh logika fitur yang sama, tetapi storage dan access pattern disesuaikan dengan workload.
4. Gunakan Event Time, Bukan Hanya Processing Time
Timestamp adalah komponen penting dalam feature store.
Untuk model machine learning, Anda perlu mengetahui bukan hanya kapan data masuk ke pipeline, tetapi kapan sebuah kejadian sebenarnya terjadi.
Misalnya transaksi terjadi pukul 09.00 tetapi baru masuk data warehouse pukul 09.10.
Jika training menggunakan processing time secara sembarangan, model bisa mendapatkan representasi kondisi yang berbeda dibanding keadaan sebenarnya ketika keputusan dibuat.
AWS Feature Store menggunakan event time sebagai bagian dari record feature group. Online store mempertahankan record terbaru berdasarkan event time, sedangkan offline store mempertahankan data historis.
Dengan event timestamp yang jelas, tim dapat membangun dataset historis secara lebih konsisten.
Ini juga menjadi fondasi untuk point-in-time join.
5. Hindari Data Leakage dengan Point-in-Time Join
Salah satu masalah tersulit dalam pembuatan training dataset adalah data leakage.
Bayangkan model churn memprediksi apakah pelanggan akan berhenti pada 1 Juli. Namun training dataset tanpa sengaja memasukkan fitur total_support_tickets yang mencakup tiket hingga 15 Juli.
Model secara tidak sadar melihat masa depan.
Hasil offline evaluation bisa tampak luar biasa, tetapi model tersebut tidak realistis.
Databricks menjelaskan bahwa point-in-time correctness memastikan setiap training record hanya menggunakan feature value yang sudah tersedia pada timestamp label tersebut. Pendekatan ini mencegah informasi masa depan bocor ke training dataset.
Untuk time-dependent features seperti rolling transaction count, inventory level, account balance, atau activity score, kemampuan ini sangat penting.
Feature store seharusnya membantu tim mendapatkan nilai fitur “sebagaimana diketahui saat itu”, bukan nilai terbaru hari ini.
6. Kurangi Duplikasi Feature Engineering
Tanpa feature store, tim sering membuat fitur yang sebenarnya sama berkali-kali.
Tim fraud membuat customer_transaction_30d.
Tim risk membuat transactions_last_30_days.
Tim marketing membuat purchase_count_monthly.
Ketiganya mungkin menghitung konsep serupa menggunakan logic sedikit berbeda.
Hasilnya adalah duplikasi compute, definisi yang tidak konsisten, dan kebingungan ketika model menghasilkan angka berbeda.
Databricks Feature Store berfungsi sebagai registry terpusat untuk feature, dengan kemampuan discovery, reuse, governance, serta lineage ke model yang menggunakannya.
Azure Managed Feature Store juga menekankan kemampuan menemukan dan menggunakan kembali feature yang sudah dikembangkan tim lain.
Dengan catalog yang baik, data scientist dapat mencari fitur yang sudah tersedia sebelum membuat pipeline baru.
Ini mengurangi kerja berulang sekaligus mempercepat eksperimen.
7. Monitor Freshness dan Materialization
Feature yang definisinya benar tetap bisa bermasalah jika nilainya terlambat diperbarui.
Misalnya fitur inventory_available baru diperbarui setiap enam jam, sedangkan model rekomendasi produk berjalan real-time.
Model bisa terus merekomendasikan barang yang sebenarnya sudah habis.
Azure Managed Feature Store menyediakan materialization yang dapat dijadwalkan serta monitoring terhadap pekerjaan materialization. Sistem dapat menghitung feature value untuk window tertentu dan menyimpannya agar siap digunakan saat retrieval.
Tetapkan freshness SLA per fitur.
Fitur demografi mungkin cukup diperbarui sekali sehari. Transaction velocity untuk fraud detection mungkin membutuhkan refresh dalam hitungan menit atau detik.
Jangan menyamakan semua fitur.
Freshnes requirement sebaiknya mengikuti kecepatan perubahan data dan dampaknya terhadap keputusan model.
8. Jangan Jadikan Feature Store sebagai Data Dump
Feature store bukan tempat untuk menyalin semua kolom dari data warehouse.
Simpan feature yang memang mempunyai definisi jelas, owner, consumer, dan alasan penggunaan.
Gunakan metadata seperti deskripsi, source, version, owner, tags, dan entity key agar fitur mudah ditemukan dan dipahami.
AWS Feature Store mendukung metadata pada feature groups serta kemampuan discovery dan sharing bagi pengguna yang memiliki akses.
Semakin besar organisasi, governance ini semakin penting.
Tanpa catalog yang teratur, feature store hanya berubah menjadi warehouse kedua yang sama sulitnya dipahami.
Menggunakan Feature Store membantu menjaga definisi fitur tetap konsisten antara training dan inference, mengurangi duplikasi, serta memperkuat reproducibility model.
Pisahkan kebutuhan online dan offline, gunakan event time dan point-in-time join, lalu pantau freshness setiap fitur. Mulailah dari beberapa feature penting yang digunakan banyak model sebelum memperluas feature store menjadi platform bersama.