การโต้กลับของนักวิทยาศาสตร์ข้อมูล

 (hamel.dev)
22 คะแนน โดย GN⁺ 28 일 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังการมาถึงของ LLM API ทำให้นักวิทยาศาสตร์ข้อมูลและ MLE ถูกกันออกจากเส้นทางหลักของการเปิดตัว AI แต่แก่นแท้ของงานจริง—การออกแบบการทดลอง, การวัดเมตริก, การดีบักระบบเชิงความน่าจะเป็น—ไม่ได้หายไป
  • ทั้งกรณีของ Codex จาก OpenAI และโปรเจกต์ auto-research ของ Karpathy ต่างแสดงให้เห็นว่าแกนสำคัญคือ harness ที่ประกอบด้วยสแตกสำหรับการทดสอบ, เมตริก, และการสังเกตการณ์ และส่วนสำคัญของ harness นี้ก็คืองานด้าน data science
  • 5 กับดักของ eval ที่พบซ้ำๆ ในภาคสนาม—เมตริกแบบครอบจักรวาล, โมเดลผู้ตัดสินที่ไม่ผ่านการตรวจสอบ, การออกแบบการทดลองที่ผิดพลาด, ข้อมูลและเลเบลคุณภาพต่ำ, การทำอัตโนมัติมากเกินไป—กำลังบั่นทอนคุณภาพของระบบ AI
  • สาเหตุร่วมของทุกกับดักคือ การขาดพื้นฐาน data science และแนวทางเดิมอย่าง exploratory data analysis, model evaluation, experimental design, data collection, production ML ก็ยังเป็นคำตอบเหมือนเดิม
  • "การดูข้อมูลด้วยตาตัวเอง" เป็นกิจกรรมที่ให้ ROI สูงที่สุด แต่กลับถูกข้ามบ่อยที่สุด และบทบาทของนักวิทยาศาสตร์ข้อมูลก็ยังคงสำคัญในยุค LLM

การคืนชีพของนักวิทยาศาสตร์ข้อมูล

  • ครั้งหนึ่งนักวิทยาศาสตร์ข้อมูลเคยถูกเรียกว่า “อาชีพที่เซ็กซี่ที่สุดแห่งศตวรรษที่ 21” และได้รับค่าตอบแทนสูง
    • ต้องใช้ทักษะซับซ้อน เช่น predictive modeling, การวัดความเป็นเหตุเป็นผล, และการสำรวจแพตเทิร์นของข้อมูล
    • ต่อมางานด้าน predictive modeling ถูกแยกออกไปเป็น Machine Learning Engineer(MLE)
  • การมาถึงของ LLM(large language model) ทำให้เกิดการเปลี่ยนแปลงที่เมื่อบริษัทต้องการ deploy AI นักวิทยาศาสตร์ข้อมูลหรือ MLE ไม่ได้อยู่ในเส้นทางบังคับอีกต่อไป
    • ทีมสามารถผนวก AI ได้อย่างอิสระผ่าน Foundation Model API
  • แต่การฝึกโมเดลไม่ใช่ทั้งหมดของงานนักวิทยาศาสตร์ข้อมูล และ การออกแบบการทดลอง, การดีบัก, การออกแบบเมตริก ก็ยังคงเป็นงานแกนหลัก
    • งานเหล่านี้ไม่ได้หายไปเพียงเพราะเรียกใช้ LLM API
  • งานบรรยาย “The Revenge of the Data Scientist” ใน PyAI Conf พูดถึงประเด็นนี้ผ่านกรณีศึกษาต่างๆ และเน้นว่า บทบาทของ data science ยังสำคัญอยู่มาก

แก่นแท้ของ Harness ก็คือ Data Science

  • แนวคิด Harness Engineering ของ OpenAI อธิบายโครงสร้างที่เอเจนต์พัฒนาโค้ดได้อย่างอัตโนมัติภายในสภาพแวดล้อมที่ถูกล้อมด้วยการทดสอบและสเปก
    • ใน harness มีสแตกด้าน observability เช่น logs, metrics, traces ทำให้เอเจนต์ตรวจจับความผิดปกติของตัวเองได้
  • โปรเจกต์ auto-research ของ Andrej Karpathy ก็แสดงแพตเทิร์นเดียวกัน โดยทำ optimization แบบวนซ้ำโดยอิงกับเมตริก validation loss
  • การ "เรียก LLM ผ่าน API" ไม่ได้ทำให้งานออกแบบการทดลอง, การดีบัก, และการออกแบบเมตริกหายไป และ ส่วนสำคัญของ harness ก็คือ data science
    • ในอดีตมีการใช้เวลาจำนวนมากกับการตรวจข้อมูล, การเช็กความสอดคล้องของเลเบล, และการออกแบบเมตริก
    • แต่ปัจจุบันมีแนวโน้มจะพึ่ง “ความรู้สึก” ของโมเดล หรือใช้งานไลบรารีเมตริกโอเพนซอร์สแบบยกมาใช้ตรงๆ
  • โดยเฉพาะในงาน RAG(Retrieval-Augmented Generation) หรือ Evals(การประเมิน) มีความเข้าใจผิดมากมายจากการขาดความเข้าใจข้อมูล
  • มีคำกล่าวอย่าง RAG is dead, evals are dead แต่ทีมที่พูดเช่นนั้นก็ยังสร้างระบบที่พึ่งพาแนวคิดเหล่านี้อยู่
  • ปรากฏการณ์ที่วิศวกรซึ่งไม่มีพื้นฐานด้านข้อมูลกลัวและหลีกเลี่ยงสิ่งที่ตนไม่เข้าใจนั้นเห็นได้ชัดเป็นพิเศษในพื้นที่ของ retrieval และ evals
  • การ "เรียก LLM ผ่าน API" ไม่ได้ทำให้งานออกแบบการทดลอง, การดีบัก, และการออกแบบเมตริกหายไป และ ส่วนสำคัญของ harness ก็คือ data science

5 กับดักของ Eval

  • กับดัก 1: เมตริกแบบครอบจักรวาล(Generic Metrics)

    • เมตริกแบบครอบจักรวาล อย่าง helpfulness score, coherence score, hallucination score นั้นกว้างเกินไปที่จะใช้วินิจฉัยความล้มเหลวจริงของแอปพลิเคชัน
    • ถ้าเป็นนักวิทยาศาสตร์ข้อมูล จะไม่หยิบเมตริกมาใช้ทันที แต่จะสำรวจข้อมูลและ traces ด้วยตัวเองก่อน เพื่อหาว่า "จริงๆ แล้วอะไรที่กำลังพังอยู่"
    • "การดูข้อมูล" หมายถึงการอ่าน traces ด้วยตัวเอง, ทำ custom trace viewer, และทำ error analysis เพื่อจัดหมวดหมู่ความล้มเหลว
    • เมตริกความคล้ายคลึงแบบทั่วไปอย่าง ROUGE, BLEU แทบไม่เหมาะกับเอาต์พุตของ LLM และจำเป็นต้องมีเมตริกเฉพาะแอป เช่น "Calendar Scheduling Failure" หรือ "Failure to Escalate To Human"
    • การดูข้อมูลคือกิจกรรมที่ให้ ROI สูงที่สุด และก็เป็นสิ่งที่ถูกละเลยบ่อยที่สุด

  • กับดัก 2: โมเดลผู้ตัดสินที่ไม่ผ่านการตรวจสอบ(Unverified Judges)

    • ทีมส่วนใหญ่ที่ใช้ LLM เป็นผู้ตัดสิน ไม่ได้มีคำตอบต่อคำถามว่า "เราจะเชื่อถือผู้ตัดสินได้อย่างไร"
    • นักวิทยาศาสตร์ข้อมูลจะปฏิบัติต่อผู้ตัดสินเหมือน classifier โดยเก็บ human labels แล้วแบ่งเป็น train/dev/test เพื่อวัดความน่าเชื่อถือ
      • ตัวอย่าง few-shot ควรมาจากชุดฝึก ใช้ dev set ปรับปรุง judge prompt และเก็บ test set ไว้เพื่อตรวจสอบ overfitting
    • เวลารายงานผลควรใช้ precision และ recall แทนการดูแค่ accuracy — ต่อให้ failure mode มีเพียง 5% accuracy ก็อาจซ่อนประสิทธิภาพจริงไว้
    • การตรวจสอบ classifier ได้กลายเป็น ทักษะที่สูญหาย ไปแล้วใน AI ยุคปัจจุบัน

  • กับดัก 3: การออกแบบการทดลองที่ผิดพลาด(Bad Experimental Design)

    • การสร้าง test set: ทีมส่วนใหญ่มักขอให้ LLM "สร้าง test query มา 50 รายการ" แต่วิธีนี้ทำให้ได้ ข้อมูลทั่วไปที่ไม่เป็นตัวแทน
      • นักวิทยาศาสตร์ข้อมูลจะดูข้อมูล production จริงก่อน ระบุมิติสำคัญ แล้วค่อยสร้างตัวอย่างสังเคราะห์ให้สอดคล้องกับมิติเหล่านั้น
      • ควรสร้างข้อมูลสังเคราะห์โดยอิงจาก logs หรือ traces จริง และใส่ edge cases เข้าไป
    • การออกแบบเมตริก: การยัด rubric ทั้งหมดไว้ใน LLM call เดียว แล้วใช้สเกล Likert 1~5 เป็นค่าเริ่มต้น คือการซ่อนความกำกวมและเลื่อนการตัดสินใจยากๆ เกี่ยวกับประสิทธิภาพของระบบออกไป
      • ควรแทนที่ด้วยการตัดสินแบบ binary(pass/fail) สำหรับเกณฑ์ที่มีขอบเขตแคบ

  • กับดัก 4: ข้อมูลและเลเบลคุณภาพต่ำ(Bad Data and Labels)

    • เพราะงานติดเลเบลไม่หวือหวา จึงมักถูกโยนให้ทีมพัฒนาหรือจ้างคนนอกทำ แต่นักวิทยาศาสตร์ข้อมูลจะยืนยันให้ ผู้เชี่ยวชาญโดเมน เป็นคนติดเลเบลเอง
    • นอกจากคุณภาพของเลเบลแล้ว ยังมีเหตุผลเชิงลึกกว่านั้น: แนวคิด "criteria drift" ที่ได้รับการยืนยันในงานวิจัยของ Shreya Shankar และคณะ—ผู้ใช้ต้องมีเกณฑ์เพื่อประเมินผลลัพธ์ แต่ในกระบวนการประเมินผลลัพธ์นั้นเอง พวกเขาจึงค่อยนิยามเกณฑ์ขึ้นมา กล่าวคือ ก่อนเห็นผลลัพธ์ของ LLM ผู้ใช้ยังไม่รู้ด้วยซ้ำว่าตัวเองต้องการอะไร
    • ควรวางผู้เชี่ยวชาญโดเมนและ PM ไว้ต่อหน้ากับ ข้อมูลดิบ ไม่ใช่คะแนนสรุป

  • กับดัก 5: การทำอัตโนมัติมากเกินไป(Automating Too Much)

    • LLM สามารถช่วยเขียน plumbing code, สร้าง boilerplate, และเชื่อมต่องานประเมินได้
    • แต่ งานดูข้อมูลด้วยตาตัวเองนั้นทำอัตโนมัติไม่ได้ — เพราะ "เราไม่รู้ว่าต้องการอะไรจนกว่าจะได้เห็นผลลัพธ์"
    • กับดักเพิ่มเติมที่ถูกกล่าวถึงได้แก่: การใช้ similarity score ผิดวิธี, การถามผู้ตัดสินด้วยคำถามกำกวมอย่าง "มีประโยชน์ไหม?", ให้ผู้ทำ annotation อ่าน raw JSON, รายงานคะแนนที่ไม่ได้ปรับแก้และไม่มีช่วงความเชื่อมั่น, data drift, overfitting, การสุ่มตัวอย่างที่ผิดพลาด, และแดชบอร์ดที่เข้าใจยาก

การแมปกลับไปสู่พื้นฐาน Data Science

  • ทั้ง 5 กับดักมีรากเหง้าร่วมกันคือ การขาดพื้นฐาน data science
  • ความสัมพันธ์ระหว่างแต่ละกับดักกับวิธีการดั้งเดิมมีดังนี้:
    • การอ่าน traces และจัดหมวดหมู่ความล้มเหลว → exploratory data analysis(EDA)
    • การตรวจสอบ LLM judge ด้วย human labels → model evaluation
    • การสร้าง representative test set จากข้อมูล production → experimental design
    • การติดเลเบลโดยผู้เชี่ยวชาญโดเมน → data collection
    • การมอนิเตอร์การทำงานของผลิตภัณฑ์ใน production → production ML
  • ชื่ออาจเปลี่ยนไป แต่ตัวงานจริงยังเหมือนเดิม
  • Python ยังคงเป็น toolset ที่เหมาะที่สุด สำหรับการสำรวจและจัดการข้อมูล
  • มีการเผยแพร่เครื่องมือสำหรับวิเคราะห์ eval pipeline และวินิจฉัยจุดที่ผิดพลาดผ่าน โอเพนซอร์สปลั๊กอิน(evals-skills)

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 28 일 전
ความคิดเห็นจาก Hacker News

  • เป็นแนวปฏิบัติที่ดีเวลาสร้างโซลูชัน GenAI ก็จริง แต่ผมไม่คิดว่าการเปลี่ยนแปลงนี้จะรับประกันความยั่งยืนของสายอาชีพ นักวิทยาศาสตร์ข้อมูล ได้
    แต่ก่อนนักวิทยาศาสตร์ข้อมูลได้รับความสนใจเพราะมีความสามารถในการสร้างโมเดลเองเพื่อ สร้างมูลค่าทางธุรกิจ
    แต่ตอนนี้ผู้ให้บริการ LLM กับวิศวกรที่เรียกใช้ API เข้ามารับบทนั้นแทนแล้ว การปรับพฤติกรรมของ LLM เป็นเหมือนแบล็กเมจิกอย่างหนึ่ง แต่ไม่จำเป็นต้องมีความรู้คณิตศาสตร์ลึกซึ้งเสมอไป
    ตอนนี้งานที่เหลือคือการประเมินผลและมอนิเตอร์ ซึ่งในมุมธุรกิจไม่ได้ดูเป็น ‘คุณค่าหลัก’ และในองค์กรที่อยากปล่อยต้นแบบให้เร็ว กลับถูกมองว่าเป็นตัวถ่วงด้วยซ้ำ
    สุดท้ายเลยกลายเป็นสถานการณ์ที่ต้องพยายามโน้มน้าวว่า “นักวิทยาศาสตร์ข้อมูลควรเป็นผู้เฝ้าประตูของการสร้าง LLM” ซึ่งก็ไม่แน่ใจว่าเหตุผลนี้จะโน้มน้าวได้มากแค่ไหน

    • ผมก็รู้สึกคล้ายกัน การใช้ LLM สำเร็จรูป ไม่ได้จำเป็นต้องมีนักวิทยาศาสตร์ข้อมูลเสมอไป วิศวกรที่คุ้นกับ AI แบบผมก็เรียนรู้ได้เร็ว
      แต่ผมก็ยังคิดว่านอกจาก LLM แล้ว ยังมีหลายพื้นที่ที่ยังต้องใช้ โมเดล ML แบบปรับแต่งเฉพาะ อยู่ เช่น search ranking ของ AirBnB หรืออัลกอริทึม matching ของ Uber ก็แทนที่ด้วย LLM ไม่ได้
      สุดท้ายตลาดอาจเล็กลงจริง แต่ยังไม่ได้หายไปทั้งหมด
    • โน้มน้าวฝ่ายผู้นำก็ยาก และจริงๆ แล้ว DS จำนวนมากก็ไม่ได้อยากทำ งานประเมินผล แบบนี้
      แต่กระบวนการนี้ช่วยบังคับให้เรานิยามให้ชัดว่า “เรากำลังพยายามแก้อะไรอยู่” บางครั้งคำตอบอาจเป็น “ผลิตภัณฑ์นี้ไม่คุ้มจะสร้าง” ก็ได้
      เพียงแต่แทบไม่มีใครอยากได้ยินเรื่องแบบนั้น
    • ผมไม่เข้าใจว่าทำไมงานประเมินผลถึงต้องเป็นขอบเขตของนักวิทยาศาสตร์ข้อมูลเท่านั้น
      วิศวกร AI ที่มีพื้นฐาน SWE หลายครั้งกลับเหมาะกว่า เพราะกรอบคิดแบบ “การประเมิน = การทดสอบอัตโนมัติ” เป็นเรื่องธรรมชาติสำหรับพวกเขา
      ในหลายโปรเจ็กต์เอเจนต์ บทบาทของ DS แทบหายไปแล้ว
    • ความ เข้มงวดทางสถิติ ที่นักวิทยาศาสตร์ข้อมูลเคยมอบให้ ดูเหมือนจะหายไปเกือบหมดในโซลูชันที่อิง LLM

  • นี่เป็นคำแนะนำที่ผมบอกนักวิทยาศาสตร์ข้อมูลอยู่บ่อยๆ

    1. ให้คิดว่าข้อมูลบริบทคือ ข้อมูลฝึก — LLM เรียนรู้จากบริบทที่ได้รับ
    2. ให้คิดว่าข้อมูลประเมินผลคือ ข้อมูลทดสอบ — ต้องเก็บจาก execution log ของเอเจนต์และติดป้ายกำกับด้วยมือ
      ถ้าจะใช้ LLM เป็นผู้ตัดสิน โมเดลนั้นเองสุดท้ายก็ต้องทำ in-context learning ผ่านข้อมูลตัวอย่างที่ดี
      ผมสรุปเรื่องที่เกี่ยวข้องไว้ในหนังสือ ของผม
    • เห็นด้วยอย่างยิ่ง “Evaluations = Tests”
      เพียงแต่ถ้าต้องให้โมเดลหนึ่งประเมินผลลัพธ์ของอีกโมเดล มันจะกลายเป็น โครงสร้างเชิงเมตา และสุดท้ายก็ต้องมีจุดที่เราตรึง ‘คำตอบจริง’ เอาไว้

  • ผมมีพื้นฐานด้าน data science/engineering
    การใช้ AI คล้ายกับการ สำรวจพื้นที่คำตอบ เป็นกระบวนการค้นหาจุดที่เหมาะที่สุดจากชุดพารามิเตอร์นับพันล้านแบบ
    เราใช้พรอมป์ต์เพื่อลดขอบเขตของพื้นที่ค้นหา แล้วใช้ฮิวริสติกเชิงความหมายเพื่อหาคำตอบที่ดีกว่า
    บางครั้งก็ติดอยู่ใน local optimum หรือไม่ก็หลงไปผิดทิศทางเลย เพราะงั้นผมจึงเริ่มโค้ดเบสใหม่ทุกสัปดาห์เพื่อทำให้เรียบง่ายขึ้นหรือเพิ่มฟีเจอร์ วิธีนี้ช่วยให้หาคำตอบที่ดีกว่าได้

  • กรณีอย่าง pg_textsearch ที่มีการพูดถึงล่าสุด ผมคิดว่าเป็นตัวอย่างที่วิธีพัฒนาแบบนี้เข้ากันได้ดี
    เมื่อมี test case และ benchmark ที่ชัดเจน โอกาสสำเร็จก็สูง
    แต่ใน การพัฒนาแบบกรีนฟิลด์ การนิยาม test case อาจยากพอๆ กับหรือยากกว่าการเขียนโค้ดเสียอีก
    นอกจากนี้ LLM ยังมีแนวโน้มจะติดอยู่ใน local minima บ่อยๆ เมื่อโครงสร้างโค้ดเริ่มแข็งตัว มันแทบไม่ลองรีแฟกเตอร์ครั้งใหญ่เลย เป็นปรากฏการณ์ที่คล้ายโอเวอร์ฟิตแบบหนึ่ง

  • มีคนบอกว่าหัวใจของการทดลอง AI คือการตรวจสอบว่าโมเดล ทั่วไปกับข้อมูลใหม่ ได้แค่ไหน แต่ในทางปฏิบัติกลับขาดขั้นตอนการยืนยันให้ชัดว่า “ข้อมูลคืออะไร”
    เพราะบ่อยครั้งข้อมูลที่คนคิดกับข้อมูลจริงไม่ตรงกัน

  • สำหรับผม การ สังเกตพฤติกรรมของเอเจนต์โดยตรง ให้ข้อมูลเชิงลึกมากกว่าการสร้างเวิร์กโฟลว์ LLM-as-judge ที่ซับซ้อนมาก

  • เมื่อวานผมลองเอาแนวทาง autoresearch ของ Karpathy ไปใช้กับปัญหา ML
    หลังทดลองหลายรอบ ผมประหลาดใจกับผลลัพธ์ที่โมเดลแสดงออกมา ถ้า Kaggle ยังคึกคักเหมือนเดิม ผมว่า AI คงชนะปัญหาส่วนใหญ่ได้
    แต่ในงาน data science จริง คนส่วนมากกลับเป็นพวกที่ ไม่รู้แม้แต่เครื่องมือพื้นฐานให้ดีพอ ต่อให้ให้ AI ไปก็คงไม่ได้เก่งขึ้นแบบทันทีทันใด
    สุดท้ายผู้เชี่ยวชาญก็ยังใช้จูเนียร์ทำงานอยู่ดี ส่วนคนที่ไม่เชี่ยวชาญก็จะหลงทางอยู่ในผลลัพธ์ที่สะเปะสะปะ

    • ถ้าเป็นโจทย์แบบ Kaggle ผมว่า AI น่าจะทำได้ค่อนข้างดี
      แต่ในงาน DS จริง ส่วนใหญ่คือการจัดการกับ ข้อมูลที่ไม่สมบูรณ์และเป้าหมายที่คลุมเครือ
      DS ที่ดีต้องกล้าพูดว่า “อันนี้ทำไม่ได้” ในขณะที่ LLM มักตอบแค่ว่า “ได้เลย ไอเดียเยี่ยมมาก!” เสมอ

  • สุดท้ายแล้วการพัฒนา AI ก็เป็นลูปแบบเดียวกัน — คือ “นิยามว่าผลลัพธ์ที่ดีคืออะไร วัดช่องว่างจากจุดนั้น แล้วปรับปรุงซ้ำไปเรื่อยๆ”
    เพียงแต่คนที่คิดแบบนี้มานานแล้ว มักนำหน้า prompt engineer ไปไกลมาก
 
raykim 27 일 전

ไม่ทราบว่ามีชาว DS มาแสดงความเห็นในคอมเมนต์บ้างหรือเปล่า ดูเหมือนว่าทุกคนจะมองจากมุมของนักพัฒนากันหมด..