Model drift

Model drift คืออาการที่ระบบ machine-learning ซึ่งเคยทำงานได้แม่นตอนเปิดใช้ ค่อยๆ ทำนายพลาดมากขึ้นเมื่อเวลาผ่านไป ทั้งที่ไม่มีใครไปแก้โค้ดหรือเปลี่ยนตัวโมเดลเลยสักบรรทัด ต้นเหตุอยู่นอกตัวระบบ คือโลกจริงเคลื่อนออกจากสมมติฐานที่โมเดลเรียนมาตอนเทรน เอกสาร Playbook ของ nist-ai-rmf อธิบายเรื่องนี้ไว้ในหัวข้อ MEASURE 2.4 ว่าระบบ AI อาจเจอปัญหาและความเสี่ยงใหม่ระหว่างที่รันอยู่จริง เมื่อสภาพแวดล้อมเปลี่ยนไปตามเวลา และเรียกผลข้างเคียงนี้ว่า drift ซึ่งหมายถึงระบบไม่เข้ากับสมมติฐานและข้อจำกัดของการออกแบบเดิมอีกต่อไป ในกรอบเดียวกันนั้น หัวข้อ MEASURE 2.4 ยังวางผลลัพธ์ที่ต้องการไว้ตรงตัวว่าการทำงานและพฤติกรรมของระบบ AI กับส่วนประกอบของมัน ตามที่ระบุไว้ในฟังก์ชัน MAP ถูกเฝ้าดูเมื่ออยู่ในการใช้งานจริง แปลว่าการเฝ้าดูหลังเปิดใช้ถูกวางไว้เป็นผลลัพธ์ที่กรอบนี้อยากให้เกิด ไม่ใช่งานเสริมท้ายโครงการ ข้อควรระวังคือหน้าเว็บของ NIST ระบุว่ากรอบ AI RMF มีไว้ให้ใช้แบบสมัครใจ และหน้าแรกของ Playbook เขียนไว้ว่า Playbook ไม่ใช่เช็กลิสต์และไม่ใช่ชุดขั้นตอนที่ต้องทำให้ครบทั้งหมด ข้อเสนอในนั้นเป็นเรื่องสมัครใจ องค์กรจึงหยิบไปใช้เท่าที่ตรงกับงานของตัวเองได้

ในทางปฏิบัติคนทำงานสายข้อมูลแยกอาการนี้ออกเป็นสองแบบที่แก้คนละทาง แบบแรกคือ data drift ซึ่งบล็อกของ Google Cloud ที่อธิบายการเฝ้าดูโมเดลบน vertex-ai เมื่อ 31 กรกฎาคม 2021 นิยามว่าเป็นความเปลี่ยนแปลงใดก็ตามของข้อมูล คือค่าของ feature ระหว่างตอนเทรนกับตอนให้บริการจริง และระบุว่าอีกชื่อของมันคือ covariate shift ข้อควรระวังคือบล็อกนั้นพูดถึงการเทียบกับข้อมูลตอนเทรนเป็นหลัก ส่วนเอกสารของ Azure Machine Learning ระบุว่า baseline ที่ใช้เทียบจะเป็นข้อมูลตอนเทรนหรือข้อมูลการใช้งานจริงช่วงก่อนหน้าก็ได้ ซึ่งทำให้จับการเลื่อนที่ค่อยๆ เกิดขึ้นตามเวลาได้ด้วย พูดง่ายๆ คือหน้าตาของประชากรที่ไหลเข้ามาไม่เหมือนชุดที่ใช้เทรนแล้ว เช่น สัดส่วนลูกค้าต่างจังหวัดเพิ่มขึ้น หรือช่องกรอกรายได้เริ่มมีค่าว่างเยอะผิดปกติ แบบที่สองคือ concept drift ซึ่งหนักกว่า เพราะกฎเกณฑ์เบื้องหลังเปลี่ยนไปเอง งานทบทวนวรรณกรรมเรื่อง Learning under Concept Drift ของ Jie Lu และคณะ ที่เผยแพร่บน arXiv เมื่อ 13 เมษายน 2020 นิยามไว้สั้นๆ ว่า concept drift คือความเปลี่ยนแปลงที่คาดการณ์ไม่ได้ของการแจกแจงเบื้องหลังของข้อมูลที่ไหลเข้ามาต่อเนื่องตามเวลา ตัวอย่างที่เห็นภาพชัดคืออีเมลฟิชชิ่ง ฉลากว่า "อีเมลหลอกลวง" ยังเป็นฉลากเดิม แต่รูปแบบสัญญาณที่ใช้จับเปลี่ยนไป จากยุคที่คนร้ายใช้คำโจ่งแจ้งอย่าง lottery มาเป็นสำนวนขัดเกลาที่พยายามทำให้ดูน่าเชื่อถือและหลบการตรวจจับ

กลไกการเฝ้าดูของผู้ให้บริการคลาวด์รายใหญ่ทำงานคล้ายกัน เอกสาร Model monitoring ของ Azure Machine Learning อธิบายเป็นสามจังหวะ คือคำนวณการแจกแจงทางสถิติของค่าใน feature จากข้อมูลตอนเทรนไว้เป็น baseline แล้วคำนวณการแจกแจงของค่าล่าสุดที่เก็บได้จากการใช้งานจริง จากนั้นทำการทดสอบทางสถิติหรือคำนวณคะแนนระยะห่างระหว่างสองการแจกแจงนั้น ถ้าเกินเกณฑ์ที่ผู้ใช้ตั้งไว้ก็แจ้งเตือน มาตรวัดที่เอกสารระบุไว้สำหรับสัญญาณ data drift ได้แก่ Jensen-Shannon Distance, Population Stability Index, Normalized Wasserstein Distance, Two-Sample Kolmogorov-Smirnov Test และ Pearson's Chi-Squared Test ส่วนฝั่ง Google บล็อกของ Google Cloud ระบุว่าใช้ JS divergence กับ feature ที่เป็นตัวเลข และใช้ L-infinity distance กับ feature ที่เป็นหมวดหมู่ ฝั่ง AWS นั้น Amazon SageMaker Model Monitor แบ่งการเฝ้าดูออกเป็นสี่ชนิด คือคุณภาพข้อมูล คุณภาพโมเดล อคติในคำทำนาย และการเปลี่ยนแปลงของน้ำหนักที่แต่ละ feature ส่งผลต่อคำตอบ

จุดที่คนทำงานต้องระวังมากที่สุดคือตัวเลข drift ของข้อมูลขาเข้าบอกได้แค่ว่า "ของที่ไหลเข้ามาเปลี่ยนไป" ไม่ได้บอกว่าโมเดลตอบผิดมากขึ้นจริงหรือเปล่า จะรู้ว่าแม่นลดลงจริงต้องเทียบกับ ground truth คือคำตอบที่ถูกต้องซึ่งเกิดขึ้นจริงในภายหลัง เอกสารของ AWS อธิบายว่าการเฝ้าดูคุณภาพโมเดลต้องเอาข้อมูลที่ดักจับจากการเรียกใช้จริงมารวมกับฉลากคำตอบจริงที่องค์กรเก็บไว้ใน S3 ก่อนแล้วค่อยเทียบกัน ส่วนเอกสารของ Azure ก็แนะนำให้ใช้สัญญาณ model performance เฉพาะเมื่อองค์กรมีข้อมูลคำตอบจริงในมือ และให้ใช้สัญญาณ data drift ร่วมกับ feature attribution drift เพื่อให้ได้คำเตือนล่วงหน้าก่อนที่ประสิทธิภาพจะตกจริง คำแนะนำอีกข้อที่ตรงกับหน้างานคือให้เริ่มเฝ้าดูทันทีที่โมเดลขึ้นใช้จริง และให้คนที่เข้าใจโมเดลเป็นคนตั้งเกณฑ์แจ้งเตือน เพราะตั้งไว้ไวเกินไปจะเกิดอาการล้าจากการแจ้งเตือนจนคนเลิกสนใจ ฝั่ง NIST ก็ให้แนวเดียวกัน คือให้บันทึกว่าตัวชี้วัดที่เห็นในการใช้งานจริงต่างจากตัวชี้วัดชุดเดียวกันที่เก็บตอนทดสอบก่อนเปิดใช้อย่างไร ซึ่งแปลว่าชุด evals ที่ตั้งไว้ตอนก่อนขึ้นระบบต้องถูกรันซ้ำเป็นระยะ ไม่ใช่รันครั้งเดียวจบ และให้ใช้การทดสอบสมมติฐานทางสถิติหรือความเชี่ยวชาญของคนในสายงานนั้นมาช่วยวัดความต่าง ซึ่งหมายความว่า human-review ยังเป็นส่วนหนึ่งของการเฝ้าดู ไม่ใช่ปล่อยให้ dashboard ตัดสินอย่างเดียว

ข้อควรระวังเรื่องเครื่องมือคือของพวกนี้เปลี่ยนเร็ว เอกสารของ AWS ขึ้นหมายเหตุไว้ตอนต้นหน้าว่า Amazon SageMaker Model Monitor ไม่เปิดรับลูกค้าใหม่แล้ว ลูกค้าเดิมใช้ต่อได้ตามปกติ และ AWS ยังลงทุนด้านความปลอดภัยกับความพร้อมใช้งานต่อไป แต่ไม่มีแผนออกฟีเจอร์ใหม่ อีกข้อจำกัดที่ต้องรู้ก่อนตั้งความหวังคือเครื่องมือ built-in เหล่านี้ออกแบบมาสำหรับข้อมูลตารางเป็นหลัก เอกสารของ AWS ระบุตรงตัวว่า Model Monitor คำนวณสถิติและมาตรวัดของโมเดลได้กับข้อมูลตารางเท่านั้น ส่วนตารางสัญญาณของ Azure ก็กำกับงาน classification และ regression บนข้อมูลตารางไว้เกือบทุกช่อง สำหรับงาน generative AI นั้น Azure แยกสัญญาณอีกชุดหนึ่งที่ยังเป็น public preview ชื่อ Generation safety and quality ซึ่งวัดด้วยเกณฑ์อย่าง groundedness, relevance, fluency, similarity และ coherence แทนที่จะวัดการเลื่อนของการแจกแจง สุดท้ายที่มักสับสนกันคือกรณีที่ผู้ให้บริการเปลี่ยนรุ่นโมเดลเอง ถ้าองค์กรเรียกโมเดลผ่าน API ของผู้ให้บริการอย่าง openai แล้ววันหนึ่งคำตอบเปลี่ยนหน้าตาไปโดยไม่มี error สาเหตุที่เป็นไปได้คือชื่อรุ่นที่เรียกเป็นชื่อกลาง ไม่ใช่ชื่อ snapshot ที่ระบุวันที่ตรงตัว เอกสารปลดระวางของ OpenAI มีรายการจับคู่ชื่อกลางแบบไม่มีวันที่เข้ากับชื่อรุ่นที่มีวันที่กำกับ การเรียกด้วยชื่อกลางจึงไม่ได้ล็อกว่าเบื้องหลังจะเป็นรุ่นเดิมตลอดไป รุ่นที่ทำงานอยู่จริงเปลี่ยนได้โดยที่ฝั่งผู้เรียกไม่ต้องแก้โค้ดอะไรเลย ส่วนการปลดระวางรุ่นที่ระบุชื่อ snapshot ตรงตัวนั้น เอกสารของ OpenAI ระบุว่ารุ่นที่ประกาศเลิกใช้ทุกตัวจะมีวันปิดใช้กำกับไว้ และเมื่อถึงวันนั้นรุ่นดังกล่าวจะเรียกใช้ไม่ได้อีก ทั้งสองกรณีเป็นคนละเรื่องกับ drift และเอกสารสถาปัตยกรรม MLOps ของ Google Cloud ก็สรุปภาพรวมไว้ตรงจุดว่าโมเดลเสื่อมสภาพได้หลายทางกว่าซอฟต์แวร์แบบเดิม องค์กรจึงต้องเผื่อความเสื่อมนี้ไว้ด้วย โดยเอกสารเดียวกันแนะนำให้ติดตามสถิติสรุปของข้อมูลและเฝ้าดูประสิทธิภาพของโมเดลตอนใช้งานจริง เพื่อจะได้แจ้งเตือนหรือย้อนกลับไปใช้รุ่นก่อนหน้าเมื่อค่าที่วัดได้เบี่ยงจากที่คาดไว้

ตัวอย่างจากบทสนทนาจริง

หัวหน้าฝ่ายสินเชื่อ: "โมเดลคัดกรองใบสมัครที่เปิดใช้ตั้งแต่ปีที่แล้ว ตอนนี้ปฏิเสธลูกค้าที่ดูดีมากๆ เยอะขึ้นผิดปกติ ทีมไอทีบอกว่าไม่ได้แก้อะไรเลยสักบรรทัด แล้วมันแย่ลงเองได้ยังไง"

ทีมข้อมูล: "อาการนี้เรียกว่า model drift ครับ โค้ดเหมือนเดิมจริง แต่ฐานผู้สมัครปีนี้หน้าตาไม่เหมือนชุดข้อมูลที่ใช้เทรนแล้ว เดี๋ยวผมดึงการแจกแจงของ feature หลักมาเทียบกับ baseline ตอนเทรนให้ดูว่าตัวไหนเลื่อนไปมากที่สุด"

หัวหน้าฝ่ายสินเชื่อ: "ถ้าเทียบแล้วเลื่อนจริง คือต้องเทรนใหม่เลยใช่ไหม"

ทีมข้อมูล: "ยังสรุปแบบนั้นไม่ได้ครับ ต้องแยกก่อนว่าเป็นแค่ข้อมูลขาเข้าเปลี่ยน หรือเกณฑ์การเป็นลูกหนี้ดีเปลี่ยนไปด้วย สองอย่างนี้แก้คนละทาง และที่สำคัญกว่านั้นคือเราต้องเอาผลจริงของสัญญาที่อนุมัติไปแล้วกลับมาเทียบ ถึงจะรู้ว่าโมเดลแม่นลดลงจริงหรือแค่ข้อมูลหน้าตาเปลี่ยน"

ระวังสับสนกับ

• model-deprecation : ผู้ให้บริการประกาศเลิกใช้โมเดลรุ่นเดิมและบังคับให้ย้ายไปรุ่นใหม่ เป็นเหตุการณ์ที่มีวันที่ชัดเจนและอยู่นอกการควบคุมขององค์กร ส่วน model drift โมเดลตัวเดิมยังอยู่ครบไม่มีอะไรเปลี่ยน แต่โลกรอบตัวมันเปลี่ยนไปเอง
• overfitting : เป็นปัญหาที่เกิดตั้งแต่ตอนเทรน โมเดลจำรายละเอียดของชุดข้อมูลฝึกจนแม่นเฉพาะข้อมูลชุดนั้น พอเจอของจริงก็พลาดตั้งแต่วันแรกที่เปิดใช้ ส่วน model drift วันแรกแม่นจริง แล้วค่อยๆ แย่ลงตามเวลา
• model-collapse : เป็นความเสื่อมที่เกิดกับโมเดลรุ่นถัดๆ ไปเมื่อถูกเทรนด้วยข้อมูลที่ AI สร้างขึ้นเอง ปัญหาอยู่ที่ฝั่งข้อมูลฝึกของรุ่นใหม่ ส่วน model drift เป็นเรื่องของโมเดลตัวที่กำลังรันอยู่กับข้อมูลจริงที่ไหลเข้ามาทุกวัน