กำไร:
- ความสามารถในการรับรู้ถึงความท้าทายพิเศษของ ML ที่เกี่ยวข้องกับทั้งสามโมเดลโค้ด-ข้อมูล-โมเดล และแพ็คเกจ และนำเสนอโมเดลทางออนไลน์หรือเป็นชุดตามความต้องการทางธุรกิจ
- ความสามารถในการใช้รูปแบบการปรับใช้แบบค่อยเป็นค่อยไปและย้อนกลับ (เงา, คานารี, A/B, การย้อนกลับ) และเพิ่มแผนการย้อนกลับที่ทดสอบแล้วลงในการปรับใช้แต่ละครั้ง
- ความสามารถในการเก็บลิงก์ข้อมูล-โค้ด-เมตริกของแบบจำลองที่ใส่เข้าไปในการผลิตที่สามารถตรวจสอบย้อนกลับได้ด้วย CI/CD ที่ควบคุมตามเกณฑ์การประเมิน และการลงทะเบียนโมเดล
การสร้างโมเดลให้มีความแม่นยำ 95% ในโน้ตบุ๊กเป็นเพียงครึ่งเรื่องเท่านั้น อีกครึ่งหนึ่ง—ซึ่งมักจะเป็นส่วนที่ยาก—คือการนำโมเดลนั้นไปสู่ผู้ใช้จริงด้วยวิธีที่เชื่อถือได้ ปรับขนาดได้ และบำรุงรักษาได้ MLOps (การดำเนินการเรียนรู้ของเครื่อง: ระเบียบวินัยในการวาง ปฏิบัติการ และบำรุงรักษาโมเดล ML ไปสู่การผลิต) ผสมผสานแนวปฏิบัติ DevOps ของวิศวกรรมซอฟต์แวร์เข้ากับความท้าทายเฉพาะตัวของ ML ในหน่วยนี้ เราจะครอบคลุมขั้นตอนการย้ายแบบจำลองไปสู่การใช้งานจริง และวิธีที่ปัญญาประดิษฐ์ช่วยในกระบวนการนี้
เหตุใด ML จึงแตกต่างจากซอฟต์แวร์ทั่วไป
ในซอฟต์แวร์ทั่วไป ลักษณะการทำงานจะอยู่ในโค้ด ถ้าโค้ดไม่เปลี่ยน พฤติกรรมก็ไม่เปลี่ยน ใน ML ลักษณะการทำงานขึ้นอยู่กับทั้งโค้ด ข้อมูล และโมเดล มิติสามมิติเหล่านี้สร้างความท้าทายเพิ่มเติมของ MLOps:
- การเบี่ยงเบนของข้อมูล: ข้อมูลในการผลิตจะเคลื่อนออกจากข้อมูลในการฝึกอบรมเมื่อเวลาผ่านไป โมเดลจะล้าสมัย
- คุณต้องสร้างเวอร์ชันสามสิ่ง: โค้ด ข้อมูล และโมเดล ทั้งสามอย่าง
- ความล้มเหลวแบบเงียบ: โมเดลสามารถล้มเหลวได้โดยไม่ขัดข้อง โดยปราศจากข้อผิดพลาด เพียงแค่สร้างการคาดการณ์ที่ไม่ถูกต้อง การจับสิ่งนี้ต้องมีการตรวจสอบ
นั่นเป็นเหตุผลว่าทำไมจึงมีความแตกต่างอย่างมากระหว่าง "โมเดลการทำงาน" และ "โมเดลพร้อมสำหรับการผลิต"
โมเดลบรรจุภัณฑ์และการนำเสนอ
ขั้นตอนแรกในการนำโมเดลไปใช้งานจริงคือการรวมไฟล์โมเดล ไลบรารีที่จำเป็น โค้ดในการประมวลผลล่วงหน้า และข้อมูลเวอร์ชันไว้ด้วยกันเป็นภาพรวมที่สามารถทำซ้ำได้ การวางคอนเทนเนอร์ (เช่น Docker: การวางแอปพลิเคชันในกล่องแยกที่มีการขึ้นต่อกันทั้งหมด) ถือเป็นมาตรฐานที่นี่ มันช่วยขจัดปัญหา "มันทำงานบนเครื่องของฉัน"
รูปแบบพื้นฐานสองประการในการให้บริการโมเดล:
- ออนไลน์/เรียลไทม์ (ออนไลน์): โมเดลอยู่เบื้องหลัง API ซึ่งส่งคืนการคาดการณ์ทันทีสำหรับทุกคำขอที่เข้ามา เวลาแฝงต่ำเป็นสิ่งสำคัญ
- เป็นกลุ่ม: โมเดลจะประมวลผลชุดข้อมูลขนาดใหญ่เป็นระยะ (เช่น สร้างคะแนนสำหรับลูกค้าทุกคนในเวลากลางคืน) เวลาแฝงไม่เกี่ยวข้อง ประสิทธิภาพเป็นสิ่งสำคัญ
ข้อใดถูกต้องขึ้นอยู่กับความต้องการทางธุรกิจ: คำแนะนำออนไลน์ทันที คะแนนความเสี่ยงรายเดือนเป็นชุด
เคล็ดลับ: "เรียลไทม์" เป็นต้นทุน ไม่ใช่ค่าเริ่มต้น แบทช์มีราคาถูกกว่าและง่ายกว่ามากหากใช้ผลลัพธ์ภายในไม่กี่ชั่วโมง คุณต้องการคำตอบทันทีจริง ๆ หรือไม่? ถามอันนั้นก่อน
กลยุทธ์การกระจายที่ปลอดภัย
การเปิดโมเดลใหม่ให้กับการรับส่งข้อมูลทั้งหมดโดยตรงนั้นมีความเสี่ยง หากผิดพลาดทุกคนได้รับผลกระทบ รูปแบบการกระจายที่ปลอดภัย:
- การปรับใช้เงา: โมเดลใหม่ได้รับปริมาณการใช้งานจริง แต่การคาดการณ์จะไม่แสดงให้ผู้ใช้เห็น แต่จะบันทึกไว้เท่านั้น นำไปเปรียบเทียบกับรุ่นเก่าเพื่อดูว่าปลอดภัยในข้อมูลจริงหรือไม่
- การปรับใช้ Canary: โมเดลใหม่นี้เปิดตัวครั้งแรกกับปริมาณการรับส่งข้อมูลเพียงเล็กน้อย (เช่น 5%) ถ้าไม่มีปัญหาก็จะค่อยๆ เพิ่มขึ้น
- การทดสอบ A/B: มีการนำเสนอสองแบบจำลองต่อผู้ใช้จริงพร้อมกันและมีการเปรียบเทียบการวัดทางธุรกิจ (Conversion, คลิก)
- ย้อนกลับ: ความสามารถในการเปลี่ยนกลับเป็นเวอร์ชันเก่าอย่างรวดเร็วหากรุ่นใหม่ปรากฏว่าไม่ดี การปรับใช้ทุกครั้งควรมีแผนย้อนกลับ
ข้อควรระวัง: การปรับใช้โดยไม่มีแผนการย้อนกลับจะไม่เสร็จสมบูรณ์ ความสามารถในการเปลี่ยนกลับเป็นเวอร์ชันเก่าได้ภายในไม่กี่นาทีจะช่วยปกป้องผู้ใช้เมื่อโมเดลใหม่ทำงานโดยไม่คาดคิดในเวอร์ชันที่ใช้งานจริง ทดสอบสิ่งนี้ก่อนที่จะปรับใช้
แนวทางที่อ่อนแอ / แนวทางที่แข็งแกร่ง
จุดอ่อน: "โมเดลนี้ดีในการทดสอบ เราเผยแพร่ เราเปิดให้ทุกคนเข้าชม"
Güçlü: "เราสร้างโมเดลในคอนเทนเนอร์และติดป้ายกำกับว่าเป็นเวอร์ชัน ขั้นแรก เราใช้งานมันในโหมดแชโดว์พร้อมปริมาณการใช้งานจริงเป็นเวลา 3 วัน โดยเปรียบเทียบการคาดการณ์กับโมเดลเก่า ซึ่งยอมรับความเบี่ยงเบนได้ จากนั้นเราเปิดมันด้วยคานารี 5% ตรวจสอบตัววัดปริมาณงานและเวลาแฝง เมื่อไม่มีปัญหา เราก็ค่อยๆ เพิ่มเป็น 100% เราได้ทดสอบคำสั่งย้อนกลับล่วงหน้าแล้ว"
ความแตกต่าง: แนวทางที่ชัดเจนคือแบบค่อยเป็นค่อยไป วัดได้ และย้อนกลับได้ ความเสี่ยงมีจำกัดในทุกขั้นตอน
CI/CD และระบบอัตโนมัติ
CI/CD (การผสานรวมอย่างต่อเนื่อง / การปรับใช้อย่างต่อเนื่อง: ไปป์ไลน์ของการทดสอบและปล่อยการเปลี่ยนแปลงโค้ดโดยอัตโนมัติ) ใน ML ไม่เพียงแต่ครอบคลุมโค้ดเท่านั้น แต่ยังรวมถึงขั้นตอนข้อมูลและโมเดลด้วย ไปป์ไลน์ ML CI/CD ที่ดี: รันการทดสอบเมื่อโค้ดเปลี่ยนแปลง ดำเนินการตรวจสอบข้อมูล ฝึกโมเดลใหม่ (หากจำเป็น) ตรวจสอบเกณฑ์การประเมิน และเลื่อนระดับการใช้งานเฉพาะเมื่อถึงขีดจำกัดนั้น หลักการของ “การฝึกอบรมเป็นไปโดยอัตโนมัติ การปรับใช้เป็นไปตามเกณฑ์” ป้องกันไม่ให้โมเดลที่ไม่ดีรั่วไหลไปสู่การใช้งานจริงอย่างเงียบๆ
AI มีประโยชน์มากเมื่อตั้งค่าไปป์ไลน์เหล่านี้: การเขียนแบบร่างไฟล์การกำหนดค่า (YAML) กรณีทดสอบ สคริปต์การปรับใช้ แต่คุณเป็นผู้กำหนดเกณฑ์การกระจาย (ตัวชี้วัดใดก็ตามที่เกินกว่าค่าที่เผยแพร่) และนโยบายการย้อนกลับ นี่คือการตัดสินใจความเสี่ยงทางธุรกิจ
โครงสร้างพื้นฐานการทำซ้ำ
เพื่อสร้างลักษณะการทำงานของแบบจำลองในการผลิตขึ้นใหม่ การลงทะเบียนแบบจำลอง: บันทึกที่เก็บข้อมูลและโค้ดของแบบจำลองใดที่ได้รับ และหน่วยวัดใดที่ได้รับ สำหรับโมเดลการผลิตแต่ละโมเดล ควรติดตามสิ่งต่อไปนี้: เวอร์ชันข้อมูลการฝึกอบรม เวอร์ชันโค้ด (คอมมิต git) ไฮเปอร์พารามิเตอร์ คะแนนการประเมิน และวันที่ปรับใช้ เมื่อเกิดปัญหา คุณควรตอบคำถามที่ว่า "แบบจำลองใดที่สร้างการทำนายนี้ด้วยข้อมูลใด" ภายในไม่กี่นาที เราจะเจาะลึกเรื่องนี้ในหน่วยที่ 11
มินิเคสสามอัน
กรณีที่ 1 - ปัญหาที่เกิดจากการกระจายเงา โมเดลคำแนะนำเอาชนะโมเดลเก่าในการทดสอบ พบว่าการใช้งานกับปริมาณการใช้งานจริงในโหมดเงานั้นให้ข้อเสนอแนะที่ไม่ดีมากสำหรับผู้ใช้กลุ่มใดกลุ่มหนึ่ง (ผู้ใช้ใหม่) ข้อมูลการทดสอบเป็นตัวแทนของกลุ่มนี้น้อยเกินไป โมเดลได้รับการแก้ไขโดยไม่เคยแสดงให้ผู้ใช้เห็น หากเปิดโดยตรง ประสบการณ์ผู้ใช้ใหม่จะหยุดชะงัก
กรณีที่ 2 - การกระจายแบบเพิกถอนไม่ได้ ทีมงานเปิดตัวรูปแบบการกำหนดราคาใหม่สำหรับการรับส่งข้อมูลทั้งหมด โดยไม่มีแผนย้อนกลับ โมเดลนี้ตั้งราคาสินค้าบางอย่างอย่างไม่คาดคิดโดยไม่คาดคิด การเปลี่ยนกลับเป็นเวอร์ชันเก่าใช้เวลาหลายชั่วโมงเนื่องจากกระบวนการยังไม่พร้อม มีการสูญเสียรายได้อย่างรุนแรง หลังจากนั้น มีการเพิ่มการทดสอบการย้อนกลับภาคบังคับในการปรับใช้ทุกครั้ง
กรณีที่ 3 - การเคลื่อนตัวของข้อมูลแบบเงียบๆ รูปแบบการฉ้อโกงปรากฏเป็นเวลาหลายเดือนโดยไม่มีข้อผิดพลาดใดๆ แต่กลยุทธ์ของผู้ฉ้อโกงเปลี่ยนไป (การเบี่ยงเบนของข้อมูล) และการเรียกคืนโมเดลก็ลดลงอย่างเงียบ ๆ ไม่มีใครสังเกตเห็นเพราะไม่มีการติดตาม เมื่อมีการจัดตั้งแผงติดตามการกระจายการคาดการณ์ การเบี่ยงเบนก็มองเห็นได้ตั้งแต่เนิ่นๆ เราจะครอบคลุมการติดตามในหน่วยที่ 8
เทมเพลตที่คัดลอกได้
เขียนร่างแผนการปรับใช้สำหรับโมเดลนี้ รุ่น: [มันทำอะไร] การใช้งาน: [ออนไลน์หรือเป็นชุด?] ควรรวมถึง:1) การบรรจุภัณฑ์ (คอนเทนเนอร์ การกำหนดเวอร์ชัน)2) กลยุทธ์การปรับใช้ส่วนเพิ่ม (เงา/คานารี/A-B) และเหตุผล3) ตัวชี้วัดที่จะติดตาม (ธุรกิจ + เทคนิค + เวลาแฝง)4) แผนการย้อนกลับและวิธีการทดสอบ5) เกณฑ์การปรับใช้งาน (ตัวชี้วัดใดควรเกินค่าใด)
ตรวจสอบไปป์ไลน์ ML CI/CD นี้:1) มีการตรวจสอบความถูกต้องของข้อมูลในบรรทัดหรือไม่2) การปรับใช้สามารถดำเนินการต่อไปโดยไม่ถือเกณฑ์การประเมินได้หรือไม่ (ไม่ควรถือ)
ช่วยฉันตัดสินใจว่าการนำเสนอแบบออนไลน์หรือแบบกลุ่มเหมาะสำหรับโมเดลนี้ ผลลัพธ์จะถูกใช้นานเท่าใด: [ทันที / นาที / ชั่วโมง / วัน]ปริมาณคำขอที่คาดหวัง: [หมายเลข]มีข้อจำกัดด้านความล่าช้าหรือไม่: [ms]คุณจะแนะนำข้อใดในแง่ของต้นทุนและความซับซ้อน และเพราะเหตุใด
เขียนขั้นตอนการย้อนกลับสำหรับรุ่นนี้- ตัวชี้วัด/เกณฑ์ใดที่กระตุ้นให้เกิดประสิทธิภาพต่ำ- ขั้นตอนการย้อนกลับคืออะไร- การย้อนกลับควรใช้เวลานานเท่าใด (เป้าหมาย)- ฉันจะทดสอบขั้นตอนนี้ก่อนการผลิตได้อย่างไร
ตารางรูปแบบการนำเสนอ
เกณฑ์
ออนไลน์ (เรียลไทม์)
แบทช์
ล่าช้า
วิกฤติ (มิลลิวินาที)
ไม่มีนัยสำคัญ
การใช้งาน
ต้องการการตอบสนองทันที
คะแนนเป็นระยะ
ราคา
สูง
ต่ำ
ความซับซ้อน
สูง
ต่ำ
ตัวอย่าง
แนะนำสดหลอกลวง
คะแนนความเสี่ยงรายเดือน
ข้อผิดพลาดทั่วไป
- แจกจ่ายโดยไม่มีแผนในการเรียกคืน ผิดรุ่นกระทบถึงผู้ใช้ทั้งหมด
- เปิดโดยตรงสู่การเข้าชม 100% จำกัดความเสี่ยงด้วยการกระจายแบบเซ
- ไม่จัดให้มีการตรวจติดตาม โมเดลนี้สร้างข้อผิดพลาดแบบเงียบๆ โดยไม่มีข้อผิดพลาด
- การนำเสนอแบบเรียลไทม์ซ้ำซ้อน แม้ว่าการแบทช์จะเพียงพอ แต่ต้นทุนและความซับซ้อนก็เพิ่มขึ้น
- ไม่เชื่อมโยงเวอร์ชันรหัสข้อมูลโมเดล คุณไม่สามารถเกิดปัญหาได้
- ปล่อยอัตโนมัติโดยไม่มีเกณฑ์การกระจาย นางแบบตัวร้ายแอบเข้ามาเงียบๆ
โดยสรุป
การย้ายแบบจำลองไปสู่การใช้งานจริงเป็นงานด้านวิศวกรรมที่แตกต่างและมักจะยากกว่าการฝึกอบรม ML จำเป็นต้องมีระเบียบวินัยเพิ่มเติมเนื่องจากขึ้นอยู่กับสามโมเดลโค้ด-ข้อมูล-โมเดล: การบรรจุภัณฑ์และการกำหนดเวอร์ชัน รูปแบบการจัดส่ง (ออนไลน์/แบทช์) ที่เหมาะกับความต้องการทางธุรกิจ การปรับใช้แบบค่อยเป็นค่อยไปและแบบย้อนกลับได้ CI/CD ที่ควบคุมตามเกณฑ์ และการลงทะเบียนโมเดล ปัญญาประดิษฐ์เป็นตัวช่วยที่ทรงพลังในการสร้างโค้ดและการกำหนดค่าโครงสร้างพื้นฐานนี้ แต่เกณฑ์การกระจาย นโยบายการเรียกคืน และการตัดสินใจด้านความเสี่ยงเป็นของคุณ การแจกจ่ายโดยไม่มีแผนการย้อนกลับจะไม่เสร็จสมบูรณ์
งานสมัคร
บรรจุโมเดล (นักเทียบท่า) และติดป้ายกำกับเวอร์ชัน ตัดสินใจว่าคุณจะเสนอออนไลน์หรือเป็นกลุ่มตามความต้องการทางธุรกิจของคุณและเขียนเหตุผลของคุณ จัดทำเอกสารแผนการปรับใช้แบบเป็นขั้นตอน (เงาหรือคานารี) และขั้นตอนการย้อนกลับที่ทดสอบแล้ว ตรวจสอบให้แน่ใจว่าได้บันทึกเวอร์ชันข้อมูล การคอมมิตโค้ด และคะแนนการประเมินในรีจิสตรีโมเดล
รายการตรวจสอบ
- [ ] โมเดลได้รับการบรรจุและกำหนดเวอร์ชัน (คอนเทนเนอร์ + ป้ายกำกับ)
- [ ] เลือกรูปแบบการนำเสนอ (ออนไลน์/ชุด) ตามความต้องการทางธุรกิจ
- [ ] มีการใช้กลยุทธ์การปรับใช้แบบเป็นขั้น (เงา/คานารี)
- [ ] ขั้นตอนการย้อนกลับที่เขียนและทดสอบ
- [ ] CI/CD จะไม่เลื่อนการใช้งานก่อนที่จะถึงเกณฑ์การประเมิน
- [ ] รีจิสทรีโมเดลเก็บลิงก์ data+code+metric