הניסויים עוזרים להצלחת הפרויקט. הן השערות שניתנות לבדיקה וניתנות לשחזור. המטרה היא לבצע שיפורים מתמשכים לאורך הזמן, על ידי הערכה של מגוון ארכיטקטורות ותכונות של מודלים. כשאתם עורכים ניסויים, מומלץ לבצע את הפעולות הבאות:
קובעים את רמת הביצועים הבסיסית. קודם כל צריך ליצור מדד בסיסי. רמת הבסיס משמשת ככלי מדידה שאליו אפשר להשוות את הניסויים.
במקרים מסוימים, הפתרון הנוכחי שאינו ML יכול לספק את מדד הבסיס הראשון. אם לא קיים פתרון כרגע, יוצרים מודל למידת מכונה עם ארכיטקטורה פשוטה וכמה תכונות ומשתמשים במדדים שלו כבסיס.
עושים שינויים בודדים, קטנים. בצעו רק שינוי אחד קטן בכל פעם, לדוגמה, בהיפר-פרמטרים, בארכיטקטורה או בתכונות. אם השינוי משפר את המודל, המדדים שלו הופכים לבסיס החדש שאליו ניתן להשוות ניסויים עתידיים.
הנה דוגמאות לניסויים שמבצעים שינוי קטן אחד:
- כוללים את התכונה X.
- משתמש בשחרור 0.5 בשכבה המוסתרת הראשונה.
- לוקחים את הטרנספורמציה של היומן של התכונה Y.
- משנים את קצב הלמידה ל-0.001.
מתעדים את התקדמות הניסויים. סביר להניח שתצטרכו לעשות הרבה ניסויים. עדיין ניתן לעקוב אחר ניסויים עם איכות חיזוי נמוכה (או ניטרלית) בהשוואה לערך הבסיס. הם מסמנים אילו גישות לא יעבדו. מכיוון שההתקדמות בדרך כלל לא לינארית, חשוב להראות שאתם עובדים על הבעיה ומדגישים את כל הדרכים שלא עובדות, בנוסף להתקדמות שלכם בשיפור האיכות הבסיסית.
מכיוון שכל אימון מלא על מערך נתונים מהעולם האמיתי יכול להימשך שעות (או ימים), מומלץ להריץ מספר ניסויים עצמאיים בו-זמנית כדי לחקור את המרחב במהירות. ככל שתמשיכו באיטרציה, תתקרבו לרמת האיכות שתזדקקו להם לייצור.
רעש בתוצאות הניסוי
שימו לב שבתוצאות הניסוי יכול להיות שתבחינו ברעשים, שהם לא שינויים שבוצעו במודל או בנתונים, ולכן יהיה קשה לקבוע אם שינוי שביצעתם אכן שיפר את המודל. הדוגמאות הבאות הן דוגמאות לדברים שיכולים ליצור רעש בתוצאות ניסוי:
ערבול נתונים: הסדר שבו הנתונים מוצגים למודל יכול להשפיע על ביצועי המודל.
אתחול משתנה: גם האופן שבו המשתנים של המודל מאתחלים יכול להשפיע על הביצועים שלו.
מקביליות אסינכרונית: אם המודל אומן באמצעות מקביליות אסינכרונית, גם הסדר שבו מעודכנים החלקים השונים של המודל יכול להשפיע על הביצועים שלו.
קבוצות הערכה קטנות: אם קבוצת ההערכה קטנה מדי, יכול להיות שהיא לא מייצגת את הביצועים הכוללים של המודל, ולכן יש הבדלים לא זהים באיכות המודל.
הפעלת ניסוי מספר פעמים עוזרת לאשר את תוצאות הניסוי.
מגיעים להסכמה לגבי שיטות הניסוי
הצוות שלכם צריך להיות מבין בבירור מהו "ניסוי", באמצעות סדרה מוגדרת של שיטות עבודה וארטיפקטים. צריך תיעוד שכולל את הפרטים הבאים:
ממצאים. מהם פריטי המידע שנוצרו בתהליך הפיתוח (Artifact) לניסוי? ברוב המקרים, ניסוי הוא השערה שנבדקה שאפשר לשחזר, בדרך כלל על ידי רישום המטא-נתונים (כמו התכונות וההיפר-פרמטרים) שמציינים את השינויים בין הניסויים והאופן שבו הם משפיעים על איכות המודל.
שיטות תכנות. האם כולם ישתמשו בסביבות הניסיוניות שלהם? עד כמה ניתן (או קל) לאחד את העבודה של כולם לספריות משותפות?
שחזור ומעקב. מהם הסטנדרטים לשחזור? לדוגמה, האם כדאי לצוות להשתמש באותה צינור נתונים ובאותן שיטות של ניהול גרסאות, או שמותר להציג רק תרשימים? איך יישמרו נתונים לניסוי: כשאילתות SQL או כקובצי snapshot של המודלים? איפה יתועדו היומנים מכל ניסוי: במסמך, בגיליון אלקטרוני או במערכת ניהול תוכן לניהול ניסויים?
חיזויים שגויים
אף מודל מהעולם האמיתי לא מושלם. איך המערכת תטפל בחיזויים שגויים? כדאי להתחיל לחשוב בשלב מוקדם איך להתמודד איתם.
אסטרטגיית שיטות עבודה מומלצות מעודדת את המשתמשים לתייג חיזויים שגויים. לדוגמה, אפליקציות אימייל מתעדות אימייל שלא סווג כראוי על ידי רישום הודעות הדואר שהמשתמשים מעבירים לתיקיית הספאם, ולהיפך. באמצעות איסוף תוויות מהימנות ממשתמשים, אפשר לתכנן לולאות משוב אוטומטיות לאיסוף נתונים ולאימון מחדש של המודל.
שימו לב: על אף שסקרים מוטמעים בממשק המשתמש מתעדים משוב מהמשתמשים, בדרך כלל הנתונים הם איכותיים ואי אפשר לשלב אותם בנתונים של האימון מחדש.
הטמעת פתרון מקצה לקצה
בזמן שהצוות שלכם בודק את המודל, כדאי להתחיל לבנות חלקים מצינור עיבוד הנתונים הסופי (אם יש לכם את המשאבים לכך).
על ידי יצירת חלקים שונים בצינור עיבוד הנתונים, כמו קליטת נתונים ואימון מחדש של המודל, קל יותר להעביר את המודל הסופי לייצור. לדוגמה, קבלת צינור עיבוד נתונים מקצה לקצה להטמעת נתונים ולתחזיות לגבי הצגת מודעות יכולה לעזור לצוות להתחיל לשלב את המודל במוצר ולהתחיל לבצע בדיקות משתמשים בשלבים מוקדמים.
פתרון בעיות בפרויקטים שנתקעו
יכול להיות שתיתקלו בתרחישים שבהם ההתקדמות של פרויקט מושהית. אולי הצוות שלכם עבד על ניסוי מבטיח, אבל לא הצליח לשפר את המודל במשך שבועות. מה עליך לעשות? אלו הן כמה גישות אפשריות:
אסטרטגיה. יכול להיות שתצטרכו לשנות את גבולות הפריים של הבעיה. אחרי שתקדישו זמן בשלב הניסוי, סביר להניח שתבינו טוב יותר את הבעיה, את הנתונים ואת הפתרונות האפשריים. אם יש לכם ידע מעמיק יותר בתחום, סביר להניח שתוכלו להציג את הבעיה בצורה מדויקת יותר.
לדוגמה, אולי רצית בהתחלה להשתמש ברגרסיה לינארית כדי לחזות ערך מספרי. לצערנו, הנתונים לא היו מספיק טובים כדי לאמן מודל של רגרסיה ליניארית בת קיימא. אולי ניתוח נוסף חושף את הבעיה ואיך אפשר לפתור אותה על ידי חיזוי אם דוגמה נמצאת מעל או מתחת לערך מסוים. כך אפשר להגדיר מחדש את הבעיה כסיווג בינארי.
אם ההתקדמות איטית מהצפוי, אל תוותר. שיפורים מצטברים לאורך זמן עשויים להיות הדרך היחידה לפתור את הבעיה. כפי שצוין קודם לכן, אל תצפו באותה כמות של התקדמות בהשוואה לשבוע שעבר. לעיתים קרובות, כדי להגיע לגרסה מוכנה לייצור של מודל, נדרש זמן רב. שיפור המודל עשוי להיות לא סדיר ובלתי צפוי. אחרי תקופות של התקדמות איטית יכולות להיות עליות חדות מבחינת השיפור, או להפך.
טכני. הקדישו זמן לניתוח ולניתוח של תחזיות שגויות. במקרים מסוימים, אפשר למצוא את הבעיה על ידי בידוד של כמה חיזויים שגויים ואבחון התנהגות המודל במקרים האלה. לדוגמה, יכול להיות שתגלו בעיות בארכיטקטורה או בנתונים. במקרים אחרים, כדאי לקבל יותר נתונים. יכול להיות שתקבלו אות ברור יותר שיעיד על כך שאתם בדרך הנכונה, או שהוא יפיק רעש נוסף, מה שמצביע על בעיות אחרות בגישה.
אם אתם עובדים על בעיה שמחייבת מערכי נתונים בתווית אנושית, יכול להיות שיהיה קשה להשיג מערך נתונים עם תווית להערכת המודל. מקורות מידע כדי לקבל את מערכי הנתונים שדרושים להערכה.
יכול להיות שאין פתרון אפשרי. הגדירו תיבת זמן לגישה, כך שתפסיקו לעשות את זה אם לא התקדמתם בפרק הזמן הזה. עם זאת, אם אתם מציינים בעיה חמורה, סביר להניח שהיא מצדיקה פתרון.