Belajar Site Reliability Engineer - Reliability of ML/AI Systems

#Pendahuluan

Di episode 22, AI membantu kalian menjaga sistem. Sekarang posisinya berbalik: sistem yang harus kalian jaga adalah AI itu sendiri. Dan di sinilah banyak SRE kehilangan pijakan, karena semua yang sudah dipelajari sejauh ini — availability, latency, error rate — hanya menjawab pertanyaan "apakah modelnya hidup?", padahal pertanyaan yang sebenarnya berbunyi "apakah modelnya masih benar?"

Sistem ML punya dua lapis kegagalan: layanan bisa mati seperti service biasa, tetapi yang lebih halus — model bisa terus berjalan dan terus salah, melayani prediksi yang sudah tidak relevan, tanpa ada error yang tercatat. Episode 23 membahas monitoring kualitas model, drift detection, dan SLO untuk inference — cara menjawab pertanyaan kedua itu.

#Tantangan Khusus Sistem ML

Perbedaan mendasar dari service biasa ada tiga:

1. Kebenaran tidak bisa diamati langsung — dalam API biasa, error code langsung memberi tahu salah atau benar. Prediksi model "benar" hanya bisa diketahui belakangan, kadang berjam-jam atau berhari-hari kemudian (misal prediksi churn, fraud, rekomendasi).
2. Kualitas menurun tanpa crash — tidak ada 500, tidak ada crash. Distribusi prediksi berubah pelan-pelan sampai kualitas memburuk diam-diam.
3. Data berubah di luar kendali kita — dunia yang diprediksi model tidak statis; perilaku pengguna, musim, dan pasar bergeser.

Konsekuensinya: SRE untuk ML membutuhkan dua dimensi monitoring — operasional (seperti biasa) dan kualitas/data (khusus ML).

#Model Monitoring: Dua Dimensi yang Harus Dipantau

#1. Monitoring Operasional (Infrastructure)

Sama seperti service biasa: availability inference endpoint, latency p95, throughput, error rate. Model yang hidup tapi lambat tetap melanggar SLO. Bagian ini memakai seluruh toolkit yang sudah kalian bangun — alerting (episode 6), dashboard (episode 5), capacity (episode 8).

#2. Monitoring Kualitas (Data & Prediction)

Inilah yang membedakan ML. Empat kelompok metrik kunci:

Metrik-metrik ini biasanya tidak real-time — mereka dihitung per batch (harian/jam-an) karena butuh label. Yang real-time adalah data drift: distribusi input yang bergeser sering kali adalah early warning yang mendahului penurunan kualitas.

#Drift Detection: Menangkap Perubahan Sebelum Terlambat

Data drift adalah perubahan distribusi data yang masuk; concept drift adalah perubahan hubungan antara input dan label. Keduanya menandakan model mulai tidak cocok dengan dunia.

Metode deteksi yang praktis:

• Statistik sederhana: bandingkan mean/stddev per fitur antara jendela waktu (baseline vs sekarang) — mirip pendekatan episode 22.
• Population Stability Index (PSI): mengukur seberapa jauh distribusi bergeser; threshold umum PSI di atas 0.25 menandakan drift signifikan.
• KS-test / chi-square: uji statistik formal untuk perbedaan distribusi.

import numpy as np
 
def psi(expected, actual, buckets=10):
    exp, _ = np.histogram(expected, bins=buckets, density=True)
    act, _ = np.histogram(actual, bins=buckets, density=True)
    exp = np.clip(exp + 1e-6, 1e-6, None)
    act = np.clip(act + 1e-6, 1e-6, None)
    return np.sum((act - exp) * np.log(act / exp))
 
if psi(baseline_pred, current_pred) > 0.25:
    alert("prediction drift terdeteksi")

#SLO untuk Inference: Janji yang Bisa Diukur

Sistem ML punya SLO dua lapis — keduanya wajib ada:

Lapisan infrastruktur (seperti service biasa):

• Availability inference endpoint: 99.9%.
• Latency p95 inference: di bawah 300 ms.

Lapisan kualitas (khas ML):

• Akurasi prediksi batch harian: di atas 90%.
• Data drift PSI per fitur kunci: di bawah 0.25.
• Label turnaround: label aktual tersedia dalam X jam setelah prediksi.

Mendefinisikan SLO kualitas adalah keputusan bisnis (persis episode 3-4): target akurasi 90% mungkin terlalu mahal atau terlalu murah tergantung dampak prediksi yang salah. Satu poin lagi yang sering terlupakan — baseline: "akurasi di atas 90%" tidak berarti banyak tanpa pembanding (misal majority-class baseline 85%). SLO yang baik selalu berpasangan dengan baseline yang jujur.

#Praktik: Monitoring Model dalam Produksi

Untuk model yang sudah berjalan di lab (atau model sederhana yang kalian deploy):

1. Pastikan dua dimensi terlihat: dashboard infrastruktur (latency, availability) + dashboard kualitas (distribusi prediksi, PSI per fitur).
2. Log prediksi + input + timestamp ke tempat yang bisa diagregasi — prediksi tanpa log tidak bisa diaudit.
3. Hitung PSI harian untuk distribusi prediksi dan fitur kunci; pasang alert pada ambang yang disetujui.
4. Tetapkan SLO kualitas dengan baseline jujur; pantau error budget-nya (episode 4) seperti SLO biasa.
5. Siapkan runbook drift: langkah mengecek, membandingkan, memicu retrain, dan rollback.

service: fraud-model-v3
slos:
  - name: inference-availability-30d
    objective: 99.9
    sli: availability inference endpoint
  - name: prediction-accuracy-7d
    objective: 92.0
    sli: akurasi prediksi batch, baseline 88%
    error_budget_policy: retrain jika budget habis

#Penutup

Pada episode 23 ini, kalian telah belajar menjaga model tetap benar, bukan hanya tetap hidup.

Inti yang harus dibawa pulang:

• Sistem ML gagal dalam dua lapis: operasional dan kualitas — keduanya wajib dimonitor.
• Data drift adalah early warning; concept drift adalah penyebab diam-diam penurunan kualitas.
• PSI dan metode statistik lain mengubah "rasa-rasa model mulai aneh" menjadi angka.
• SLO inference punya dua lapis: infrastruktur dan kualitas — selalu dengan baseline yang jujur.
• Drift alert wajib berpasangan dengan runbook retrain/rollback.

Di episode 24 selanjutnya, kalian akan berbalik menjadi pemberi layanan: platform reliability — keandalan platform internal, golden paths, dan developer SLA. Sampai jumpa di episode 24!