MLOps

Overview

เอ็มแอลออปส์ คือชุดของแนวปฏิบัติ วัฒนธรรมการทำงาน และกระบวนการทางวิศวกรรมสำหรับพัฒนา นำขึ้นใช้งาน เฝ้าระวัง และปรับปรุงระบบการเรียนรู้ของเครื่อง ในสภาพแวดล้อมใช้งานจริงอย่างทำซ้ำได้ เชื่อถือได้ และตรวจสอบได้ MLOps ผสานความรู้จากการเรียนรู้ของเครื่อง วิศวกรรมข้อมูล และวิศวกรรมซอฟต์แวร์ โดยเฉพาะหลักการณ์ของเดฟออปส์ (DevOps) เพื่อเชื่อมงานทดลองของนักวิทยาการข้อมูลเข้ากับการดำเนินงานของบริการหรือผลิตภัณฑ์จริง

แผนภาพวงกลมซ้อนสามวง แสดงการเรียนรู้ของเครื่อง เดฟออปส์ และวิศวกรรมข้อมูล โดยส่วนตัดร่วมคือเอ็มแอลออปส์
เอ็มแอลออปส์อยู่ที่จุดตัดของการเรียนรู้ของเครื่อง เดฟออปส์ และวิศวกรรมข้อมูล

เอ็มแอลออปส์ (อังกฤษ: MLOps หรือ ML Ops; ชื่อผสมจาก machine learning และ operations) คือชุดของแนวปฏิบัติ วัฒนธรรมการทำงาน และกระบวนการทางวิศวกรรมสำหรับพัฒนา นำขึ้นใช้งาน เฝ้าระวัง และปรับปรุงระบบการเรียนรู้ของเครื่อง (machine learning; ML) ในสภาพแวดล้อมใช้งานจริงอย่างทำซ้ำได้ เชื่อถือได้ และตรวจสอบได้[1] MLOps ผสานความรู้จากการเรียนรู้ของเครื่อง วิศวกรรมข้อมูล และวิศวกรรมซอฟต์แวร์ โดยเฉพาะหลักการณ์ของเดฟออปส์ (DevOps) เพื่อเชื่อมงานทดลองของนักวิทยาการข้อมูลเข้ากับการดำเนินงานของบริการหรือผลิตภัณฑ์จริง[2]

สิ่งที่เอ็มแอลออปส์จัดการไม่ได้มีเพียงโค้ด แต่มีทั้งข้อมูล นิยามฟีเจอร์ ป้ายกำกับ การตั้งค่าการฝึก สภาพแวดล้อม ซอฟต์แวร์พึ่งพา โมเดลที่ฝึกแล้ว ผลการประเมิน ข้อมูลเมตา และบันทึกการตัดสินใจ ช่วยให้ทีมพัฒนาตอบคำถามสำคัญได้ว่าโมเดลรุ่นใดใช้ข้อมูลและโค้ดใด ผ่านเกณฑ์ใด ใครอนุมัติ และเมื่อเกิดปัญหาจะย้อนกลับหรือฝึกใหม่อย่างไร[2] อย่างไรก็ดี เอ็มแอลออปส์ไม่ใช่ชื่อผลิตภัณฑ์หรือเครื่องมือหนึ่งชนิด และระบบอัตโนมัติไม่ได้ทำให้โมเดลถูกต้อง เป็นธรรม ปลอดภัย หรือสอดคล้องกับกฎหมายโดยอัตโนมัติ[3]

ที่มาและขอบเขต

ปัญหาที่เอ็มแอลออปส์พยายามแก้มีมาก่อนคำว่า MLOps งานของสกัลลีย์ (Sculley) และคณะในปี 2015 ชี้ว่าระบบการเรียนรู้ของเครื่องในโลกจริงมีภาระบำรุงรักษาแบบซอฟต์แวร์ทั่วไป และมีหนี้ทางเทคนิคเฉพาะด้านเพิ่มขึ้น เช่น การพึ่งพาข้อมูล การเชื่อมโยงกันขององค์ประกอบโมเดล วงจรป้อนกลับที่มองไม่เห็น และการเปลี่ยนแปลงของโลกภายนอก[4] ต่อมาเบร์คและคณะเสนอรายการทดสอบและการติดตาม 28 รายการเพื่อประเมินความพร้อมของระบบ ML สำหรับการใช้งานจริง[5]

การศึกษาทีมพัฒนาของไมโครซอฟท์ใน 2019 ยังพบว่าการสร้างระบบที่ใช้ ML ต่างจากซอฟต์แวร์ทั่วไปโดยพื้นฐานอย่างน้อยสามด้าน ได้แก่[6]

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

ดังนั้น เอ็มแอลออปส์จึงมีขอบเขตกว้างกว่าการนำไฟล์โมเดลขึ้นเป็นบริการทำนาย แต่ครอบคลุมถึงวงจรชีวิตของระบบ ML ตั้งแต่นิยามปัญหาจนถึงการเลิกใช้โมเดลนั้น ๆ

MLOps กับ DevOps

MLOps ต่อยอดหลักของ DevOps เช่น การควบคุมรุ่น การบูรณาการอย่างต่อเนื่อง (continuous integration; CI) และการส่งมอบอย่างต่อเนื่อง (continuous delivery; CD) แต่เพิ่มสิ่งส่งมอบและความเสี่ยงที่เกิดจากข้อมูลกับโมเดล[2] การเปรียบเทียบโดยสังเขปมีดังนี้:

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

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

วงจรชีวิตของระบบ ML

ไม่มีมาตรฐานเดียวที่บังคับใช้กับทุกโครงการ เพราะระบบแนะนำสินค้า ระบบตรวจภาพทางการแพทย์ และโมเดลบนอุปกรณ์ปลายทางมีความต้องการต่างกัน อย่างไรก็ตาม วงจรชีวิตโดยทั่วไปมีลักษณะวนซ้ำตามตารางต่อไปนี้[2][6]

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

คำว่า ไปป์ไลน์ ML (ML pipeline) หมายถึงลำดับงานที่จัดระเบียบและสามารถเรียกใช้ได้ เช่น การตรวจข้อมูล การแปลงข้อมูล การฝึก การประเมิน และการนำขึ้นใช้งาน (deploy) นั้น ไม่จำเป็นต้องเป็นเส้นตรงเสมอไป เนื่องจากผลการติดตามหลังการใช้งานจากผู้ใช้ อาจทำให้ต้องย้อนกลับไปทบทวนข้อมูล นิยามปัญหา หรือโมเดลก่อนหน้า[6]

หลักปฏิบัติสำคัญ

การทำซ้ำได้และการติดตามความเป็นมา

การทำซ้ำได้ (reproducibility) คือความสามารถในการสร้างหรืออธิบายผลการฝึกและผลทำนายอีกครั้งจากหลักฐานที่บันทึกไว้ ไม่ได้หมายความว่าทุกระบบต้องให้ตัวเลขบิตต่อบิตเหมือนกันเสมอ เพราะฮาร์ดแวร์ การคำนวณแบบขนาน และการสุ่มอาจทำให้ผลต่างเล็กน้อยได้ เป้าหมายเชิงวิศวกรรมคือให้ทีมระบุสาเหตุของความต่าง เปรียบเทียบรุ่น และย้อนกลับไปยังรุ่นที่เชื่อถือได้

สิ่งที่ควรระบุหรือกำหนดรุ่น ตัวอย่าง ประโยชน์
ข้อมูลและสคีมา แหล่งข้อมูล ช่วงเวลา วิธีคัดเลือก รุ่นของชุดข้อมูล นิยามป้ายกำกับ และกฎตรวจสอบ ป้องกันการฝึกจากข้อมูลที่ไม่ทราบที่มา และช่วยตรวจความเปลี่ยนแปลงของข้อมูล
โค้ด ฟีเจอร์ และการตั้งค่า รุ่นของโค้ด นิยามการแปลงข้อมูล ไฮเปอร์พารามิเตอร์ เมล็ดสุ่ม และไฟล์กำหนดค่า สร้างการทดลองเดิมหรือเปรียบเทียบการเปลี่ยนแปลงอย่างเป็นธรรม
สภาพแวดล้อม รุ่นไลบรารี คอนเทนเนอร์ ระบบปฏิบัติการ ชนิดตัวเร่งคำนวณ และทรัพยากรที่ใช้ ลดปัญหาผลต่างระหว่างเครื่องพัฒนาและระบบจริง
โมเดลและสิ่งส่งมอบจากการฝึก ไฟล์น้ำหนักโมเดล รูปแบบรับ–ส่งข้อมูล ตัวชี้วัด และเอกสารข้อจำกัด ทำให้เลือก ย้อนกลับ และตรวจสอบโมเดลที่ให้บริการอยู่ได้
ข้อมูลกำกับของการทำงาน รุ่นของไปป์ไลน์ ผู้เรียกใช้ เวลา พารามิเตอร์ ขั้นตอนที่สำเร็จ และการอนุมัติ เชื่อมโยงข้อมูล โค้ด ผลการประเมิน และรุ่นโมเดลเป็นร่องรอยเดียวกัน

การใช้การควบคุมรุ่นจึงไม่ได้แปลว่าต้องเก็บไฟล์ข้อมูลขนาดใหญ่ทุกไฟล์ไว้ในคลังโค้ดเดียว แต่ต้องมีวิธีอ้างอิงรุ่นและความสมบูรณ์ของข้อมูล รวมทั้งเก็บข้อมูลกำกับเพียงพอให้ตามรอยได้ การจัดการข้อมูลกำกับของไปป์ไลน์ช่วยทำซ้ำ เปรียบเทียบ แก้จุดบกพร่อง และย้อนกลับโมเดลได้[2]

การบูรณาการ การส่งมอบ และการฝึกอย่างต่อเนื่อง

ในบริบทเอ็มแอลออปส์ คำว่า “อย่างต่อเนื่อง” มีความหมายกว้างกว่าในซอฟต์แวร์ทั่วไป

  • การบูรณาการอย่างต่อเนื่อง (continuous integration; CI) คือการสร้างและทดสอบโค้ดเมื่อมีการเปลี่ยนแปลง แต่สำหรับ ML ยังรวมการตรวจข้อมูล สคีมา ตรรกะสร้างฟีเจอร์ และคุณสมบัติพื้นฐานของการฝึกโมเดลด้วย
  • การส่งมอบอย่างต่อเนื่อง (continuous delivery; CD) คือการทำให้ไปป์ไลน์หรือบริการโมเดลที่ผ่านเกณฑ์พร้อมนำขึ้นใช้งานได้อย่างสม่ำเสมอ การอนุมัติของมนุษย์อาจยังจำเป็นก่อนใช้กับผู้ใช้จริง
  • การฝึกอย่างต่อเนื่อง (continuous training; CT) คือการเรียกไปป์ไลน์เพื่อฝึกและประเมินโมเดลซ้ำตามกำหนดเวลา ข้อมูลใหม่ การเปลี่ยนแปลงโค้ด หรือสัญญาณจากการติดตาม ไม่ใช่คำพ้องของการเรียนรู้แบบออนไลน์ และไม่ควรตีความว่าโมเดลใหม่ต้องถูกเผยแพร่โดยอัตโนมัติทุกครั้ง[2]

การแยก CT ออกจาก CD สำคัญมาก: ระบบอาจฝึกซ้ำได้อัตโนมัติ แต่จะเลื่อนโมเดลใหม่ไปใช้จริงต่อเมื่อผ่านเกณฑ์ด้านคุณภาพ ความปลอดภัย สมรรถนะ และข้อกำกับเท่านั้น[2]

การทดสอบและเกณฑ์ผ่าน

การทดสอบระบบ ML ต้องมีหลายชั้น เพราะความล้มเหลวอาจอยู่ที่ข้อมูล โมเดล ไปป์ไลน์ หรือบริการที่ให้ผลทำนาย ไม่ใช่ที่โค้ดเพียงอย่างเดียว[5][2]

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

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

การนำขึ้นใช้งาน

โมเดลที่ผ่านการตรวจสอบอาจให้บริการได้หลายรูปแบบ ได้แก่ บริการทำนายออนไลน์ผ่าน API การประมวลผลเป็นชุดตามเวลา หรือโมเดลที่ฝังอยู่ในอุปกรณ์ปลายทาง[2] ก่อนขยายการใช้งานไปยังผู้ใช้ทั้งหมด ทีมอาจทดสอบในสภาพแวดล้อมก่อนใช้งานจริง ใช้การปล่อยแบบค่อยเป็นค่อยไป (canary deployment) หรือการทดลอง A/B และต้องเตรียมวิธีย้อนกลับไปยังรุ่นก่อนหน้า[2]

การนำขึ้นใช้งานจึงควรพิจารณาสัญญาระหว่างโมเดลกับระบบโดยรอบด้วย เช่น ชื่อและชนิดของฟีเจอร์ รูปแบบผลลัพธ์ รุ่นไลบรารี หน่วยความจำ ตัวเร่งคำนวณ ความหน่วง และการจัดการความล้มเหลว หากฟีเจอร์ที่ใช้ฝึกกับฟีเจอร์ที่ใช้จริงมีนิยามหรือวิธีคำนวณต่างกัน จะเกิดความคลาดเคลื่อนระหว่างการฝึกกับการให้บริการ (training-serving skew) ซึ่งทำให้ผลในระบบจริงต่างจากผลทดลองได้[2]

การติดตาม การเสื่อมสมรรถนะ และข้อมูลป้อนกลับ

การติดตาม (monitoring) ของระบบ ML ควรแยกสัญญาณหลายชนิดออกจากกัน

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

การเปลี่ยนแปลงของข้อมูล (data drift) โดยทั่วไปหมายถึงการเปลี่ยนแปลงของการแจกแจงตัวแปรนำเข้าเมื่อเทียบกับข้อมูลที่ใช้ฝึก ส่วนการเปลี่ยนแปลงของแนวคิด (concept drift) หมายถึงการเปลี่ยนแปลงของความสัมพันธ์ระหว่างข้อมูลนำเข้ากับสิ่งที่ต้องทำนาย จึงอาจทำให้กฎที่โมเดลเรียนรู้ไม่เหมาะกับบริบทใหม่[7] สัญญาณ drift ไม่ใช่หลักฐานโดยตัวมันเองว่าโมเดลเสียหรือควรฝึกใหม่ทันที เพราะสาเหตุอาจเป็นความผิดพลาดของไปป์ไลน์ การเปลี่ยนสคีมา การเปลี่ยนธุรกิจ หรือการเปลี่ยนพฤติกรรมจริง จึงต้องมีเกณฑ์และผู้รับผิดชอบในการตีความสัญญาณนั้น[2]

สถาปัตยกรรมและองค์ประกอบ

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

องค์ประกอบ หน้าที่ ข้อสังเกต
คลังซอร์สและการตั้งค่า เก็บโค้ด ไปป์ไลน์ นิยามโครงสร้างพื้นฐาน และการตรวจทานการเปลี่ยนแปลง ไม่ควรเก็บข้อมูลลับไว้ในคลังซอร์ส
ที่เก็บข้อมูลและการตรวจข้อมูล จัดเก็บ อ้างอิง และตรวจคุณภาพข้อมูลดิบ ข้อมูลที่เตรียมแล้ว และป้ายกำกับ ต้องคำนึงถึงสิทธิ์เข้าถึง ความเป็นส่วนตัว และการเก็บรักษาข้อมูล
ตัวจัดการไปป์ไลน์ เรียกและจัดลำดับการประมวลผล การฝึก การประเมิน และการนำขึ้นใช้งาน อาจเรียกตามกำหนดเวลา เหตุการณ์ หรือการอนุมัติ
การติดตามการทดลองและคลังข้อมูลกำกับ บันทึกพารามิเตอร์ สิ่งประดิษฐ์ ผลวัด รุ่นข้อมูล และความเป็นมาของผลลัพธ์ เป็นฐานของการทำซ้ำ การเปรียบเทียบ และการตรวจสอบย้อนกลับ
ทะเบียนโมเดล (model registry) จัดการรุ่น สถานะ เกณฑ์ผ่าน เอกสาร และสิทธิ์ของโมเดล ช่วยแยก “โมเดลที่ทดลอง” ออกจาก “โมเดลที่อนุมัติให้ใช้”
ที่เก็บฟีเจอร์ (feature store) ทำให้นิยามและการเข้าถึงฟีเจอร์สำหรับการฝึกกับการให้บริการเป็นมาตรฐานเดียวกัน เป็นองค์ประกอบทางเลือก เหมาะเมื่อมีการใช้ฟีเจอร์ร่วมกันหรือมีการทำนายเวลาจริงมาก
โครงสร้างพื้นฐานให้บริการและการติดตาม ให้บริการทำนาย จัดการการขยายตัว บันทึกเหตุการณ์ และส่งสัญญาณเตือน ต้องทดสอบร่วมกับสัญญา API และข้อจำกัดด้านความหน่วง

การกำกับดูแล ความรับผิดชอบ และความมั่นคงปลอดภัย

เอ็มแอลออปส์ที่ดีทำให้การกำกับดูแล (governance) เป็นส่วนหนึ่งของวงจรชีวิต ไม่ใช่ด่านสุดท้ายก่อนเผยแพร่ หลักการหนึ่งคือกำหนดเจ้าของระบบ เกณฑ์ยอมรับความเสี่ยง สิทธิ์เข้าถึงข้อมูลและโมเดล ขั้นตอนอนุมัติ การบันทึกการเปลี่ยนแปลง และแผนรับมือเหตุการณ์ไว้ตั้งแต่ต้น NIST AI RMF เสนอกรอบจัดการความเสี่ยงของ AI ที่แบ่งการทำงานเป็นการกำกับดูแล (govern) การทำความเข้าใจบริบทและความเสี่ยง (map) การวัด (measure) และการจัดการความเสี่ยง (manage)[3]

เอกสารกำกับข้อมูลและโมเดลช่วยให้การกำกับดูแลเกิดขึ้นจริง ตัวอย่างเช่นแนวคิดแผ่นข้อมูลชุดข้อมูล (datasheets for datasets) เสนอให้บันทึกแรงจูงใจ องค์ประกอบ วิธีรวบรวม การใช้ที่แนะนำ และการบำรุงรักษาของชุดข้อมูล[8] ส่วนบัตรโมเดล (model card) คือเอกสารสรุปวัตถุประสงค์ที่เหมาะสม ลักษณะการประเมิน ข้อจำกัด และผลต่อกลุ่มย่อยที่เกี่ยวข้องของโมเดล[9]

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

บุคลากรและการทำงานร่วมกัน

ตำแหน่งงานไม่จำเป็นต้องตายตัว แต่เอ็มแอลออปส์มักต้องอาศัยความร่วมมือของผู้มีบทบาทต่อไปนี้

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

หัวใจสำคัญจึงไม่ใช่การบังคับให้ทุกคนใช้ตำแหน่ง “วิศวกรเอ็มแอลออปส์” แต่คือการทำให้ความรับผิดชอบต่อข้อมูล โมเดล และบริการจริงไม่ขาดตอนระหว่างทีม[6]

ระดับความพร้อมของเอ็มแอลออปส์

Google Cloud เสนอโมเดลระดับความพร้อมสามระดับซึ่งใช้เป็นภาษากลางในการวางแผนได้ แต่ไม่ใช่มาตรฐานสากลหรือบันไดที่ทุกองค์กรต้องปีนตามลำดับ[2]

ระดับ ลักษณะ เหมาะกับ
ระดับ 0: กระบวนการด้วยมือ วิเคราะห์ข้อมูล ฝึก ตรวจสอบ และส่งมอบโมเดลด้วยมือเป็นส่วนใหญ่; อาจเพียงพอเมื่อโมเดลเปลี่ยนน้อย งานวิจัย โครงการเริ่มต้น หรือโมเดลที่ใช้ไม่บ่อยและมีความเสี่ยงต่ำ
ระดับ 1: ทำไปป์ไลน์ฝึกให้เป็นอัตโนมัติ ไปป์ไลน์ตรวจข้อมูล ฝึก ประเมิน และส่งมอบโมเดลซ้ำได้; มี trigger และข้อมูลกำกับรองรับ CT โมเดลที่ข้อมูลหรือบริบทเปลี่ยนเป็นระยะและต้องฝึกซ้ำอย่างควบคุมได้
ระดับ 2: ทำ CI/CD ของไปป์ไลน์ให้เป็นอัตโนมัติ โค้ดส่วนประกอบไปป์ไลน์ถูกสร้าง ทดสอบ และนำขึ้นใช้งานอย่างเป็นระบบ พร้อมทะเบียนโมเดลและการติดตาม องค์กรที่มีหลายไปป์ไลน์ หลายทีม หรือมีการเปลี่ยนโมเดลและฟีเจอร์บ่อย

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

ความสัมพันธ์กับแนวทางอื่น

แนวทาง จุดเน้น ความสัมพันธ์กับเอ็มแอลออปส์
DevOps การพัฒนาและดำเนินงานซอฟต์แวร์ เป็นรากสำคัญของการควบคุมรุ่น CI/CD การทำงานอัตโนมัติ และความรับผิดชอบร่วม แต่ไม่ครอบคลุมปัญหาข้อมูลและสมรรถนะโมเดลทั้งหมด
DataOps คุณภาพ การไหล และการส่งมอบข้อมูล/ผลวิเคราะห์ สนับสนุนข้อมูลที่ระบบ ML ใช้; เอ็มแอลออปส์เพิ่มการฝึก การประเมิน และการดำเนินงานของโมเดล[10]
AIOps การใช้ AI หรือ ML ช่วยวิเคราะห์และดำเนินงานด้านไอที เป็นกรณีใช้ ML กับงานปฏิบัติการไอที ไม่ใช่ชื่อกระบวนการพัฒนาและดูแลโมเดลทุกประเภท[11]
LLMOps การดำเนินงานของระบบที่ใช้โมเดลภาษาขนาดใหญ่ (LLMs) หรือปัญญาประดิษฐ์แบบรู้สร้าง (generative AI) เป็นคำที่ใช้เรียกแนวปฏิบัติเฉพาะทางซึ่งต่อยอดจากเอ็มแอลออปส์ เช่น การกำหนดรุ่นพรอมป์ต โมเดลพื้นฐาน ชุดข้อมูลสำหรับการประเมิน การค้นคืนข้อมูล และการตรวจความปลอดภัยของผลลัพธ์; ขอบเขตคำยังไม่เป็นมาตรฐานตายตัว[12]

ข้อจำกัดและความเข้าใจที่คลาดเคลื่อน

เอ็มแอลออปส์ไม่ใช่ทางลัดที่ทำให้โครงการ ML สำเร็จ หากไม่มีปัญหาที่ชัดเจน ข้อมูลเหมาะสม เกณฑ์ประเมินที่สัมพันธ์กับการใช้งาน และเจ้าของระบบที่รับผิดชอบเมื่อผลลัพธ์เปลี่ยนไป ระบบอัตโนมัติเพียงอย่างเดียวอาจทำให้ความผิดพลาดแพร่กระจายเร็วขึ้นได้[4][3] ในทำนองเดียวกัน การฝึกซ้ำบ่อยไม่ได้รับประกันผลดีเสมอไป: ข้อมูลใหม่อาจมีคุณภาพต่ำ มีอคติ หรือยังไม่มีผลจริงพอให้ประเมินได้ จึงควรแยกการตรวจพบสัญญาณ การสืบหาสาเหตุ และการอนุมัติเปลี่ยนรุ่นออกจากกัน

ดูเพิ่ม

อ้างอิง

  1. ↑ Kreuzberger, Dominik; Kühl, Niklas; Hirschl, Sebastian (2023). "Machine Learning Operations (MLOps): Overview, Definition, and Architecture". IEEE Access. 11: 31866–31879. arXiv:2205.02302. doi:10.1109/ACCESS.2023.3262138.
  2. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 "MLOps: Continuous delivery and automation pipelines in machine learning". Google Cloud Documentation. สืบค้นเมื่อ 25 กรกฎาคม 2026.
  3. 1 2 3 4 Tabassi, Elham (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0) (PDF) (NIST AI). National Institute of Standards and Technology. doi:10.6028/NIST.AI.100-1.
  4. 1 2 3 Sculley, D.; Holt, Gary; และคณะ (2015). "Hidden Technical Debt in Machine Learning Systems" (PDF). Advances in Neural Information Processing Systems. เล่มที่ 28. น. 2503–2511.
  5. 1 2 Breck, Eric; Cai, Shanqing; Nielsen, Eric; Salib, Michael; Sculley, D. (2017). "The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction" (PDF). 2017 IEEE International Conference on Big Data (Big Data).
  6. 1 2 3 4 Amershi, Saleema; Begel, Andrew; Bird, Christian; DeLine, Robert; Gall, Harald C.; Kamar, Ece; Nagappan, Nachiappan; Nushi, Besmira; Zimmermann, Thomas (2019). "Software Engineering for Machine Learning: A Case Study" (PDF). 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). น. 291–300. doi:10.1109/ICSE-SEIP.2019.00042.
  7. ↑ Gama, João; Žliobaitė, Indrė; Bifet, Albert; Pechenizkiy, Mykola; Bouchachia, Abdelhamid (2014). "A Survey on Concept Drift Adaptation". ACM Computing Surveys. 46 (4). doi:10.1145/2523813.
  8. ↑ Gebru, Timnit; Morgenstern, Jamie; Vecchione, Briana; Vaughan, Jennifer Wortman; Wallach, Hanna; Daumé III, Hal; Crawford, Kate (2021). "Datasheets for Datasets". Communications of the ACM. 64 (12): 86–92. doi:10.1145/3458723.
  9. ↑ Mitchell, Margaret; Wu, Simone; Zaldivar, Andrew; Barnes, Parker; Vasserman, Lucy; Hutchinson, Ben; Spitzer, Elena; Raji, Inioluwa Deborah; Gebru, Timnit (2019). "Model Cards for Model Reporting". Proceedings of the Conference on Fairness, Accountability, and Transparency. น. 220–229. doi:10.1145/3287560.3287596.
  10. ↑ Ereth, Julian (2018). "DataOps – Towards a Definition" (PDF). Proceedings of LWDA 2018. น. 109.
  11. ↑ "AIOps คืออะไร – คำอธิบายปัญญาประดิษฐ์สำหรับการปฏิบัติงานด้านไอที". Amazon Web Services. สืบค้นเมื่อ 25 กรกฎาคม 2026.
  12. ↑ Pahune, Saurabh; Akhtar, Zahid (2025). "Transitioning from MLOps to LLMOps: Navigating the Unique Challenges of Large Language Models". Information. 16 (2). doi:10.3390/info16020087.{{cite journal}}: CS1 maint: unflagged free DOI (ลิงก์)

อ่านเพิ่มเติมและแหล่งเรียนรู้

เอกสารและตำรา

  • Huyen, Chip (2022). Designing Machine Learning Systems หลักการและเทคนิคจากประสบการณ์จริงในธุรกิจ. O'Reilly Media. ISBN 978-1-0981-0795-6.
  • Mark, Gracewell (2025). Cloud and Multicould Mastery: aws. Core Function. ISBN 978-6168282472.
  • Treveil, Mark; Omont, Nicolas; Stenac, Clément; Lefevre, Kenji; Phan, Du; Zentici, Joachim; Lavoillotte, Adrien; Miyazaki, Makoto; Heidmann, Lynn (2020). Introducing MLOps: How to Scale Machine Learning in the Enterprise. O'Reilly Media. ISBN 978-1-4920-8328-3.
  • Kreuzberger, Dominik; Kühl, Niklas; Hirschl, Sebastian (2023). "Machine Learning Operations (MLOps): Overview, Definition, and Architecture". IEEE Access. 11: 31866–31879. doi:10.1109/ACCESS.2023.3262138.

แหล่งเรียนรู้เปิด

  • "Machine Learning Crash Course". Google for Developers. สืบค้นเมื่อ 25 กรกฎาคม 2026. พื้นฐานการเรียนรู้ของเครื่อง การประเมิน และระบบ ML
  • "MLOps คืออะไร". Amazon Web Services. สืบค้นเมื่อ 25 กรกฎาคม 2026. บทนำภาษาไทยเกี่ยวกับวงจรชีวิตและศัพท์พื้นฐาน
  • "MLOps: Continuous delivery and automation pipelines in machine learning". Google Cloud Documentation. สืบค้นเมื่อ 25 กรกฎาคม 2026. เอกสารเชิงสถาปัตยกรรมและระดับความพร้อม
  • "Machine Learning Operations (MLOps): Getting Started". Google Skills. สืบค้นเมื่อ 25 กรกฎาคม 2026. หลักสูตรระดับกลางว่าด้วยการนำขึ้นใช้งาน การประเมิน การติดตาม และการดำเนินงานของระบบ ML
  • "Machine Learning Operations". ML Ops. สืบค้นเมื่อ 25 กรกฎาคม 2026. แหล่งเรียนรู้เปิดเรื่องวงจรชีวิต หลักปฏิบัติ และการกำกับดูแลของระบบ ML

Related

No related data.

Recommendations