डेटा साइंटिस्ट की वापसी

• LLM API के आने से data scientist और MLE को AI लॉन्च करने की मुख्य प्रक्रिया से बाहर कर दिया गया, लेकिन वास्तविक काम का मूल — experiment design, metric measurement, probabilistic systems debugging — गायब नहीं हुआ
• OpenAI के Codex उदाहरण और Karpathy के auto-research प्रोजेक्ट, दोनों यह दिखाते हैं कि tests, metrics, और observability stack से बना harness ही केंद्र में है, और इस harness का बड़ा हिस्सा data science है
• मैदान में बार-बार दिखने वाले 5 eval pitfalls — generic metrics, unverified judge models, bad experimental design, bad data·labels, excessive automation — AI systems की quality को नुकसान पहुँचा रहे हैं
• हर pitfall का साझा कारण data science की बुनियादी समझ की कमी है, और exploratory data analysis, model evaluation, experimental design, data collection, production ML जैसी पारंपरिक methodologies ही इसका समाधान हैं
• "डेटा को सीधे देखना" सबसे अधिक ROI देने वाली गतिविधि है, फिर भी इसे सबसे ज़्यादा छोड़ा जाता है; LLM युग में भी data scientist की भूमिका अब भी केंद्रीय है

---

डेटा साइंटिस्ट की वापसी

• data scientist को कभी “21वीं सदी की सबसे sexy job” कहा जाता था और उन्हें ऊँचा वेतन मिलता था
  • predictive modeling, causality measurement, और data patterns की खोज जैसी जटिल skills की ज़रूरत होती थी
  • बाद में predictive modeling का काम Machine Learning Engineer(MLE) के रूप में अलग हो गया
• LLM (large language model) के आने के बाद, कंपनियों में AI deploy करते समय data scientist या MLE का अनिवार्य होना कम हो गया
  • Foundation Model API के ज़रिए टीमें स्वतंत्र रूप से AI integrate कर सकती हैं
• लेकिन model training ही data scientist का पूरा काम नहीं है; experiment design, debugging, और metric design अब भी मुख्य काम हैं
  • सिर्फ LLM API call करने से ये काम खत्म नहीं हो जाते
• PyAI Conf का “The Revenge of the Data Scientist” प्रस्तुतीकरण इसी बात को case studies के साथ समझाता है और यह रेखांकित करता है कि data science की भूमिका अब भी महत्वपूर्ण है

Harness की असल प्रकृति data science है

• OpenAI का Harness Engineering कॉन्सेप्ट उस संरचना को समझाता है जिसमें agents tests और specifications से घिरे environment में autonomously code develop करते हैं
  • harness में logs, metrics, traces जैसी observability stack शामिल होती है, जिससे agent खुद असामान्य behavior पहचान सकता है
• Andrej Karpathy का auto-research project भी validation loss metric के आधार पर iterative optimization वाला वही pattern दिखाता है
• "LLM को API के रूप में call करना" experiment design, debugging, और metric design के काम को खत्म नहीं करता; harness का बड़ा हिस्सा data science है
  • पहले data inspection, label consistency checking, और metric design में बहुत समय लगता था
  • अब model की “vibes” पर निर्भर रहने या open source metric libraries को ज्यों का त्यों इस्तेमाल करने की प्रवृत्ति बढ़ गई है
• खासकर RAG (Retrieval-Augmented Generation) और Evals के क्षेत्र में data की समझ की कमी से कई गलतफहमियाँ पैदा होती हैं
• RAG is dead, evals are dead जैसे दावे किए जाते हैं, लेकिन वही टीमें इन अवधारणाओं पर निर्भर systems भी बना रही होती हैं
• data background के बिना engineers अक्सर जिस चीज़ को समझ नहीं पाते, उससे डरकर बचते हैं; retrieval और evals में यह रुझान खास तौर पर दिखता है
• "LLM को API के रूप में call करना" experiment design, debugging, और metric design के काम को खत्म नहीं करता; harness का बड़ा हिस्सा data science है

5 Eval Pitfalls

• Pitfall 1: Generic Metrics

  • helpfulness score, coherence score, hallucination score जैसे generic metrics किसी application की वास्तविक failures को diagnose करने के लिए बहुत व्यापक हैं
  • data scientist ऐसे metrics को तुरंत adopt नहीं करता; वह पहले data और traces को सीधे explore करके यह समझता है कि असल में क्या टूट रहा है
  • "डेटा को देखना" का मतलब है traces को खुद पढ़ना, custom trace viewer बनाना, और error analysis के ज़रिए failures को classify करना
  • ROUGE, BLEU जैसे generic similarity metrics LLM outputs पर लगभग फिट नहीं बैठते; इसकी जगह "Calendar Scheduling Failure" या "Failure to Escalate To Human" जैसे application-specific metrics चाहिए
  • data को देखना सबसे अधिक ROI देने वाली गतिविधि है, और यही सबसे ज़्यादा छोड़ी जाती है

• Pitfall 2: Unverified Judges

  • LLM को judge की तरह इस्तेमाल करने वाली ज़्यादातर teams के पास "judge पर भरोसा क्यों किया जाए" इसका जवाब नहीं होता
  • data scientist judge को classifier की तरह treat करता है, human labels इकट्ठा करता है, और trustworthiness मापने के लिए उसे train/dev/test में split करता है
    • few-shot examples training set से लिए जाते हैं, dev set से judge prompt सुधारा जाता है, और test set को overfitting जाँचने के लिए सुरक्षित रखा जाता है
  • results report करते समय सिर्फ accuracy नहीं, बल्कि precision और recall का उपयोग होना चाहिए — अगर failure mode केवल 5% हो, तब भी accuracy वास्तविक performance छिपा सकती है
  • classifier validation आधुनिक AI में एक तरह की खोई हुई कला बन गई है

• Pitfall 3: Bad Experimental Design

  • test set construction: ज़्यादातर teams LLM से कहती हैं, "50 test queries generate करो," लेकिन यह तरीका गैर-प्रतिनिधिक generic data बनाता है
    • data scientist पहले वास्तविक production data देखेगा, महत्वपूर्ण dimensions पहचानेगा, और फिर उन्हीं dimensions के अनुरूप synthetic examples बनाएगा
    • synthetic data वास्तविक logs या traces के आधार पर generate किया जाना चाहिए, और edge cases inject किए जाने चाहिए
  • metric design: पूरी rubric को एक single LLM call में भर देना और 1~5 Likert scale को default बनाना ambiguity छिपाने और system performance पर कठिन निर्णयों को टालने जैसा है
    • इसकी जगह सीमित दायरे वाले मानदंडों पर binary (pass/fail) judgments होने चाहिए

• Pitfall 4: Bad Data and Labels

  • labeling को कम glamorous मानकर development team को सौंप देना या outsource कर देना आम है, लेकिन data scientist ज़ोर देता है कि labeling domain experts करें
  • label quality के अलावा एक और गहरा कारण है: Shreya Shankar आदि के papers में प्रमाणित "criteria drift" — users को outputs का मूल्यांकन करने के लिए criteria चाहिए, लेकिन outputs को देखते-देखते वही criteria बनते हैं; यानी LLM output देखे बिना उन्हें पता नहीं होता कि वे वास्तव में क्या चाहते हैं
  • domain experts और PMs को summary scores के सामने नहीं, बल्कि raw data के सामने बैठाना चाहिए

• Pitfall 5: Automating Too Much

  • LLM plumbing code लिखने, boilerplate generate करने, और evaluations को connect करने में मदद कर सकता है
  • लेकिन data को सीधे देखने का काम automate नहीं किया जा सकता — क्योंकि "output देखे बिना पता नहीं चलता कि आप क्या चाहते हैं"
  • और भी अतिरिक्त pitfalls बताए गए हैं: similarity scores का दुरुपयोग, judge से "क्या यह helpful है?" जैसे अस्पष्ट सवाल पूछना, annotators से raw JSON पढ़वाना, confidence intervals के बिना uncalibrated scores report करना, data drift, overfitting, bad sampling, और मुश्किल dashboards

data science fundamentals से mapping

• ये सभी 5 pitfalls एक ही मूल कारण से जुड़े हैं: data science की बुनियादी समझ का अभाव
• हर pitfall और पारंपरिक methodology के बीच संबंध:
  • traces पढ़ना और failures classify करना → exploratory data analysis (EDA)
  • human labels से LLM judge को validate करना → model evaluation
  • production data के आधार पर representative test set बनाना → experimental design
  • domain expert labeling → data collection
  • production में product behavior की monitoring → production ML
• नाम बदल गए हैं, लेकिन काम वही है
• Python आज भी data को explore और handle करने के लिए सबसे अच्छा toolset है
• open source plugin(evals-skills) के ज़रिए eval pipeline का विश्लेषण करने और गलत हिस्सों को diagnose करने वाला tool जारी किया गया है