Perangkap Biasa Data Scientist (Dan Cara Berhenti Mengulanginya)

Saya telah menyaksikan corak yang sama berulang pada tiga pasukan berbeza. Data Scientist baru menyertai, menghantar model pertama yang bersih dalam enam bulan, mendapat pujian lazim dalam all-hands. Kemudian di sekitar bulan sembilan atau dua belas, roda berhenti berpusing. Promosi tidak datang. PM diam. Penstrukturan semula menempatkan mereka dalam pasukan "kurang strategik" dan mereka menghabiskan setahun berikutnya tertanya-tanya apa yang berlaku.

Hampir setiap kali, ia adalah salah satu daripada tujuh kesilapan. Kadang-kadang dua atau tiga sekaligus.

Ini bukan senarai "kesilapan teratas untuk dielakkan." Ia adalah senarai perkara khusus yang membunuh kerjaya DS antara bulan 6 dan 18, apabila muhibah graduan baru habis dan pihak berkepentingan mula mengharapkan impak perniagaan sebenar. Setiap perangkap datang dengan gejala yang boleh anda kesan pada diri sendiri, nombor sebenar yang menjadikan kos konkrit, dan pembetulan yang boleh anda jalankan minggu ini.

Mengapa Ini Penting Sekarang

Tahun pertama, anda mendapat laluan bebas. Orang sabar. Mereka mengharapkan kenaikan tahap. Anda boleh menghantar notebook dan menyebutnya sebagai hasil kerja.

Tahun dua dan tiga, itu sudah tiada. Anda dinilai berdasarkan hasil perniagaan yang dihantar: model berjalan dalam pengeluaran, keputusan yang berubah, dollar yang diselamatkan atau dibuat. Data Scientist yang mencapai Senior dalam 2-3 tahun berbanding yang mencapai tahap IC2 sahaja, jurangnya jarang kecerdasan atau kemahiran statistik. Hampir semua orang pada tahap ini mempunyai asas teknikal. Jurangnya adalah sama ada mereka mengelakkan senarai ini.

Jika anda berusia 6-18 bulan dan sesuatu terasa tidak kena tetapi anda tidak dapat menamakannya, mulakan di sini.

Perangkap 1: Bermula dengan Model, Bukan Masalah

Gejala. Anda membuka notebook dan mula menarik data sebelum anda menuliskan keputusan apa yang model itu sepatutnya memaklumkan. Mungkin anda sudah memilih XGBoost. Mungkin anda sedang memikirkan sama ada hendak mencuba transformer. Utas Slack dengan pihak berkepentingan mempunyai tiga mesej di dalamnya.

Kos. Gartner dan VentureBeat telah menerbitkan nombor yang sama menyedihkan selama bertahun-tahun: 60-70% projek ML tidak pernah mencapai pengeluaran. Kerja teknikal biasanya bukan yang membunuh mereka. Kebanyakan mati kerana tiada siapa yang membingkaikan keputusan perniagaan yang sepatutnya dimaklumkan oleh model, jadi apabila model "siap," tiada tempat untuknya disambungkan. Dashboard yang tidak ada siapa buka. Skor yang tidak ada siapa bertindak. Enam bulan hidup anda.

Pembetulan. Sebelum anda membuka notebook, tulis brief masalah satu halaman. Bukan esei Confluence. Satu halaman.

Keputusan apa yang dibuat, dan oleh siapa
Apakah asas semasa (enjin peraturan, naluri, purata suku tahun lepas)
Seperti apa "lebih baik" dalam dollar atau KPI perniagaan
Siapa yang bertindak atas output model, dan melalui permukaan mana (dashboard, amaran, panggilan API, e-mel)
Apakah kos jika salah, dalam kedua-dua arah

Jika anda tidak boleh menjawab semua lima, anda belum mempunyai projek. Anda mempunyai pameran sains. Kembali kepada pihak berkepentingan dan adakan perbualan.

Perangkap 2: Membina dalam Notebook dan Melemparkannya Melepasi Tembok

Gejala. Dokumen serah terima anda adalah notebook Jupyter dengan laluan berkod keras dan sel yang berbunyi df = pd.read_csv('/Users/yourname/Downloads/data_v3_FINAL.csv'). Kejuruteraan memberi sebutan 6-8 minggu untuk "pengeluarannya." Separuh usaha mereka pergi untuk menulis semula kod anda kepada sesuatu yang sebenarnya boleh berjalan mengikut jadual.

Kos. Tinjauan Keadaan Sains Data Anaconda telah menempatkan kira-kira 38% masa DS pada penyediaan data dan geseran penempatan selama bertahun-tahun. Penulisan semula notebook-ke-pengeluaran adalah sebahagian terbesar geseran penempatan itu. Setiap kali kejuruteraan perlu menterjemahkan notebook anda ke dalam kod pengeluaran, anda telah menambah minggu ke garis masa dan menjadikan pasukan kejuruteraan kurang bersemangat untuk bekerja dengan anda suku tahun seterusnya.

Pembetulan. Dari minggu pertama projek, tulis kod seolah-olah rakan sekerja akan menjalankannya esok pada mesin yang berbeza. Ini bukan DevOps. Ia adalah kebersihan asas.

Tarik logik pembersihan dan ciri ke dalam modul .py yang boleh diimport. Notebook memanggilnya. Ia tidak mendefinisikannya semula.
Pin kebergantungan dalam requirements.txt atau pyproject.toml. Bukan "apa sahaja yang ada pada laptop saya pada bulan Mac."
Parameterkan laluan dan tarikh. Tiada /Users/yourname/. Tiada 2024-Q3 berkod keras.
Gunakan fail konfigurasi atau pemboleh ubah persekitaran untuk apa-apa yang berubah antara dev dan pengeluaran.
Jalankan kod anda sendiri dalam persekitaran bersih sebelum anda serah. Jika ia rosak untuk anda pada pemasangan bersih, ia akan rosak untuk kejuruteraan.

Anda tidak memerlukan Kubernetes. Anda memerlukan kod yang boleh dijalankan oleh orang lain tanpa menjadualkan Zoom.

Perangkap 3: Melangkau Pemantauan Pengeluaran

Gejala. Model telah dihantar. Anda beralih ke projek seterusnya. Tiga bulan kemudian, tiket sokongan melonjak. Kejayaan pelanggan menjerit. Anda menghabiskan dua hari menggali dan mendapati model telah hanyut secara senyap sejak minggu empat.

Kos. Kajian industri secara konsisten menempatkan kemerosotan prestasi model pada 20-40% dalam tempoh 6-12 bulan untuk model perniagaan biasa tanpa latihan semula. Tingkah laku pelanggan berubah. Sumber data hulu mengubah skema tanpa memberitahu anda. Ciri produk baru mengubah taburan input. Tanpa pemantauan, anda mengetahui daripada orang yang terjejas: pelanggan dan pihak berkepentingan anda.

Pembetulan. Hantar dashboard pemantauan pada minggu yang sama anda menghantar model. Bukan "selepas sprint seterusnya." Minggu yang sama.

Jejak Population Stability Index (PSI) pada 5-10 ciri teratas anda. Beri amaran apabila PSI > 0.2.
Jejak taburan ramalan dari hari ke hari. Pergeseran mendadak dalam min atau bentuk adalah penunjuk awal.
Jejak KPI perniagaan yang diikat kepada model (kadar penukaran, kadar peralihan pelanggan, kadar tangkapan penipuan). Jika KPI hanyut, anda perlu tahu sebelum VP.
Tetapkan kadensi latihan semula. Suku tahunan adalah paras untuk kebanyakan model perniagaan, bulanan untuk apa-apa dalam domain yang bergerak pantas.
Letakkan nama dan kenalan anda pada dashboard. Miliki.

Model tanpa pemantauan adalah liabiliti, bukan aset. Anggaplah begitu.

Perangkap 4: Rekabentuk Berlebihan pada Ciri

Gejala. Saluran akhir anda mempunyai 200 ciri dan rantai prapemprosesan 12 langkah. AUC naik dari 0.81 ke 0.83. Anda bangga dengannya. Pihak berkepentingan anda tidak menyedari perbezaannya.

Kos. 180 ciri tambahan itu menggandakan masa latihan, melipattigakan permukaan kegagalan dalam pengeluaran (setiap ciri adalah potensi null, pecahan skema, atau insiden hulu), dan peningkatan yang anda "menang" berada dalam band hingar set ujian anda. Anda kini bertanggungjawab untuk menyelenggara saluran yang rapuh untuk peningkatan AUC 2% yang tiada siapa minta.

Pembetulan. Mulakan dengan ringkas. Tambah hanya apabila matematik membenarkannya.

Buka dengan 10-20 ciri. Yang akan dinamakan oleh pakar domain dalam mesyuarat.
Tambah ciri hanya apabila SHAP atau kepentingan permutasi menunjukkan ia membeli peningkatan >1% pada set tertahan.
Tambah ciri hanya apabila pihak berkepentingan mengambil berat tentang 1% itu. Jika 1% peralihan pelanggan adalah $50,000, baik. Jika $500, buangnya.
Setiap ciri yang anda tambah adalah janji penyelenggaraan. Jika anda tidak boleh berkomitmen untuk menyelenggaranya, jangan tambah.
Apabila ragu, ablasi. Buang ciri kepentingan terbawah dan lihat sama ada ada yang benar-benar rosak.

Bar DS Senior bukan "AUC tertinggi." Ia adalah "impak perniagaan tertinggi per unit kerumitan saluran."

Perangkap 5: Melaporkan AUC Tanpa Metrik Perniagaan

Gejala. Slaid bacaan anda berkata "AUC 0.87, F1 0.74, log loss 0.21." Pihak berkepentingan anda mengangguk dengan sopan. Mereka melupakan projek itu menjelang semakan suku tahunan seterusnya.

Kos. Sifar dollar langsung, tetapi projek berhenti mendapat pembiayaan kerana tiada siapa dapat menjelaskannya kepada VP. Anda telah membina sesuatu yang berfungsi dan tiada siapa tahu ia berfungsi. Enam bulan kemudian, apabila belanjawan semakin ketat, projek "yang kami tidak dapat benar-benar menyatakan nilainya" adalah yang pertama dipotong.

Pembetulan. Setiap laporan model dipimpin dengan metrik perniagaan. Sentiasa.

Buka dengan dollar atau KPI: "$2.1 juta dalam peralihan pelanggan diselamatkan pada ambang ini," "peningkatan ketepatan 14% melebihi enjin peraturan," "pengurangan 23% dalam caj balik penipuan."
Tunjukkan keluk pertukaran dalam istilah perniagaan. "Pada ambang 0.4, kita menangkap 80% penipuan dan menandai 3% transaksi sah. Pada ambang 0.6, kita menangkap 60% dan menandai 0.5%. Inilah kos setiap satu."
Ikat metrik kepada nombor yang pihak berkepentingan sudah ambil berat. Jika mereka hidup dengan ARR, frasa dalam ARR. Jika mereka hidup dengan NPS, frasa dalam NPS.
AUC, F1, dan log loss masuk dalam lampiran. Ia untuk anda dan pengulas DS anda, bukan VP.
Tamatkan dengan keputusan yang model membolehkan, bukan model itu sendiri.

Laporan model yang tidak dipimpin dengan nilai perniagaan adalah kemaskini status, bukan hasil.

Perangkap 6: Mengabaikan Kualiti Data pada Sumber

Gejala. Notebook anda mempunyai 400 baris kod pembersihan kerana "data itu tidak kemas." Anda telah menjelaskan ini dalam tiga standup terakhir. Anda mula memikirkan diri anda sebagai orang yang tahu di mana mayat-mayat dikuburkan dalam jadual peristiwa pelanggan.

Kos. Nombor lama IBM meletakkan kos data buruk pada $3.1 trilion setahun merentasi ekonomi AS. Pada peringkat syarikat, tinjauan secara konsisten menunjukkan pasukan DS menghabiskan 40-60% masa mereka untuk pembersihan. Itu masa anda. Gaji anda. Dan setiap peraturan pembersihan yang anda tulis dalam notebook anda adalah peraturan yang akan senyap reput kali seterusnya skema hulu berubah, kerana tiada siapa lain yang tahu ia wujud.

Pembetulan. Anggap setiap peraturan pembersihan sebagai laporan pepijat yang anda hutang kepada pasukan kejuruteraan data.

Failkan pepijat itu. Sekali. Dengan repro yang jelas dan impak ("ini mempengaruhi tiga model pengeluaran").
Berhenti memperbaikinya dalam notebook anda. Perbaiki hulu, dalam saluran sumber, di mana setiap pengguna hilir mendapat manfaat.
Tolak untuk kontrak data pada jadual yang anda bergantung kepada. Skema, kebolehnailan, SLA kesegaran, pemilik.
Jadikan kualiti data metrik bersama. Jika pasukan anda dan kejuruteraan data kedua-duanya mempunyai "kesegaran data" atau "kadar pecahan skema" pada dashboard, pembetulan berlaku lebih pantas.
Apabila kejuruteraan menolak balik ("bukan keutamaan suku tahun ini"), datang dengan kos dollar: jam DS yang terbuang, model yang merosot, keputusan yang disekat.

Pembetulan notebook adalah cukai yang anda bayar selamanya. Pembetulan hulu adalah pelaburan sekali sahaja. Bayarnya sekali.

Perangkap 7: Berkata "Model Baik, Data Salah" Tanpa Memperbaiki Data

Gejala. Anda telah menggunakan beberapa versi ayat ini dalam 3+ standup: "Model berfungsi. Data latihan sahaja yang buruk." Anda mengatakannya sekali lagi dalam semakan minggu lepas. Pihak berkepentingan diam.

Kos. Anda, khususnya. Dalam kira-kira enam bulan, pihak berkepentingan menghalau anda kepada DS yang "sebenarnya menghantar." Anda tidak dipanggil ke projek strategik seterusnya. Anda tidak mendapat perbualan promosi. Model yang "baik" adalah model yang tiada siapa percaya dalam pengeluaran, yang bermaksud ia tidak baik.

Pembetulan. Miliki saluran penuh. Titik.

Model adalah tanggungjawab anda, dan model itu termasuk data yang mempersiapkannya. Tiada garis bersih di mana "kerja anda" berhenti dan "kerja kejuruteraan data" bermula apabila output rosak.
Jika data salah, anda meningkat. Bukan dalam Slack suara pasif. Dalam e-mel dengan nama padanya dan tarikh akhir.
Tulis spesifikasi untuk apa "betul" kelihatan seperti. Julat numerik, kesegaran, skema. Jangan biarkan untuk tafsiran.
Duduk dalam semakan kejuruteraan apabila pembetulan sedang dilingkupkan. Pastikan mereka menyelesaikan masalah yang betul.
Jangan lepaskannya sehingga ia diperbaiki dalam pengeluaran dan disahkan dalam dashboard pemantauan anda.

"Bukan masalah saya" adalah ayat yang mengakhiri kerjaya pada peringkat ini. Model tidak baik jika ia tidak berfungsi dalam pengeluaran. Menjadikannya berfungsi dalam pengeluaran adalah kerja anda.

Corak di Bawah Semua Tujuh

Baca semula tujuh perangkap itu. Setiap satu adalah kesilapan yang sama.

Menganggap sains data sebagai kerja pemodelan dan bukannya kerja hasil perniagaan.

Perangkap 1 adalah "Saya fokus pada model, bukan keputusan." Perangkap 2 adalah "Saya fokus pada model, bukan serah terima." Perangkap 3 adalah "Saya fokus pada model, bukan apa yang berlaku selepas pelancaran." Empat adalah "model, bukan kos penyelenggaraan." Lima adalah "model, bukan dollar." Enam adalah "model, bukan data yang mempersiapkannya." Tujuh adalah "model, bukan sistem di sekelilingnya."

Bar DS Senior adalah "menghantar impak perniagaan yang boleh diukur." Bar IC2-selamanya adalah "menghasilkan model tepat yang tiada siapa gunakan." Lihat mana-mana DS yang mencapai Senior dalam 2-3 tahun dalam pasukan anda. Kemudian lihat yang telah menjadi IC2 selama empat tahun. Jurangnya hampir tidak pernah dalam matematik. Ia adalah sama ada mereka menganggap model sebagai hasil kerja, atau sebagai satu komponen sistem yang benar-benar perlu berfungsi untuk perniagaan.

Audit Diri

Jalankan ini terhadap 2-3 projek terakhir anda. Bersikap jujur. Tujuannya bukan untuk berasa sedih, ia untuk mengetahui di mana anda berada.

Untuk setiap projek, tanya:

Adakah saya menulis brief masalah satu halaman sebelum membuka notebook?
Adakah serah terima saya kepada kejuruteraan kod bersih dalam modul yang boleh diimport, bukan notebook dengan laluan berkod keras?
Adakah saya menghantar pemantauan pada minggu yang sama saya menghantar model?
Adakah saya memastikan ciri ringkas, menambah hanya apabila SHAP membenarkannya DAN pihak berkepentingan mengambil berat?
Adakah bacaan saya dipimpin dengan metrik perniagaan, dengan AUC dalam lampiran?
Adakah saya memfailkan isu kualiti data hulu, atau hanya membersihkannya dalam notebook saya?
Apabila data salah, adakah saya memiliki pembetulan dari hujung ke hujung?

Kira yang tidak.

0-1 tidak: Anda berada di landasan yang betul. Terus lakukan apa yang anda lakukan.
2-3 tidak: Betulkan sekarang. Pilih yang paling berdampak tinggi dan betulkan pada projek seterusnya.
4+ tidak: Adakan perbualan sebenar dengan pengurus anda minggu ini. Anda berada satu penstrukturan semula jauh dari pasukan yang kurang strategik dan anda mungkin sudah merasakannya.

Seperti Apa "Baik" Kelihatan

DS yang mencapai Senior dalam 2-3 tahun tidak lebih bijak daripada anda. Mereka hanya menghayati definisi kerja yang berbeza.

Mereka memulakan setiap projek dengan brief masalah, bukan notebook. Mereka menulis kod dari minggu pertama seolah-olah kejuruteraan akan menjalankannya pada hari Isnin. Mereka menghantar pemantauan pada minggu yang sama seperti model dan memeriksanya mingguan. Mereka memastikan ciri ringkas dan ablasi tanpa rasa sayang. Mereka memimpin bacaan dengan dollar, bukan AUC. Mereka memfailkan isu kualiti data hulu dan mengikutinya. Apabila data salah, mereka memiliki pembetulan sehingga ia digunakan.

Orang itu menghantar lebih sedikit notebook dan lebih banyak sistem impak perniagaan yang dihantar dan dipantau. Pihak berkepentingan menarik mereka ke projek strategik seterusnya sebelum yang semasa berakhir. Bungkusan promosi menulis sendiri, kerana setiap projek mempunyai cerita "saya menghantar X, ia mendorong Y dalam nilai perniagaan, inilah dashboard" yang bersih.

Anda boleh menjadi orang itu. Sebahagian besar jurangnya adalah tabiat, bukan kecerdasan.

Buku Panduan Data Scientist