Sehari dalam Kehidupan Data Scientist

Pukul 8:07 pagi. Telefon anda berdengung pada pukul 6:42 dengan amaran kemerosotan model dari MLflow. PM menghantar mesej langsung Slack pada pukul 7:55: "soalan cepat, mengapa pengguna ini ditandai sebagai peralihan pelanggan?" Anda belum pun membuka laptop. Selamat datang ke kerja yang tiada siapa menggambarkan dengan tepat di LinkedIn.

Perihalan kerja yang anda daftar menjanjikan "bina model ML, pandu penemuan, bermitra dengan pihak berkepentingan." Semua itu benar, secara teknikal. Nisbahnya tidak. Pada Selasa biasa di syarikat B2B SaaS, pembinaan model mungkin hanya seperempat hari anda. Kejuruteraan ciri dan pendaipan SQL menelan sebahagian besar lagi. Selebihnya adalah kerja terjemahan: menerangkan kepada VP mengapa ketepatan bukan kejituan, mempertahankan selang keyakinan kepada pemimpin jualan, menulis Loom yang tiada siapa tonton, dan mengingatkan pasukan platform bahawa ya, model dbt yang rosak setiap hari Rabu masih rosak setiap hari Rabu.

Ini bukan versi DS-senior-di-LinkedIn mengenai kerja tersebut. Ini yang sebenar. Jika anda tiga bulan ke dalam peranan dan minggu anda sama sekali tidak seperti peranan yang anda temuduga, itu bukan pepijat dalam diri anda. Itulah peranannya.

Inilah seperti apa Selasa yang sebenar.

8:00 hingga 8:30 pagi: Pemeriksaan prestasi model

Kopi di tangan, laptop terbuka, tab pertama sentiasa MLflow atau Weights & Biases. Anda mengimbas ramalan semalam berbanding label yang masuk semalaman. AUC model peralihan pelanggan turun dari 0.84 ke 0.79 sepanjang hujung minggu. Itu bukan malapetaka, tetapi cukup untuk disiasat sebelum standup.

Anda semak perkara yang jelas dahulu. Adakah taburan input berubah? Anda tarik dashboard hanyutan ciri. Dua ciri sedang hanyut. Satu adalah "hari sejak log masuk terakhir," yang masuk akal kerana pasukan produk menghantar aliran onboarding baru pada hari Jumaat dan banyak pengguna lama didorong kembali. Satu lagi adalah "tiket sokongan dalam 30 hari lepas," yang tidak mempunyai penjelasan yang jelas. Anda buat nota untuk menggali selepas standup.

Pemeriksaan tiga puluh minit ini adalah salah satu bahagian yang paling kurang dihargai dalam kerja. Separuh DS senior yang saya kenal dipromosikan berdasarkan kekuatan menangkap sesuatu di sini yang tiada orang lain akan tangkap. Model tidak rosak. Dunia yang dilatih oleh model itu rosak, sedikit, dan anda menyedarinya sebelum orang lain.

Anda juga semak larian eksperimen semalam dalam MLflow. Dua rakan sekerja anda memulakan kerja latihan pada pukul 11 malam. Satu menumpu. Satu terburai kerana seseorang menamakan semula lajur dalam jadual sumber tanpa memberitahu sesiapa. Selamat datang ke kerja data.

9:30 hingga 11:30 pagi: Rekabentuk eksperimen (90 minit berhujah tentang metrik)

PM masuk ke standup dengan soalan: "Adakah halaman harga baru menukar dengan lebih baik?" Mudah, kan? Saiz sampel, ujian dua-kadar, hantar.

Ia tidak pernah semudah itu.

Anda menghabiskan 90 minit dalam Hex untuk melingkupkan eksperimen. Matematik adalah bahagian yang mudah. Inilah yang sebenarnya menelan masa:

Menentukan "menang." PM ingin mengukur klik pada butang "Mulakan percubaan percuma." Anda menekankan bahawa klik bukan bermaksud mula, mula bukan bermaksud pengaktifan, dan pengaktifan bukan bermaksud penukaran berbayar. Apabila anda selesai, metrik kejayaan telah berubah tiga kali dan anda mempunyai metrik pelindung untuk pengekalan minggu pertama kerana corong halaman harga lama mempunyai kebocoran yang diketahui selepas pengaktifan.

Semakan kenyataan pengiraan kuasa. Dengan trafik mingguan semasa anda, mengesan peningkatan relatif 3% dalam penukaran berbayar memerlukan menjalankan ujian selama enam minggu. PM mahukan keputusan dalam dua minggu. Anda bersetuju dengan metrik proksi yang lebih bising (permulaan percubaan) untuk bacaan awal dan metrik sebenar (penukaran berbayar) untuk keputusan akhir.

Metrik pelindung. Bagaimana jika halaman baru meningkatkan permulaan percubaan tetapi menjejaskan kualiti percubaan tersebut? Anda tambah pelindung pada kadar pengaktifan. Bagaimana jika ia mengubah campuran pilihan peringkat rancangan? Anda tambah pelindung pada purata hasil setiap pelanggan baru. Kini terdapat tiga metrik, dua pelindung, dan peraturan berhenti.

Komitmen pra-pembahagian. PM bertanya sama ada anda boleh "hanya menghiris mengikut saiz syarikat selepas." Anda berkata tidak, dan kemudian ya, tetapi hanya dengan pembetulan Bonferroni dan senarai segmen yang ditulis sebelum ujian bermula. Anda tulis senarai bersama. Ini akan menyelamatkan kerja seseorang kemudian.

Anda menerbitkan dokumen rekabentuk eksperimen ke ruang kerja Hex pasukan, menautkan dalam halaman Notion projek, dan tag PM dan ketua kejuruteraan. Matematik mengambil masa 15 minit. Perbualan mengambil masa 75 minit. Nisbah itu lebih kurang betul untuk selebihnya kerjaya anda.

12:30 hingga 2:00 petang: Async dengan kejuruteraan pada penempatan pengeluaran

Anda menelan makan tengah hari di meja. Blok petang adalah yang paling mengecewakan Data Scientist baru: model anda telah "sedia untuk dihantar" selama tiga minggu, dan halangan tidak ada kena mengena dengan model.

Model itu sendiri baik. Masalahnya adalah saluran ciri. Model peralihan pelanggan anda memerlukan ciri yang dipanggil weighted_engagement_30d, iaitu jumlah berwajaran log masuk, penghantaran mesej, dan kehadiran mesyuarat selama 30 hari lepas. Ciri itu dikira dalam model dbt yang dipanggil fct_user_engagement_daily. Model dbt rosak setiap hari Rabu pagi antara pukul 6 dan 7 pagi Pasifik kerana ia bergantung kepada penyegerakan Salesforce yang siap dengan tidak konsisten.

Anda tidak memiliki model dbt itu. Pasukan kejuruteraan analitik yang memilikinya. Mereka tahu ia tidak stabil. Mereka mempunyai tiket untuk itu. Mereka mempunyai tiket selama dua bulan.

Jadi kerja hari ini adalah untuk menulis ulasan PR yang panjang pada penempatan pementasan. Anda terangkan:

Saluran ciri mempunyai tetingkap kegagalan mingguan yang diketahui
Model anda memerlukan ciri dengan ketinggian paling banyak 24 jam
Pemantauan semasa pada model dbt berlepas selepas ciri sudah ketinggalan
Anda ingin pasukan platform sama ada membaiki model dbt hulu atau menyambungkan sandaran yang menggunakan syot kilat terakhir yang baik dari ciri dengan bendera kesegaran

Anda tag ketua pasukan platform, tautkan amaran pemantauan dbt dari hari Rabu lepas sebagai bukti, dan tautkan dokumen keperluan kesegaran model anda. Anda tidak meningkat. Anda tidak merungut. Anda tinggalkan ulasan PR yang tenang dan spesifik dengan tiga pilihan yang disusun mengikut keutamaan anda dan cadangan lalai. Kemudian anda tutup tab.

Ini adalah bahagian kerja yang JD panggil "kerjasama merentas fungsi." Ia kebanyakannya menunggu, dengan advokasi tenang yang berselang-seli, untuk sesuatu yang tidak dapat anda baiki untuk dibaiki oleh orang lain. Berdamai dengannya dari awal.

2:00 hingga 3:00 petang: Mesyuarat "ramalan ini salah"

Pemimpin jualan telah menempah tiga puluh minit dalam kalendar anda. Baris subjek: "Berbual pantas tentang model peralihan pelanggan, salah seorang pelanggan yang ia tandai baru sahaja memperbaharui selama tiga tahun."

Anda tahu bagaimana ini akan berlaku. Anda telah mengadakan mesyuarat ini kira-kira empat belas kali sejak anda memulakan. Anda mempunyai skrip. Inilah bentuk kasarnya:

Buka dengan ingin tahu, bukan bertahan. "Ceritakan tentang pelanggan itu. Apakah cerita mereka?" Anda biarkan pemimpin jualan meluahkan perasaan selama lima minit tentang bagaimana model akan mempermalukan pasukan, bagaimana pelanggan akan tersinggung jika mereka tahu, dan bagaimana mereka mempunyai perasaan model tidak boleh dipercayai pun.

Bingkai semula metrik tanpa membuat mereka berasa bodoh. "Model meramalkan pada ketepatan 87% pada kohort 'risiko peralihan pelanggan tinggi.' Itu bermaksud daripada setiap 100 akaun yang ditandai oleh model, kira-kira 87 benar-benar berpindah dalam 90 hari. 13 yang lain tidak. Akaun ini adalah salah satu daripada 13 itu. Itu bukan kegagalan model. Itu model yang berprestasi tepat seperti yang direka bentuk."

Bawa dashboard Looker, bukan nada bertahan. Anda kongsi skrin dan tarik Looker prestasi model peralihan pelanggan. Anda tunjukkan keluk ketepatan-ingatan semula. Anda tunjukkan bahawa menurunkan ambang untuk menangkap lebih banyak peralihan pelanggan akan bermaksud lebih banyak positif palsu, dan menaikkannya akan terlepas peralihan pelanggan sebenar. Anda tunjukkan nilai dollar peralihan pelanggan yang ditangkap suku tahun lepas ($2.4 juta) berbanding nilai dollar positif palsu jika setiap akaun yang ditandai pergi (jauh lebih tinggi daripada itu, tetapi mereka tidak perlu tahu).

Tutup dengan apa model itu untuk, dalam bahasa mereka. "Model ini adalah alat triage. Ia bukan keputusan muktamad. Ia memberitahu pasukan anda di mana hendak menghabiskan jam pertama minggu mereka. Hakikat bahawa satu akaun yang ditandai diperbaharui bermaksud pasukan anda melakukan kerja mereka. Mereka campur tangan. Itu adalah syarat kemenangan."

Pemimpin jualan meninggalkan panggilan dengan lebih tenang berbanding semasa mereka datang. Anda tambah perbualan ke log eksperimen. Anda tambah slaid ke segerak DS-ke-Jualan bulanan seterusnya yang dipanggil "Ketepatan bukan Kejituan" kerana jika anda telah mengadakan perbualan ini 14 kali, selebihnya organisasi jualan telah mengalaminya lebih kerap daripada yang mereka akui.

4:00 hingga 5:30 petang: Pembersihan notebook dan log eksperimen

Blok terakhir hari ini adalah kembali dalam Jupyter. Anda buka notebook analisis dari penglingkupan eksperimen halaman harga pagi tadi. Ia bersepah. Separuh daripadanya adalah kod lakaran. Terdapat sel yang hanya berbunyi df.head() tanpa ulasan. Terdapat carta tanpa label paksi. Terdapat pertanyaan SQL terhadap skema yang salah.

Anda membersihkannya. Disiplin di sini lebih penting daripada kecantikan. Anda tidak menjadikannya cantik untuk diri sendiri. Anda menjadikannya boleh dibaca untuk versi diri anda tiga bulan lagi yang perlu ingat mengapa anda memilih saiz sampel 4,200 dan bukan 5,000. Konvensyen dalam pasukan anda:

Sel markdown atas-notebook dengan soalan, tarikh, dan kesimpulan
Setiap bahagian mempunyai pengepala markdown satu baris di atas kod
Carta mempunyai tajuk, label paksi, dan tafsiran satu ayat di bawah
Sel terakhir adalah sel markdown dengan cadangan dan tindakan seterusnya

Anda komit notebook ke repo pasukan. Anda tulis ringkasan 200 perkataan dalam log eksperimen pasukan, yang tinggal dalam halaman Notion yang dikongsi. Anda juga push perubahan model dbt yang anda tulis pagi tadi. Ia dalam cabang berasingan dan ditag untuk semakan esok.

Perkara terakhir sebelum anda tutup laptop: anda semak nota mesyuarat pemimpin jualan dari pukul 2 petang dan tambah TODO ke backlog pasukan. "Bina dashboard Looker yang menghadap jualan yang menunjukkan ketepatan dan ingatan semula model peralihan pelanggan dalam bahasa mudah, dikemas kini mingguan." Ini kali ketiga anda memikirkan tentang membinanya. Mungkin minggu ini anda akan melakukannya.

Apa yang JD tidak akan beritahu anda

Beberapa perkara yang JD akan luputkan yang berbaloi diketahui pada hari pertama.

Anda akan menulis lebih banyak SQL daripada Python. Snowflake atau BigQuery akan menjadi bahasa kedua anda. Semakin bersih SQL anda, semakin pantas gelung lelaran anda. Kebanyakan kesesakan dalam minggu anda bukan pemodelan. Ia adalah "data belum dalam bentuk yang betul lagi."

Kejuruteraan ciri menelan 40% masa pemodelan anda. Model XGBoost mengambil masa 20 minit untuk dilatih. Ciri yang masuk ke dalamnya mengambil masa dua minggu untuk dibina, disahkan, dan disambungkan ke dalam saluran. DS baru meremehkan ini setiap kali.

Masalah "ML" yang paling sukar biasanya pihak berkepentingan yang tidak mempercayai output. Anda boleh mempunyai model yang dikalibrasi dengan indah dengan AUC bernilai penerbitan dan sifar impak, kerana tiada siapa yang akan bertindak atasnya. Kepercayaan dibina melalui penjelasan yang boleh diulang, dashboard dalam bahasa pihak berkepentingan, dan hadir di mesyuarat "ramalan ini salah" dengan tenang.

Panik "ramalan ini salah" adalah peristiwa mingguan. Sediakan skrip. Bawa dashboard. Jangan bertahan. Perbualan itu adalah kerja, bukan gangguan dari kerja.

Penempatan pengeluaran lebih perlahan daripada yang anda fikir. Bukan kerana kod sukar. Kerana kebergantungan data tidak stabil, persekitaran pementasan adalah cermin pengeluaran suku tahun lepas, dan pasukan platform juga melakukan yang terbaik mereka.

Alat yang akan anda gunakan sebenarnya

Tumpukan berbeza mengikut syarikat, tetapi bentuknya konsisten. Pada kebanyakan kedai B2B SaaS dengan fungsi DS sebenar pada tahun 2026:

Python dan Jupyter untuk analisis dan pemodelan. Beberapa pasukan telah memindahkan kerja yang lebih berat ke VS Code dengan notebook-sebagai-fail-peratus, tetapi Jupyter masih lalai untuk penerokaan.
SQL pada Snowflake atau BigQuery untuk semua yang menyentuh data pengeluaran. Jika anda datang dari tempat yang menggunakan Postgres terus, model mental gudang data adalah berbeza, dan anda akan memikirkan kos setiap pertanyaan buat kali pertama.
dbt untuk transformasi. Anda akan membaca lebih banyak model dbt daripada yang anda tulis, tetapi anda akan menulis beberapa.
MLflow atau Weights & Biases untuk penjejakan eksperimen. Kebanyakan pasukan mempunyai satu atau yang lain; hampir tidak penting mana satu.
Hex untuk notebook kolaboratif yang PM dan penganalisis boleh baca. Hex melakukan untuk analitik apa yang Figma lakukan untuk reka bentuk.
Looker untuk dashboard yang menghadap pihak berkepentingan. Dashboard yang anda bina di sini adalah perkara yang pihak berkepentingan anda nilai anda, walaupun model di belakang mereka adalah kerja sebenar.
Pilihan tetapi biasa: Airflow, Prefect, atau Dagster untuk orkestrasi. Anda mungkin atau mungkin tidak memiliki ini.

Anda tidak akan menggunakan semua ini pada setiap pasukan. Anda mungkin akan mempelajari yang baru dalam 90 hari pertama anda.

Seperti apa "baik" selepas 90 hari

Jika anda baru dalam peranan, inilah definisi kejayaan yang berguna pada tanda tiga bulan. Lupakan kiraan model. Cari ini:

Anda boleh menamakan soalan sebenar tiga pihak berkepentingan teratas anda, dalam bahasa mereka, tanpa dokumen di hadapan anda.
Anda mempunyai satu model dalam pengeluaran. Walaupun yang kecil. Walaupun regresi logistik pada satu ciri. Pengeluaran mengalahkan notebook.
Anda telah berhenti terkejut apabila pihak berkepentingan menghantar mesej anda dengan "ramalan ini salah." Anda mempunyai skrip. Anda bawa dashboard.
Anda tahu model dbt mana yang rosak setiap minggu dan ciri mana yang tidak stabil. Anda telah berhenti terkejut dengan kerosakan hari Rabu.
Anda telah menulis sekurang-kurangnya satu dokumen yang DS lain dalam pasukan telah tautkan. Pengetahuan yang berganda mengalahkan analisis yang dilupakan.

Itulah barnya. Ia bukan "menghantar lima model" atau "menggandakan kelajuan pasukan." Metrik tersebut tidak bertahan apabila berhadapan dengan realiti. Senarai di atas bertahan.

Pembahagian 50/50 antara kerja teknikal dan kerja terjemahan bukan kecacatan dalam peranan. Itulah peranannya. Terjemahan bukan di bawah pemodelan. Itulah cara pemodelan sebenarnya mengubah sesuatu. DS yang condong ke arah itu lebih awal berbanding rakan sebaya mereka adalah yang dipromosikan ke Senior dalam 18 bulan dan bukannya 30 bulan.

Amaran kemerosotan model pada pukul 6:42 pagi akan berbunyi semula esok. Makan sarapan dahulu.

Buku Panduan Data Scientist