เมื่อค่าเฉลี่ยหลอกเรา: ปัญหาของการประเมินแบบรวมเดียว
การประเมินผล ML models คือกระบวนการออกแบบ วัดผล และตรวจสอบพฤติกรรมของโมเดลกับข้อมูลที่มีโครงสร้างหลากหลาย ภายใต้เงื่อนไขการใช้งานใกล้เคียงของจริง เป้าหมายไม่ใช่แค่หาค่าความแม่นยำสูงสุด แต่คือการทำให้ทีมเข้าใจว่าโมเดลผิดพลาดที่ไหน อย่างไร และผลกระทบต่อระบบจริงคืออะไร เพื่อใช้ตัดสินใจเชิงวิศวกรรมว่าจะปรับปรุงหรือหยุดปล่อยโมเดลรุ่นนั้น
ในโลกการทำงาน หลายทีมยังติดกับกับดักค่าเดียว เช่น accuracy หรือ F1 แล้วคิดว่าตัดสินทุกอย่างได้ ทั้งที่ผู้เขียนกรอบการประเมินสำหรับระบบรับรู้ของรถไร้คนขับยืนยันว่า การวัดผลเป็นหนึ่งในปัญหาวิศวกรรมยากที่สุดและมักถูกพูดถึงน้อยที่สุด ตัวเลขรวมดูเป็นวิทยาศาสตร์ แต่แอบสมมติว่าข้อมูลใน production จะเหมือนชุดทดสอบ ซึ่งผิดจากความเป็นจริงอย่างชัดเจน ผลคือโมเดลที่ได้ 94 เปอร์เซ็นต์บน benchmark อาจอันตรายบนถนน เพราะตัวเลขนี้ตอบคนละคำถามกับคำถามว่า “ใช้งานได้อย่างปลอดภัยหรือไม่”
ปัญหาใหญ่คือคณิตศาสตร์ของค่าเฉลี่ย ค่าเฉลี่ยถูกครอบงำด้วยเคสที่พบบ่อย ซึ่งมักเป็นเคสง่าย เช่น สภาพอากาศดี รถธรรมดา ระยะมองเห็นชัด ในระบบความปลอดภัยสูง เหตุการณ์ที่กำหนดว่าระบบปลอดภัยหรือไม่กลับเกิดน้อยตามนิยาม เช่น คนเดินออกจากหลังรถที่จอดบัง หรือสัญญาณเซ็นเซอร์แปลกในแสงพลบค่ำ โมเดลสามารถเพิ่มคะแนนรวมไปพร้อมกับทำผลงานแย่ลงบนกลุ่มเหตุการณ์อันตรายเหล่านี้ได้ และตัวเลขบนสุดยังยิ้มให้คุณเหมือนไม่มีอะไรผิดปกติ
slice-based evaluation: จากตัวเลขเดียวสู่โปรไฟล์ความล้มเหลวของโมเดล
ทางออกไม่ใช่การโยนข้อมูลประเมินให้เยอะขึ้น แต่คือการจัดโครงสร้าง coverage ให้ตรงกับโหมดความล้มเหลวของระบบ ผู้เชี่ยวชาญด้าน perception สำหรับรถไร้คนขับจึงจัด measurement ตามมิติที่ระบบอาจล้มเหลว เช่น ประเภทวัตถุ ระยะห่าง ระดับการบัง การมองเห็น สภาพแวดล้อม โดยให้แต่ละ slice มีมาตรฐานของตัวเอง นี่คือหัวใจของ slice-based evaluation
เมื่อทำแบบนี้ คำถามจะเปลี่ยนจาก “คะแนนเท่าไร” เป็น “มี slice ไหนที่โมเดลแย่จนรับไม่ได้หรือไม่” ตัวเลขเดียวกลายเป็นโปรไฟล์ และโปรไฟล์คือสิ่งที่ใช้ถกเถียงในห้องอนุมัติปล่อยระบบ นี่คือรูปแบบ model reliability testing ที่จริงจัง เพราะบังคับให้ทีมเผชิญหน้ากับเคสปลายหาง แทนการซ่อนมันไว้ใต้ค่าเฉลี่ย การประเมินผล ML models แบบใหม่จึงไม่ใช่รายงานท้ายสไลด์ แต่เป็นเครื่องมือกำกับความเสี่ยงขององค์กรโดยตรง
แต่ slice-based evaluation จะมีพลังได้ต้องทำให้ทำซ้ำได้อย่างเคร่งครัด เจ้าของกรอบประเมินชี้ชัดว่า ถ้าวิศวกรสองคนรันแล้วสร้างตารางผลเดียวกันไม่ได้ แปลว่ากรอบประเมินยังไม่เสร็จ การมีเวอร์ชันข้อมูล เมตริก และสคริปต์รันที่แน่นอน ทำให้เราทดสอบพฤติกรรมโมเดลบนแต่ละ slice ได้ทุกครั้งที่มีรุ่นใหม่ เท่ากับมี automated gate ที่ดัก regression ก่อนถึง production ไม่ใช่ปล่อยให้ผู้ใช้เป็นคนเจอ
จาก flat logs สู่ execution-aware tracing: รู้ว่าโมเดลผิดตรงไหน ไม่ใช่แค่รู้ว่าผิด
เมื่อระบบเริ่มใช้เอเจนต์ AI หรือ workflow ที่มีหลายโมเดลและหลายเครื่องมือ ปัญหาการประเมินเปลี่ยนจาก “โมเดลตอบผิดไหม” เป็น “โมเดลตอบผิดเพราะกิ่งไหนของ workflow” เอเจนต์ไม่ล้มเหลวแบบ request handler ทั่วไป แต่ล้มเหลวข้ามเครื่องมือ การลองใหม่ การส่งต่อ และสาขาขนานกัน ถ้าเรายังใช้ flat logs ที่เป็นสายข้อความเรียงตามเวลาโดยไม่มีโครงสร้าง การตามหารากเหตุกลายเป็นฝันร้าย
ตัวอย่างเชิงปฏิบัติคือ เมื่อเครื่องมือ analyze_data ล้มเหลว คำถามสำคัญไม่ใช่แค่บรรทัดไหนพัง แต่คือ “ทำไมสาขานี้ถึงเรียก analyze_data” มันถูกเรียกโดยเอเจนต์ค้นคว้าหรือเอเจนต์รายงาน เป็นความพยายามครั้งแรกหรือครั้ง retry ข้อมูลดึงมาบางส่วนหรือไม่ มีเครื่องมือก่อนหน้าพังจนดัน workflow ไปเส้น fallback หรือไม่ ตอนนี้คุณต้องเลื่อนดูบรรทัดล็อกหลายร้อยบรรทัด มีการเรียกเครื่องมือแบบขนานสามตัว มี retry สองรอบที่สลับข้อความกัน และเอเจนต์ที่สองใช้ผลจากเอเจนต์แรก ในจุดใดสักจุด workflow เปลี่ยนจากปัญหาที่แก้ได้ ไปสู่คำตอบผิดที่ดูน่าเชื่อถือ
นี่ไม่ใช่แค่ทักษะการดีบัก แต่คือปัญหาการแทนโครงสร้างระบบ นักเขียนบทความเสนอว่า เพิ่มปริมาณล็อกไม่ใช่คำตอบ แต่ต้องเพิ่มโครงสร้างของข้อมูลสังเกตการณ์แทน execution-aware tracing จึงต้องแสดงโครง workflow เป็นลำต้นและกิ่งก้าน เห็นแต่ละการเรียกโมเดล เครื่องมือ การ retry และการส่งต่อเชื่อมกันอย่างไร เมื่อจับคู่สิ่งนี้กับ slice-based evaluation เราจะไม่เพียงรู้ว่าโมเดลล้มเหลวใน slice ไหน แต่รู้ด้วยว่าล้มเหลวในสาขาใดของระบบ ซึ่งเป็นข้อมูลจำเป็นสำหรับการออกแบบเกณฑ์หยุด ปรับเส้นทาง fallback และออกแบบการทดสอบก่อนปล่อยรุ่นใหม่
LLM vs statistical models: ประเด็นคือรูปแบบข้อมูล ไม่ใช่กระแสเทคโนโลยี
การถกเถียง LLM vs statistical models มักติดกับดักว่าใครดีกว่าโดยรวม แต่ผู้เขียนการเปรียบเทียบหลายเคสย้ำว่า เรื่องนี้ไม่ใช่การแบ่งฝั่งระหว่าง LLM กับ machine learning แบบดั้งเดิม บทเรียนจากงานจริงในประกันภัย การพยากรณ์เวลา และการสร้างโมเดลขนาดใหญ่แสดงให้เห็นว่า สิ่งที่ชี้ชะตาว่าแบบไหนชนะคือโมเดลถูกออกแบบให้เข้ากับรูปแบบข้อมูลมากแค่ไหน
ในเคสการกำหนดราคาเบี้ยประกันรถ นักวิจัยนำข้อมูลที่เคยป้อนเป็นตัวเลข มาเขียนเป็นประโยค แล้วให้ LLM แปลงเป็น embedding เพียงเวกเตอร์เดียว จากนั้นป้อนให้ GLM เดิมใช้ แทนฟีเจอร์ที่นักคณิตประกันภัยสร้างมือ ผลคือเมื่อข้อมูลบาง โมเดลที่ใช้ embedding ทำนายความถี่การเคลมได้ดีกว่ารุ่นมาตรฐาน เพราะ GLM มีข้อจำกัดว่าเห็นผลของแต่ละตัวแปรแยกกัน และจะมองเห็นผลรวมของปัจจัยเสี่ยงหลายอย่างพร้อมกันก็ต่อเมื่อมีการสร้างฟีเจอร์เชิงโต้ตอบให้โดยเจตนา
เมื่อข้อมูลน้อย และโมเดลปัจจุบันไม่มีโครงสร้างให้ค้นหารูปแบบที่ซับซ้อนได้เองโดยไม่ช่วยเหลือ นั่นคือสถานการณ์ที่ embedding จาก LLM ช่วยได้มากที่สุด เพราะมันส่งมอบปฏิสัมพันธ์ของตัวแปรแบบที่ GLM หาเองไม่ได้โดยไม่ต้องเพิ่มฟิลด์ใหม่เลย แต่เมื่อข้อมูลมากขึ้นว่าโมเดลไหนชนะเริ่มขึ้นกับรายละเอียดปลีกย่อย เช่น รุ่น embedding และจำนวนมิติที่เก็บไว้ และเส้นแบ่งระหว่าง LLM กับโมเดลเชิงสถิติก็ขยับไปเรื่อยๆ เหมือนที่มันขยับทันทีในงานประกันภัยเมื่อข้อมูลฝั่งหนึ่งเริ่มบางลง
ยกระดับการประเมินเป็นวินัยวิศวกรรมเต็มตัว ก่อนข้อผิดพลาดไปเกิดในโลกจริง
ถ้าให้สรุปในประโยคเดียว โมเดลคือสมมติฐาน การประเมินคือการทดลอง และในการใช้งาน production การทดลองนี้ต้องได้มาตรฐานวิศวกรรมเดียวกับโมเดล ทั้งข้อมูลและเมตริกต้องมีเวอร์ชัน การครอบคลุมต้องจัดตามโหมดความล้มเหลว การรันต้องทำซ้ำได้ และค่าเกณฑ์ต้องมีอำนาจหยุดการปล่อยระบบ ผู้สร้างระบบรับรู้ในรถไร้คนขับพบว่า เมื่อปฏิบัติต่อการประเมินเหมือนระบบวิศวกรรมเต็มรูปแบบ มีการรีวิวออกแบบและความคาดหวังด้านความเชื่อถือ ไม่ใช่แค่สคริปต์ที่ใครสักคนรันก่อนประชุมปล่อยรุ่น ผลคือข้อผิดพลาดหลุดเข้าสู่ระบบ onboard น้อยลง เพราะ regression ถูกจับได้ที่ด่าน ก่อนหลุดไปถึงภาคสนาม และบทสนทนาเรื่องการปล่อยระบบเปลี่ยนจากการโต้แย้งตามสัญชาตญาณ มาเป็นการอภิปรายบนข้อมูลวัดผลที่แชร์ร่วมกันได้และทำซ้ำได้
แนวคิดเดียวกันนี้ควรถูกต่อยอดถึง model reliability testing สำหรับระบบที่ใช้ LLM และเอเจนต์ซับซ้อน ต้องมีทั้ง slice-based evaluation ที่จัดการกับความล้มเหลวเชิงเนื้อหาของคำตอบ และ execution-aware tracing ที่ทำให้เห็นโครง workflow เมื่อโมเดลเรียกเครื่องมือหรือทำงานเป็นกิ่งก้าน ไม่ใช่เพียงสายน้ำข้อความในล็อก เมื่อประกอบกับการเลือก LLM หรือโมเดลเชิงสถิติให้สอดคล้องกับรูปแบบข้อมูลและวิธีแทนข้อมูล เราจึงจะได้ระบบที่ไม่เพียงทำงานได้ดีบนสไลด์ แต่ยังทนต่อความหลากหลายของโลกจริง ลดความเสี่ยงของเหตุการณ์ปลายหางที่แพงและอันตรายเกินกว่าจะปล่อยให้ค่าเฉลี่ยกลบเกลื่อน