תכנון פרויקטים של למידת מכונה שונה מתכנון פרויקטים רגילים של הנדסת תוכנה. פרויקטים של למידת מכונה הם בדרך כלל לא לינאריים ויש להם רמות שונות של אי-ודאות. הם דורשים גישה איטרטיבית וחשיבה ניסיונית.
אי-ודאות בפרויקט
תכנון בשלבים מוקדמים יכול להיות קשה כי בדרך כלל לא ברור מהי הגישה הטובה ביותר כשמתחילים פרויקט. אי הוודאות המובנית הזו מקשה על הערכת לוחות זמנים.
תחרות Kaggle שנערכה לאחרונה מדגימה את אי-הוודאות בפרויקטים של למידת מכונה. בשבועות הראשונים של התחרות השתתפו 350 צוותים. הצוותים המובילים הצליחו לשפר את איכות התחזית של מדד ההשוואה מ-35% ל-65%. במהלך השבועיים הבאים, מספר הצוותים שעבדו על הבעיה גדל מ-350 ל-1,400. עם זאת, איכות החיזוי של המודל הטוב ביותר הייתה רק 68%.
באיור 3 מוצגת אי-הוודאות בפיתוח למידת מכונה, דרך העלייה המשמעותית במאמץ, אבל השיפורים המינימליים באיכות המודל.
איור 3. במהלך שבועיים, מספר הצוותים שעבדו על הבעיה הוכפל פי 4, אבל איכות המודל נשארה כמעט זהה, מה שממחיש את הקושי להעריך את המאמץ הנדרש לפתרון באמצעות למידת מכונה.
במילים אחרות, יותר מאלף צוותים – שכל אחד מהם התנסה במגוון של טרנספורמציות נתונים, ארכיטקטורות והיפארמטרים – הצליחו ליצור רק מודל עם איכות חיזוי של 68%.
דוגמה מהתעשייה ממחישה את אי-הלינאריות של פרויקטים של למידת מכונה, שבהם הפלט לא יחסי לקלטים. שני צוותים הקדישו כמה חודשים לאימון מודל באיכות חיזוי של 90%. עם זאת, נדרשו לכמה צוותים יותר מחמש שנים כדי להכין את המודל להפעלה בסביבת הייצור עם איכות תחזית של 99.9%.
הדוגמאות האלה מדגישות שלמידת מכונה מוכנה לייצור היא תהליך של חקירה, שמחייב חשיבה מדעית וחשיבה מהנדסית.
גישה ניסיונית
ברוב המקרים, פיתוח למידת מכונה דומה יותר לביצוע ניסויים מאשר לעבודה של מהנדסי תוכנה מסורתיים. למידת מכונה מחייבת בדיקה של תכונות שונות, ניסיון בכמה ארכיטקטורות ושינוי של ההיפר-פרמטרים בצורה מדויקת. מעצם הגדרתם, לא בטוח שהניסויים יצליחו. לכן, מומלץ לתכנן את הניסוי באמצעות מסגרת ניסיונית.
נבחן תוכנית אופיינית של מהנדסי תוכנה כדי לראות איך היא שונה מתוכנית של פרויקט למידת מכונה.
תכנון פרויקטים של הנדסת תוכנה
בתוכנית רגילה של מהנדסי תוכנה, מגדירים את הדרישות, מתארים את הרכיבים, מעריכים את המאמץ ומתזמנים את העבודה. יש דרך ברורה לפתרון. לדוגמה, מהנדסים בדרך כלל יודעים בוודאות גבוהה אילו משימות הם צריכים להשלים כדי ליצור אפליקציה שעומדת בדרישות המפרט של העיצוב.
כשהם מנסים לחזות את משך הזמן שיידרש כדי להשלים משימה, הם יכולים להעריך את משך העבודה על סמך פרויקטים דומים. תמיד יש אתגרים – כמו יחסי תלות לא ידועים או דרישות משתנות – שיכולים לגרום לקשיים בשקלול, אבל בדרך כלל יש דרך ברורה לפתרון.
לעומת זאת, בפרויקטים של למידת מכונה בדרך כלל אין דרך ברורה אחת להצלחה.
תכנון פרויקטים של למידת מכונה
ברוב הפרויקטים של למידת מכונה, הפתרון הטוב ביותר מתקבל באמצעות ניסוי עם כמה גישות בתהליך של ניסוי וטעייה. בדרך כלל לא תדעו מהו הפתרון האופטימלי לבעיה לפני שתנסו לפתור אותה. לדוגמה, הארכיטקטורה של הפתרון האופטימלי עשויה להיות מודל לינארי פשוט, רשת עצבית או עץ החלטות. רק על ידי ניסיון כל גישה תוכלו לגלות את הפתרון הטוב ביותר.
אי-הבהירות הזו מקשה על התכנון. כפי שציינתי קודם, קשה לחזות את המאמץ הנדרש לפרויקט למידת מכונה. רק אחרי שתנסו לפתור את הבעיה תוכלו להבין טוב יותר את משך הזמן והמשאבים הנדרשים לפתרון.
אלה השיטות המומלצות לתכנון עבודה ב-ML:
הקצאת זמן לעבודה. כדאי להגדיר מסגרות זמן ברורות להשלמת משימות או לניסיון פתרון מסוים. לדוגמה, תוכלו להקצות שבועיים כדי לקבוע אם יש לכם גישה לנתונים המתאימים. אם ניתן לקבל את הנתונים, כדאי להקצות עוד שבועיים כדי לבדוק אם מודל פשוט מציין שפתרון של למידת מכונה אפשרי. אם מודל פשוט נכשל, תוכלו להקצות עוד שבועיים לניסיון עם רשת עצבית. בסוף כל מסגרת זמן, תהיה לכם יותר מידע כדי לקבוע אם כדאי להמשיך להשקיע משאבים בפתרון הבעיה.
הצגת דרישות הפרויקט ברמת פירוט נמוכה יותר אם פתרון למידת מכונה נראה מבטיח אבל הוא לא תכונה קריטית למוצר או לשירות שלכם, תוכלו לצמצם את הדרישות שלו. לדוגמה, כשמתכננים את העבודה ברבעון הבא, אפשר לנסות פתרון פשוט מאוד. לאחר מכן, ברבעונים הבאים תוכלו לשפר את הפתרון באופן שיטתי. צוותים רבים הגיעו לפתרונות ML יעילים על ידי הטמעת פתרון ML תוך ביצוע שיפורים מצטברים לאורך תקופת זמן ארוכה יותר.
פרויקט של סטודנטים או של עובדים חדשים. הדרכה של סטודנטים או עובדים חדשים לנסות פתרון של למידת מכונה יכולה להיות דרך טובה להתחיל לבדוק תחום חדש עם תוצאות לא ידועות. בסיום הפרויקט תוכלו להבין טוב יותר את המאמץ הנדרש לפתרון ב-ML ואת הגישות שעשויות להניב תוצאות טובות, או להבין אם כדאי להשקיע את המשאבים במקום אחר.
בכל אסטרטגיה, מומלץ להיכשל מהר. נסו קודם את הגישות עם העלויות הנמוכות ביותר, אבל עם פוטנציאל התמורה הגבוה ביותר. אם הגישה עובדת, סימן שמצאתם פתרון טוב. אם לא, לא תבזבזו הרבה זמן ומשאבים.
ככל שהצוותים יצברו ניסיון וחשיפה להרצת ניסויים, הם יוכלו להעריך טוב יותר את המאמץ הנדרש לניסוי, וכך לתכנן בצורה יעילה יותר. עם זאת, התוצאה של ניסוי תהיה כמעט תמיד לא ידועה, ולכן אי אפשר להעריך מראש את מספר הניסויים הנדרשים כדי למצוא את הפתרון הטוב ביותר.
תכנון גישה עם גישה ניסיונית עוזר לצוות להצליח. כשגישה מסוימת מובילה למבוי סתום, חברי הצוות לא מתייאש, אלא מבינים שזה חלק מהתהליך של מציאת פתרון ב-ML. חשוב מכך, כשמדברים עם בעלי עניין על אי-הוודאות הטבועה בפיתוח למידת מכונה, אפשר להגדיר ציפיות ריאליסטיות יותר.
בדיקת ההבנה
חשוב לזכור
כדי ללמוד לתכנן מספר גישות של למידת מכונה באופן מבוסס-הסתברות, נדרשים זמן וניסיון. יכול להיות שתצטרכו לעדכן את תוכנית הפרויקט לעיתים קרובות. אפשר לחשוב עליו כמסמך דינמי שנמצא בהתפתחות מתמדת, ככל שהצוות שלכם ינסו כמה גישות. כדי להגדיל את הסיכויים להצלחה, כדאי להתמקד ברעיונות המרכזיים הבאים:
- להעריך את העלות ואת הסיכוי להצלחה של כל גישה.
- נסו להשתמש במגוון גישות.
- זיהוי הלקחים שנלמדו וניסיון לשפר את המערכת, דבר אחר דבר.
- תכנון למקרה של כשלים.
לפעמים גישה מוקדמת מובילה לפריצת דרך. יכול להיות שמישהו יגלה באג בצינור עיבוד הנתונים ליצירת נתונים או בחלוקה של אימון ותיקוף. תכנון טוב ותיעוד מקיף יגדילו את הסיכוי שתמצאו מודל שפותר את הבעיה העסקית שלכם מהר יותר מהצפוי.