Machine Learning คืออะไรในงานจริง? จากโจทย์สู่โมเดลที่ตรวจสอบได้

อ่านจบบทนี้ คุณจะทำอะไรได้

• อธิบายความต่างระหว่างโมเดลกับระบบ Machine Learning ทั้งระบบได้
• วางบทบาทของ Train, Validation และ Test โดยไม่ทำให้ข้อมูลรั่วได้
• เลือก Baseline และ Metric ให้สัมพันธ์กับต้นทุนของความผิดพลาดได้
• ระบุสิ่งที่ต้องเฝ้าระวังหลัง Deployment และจุดที่มนุษย์ต้องรับผิดชอบได้

Machine Learning คืออะไรในความหมายที่ใช้ทำงานได้

คำตอบสั้นที่สุดคือ Machine Learning หรือการเรียนรู้ของเครื่อง เป็นวิธีสร้างระบบที่ปรับพฤติกรรมจากข้อมูลหรือประสบการณ์ เพื่อทำงานบางอย่างให้ดีขึ้นตามเกณฑ์ที่กำหนด

นิยามคลาสสิกของศาสตราจารย์ Tom Mitchell ช่วยเปลี่ยนคำว่า “เรียนรู้” ที่ฟังดูกว้างให้ตรวจสอบได้ โดยให้เราระบุสามส่วน:

• T — Task: งานที่ระบบต้องทำ เช่น แยกมะม่วงที่ควรส่งออกกับผลที่ต้องตรวจซ้ำ
• E — Experience: ประสบการณ์ที่ระบบได้รับ เช่น ภาพมะม่วงพร้อมผลการตรวจจากผู้เชี่ยวชาญ
• P — Performance measure: เกณฑ์วัดว่าทำได้ดีขึ้นหรือไม่ เช่น อัตราการตรวจพบผลมีตำหนิและอัตราการคัดของดีทิ้ง

หากเราอธิบายสามส่วนนี้ไม่ได้ ประโยคว่า “จะใช้ Machine Learning” ยังเป็นเพียงความตั้งใจ ไม่ใช่โจทย์ที่สร้างและทดสอบได้

ลองเปรียบเทียบกับการสอนพนักงานใหม่ เราไม่ได้บอกเพียงว่า “ช่วยคัดของให้เก่งขึ้น” แต่ต้องให้ดูตัวอย่าง อธิบายประเภทตำหนิ ให้ลองคัด แล้วตรวจว่าพลาดแบบใด โมเดลก็คล้ายกันตรงที่ต้องเรียนจากตัวอย่างและรับการประเมิน แต่ ไม่ได้หมายความว่าโมเดลเข้าใจมะม่วงเหมือนมนุษย์ มันค้นหารูปแบบทางสถิติที่ช่วยทำนายผลในข้อมูลซึ่งมันได้รับ

AI, Machine Learning และโมเดลไม่ใช่คำเดียวกัน

คำสามคำนี้มักถูกใช้แทนกันจนทำให้ขอบเขตงานสับสน:

โมเดลจึงเปรียบเหมือนเครื่องยนต์ ไม่ใช่รถทั้งคัน เครื่องยนต์ที่แรงไม่ได้รับประกันว่ารถจะปลอดภัย หากเบรก เซนเซอร์ ถนน และคนขับไม่พร้อม

จุดเริ่มต้นไม่ใช่อัลกอริทึม แต่คือการตัดสินใจ

โครงการ Machine Learning จำนวนมากเริ่มด้วยคำถามว่า “ควรใช้โมเดลอะไร” ทั้งที่คำถามก่อนหน้าสำคัญกว่า:

ระบบนี้จะช่วยใครตัดสินใจเรื่องอะไร และความผิดพลาดแบบใดมีต้นทุนสูงกว่า?

สำหรับโรงคัดมะม่วง คำว่า “คัดคุณภาพ” ยังคลุมเครือ เราต้องแปลงให้เป็นเหตุการณ์ที่สังเกตและบันทึกได้ เช่น:

• ส่งผลนี้เข้ากลุ่มส่งออก
• ส่งให้พนักงานตรวจซ้ำ
• แยกออกจากสายการผลิต
• ให้คะแนนชนิดและความรุนแรงของตำหนิ

เมื่อระบุการตัดสินใจแล้ว จึงถามต่อว่าใครได้รับผลกระทบ หากโมเดลพลาดผลเสียและปล่อยผ่าน ผู้ซื้อหรือผู้ส่งออกอาจรับความเสียหาย แต่หากโมเดลระแวงเกินไปและคัดผลดีทิ้ง เกษตรกรและโรงงานก็เสียรายได้ Metric ที่ดีจึงต้องสะท้อนต้นทุนทั้งสองด้าน ไม่ใช่เลือกตัวเลขที่สูงที่สุดเพียงตัวเดียว

เริ่มจาก Baseline ก่อนสร้างสิ่งซับซ้อน

Baseline คือผลงานอ้างอิงขั้นต่ำที่โมเดลใหม่ต้องเอาชนะ อาจเป็น:

• ขั้นตอนเดิมของมนุษย์
• กฎง่าย ๆ ที่ใช้อยู่
• การทายคลาสที่พบบ่อยที่สุด
• โมเดลพื้นฐานที่อธิบายง่าย

ถ้าระบบใหม่ใช้เวลาและต้นทุนมากกว่าเดิม แต่ไม่ได้ทำให้การตัดสินใจดีขึ้นอย่างมีความหมาย เราอาจยังไม่ควรนำไปใช้ Baseline จึงไม่ได้มีไว้ให้ดูด้อย แต่มีไว้ป้องกันไม่ให้ทีมหลงกับความซับซ้อนที่ไม่สร้างคุณค่า

แยก Metric ของโมเดลออกจาก Metric ของงาน

Metric ของโมเดล เช่น Precision, Recall หรือ Mean Absolute Error บอกคุณภาพการทำนายบางด้าน ส่วน Metric ของงาน เช่น จำนวนสินค้าร้องเรียน เวลาตรวจเฉลี่ย หรือมูลค่าของดีที่ถูกคัดทิ้ง บอกผลกระทบต่อกระบวนการจริง

ทั้งสองกลุ่มต้องเชื่อมกัน แต่ไม่ใช่สิ่งเดียวกัน โมเดลอาจมี Recall ดีขึ้น ขณะที่สายพานช้าลงจนเกิดคอขวดก็ได้ การประเมินที่ครบจึงต้องถามทั้ง “ทำนายแม่นแค่ไหน” และ “ช่วยงานจริงดีขึ้นหรือไม่”

เปิดกล่องดำ: วงจร Machine Learning 7 ขั้น

วงจรต่อไปนี้ไม่ใช่เส้นตรงที่เดินเพียงรอบเดียว เมื่อพบข้อมูลผิดหรือผลลัพธ์ไม่ตอบโจทย์ ทีมต้องย้อนกลับไปแก้ขั้นก่อนหน้า

1. กำหนด Task ผู้ใช้ และขอบเขตการตัดสินใจ

เขียนให้ชัดว่า:

• ข้อมูลอะไรจะเข้าระบบ
• ระบบต้องให้ผลลัพธ์อะไร
• ใครจะใช้ผลนั้น
• ต้องตอบภายในเวลาเท่าใด
• กรณีใดต้องส่งต่อให้มนุษย์

ตัวอย่างโจทย์ที่ตรวจสอบได้คือ “ใช้ภาพจากกล้องเหนือสายพานเพื่อจัดผลมะม่วงเป็น ‘ผ่าน’ หรือ ‘ตรวจซ้ำ’ ภายในเวลาที่ไม่ทำให้สายพานช้าลง โดยให้ผู้ตรวจคุณภาพเป็นผู้ตัดสินสุดท้ายในกรณีที่โมเดลไม่มั่นใจ”

2. เก็บข้อมูลและกำหนดความหมายของ Label

ข้อมูลที่มากแต่ความหมายไม่ตรงกันอาจแย่กว่าข้อมูลน้อยที่ตรวจสอบแล้ว ทีมต้องตกลงว่า “ตำหนิ” หมายถึงอะไร ใครมีสิทธิ์ติด Label และจะจัดการกรณีผู้เชี่ยวชาญเห็นต่างอย่างไร

ข้อมูลควรครอบคลุมสภาพที่จะพบจริง เช่น สายพันธุ์ ฤดูกาล สวน ขนาดผล กล้อง และแสง ไม่ใช่รวบรวมเฉพาะตัวอย่างที่ถ่ายง่ายในวันเดียว นอกจากนี้ต้องตรวจสิทธิ์ในการใช้ข้อมูล ความเป็นส่วนตัว และระยะเวลาจัดเก็บตั้งแต่ต้น

3. แบ่ง Train, Validation และ Test ก่อนเรียนรู้จากข้อมูล

หลักสำคัญคือชุด Test ต้องทำหน้าที่เหมือนข้อสอบที่โมเดลไม่เคยเห็น ไม่ควรนำผลจาก Test มาปรับโมเดลซ้ำไปเรื่อย ๆ เพราะเมื่อทำเช่นนั้น เรากำลัง “ติวตามข้อสอบ” โดยไม่รู้ตัว

การแบ่งข้อมูลต้องสะท้อนโลกจริงด้วย หากภาพของมะม่วงผลเดียวกันหลายมุมถูกสุ่มกระจายไปทั้ง Train และ Test คะแนนจะสูงเกินจริงเพราะโมเดลอาจจำลักษณะเฉพาะของผลนั้นได้ วิธีที่เหมาะกว่าคือแบ่งเป็นกลุ่มตามผล ล็อต สวน หรือช่วงเวลา ขึ้นอยู่กับสถานการณ์ที่จะนำไปใช้

4. สร้าง Baseline และเลือก Metric ก่อนทดลองหลายโมเดล

บันทึกผลของวิธีเดิมและกำหนดเกณฑ์ผ่านล่วงหน้า เช่น:

• ตรวจพบผลมีตำหนิได้มากพอหรือไม่
• ของดีถูกส่งไปตรวจซ้ำมากเกินไปหรือไม่
• เวลาตอบสนองเหมาะกับสายพานหรือไม่
• ผลลัพธ์แต่ละกลุ่มสวนหรือฤดูกาลต่างกันมากหรือไม่

การกำหนดก่อนเห็นผลช่วยลดโอกาสเลือกเฉพาะตัวเลขที่ทำให้โมเดลดูดี

5. ฝึกโมเดลและปรับ Hyperparameter บน Train กับ Validation

ชุด Train ใช้ปรับ Model parameter ซึ่งเป็นค่าที่โมเดลเรียนรู้จากข้อมูล ส่วน Hyperparameter คือการตั้งค่าที่ทีมกำหนด เช่น ความซับซ้อนของโมเดล อัตราการเรียนรู้ หรือเงื่อนไขหยุดฝึก

ทีมทดลองหลายทางเลือกบน Train และเปรียบเทียบบน Validation พร้อมจดบันทึกเวอร์ชันข้อมูล โค้ด การตั้งค่า และผลลัพธ์ การทดลองที่ทำซ้ำไม่ได้ยากต่อการตรวจสอบ แม้คะแนนครั้งแรกจะดูดีมากก็ตาม

6. เปิดชุด Test เมื่อเลือกแนวทางแล้ว

ชุด Test ใช้ประมาณว่าแนวทางที่เลือกจะทำงานกับข้อมูลใหม่ได้ดีเพียงใด หากผลแย่กว่าชุด Validation มาก ต้องหาสาเหตุ ไม่ควรรีบกลับไปปรับตาม Test ครั้งแล้วครั้งเล่า

คะแนน Test ก็ยังไม่ใช่คำรับรองตลอดไป เพราะมันสะท้อนเพียงประชากรและช่วงเวลาที่ข้อมูลชุดนั้นเป็นตัวแทน การทดสอบหน้างานแบบมีขอบเขตและทางย้อนกลับจึงยังจำเป็น

7. นำไปใช้ เฝ้าระวัง และเตรียมแผนเมื่อระบบเสื่อม

หลัง Deployment ทีมต้องติดตามอย่างน้อยสามชั้น:

1. ระบบทำงานหรือไม่ — กล้องส่งภาพครบไหม เวลาตอบสนองผิดปกติหรือไม่
2. ข้อมูลเปลี่ยนหรือไม่ — ความสว่าง สายพันธุ์ ฤดูกาล หรือรูปแบบตำหนิเปลี่ยนไปหรือไม่
3. คุณภาพการตัดสินใจเปลี่ยนหรือไม่ — ผลร้องเรียน อัตราตรวจซ้ำ และการยืนยันจากผู้เชี่ยวชาญแย่ลงหรือไม่

ต้องกำหนดว่าใครรับการแจ้งเตือน เมื่อใดควรหยุดใช้โมเดล จะย้อนกลับไปใช้วิธีเดิมอย่างไร และเงื่อนไขใดจึงฝึกโมเดลใหม่ ระบบที่ไม่มีเจ้าของหลังเปิดใช้งานกำลังสะสมความเสี่ยง แม้วันเปิดตัวจะทำงานดี

Train, Validation และ Test ทำหน้าที่ต่างกันอย่างไร

ลองนึกถึงการเตรียมตัวสอบ:

• Train set คือแบบฝึกหัดที่ใช้เรียนและแก้ความเข้าใจ
• Validation set คือข้อสอบซ้อมที่ใช้เลือกรูปแบบการเตรียมตัว
• Test set คือการสอบปลายภาคที่ใช้ประเมินแนวทางหลังเลือกแล้ว

เมื่อข้อมูลมีไม่มาก อาจใช้ Cross-validation โดยแบ่ง Train ออกเป็นหลายส่วนและสลับกันทำหน้าที่ฝึกกับตรวจสอบ วิธีนี้ช่วยดูว่าผลลัพธ์เสถียรเพียงใด แต่ยังควรมี Test ที่กันไว้สำหรับการประเมินขั้นสุดท้ายเมื่อเป็นไปได้

ป้องกัน Data Leakage ตั้งแต่ก่อน Preprocessing

Data Leakage คือข้อมูลที่ไม่ควรมีในเวลาทำนายจริงรั่วเข้าไปในกระบวนการฝึก ทำให้คะแนนทดสอบดูดีเกินจริง ตัวอย่างเช่น:

• ใช้ผลตรวจหลังคัดสินค้าเป็น Feature ทั้งที่ตอนทำนายยังไม่มีข้อมูลนั้น
• คำนวณค่าเฉลี่ยสำหรับเติมข้อมูลหายจากทั้ง Train และ Test
• ให้ภาพจากวัตถุเดียวกันอยู่ทั้งฝั่งฝึกและทดสอบ
• มีชื่อไฟล์หรือรหัสกระบวนการที่บอก Label โดยอ้อม

หลักปฏิบัติที่ช่วยลดความเสี่ยงคือ แยกข้อมูลก่อน แล้วให้ขั้นตอนที่ต้องเรียนค่าจากข้อมูล Fit บน Train เท่านั้น จากนั้นจึงใช้ค่าที่ได้แปลง Validation และ Test การใช้ Pipeline ช่วยบังคับลำดับนี้ให้สม่ำเสมอและลดความผิดพลาดจากการทำด้วยมือ

ทำไมโมเดลคะแนนสูงจึงยังใช้จริงไม่ได้

Accuracy อาจซ่อนความผิดพลาดสำคัญ

สมมติว่ามะม่วงมีตำหนิรุนแรงเป็นส่วนน้อย โมเดลที่ทายว่า “ผ่าน” เกือบทุกผลอาจได้ Accuracy สูง แต่ตรวจจับของเสียแทบไม่ได้ ในกรณีนี้ Recall ของกลุ่มตำหนิและจำนวนผลเสียที่หลุดผ่านอาจสำคัญกว่า Accuracy รวม

Metric จึงเป็นการประกาศว่าเราให้คุณค่ากับความผิดพลาดแบบใด ไม่มี Metric เดียวที่ดีที่สุดสำหรับทุกปัญหา:

• Precision ช่วยตอบว่า ในสิ่งที่โมเดลแจ้งเตือน มีของเสียจริงมากเพียงใด
• Recall ช่วยตอบว่า จากของเสียทั้งหมด โมเดลค้นพบได้มากเพียงใด
• False positive rate ช่วยดูว่าของดีถูกเตือนว่าเสียผิดบ่อยเพียงใด
• Latency ช่วยดูว่าระบบตอบทันกระบวนการหรือไม่
• Cost-based metric ช่วยรวมผลกระทบที่มีต้นทุนไม่เท่ากัน

ทีมอาจต้องใช้หลาย Metric และกำหนด Threshold ตามความเสี่ยง แทนการไล่เพิ่มคะแนนตัวเดียว

ข้อมูลทดสอบอาจง่ายกว่าโลกจริง

ถ้าชุด Test มาจากกล้อง รุ่นแสง และสวนเดียวกับ Train มันอาจไม่สะท้อนการใช้งานกับสวนใหม่หรือฤดูใหม่ การสุ่มแบ่งข้อมูลไม่ใช่คำตอบอัตโนมัติ เราต้องเลือกวิธีแบ่งให้ตรงกับคำถามว่า “ข้อมูลใหม่” ในงานจริงหมายถึงอะไร

หากต้องทำนายอนาคต การแบ่งตามเวลามักสมจริงกว่าการสุ่ม หากต้องใช้กับลูกค้ารายใหม่ การแยกตามลูกค้าหรือสถานที่อาจสำคัญกว่า

โลกเปลี่ยนหลังโมเดลถูกฝึก

เมื่อกล้องถูกเปลี่ยน ตำหนิชนิดใหม่เกิดขึ้น หรือมาตรฐานการส่งออกเปลี่ยน ความสัมพันธ์ที่โมเดลเรียนไว้อาจไม่เหมือนเดิม ปัญหานี้เรียกโดยรวมว่า Drift และอาจเกิดกับข้อมูลนำเข้า ความสัมพันธ์ระหว่างข้อมูลกับ Label หรือพฤติกรรมของผู้ใช้ระบบ

โมเดลจึงไม่มีวัน “เสร็จถาวร” การติดตามการเปลี่ยนแปลงและทบทวนความเหมาะสมเป็นส่วนหนึ่งของผลิตภัณฑ์ ไม่ใช่งานบำรุงรักษาที่ค่อยคิดภายหลัง

โมเดลเป็นเพียงส่วนหนึ่งของระบบผลิตจริง

เอกสาร Production ML Systems ของ Google ชี้ให้เห็นว่าในระบบจริง โค้ดส่วนโมเดลอาจเป็นเพียงสัดส่วนเล็กของโค้ดทั้งหมด ส่วนที่เหลือคือการเก็บข้อมูล ตรวจสอบข้อมูล จัดการ Feature ให้บริการคำทำนาย เฝ้าระวัง และดูแลโครงสร้างพื้นฐาน

ข้อสรุปไม่ได้อยู่ที่ตัวเลขสัดส่วนเพียงอย่างเดียว แต่อยู่ที่วิธีคิด: ความสำเร็จของ ML ขึ้นกับระบบรอบโมเดลอย่างน้อยพอ ๆ กับตัวโมเดล

กรณีศึกษา: ออกแบบระบบคัดมะม่วงแบบไม่หลงคะแนน

ต่อไปนี้เป็นตัวอย่างสมมติสำหรับฝึกวางระบบ ไม่ใช่ผลการทดลองจากโรงงานจริง

ขั้นที่ 1: เขียนการตัดสินใจให้ชัด

แทนโจทย์ว่า “หาโมเดลมาคัดมะม่วง” ทีมเขียนใหม่ว่า:

ระบบรับภาพจากกล้องบนสายพานและเสนอผล “ผ่าน” หรือ “ตรวจซ้ำ” ผู้ตรวจคุณภาพเป็นผู้ตัดสินสุดท้ายสำหรับกลุ่มตรวจซ้ำ เป้าหมายคือค้นหาผลที่มีตำหนิสำคัญให้มากขึ้น โดยไม่เพิ่มอัตราการส่งผลดีไปตรวจซ้ำจนเกินกำลังคน

ประโยคนี้บอก Input, Output, ผู้ใช้, จุดที่มนุษย์รับช่วง และ Trade-off ที่ต้องวัด

ขั้นที่ 2: สร้าง Data map

ทีมทำแผนที่ข้อมูลก่อนเก็บ:

• ภาพมาจากกล้องใดและมีการตั้งค่าอย่างไร
• หนึ่งผลมีภาพกี่มุม
• Label มาจากผู้ตรวจคนใด
• หากผู้ตรวจสองคนเห็นต่าง จะตัดสินอย่างไร
• มีสวน สายพันธุ์ ฤดูกาล และระดับความสุกใดบ้าง
• ข้อมูลใดจะไม่มีในวันใช้งานจริง

Data map ช่วยให้เห็นช่องว่าง เช่น มีภาพมากแต่แทบทั้งหมดมาจากสวนเดียว หรือมี Label “มีตำหนิ” แต่ไม่รู้ว่าตำหนิชนิดใดทำให้โมเดลพลาด

ขั้นที่ 3: แบ่งข้อมูลตามหน่วยที่ไม่ควรรั่ว

หากหนึ่งผลมีหลายภาพ ต้องให้ภาพทั้งหมดของผลนั้นอยู่ชุดเดียวกัน ทีมอาจกันล็อตจากช่วงเวลาหลังสุดไว้เป็น Test เพื่อจำลองการเจอผลผลิตใหม่ และใช้ล็อตก่อนหน้าสำหรับ Train กับ Validation

การออกแบบนี้อาจทำให้คะแนนต่ำกว่าการสุ่มภาพ แต่เป็นคะแนนที่ตอบคำถามจริงกว่า

ขั้นที่ 4: กำหนด Baseline และเกณฑ์ผ่าน

Baseline อาจเป็นผลการทำงานของขั้นตอนคัดเดิมในช่วงทดสอบเดียวกัน ทีมไม่จำเป็นต้องบังคับให้โมเดลตัดสินทุกผลตั้งแต่วันแรก อาจเริ่มจากโหมดแนะนำ ให้โมเดลส่งเฉพาะกรณีที่มั่นใจหรือกรณีเสี่ยงไปยังผู้ตรวจ

เกณฑ์ประเมินควรครอบคลุม:

• Recall ของตำหนิสำคัญแต่ละชนิด
• อัตราของดีที่ถูกส่งไปตรวจซ้ำ
• เวลาตอบสนองต่อภาพ
• ประสิทธิภาพแยกตามสวน ฤดูกาล และสภาพแสง
• ผลต่อเวลางานและข้อร้องเรียน

ขั้นที่ 5: ทดลองแบบมีบันทึกและวิเคราะห์ข้อผิดพลาด

เมื่อโมเดล A ชนะโมเดล B ทีมไม่ควรดูเพียงค่าเฉลี่ย แต่ควรเปิดดูตัวอย่างที่พลาดและจัดกลุ่มสาเหตุ เช่น แสงสะท้อน ตำหนิเล็กใกล้ขั้ว ภาพเบลอ หรือผลซ้อนกัน

การวิเคราะห์ข้อผิดพลาดบอกทีมว่าควร:

• เก็บข้อมูลเพิ่ม
• แก้กล้องหรือแสง
• ปรับนิยาม Label
• แยกโจทย์ออกเป็นหลายขั้น
• หรือยอมรับว่ากรณีนี้ควรให้มนุษย์ตัดสิน

บางครั้งการปรับกระบวนการถ่ายภาพสร้างผลลัพธ์มากกว่าการเปลี่ยนโมเดล

ขั้นที่ 6: ทดลองหน้างานแบบมีทางย้อนกลับ

ก่อนให้โมเดลควบคุมสายพาน ทีมอาจเปิด Shadow mode ให้ระบบทำนายโดยยังไม่ส่งผลไปตัดสินจริง แล้วเปรียบเทียบกับผู้ตรวจ เมื่อเข้าใจรูปแบบความผิดพลาดจึงทดลองกับบางช่วงเวลา พร้อมกำหนดปุ่มหยุดและวิธีกลับไปใช้ขั้นตอนเดิม

ขั้นที่ 7: เฝ้าระวังสิ่งที่เชื่อมกับความเสียหาย

Dashboard ที่ดีไม่ควรมีเพียงจำนวนคำทำนาย แต่ต้องช่วยตอบว่า:

• สัดส่วนภาพมืดหรือเบลอเพิ่มขึ้นหรือไม่
• คะแนนความมั่นใจเปลี่ยนจากช่วงฝึกหรือไม่
• ผู้ตรวจแก้คำตอบของโมเดลบ่อยขึ้นในกลุ่มใด
• ข้อร้องเรียนปลายทางเพิ่มขึ้นหรือไม่
• โมเดลรุ่นนี้ฝึกจากข้อมูลถึงวันใด

เมื่อ Metric ผิดปกติ ระบบควรมีผู้รับผิดชอบและขั้นตอนตอบสนอง ไม่ใช่เพียงส่งแจ้งเตือนที่ไม่มีใครเป็นเจ้าของ

Machine Learning เรียนรู้ได้หลายรูปแบบ

คำว่า Machine Learning ครอบคลุมวิธีเรียนหลายแบบ สิ่งที่ต่างกันสำคัญคือ สัญญาณที่ใช้บอกว่าควรปรับตัวอย่างไร

บทนี้เน้นวงจรที่ใช้ร่วมกัน ส่วนบทถัดไปจะเจาะ Supervised Learning ซึ่งเป็นรูปแบบที่ตรงกับตัวอย่างภาพพร้อม Label มากที่สุด

ข้อจำกัด ความเสี่ยง และบทบาทของมนุษย์

Machine Learning ทำให้ระบบค้นหารูปแบบที่เขียนเป็นกฎด้วยมือได้ยาก แต่ไม่ได้แปลว่า รูปแบบที่พบถูกต้อง ยุติธรรม หรือใช้ได้ตลอดไป

ข้อมูลสะท้อนสิ่งที่ถูกเก็บ ไม่ใช่โลกทั้งหมด

หากข้อมูลขาดสวนขนาดเล็ก ตำหนิหายาก หรือสภาพแสงบางแบบ โมเดลไม่สามารถเรียนสิ่งที่ไม่เคยเห็นได้อย่างน่าเชื่อถือ การเพิ่มข้อมูลควรเริ่มจากช่องว่างและข้อผิดพลาด ไม่ใช่เพิ่มปริมาณแบบไม่รู้ว่าเพิ่มอะไร

Label อาจมีความไม่แน่นอน

ผู้เชี่ยวชาญอาจเห็นต่าง โดยเฉพาะกรณีขอบเขต การบังคับให้ทุกตัวอย่างมีคำตอบเดียวโดยไม่เก็บความเห็นต่างอาจทำให้โมเดลดูมั่นใจเกินจริง ทีมควรบันทึกกติกา ผู้ให้ Label และความไม่แน่นอนที่สำคัญ

Feedback loop อาจเปลี่ยนข้อมูลในอนาคต

เมื่อระบบเลือกส่งเฉพาะกรณีที่โมเดลสงสัยไปให้มนุษย์ตรวจ ข้อมูลใหม่ที่ได้จะกระจุกในกรณีเหล่านั้น เราอาจมองไม่เห็นความผิดพลาดในสิ่งที่โมเดลปล่อยผ่าน กระบวนการสุ่มตรวจบางส่วนจึงยังมีคุณค่า

ความเป็นส่วนตัวและสิทธิในการใช้ข้อมูลต้องคิดตั้งแต่ต้น

แม้ตัวอย่างมะม่วงจะไม่ใช่ข้อมูลส่วนบุคคล แต่โครงการอื่นอาจใช้ใบหน้า เสียง สุขภาพ พฤติกรรมลูกค้า หรือตำแหน่งที่ตั้ง การเก็บข้อมูล “เผื่อไว้ก่อน” เพิ่มทั้งความเสี่ยงและภาระดูแล ควรเก็บเท่าที่จำเป็น กำหนดสิทธิ์เข้าถึง ระยะเวลาเก็บ และวัตถุประสงค์ที่ชัดเจน

ระบบต้องมีเจ้าของและช่องทางคัดค้าน

หากผลทำนายมีผลต่อคน เช่น การอนุมัติสินเชื่อ การรับเข้าทำงาน หรือการรักษา ผู้ได้รับผลกระทบควรรู้ว่าผลถูกนำไปใช้อย่างไร มีมนุษย์รับผิดชอบ และมีช่องทางทบทวนการตัดสินใจ ความเสี่ยงสูงยิ่งต้องทดสอบ เอกสาร และเฝ้าระวังเข้มกว่ากรณีแนะนำเพลงหรือจัดหมวดภาพ

กรอบบริหารความเสี่ยง AI ของ NIST จัดการงานเหล่านี้เป็นวงจรต่อเนื่องผ่านการกำกับ ดูบริบท วัด และจัดการความเสี่ยง ไม่ใช่ Checklist ที่ติ๊กครั้งเดียวก่อนเปิดระบบ

Checklist ก่อนเชื่อว่าโมเดลพร้อมใช้งาน

ใช้คำถามต่อไปนี้ในการ Review โครงการก่อน Deployment:

• □การตัดสินใจ: เราระบุชัดหรือยังว่าระบบช่วยใครตัดสินใจอะไร
• □ขอบเขต: เรารู้หรือไม่ว่ากรณีใดอยู่นอกขอบเขตและต้องส่งให้มนุษย์
• □ข้อมูล: Train, Validation และ Test เป็นตัวแทนสภาพใช้งานจริงเพียงใด
• □การรั่วของข้อมูล: มี Feature หรือขั้นตอน Preprocessing ใดใช้ข้อมูลที่วันทำนายจริงจะไม่มีหรือไม่
• □Baseline: โมเดลชนะวิธีเดิมหรือวิธีง่ายอย่างมีความหมายหรือยัง
• □Metric: ตัวชี้วัดสะท้อนต้นทุนของความผิดพลาดแต่ละแบบหรือไม่
• □กลุ่มย่อย: ผลลัพธ์แตกต่างกันมากระหว่างเวลา สถานที่ อุปกรณ์ หรือกลุ่มผู้ใช้หรือไม่
• □การทำซ้ำ: เรารู้หรือไม่ว่าโมเดลฝึกจากข้อมูล โค้ด และค่าตั้งเวอร์ชันใด
• □การทดลองหน้างาน: มี Shadow mode, Pilot หรือการเปิดใช้ทีละส่วนหรือไม่
• □Monitoring: มีสัญญาณใดบอกว่าข้อมูลหรือคุณภาพกำลังเปลี่ยน
• □ผู้รับผิดชอบ: ใครเป็นเจ้าของการแจ้งเตือน การทบทวน และการอนุมัติรุ่นใหม่
• □ทางย้อนกลับ: หากระบบผิดปกติ เราหยุดหรือกลับไปใช้วิธีเดิมได้อย่างไร

ถ้าคำตอบสำคัญหลายข้อยังเป็น “ไม่รู้” ปัญหาไม่ได้แปลว่าต้องหาโมเดลที่เก่งกว่าเสมอไป แต่อาจหมายถึงโครงการยังไม่พร้อมกำหนดความสำเร็จและความรับผิดชอบ

ความเข้าใจผิดที่ทำให้โครงการ Machine Learning หลงทาง

“ข้อมูลยิ่งมากยิ่งดี”

ข้อมูลมากช่วยได้เมื่อมีความเกี่ยวข้อง คุณภาพเหมาะสม และครอบคลุมการใช้งานจริง ข้อมูลซ้ำจำนวนมากจากสภาพเดิมอาจเพิ่มต้นทุนโดยไม่เพิ่มความสามารถ ขณะที่ข้อมูลส่วนน้อยจากฤดูกาลหรืออุปกรณ์ใหม่อาจมีคุณค่ากว่า

คำถามที่ดีกว่าคือ “ข้อผิดพลาดปัจจุบันบอกว่าเราขาดข้อมูลแบบใด”

“Accuracy สูงสุดคือโมเดลที่ดีที่สุด”

Accuracy ให้น้ำหนักความผิดพลาดทุกตัวอย่างเท่ากันและอาจถูกครอบงำโดยกลุ่มใหญ่ โมเดลที่เหมาะต้องผ่านข้อจำกัดของงาน เช่น Recall ขั้นต่ำ Latency งบประมาณ ความสามารถในการอธิบาย และผลต่อกลุ่มย่อย

คำถามที่ดีกว่าคือ “Metric ชุดใดสะท้อนความเสียหายจริง และ Trade-off ใดเรายอมรับได้”

“ทดสอบผ่านแล้ว งานจบ”

ชุด Test เป็นภาพถ่ายของเงื่อนไขช่วงหนึ่ง เมื่อโลกเปลี่ยน คะแนนเดิมไม่รับประกันผลใหม่ Deployment จึงเป็นจุดเริ่มของวงจรสังเกตผล เก็บหลักฐาน และปรับปรุง ไม่ใช่เส้นชัย

คำถามที่ดีกว่าคือ “เราจะรู้ได้อย่างไรว่าโมเดลเริ่มไม่เหมาะ และใครต้องทำอะไรต่อ”

“โมเดลซับซ้อนกว่าย่อมฉลาดกว่า”

โมเดลซับซ้อนอาจจับรูปแบบละเอียดได้ แต่ใช้ทรัพยากรมาก อธิบายยาก และเสี่ยง Overfitting หากข้อมูลไม่พอ หากโมเดลง่ายผ่านเกณฑ์งาน มีเสถียรภาพ และดูแลถูกกว่า ความง่ายอาจเป็นข้อได้เปรียบ

คำถามที่ดีกว่าคือ “ความซับซ้อนที่เพิ่มขึ้นซื้อผลลัพธ์ที่มีความหมายมากพอหรือไม่”

แบบฝึกคิด: สร้าง ML Project Card ในหนึ่งหน้า

เลือกปัญหาใกล้ตัวหนึ่งเรื่อง เช่น คัดอีเมล จัดหมวดเอกสาร คาดการณ์จำนวนสินค้า หรือช่วยตรวจภาพ แล้วกรอกข้อความต่อไปนี้โดยยังไม่ต้องเขียนโค้ด:

1. Decision: ระบบจะช่วยใครตัดสินใจอะไร
2. Input: ตอนใช้งานจริง ระบบจะเห็นข้อมูลอะไร
3. Output: ต้องให้ผลในรูป Class, Score, Ranking หรือค่าตัวเลข
4. Experience: ข้อมูลฝึกมาจากไหน ใครเป็นเจ้าของ และ Label เกิดอย่างไร
5. Baseline: วิธีเดิมหรือวิธีง่ายทำได้ดีเพียงใด
6. Cost of errors: การเตือนผิดว่าของดีเป็นของเสีย (False positive) และการปล่อยของเสียผ่าน (False negative) กระทบใครบ้าง
7. Evaluation: จะใช้ Metric ใด และจะแบ่ง Test ให้เหมือนโลกจริงอย่างไร
8. Human role: กรณีใดมนุษย์ต้องตรวจ ยืนยัน หรือคัดค้าน
9. Monitoring: สัญญาณใดบอกว่าข้อมูลและคุณภาพเปลี่ยน
10. Fallback: ถ้าระบบล้มเหลว จะกลับไปใช้กระบวนการใด

หาก Card ยังตอบไม่ได้บางข้อ ให้ถือว่านั่นคือรายการค้นคว้ารอบถัดไป ไม่ใช่ช่องว่างที่ควรเดา การทำแบบฝึกนี้ก่อนเลือก Library หรือโมเดลมักช่วยลดงานย้อนกลับภายหลัง

บทเรียนสำคัญและคำถามที่พบบ่อย

แก่นของ Machine Learning ไม่ใช่การทำให้คอมพิวเตอร์ “รู้คำตอบ” แต่คือการสร้างวงจรที่เชื่อม:

โจทย์ที่วัดได้ → ข้อมูลที่เป็นตัวแทน → การเรียนรู้ที่แยกจากการสอบ → Metric ที่สะท้อนความเสียหาย → การใช้งานที่มีคนรับผิดชอบ → การเฝ้าระวังเมื่อโลกเปลี่ยน

ความผิดพลาดจำนวนมากเกิดเมื่อทีมตัดบางช่วงออก เช่น มีข้อมูลแต่ไม่มีนิยาม Label มีคะแนนแต่ไม่มี Baseline มี Test แต่ข้อมูลรั่ว หรือมี Deployment แต่ไม่มี Monitoring การมองทั้งวงจรช่วยให้เราเปลี่ยนจากคำถาม “โมเดลไหนเก่งที่สุด” เป็น “ระบบนี้ให้หลักฐานเพียงพอสำหรับการตัดสินใจนี้หรือยัง”

Machine Learning ต่างจากการเขียนกฎทั่วไปอย่างไร

การเขียนกฎกำหนดเงื่อนไขโดยมนุษย์ เช่น ถ้าอุณหภูมิสูงกว่าค่าหนึ่งให้แจ้งเตือน ส่วน Machine Learning ให้โมเดลเรียนความสัมพันธ์จากตัวอย่าง เหมาะกับรูปแบบที่ซับซ้อนหรือเขียนกฎให้ครอบคลุมได้ยาก อย่างไรก็ตาม ระบบจริงมักใช้ทั้งสองร่วมกัน เช่น ใช้โมเดลให้คะแนนและใช้กฎความปลอดภัยกำหนดกรณีห้ามทำอัตโนมัติ

ต้องมีข้อมูลมากแค่ไหนจึงเริ่มทำ Machine Learning ได้

ไม่มีจำนวนเดียวที่ตอบได้ เพราะขึ้นกับความซับซ้อนของโจทย์ ความหลากหลายของข้อมูล คุณภาพ Label และโมเดลที่ใช้ จุดเริ่มที่ดีกว่าคือสร้าง Baseline และ Learning curve เพื่อดูว่าการเพิ่มข้อมูลยังช่วยหรือไม่ พร้อมวิเคราะห์ว่าข้อมูลใหม่เพิ่มความหลากหลายที่ขาดอยู่หรือเพียงทำซ้ำของเดิม

Validation กับ Test รวมเป็นชุดเดียวได้ไหม

โครงการทดลองขนาดเล็กอาจทำเช่นนั้นเพราะข้อจำกัดข้อมูล แต่จะเสี่ยงประเมินสูงเกินจริงเมื่อใช้ชุดเดียวทั้งเลือกและตัดสินโมเดล หากผลมีความสำคัญ ควรกัน Test ไว้ หรือใช้ Cross-validation สำหรับการเลือกแนวทางแล้วประเมินกับข้อมูลภายนอกหรือช่วงเวลาที่กันไว้

จำเป็นต้องใช้โมเดล Deep Learning หรือไม่

ไม่จำเป็น โมเดลที่เหมาะคือโมเดลที่ผ่านเกณฑ์งานภายใต้ข้อจำกัดจริง หากข้อมูลเป็นตารางขนาดไม่ใหญ่ โมเดลพื้นฐานอาจฝึกเร็ว อธิบายง่าย และเพียงพอ Deep Learning มีประโยชน์มากในงานอย่างภาพ เสียง หรือภาษาบางประเภท แต่ยังต้องพิสูจน์ด้วย Baseline และการทดสอบที่ถูกต้อง

เมื่อใดไม่ควรใช้ Machine Learning

หากกฎของงานชัดและเปลี่ยนน้อย ข้อมูลไม่พอหรือใช้ไม่ได้อย่างถูกต้อง ความผิดพลาดยอมรับไม่ได้แต่ตรวจสอบผลไม่ได้ หรือไม่มีเจ้าของดูแลหลังใช้งาน วิธีแบบกฎ การปรับกระบวนการ หรือการให้มนุษย์ตัดสินอาจเหมาะกว่า การไม่ใช้ ML ในโจทย์ที่ไม่พร้อมเป็นการตัดสินใจทางวิศวกรรมที่ดี ไม่ใช่ความล้มเหลว

แบบทดสอบความเข้าใจ: วงจร Machine Learning

เลือกคำตอบที่เหมาะสมที่สุดให้ครบทั้ง 5 ข้อ แล้วกด ตรวจคำตอบ ระบบจะแสดงคะแนนรวม พร้อมเฉลยและเหตุผลของแต่ละข้อ

1. ก่อนเลือกอัลกอริทึมหรือโมเดล ทีมควรทำสิ่งใดก่อน?

ก. ระบุการตัดสินใจ ผู้ใช้ และต้นทุนของความผิดพลาดให้ชัดเจน ข. เลือกโมเดลที่ซับซ้อนที่สุดไว้ก่อน ค. รวบรวมข้อมูลให้มากที่สุดโดยยังไม่กำหนด Label ง. ใช้ Accuracy เป็นเกณฑ์เดียวเพื่อให้เปรียบเทียบง่าย

2. ชุด Test มีหน้าที่สำคัญที่สุดอย่างไร?

ก. ใช้เรียนรู้ Model parameter ระหว่างการฝึก ข. ใช้เลือก Hyperparameter ทุกครั้งที่ทดลอง ค. ใช้ประเมินแนวทางสุดท้ายกับข้อมูลที่ไม่ได้ใช้เลือกหรือปรับโมเดล ง. ใช้แทนข้อมูลจริงหลังนำระบบไปใช้งานแล้ว

3. เหตุใดภาพหลายมุมของมะม่วงผลเดียวกันจึงไม่ควรถูกสุ่มกระจายไปทั้ง Train และ Test?

ก. เพราะชุด Train ต้องมีภาพเพียงมุมเดียวต่อวัตถุ ข. เพราะโมเดลอาจจำลักษณะเฉพาะของผลเดิม ทำให้คะแนน Test สูงเกินจริง ค. เพราะชุด Test ต้องมีจำนวนภาพมากกว่าชุด Train เสมอ ง. เพราะภาพทุกมุมต้องถูกจัดไว้ในชุด Validation เท่านั้น

4. เพราะเหตุใด Accuracy เพียงค่าเดียวจึงอาจไม่พอสำหรับตัดสินว่าโมเดลพร้อมใช้งาน?

ก. เพราะ Accuracy ใช้ได้กับข้อมูลภาพเท่านั้น ข. เพราะ Accuracy ต้องมีค่าเท่ากับ 100% จึงจะเชื่อถือได้ ค. เพราะ Accuracy วัดความเร็วของระบบ แต่ไม่วัดคุณภาพการทำนาย ง. เพราะความผิดพลาดแต่ละแบบมีต้นทุนต่างกัน และข้อมูลอาจมีสัดส่วนแต่ละกลุ่มไม่เท่ากัน

5. หลังนำโมเดลไปใช้งานจริง ทีมควรทำสิ่งใดต่อ?

ก. หยุดเก็บข้อมูลเพื่อไม่ให้ผลประเมินเดิมเปลี่ยน ข. ใช้คะแนน Test เดิมเป็นหลักฐานว่าโมเดลจะทำงานดีตลอดไป ค. เฝ้าระวังระบบ ข้อมูล และคุณภาพการตัดสินใจ พร้อมกำหนดผู้รับผิดชอบและทางย้อนกลับ ง. ปรับโมเดลทันทีทุกครั้งที่ข้อมูลหนึ่งรายการเปลี่ยน

ตรวจคำตอบ ทำแบบทดสอบใหม่

ยังไม่ได้ตรวจคำตอบ เลือกคำตอบแล้วกดปุ่มตรวจคำตอบเพื่อดูคะแนน

สรุป: จาก “โมเดลแม่นไหม” สู่ “ระบบน่าเชื่อถือพอหรือยัง”

ย้อนกลับไปที่โรงคัดมะม่วง ตัวเลข Accuracy ที่ดูดีไม่ได้ตอบว่าระบบพร้อมใช้งาน เพราะคำถามจริงครอบคลุมมากกว่านั้น: ข้อมูลแทนสวนและฤดูกาลใหม่หรือไม่ ตำหนิชนิดสำคัญถูกตรวจพบเพียงใด ของดีถูกคัดทิ้งมากแค่ไหน พนักงานรับช่วงกรณีไม่แน่ใจได้หรือไม่ และเมื่อกล้องหรือผลผลิตเปลี่ยน ใครจะรู้ก่อนเกิดความเสียหาย

เมื่อเข้าใจ Machine Learning เป็นวงจร เราจะไม่เริ่มจากการตามหาอัลกอริทึมที่ดังที่สุด แต่เริ่มจากการตัดสินใจที่ต้องช่วย กำหนดประสบการณ์และเกณฑ์วัด แยกการฝึกออกจากการสอบ แล้วสร้างระบบที่เฝ้าดูและย้อนกลับได้

โมเดลที่ดีจึงไม่ใช่โมเดลที่มีคะแนนสูงที่สุดบนไฟล์หนึ่งชุด แต่คือส่วนหนึ่งของระบบที่ให้หลักฐานเพียงพอ รู้ขอบเขตของตนเอง และเปิดพื้นที่ให้มนุษย์รับผิดชอบต่อผลลัพธ์

ภาพสรุปบทเรียน

เรียนต่อใน PATH 09

บทนี้ทำให้เราเห็นวงจร Machine Learning ทั้งระบบแล้ว บทถัดไปจะเจาะ Supervised Learning ว่าโมเดลเรียนจากตัวอย่างที่มี Label อย่างไร งาน Classification กับ Regression ต่างกันตรงไหน และเราควรตรวจคุณภาพ Label ก่อนฝึกอย่างไร

ดู Learning Pack ของ PATH 09: พื้นฐาน Machine Learning

แหล่งข้อมูลอ้างอิง

• Tom M. Mitchell, Machine Learning, McGraw-Hill, 1997 — ใช้เป็นฐานนิยาม Task, Experience และ Performance measure
• scikit-learn, Cross-validation: Evaluating estimator performance — หลักการแยกข้อมูลฝึกและข้อมูลทดสอบ
• scikit-learn, Common pitfalls and recommended practices — Data Leakage, การทำ Preprocessing และ Pipeline
• scikit-learn, Metrics and scoring: Quantifying the quality of predictions — การเลือก Metric สำหรับงานประเภทต่าง ๆ
• Google for Developers, Production ML Systems — องค์ประกอบของระบบ Machine Learning ในการใช้งานจริง
• Google for Developers, Monitoring ML models in production — การเฝ้าระวังข้อมูล ประสิทธิภาพ และคุณภาพหลัง Deployment
• D. Sculley et al., Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015 — ความซับซ้อนและหนี้ทางเทคนิครอบระบบ ML
• Eric Breck et al., The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction, 2017 — แนวคิดการทดสอบและความพร้อมก่อนใช้งานจริง
• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023 — การกำกับ วัด เฝ้าระวัง และจัดการความเสี่ยงตลอดวงจรชีวิต

ตรวจสอบแหล่งข้อมูลล่าสุด: 31 กรกฎาคม 2026 หมายเหตุบรรณาธิการ: ตัวอย่างโรงคัดมะม่วงเป็นสถานการณ์สมมติเพื่ออธิบายกระบวนการ ไม่ใช่รายงานผลจากองค์กรหรือระบบที่ใช้งานจริง

หมายเหตุภาพประกอบ: ภาพ Featured Image ภาพ Train–Validation–Test และ Infographic สร้างด้วย OpenAI ImageGen โดยใช้ Character Sheet ของ SHIRO และภาพอ้างอิงสไตล์ AI Academy ภายในโครงการ รายละเอียด Prompt, Reference และ Visual QA บันทึกไว้ใน website-assets/machine-learning-workflow-inline/imagegen-prompts-topic-401.md