פיתוח AI א-סינכרוני

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

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

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

דיאגרמת פיתוח קלאסית של רכיב ML

למעשה, תהליך פיתוח של רכיב ML כולל בתוכו לפחות ארבע לולאות פיתוח מתמשכות שמתקדמות במקביל:

1. לולאת "הדאטה ותיוגו" אחראית לאסוף דאטה גולמי חדש, לתייג אותו באופן עקבי, ולהמיר אותו לפורמט אחיד שאלגוריתם האימון יכול לצרוך.
2. לולאת "המודל ואימונו" אחראית על המחקר ופיתוח המודלים, וכן על הפייפליין שלוקח את הדאטה המתוייג שאושר לאימון, עושה לו את ה-preprocessing הנדרש, מאמן מודל, ומייצר בסוף קופסה שיכולה לעשות inference על דאטה שמגיע מסביבה שדומה לפרודקשן.
3. לולאת "הטסט סט ואצירתו" אחראית לשמור דאטה בצד שעליו אפשר למדוד מודלים, באופן שמצד אחד מדמה תנאי והתפלגות פרודקשן, ומצד שני נותן ייצוג סטטיסטי נאה למקרי-קצה.
4. לולאת "הריפורט וחישובו" אחראית על מדידת ביצועי המודל על הטסט-סטים, בחירת המטריקות להשוואה והתקשור שלהן לחוקרים, אנשי הפרודקט והמנהלים. התוצר שלה הוא אלגוריתם evaluation שבהינתן מודל מאומן וטסט-סט מוציא ריפורט.

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

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

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

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

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