Serangan Balik Ilmuwan Data

• Dengan munculnya LLM API, data scientist dan MLE tersingkir dari jalur utama peluncuran AI, tetapi hakikat pekerjaan sebenarnya—perancangan eksperimen, pengukuran metrik, debugging sistem probabilistik—tidak hilang
• Baik kasus Codex dari OpenAI maupun proyek auto-research dari Karpathy menunjukkan bahwa harness yang terdiri dari stack pengujian, metrik, dan observabilitas adalah inti, dan sebagian besar harness tersebut adalah data science
• 5 jebakan eval yang terus berulang di lapangan—metrik generik, model juri yang belum tervalidasi, desain eksperimen yang buruk, data dan label yang jelek, serta otomatisasi berlebihan—merusak kualitas sistem AI
• Akar penyebab yang sama di setiap jebakan adalah tidaknya ada fondasi dasar data science, dan metodologi lama seperti eksplorasi data, evaluasi model, desain eksperimen, pengumpulan data, dan production ML tetap menjadi solusinya
• "Melihat data secara langsung" adalah aktivitas dengan ROI tertinggi, tetapi juga yang paling sering dilewati, dan peran data scientist tetap krusial bahkan di era LLM

---

Kebangkitan Ilmuwan Data

• Data scientist pernah disebut sebagai "pekerjaan paling seksi di abad ke-21" dan menerima kompensasi tinggi
  • Membutuhkan kombinasi keterampilan seperti predictive modeling, pengukuran hubungan kausal, dan eksplorasi pola data
  • Setelah itu, pekerjaan predictive modeling dipisahkan menjadi Machine Learning Engineer (MLE)
• Kemunculan LLM (large language model) mengubah cara perusahaan menerapkan AI sehingga data scientist atau MLE tidak lagi menjadi jalur wajib
  • Melalui Foundation Model API, tim bisa mengintegrasikan AI secara mandiri
• Namun, melatih model bukanlah seluruh pekerjaan data scientist, dan desain eksperimen, debugging, serta perancangan metrik tetap menjadi pekerjaan inti
  • Memanggil LLM API saja tidak membuat pekerjaan ini menghilang
• Presentasi “The Revenge of the Data Scientist” di PyAI Conf membahas poin ini lewat contoh-contoh konkret, dan menekankan bahwa peran data science tetap penting

Hakikat Harness adalah Data Science

• Konsep Harness Engineering dari OpenAI menjelaskan struktur di mana agen mengembangkan kode secara otonom dalam lingkungan yang dikelilingi pengujian dan spesifikasi
  • Harness mencakup stack observabilitas seperti log, metrics, trace, sehingga agen dapat mendeteksi perilaku abnormalnya sendiri
• Proyek auto-research dari Andrej Karpathy juga memperlihatkan pola yang sama, yaitu optimasi berulang berdasarkan metrik validation loss
• “Memanggil LLM sebagai API” tidak menghapus pekerjaan desain eksperimen, debugging, dan perancangan metrik; sebagian besar harness adalah data science
  • Dulu banyak waktu dihabiskan untuk memeriksa data, memvalidasi konsistensi label, dan merancang metrik
  • Sekarang ada kecenderungan mengandalkan “feeling” model, atau memakai begitu saja pustaka metrik open source
• Khususnya di area RAG (Retrieval-Augmented Generation) atau Evals, banyak kesalahpahaman muncul karena kurangnya pemahaman terhadap data
• Klaim seperti RAG is dead, evals are dead bermunculan, tetapi tim yang mengatakan itu pun tetap membangun sistem yang bergantung pada konsep-konsep tersebut
• Fenomena engineer tanpa latar belakang data yang takut dan menghindari hal yang tidak mereka pahami sangat menonjol di area retrieval dan evals
• “Memanggil LLM sebagai API” tidak menghapus pekerjaan desain eksperimen, debugging, dan perancangan metrik; sebagian besar harness adalah data science

5 Jebakan Eval

• Jebakan 1: Metrik Generik (Generic Metrics)

  • Metrik generik seperti helpfulness score, coherence score, dan hallucination score terlalu luas untuk mendiagnosis kegagalan nyata pada aplikasi
  • Seorang data scientist tidak akan langsung mengadopsi metrik, melainkan terlebih dahulu mengeksplorasi data dan trace secara langsung untuk memahami “apa yang sebenarnya rusak”
  • "Melihat data" berarti membaca trace secara langsung, membuat trace viewer kustom, dan melakukan error analysis dengan mengklasifikasikan kegagalan
  • Metrik kesamaan generik seperti ROUGE dan BLEU hampir tidak cocok untuk output LLM, dan yang dibutuhkan adalah metrik spesifik aplikasi seperti "Calendar Scheduling Failure" atau "Failure to Escalate To Human"
  • Melihat data adalah aktivitas dengan ROI tertinggi dan yang paling sering dilewati

• Jebakan 2: Juri yang Belum Tervalidasi (Unverified Judges)

  • Sebagian besar tim yang memakai LLM sebagai juri tidak punya jawaban atas pertanyaan "bagaimana kita mempercayai jurinya"
  • Data scientist memperlakukan juri seperti classifier, memperoleh label manusia, lalu membaginya menjadi train/dev/test untuk mengukur reliabilitas
    • Contoh few-shot diambil dari set pelatihan, prompt juri diperbaiki dengan dev set, dan test set disimpan untuk memeriksa overfitting
  • Saat melaporkan hasil, jangan hanya memakai accuracy, tetapi gunakan juga precision dan recall — jika mode kegagalan hanya 5%, accuracy bisa menyembunyikan performa sebenarnya
  • Validasi classifier telah menjadi keahlian yang hilang dalam AI modern

• Jebakan 3: Desain Eksperimen yang Buruk (Bad Experimental Design)

  • Menyusun test set: sebagian besar tim meminta LLM untuk “menghasilkan 50 query uji”, tetapi cara ini menghasilkan data generik yang tidak representatif
    • Seorang data scientist akan lebih dulu melihat data produksi nyata, mengidentifikasi dimensi penting, lalu membuat contoh sintetis yang sesuai dengan dimensi tersebut
    • Data sintetis harus dibuat berdasarkan log atau trace nyata, dan edge case perlu disuntikkan
  • Perancangan metrik: memasukkan seluruh rubric ke dalam satu panggilan LLM dan menjadikan skala Likert 1–5 sebagai default hanya menyembunyikan ambiguitas dan menunda keputusan sulit tentang performa sistem
    • Ini seharusnya diganti dengan penilaian biner (lulus/gagal) untuk kriteria dengan cakupan sempit

• Jebakan 4: Data dan Label yang Jelek (Bad Data and Labels)

  • Karena pelabelan dianggap tidak glamor, pekerjaan ini sering dilimpahkan ke tim pengembang atau di-outsource, tetapi data scientist akan menuntut agar pakar domain melakukan pelabelan secara langsung
  • Di luar kualitas label, ada alasan yang lebih mendasar: konsep "criteria drift" yang dibuktikan dalam makalah Shreya Shankar dkk.—pengguna membutuhkan kriteria untuk mengevaluasi output, tetapi justru mendefinisikan kriterianya saat mereka menilai output. Artinya, mereka tidak tahu apa yang mereka inginkan sampai melihat output LLM
  • Pakar domain dan PM harus ditempatkan di depan data mentah, bukan hanya skor ringkasan

• Jebakan 5: Otomatisasi Berlebihan (Automating Too Much)

  • LLM dapat membantu menulis plumbing code, membuat boilerplate, dan menghubungkan evaluasi
  • Namun, pekerjaan melihat data secara langsung tidak bisa diautomatisasi — karena “kita tidak tahu apa yang kita inginkan sampai melihat output”
  • Jebakan tambahan lain yang juga disebutkan: penyalahgunaan skor kemiripan, melempar pertanyaan ambigu seperti "apakah ini membantu?" kepada juri, meminta anotator membaca raw JSON, melaporkan skor yang tidak dikalibrasi tanpa interval kepercayaan, data drift, overfitting, sampling yang buruk, dan dashboard yang sulit dipahami

Pemetaan ke Fondasi Dasar Data Science

• Kelima jebakan tersebut memiliki akar penyebab yang sama, yaitu ketiadaan fondasi dasar data science
• Hubungan antara masing-masing jebakan dan metodologi yang sudah ada:
  • Membaca trace dan mengklasifikasikan kegagalan → exploratory data analysis (EDA)
  • Memvalidasi juri LLM dengan label manusia → model evaluation
  • Membangun test set representatif berbasis data produksi → experimental design
  • Pelabelan oleh pakar domain → data collection
  • Memantau perilaku produk di produksi → production ML
• Namanya mungkin berubah, tetapi pekerjaannya tetap sama
• Python tetap merupakan toolset terbaik untuk mengeksplorasi dan menangani data
• Tersedia plugin open source (evals-skills) untuk menganalisis pipeline eval dan mendiagnosis bagian yang bermasalah

[GN⁺]

Komentar Hacker News

• Ini praktik yang baik saat membangun solusi GenAI, tetapi menurut saya perubahan ini tidak menjamin keberlanjutan peran data scientist
  Dulu, data scientist mendapat sorotan karena kemampuan mereka membangun model sendiri untuk menciptakan nilai bisnis
  Namun sekarang, peran itu digantikan oleh penyedia LLM dan engineer yang memanggil API. Mengatur perilaku LLM memang semacam black magic, tetapi tidak selalu membutuhkan pengetahuan matematika
  Pekerjaan yang tersisa sekarang adalah evaluasi dan monitoring, tetapi dari sudut pandang bisnis ini tidak terlihat sebagai ‘nilai inti’. Dalam organisasi yang ingin cepat merilis prototipe, hal ini justru sering dianggap sebagai hambatan
  Pada akhirnya situasinya menjadi “data scientist harus menjadi gatekeeper dalam pembangunan LLM”, dan saya ragu logika itu akan seberapa meyakinkan

  • Saya juga merasakan hal serupa. Untuk menggunakan LLM siap pakai, data scientist tidak selalu diperlukan. Engineer yang ramah terhadap AI seperti saya pun bisa mempelajarinya dengan cepat
    Namun, saya tetap berpikir masih banyak area di luar LLM yang tetap membutuhkan model ML kustom. Misalnya, ranking pencarian AirBnB atau algoritme matching Uber tidak bisa digantikan oleh LLM
    Jadi memang pasarnya menyusut, tetapi belum benar-benar hilang
  • Sulit meyakinkan pihak leadership, dan pada kenyataannya banyak DS juga tidak ingin mengerjakan pekerjaan evaluasi seperti ini
    Namun proses ini memaksa kita mendefinisikan dengan jelas “apa yang sebenarnya ingin diselesaikan”. Kadang jawabannya justru “produk ini tidak layak dibuat”
    Hanya saja hampir tidak ada orang yang ingin mendengar hal seperti itu
  • Saya tidak melihat alasan mengapa pekerjaan evaluasi harus menjadi ranah data scientist
    AI engineer berlatar SWE justru sering lebih cocok. Pola pikir “evaluasi = pengujian otomatis” terasa alami bagi mereka
    Dalam banyak proyek agent, peran DS memang nyaris menghilang
  • Ketelitian statistik yang dulu diberikan data scientist tampaknya hampir hilang dalam solusi berbasis LLM

• Ini saran yang sering saya berikan kepada para data scientist

  1. Anggap data konteks sebagai data pelatihan — LLM belajar dari konteks yang diberikan
  2. Anggap data evaluasi sebagai data uji — harus dikumpulkan dari log eksekusi agent dan diberi label secara manual
     Jika ingin memakai LLM sebagai juri, model itu juga pada akhirnya perlu melakukan in-context learning melalui data contoh yang baik
     Hal terkait ini saya rangkum dalam buku saya
  • Sangat setuju. “Evaluations = Tests”
    Hanya saja ketika sebuah model harus mengevaluasi output model lain, itu menjadi struktur meta, sehingga pada akhirnya di suatu titik tetap harus ada ‘jawaban benar’ yang dipakukan

• Saya memiliki latar belakang data science/engineering
  Menggunakan AI itu terasa seperti menjelajahi ruang solusi. Ini adalah proses mencari titik optimum di antara miliaran kombinasi parameter
  Kita mempersempit ruang pencarian dengan prompt, lalu mencoba menemukan solusi yang lebih baik dengan heuristik berbasis makna
  Sering kali kita terjebak di optimum lokal, atau malah bergerak ke arah yang sepenuhnya salah. Karena itu saya memulai ulang codebase setiap minggu, menyederhanakan atau menambah fitur. Dengan begitu kita bisa menemukan solusi yang lebih baik

• Kasus seperti pg_textsearch yang belakangan disebut menurut saya adalah contoh yang cocok untuk gaya pengembangan seperti ini
  Ketika ada test case dan benchmark yang jelas, peluang berhasilnya tinggi
  Tetapi dalam pengembangan greenfield, mendefinisikan test case bisa sama sulitnya atau bahkan lebih sulit daripada menulis kode
  Selain itu, LLM sering cenderung terjebak di minimum lokal. Ketika struktur kode sudah mengeras, model hampir tidak pernah mencoba refaktor besar. Fenomena ini mirip semacam overfitting

• Dikatakan bahwa inti eksperimen AI adalah memverifikasi seberapa baik model menggeneralisasi pada data baru, tetapi dalam praktiknya proses untuk memastikan dengan jelas “apa sebenarnya datanya” justru sering hilang
  Sebab data yang dibayangkan orang sering kali berbeda dengan data yang sebenarnya

• Bagi saya, mengamati langsung perilaku agent memberi jauh lebih banyak insight daripada membangun workflow LLM-sebagai-juri yang rumit

• Kemarin saya mencoba menerapkan pendekatan autoresearch milik Karpathy pada masalah ML
  Setelah beberapa kali eksperimen, saya terkejut dengan hasil yang ditunjukkan model. Jika Kaggle masih seramai dulu, rasanya AI akan memenangkan sebagian besar masalah
  Tetapi pekerjaan data science di dunia nyata kebanyakan melibatkan orang-orang yang bahkan tidak benar-benar memahami alat dasarnya. Memberi mereka AI pun tampaknya tidak akan membuat mereka tiba-tiba menjadi hebat
  Pada akhirnya para ahli tetap akan menyuruh junior mengerjakan pekerjaan, sementara non-ahli akan terus tersesat di antara hasil yang berantakan

  • Untuk masalah Kaggle, saya rasa AI memang bisa bekerja cukup baik
    Tetapi pekerjaan DS yang nyata sebagian besar berkutat pada data yang tidak lengkap dan tujuan yang ambigu
    Data scientist yang baik harus bisa berkata “ini tidak bisa dilakukan”. Sementara LLM selalu berkata “baik, ide yang bagus!”

• Pada akhirnya pengembangan AI juga adalah loop yang mirip — proses “mendefinisikan apa itu hasil yang baik, mengukur selisihnya, lalu memperbaikinya secara iteratif”
  Hanya saja orang yang sudah lama berpikir dengan cara seperti ini jauh lebih unggul dibanding prompt engineer

[raykim]

Saya tidak tahu apakah ada rekan DS yang sudah berkomentar di sini. Sepertinya semuanya dari sudut pandang developer..