Kebutuhan Data Machine Learning

Sepanjang course ini kita membangun pipeline yang menyajikan data untuk manusia: dashboard, laporan, dan hasil query untuk analis. Machine learning memakai data dari tabel yang sama, tetapi dengan kontrak yang jauh lebih ketat, karena model mempelajari pola dari data masa lalu lalu menerapkan pola tersebut pada data baru setiap saat. Kesalahan kecil yang mudah terlihat mata pada dashboard — satu kolom yang terisi belakangan, satu pembulatan yang berbeda — dapat membuat model tampak pintar saat latihan lalu gagal senyap di produksi. Section ini membahas sisi data engineering dari machine learning, dan chapter pembuka ini memetakan kebutuhan tersebut lewat satu contoh kegagalan yang paling sering terjadi: data leakage.

Perbedaan Kontrak Data Analytics dan Machine Learning #

Chapter Serving Data untuk Analytics menutup section sebelumnya dengan prinsip bahwa tabel analitik dirancang mengikuti cara konsumennya membaca. Prinsip yang sama berlaku di sini, hanya konsumennya berganti: pembaca dashboard adalah manusia yang bisa curiga melihat angka aneh, sedangkan pembaca data model adalah algoritma yang menelan apa pun yang diberikan tanpa komplain.

Perbedaan paling mendasar ada di baris terakhir. Analytics bekerja dengan tabel dan query; machine learning bekerja dengan tiga artefak baru: dataset training (baris fitur plus label dari masa lalu), fitur serving (nilai yang sama, dihitung ulang untuk satu baris pada saat itu), dan model yang merekam hubungan keduanya. Tiga artefak inilah yang memunculkan seluruh pekerjaan baru di section ini, dan masing-masing menuntut jaminan yang tidak diminta dashboard manapun.

Kontrak Waktu dan Data Leakage #

Model fraud detection memutuskan dalam hitungan detik apakah sebuah transaksi dicurigai. Saat keputusan dibuat, satu-satunya data yang sah dipakai adalah data yang sudah ada sebelum transaksi tersebut — bukan data yang baru terbentuk sesudahnya, seberapa pun prediktifnya. Fitur yang melanggar kontrak waktu ini disebut bocor (leakage), dan inilah penyakit data paling khas machine learning: model yang dilatih dengan fitur bocor menghasilkan metrik latihan yang nyaris sempurna, lalu runtuh begitu dipakai di dunia nyata. Dashboard hampir kebal terhadap penyakit ini karena angka yang dihitung tetap benar; hanya model yang menelan kebohongannya.

Studi Kasus: Fitur Pembatalan yang Bocor #

TokoKita membangun model deteksi fraud dari 20 transaksi awal Oktober 2026. Tim riset menemukan bahwa hampir semua transaksi fraud berujung pembatalan dana, sehingga kolom ada_pembatalan tampak seperti fitur sempurna. Skrip berikut memotong bagian pembuatan tabel transaksi dan pembatalan (20 baris transaksi plus 6 baris pembatalan pada berkas scratch) dan langsung menyoroti masalahnya:

label = transaksi["is_fraud"]

# --- Fitur bocor: "transaksi ini dibatalkan" (baru diketahui setelahnya) ---------
fitur_bocor = transaksi["tx_id"].isin(pembatalan["tx_id"]).astype(int)
prediksi_bocor = fitur_bocor  # model aturan: fraud bila ada pembatalan

print("== Fitur bocor 'ada_pembatalan' pada data training ==")
contoh = transaksi[transaksi["tx_id"].isin([2, 9])].merge(pembatalan, on="tx_id")
for _, r in contoh.iterrows():
    selisih = pd.Timestamp(r.waktu_pembatalan) - pd.Timestamp(r.waktu)
    print(f"  tx {r.tx_id} ({r.waktu}) -> dibatalkan {r.waktu_pembatalan}, "
          f"yaitu {selisih.days} hari setelah transaksi")
akurasi_train = (prediksi_bocor == label).mean()
recall_train = (prediksi_bocor[label == 1] == 1).mean()
print(f"  akurasi training: {akurasi_train:.2f}, recall fraud: {recall_train:.2f}")

Mari kita telaah baris-baris kode di atas:

1. Baris 4 (fitur_bocor = ...): method isin menandai transaksi yang tx_id-nya muncul di tabel pembatalan — tabel yang baru terisi satu sampai dua hari setelah transaksi berjalan.
2. Baris 5 (prediksi_bocor = fitur_bocor): sebagai pengganti model, kita memakai model aturan sederhana: transaksi diprediksi fraud bila pembatalannya ada.
3. Baris 7-13 (contoh = ...): loop menampilkan dua contoh transaksi beserta jarak waktunya, membuktikan bahwa informasi pembatalan lahir setelah momen prediksi.
4. Baris 14-15: akurasi dan recall diukur pada data latih yang sama.

Output yang Dihasilkan:

== Fitur bocor 'ada_pembatalan' pada data training ==
  tx 2 (2026-10-01 02:14) -> dibatalkan 2026-10-03 10:00, yaitu 2 hari setelah transaksi
  tx 9 (2026-10-03 01:05) -> dibatalkan 2026-10-05 11:15, yaitu 2 hari setelah transaksi
  akurasi training: 1.00, recall fraud: 1.00

Akurasi 1.00 dan recall 1.00 — metrik yang mustahil dicapai fitur jujur. Sekarang kita bawa fitur yang sama ke saat serving, lalu bandingkan dengan fitur sederhana yang memang tersedia sejak transaksi tiba:

# --- Simulasi serving: transaksi tiba -> skor DIBUTUHKAN saat itu juga ----------
# Pembatalan belum ada di tabel, jadi fitur 'ada_pembatalan' selalu bernilai 0.
fitur_serving = pd.Series(0, index=transaksi.index)
prediksi_serving = fitur_serving
akurasi_serving = (prediksi_serving == label).mean()
recall_serving = (prediksi_serving[label == 1] == 1).mean()
print()
print("== Fitur yang sama saat serving (pembatalan belum terjadi) ==")
print(f"  akurasi serving: {akurasi_serving:.2f}, recall fraud: {recall_serving:.2f}")

# --- Fitur jujur: nilai transaksi, tersedia pada detik transaksi tiba -----------
prediksi_jujur = (transaksi["nilai"] >= 2_000_000).astype(int)
akurasi_jujur = (prediksi_jujur == label).mean()
recall_jujur = (prediksi_jujur[label == 1] == 1).mean()
print()
print("== Fitur jujur 'nilai >= 2.000.000' ==")
print(f"  akurasi training: {akurasi_jujur:.2f}, recall fraud: {recall_jujur:.2f}")
print(f"  akurasi serving : {akurasi_jujur:.2f} (nilai tersedia saat transaksi tiba)")

Output yang Dihasilkan:

== Fitur yang sama saat serving (pembatalan belum terjadi) ==
  akurasi serving: 0.70, recall fraud: 0.00

== Fitur jujur 'nilai >= 2.000.000' ==
  akurasi training: 0.80, recall fraud: 0.67
  akurasi serving : 0.80 (nilai tersedia saat transaksi tiba)

Hasilnya berbalik arah. Fitur bocor yang “sempurna” di training menghasilkan recall 0.00 saat serving karena tabel pembatalan masih kosong ketika skor dibutuhkan — model menolak semua transaksi justru pada momen tugasnya diuji.

Fitur jujur nilai >= 2.000.000 tampak lebih rendah di kertas, tetapi angka 0.80 tersebut jujur: nilainya sama di training maupun serving, dan 0.80 itulah yang akan kita terima di produksi. Perbandingan ini juga menunjukkan cara menguji setiap fitur baru: jalankan di data training, lalu jalankan ulang dengan asumsi tabel masa depan kosong. Rujukan API untuk pola penandaan isin dan Series di atas tersedia di dokumentasi pandas .

Peta Pekerjaan Data Engineering untuk ML #

Satu studi kasus di atas sudah memunculkan seluruh agenda section ini. Urutan pengerjaannya mengikuti alur kerja nyata: dari cara menyusun dataset, ke perhitungan dan penyimpanan fitur, lalu ke pengamanan kualitas, dan ditutup operasionalnya di produksi. Setiap kebutuhan berikut menjadi satu chapter:

• Dataset yang jujur terhadap arah waktu dan pembagian yang meniru produksi — Dataset Training dan Inference
• Perhitungan fitur sebagai kode yang terdokumentasi — Feature Pipeline
• Satu tempat penyimpanan fitur untuk training dan serving — Feature Store
• Jaminan nilai fitur identik di kedua jalur — Feature Consistency
• Dataset yang bisa dipulihkan persis untuk setiap eksperimen — Data Versioning
• Pemeriksaan skema, drift, dan kebocoran label — Data Validation untuk ML
• Dua cara menghitung fitur: terjadwal dan real-time — Batch Feature Computation serta Streaming Feature Computation
• Menutup lingkaran: data sebagai pemicu retraining model — Integrasi dengan MLOps

Kita mulai dari fondasinya: bagaimana dataset untuk melatih model disusun agar hasil pengukurannya bisa dipercaya. Pembahasan tersebut menanti di chapter Dataset Training dan Inference, yang membuktikan bahwa cara memotong dataset bisa mengubah metrik evaluasi hingga dua kali lipat.