Feature Store: Cara Tim Engineering Indonesia Bawa Model ML ke Produksi Tanpa Drift

TL;DR: Feature store adalah lapisan data terpusat yang menyajikan fitur ML konsisten antara saat training dan serving. Tanpa ini, tim sering rilis model yang akurasinya turun di produksi karena fitur dihitung beda di notebook vs API. Untuk tim Indonesia yang baru bawa model rekomendasi atau scoring ke produksi, feature store memutus drift dan mempercepat eksperimen tanpa harus duplikasi pipeline.

Saat membantu sebuah marketplace di Indonesia menerapkan model lead scoring, kami menemukan masalah klasik: angka conversion probability di notebook 0,82, tapi di endpoint produksi hanya 0,61 untuk pengguna yang sama. Penyebabnya bukan model rusak. Penyebabnya: feature "30-day spend" dihitung dari Snowflake saat training, tapi dari Redis cache yang lag 8 jam saat serving.

Bug seperti ini wajar terjadi di tim yang scale ML lebih cepat daripada infrastrukturnya. Solusinya bukan training ulang, tapi memperkenalkan feature store sebagai single source of truth.

Masalah Sebenarnya: Training-Serving Skew

Skew muncul saat fitur yang sama dihitung dengan logika atau sumber berbeda di dua jalur (training pipeline vs inference API). Hasilnya: model yang valid secara statistik gagal di produksi. Riset Uber Engineering pada 2024 menyebut training-serving skew sebagai akar masalah nomor satu di kegagalan deployment ML.

Untuk produk dengan reasoning model atau klasifikasi real-time, skew membuat metrik bisnis ikut bias. Marketing yang mengandalkan score ini untuk targeting akan salah alokasi budget tanpa sadar.

Anatomi Feature Store

Fitur didefinisikan sekali di registry, lalu dipanggil dengan satu API entah saat training atau saat inference. Konsistensi otomatis terjaga karena hanya ada satu definisi yang dieksekusi di kedua jalur.

Studi Kasus Implementasi

Untuk marketplace tadi, kami memakai Feast (open source) di atas BigQuery + Redis. Empat fitur utama (30-day spend, last-7-day session count, primary device, days since signup) dipindah ke registry. Hasil setelah dua sprint:

• Akurasi produksi naik dari 0,61 ke 0,79 (gap dengan training tinggal 3 poin)
• Time-to-experiment turun dari rata-rata 5 hari ke 1 hari karena tim data tidak menulis ulang SQL pipeline
• Insiden "model output aneh" turun dari 4-6 per bulan ke 0-1

Lihat juga praktik LLM grounding untuk konteks bagaimana data konsisten juga jadi fondasi fitur AI generatif. Untuk evaluasi model yang masuk ke feature store, model evaluation dan agent evaluation tetap wajib dijalankan terpisah sebelum pipeline materialization aktif.

Build vs Buy untuk Tim Indonesia

Tidak semua tim butuh Tecton atau Hopsworks dari hari pertama. Heuristik praktis:

• 0-3 model di produksi: cukup BigQuery + Redis manual + tabel definisi fitur internal di Notion
• 3-10 model: pertimbangkan Feast (open source, gratis lisensi, butuh effort ops)
• 10+ model atau tim ML 10+ orang: managed service (Tecton, Vertex AI Feature Store) sering lebih murah daripada salary engineer ops

Untuk konteks praktis, lihat juga composable architecture sebagai pola umum agar feature store tidak terkunci pada satu vendor.

Pertanyaan Umum

Apakah feature store hanya untuk model ML klasik?

Tidak. Konsep yang sama berlaku untuk embedding dan retrieval di sistem RAG. Embeddings dianggap fitur juga, jadi banyak tim mulai menyimpan vector di feature store yang sama.

Apa beda feature store dengan data warehouse biasa?

Data warehouse fokus analitik historis, latency tinggi tidak masalah. Feature store wajib serve fitur real-time (millisecond), sambil tetap menyimpan historis untuk training. Dua kebutuhan ini biasanya dipisah jadi offline + online store.

Berapa lama implementasi feature store?

Untuk tim 3-5 engineer dengan stack standar, MVP Feast biasanya 4-8 minggu. Adopsi penuh (semua model migrasi ke registry) sering butuh 2-3 kuartal.

Apakah Supabase atau Postgres bisa jadi online store?

Bisa untuk traffic rendah hingga menengah. Untuk traffic tinggi atau latency budget di bawah 50 ms, Redis atau DynamoDB lebih aman. Lihat panduan latency budget untuk konteks angka.

Penutup

Feature store bukan sekadar trend infra ML. Ia adalah jawaban arsitektural untuk masalah bisnis nyata: model yang disetujui di review tapi gagal di produksi. Bagi tim engineering Indonesia yang sedang scale dari 1 model ke banyak model, investasi ini biasanya bayar balik di kuartal pertama lewat penurunan insiden dan kecepatan eksperimen. Mulai dari yang kecil (registry sederhana di repo), lalu tumbuhkan saat jumlah model bertambah. Referensi resmi: Feast documentation dan Google ML Ops guide.