MLOps คืออะไร? วิธีที่ทีมสร้าง ปรับใช้ และตรวจสอบระบบการเรียนรู้ของเครื่อง

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

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

MLOps: คำจำกัดความ, ขอบเขต, และวัตถุประสงค์

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

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

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

แผนผังการดำเนินงานห้าขั้นตอนของ MLOps

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

1. เวอร์ชันข้อมูล, โค้ด, สภาพแวดล้อม, และโมเดล: อินพุตและสมมติฐานใน MLOps

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

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

2. อัตโนมัติการฝึกและขั้นตอนการตรวจสอบ: การแทนหรือการตัดสินใจใน MLOps

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

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

3. ลงทะเบียนศิลปวัตถุที่ได้รับการอนุมัติและต้นสาย: การแปลงที่โดดเด่นใน MLOps

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

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

4. ปรับใช้พร้อมการย้อนกลับและการปล่อยเป็นขั้นตอน: ข้อจำกัดและขอบเขตการตรวจสอบใน MLOps

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

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

5. ตรวจสอบบริการ, ข้อมูล, และพฤติกรรมของโมเดล: ผลลัพธ์, ข้อเสนอแนะ, และกฎการหยุดใน MLOps

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

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

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

ตัวอย่าง MLOps ที่ทำงานจริง

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

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

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

MLOps กับทางลัดที่พบบ่อยที่สุดของมัน

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

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

ทำไม MLOps ถึงสำคัญในระบบ AI ปัจจุบัน

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

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

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

ประโยชน์ที่ MLOps สามารถมอบให้

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

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

โหมดความล้มเหลวที่กำหนด MLOps

ข้อจำกัดหลักคือการอัตโนมัติอาจส่งข้อมูลหรือโมเดลที่ไม่ดีได้เร็วขึ้น หากไม่มีการตั้งกฎเกณฑ์การยอมรับที่แท้จริง ความล้มเหลวนี้ไม่ได้เป็นเรื่องหลังจากเสร็จสิ้นการพัฒนา ควรกำหนดการเก็บรวบรวมข้อมูล สถาปัตยกรรม สิทธิ์ การประเมิน ประตูปล่อย และการตรวจสอบสำหรับ MLOps ตั้งแต่แรกเริ่ม

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

แผนการประเมินสำหรับ MLOps

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

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

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

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

คำถามที่ควรถามก่อนนำ MLOps ไปใช้

• วัตถุประสงค์: MLOps ตั้งใจแก้ไขคอขวดที่วัดได้อะไร?
• กลไก: ขั้นตอนห้าขั้นตอนใดมีการแปลงที่โดดเด่น?
• ฐานเปรียบเทียบ: มันเปรียบเทียบอย่างไรกับ DevOps ที่ใช้เฉพาะกับ API โดยละเลยวงจรชีวิตของข้อมูลและโมเดลหรือทางเลือกที่ง่ายกว่าอื่น ๆ?
• หลักฐาน: กรณีทั่วไป ยาก การต่อสู้เชิงศัตรู และกลุ่มย่อยใดบ้างที่ถูกทดสอบ?
• การดำเนินงาน: ความหน่วง เวลาใช้หน่วยความจำ การคำนวณ พลังงาน การบำรุงรักษา และค่าใช้จ่ายการรีวิวที่ปรากฏเมื่อขยายขนาดเป็นอย่างไร?
• ความเสี่ยง: ทีมจะตรวจจับได้อย่างไรว่าการอัตโนมัติอาจส่งข้อมูลหรือโมเดลที่ไม่ดีได้เร็วขึ้น หากไม่มีการตั้งกฎเกณฑ์การยอมรับที่แท้จริง?
• การฟื้นฟู: ระบบสามารถละเว้น, ถอยกลับ, ย้อนกลับ, หรือยกระดับก่อนเกิดอันตรายได้หรือไม่?

แหล่งข้อมูลหลักสำหรับศึกษ MLOps

จุดเริ่มต้นที่น่าเชื่อถือสำหรับส่วนของสแตก AI ที่ล้อมรอบ MLOps ได้แก่ คู่มือการเลือกโมเดลของ scikit-learn, Google Rules of ML, NIST AI RMF. อ่านพร้อมกับเอกสารของโมเดล, ชุดข้อมูล, ฮาร์ดแวร์, และเขตอำนาจที่เกี่ยวข้อง แหล่งข้อมูลทั่วไปอาจกำหนดกลไกได้ แต่เฉพาะหลักฐานที่เกี่ยวกับการปรับใช้เท่านั้นที่สามารถยืนยันว่าการดำเนินการเฉพาะเป็นที่เหมาะสม

สิ่งที่ควรจำเกี่ยวกับ MLOps

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

กฎปฏิบัติสำหรับ MLOps คือกำหนดวัตถุประสงค์ เปรียบเทียบกับฐานเปรียบเทียบที่เชื่อถือได้ ทดสอบความล้มเหลวที่สำคัญที่สุด และเก็บหลักฐานที่จำเป็นเพื่อเฝ้าติดตามการเปลี่ยนแปลง เมื่อมีชิ้นส่วนเหล่านี้ครบ แนวคิดจะกลายเป็นการเลือกด้านวิศวกรรมและการกำกับดูแลที่สามารถประเมินได้ หากไม่มีสิ่งเหล่านี้ มันยังคงเป็นชื่อที่มีศักยภาพแต่เชื่อมโยงกับความเสี่ยงการดำเนินงานที่ไม่ทราบ