ML CI/CD: אימון אוטומטי, פריסה וניטור של מודלים

מדוע CI/CD ML מתפרק לפעולות ידניות

מחזור האימון וההעלאה של המודל לפרודקשן נשען לעתים קרובות על מהנדס אחד והמחשב הנייד שלו. את האימון מריצים ידנית — בסקריפט, עם פרמטרים שזוכרים בעל פה, ועל דגימה שהוצאה לפני שבוע.

מעקב ניסויים כמו MLflow מותקן, אך חלק מההרצות עוקפות אותו, והניתנות לשחזור של הניסויים הולכת לאיבוד: אין במה להשוות שני מודלים מלבד קובץ מדדים ששרד.

הפער הבא — אי-התאמה בין הסביבות. האימון עבר על גרסה אחת של ספריות, והאינפרנס הוקם על אחרת, וחלק מהפיצ'רים בסביבת הפרודקשן מחושבים אחרת מאשר באימון. המדד על סט הוולידציה נראה תקין, אך ההתנהגות בפרודקשן סוטה ממנו — וכבר אין אפשרות לקשור זאת לשינוי מסוים.

הפער השלישי — ההפצה של המודל לפרודקשן. את המשקלים מעתיקים לשרת ידנית, את הקונפיגורציה מתקנים במקום, ואין רולבק: אם האיכות ירדה, את הגרסה הקודמת משחזרים מגיבוי. לאחר ההפצה את מדדי האיכות מחשבים באופן לא סדיר, ולכן את הדגרדציה מזהים דרך פניות משתמשים ולא דרך גרף.

בסופו של דבר ci/cd ml קיים לא כתהליך אלא כאוסף של פעולות ידניות בין האימון לסביבת הפרודקשן — כל אחת מהן עלולה להישבר בשקט. נבחן כיצד המחזור הזה נסגר ומה בדיוק עובר אוטומציה.

מה נותנת האוטומציה של אימון והפצת מודלים

הפצה ידנית של מודל נמשכת ימים: איסוף נתונים, אימון על מחשב מקומי, הוצאה ידנית של המשקלים, העברה לשרת, בדיקה «בעין».

הצינור של CI/CD ML עובר את הנתיב הזה לפי קומיט או לפי לוח זמנים — מהיפותזה ועד מודל עובד נשארות שעות ולא שבועות, וכל הרצה ניתנת לשחזור לפי גרסאות נתונים ופרמטרים מקובעות.

אימון מחדש אוטומטי מסיר את המקור העיקרי לדגרדציה שקטה, שבה המודל ממשיך לעבוד על נתונים מיושנים ואיש אינו יודע על כך. הטריגר הוא לוח זמנים, הגעת מנה חדשה של דוגמאות מתויגות או ירידה של מדדי האיכות מתחת לסף: האימון מחדש מופעל מעצמו, והגרסה החדשה עוברת את אותן בדיקות כמו הקודמת.

ניטור דגרדציה משווה את התפלגויות הקלט ואיכות החיזויים למול הייחוס, ולכן את הירידה רואים לפני שהמשתמשים מבחינים בה. סטייה בשיעור הכשלים, עלייה בשגיאות בסגמנטים מסוימים, הסחה של פיצ'רים — כל אות כזה עוצר את ההפצה אוטומטית.

רולבק הוא החזרת המצביע לגרסה יציבה קודמת של המודל: דקות במקום שעות של בנייה מחדש ידנית. יחד עם השלבים הידניים נעלם סוג שלם של כשלים: שכחו לאמן מחדש, העלו קובץ משקלים שגוי, לא השוו את המדד לפני ההפצה.

זמן ההתאוששות לאחר תקלה מפסיק להיות תלוי במי מהמהנדסים בתורנות ובשאלה אם הוא זוכר כיצד נבנתה הגרסה הקודמת.

מצבי אוטומציה: מלא, היברידי וידני

מצב האוטומציה קובע כמה שלבים במחזור — אימון מחדש, בדיקת איכות, פריסה ורולבק — עוברים ללא מעורבות מהנדס. ההבדל בין האפשרויות אינו ב«רמת הקדמה», אלא בשלב שבו האדם מקבל את ההחלטה על הפצת גרסה חדשה של המודל לסביבת הפרודקשן.

את הבחירה מכתיבים שלושה דברים: מחיר הטעות של המודל, תדירות הגעת נתונים חדשים ובגרות התהליכים בצוות. להלן — במה נבדלים המצבים מבחינת התאמה ומה כל אחד מהם מגביל.

בפועל לרוב המשימות מספיק צינור היברידי: האימון מחדש מופעל לפי לוח זמנים או עם ירידת המדדים, והפריסה ממתינה לאישור. זה שומר על שליטה בלי שגרה ידנית, וככל שנצברת סטטיסטיקה על ריליסים, שלבים בודדים מועברים לאוטומציה מלאה — ולא להפך.

הטמעת CI/CD ML: שלבי העבודה ההנדסית

המשימה — להפוך את האימון והפריסה של המודלים מהליך ידני לצינור צפוי. מתחילים בסקר של מחזור האימון: היכן חיים הנתונים, כיצד מופעל האימון, מי מפרסם את המודל ואילו שלבים נשענים על פעולות ידניות.

שם בדרך כלל הולכת לאיבוד הניתנות לשחזור — אי אפשר לחזור על התוצאה, והרולבק לגרסה הקודמת נבנה ידנית. בהמשך בונים את הצינור כך שכל מעבר יהיה אוטומטי וניתן לבדיקה.

סדר העבודה

1. סקר של מחזור האימון. מתעדים את מקורות הנתונים, נקודות ההתערבות הידנית והזמן מרגע הופעת נתונים חדשים ועד עדכון המודל בפרודקשן. צוואר הבקבוק הוא לרוב הכנת הפיצ'רים והפריסה הידנית.
2. תרשים הצינור. מתאמים את השרשרת: הכנת נתונים, אימון, בדיקת איכות, פריסה, ניטור. בתרשים מסמנים היכן נמצאות הבדיקות האוטומטיות ולפי אילו כללים מופעל הרולבק.
3. ניהול גרסאות של נתונים ומודלים. יוצרים תצלומי מצב של מערכי הנתונים ומקשרים כל מודל לנתונים, לקוד ולמדדים שעליהם אומן: כל גרסה ניתנת לשחזור ולהשוואה מול הקודמת.
4. הגדרת הסביבות והצינור. מפרידים בין סביבת הניסויים לסביבת הפרודקשן, מקביעים תלויות, מפעילים אימון לפי אירוע — נתונים חדשים או שינוי בקוד. הפריסה לפרודקשן נשארת באישור האחראי.
5. בדיקה על נתונים היסטוריים. מריצים את הצינור על תקופות עבר ומשווים את התוצאה למודל שבפרודקשן. קובעים ספי איכות שמתחתם הפריסה אינה עוברת אוטומטית.
6. קבלה ומסירה. מבצעים ריליס הדגמה יחד עם צוות הלקוח, מוסרים תיעוד של הצינור, תקנון רולבק והגדרות ניטור.

לאחר המסירה הצוות מפעיל את עדכון המודל בעצמו, ללא התמיכה שלנו בכל שלב.

ארטיפקטים של הפרויקט: קונפיגורציות, תרשימים ותקנונים

את הפרויקט מוסרים לא כמצגת אלא כסביבה עובדת שהצוות שלכם ממשיך להפעיל בעצמו. כל האמור לעיל נשאר אצלכם במאגרי הקוד ובבסיס הידע הפנימי — עם גרסאות, הערות ואחראים מצוינים, ולא בהתכתבות עם הספק.

• קונפיגורציות של הצינור — תיאור שלבי האימון וההפצה: הכנת נתונים, אימון, בדיקות איכות, פרסום המודל. שינויים עוברים דרך רוויו ולא דרך פעולות ידניות בממשק.
• תרשים ארכיטקטורה — זרימת הנתונים מהמקורות ועד שירות החיזוי, נקודות בקרת האיכות, מאגרי הגרסאות של המודלים והארטיפקטים הקשורים.
• מדיניות הרשאות — תפקידי המהנדסים, האנליסטים והתמיכה, הרשאות להפעלת אימון מחדש ולהפצה לפרודקשן, הפרדת סביבות, סדר העבודה עם מפתחות וסודות.
• תקנון הפצת המודל — רצף הבדיקות לפני הפריסה, תנאי הקבלה לפי מדדים, מי מאשר, כיצד מתועדת הגרסה ומה נכנס ליומן השינויים.
• תקנון רולבק של המודל — כיצד מחזירים את הגרסה הקודמת ואת הקונפיגורציה הקודמת, מי מקבל את ההחלטה, לפי אילו אותות ניטור מופעל הרולבק.
• תקנון הניטור — מערך מדדי האיכות והיציבות, ספי ההפעלה, למי נשלחת התראה ובתוך איזה פרק זמן מצופה תגובה.
• תיעוד הנתונים והמודל — מקורות, תרשים הפיצ'רים, כללי התיוג, מגבלות היישום ונקודות התורפה הידועות של הגרסה.
• הוראות תמיכה ותחזוקה — פעולות שגרתיות: אימון מחדש לפי לוח זמנים, תגובה לדגרדציה של מדדים, עדכון תלויות, טיפול באירועים.

במסירה עוברים על כל סעיף יחד עם המהנדסים שלכם: מראים היכן זה נמצא, כיצד לשנות ומה לבדוק לאחר השינוי. את התקנונים כותבים לפי תהליך האישור שלכם, ולא לפי מה שנוח לנו.

מקרה בוחן: כיצד בוטלו ההרצות הידניות וההשבתות של המודלים

לפני הפרויקט צוות הלקוח הפיץ מודל אחת לשבועיים: האימון מחדש הופעל ידנית מהמחשב הנייד של המהנדס, הארטיפקטים נשמרו בתיקייה משותפת, והגרסה בפרודקשן נקבעה לפי הזיכרון. כל הפצה — 12-15 פעולות ידניות: אימון, בדיקת מדדים, בניית אימג', עריכת קונפיגים, דיפלוי ופיקוח בשעות הראשונות. אם האיכות ירדה, הרולבק בוצע דרך עצירת השירות — 30-40 דקות של אי-זמינות.

מה שינו

את האימון מחדש קשרו לאירועים: עדכון של מערך האימון או ירידת מדד בבקרה מפעילים הרצה. הארטיפקטים והפרמטרים נשמרים ב-MLflow — לכל מודל יש גרסה, מחבר ומערך נתונים מקושר, ואת המצב ניתן לשחזר באופן חד-משמעי.

את ניטור המודלים הוציאו בנפרד: מחשבים את התפלגות פיצ'רי הקלט, את שיעור הכשלים ואת האיכות על משוב מתויג, וההתראות נשלחות לערוץ של צוות התורנות.

את העברת התעבורה הפכו לניתנת לשליטה — הגרסה החדשה מקבלת חלק מהבקשות, ובחריגת מדדים מהסף התעבורה חוזרת אוטומטית לגרסה הקודמת תוך 2-3 דקות וללא עצירת השירות.

מה שהושג: אפס פעולות ידניות בשבוע במקום שתים-עשרה, זמן הפצת המודל הצטמצם מכמה שעות ל-25 דקות, והרולבק הפסיק לדרוש השבתה. במהלך רבעון אף אירוע של דגרדציה באיכות לא הגיע עד לתלונות משתמשים.

במה שונה אימון מודל מבניית תוכנה רגילה

ביישום רגיל ההתנהגות מוגדרת בקוד: הבדיקה קובעת את התוצאה הצפויה, וכל עוד היא עוברת, הריליס תקין. למודל אין חוזה — אותו קוד אימון על נתונים אחרים נותן איכות אחרת, ומדד טוב בממוצע אינו מעיד על ההתנהגות בסגמנטים בודדים.

לכן לא מנהלים גרסה של קומיט בודד, אלא של כל החבילה: קוד האימון, תצלום הנתונים, הפרמטרים והסביבה. בלי תצלום, הרצה חוזרת נותנת משקלים אחרים, ואין במה להשוות בין שני ריליסים.

גם קריטריון המוכנות משתנה: מפיצים את המודל רק אם האיכות על סט מוחזק ובסגמנטים המרכזיים אינה נמוכה מזו של הגרסה הפעילה. דריפט נתונים מוסיף מימד שאין לתוכנה רגילה — האיכות יורדת מעצמה, בלי אף שינוי בקוד, והיא ניכרת רק דרך ניטור הפיצ'רים והמדדים.

הרולבק מורכב יותר: המשקלים הקודמים חסרי תועלת אם סכמת הפיצ'רים כבר השתנתה, ולכן הגרסאות של המודל, הנתונים והפיצ'רים מתקדמות יחד. נבחן כיצד המחזור הזה נסגר לצינור אוטומטי.

חששות טכניים לפני תחילת העבודה

חששות הנדסיים נוגעים כמעט תמיד לא למודל עצמו, אלא לחיים שלו בסביבה שלכם: מהיכן מגיעים הנתונים, מי מתחבר אליהם, במה מוכחת האיכות של הגרסה החדשה ומה יקרה בעת דגרדציה. להלן — תשובות למה שנבדק לרוב בשלב ההערכה.

כיצד בודקים שהגרסה החדשה של המודל אינה גרועה מהנוכחית?

לפני ההפצה המודל עובר מערך בדיקות קבוע על סט מוחזק ועל חתכים: מחלקות נדירות, תקופות עונתיות, סגמנטים אנומליים. ההשוואה נעשית מול הגרסה הפעילה — בעת רגרסיה במדדים המוסכמים ההפצה נחסמת אוטומטית, ולא לפי סיכום בצ'אט. את ההחלטה מקבל כלל, ולא המפתח.

מה יקרה אם המדדים ייפלו לאחר ההפצה?

הניטור עוקב לא רק אחר איכות התשובות אלא גם אחר התפלגות נתוני הקלט — הדגרדציה נראית לפני שהעסק מבחין בה. בחריגה מהסף מופעל רולבק לגרסה היציבה הקודמת: מדובר בדקות, ואין צורך בבנייה מחדש. האירוע נכנס לתור הטיפול יחד עם חתך הנתונים שנשמר ושבו הכול נשבר.

האם יש לאמן את המודל מחדש לפי לוח זמנים?

לוח זמנים הוא היגיינה, ולא הבטחה לעדכניות. האימון מחדש מופעל בנוסף לפי טריגרים: דריפט נתונים או הצטברות של נפח מתויג חדש. אם המדדים נשמרים בטווח התקין, המחזור המיותר אינו יוצא לדרך ואינו מבזבז משאבים של הסביבה.

נדון במשימה ונחזור עם אומדן ותוכנית

כדי לחזור עם אומדן ותוכנית עבודה, ולא עם מילים כלליות, אנחנו צריכים חתך של התהליך הנוכחי: כיצד המודל מאומן היום, היכן חיים הנתונים והארטיפקטים, מי מפרס אותם לסביבת הפרודקשן. ככל שנתוני הפתיחה קונקרטיים יותר, כך פחות הנחות בתוכנית וכך מוקדם יותר ההרצה העובדת הראשונה.

מה יידרש מצדכם:

• תיאור מחזור האימון הנוכחי: לפי אירוע או לוח זמנים הוא מופעל, כמה זמן נמשך, ובאמצעות מה מנוהלות הגרסאות של הנתונים ושל משקלי המודל.
• גישות למאגרי הקוד ולקונפיגורציות האימון — קריאה לצורך הסקר, כתיבה בענף נפרד.
• תרשים הנתונים: היכן נמצאים מערכי האימון, האם יש תיוג וכללים לבנייתו מחדש בעת שינוי הפיצ'רים.
• מבנה הסביבה: היכן פועל המודל, דרישות הבידוד, ומה אסור להוציא מחוץ לפרימטר.
• מדדי האיכות והכללים שלפיהם כיום נודע על דגרדציה של המודל בסביבת הפרודקשן.
• אחראי הקבלה מצדכם — זה שמאשר את התוצאה בכל שלב.
• מגבלות תקנוניות: חלונות פריסה, סדר אישור שינויים, דרישות לשמירת לוגים.

תארו את המשימה בצורה חופשית וצרפו את מה שכבר קיים. נחזור עם אומדן ותוכנית עבודה: שלבים, הרכב צוות, נקודות בקרה וקריטריוני קבלה.