הגדרת ClearML למעקב אחר ניסויים ו-MLOps

הגדרת ClearML: היכן נשבר מעקב אחר ניסויים

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

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

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

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

מה נותן מעקב מנוהל: אפקטים מדידים

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

שחזור ניסויים

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

ניהול גרסאות נתונים ומאגר ארטיפקטים אחיד

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

השוואת הרצות של מודלים

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

השוואת מודלי פריסה: הגדרת ClearML בהתאם למשימה

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

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

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

שלבי ההטמעה: מהביקורת ועד מסירה לצוות

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

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

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

מה נותר במאגר לאחר ההטמעה

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

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

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

מקרה בוחן: כיצד הצוות הפסיק לאבד תוצאות ניסויים

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

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

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

מה שינו ומה יצא

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

שיעור ההרצות הניתנות לשחזור עלה משליש ללמעלה מ-90%: התצורה והנתונים משוחזרים מההיסטוריה בקליק אחד. זמן החיפוש אחר התוצאה התקצר מ-40–60 דקות ל-2–3 דקות. נפח האחסון הפסיק לגדול באופן לינארי — רישום הארטיפקטים הצטמצם פי שלושה, ובמקביל נסיגה לגרסאות קודמות של המודלים נותרה זמינה.

במה נבדל מעקב מנוהל מטבלאות עם תוצאות?

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

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

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

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

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

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

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

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

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