AI dalam Aliran Kerja Data Scientist: Apa yang Perlu Diautomasikan, Apa yang Tidak Boleh Disentuh

Kali pertama Copilot mengarang nama lajur yang salah pada saya, model itu tetap dilatih. Pull request menggabungkan customer_id dengan lajur bernama customer_uuid yang tidak wujud dalam jadual sebelah kanan. Pandas melakukan apa yang selalunya dilakukan oleh pandas: menghasilkan NaN untuk setiap baris secara senyap, tanpa sebarang ralat, dan gabungan itu "berjaya." Model hilir mengepas dengan baik. AUC pengesahan kelihatan normal. Saya menyedarinya tiga hari kemudian hanya kerana pihak berkepentingan bertanya mengapa kumpulan tertentu hilang dari output.

Tiada siapa yang memberi amaran tentang mod kegagalan itu. Pemasaran untuk sains data berbantukan AI penuh dengan demo di mana model menulis pd.merge yang sempurna terhadap dataset mainan yang bersih. Mod kegagalan sebenar adalah senyap. Kod berjalan, keputusan kelihatan munasabah, dan pepijat muncul setelah anda telah membentangkan carta tersebut.

Jadi inilah garis yang telah saya tetapkan setelah kira-kira lapan belas bulan menggunakan alat-alat ini setiap hari, ditulis untuk Data Scientist yang sedang bekerja yang sudah jemu dengan lebih-hype dan penolakan refleks. Kedua-dua hujung melampau itu salah. Ada jalan tengah yang membolehkan penghantaran lebih pantas tanpa kualiti model merosot, dan panduan ini cuba menghuraikannya secara konkrit.

Mengapa ini penting sekarang (dan mengapa kebanyakan kandungan "AI dalam DS" mengelirukan)

Terdapat dua perkara yang sangat berbeza yang dimaksudkan orang apabila mereka berkata "AI dalam sains data," dan mencampurkan kedua-duanya menghasilkan nasihat yang tidak konsisten.

Yang pertama ialah AI sebagai pempercepar aliran kerja untuk kerja sains data sedia ada: kod boilerplate, skrip EDA, docstrings, draf slaid. Inilah yang dilakukan oleh Copilot IDE, Cursor, dan Claude anda. Kerja itu masih membina model dan menerangkannya. AI adalah mesin taip yang lebih pantas.

Yang kedua ialah membina aplikasi berkuasa LLM: sistem RAG, saluran ejen, harness penilaian untuk output generatif. Ini adalah kerja yang berbeza. Kemahiran bertindih (anda masih memerlukan statistik, anda masih perlu memikirkan penilaian), tetapi mod kegagalan, rantai alat, dan kerja harian berbeza daripada melatih model XGBoost.

Apabila pihak pengurusan berkata "tambah AI ke dalam aliran kerja anda," mereka biasanya bermaksud yang pertama. Apabila pengurusan berkata "bina ciri AI," mereka biasanya bermaksud yang kedua. Jika anda tidak memisahkan ini, anda akan membuang suku tahun cuba menggunakan corak RAG untuk masalah ramalan peralihan pelanggan, atau lebih teruk, anda akan menghantar chatbot menggunakan intuisi XGBoost dan tertanya-tanya mengapa penilaian anda tidak berfungsi.

Selebihnya panduan ini kebanyakannya tentang yang pertama. Ada bahagian di penghujung tentang yang kedua.

Di mana AI benar-benar membantu (gunakan setiap hari)

Inilah tempat saya membiarkan AI menulis draf pertama setiap hari, dengan semakan ringan:

Kod boilerplate. Susun semula Pandas yang telah saya tulis ratusan kali: pivot, melt, rantai groupby. Perancah Pipeline dan ColumnTransformer sklearn. Grid subplot Matplotlib. Bahan mekanikal di mana strukturnya tetap dan hanya nama lajur yang berbeza. Cursor atau Copilot akan mendapatkannya betul 90% daripada masa, dan 10% yang salah mudah dikesan kerana anda sudah tahu seperti apa outputnya.

Skrip EDA. Plot taburan laluan pertama, kiraan null, heatmap korelasi, kiraan nilai pada setiap kategorikal. Laluan "beri saya bentuk dataset ini." AI bagus untuk ini kerana coraknya berformula dan outputnya visual, jadi anda akan nampak jika ada yang kelihatan tidak betul. Saya masih menulis EDA laluan kedua sendiri, kerana di sanalah pemikiran sebenar berlaku.

Docstrings dan petunjuk jenis. Apabila anda sudah tahu apa yang dilakukan oleh fungsi dan anda hanya perlu mendokumentasikannya. Sorot fungsi, minta "tulis docstring gaya numpy dengan contoh," dan semak. Jimat dua puluh minit setiap modul pada asas kod sebenar.

Draf slaid dan ringkasan untuk pihak berkepentingan. Draf pertama sahaja. Saya tulis perenggan poin peluru tentang apa yang dilakukan model dan apakah hasilnya, kemudian minta Claude mengubahnya menjadi tiga slaid untuk penonton bukan ML. Kemudian saya tulis semula kira-kira 60% daripadanya. Draf pertama adalah bahagian membosankan: struktur, peralihan, pengulangan untuk penekanan. Penulisan semula adalah di mana saya menambah bahagian yang benar-benar penting.

Ringkasan kajian literatur. Saya masukkan lima abstrak kertas kerja dan tanya "yang mana berkaitan untuk meramal peralihan pelanggan dari data strim peristiwa, dan apakah kaedah teras dalam setiap satu?" Outputnya adalah senarai triage. Kemudian saya baca kertas yang benar-benar perlu saya baca. Ini adalah rumusan, bukan tafsiran, dan ia berfungsi kerana ia boleh disahkan. Jika ringkasan mengatakan kertas 3 menggunakan transformer, saya boleh semak.

Corak merentasi semua ini: AI bagus untuk bahagian di mana anda sudah tahu seperti apa "betul," jadi anda boleh mengesan kesilapan. Ia adalah pempercepar taip, bukan pengganti pemikiran.

Di mana AI rosak (jangan pernah wakilkan)

Inilah bahagian-bahagian yang tidak akan saya biarkan AI sentuh, dan saya akan terangkan mengapa untuk setiap satu:

Inferens sebab-akibat. Pemboleh ubah perancu, kecenderungan pemilihan, strategi pengenalpastian, soalan sama ada pekali regresi bermaksud sesuatu yang sebab-akibat. LLM dengan senang hati akan menulis model skor kecenderungan untuk soalan yang memerlukan rekabentuk perbezaan-dalam-perbezaan. Mereka tidak tahu proses penjanaan data anda. Mereka tidak tahu pemboleh ubah mana yang pasca-rawatan. Mereka tidak tahu bahawa "kumpulan kawalan" anda dipilih berdasarkan hasil. Tuntutan sebab-akibat yang salah dengan yakin lebih teruk daripada tiada tuntutan, dan AI sangat pandai untuk salah dengan penuh keyakinan tentang perkara ini.

Keputusan pemodelan. Algoritma mana yang digunakan, fungsi kehilangan mana, skema pengesahan mana, cara mengendalikan kebocoran. Ini adalah pertimbangan yang bergantung kepada konteks perniagaan, bentuk data, dan apa yang model itu untuk. Copilot akan mencadangkan random forest untuk segalanya kerana random forest paling kerap muncul dalam data latihan. Ia tidak tahu bahawa masalah anda mempunyai kebocoran temporal yang merosakkan setiap skema pengesahan silang kecuali forward-chaining. Anda perlu membuat keputusan-keputusan ini sendiri.

Tafsiran ciri. Apa yang nilai SHAP bermaksud dalam konteks perniagaan ini. AI boleh menjana plot SHAP. Ia boleh menggambarkan apa itu nilai SHAP secara abstrak. Ia tidak boleh memberitahu anda sama ada "tempoh mempunyai nilai SHAP yang tinggi" bermaksud tempoh itu penting secara sebab-akibat atau hanya bahawa tempoh merangkumi sesuatu yang lain yang tidak anda ukur. Itu memerlukan pengetahuan perniagaan.

Pembingkaian perniagaan. Menterjemahkan "model mengatakan kebarangkalian peralihan pelanggan adalah 0.73 untuk segmen ini" kepada "kita perlu mengubah kadensi pembaharuan untuk akaun melebihi $50k." Itu adalah terjemahan membuat keputusan, dan melakukan kesilapan adalah cara sains data kehilangan kredibiliti. LLM tidak tahu apakah toleransi risiko syarikat anda. Ia tidak tahu pihak berkepentingan mana yang skeptikal tentang kerja data dan memerlukan bukti tambahan. Ia tidak tahu bahawa kali terakhir anda mencadangkan campur tangan serupa ia gagal.

Singkatannya: AI baik untuk apa. Jangan gunakan untuk mengapa atau implikasinya.

Tumpukan alat yang benar-benar berfungsi

Setelah mencuba kebanyakannya, inilah tumpukan yang saya gunakan untuk Data Scientist yang sedang bekerja pada tahun 2026:

Cursor untuk kod. Ia adalah VS Code dengan integrasi LLM yang lebih baik. Ciri Composer (di mana anda menggambarkan perubahan berbilang fail dan membiarkannya mencadangkan suntingan) benar-benar berguna untuk memfaktor semula saluran ciri merentasi tiga fail. Saya biarkan pelengkap automatik untuk boilerplate dan matikannya apabila saya sedang memikirkan logik. Pertukaran mod itu penting.

Claude (atau setara) untuk semakan kod. Sebelum saya membuka PR, saya tampal perbezaan ke dalam Claude dengan arahan seperti: "Semak ini untuk ketepatan, bukan gaya. Fokus pada: rujukan lajur, ralat off-by-one, kebocoran, API yang lapuk, dan kes tepi pada pengendalian null." Ia menangkap perkara-perkara. Tidak selalu, tetapi cukup kerap sehingga saya terus melakukannya. Ia adalah pasangan mata kedua yang tersedia pada jam 11 malam sebelum tarikh akhir.

AI dalam notebook (Hex Magic, Deepnote AI) dengan kawalan ketat. Ini bagus untuk laluan EDA: "tunjukkan saya taburan setiap lajur numerik" atau "cari korelasi melebihi 0.7." Saya tidak membiarkan mereka menulis analisis akhir. Kawatan ketat itu adalah peraturan bahawa apa sahaja yang mereka hasilkan dijalankan semula dalam notebook bersih sebelum meninggalkan laptop saya, dan saya membaca setiap baris SQL yang dihasilkan. Kemudahannya adalah nyata, kepercayaannya terbatas.

Sebab sepasang alat mengalahkan alat tunggal: setiap satu mempunyai titik buta yang berbeza. Cursor bagus untuk konteks tempatan (fail yang anda sedang kerjakan) tetapi lemah dalam memahami bagaimana data anda sebenarnya kelihatan. Claude bagus untuk penaakulan peringkat lebih tinggi ("adakah ini masuk akal?") tetapi tidak mempunyai konteks IDE anda. Alat notebook bagus untuk periksa data pantas tetapi cenderung menulis kod buang. Anda mahukan alat berbeza untuk kerja berbeza, bukan satu alat yang cuba melakukan ketiga-tiganya dengan buruk.

Perangkap "LLM menulis analisis"

Ini adalah kegagalan yang paling kerap saya lihat pada DS junior dan pertengahan, dan semakin kerap pada DS senior yang sepatutnya lebih tahu.

Coraknya: anda selesai pemodelan, anda mempunyai jadual keputusan, anda tampalnya ke dalam ChatGPT, dan anda minta "ringkaskan penemuan utama." Ia menulis naratif yang yakin, jelas, dan tersusun dengan baik. Anda suntingnya sedikit, tampalnya ke dalam laporan, dan hantar.

Masalahnya ialah LLM itu membuat padanan corak kepada bunyi seperti apa kesimpulan sains data biasanya, bukan kepada apa yang data anda sebenarnya tunjukkan. Ia akan mengatakan perkara seperti "model menunjukkan prestasi ramalan yang kukuh, dengan kepentingan ciri mencadangkan bahawa penglibatan pelanggan adalah pemacu utama." Ayat itu betul dari segi struktur dan mungkin sepenuhnya palsu. Model mungkin berprestasi baik hanya pada ciri bocor. "Penglibatan pelanggan" mungkin penting hanya kerana ia hampir menduplikasi sasaran.

Ini adalah setara moden dengan p-hacking. P-hacking adalah tentang mencari cerita yang sesuai dengan data melalui carian yang cukup. Perangkap analisis LLM adalah tentang mendapatkan cerita yang ditulis kepada data tanpa menyemak sama ada ia benar. Ceritanya munasabah, prosanya bersih, dan tuntutan asasnya salah.

Cara untuk tahu bila anda telah terjatuh ke dalamnya: jika anda tidak boleh, baris demi baris, menunjuk kepada nombor tertentu dalam keputusan yang menyokong setiap ayat dalam ringkasan, anda berada dalam perangkap itu. Penyelesaiannya adalah menulis analisis sendiri, kemudian minta LLM untuk menyunting untuk kejelasan. Menyunting draf yang anda tulis adalah berbeza secara asas daripada menghasilkan draf dari nombor, walaupun kiraan perkataan akhir adalah sama.

AI untuk ML berbanding membina aplikasi LLM

Penjelasan ringkas kerana ini sentiasa mengelirukan perbualan pasukan.

Data Scientist menggunakan Copilot untuk membina model peralihan pelanggan sedang melakukan ML klasik dengan IDE berbantukan AI. Modelnya adalah XGBoost atau rangkaian neural. Penilaiannya adalah AUC, kalibrasi, kesan terhadap perniagaan. Pengerahannya adalah kerja pemarkahan kelompok atau API masa nyata. Mod kegagalan adalah kebocoran, hanyutan model, dan kalibrasi salah.

Data Scientist membina sistem RAG atau ejen LLM sedang melakukan sesuatu yang berbeza. "Model" adalah model asas yang tidak anda latih. Penilaian adalah kualitatif atau berasaskan hakim LLM, bukan AUC. Pengerahan adalah perkhidmatan dengan templat arahan, indeks pengambilan semula, dan penjaga. Mod kegagalan adalah halusinasi, suntikan arahan, dan pusing gila kos.

Kedua-duanya adalah kerja yang sah. Kedua-duanya boleh ada di meja Data Scientist. Tetapi ia bukan kemahiran yang sama, dan DS senior yang hebat dalam yang pertama mungkin sederhana dalam yang kedua sehingga mereka memasukkan reputasi. Apabila pengurusan berkata "tambah AI ke dalam produk," tanya mereka yang mana satu yang mereka maksudkan. Jika mereka tidak tahu, itulah perbualan pertama, bukan tugas pengekodan.

Penandaan ACE Framework pilihan

Jika pasukan anda menggunakan ACE Framework (Ingest, Analyze, Predict, Generate, Execute), kebanyakan kerja DS klasik berada di Analyze dan Predict. Membina aplikasi LLM berada di Generate. Ini bukan sekadar perbendaharaan kata. Ia adalah cara untuk menolak balik apabila skop merayap. Apabila PM bertanya "bolehkah anda tambah ciri AI generatif ke model peralihan pelanggan," anda boleh berkata: "model peralihan pelanggan adalah keupayaan Predict; apa yang anda huraikan adalah keupayaan Generate, yang merupakan sistem berbeza dengan penilaian berbeza. Jom lingkupkan secara berasingan." Rangka kerja memberi anda perkataan untuk sempadan yang anda sudah tahu wujud.

Pelan penggunaan 30 hari

Inilah pelan yang akan saya jalankan jika saya memulakan semula, atau memperkenalkan DS junior kepada kerja berbantukan AI:

Minggu 1: Boilerplate dan docstrings sahaja. Pasang Cursor dan buka akaun Claude. Gunakan hanya untuk penyelesaian kod pada tugas mekanikal (susun semula pandas, saluran sklearn) dan untuk menulis docstrings pada fungsi yang telah anda tulis. Simpan nota berterusan (hanya fail teks) setiap kali cadangan itu salah. Menjelang akhir minggu, anda sepatutnya mempunyai sekitar 20 contoh mod kegagalan khusus untuk asas kod anda. Ini adalah data kalibrasi. Ia memberitahu anda bila hendak mempercayai alat dan bila hendak mengabaikannya.

Minggu 2: Tambah bantuan EDA. Pilih satu projek selesai di mana anda sudah tahu apa yang EDA sepatutnya tunjukkan. Jalankan semula laluan EDA menggunakan bantuan AI dan bandingkannya dengan kerja asal anda. Perhatikan khususnya apa yang AI terlepas (ia sering terlepas perkara kontekstual, seperti "pemboleh ubah ini kelihatan normal tetapi sebenarnya adalah kebocoran dari masa depan") dan apa yang ia tangkap lebih pantas daripada anda. Menjelang akhir minggu, anda sepatutnya mempunyai peraturan bertulis untuk bila EDA AI berguna dan bila tidak.

Minggu 3: Gelung semakan kod. Untuk setiap PR yang anda buka, tampal perbezaan ke dalam Claude terlebih dahulu dengan arahan semakan kod. Log: berapa banyak PR mendapat komen berguna dari Claude? Berapa banyak pepijat Claude tangkap yang pengulas pasukan anda akan terlepas? Berapa banyak positif palsu? Selepas seminggu anda akan mempunyai pemahaman sama ada gelung ini berbaloi. Bagi saya, ia berbaloi, tetapi kalibrasi adalah per-pasukan.

Minggu 4: Tulis dokumen "di mana kita gunakan AI / di mana kita tidak" pasukan. Satu halaman. Senaraikan tugas-tugas di mana AI adalah alat lalai. Senaraikan tugas-tugas di mana AI dilarang. Senaraikan tugas-tugas di mana AI dibenarkan tetapi setiap output mendapat semakan manusia sebelum digabungkan. Dapatkan kelulusan dari pengurus anda. Tujuan menulisnya adalah ia memaksa perbualan, yang mendedahkan perselisihan yang anda tidak tahu wujud.

Perangkap biasa

Senarai pendek, disusun mengikut kekerapan saya melihatnya meletup dalam pengeluaran:

Mempercayai nama lajur yang dihallusinasikan. Sentiasa semak bahawa lajur yang dirujuk dalam kod yang dijana AI wujud dalam dataframe. df.columns.tolist() adalah rakan anda.
Menerima cadangan model tanpa pendapat kedua. Jika Copilot berkata "gunakan random forest di sini," tanya diri sendiri mengapa, dan tanya Claude secara berasingan untuk mengkritik pilihan itu. Perselisihan adalah maklumat.
Membiarkan AI menulis ringkasan eksekutif. Sudah dibincangkan. Jangan.
Menggunakan LLM untuk tuntutan sebab-akibat. Mereka akan memberi anda jawapan yang yakin. Jawapan itu tidak berkorelasi dengan kebenaran.
Melupakan bahawa tetingkap konteks arahan memotong dataframe anda. Jika anda tampal sampel 50 baris dan tanya "adakah ada corak outlier," LLM hanya melihat 50 baris. Ia tidak akan tahu tentang ekor panjang. Nasihat yang diberikannya akan salah untuk data penuh.
Menghantar arahan yang sama merentasi projek tanpa penalaan semula. Asas kod anda mempunyai konvensyen. Arahan semakan kod generik tidak menangkap corak khusus pasukan anda.

Templat dan alat

Kit pemula yang berfungsi:

Fail peraturan Cursor untuk kerja DS. Memberitahu Cursor tentang konvensyen pasukan anda: versi sklearn yang anda gunakan, bahawa anda menggunakan Polars bukan pandas (atau sebaliknya), bahawa semua ciri memerlukan komen kebocoran.
Templat arahan semakan kod Claude. "Semak perbezaan ini untuk: ketepatan rujukan lajur, kebocoran, API yang lapuk, kes tepi pada null, dan konsistensi dengan selebihnya asas kod. Jangan komen tentang gaya."
Dasar penggunaan AI satu halaman. Dokumen Google literal satu halaman yang pasukan anda tandatangani. Tiga lajur: tugas, AI dibenarkan?, semakan diperlukan? Gantungnya di saluran pasukan anda.
Senarai semak pengesahan EDA. Apabila AI menjana EDA, jalankan melalui: adakah ia mengira null dengan betul? Adakah ia menangkap kategorikal dengan 10,000 nilai unik? Adakah ia memperhatikan lajur tarikh dengan isu zon waktu? Jika ia terlepas mana-mana ini, selebihnya outputnya adalah meragukan.

Mengukur sama ada ini berfungsi

Tiga isyarat, mengikut urutan kepentingan:

Masa ke model pertama pada dataset baru turun secara ketara. Jika DS junior biasanya mengambil tiga hari untuk sampai ke model asas dan kini mengambil satu hari, itulah kemenangan yang anda cari. Jika masa tidak turun, anda sebenarnya tidak menggunakan AI untuk bahagian yang ia bantu.
Komen semakan PR tentang "lajur salah" atau "API lapuk" turun ke sifar. Ini adalah pepijat mudah. Jika ia masih muncul, gelung semakan kod dalam Minggu 3 tidak menangkapnya.
Pasukan mempunyai dasar bertulis dan merujuknya. Bukan sekadar dokumen yang wujud, tetapi dokumen yang disebut dalam PR dan semakan reka bentuk. "Kita tidak menggunakan AI untuk ini kerana seksyen 3 dasar" adalah penanda bahawa sempadan itu nyata.

Isyarat negatif yang lebih penting daripada semua ini: tiada siapa dalam pasukan yang pernah menghantar analisis yang ditulis LLM sebagai kerja mereka sendiri. Jika itu pernah berlaku, dan ia akan berlaku akhirnya, anda tidak mempunyai masalah dasar AI, anda mempunyai masalah kredibiliti, dan penyelesaiannya adalah perbualan, bukan perubahan alat.

Garis antara "AI membantu saya menghantar lebih pantas" dan "AI menghantar analisis salah atas nama saya" lebih tipis daripada yang dicadangkan oleh pemasaran. Tetapkan dengan jelas, tuliskan, dan semak semula setiap suku tahun seiring perubahan alat.

Buku Panduan Data Scientist