Bahasa Indonesia

Memindahkan Model ke Produksi Tanpa Merusaknya

Notebook Anda menghasilkan AUC 0,91 di laptop. Model kini sudah aktif, mengembalikan nilai minus tak terhingga untuk 3% permintaan, insinyur on-call dipanggil pukul 2 pagi, dan Anda tidak bisa mereproduksi proses pelatihan awal karena Anda tidak pernah menetapkan seed acak. Selamat datang di kesenjangan antara "model berfungsi" dan "model dirilis."

Saya telah menyaksikan adegan ini terjadi di enam perusahaan, dengan lima tumpukan ML yang berbeda, dan polanya tidak berubah. Kerugiannya bukan algoritmik. Kerugiannya bersifat operasional. Ketidaksesuaian pelatihan dan penyajian secara diam-diam menurunkan AUC produksi sebesar 4-7 poin. Alur fitur yang bekerja kemarin mengembalikan NaN hari ini karena seseorang mengubah skema upstream dan tidak memberi tahu Anda. Tim rekayasa memperlakukan model Anda sebagai kotak hitam karena Anda memperlakukan layanan mereka sebagai kotak hitam.

Ini adalah Playbook yang ingin saya terima sebelum insiden produksi pertama saya. Ini mencakup tujuh hal yang menentukan apakah model Anda menjadi pendapatan yang tenang atau topik analisis pascainsiden yang berulang.

Mengapa ini penting sekarang

Sebagian besar tim ilmu data kehilangan 30-50% nilai model antara AUC offline dan dampak bisnis online. Itu bukan metrik yang saya buat sendiri. Jalankan angkanya pada tiga model terakhir yang Anda rilis: peningkatan offline, peningkatan online, waktu dari "digabungkan" ke "sepenuhnya diluncurkan." Kesenjangan hampir selalu berbentuk staffing, bukan berbentuk algoritma.

DS yang memiliki disiplin pengembalian, pemantauan, dan antarmuka rekayasa merilis nilai 5 kali lebih banyak daripada DS dengan arsitektur model yang sedikit lebih baik. Kesiapan produksi adalah disiplin, bukan pilihan alat. Anda bisa melakukannya dengan AWS Batch dan tabel Postgres. Anda juga bisa gagal secara spektakuler dengan penyimpanan fitur paling mahal di pasar.

Alur fitur: Feast vs Tecton vs DIY

Setiap kegagalan produksi ML yang secara pribadi saya sebabkan berakar pada fitur. Secara khusus: fitur yang dilatih model tidak sama dengan fitur yang dilihat model saat penilaian. Kita menyebut ini ketidaksesuaian pelatihan dan penyajian, dan itu adalah pembunuh senyap.

Tiga pilihan:

DIY (tabel Postgres atau tampilan gudang data). Baik ketika Anda memiliki satu model, penilaian batch, dan SQL yang sama menghasilkan data pelatihan dan data penyajian. Sebagian besar perusahaan harus memulai di sini dan bertahan lebih lama dari yang mereka kira. Jebakannya: ketika Anda mulai menambahkan fitur realtime, SQL yang Anda tulis untuk pelatihan (jumlah bergulir 7 hari dari gudang) bukanlah SQL yang dijalankan layanan penyajian (agregat streaming dari Redis). Keduanya menyimpang. Secara diam-diam.

Feast (open source). Gratis, Anda yang mengelolanya. Layak dipilih ketika Anda memiliki 3+ model yang berbagi fitur, ingin definisi yang sama digunakan dalam pelatihan dan penyajian online, dan bersedia mengoperasikan Redis/DynamoDB dan alur Spark atau Flink. Pajak jujurnya: Anda akan menghabiskan satu kuartal untuk orientasi sebelum fitur mulai mengalir. Sepadan jika Anda sudah melewati fase satu model.

Tecton (terkelola). Beli ketika rekayasa fitur benar-benar menjadi hambatan, Anda memiliki anggaran untuk $80-200 ribu/tahun, dan Anda lebih suka tidak menjalankan infrastruktur streaming. Tecton menyelesaikan ketidaksesuaian pelatihan dan penyajian dengan membuat satu definisi menghasilkan backfill maupun nilai online. Pelacakan silsilah mereka menangkap "fitur ini berubah Selasa lalu" sebelum Anda mengetahuinya.

Keputusannya bukan "alat mana yang terbaik." Keputusannya adalah: apakah saya memiliki satu model atau banyak, batch atau realtime, dan apakah penyimpangan fitur saat ini tidak terlihat oleh saya? Jika ya-ya-ya, Anda memerlukan penyimpanan fitur. Jika tidak-tidak-tidak, tampilan gudang data dan file feature_definitions.py yang Anda impor dalam pelatihan dan penyajian lebih dari cukup.

Keterulangan alur pelatihan

Jika saya meminta Anda untuk menjalankan ulang pekerjaan pelatihan yang menghasilkan model yang ada di produksi sekarang, dari data mentah, dengan pemisahan yang sama dan metrik yang sama, bisakah Anda melakukannya dalam 30 menit?

Jika jawabannya tidak, Anda tidak memiliki alur yang dapat diulang. Anda memiliki kenang-kenangan.

Yang sebenarnya diperlukan keterulangan:

  1. Tetapkan setiap seed. Bukan hanya random_state=42 pada pembagian latih dan uji. Tetapkan seed numpy, tetapkan seed PyTorch/TensorFlow, tetapkan seed sampler Anda, tetapkan seed pengacak data Anda, tetapkan seed augmentasi apa pun. Saya pernah men-debug model di mana dua insinyur mendapatkan AUC 0,86 dan 0,91 dari "notebook yang sama" karena RNG CUDA torch tidak di-seed. Tiga hari terbuang.

  2. Hash pemisahan Anda. Jangan percaya train_test_split untuk bersifat deterministik lintas versi pandas. Hitung hash stabil dari pengidentifikasi baris (user_id, transaction_id) modulo rasio pemisahan. Baris yang sama, pemisahan yang sama, selamanya. Bonus: ketika Anda melatih ulang pada data baru, baris set uji lama tetap di set uji.

  3. Rekam SHA dataset dalam artefak model. Kartu model harus mencakup: SHA-256 dari dataset pelatihan (pasca rekayasa fitur), jendela pelatihan (2025-10-01 hingga 2026-03-31), versi skema fitur, commit kode, hash lockfile library, metrik eval pada set tahan, metrik eval pada set referensi beku. Ini masuk ke Git LFS atau artefak MLflow yang sama dengan bobot model.

  4. Kunci runtime. Sebuah requirements.lock atau poetry.lock atau uv.lock yang di-commit bersamaan dengan model. Penyimpangan versi library merusak keterulangan secara diam-diam. scikit-learn 1.3 vs 1.4 sudah cukup untuk menggeser prediksi.

Tes "jalankan ulang pelatihan dari 6 minggu lalu" tidak bisa ditawar. Jika Anda tidak bisa melewatinya, Anda tidak bisa men-debug regresi secara kredibel. Anda hanya menebak.

Penyajian batch vs realtime: kapan masing-masing

Sebagian besar model "realtime" seharusnya batch. Saya akan mengatakannya dua kali karena ini selalu diabaikan. Sebagian besar model "realtime" seharusnya batch.

Pohon keputusannya:

  • Anggaran latensi lebih dari 1 jam, prediksi berubah lambat, batch setiap malam. Nilai semua orang pada pukul 2 pagi, tulis ke tabel, produk membaca dari tabel. Lead scoring, risiko churn, rekomendasi konten untuk pengguna yang bukan cold-start. Latensi p99: sebuah SELECT.
  • Anggaran latensi 5-60 menit, prediksi membutuhkan kesegaran per jam, batch per jam. Bentuk yang sama, lebih sering. Peramalan inventaris, sinyal permintaan.
  • Anggaran latensi 30 detik hingga 5 menit, bergantung pada aktivitas sesi, microbatch. Konsumen streaming menilai dalam batch 100-1.000 catatan setiap 30 detik. Sinyal penipuan, deteksi anomali di mana tindakan bisa menunggu satu menit.
  • Anggaran latensi kurang dari 200ms, permintaan tidak dapat diprediksi, realtime. Peringkat iklan, relevansi pencarian, pemblokiran penipuan saat checkout, personalisasi real-time. Ini yang mahal. Anggaran latensi p99 harus ditetapkan dalam kontrak antarmuka sebelum Anda melatih, bukan setelah Anda menerapkan.

Perbedaan biayanya sangat besar. Pekerjaan batch malam berjalan pada satu instance besar selama satu jam. Layanan realtime membutuhkan autoscaling, warm pool, pemantauan p99, dan SRE dalam rotasi. Pilih batch kecuali Anda memiliki alasan yang nyata.

Sebuah kisah perang: kami merilis model rekomendasi "realtime" yang memanggil Postgres secara sinkron untuk tiga pencarian fitur per permintaan. p99 naik ke 4 detik sebelum kami menyadarinya. Solusinya bukan Postgres yang lebih cepat. Solusinya adalah mengakui bahwa model tidak perlu realtime, memindahkannya ke batch, dan menyajikan dari tabel yang telah dihitung sebelumnya. Latensi turun ke 8ms. Tim produk tidak menyadari perubahan karena rekomendasinya sebenarnya tidak bergantung pada sesi.

Pemantauan model: penyimpangan, pergeseran konsep, metrik bisnis

Empat hal yang perlu dipantau. Tiga di antaranya bersifat diagnostik. Hanya satu yang membayar tagihan.

Penyimpangan data. Apakah fitur yang dilihat model hari ini terdistribusi seperti fitur yang dilatihnya? Lacak Population Stability Index (PSI) per fitur, setiap hari. PSI lebih dari 0,1: selidiki. PSI lebih dari 0,25: distribusi pelatihan dan distribusi produksi Anda tidak lagi sama. Beri peringatan. Untuk fitur kontinu, jalankan juga uji Kolmogorov-Smirnov terhadap jendela referensi. Murah, cepat, menangkap pemutusan skema sebelum prediksi menjadi buruk.

Penyimpangan prediksi. Apakah keluaran model terdistribusi seperti minggu lalu? Terkadang penyimpangan data tidak terlihat (interaksi fitur bergerak) tetapi penyimpangan prediksi terdengar keras. Lacak p10/p50/p90 keluaran model setiap hari.

Penyimpangan konsep (dengan kesadaran penundaan label). Apakah hubungan antara fitur dan label berubah? Anda hanya bisa memeriksa ini ketika label tiba, yang untuk banyak model terjadi beberapa hari atau minggu kemudian. Bangun alur evaluasi tertunda: ketika label tiba, hitung ulang AUC/MAE pada baris-baris tersebut dan buat grafiknya dari waktu ke waktu. Jebakannya adalah memberi peringatan pada AUC sehari setelah penerapan ketika Anda tidak memiliki label. Anda akan menatap angka 0.

Metrik bisnis. Pendapatan. Tingkat konversi. CAC. Nilai seumur hidup pelanggan. Hal yang ada untuk digerakkan model. Ini adalah satu-satunya metrik yang menentukan apakah model tetap aktif. Ambang batas peringatan pada penyimpangan data/prediksi bersifat diagnostik. Ambang batas peringatan pada metrik bisnis bersifat eksistensial.

Saya pernah melihat tim merilis model dengan dashboard penyimpangan yang dikalibrasi dengan indah dan nol visibilitas apakah pendapatan bergerak. Jangan menjadi tim itu. Dashboard pertama adalah dashboard bisnis. Dashboard penyimpangan ada untuk menjelaskan mengapa metrik bisnis bergerak, bukan untuk menggantikannya.

Peluncuran "shadow mode"

Nilai tetapi jangan bertindak. Selama satu hingga dua minggu. Pada traffic yang sama. Bandingkan prediksi model baru terhadap prediksi model yang ada dan terhadap hasil aktual ketika label tiba.

Ini adalah praktik paling berdampak yang saya ketahui dalam ML produksi, dan sebagian besar tim melewatkannya.

Alur shadow rollout:

  1. Terapkan model baru di samping model yang ada. Keduanya menilai setiap permintaan. Hanya prediksi model yang ada yang memengaruhi perilaku produk.
  2. Catat kedua prediksi plus semua fitur yang digunakan.
  3. Setelah 7-14 hari, bandingkan:
    • Tumpang tindih distribusi: apakah kedua model membuat prediksi yang serupa pada input yang sama? Jika 30% tidak setuju, cari tahu alasannya sebelum beralih.
    • Cocokkan dengan ekspektasi offline: apakah perilaku online model baru sesuai dengan yang diprediksi evaluasi set tahan Anda? Jika offline mengatakan peningkatan +5% dan shadow mengatakan keduanya identik, data pelatihan Anda bocor.
    • Latensi, tingkat kesalahan, kasus tepi (input NaN, fitur yang hilang): apakah model baru menangani ekor distribusi panjang?
  4. Hanya alihkan sakelar ketika data shadow mengkonfirmasi cerita offline.

Champion/challenger adalah ide yang sama, lebih formal. Model yang ada adalah juara. Model baru adalah penantang. Anda tidak mempromosikan penantang sampai ia menang di bawah traffic nyata, bukan hanya pada set pengujian.

Peluncuran itu sendiri harus bertahap: 1% ke 5% ke 25% ke 50% ke 100%, dengan setidaknya 24-48 jam di antara setiap langkah dan metrik bisnis dipantau pada setiap tahap. Jika ada yang bergerak ke arah yang salah, berhenti. Jangan rasionalisasi.

Pola kemitraan rekayasa: kontrak antarmuka

Pendekatan "lempar pickle ke seberang tembok" selalu gagal. Inilah yang berhasil.

Sebelum Anda mulai melatih, duduklah dengan insinyur platform dan tulis kontrak antarmuka satu halaman. Ini mencakup:

  • Skema API. Bidang input, tipe, null yang diizinkan, aturan validasi. Bidang output, tipe, rentang. Seperti apa respons ketika model tidak bisa menilai (fitur yang hilang, server model mati)?
  • SLO latensi. p50, p95, p99 dalam milidetik. Ini menentukan apakah Anda dapat melakukan pencarian fitur realtime, arsitektur model apa yang tidak bisa digunakan, apakah inferensi GPU diperlukan.
  • SLO throughput. Permintaan per detik pada puncak. Menggerakkan konfigurasi autoscaling.
  • Anggaran kesalahan. Berapa persentase permintaan yang diizinkan gagal oleh layanan? 0,1%? 1%? Ini menetapkan standar keketatan validasi input.
  • Batas kepemilikan. Siapa yang dipanggil ketika model mengembalikan prediksi yang salah vs ketika layanan mengembalikan 500? DS memiliki yang pertama. Rekayasa memiliki yang kedua. Keduanya memiliki yang ketiga (model aktif tetapi prediksi buruk).
  • Otoritas pengembalian. Siapa yang bisa membalik sakelar penghenti darurat tanpa eskalasi? Pada pukul 3 pagi, jawabannya harus "insinyur on-call," bukan "hubungi Camellia."

Tuliskan ini. Tandatangani. Sematkan. Ketika insiden produksi yang tak terhindarkan terjadi, kontrak adalah yang menjaga percakapan tentang memperbaiki masalah alih-alih menegosiasikan tanggung jawab.

DS yang datang ke pertemuan itu dengan draf kontrak mendapatkan kepercayaan saat mereka masuk. DS yang datang dengan notebook dan bertanya "bagaimana kita menerapkan ini?" memulai dari nol.

Disiplin pengembalian

Setiap penerapan dilengkapi dengan jalur pengembalian yang sudah diuji. Bukan jalur pengembalian yang didokumentasikan. Yang sudah diuji.

Tiga komponen:

  1. Penandaan versi. Setiap model mendapat versi (pricing-model-v23). Setiap prediksi yang dicatat mencakup versi yang menilainya. Ketika Anda menyelidiki regresi, Anda bisa memfilter berdasarkan versi.
  2. Sakelar penghenti darurat. Tanda konfigurasi yang mengalihkan traffic dari model baru kembali ke yang sebelumnya dalam waktu kurang dari 60 detik. Bukan penerapan ulang. Pembalikan tanda. Layanan penyajian membaca tanda pada waktu permintaan.
  3. Latihan pengembalian. Setiap kuartal, jalankan pengembalian dalam produksi selama 5 menit pada jendela traffic rendah. Jika Anda belum menarik pelatuknya dalam 90 hari, pengembalian bersifat teoritis, yang berarti tidak berfungsi.

Pertama kali Anda membutuhkan pengembalian bukanlah saat yang tepat untuk menemukan bahwa artefak model sebelumnya telah dihapus dari S3, alur fitur telah di-refactor, atau sakelar penghenti darurat tidak pernah berfungsi. Saya secara pribadi mengalami ketiganya.

Kesalahan umum

  • Melatih pada data yang tidak bisa dilihat model saat penyajian. Kebocoran data. Bentuk yang paling umum: fitur yang hanya bisa dihitung setelah peristiwa yang diprediksi. Fitur "hari sejak login terakhir" yang dihitung dari gudang akan mencakup login setelah timestamp prediksi kecuali Anda secara eksplisit memotongnya.
  • Menetapkan random_state=42 tetapi tidak men-seed sampler upstream. Pemisahan Anda deterministik, pelatihan Anda tidak.
  • Menerapkan tanpa champion/challenger. Anda menebak apakah model baru lebih baik.
  • Memberi peringatan pada AUC alih-alih pendapatan. AUC turun dari 0,84 ke 0,82, apakah itu buruk? Anda tidak tahu. Mungkin pendapatan naik.
  • Tidak ada uji pengembalian dalam 90 hari. Anda tidak memiliki pengembalian. Anda memiliki keinginan.
  • Memperlakukan rekayasa sebagai meja layanan alih-alih mitra. Mereka akan memperlakukan model Anda dengan cara yang sama.

Template dan alat

Empat dokumen yang harus dimiliki setiap model yang dirilis:

  • Kartu model. SHA dataset, jendela pelatihan, seed, versi skema fitur, metrik eval pada set tahan dan referensi beku, SLO penyajian, pemilik, tanggal penerapan, prosedur pengembalian.
  • Daftar periksa perbandingan shadow-mode. Tumpang tindih distribusi, kecocokan offline-online, latensi, tingkat kesalahan, penanganan kasus tepi, persyaratan sign-off per pemangku kepentingan.
  • Runbook pengembalian. Pembalikan sakelar penghenti darurat langkah demi langkah, cara memverifikasi bahwa model sebelumnya menyajikan traffic, siapa yang diberitahu, template analisis pascainsiden.
  • Kontrak antarmuka rekayasa/DS. Satu halaman. Skema API, SLO, anggaran kesalahan, batas kepemilikan, otoritas pengembalian. Ditandatangani oleh DS, pimpinan rekayasa, dan rotasi on-call.

Mengukur keberhasilan

Anda melakukan ini dengan benar ketika:

  • Anda bisa menjalankan ulang proses pelatihan tepat model produksi mana pun dari data mentah dalam waktu kurang dari 30 menit.
  • Setiap penerapan memiliki pengembalian yang sudah diuji yang telah dijalankan dalam 90 hari terakhir.
  • Pemantauan menangkap penyimpangan sebelum metrik bisnis bergerak, bukan setelahnya.
  • Insinyur platform Anda berkata "bekerja dengan Anda itu mudah" tanpa diminta.
  • Tiga penerapan terakhir membosankan.

Penerapan yang membosankan adalah tujuannya. Drama adalah kegagalan. DS yang merilis dengan membosankan adalah DS yang sering merilis, dan DS yang sering merilis menggandakan nilai lebih cepat dari siapa pun dengan arsitektur model yang sedikit lebih baik.

Pelajari Lebih Lanjut