Belajar MLOps - Feature Store in Production

#Pendahuluan

Setelah di episode 13 pipeline retraining berjalan otomatis, kita bereskan salah satu sumber kesalahan paling licik di dunia ML: training-serving skew. Model dilatih dengan fitur yang dihitung oleh kode tertentu — lalu di produksi, fitur dihitung ulang oleh kode yang "sekiranya sama", sering dengan hasil yang sedikit berbeda.

Mengapa feature store penting? Karena ia membuat logika fitur menjadi satu sumber kebenaran: fitur yang dipakai training adalah fitur yang persis sama dipakai inference. Episode ini membedah arsitektur feature store — offline store, online store, dan point-in-time correctness — dengan Feast sebagai implementasi open source.

#Masalah yang Dipecahkan: Training-Serving Skew

Skew terjadi ketika fitur training dan fitur serving dihitung berbeda. Contoh nyata:

• Training: fitur "rata-rata transaksi 30 hari" dihitung dari seluruh data historis, termasuk transaksi yang sebenarnya belum terjadi saat prediksi dibuat (data leakage).
• Serving: fitur dihitung dari data yang tersedia saat itu juga.

Hasilnya: model terlihat bagus di evaluasi offline, tetapi buruk di produksi. Feature store memecahkan ini dengan menjamin fitur yang sama, dihitung dengan logika yang sama, pada momen yang benar.

#Arsitektur Feature Store

Dua penyimpanan dengan peran berbeda:

Point-in-time correctness adalah detail paling penting: saat mengambil fitur historis untuk training, setiap baris training harus menggunakan nilai fitur yang valid pada saat event tersebut terjadi — bukan nilai yang baru muncul belakangan. Tanpa ini, terjadi leakage: model "melihat" data masa depan saat training.

#Definisi Feature dengan Feast

Feast (Feature Store for ML) adalah implementasi open source yang paling umum. Fitur didefinisikan sebagai feature view — deskripsi logika fitur dan sumber datanya.

from datetime import timedelta
from feast import FeatureView, Field
from feast.types import Float32, Int64
from feast.infra.offline_stores.file_source import FileSource
 
transactions_source = FileSource(
    path="s3://mlops-bucket/features/transactions.parquet",
    timestamp_field="event_timestamp",
)
 
transactions_fv = FeatureView(
    name="transactions_features",
    entities=["customer"],
    schema=[
        Field(name="avg_30d_amount", dtype=Float32),
        Field(name="tx_count_30d", dtype=Int64),
    ],
    source=transactions_source,
    ttl=timedelta(days=30),
)

Fitur ini kemudian tersedia untuk dua tujuan sekaligus:

from feast import FeatureStore
 
store = FeatureStore(repo_path=".")
training_df = store.get_historical_features(
    entity_df=entity_df,
    features=["transactions_features:avg_30d_amount"],
).to_df()

features = store.get_online_features(
    features=["transactions_features:avg_30d_amount"],
    entity_rows=[{"customer": "cust-123"}],
).to_dict()

Perhatikan: kode definisi fitur hanya satu — dipakai untuk offline dan online. Inilah cara feature store menghilangkan skew: logika fitur tidak diduplikasi di dua tempat.

#Feast vs Tecton vs Build Sendiri

Aturan praktis: mulai dengan Feast — ia gratis, aktif dikembangkan, dan cukup untuk sebagian besar kasus. Naik ke Tecton hanya jika kebutuhan transformasi real-time dan skala mulai melebihi kapasitas tim untuk mengoperasikan Feast sendiri. Membangun feature store sendiri sebaiknya menjadi keputusan terakhir, bukan pertama.

#Integrasi dengan Pipeline

Feature store menyatu dengan alur yang sudah kalian bangun:

1. Data engineering (episode 6-7) menyediakan source data ke Feast.
2. Training (episode 7) mengambil offline features → dataset training di-version di DVC.
3. Serving (episode 9) mengambil online features → input inference.
4. Monitoring (episode 12) membandingkan distribusi fitur offline vs online untuk mendeteksi skew.

Karena fitur terdefinisi sekali, setiap model yang mengonsumsi fitur yang sama otomatis konsisten. Inilah kekuatan compounding-nya: satu definisi, banyak model, nol skew.

#Common Pitfalls

• Point-in-time salah → leakage dari data masa depan; selalu ikutkan timestamp event.
• Logika fitur diduplikasi (satu untuk training, satu untuk serving) → skew kembali; satu definisi saja.
• Online store tidak di-update → inference memakai fitur basi; pastikan pipeline streaming/refresh online store.
• TTL tidak sesuai → fitur lama bertahan terlalu lama; atur ttl sesuai semantik bisnis.
• Entity definition tidak konsisten → join gagal; gunakan entity yang sama untuk semua feature view.

#Penutup

Pada episode 14 ini, kalian telah menghilangkan training-serving skew.

Inti yang harus dibawa pulang:

• Skew = fitur training dan serving dihitung berbeda; feature store menyatukannya.
• Offline store untuk training/backfill; online store untuk inference real-time.
• Point-in-time correctness mencegah leakage data masa depan.
• Feast sebagai implementasi open source: satu definisi fitur, dipakai untuk keduanya.
• Feature store relevan saat fitur dibagi antar model atau berubah cepat.

Di episode 15 selanjutnya kita akan membahas model governance & compliance — model cards, audit, explainability dengan SHAP, dan regulasi seperti EU AI Act yang kini mengatur model di produksi. Sampai jumpa di episode 15!