Kesalahan Umum Data Scientist (Dan Cara Berhenti Mengulanginya)

Saya telah menyaksikan pola yang sama berulang di tiga tim berbeda. Seorang Data Scientist baru bergabung, merilis model pertama yang bersih dalam enam bulan, mendapat pujian wajib di all-hands. Kemudian sekitar bulan kesembilan atau keduabelas, roda berhenti berputar. Promosi tidak datang. PM menjadi hening. Reorganisasi menempatkan mereka di tim yang "kurang strategis" dan mereka menghabiskan tahun berikutnya bertanya-tanya apa yang terjadi.

Hampir setiap kali, itu adalah salah satu dari tujuh kesalahan. Kadang dua atau tiga sekaligus.

Ini bukan artikel "kesalahan teratas yang harus dihindari." Ini adalah daftar hal-hal spesifik yang menghancurkan karier DS antara bulan ke-6 dan ke-18, ketika niat baik lulusan baru habis dan para pemangku kepentingan mulai mengharapkan dampak bisnis yang nyata. Setiap kesalahan disertai gejala yang bisa Anda kenali pada diri sendiri, angka nyata yang membuat biayanya konkret, dan perbaikan yang bisa Anda jalankan minggu ini.

Mengapa Ini Penting Sekarang

Tahun pertama, Anda mendapat kelonggaran. Orang-orang sabar. Mereka mengharapkan masa adaptasi. Anda bisa merilis notebook dan menyebutnya deliverable.

Tahun kedua dan ketiga, itu sudah hilang. Anda dinilai berdasarkan hasil bisnis yang dirilis: model yang berjalan dalam produksi, keputusan yang berubah, dolar yang dihemat atau diperoleh. Data Scientist yang mencapai Senior dalam 2-3 tahun dibandingkan yang stagnan di IC2, perbedaannya jarang pada IQ atau kemampuan statistik. Hampir semua orang di level ini memiliki dasar teknis. Perbedaannya adalah apakah mereka menghindari daftar ini.

Jika Anda sudah 6-18 bulan dan ada sesuatu yang terasa tidak beres tetapi Anda tidak bisa menamakannya, mulailah dari sini.

Kesalahan 1: Memulai dengan Model, Bukan Masalah

Gejala. Anda membuka notebook dan mulai menarik data sebelum Anda menuliskan keputusan apa yang seharusnya diinformasikan model. Mungkin Anda sudah memilih XGBoost. Mungkin Anda sedang memikirkan apakah akan mencoba transformer. Thread Slack dengan pemangku kepentingan baru tiga pesan.

Biayanya. Gartner dan VentureBeat telah mempublikasikan angka yang sama menyedihkan selama bertahun-tahun: 60-70% proyek ML tidak pernah mencapai produksi. Pekerjaan teknisnya biasanya bukan yang membunuhnya. Kebanyakan mati karena tidak ada yang merumuskan keputusan bisnis yang seharusnya diinformasikan model, sehingga ketika model "selesai," tidak ada tempat untuk dihubungkan. Dashboard yang tidak dibuka siapa pun. Skor yang tidak ditindaklanjuti siapa pun. Enam bulan hidup Anda.

Perbaikannya. Sebelum Anda membuka notebook, tulis brief masalah satu halaman. Bukan esai Confluence. Satu halaman.

Keputusan apa yang dibuat, dan oleh siapa
Apa baseline saat ini (rules engine, intuisi, rata-rata kuartal lalu)
Seperti apa "lebih baik" dalam dolar atau KPI bisnis
Siapa yang bertindak berdasarkan output model, dan melalui permukaan mana (dashboard, alert, panggilan API, email)
Apa biaya kesalahan, dalam dua arah

Jika Anda tidak bisa menjawab kelima pertanyaan tersebut, Anda belum memiliki proyek. Anda memiliki pameran sains. Kembali ke pemangku kepentingan dan lakukan percakapan tersebut.

Kesalahan 2: Membangun di Notebook dan Melemparkannya ke Tembok

Gejala. Dokumen handoff Anda adalah Jupyter notebook dengan path yang di-hardcode dan sel yang bertuliskan df = pd.read_csv('/Users/namakamu/Downloads/data_v3_FINAL.csv'). Engineering memberikan estimasi 6-8 minggu untuk "memproduksikannya." Separuh upaya mereka dihabiskan untuk menulis ulang kode Anda menjadi sesuatu yang benar-benar bisa berjalan terjadwal.

Biayanya. Survei State of Data Science Anaconda telah menempatkan sekitar 38% waktu DS pada persiapan data dan hambatan deployment selama bertahun-tahun berturut-turut. Penulisan ulang notebook ke produksi adalah porsi terbesar dari hambatan deployment tersebut. Setiap kali eng harus menerjemahkan notebook Anda ke kode produksi, Anda telah menambahkan berminggu-minggu ke timeline dan membuat tim eng kurang antusias bekerja dengan Anda kuartal berikutnya.

Perbaikannya. Dari minggu pertama sebuah proyek, tulis kode seolah-olah seorang rekan akan menjalankannya besok di mesin yang berbeda. Ini bukan DevOps. Ini kebersihan dasar.

Pindahkan logika pembersihan dan fitur ke dalam modul .py yang dapat diimpor. Notebook memanggilnya. Tidak mendefinisikan ulangnya.
Pin dependensi dalam requirements.txt atau pyproject.toml. Bukan "apa pun yang ada di laptop saya bulan Maret."
Parameterkan path dan tanggal. Tidak ada /Users/namakamu/. Tidak ada 2024-Q3 yang di-hardcode.
Gunakan file konfigurasi atau env vars untuk apa pun yang berubah antara dev dan prod.
Jalankan kode Anda sendiri di lingkungan yang bersih sebelum Anda menyerahkannya. Jika rusak untuk Anda pada instalasi bersih, itu akan rusak untuk eng.

Anda tidak memerlukan Kubernetes. Anda memerlukan kode yang bisa dijalankan orang lain tanpa menjadwalkan Zoom.

Kesalahan 3: Melewati Pemantauan Produksi

Gejala. Model sudah dirilis. Anda pindah ke proyek berikutnya. Tiga bulan kemudian, tiket dukungan melonjak. Customer success berteriak. Anda menghabiskan dua hari menggali dan menemukan model telah mengalami penyimpangan diam-diam sejak minggu keempat.

Biayanya. Studi industri secara konsisten menempatkan penurunan performa model pada 20-40% dalam 6-12 bulan untuk model bisnis tipikal tanpa pelatihan ulang. Perilaku pelanggan berubah. Sumber data hulu mengubah skema tanpa memberi tahu Anda. Fitur produk baru mengubah distribusi input. Tanpa pemantauan, Anda mengetahuinya dari orang yang terdampak: pelanggan dan pemangku kepentingan Anda.

Perbaikannya. Kirim dashboard pemantauan di minggu yang sama Anda merilis model. Bukan "setelah sprint berikutnya." Minggu yang sama.

Lacak Population Stability Index (PSI) pada 5-10 fitur teratas Anda. Beri peringatan ketika PSI > 0,2.
Lacak distribusi prediksi hari per hari. Pergeseran mendadak dalam rata-rata atau bentuk adalah indikator utama.
Lacak KPI bisnis yang terkait dengan model (tingkat konversi, tingkat churn, tingkat tangkapan penipuan). Jika KPI bergeser, Anda perlu tahu sebelum VP mengetahuinya.
Tetapkan jadwal pelatihan ulang. Kuartalan adalah batas bawah untuk sebagian besar model bisnis, bulanan untuk apa pun di domain yang bergerak cepat.
Letakkan nama dan kontak Anda di dashboard. Miliki itu.

Model tanpa pemantauan adalah kewajiban, bukan aset. Perlakukan seperti itu.

Kesalahan 4: Over-Engineering Fitur

Gejala. Pipeline akhir Anda memiliki 200 fitur dan rantai preprocessing 12 langkah. AUC naik dari 0,81 menjadi 0,83. Anda bangga. Pemangku kepentingan tidak memperhatikan perbedaannya.

Biayanya. 180 fitur ekstra tersebut menggandakan waktu pelatihan, melipattigakan permukaan kegagalan dalam produksi (setiap fitur adalah potensi null, kerusakan skema, atau insiden hulu), dan peningkatan yang Anda "menangkan" berada di dalam pita noise test set Anda. Anda sekarang bertanggung jawab untuk mempertahankan pipeline yang rapuh demi peningkatan AUC 2% yang tidak diminta siapa pun.

Perbaikannya. Mulai ramping. Tambahkan hanya ketika matematika membenarkannya.

Buka dengan 10-20 fitur. Yang akan disebutkan ahli domain dalam sebuah rapat.
Tambahkan fitur hanya ketika SHAP atau permutation importance menunjukkan peningkatan >1% pada set yang di-hold-out.
Tambahkan fitur hanya ketika pemangku kepentingan peduli dengan 1% tersebut. Jika 1% churn adalah $50 ribu, tidak masalah. Jika itu $500, buang.
Setiap fitur yang Anda tambahkan adalah janji pemeliharaan. Jika Anda tidak bisa berkomitmen untuk memeliharanya, jangan tambahkan.
Jika ragu, lakukan ablasi. Buang fitur-fitur dengan kepentingan terendah dan lihat apakah ada yang benar-benar rusak.

Standar DS Senior bukan "AUC tertinggi." Ini adalah "dampak bisnis tertinggi per unit kompleksitas pipeline."

Kesalahan 5: Melaporkan AUC Tanpa Metrik Bisnis

Gejala. Slide readout Anda mengatakan "AUC 0,87, F1 0,74, log loss 0,21." Pemangku kepentingan Anda mengangguk sopan. Mereka melupakan keberadaan proyek pada tinjauan kuartalan berikutnya.

Biayanya. Nol dolar langsung, tetapi proyek berhenti mendapat pendanaan karena tidak ada yang bisa menjelaskannya kepada VP. Anda telah membangun sesuatu yang berhasil dan tidak ada yang tahu itu berhasil. Enam bulan kemudian, ketika anggaran ketat, proyek yang "tidak benar-benar bisa kita artikan nilainya" adalah yang pertama dipotong.

Perbaikannya. Setiap laporan model dimulai dengan metrik bisnis. Selalu.

Buka dengan dolar atau KPI: "$2,1 juta churn dihemat pada threshold ini," "peningkatan presisi 14% di atas rules engine," "pengurangan 23% dalam chargeback penipuan."
Tampilkan kurva tradeoff dalam istilah bisnis. "Pada threshold 0,4, kita menangkap 80% penipuan dan menandai 3% transaksi sah. Pada threshold 0,6, kita menangkap 60% dan menandai 0,5%. Begini biaya masing-masing."
Kaitkan metrik dengan angka yang sudah dipedulikan pemangku kepentingan. Jika mereka hidup berdasarkan ARR, ungkapkan dalam ARR. Jika mereka hidup berdasarkan NPS, ungkapkan dalam NPS.
AUC, F1, dan log loss masuk ke lampiran. Itu untuk Anda dan reviewer DS Anda, bukan VP.
Akhiri dengan keputusan yang diaktifkan model, bukan modelnya sendiri.

Laporan model yang tidak dimulai dengan nilai bisnis adalah pembaruan status, bukan hasil.

Kesalahan 6: Mengabaikan Kualitas Data di Sumbernya

Gejala. Notebook Anda memiliki 400 baris kode pembersihan karena "datanya berantakan." Anda telah menjelaskan ini dalam tiga standup terakhir. Anda mulai menganggap diri Anda sebagai orang yang tahu di mana "mayat-mayat terkubur" di tabel event pelanggan.

Biayanya. Angka lama IBM menempatkan biaya data buruk sebesar $3,1 triliun per tahun di seluruh ekonomi AS. Di tingkat perusahaan, survei secara konsisten menunjukkan tim DS menghabiskan 40-60% waktu mereka untuk pembersihan. Itu waktu Anda. Gaji Anda. Dan setiap aturan pembersihan yang Anda tulis di notebook Anda adalah aturan yang akan membusuk diam-diam saat berikutnya skema hulu berubah, karena tidak ada orang lain yang tahu keberadaannya.

Perbaikannya. Perlakukan setiap aturan pembersihan sebagai laporan bug yang Anda berikan kepada tim data engineering.

Ajukan bug-nya. Sekali. Dengan repro yang jelas dan dampaknya ("ini memengaruhi tiga model produksi").
Hentikan memperbaikinya di notebook Anda. Perbaiki di hulu, di pipeline sumber, di mana setiap konsumen hilir mendapat manfaat.
Dorong data contracts pada tabel yang Anda andalkan. Skema, nullability, SLA kesegaran, pemilik.
Jadikan kualitas data sebagai metrik bersama. Jika tim Anda dan data eng keduanya memiliki "kesegaran data" atau "tingkat kerusakan skema" di dashboard, perbaikan terjadi lebih cepat.
Ketika eng mendorong balik ("bukan prioritas kuartal ini"), datang dengan biaya dalam dolar: jam DS yang terbuang, model yang terdegradasi, keputusan yang terblokir.

Perbaikan notebook adalah pajak yang Anda bayar selamanya. Perbaikan hulu adalah investasi sekali waktu. Bayar sekali.

Kesalahan 7: Mengatakan "Model Baik-Baik Saja, Datanya yang Salah" Tanpa Memperbaiki Data

Gejala. Anda telah menggunakan beberapa versi kalimat ini dalam 3+ standup: "Model bekerja. Data pelatihannya yang buruk." Anda mengatakannya lagi dalam tinjauan minggu lalu. Pemangku kepentingan menjadi hening.

Biayanya. Anda, secara khusus. Dalam sekitar enam bulan, pemangku kepentingan melewati Anda ke DS yang "benar-benar merilis." Anda tidak diikutsertakan dalam proyek strategis berikutnya. Anda tidak mendapat percakapan promosi. Model yang "baik-baik saja" adalah model yang tidak dipercaya siapa pun dalam produksi, yang berarti itu tidak baik-baik saja.

Perbaikannya. Miliki pipeline secara penuh. Titik.

Model adalah tanggung jawab Anda, dan model mencakup data yang memberinya makan. Tidak ada garis bersih di mana "pekerjaan Anda" berakhir dan "pekerjaan data eng" dimulai ketika outputnya rusak.
Jika datanya salah, Anda eskalasi. Bukan di Slack dengan passive-voice. Dalam email dengan nama di atasnya dan deadline.
Tulis spesifikasi untuk seperti apa "benar" itu. Rentang numerik, kesegaran, skema. Jangan biarkan untuk interpretasi.
Duduk dalam tinjauan eng ketika perbaikannya sedang dibatasi. Pastikan mereka menyelesaikan masalah yang tepat.
Jangan lepaskan sampai diperbaiki dalam produksi dan diverifikasi di dashboard pemantauan Anda.

"Bukan masalah saya" adalah kalimat yang mengakhiri karier pada tahap ini. Model tidak baik-baik saja jika tidak bekerja dalam produksi. Membuatnya bekerja dalam produksi adalah pekerjaan Anda.

Pola di Balik Ketujuh Kesalahan

Baca ulang tujuh kesalahan tersebut. Semuanya adalah kesalahan yang sama.

Memperlakukan data science sebagai pekerjaan pemodelan alih-alih pekerjaan hasil bisnis.

Kesalahan 1 adalah "saya fokus pada model, bukan keputusan." Kesalahan 2 adalah "saya fokus pada model, bukan handoff." Kesalahan 3 adalah "saya fokus pada model, bukan apa yang terjadi setelah peluncuran." Empat adalah "model, bukan biaya pemeliharaan." Lima adalah "model, bukan dolar." Enam adalah "model, bukan data yang memberinya makan." Tujuh adalah "model, bukan sistem di sekitarnya."

Standar DS Senior adalah "merilis dampak bisnis yang terukur." Standar IC2-selamanya adalah "menghasilkan model akurat yang tidak digunakan siapa pun." Lihat DS mana pun yang mencapai Senior dalam 2-3 tahun di tim Anda. Kemudian lihat satu yang telah menjadi IC2 selama empat tahun. Perbedaannya hampir tidak pernah pada matematika. Ini adalah apakah mereka memperlakukan model sebagai deliverable, atau sebagai satu komponen sistem yang harus benar-benar bekerja untuk bisnis.

Audit Mandiri

Jalankan ini terhadap 2-3 proyek terakhir Anda. Jujurlah. Tujuannya bukan untuk merasa buruk, tetapi untuk mengetahui di mana Anda berada.

Untuk setiap proyek, tanyakan:

Apakah saya menulis brief masalah satu halaman sebelum membuka notebook?
Apakah handoff saya ke engineering berupa kode bersih dalam modul yang dapat diimpor, bukan notebook dengan path yang di-hardcode?
Apakah saya merilis pemantauan di minggu yang sama saya merilis model?
Apakah saya menjaga fitur tetap ramping, hanya menambahkan ketika SHAP membenarkannya DAN pemangku kepentingan peduli?
Apakah readout saya dimulai dengan metrik bisnis, dengan AUC di lampiran?
Apakah saya mengajukan masalah kualitas data hulu, atau hanya membersihkannya di notebook saya?
Ketika data salah, apakah saya memiliki perbaikan dari ujung ke ujung?

Hitung jawabannya "tidak".

0-1 tidak: Anda berada di jalur yang benar. Terus lakukan seperti sekarang.
2-3 tidak: Koreksi arah sekarang. Pilih satu dengan leverage tertinggi dan perbaiki di proyek berikutnya.
4+ tidak: Lakukan percakapan nyata dengan manajer Anda minggu ini. Anda berada selangkah dari tim yang kurang strategis dan Anda mungkin sudah merasakannya.

Seperti Apa "Bagus" Itu

DS yang mencapai Senior dalam 2-3 tahun tidak lebih cerdas dari Anda. Mereka hanya telah menginternalisasi definisi pekerjaan yang berbeda.

Mereka memulai setiap proyek dengan brief masalah, bukan notebook. Mereka menulis kode dari minggu pertama seolah-olah eng akan menjalankannya pada hari Senin. Mereka merilis pemantauan di minggu yang sama dengan model dan memeriksanya setiap minggu. Mereka menjaga fitur tetap ramping dan melakukan ablasi tanpa ragu. Mereka memimpin readout dengan dolar, bukan AUC. Mereka mengajukan masalah kualitas data di hulu dan mengikutinya sampai selesai. Ketika datanya salah, mereka memiliki perbaikannya sampai dideploy.

Orang itu merilis lebih sedikit notebook dan lebih banyak sistem yang dirilis, dipantau, berdampak pada bisnis. Pemangku kepentingan menarik mereka ke proyek strategis berikutnya sebelum proyek saat ini berakhir. Paket promosi menulis dirinya sendiri, karena setiap proyek memiliki cerita yang bersih "saya merilis X, menghasilkan Y nilai bisnis, berikut dashboardnya".

Anda bisa menjadi orang itu. Sebagian besar perbedaannya adalah kebiasaan, bukan kemampuan.

Panduan Praktis Data Scientist