Integrasi dengan MLOps

Model yang naik ke produksi bukan artefak yang selesai, melainkan artefak yang mulai menua. Perilaku pelanggan bergeser, data drift merayap, dan presisi turun sedikit demi sedikit sampai suatu hari model perlu dilatih ulang dari data yang lebih baru. MLOps adalah praktik mengelola siklus tersebut secara berkelanjutan, dan hampir setiap tahapnya menyentuh pekerjaan data engineering: data yang dipantau, dataset yang disiapkan, hingga pipeline yang dipicu ulang. Chapter penutup section ini merangkai seluruh babak sebelumnya menjadi satu lingkaran — lalu menutup perjalanan konseptual course ini.

Siklus Hidup Model dan Posisi Data Engineering #

Siklus hidup model berputar dari serving menuju serving lagi. Data engineering berada di tiga titik putaran tersebut: menghasilkan metrik yang memicu keputusan, menyiapkan data saat keputusan jatuh, dan menjaga agar versi data tetap tertelusuri:

Setiap panah pada diagram memakai perangkat yang sudah kita bangun di section ini. Monitoring membaca hasil PSI dari chapter Data Validation untuk ML; snapshot fitur lahir dari Batch Feature Computation atau Streaming Feature Computation; dataset training ter-pin lewat Data Versioning; dan paritas fitur dijamin Feature Consistency agar model baru tidak dilatih dengan definisi fitur yang berbeda dari yang disajikan.

Memicu Retraining dari Sisi Data #

Kapan model harus dilatih ulang? Jawaban yang matang menggabungkan tiga sinyal, bukan satu. Skrip berikut mengevaluasi riwayat metrik pekanan model fraud TokoKita — drift PSI fitur nilai, presisi model di produksi, dan jumlah pekan sejak training terakhir:

BASELINE_PRESISI = 0.92
AMBANG_DRIFT = 0.25
AMBANG_PERFORMA = 0.05
JADWAL_PEKAN = 8


def putuskan(baris):
    """Satu baris metrik -> keputusan retraining beserta alasannya."""
    alasan = []
    if baris.psi_nilai > AMBANG_DRIFT:
        alasan.append(f"drift PSI {baris.psi_nilai:.2f} > {AMBANG_DRIFT}")
    if BASELINE_PRESISI - baris.presisi > AMBANG_PERFORMA:
        alasan.append(f"presisi turun {BASELINE_PRESISI - baris.presisi:.2f}")
    if baris.pekan_sejak_training >= JADWAL_PEKAN:
        alasan.append(f"jadwal {baris.pekan_sejak_training} pekan")
    if alasan:
        return "LATIH ULANG", " + ".join(alasan)
    return "tahan", "semua metrik dalam batas"

RIWAYAT[["keputusan", "alasan"]] = RIWAYAT.apply(
    putuskan, axis=1, result_type="expand"
)

print("Riwayat metrik dan keputusan retraining model deteksi fraud TokoKita")
print(f"(baseline presisi {BASELINE_PRESISI:.2f}, ambang drift PSI {AMBANG_DRIFT})")
print()
for _, r in RIWAYAT.iterrows():
    print(f"  {r.pekan} | PSI {r.psi_nilai:.2f} | presisi {r.presisi:.2f} "
          f"| {r.pekan_sejak_training} pekan sejak training")
    print(f"      -> {r.keputusan}: {r.alasan}")

perlu = RIWAYAT[RIWAYAT["keputusan"] == "LATIH ULANG"]
print()
print(f"pekan yang memicu retraining: {list(perlu.pekan)}")
print("dari sisi data: siapkan snapshot fitur + label pekan-pekan tersebut, "
      "lalu serahkan ke pipeline training")

Mari kita telaah bagian penting kode di atas:

1. Baris 1-4 (empat konstanta): kebijakan retraining diekspresikan sebagai angka yang bisa ditinjau — baseline presisi saat rilis, ambang drift, ambang penurunan performa, dan jadwal maksimal.
2. Baris 9-15 (if ... alasan.append): tiga sinyal diperiksa berurutan dan alasannya dikumpulkan; keputusan selalu disertai alasan yang terbaca manusia, bukan sekadar ya atau tidak.
3. Baris 18-19 (RIWAYAT.apply ... result_type="expand"): satu fungsi diterapkan ke setiap baris riwayat, dan dua kolom hasil (keputusan, alasan) melebar menjadi kolom tabel.

Output yang Dihasilkan:

Riwayat metrik dan keputusan retraining model deteksi fraud TokoKita
(baseline presisi 0.92, ambang drift PSI 0.25)

  2026-W44 | PSI 0.03 | presisi 0.92 | 1 pekan sejak training
      -> tahan: semua metrik dalam batas
  2026-W45 | PSI 0.05 | presisi 0.91 | 2 pekan sejak training
      -> tahan: semua metrik dalam batas
  2026-W46 | PSI 0.31 | presisi 0.88 | 3 pekan sejak training
      -> LATIH ULANG: drift PSI 0.31 > 0.25
  2026-W47 | PSI 0.42 | presisi 0.79 | 4 pekan sejak training
      -> LATIH ULANG: drift PSI 0.42 > 0.25 + presisi turun 0.13

pekan yang memicu retraining: ['2026-W46', '2026-W47']
dari sisi data: siapkan snapshot fitur + label pekan-pekan tersebut, lalu serahkan ke pipeline training

Pekan W46 memicu retraining dari drift saja meskipun presisi masih 0.88 — sinyal data lebih dulu berteriak sebelum pengguna merasakan penurunan. Pekan berikutnya kedua sinyal menyatu, dan alasan gabungan drift + presisi turun tercatat lengkap untuk audit. Keputusan seperti ini di produksi digantungkan sebagai pipeline terorkestrasi — pola Event-Driven Workflows di atas orchestrator seperti Apache Airflow — sehingga pekan yang berstatus LATIH ULANG otomatis menyiapkan snapshot fitur, menjalankan training, dan menaikkan versi model.

Peran Data Engineer di Tim MLOps #

Batas peran tetap jelas: data engineer menyiapkan data yang benar, tepat waktu, dan tertelusuri; keputusan arsitektur model dan evaluasi algoritma adalah wilayah tim ML. Kedua peran bertemu di dataset emas, manifest, dan kebijakan ambang — persis artefak yang kita bangun sepanjang section ini.

Penutup: Dari Konsep ke Proyek #

Dengan chapter ini, perjalanan konseptual course Data Engineering tuntas. Kita mulai dari memahami apa yang dikerjakan data engineer, membangun fondasi Python dan SQL, mengalirkan data lewat ingestion, mentransformasikannya, menata model dan warehouse, menjaga kualitas, mengorkestrasi pipeline, mengoptimalkan performa dan biaya, hingga menyajikan data untuk analytics — dan section ini menutupnya dengan kebutuhan yang paling menuntut: menyajikan data untuk machine learning yang hidup di produksi. Pola yang sama berulang di setiap babak: data harus jujur terhadap waktu, konsisten antar jalur, tervalidasi sebelum dipakai, dan tertelusuri setelah dipakai.

Materi konseptual cukup sampai di sini; kecakapan datang dari membangun. Section Proyek menyiapkan delapan proyek terpandu yang merangkai seluruh materi menjadi pipeline sungguhan — mulai dari Proyek: Pipeline Data CSV ke PostgreSQL dan Proyek: Pipeline Ingestion API, lanjut ke Proyek: Orkestrasi Pipeline dengan Airflow, hingga Proyek: Streaming Data dengan Kafka. Ambil satu proyek, bangun pelan-pelan, dan biarkan kesalahan kecil di sandbox mengajarkan hal yang tidak bisa diajarkan chapter mana pun.