בפוסט הקודם דיברנו על פרוייקט AI כרצף של אירועים שמופקים בצורה א-סינכרונית מכמה לולאות פיתוח: איסוף דאטה ותיוגים, מידול ואימונים, טסט-סטים ייצוגיים, ריפורט ומטריקות. מדי פעם מגיע דאטה חדש להתאמן עליו, ארכיטקטורת מודל אפקטיבית יותר, טסט-סט מייצג יותר, או מטריקות שהולמות יותר את מטרת הפרוייקט. כמנהל פרוייקט חשוב לי קודם כל לוודא שאף אחת מלולאות הפיתוח אינה חסומה ושיש לה אופק התקדמות, ובכל פעם שמתרחש "אירוע" לבחון מחדש את מצב הפרוייקט.
כפי שציינו כמה מהקוראים בתגובה לפוסט הקודם, קשה לעקוב אחרי מצב הפרוייקט כאשר יכולים לשנות לך את הטסט-סט או את המטריקות באמצע, או אפילו כשמשווים בין מודלים שהתאמנו על סט-אימון שונה. השינויים הללו הם שינויים צפויים וטבעיים, במיוחד בסטארט-אפים שבונים את המוצר תוך כדי תנועה. ככל שמבינים טוב יותר את עולם הבעייה, המטריקות מתחדדות והטסט-סטים משתכללים. גם לדאטה יש חשיבות מכרעת – הרבה פעמים תוצאות האלגוריתם הראשוני על הדאטה הראשוני שקיים בפרוייקט מכתיבות את בחירת הדאטה הבא, ודאטה מגיע בקצב שונה ממקורות שונים (שיתופי פעולה, לקוחות).
מה עושים כדי להתנהל בתוך הכאוס הזה? בעיני, המפתח להבנת מצב הפרוייקט הוא הריפורט וכל כלי הניתוח שכלולים בו, ולכן האפיון של הריפורט צריך להיות באחריות מי שמנהל את הפרוייקט. בגדול, הריפורט צריך להציג בצורה ויזואלית וברורה את הביצועים של מודל X על טסט-סט Y, ולאפשר בקלות השוואה בין מודלים שונים על אותו הטסט-סט. "הביצועים" היא מילה כללית לכל המטריקות והגרפים שעוזרים להבין איך המודל יתנהג בפרודקשן (ולא בהכרח רק במובן ה-MLי, אלא גם מבחינת זמן ריצה, צריכת משאבים וכו'). כזכור, גם פיתוח הריפורט הוא אחת מלולאות הפיתוח בפרוייקט, ועם הבנת הבעייה הוא נהיה מדוייק יותר ומאפשר להפיק תובנות בחדות ובמהירות.
בפועל, הריפורט הוא בדרך-כלל משימה שנותנים לחוקר לעשות "על הדרך". בהרבה יותר מדי מקרים כששואלים חוקר או חוקרת מהם ביצועי המודל, הם שולפים מחברת ישנה או פותחים קובץ של גוגל sheets ומתקשים לפענח את הסימנים של עצמם לאיזה מודל ואיזו מטריקה כל שורה שם מתכוונת. כשהריפורט נמצא באחריות החוקרים, הוא כמעט תמיד האלמנט האחרון שנכתב בפיתוח פרוייקט, והמטריקות שמופיעות בו הן תמיד המינימום שנדרש כדי שהחוקרת תוכל להמשיך באיטרציה הבאה בלולאה של פיתוח המודל. בריפורטים כאלו אין מחשבה מעמיקה על משמעותן של המטריקות עבור הפרודקט וחוויית המשתמש (חישבו, למשל, על מטריקת ה-AUC שנהוג לדווח עליה. מה יכול לעשות איתה מנהל המוצר?), ואין כלי ניתוח שמאפשרים בדיקה על תתי-קבוצות באופן שיכול להכווין את איסוף הדאטה. במצב הזה, הריפורט המשמעותי הראשון ש"פוגש את המציאות" מופק אחרי שהמודל והארכיטקטורה כבר עברו כברת דרך, וכך פספסנו זמן רב שבו התוצרים של האלגוריתם היו יכולים למקד את לולאות הפיתוח האחרות.
דמיינו לרגע עולם שבו לולאת הריפורט נמצאת באחריות מנהלת הפרוייקט, ומשתמשים בו למעקב אחרי תוצאות המודלים מ-day one של הפיתוח. במהרה הריפורט הופך להיות כלי התקשורת המרכזי בצוות:
- באמצעותו חוקרים שונים בצוות יכולים לעבוד על מודלים עם ארכיטקטורות שונות לחלוטין ולהשוות בינהן.
- דרכו הפרודקט וההנהלה יכולים לבחון את מצב הפרוייקט באמצעות מטריקות שהם מבינים.
- דרכו מוביל הפרוייקט יכול לתת סיגנל לחוקרים איזה מטריקות כדאי למקסם, ומה המרחק ליעד.
לכן, אם זה הולך להיות כלי התקשורת המרכזי בתוך הצוות ובין הצוות להנהלה, כדאי שהריפורט יראה טוב. ריפורט מוצלח מאפשר לי בקלות לבחור טסט-סט מבין מגווון הטסט-סטים שקיימים במערכת, להשוות עליו באופן מיידי את הביצועים של כל המודלים החשובים, ולהבין מייד מי הכי טוב. הוא גם מאפשר לי לבחור מודל ספציפי ולעשות Gap Analysis – לראות על איזו תת-אוכלוסיה נופלות רוב השגיאות, אפילו עד רמה של מקרים בודדים. ריפורט טוב יכול להיות גם אינטראקטיבי, ולאפשר לי לפלטר את הטסט-סט לפי קריטריונים מסויימים.
כדי שאוכל לסמוך על הממצאים שבריפורט, חשוב שהחישוב של כל המטריקות שמופיעות בו יהיו חלק אינטגרלי מהקוד של הריפורט, ולא יחושבו על ידי החוקרים בזמן ה-inference או האימון. אם המטריקות יחושבו כחלק מהפייפליין של האימון או ה-inference והריפורט רק ילקט אותן משם, לא נוכל לדעת אף פעם שאנחנו משווים "תפוחים לתפוחים", כי יכול להיות ששני חוקרים שונים יממשו חישוב של מטריקה בצורה שונה, או שסתם הקוד של חישוב המטריקה ישתנה בין גרסה ישנה של האימון לגרסה הנוכחית.
הריפורט חייב להיות גמיש ומהיר לחישוב. אם אני רוצה להוסיף מטריקה חדשה אני צריך להיות מסוגל להוסיף אותה פעם אחת לקוד של הריפורט, ובאופן כמעט מיידי להפיק ריפורט חדש שמשווה בין כל המודלים שמעניינים אותי באותו רגע. בניגוד לקלטים והפלטים הקפואים בזמן של הג'ובים הכבדים הניסויים שרצים בענן (ומנוהלים עם פלטפורמת ה-MLOps), הריפורט צריך להיות קליל ומחושב בכל פעם בחדש לפי הקוד האחרון שנמצא בגיט. זה אומר שיש הפרדה בין הקוד הכבד שעושה inference (שמרים מודל pytorch לאוויר ומריץ אותו על הטסט-סט) לקוד של הריפורט (שרק מחשב גרפים ומטריקות), וזה גם אומר שתוצאות ה-inference צריכות להישמר כארטיפקט.
מעקב-ניסויים זה לא מספיק
העניינים ה"פעוטים" הללו הן הבעיות הכי גדולות שיש לי עם שימוש בכלי ה-MLOps הנוכחיים כדי להבין את מצב הפרוייקט. הכלים הללו בדרך כלל מתרכזים במעקב אחרי "ניסויים". הם לא מפרקים את הפרוייקט למודלים, או לטסט-סטים, אלא מסתכלים עליו כאוסף של ג'ובים שרצו בענן. ה"ריפורט" נגזר מאיזה שהוא פילטר על הג'ובים (למשל כל הג'ובים מסוג inference שרצו על טסט סט Y).
מדובר בכלים חשובים ואפילו נחוצים עבור traceability ו-reproducibility, אבל הריפורט שהם מפיקים זו רק אגרגציה של מטריקות או גרפים שנאספו מג'ובים. מעבר לזה שמבחינה ויזואלית זה נראה רע ואין כמעט חופש עיצובי, הם לא יכולים להבטיח לי שהקוד שמחשב את המטריקה הוא זהה בין שני ג'ובים שונים. בנוסף הכלים הללו לא מאפשרים גמישות בשינוי של המטריקות או הוספה של מטריקות חדשות למודלים ישנים – כל שינוי כזה דורש הרצת כל הג'ובים של ה-inference מחדש. ואחרי כל זה צריך עוד לעבוד כדי לסנן החוצה את כל הג'ובים הישנים ולבחור רק את הג'ובים הנכונים להשוואה. קשה.
מדורת השבט
דיברנו על הכאוס בניהול פרוייקט AI ואיך מנהלים אותו. אני מרגיש שעד כה, הדגש בניהול הפרוייקט הושם בצד של החוקרים שמפתחים את המודל (model-centric AI) או שמכינים את הדאטה (data-centric AI). הגישות הללו חוטאות למציאות הא-סינכרונית שבה פרוייקט AI טיפוסי מתנהל. במציאות הזו נכון יותר שמרכז הפרוייקט יהיה הריפורט.
היכולת לבחור את הטסט-סט ולהיות מסוגל לבחון את ביצועי המודלים קדימה ואחורה בזמן (כלומר גם על טסט-סטים ומטריקות שלא היו קיימים בזמן שהמודל אומן) קריטית כדי להבין לאן הפרוייקט התקדם ולפרש מחדש תוצאות ישנות בראי של סביבת פרודקשן חדשה. הריפורט הופך להיות "מדורת השבט" שמסנכרנת בין כל לולאות הפיתוח השונות. שם מתבצע השיח אחרי פרסום תוצאות של מודל חדש או טסט-סט חדש, שם אפשר להבין מהם המודלים המובילים ואיפה נקודות החולשה. התובנות שמפיקים ממנו עוזרות לקבל החלטות, כמו כמה ואיזה דאטה צריך לאסוף, איפה צריך לשים את ה-threshold, ואיזה מודלים צריכים להשתתף באנסמבל.
אם כבר, אנחנו צריכים לעבור ל-report-centric AI, ולפתח כלי ML-Ops לגישה הזו.
ברצוני להודות לענבל בודובסקי-טל ולרן שדמי על עזרתם בכתיבת הפוסט.
lifesimulator 
כתוב ממש בהיר ולעניין. שאלה – אני מכיר שהיום פלטפורמות MLOPS כן נותנות מענה לדברים כמו לראות מטריקות על פני כלל המודלים.. או להסתכל על מודל כמודל עם הדאטה בזמן האימון שלו וכו'.. בטח כשהאירוע מחובר ל-feature store מה שמתאפשר בהרבה פלטפורמות היום. ולכן שואל – מה הפער בפרקטיקה שזיהיתם?
אני לא חושב שיש היום חיבור טוב בין פלטפורמות lineage ו-dq (כמו למשל montecarlo) לבין פלטפורמות ה-mlops. כלומר אין alert שמתריע לחוקר ds או ל-mle שמשהו השתנה כשעוד לא ברור שזה השפיע על פיצ'ר כלשהו ברמת המהות.. ואולי בכלל זה over kill ולא צריך כזה ומספיק לנטר על הפיצ'ר עצמו ועל תוצאות המודל..