הנחיות נוספות לצינור עיבוד הנתונים לאימונים

בקטע הזה מפורט צינור האימון.

אופטימיזציה של צינורות עיבוד נתונים

סיכום: הגורמים לצינורות (pipelines) שמוגבלים על ידי קלט וההתערבויות בהם תלויים מאוד במשימה. משתמשים בכלי ליצירת פרופילים ומחפשים בעיות נפוצות.

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

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

אלה סיבות נפוצות לצינורות שמוגבלים על ידי קלט:

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

אנחנו מציעים את הפתרונות הבאים לצינורות שמוגבלים על ידי קלט:

הערכת הביצועים של המודל

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

הגדרות ההערכה

אתם יכולים להשתמש בהגדרות הבאות כדי להעריך את הביצועים של המודלים:

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

הגדרת הערכות תקופתיות

מומלץ להריץ הערכות תקופתיות במהלך ההדרכה מהסיבות הבאות:

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

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

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

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

אם בודקים את הבעיות האלה במרווחי זמן קבועים, קל יותר לזהות אותן.

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

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

בחירת מדגם להערכה תקופתית

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

גודל המדגם

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

מערך הנתונים שבו אתם משתמשים להערכה תקופתית צריך להיות:

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

מערכי נתונים לא מאוזנים

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

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

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

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

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

הגדרת מעקב אחר ניסויים

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

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

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

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

פרטי הטמעה של נירמול באצווה

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

נרמול באצ'ים מנרמל הפעלות באמצעות הממוצע והשונות שלהן באצ' הנוכחי. עם זאת, בהגדרה של כמה מכשירים, הנתונים הסטטיסטיים האלה שונים בכל מכשיר, אלא אם הם מסונכרנים באופן מפורש. דוחות אנקדוטליים (בעיקר ב-ImageNet) מצביעים על כך שחישוב נתוני הנורמליזציה האלה באמצעות כ-64 דוגמאות בלבד עובד טוב יותר בפועל. (ראו את התיאור של Ghost Batch Normalization במאמר Train longer, generalize better: closing the generalization gap in large batch training of neural networks). הפרדה בין גודל האצווה הכולל לבין מספר הדוגמאות שמשמשות לחישוב נתוני הנורמליזציה של האצווה שימושית במיוחד להשוואות בין גדלי אצווה.

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

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

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

סיכום: באימונים, בהערכות, ב-RNG, בנקודות ביקורת ובחלוקת נתונים, אימונים בכמה מארחים יכולים להקל מאוד על הוספת באגים.

לצינורות נתונים עם כמה מארחים, מבצעים את הפעולות הבאות:

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

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