תכנון פרויקט למידת מכונה

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

אי ודאות בפרויקט

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

תחרות Kaggle שנערכה לאחרונה ממחישה את חוסר הוודאות בפרויקטים של למידת מכונה. בשבועות הראשונים של התחרות השתתפו 350 צוותים. חלק מהצוותים הצליחו להגדיל את איכות החיזוי בנקודת ההשוואה מ-35% ל-65%. במהלך השבועיים הבאים, מספר הצוותים שעבדו על הבעיה גדל מ-350 ל-1,400. עם זאת, המודל הטוב ביותר השיג איכות חיזוי של 68% בלבד.

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

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

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

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

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

גישה ניסיונית

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

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

תכנון פרויקטים של הנדסת תוכנה

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

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

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

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

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

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

האסטרטגיות הבאות מומלצות לתכנון עבודה עם למידת מכונה:

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

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

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

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

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

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

חשוב לזכור

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

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

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