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

MLflow: מדוע ניסויים אינם משוחזרים בסביבת הייצור

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

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

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

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

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

מה נותן מעקב מרכזי אחר ניסויים

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

רישום אחיד של הרצות וארטיפקטים

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

השוואת מודלים לפי אותן מטריקות

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

נפרק כיצד זה נסגר בסביבה שלכם.

אפשרויות פריסה של MLflow: השוואת מצבי עבודה

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

בידוד נתונים וגישה רשתית

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

אחסון ארטיפקטים ומטא-נתונים

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

כיצד אנחנו בונים את ההטמעה: שלבי העבודה ההנדסית

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

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

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

3. הגדרת המאגר והשרת. מרימים שרת MLflow, מחברים מאגר אובייקטים לארטיפקטים ומסד נתונים למטא-נתונים, מגדירים גיבויים וניקוי של הרצות ישנות. את רישום המודלים מקשרים לאותו מאגר, כדי שהגרסה והקבצים שלה לא יתפצלו.

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

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

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

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

מה הלקוח מקבל לידיו: תצורות ותקנונים

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

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

מדיניות גישה ותפקידים

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

תקנון ניהול ניסויים

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

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

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

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

מה עשינו ובאיזה שלב נתקלנו בבעיה

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

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

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

אחרי ההטמעה שיעור ההרצות הניתנות לשחזור — 96%, הרצה חוזרת נבנית תוך 20–30 דקות במקום שלושה ימים, והעברת המודל התקצרה משלושה שבועות ליומיים. נעלם סוג הכשל שבו המודל בסביבת הייצור מתנהג אחרת מאשר בניסוי.

במה MLflow שונה ממעקב ניסויים שנכתב באופן עצמאי

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

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

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

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

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

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

ספקות טכניים לפני הטמעת המעקב

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

האם העומס על התשתית יגדל?

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

היכן נמצאים הנתונים ומי יש לו גישה אליהם?

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

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

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

נדון במשימה: מה להכין לקראת תחילת העבודה

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

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

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