רווחים:
- יכולת לזהות את האתגרים המיוחדים של ML הקשורים לשלישיית הקוד-נתונים-מודל והחבילה ולהציג את המודל באופן מקוון או באצווה לפי הצורך העסקי.
- יכולת ליישם דפוסי פריסה הדרגתיים והחזרה לאחור (צל, כנרית, A/B, החזרה לאחור) ולהוסיף תוכנית החזרה בדוקה לכל פריסה
- היכולת לשמור על הקישור הנתונים-קוד-מטרי של המודל שהוכנס לייצור ניתן למעקב באמצעות CI/CD ורישום מודל מבוקרים בסף הערכה
השגת דגם להשיג דיוק של 95% במחברת היא רק חצי מהסיפור. החצי השני - לרוב החלק הקשה - הוא להביא את המודל הזה למשתמשים אמיתיים בצורה אמינה, ניתנת להרחבה וניתנת לתחזוקה. MLOps (Machine Learning Operations: הדיסציפלינה של הכנסת, הפעלה ותחזוקה של מודלים של ML לייצור) משלבת את שיטות ה-DevOps של הנדסת תוכנה עם האתגרים הייחודיים של ML. ביחידה זו אנו מכסים את השלבים של העברת הדגם לייצור וכיצד בינה מלאכותית מסייעת בתהליך זה.
מדוע ML שונה מתוכנה רגילה?
בתוכנה רגילה, ההתנהגות היא בקוד; אם הקוד לא משתנה, ההתנהגות לא משתנה. ב-ML, ההתנהגות תלויה הן בקוד, בנתונים והן במודל. שלושת הממדים הללו יוצרים את האתגרים הנוספים של MLOps:
- סחף נתונים: הנתונים בייצור מתרחקים מהנתונים באימון לאורך זמן; הדגם מתיישן.
- אתה צריך לגרסת שלושה דברים: קוד, נתונים ומודל - שלושתם.
- כשל שקט: מודל יכול להיכשל בלי לקרוס, בלי לתת שגיאות, פשוט על ידי הפקת תחזיות שגויות. לתפוס את זה דורש ניטור.
לכן יש הבדל גדול בין "מודל עובד" ל"דגם מוכן לייצור".
דגם אריזה והצגה
השלב הראשון בהכנסת המודל לייצור הוא אריזתו: קובץ הדגם, הספריות הדרושות, קוד עיבוד מקדים ומידע על הגרסה יחד כמכלול שניתן לשחזר. קונטיינריזציה (למשל Docker: הכנסת האפליקציה לקופסה מבודדת עם כל התלות שלה) היא סטנדרטית כאן; זה מבטל את בעיית "זה עבד על המחשב שלי".
שני דפוסים בסיסיים של הגשת הדגם:
- מקוון/זמן אמת (מקוון): המודל יושב מאחורי API, ומחזיר חיזוי מיידי לכל בקשה נכנסת. זמן אחזור נמוך הוא קריטי.
- אצווה: המודל מעבד מערכי נתונים גדולים מעת לעת (למשל מייצר ציונים לכל הלקוחות בלילה). חביון לא רלוונטי, יעילות חשובה.
איזה מהם נכון תלוי בצורך העסקי: המלצה מיידית באינטרנט, ציון סיכון חודשי באצווה.
טיפ: "זמן אמת" הוא עלות, לא ברירת המחדל. אצווה היא הרבה יותר זולה ופשוטה אם התוצאה תשמש תוך שעות. האם אתה באמת צריך תשובה מיידית? תשאל את זה קודם.
אסטרטגיות הפצה מאובטחות
פתיחת דגם חדש ישירות לכל התעבורה היא מסוכנת; אם זה לא בסדר, כולם מושפעים. דפוסי הפצה בטוחים:
- פריסת צללים: המודל החדש מקבל תעבורת ייצור, אך תחזיותיו אינן מוצגות למשתמש, אלא רק מתועדות. זה מושווה לדגם הישן כדי לראות אם הוא בטוח בנתונים אמיתיים.
- פריסה קנרית: הדגם החדש מושק לראשונה לאחוז קטן מהתנועה (למשל 5%); אם אין בעיה, זה גדל בהדרגה.
- בדיקת A/B: שני מודלים מוצגים למשתמש האמיתי במקביל ומשווים מדדים עסקיים (המרה, קליקים).
- החזרה לאחור: יכולת לחזור במהירות לגרסה הישנה אם הדגם החדש יתברר כגרוע. לכל פריסה צריכה להיות תוכנית החזרה לאחור.
זהירות: פריסה ללא תוכנית החזרה לא הושלמה. היכולת לחזור לגרסה הישנה תוך דקות מגינה על המשתמש כאשר הדגם החדש מתנהג באופן בלתי צפוי בייצור. בדוק זאת לפני הפריסה.
גישה חלשה / גישה חזקה
חלש: "הדגם היה טוב בבדיקה, יצאנו לאוויר, פתחנו אותו לכולם".
Güçlü: "שיכלנו את המודל, תייגנו אותו כגרסה. ראשית, הרצנו אותו במצב צל עם תעבורת ייצור למשך 3 ימים, והשוואנו את התחזיות עם המודל הישן - הסטייה הייתה מקובלת. אחר כך פתחנו אותו עם 5% קנרי, ניטרנו את מדדי התפוקה וההשהיה. כשלא היו בעיות, הגדלנו בהדרגה את הפקודה החזרה ל-100%.
ההבדל: הגישה החזקה היא הדרגתית, מדודה והפיכה. הסיכון מוגבל בכל שלב.
CI/CD ואוטומציה
CI/CD (Intinuous Integration / Continuous Deployment: צינור של בדיקה ושחרור אוטומטי של שינויים בקוד) ב-ML מכסה לא רק את הקוד אלא גם את שלבי הנתונים והמודל. צינור ML CI/CD טוב: מפעיל בדיקות כאשר הקוד משתנה, מבצע אימות נתונים, מכשיר מחדש את המודל (במידת הצורך), בודק ספי הערכה ומקדם את הפריסה רק אם הספים מתקיימים. העיקרון של "האימון הוא אוטומטי, הפריסה מבוססת סף" מונע מהדגם הגרוע לדלוף בשקט לייצור.
AI מאוד מועיל בעת הגדרת צינורות אלה: כתיבת טיוטות של קבצי תצורה (YAML), מקרי בדיקה, סקריפטים של פריסה. אבל אתה קובע את ספי ההפצה (כל המדד חורג מהערך שמתפרסם) ואת מדיניות ההחזרה; אלו החלטות סיכון עסקיות.
תשתית לשחזור
על מנת לשחזר התנהגות של מודל בייצור, רישום מודל: רישום ששומר איזה דגם הוכשר עם איזה נתונים וקוד, ואילו מדדים הוא קיבל. עבור כל מודל ייצור, צריך להיות מעקב אחר הדברים הבאים: גרסת נתוני אימון, גרסת קוד (git commit), היפרפרמטרים, ציוני הערכה ותאריך פריסה. כאשר מתעוררת בעיה, אתה אמור להיות מסוגל לענות על השאלה "איזה דגם הפיק את התחזית הזו, עם אילו נתונים?" תוך דקות. נעמיק זאת ביחידה 11.
שלושה מיני תיקים
מקרה 1 - בעיה שנתפסה על ידי חלוקת הצללים. מודל המלצה גבר על הישן בבדיקה. הפעלתו עם תעבורת ייצור במצב צל נמצאה לייצר המלצות גרועות מאוד לפלח מסוים של משתמשים (משתמשים חדשים) - נתוני הבדיקה היו חסרי ייצוג של פלח זה. הדגם תוקן מבלי שהוצג למשתמש. אם הוא ייפתח ישירות, חוויית המשתמש החדשה תופרע.
מקרה 2 - חלוקה בלתי חוזרת. צוות הוציא מודל תמחור חדש לכל התנועה, ללא תוכניות החזרה. הדגם תמחר באופן בלתי צפוי כמה מוצרים בזול מאוד. החזרה לגרסה הישנה ארכה שעות כי התהליך לא היה מוכן. היה אובדן הכנסה רציני. לאחר מכן, נוספו בדיקות ביטול חובה לכל פריסה.
מקרה 3 - סחף נתונים שקט. דפוס הונאה הופיע במשך חודשים ללא שגיאות. אבל הטקטיקה של הרמאים השתנתה (סחף נתונים) והריקול של הדוגמנית ירד בשקט. אף אחד לא שם לב כי לא היה פיקוח. לאחר שהוקם פאנל לניטור התפלגות תחזיות, הסחף נהיה גלוי מוקדם. אנו נסקור ניטור ביחידה 8.
תבניות הניתנות להעתקה
כתוב טיוטת תוכנית פריסה עבור מודל זה. דגם: [מה זה עושה], שימוש: [מקוון או אצווה?] צריך לכלול: 1) אריזה (מיכל, גרסאות) 2) אסטרטגיית פריסה מצטברת (צל/כנרית/A-B) ומדוע 3) מדדים למעקב (עסקי + טכני + חביון) 4) תוכנית החזרה ואיך לבדוק5) ספי הפריסה צריכים לחרוג מאיזה ערך (איזה ערך)
בדוק את הצינור הזה של ML CI/CD: 1) האם אימות נתונים בקו? 2) האם הפריסה יכולה להמשיך בלי להחזיק את סף ההערכה (האם לא)? 3) האם החזרה לאחור אוטומטית? 4) האם מתבצע מעקב אחר נתונים+קוד+מדדים ברישום המודל?
עזרו לי להחליט אם מצגת מקוונת או אצווה מתאימה לדגם הזה. כמה זמן ישמש התוצאה: [מיידית / דקה / שעה / יום] נפח בקשה צפוי: [מספר] האם יש אילוץ עיכוב: [ms] על איזה מהם היית ממליץ מבחינת עלות ומורכבות ומדוע?
כתוב הליך החזרה לאחור עבור דגם זה.- איזה מדד/סף מפעיל ביצועים גרועים?- מהם שלבי החזרה לאחור?- כמה זמן החזרה לאחור צריכה לקחת (יעד)?- איך אני בודק הליך זה לפני הייצור?
טבלת דפוסי מצגת
קריטריון
מקוון (זמן אמת)
אצווה
עיכוב
קריטי (ms)
חסר משמעות
שימוש
נדרשת תגובה מיידית
ציון תקופתי
עלות
גבוה
נמוך
מורכבות
גבוה
נמוך
דוגמה
המלצה חיה, הונאה
ציון סיכון חודשי
טעויות נפוצות
- הפיצו ללא תוכנית שליפה. דגם שגוי פוגע בכל המשתמש.
- נפתח ישירות ל-100% תנועה. הגבל את הסיכון עם הפצה מדורגת.
- לא הקמת ניטור. המודל מייצר שגיאות בשקט, ללא שגיאות.
- מצגת מיותרת בזמן אמת. בעוד שהאצווה מספיקה, העלות והמורכבות גדלות.
- לא מקשר בין גרסאות מודל-נתונים-קוד. אתה לא יכול לשחזר את הבעיה.
- שחרור אוטומטי ללא סף הפצה. הדוגמנית הרעה מתגנבת בשקט.
לסיכום
העברת הדגם לייצור היא משימה הנדסית שונה ולרוב קשה יותר מאשר הכשרתו. ML דורשת משמעת נוספת מכיוון שהיא תלויה בשלישיית קוד-נתונים-מודל: אריזה וגירסאות, דפוס אספקה (מקוון/אצווה) המתאים לצורך העסקי, פריסה הדרגתית והפיכה, CI/CD מבוקרת סף ורישום מודל. בינה מלאכותית היא כלי עזר רב עוצמה ביצירת הקוד והתצורה של תשתית זו; אבל ספי ההפצה, מדיניות החזרת החזר והחלטות הסיכון הם שלך. הפצה ללא תוכנית החזרה לא הושלמה.
משימת יישום
מיכל (Docker) דגם ותייג אותו לגרסה. החלט אם תציע מקוון או אצווה על סמך הצרכים העסקיים שלך וכתוב את ההצדקה שלך. תיעוד תוכנית פריסה מדורגת (צל או כנרית) ונוהל החזרה נבדק. הקפד לרשום את גרסת הנתונים, התחייבות הקוד וציוני ההערכה ברישום המודלים.
רשימת בדיקה
- [ ] הדגם ארוז ובגרסה (מיכל + תווית).
- [ ] דפוס המצגת (מקוון/אצווה) נבחר בהתאם לצורך העסקי.
- [ ] יושמה אסטרטגיית פריסה מדורגת (צל/כנרית).
- [ ] נוהל החזרה כתוב ונבדק.
- [ ] CI/CD אינו מקדם את הפריסה לפני עמידה בסף ההערכה.
- [ ] רישום המודלים מחזיק את הקישור data+code+metric.