บทวิเคราะห์: Model Drift — เมื่อ AI ตรวจสอบคุณภาพในโรงงานเงียบๆ โง่ลง และวิธีตรวจจับด้วย PSI / Jensen-Shannon / Wasserstein ก่อนที่ Scrap Rate จะบอกคุณเอง

มีความล้มเหลวของ AI ในโรงงานอีกแบบหนึ่งที่เงียบกว่า outage และอันตรายกว่า bug — โมเดล vision ตรวจสอบคุณภาพที่เคยแม่นยำ 99% ในวัน go-live ค่อยๆ เสื่อมสภาพทีละนิดจนวันหนึ่ง scrap rate เริ่มไต่ขึ้นโดยไม่มี error message ใดๆ ปรากฏ ระบบยังเปิดอยู่ โมเดลยังตอบ แต่คำตอบนั้นเลื่อนจากความจริงไปเรื่อยๆ ปรากฏการณ์นี้คือ model drift และมันคือเหตุผลว่าทำไมโครงการ AI ในโรงงานจำนวนมากถึง “ตายหลังการผลิต” ทั้งที่ผ่าน UAT มาอย่างสวยงาม

ทำไมโมเดลในโรงงานถึงเสื่อมเร็วกว่าที่คิด

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

ประเด็นสำคัญที่หลายทีมพลาดคือ drift ไม่ได้แค่ “เกิดขึ้นได้” แต่เกิดขึ้น แน่นอน — คำถามมีเพียงว่าจะเร็วแค่ไหนและคุณจะรู้ตัวก่อนหรือหลังความเสียหาย และในเชิงปฏิบัติ เมื่อ label จริง (ground truth) ใน production หาได้ยากหรือช้า การเฝ้าดูการกระจายของข้อมูลนำเข้าจึงกลายเป็นสัญญาณตัวแทน (proxy signal) ที่ดีที่สุดที่เรามี

แยกให้ออก: Data Drift vs Concept Drift

ก่อนจะเฝ้าระวัง ต้องเข้าใจว่า drift มีสองตระกูลใหญ่ที่สาเหตุและวิธีรักษาต่างกัน ถ้าสับสนสองอย่างนี้จะแก้ผิดทาง

Data drift (หรือ covariate shift) คือการกระจายของ input features เปลี่ยนไปจากตอนเทรน — P(x) เปลี่ยน แต่ความสัมพันธ์ระหว่าง input กับ output ยังเหมือนเดิม ตัวอย่างโรงงานคือเปลี่ยน supplier วัสดุ ทำให้ค่าการสะท้อนแสงในภาพเลื่อนไปทางใดทางหนึ่ง ส่วน concept drift รุนแรงกว่า — ความสัมพันธ์ระหว่าง input กับ output เปลี่ยนไปเอง ใช้ค่าพารามิเตอร์เดิมแต่ผลลัพธ์ไม่เหมือนเดิม เช่น ฟิสิกส์ของกระบวนการเปลี่ยนเพราะเครื่องจักรผ่านการ overhau หรือสูตรเคมีถูกปรับ นอกจากนี้ยังมี prediction drift (การกระจายของผลทำนายเองเลื่อน) และ training-serving skew (pipeline เทรนกับ production ประมวลผลไม่เหมือนกัน) ที่ควรเฝ้าควบคู่กัน

เครื่องมือวัด: จากทฤษฎีสถิติสู่หน้างาน

การตรวจจับ drift วัดกันด้วย “ระยะห่าง” ระหว่างการกระจายของข้อมูลช่วงอ้างอิง (reference window ตอนที่โมเดลยังดี) กับช่วงปัจจุบัน เลือก metric ให้เหมาะกับลักษณะข้อมูล:

ค่าที่ออกมา (drift score) ยิ่งสูงยิ่งแปลว่าการกระจายห่างกันมาก บาง metric ให้สเกลสัมบูรณ์ บางอันให้ 0–1 — สิ่งสำคัญคือตั้ง threshold จากข้อมูลของตัวเอง ไม่ใช่ copy จากที่อื่น และเมื่อ metric ทุกตัวใช้หลักการเดียวกันคือ “เทียบสอง window” ทีมจึงเลือกผสมได้ตามชนิดของ sensor data

สถาปัตยกรรมการเฝ้าระวังที่เป็นวงปิด

การวัด drift ครั้งเดียวไม่พอ ต้องเป็นวงจรต่อเนื่อง แนวทางที่เราแนะนำคือ monitoring loop 5 ขั้น ที่รันคู่ไปกับระบบ AI ตลอดอายุการใช้งาน ไม่ใช่แค่ช่วงโครงการ

หัวใจของ loop นี้อยู่ที่ขั้นสุดท้าย — เมื่อ retrain เสร็จและ deploy ใหม่ โมเดลเวอร์ชันนั้นจะกลายเป็น reference window รอบใหม่ ทำให้เกณฑ์ “ปกติ” เลื่อนตามความจริงของสายการผลิตเสมอ ทีม MLOps ในบริษัทผลิตระดับโลกถึงกับนิยาม role และ pipeline เฉพาะเรื่องนี้อย่างชัดเจน — versioning, testing, CI/CD และ model monitoring with drift detection กลายเป็นความรับผิดชอบร่วมของทีมข้อมูลและทีมผลิต ไม่ใช่งาน “หลังโครงการ” ของ data scientist คนเดียว

บทเรียนจากงานติดตั้งระบบ IIoT ของ Honey Corporation คือระบบที่ดีที่สุดไม่ใช่ระบบที่แม่นที่สุดในวันแรก แต่คือระบบที่ “รู้ตัวว่ากำลังเสื่อม” ได้เร็วที่สุด เราจึงออกแบบ dashboard และ alert ให้ลูกค้ามองเห็นสุขภาพโมเดลควบคู่กับสุขภาพเครื่องจักร — เพราะในโรงงานยุคใหม่ โมเดล AI ก็คือสินทรัพย์ที่ต้องบำรุงรักษาเหมือน pump และ motor

Key Takeaways

• Model drift ไม่ใช่ความเสี่ยง แต่คือความแน่นอน — โมเดล production ทุกตัวเสื่อม คำถามคือรู้ตัวเร็วแค่ไหน
• แยก data drift กับ concept drift ให้ออก — P(x) เปลี่ยน (เปลี่ยน supplier/สภาพแสง) กับ P(y|x) เปลี่ยน (ฟิสิกส์กระบวนการเปลี่ยน) รักษาไม่เหมือนกัน
• เฝ้า proxy signal เมื่อไม่มี ground truth: การกระจายของ input features และ prediction score คือสัญญาณตัวแทนที่ดีที่สุด
• เลือก metric ตามชนิดข้อมูล: PSI สำหรับ tabular แบ่ง bin, Jensen-Shannon สำหรับเทียบหลาย distribution, Wasserstein สำหรับค่าต่อเนื่อง, KS-test สำหรับเช็คเดี่ยว
• ออกแบบเป็นวงปิด: เก็บ → เทียบ baseline → วัด → กระตุ้นเมื่อเกิน threshold → retrain → โมเดลใหม่กลายเป็น baseline ใหม่
• ทำเป็น pipeline ไม่ใช่โครงการ: องค์กรชั้นนำกำหนด drift monitoring เป็นส่วนของ MLOps responsibilities เคียงข้าง CI/CD
• มอง AI เป็นสินทรัพย์ที่ต้องดูแล: dashboard ควรแสดงสุขภาพโมเดลคู่กับ OEE ของเครื่องจักร