הקטע הזה מפרט את צינור עיבוד הנתונים להכשרה.
אופטימיזציה של צינור עיבוד הנתונים
סיכום: הסיבות וההתערבויות של צינורות עיבוד קלט קלט תלויות מאוד במשימות. יש להשתמש ביוצר פרופילים ולחפש בעיות נפוצות.
כדי לאבחן צינורות הקשורים לקלט:
- Perfetto ל-JAX
- TensorFlow profiler ל-TensorFlow.
בסופו של דבר, הגורמים וההתערבויות הספציפיים תלויים במידה רבה במשימות. שיקולי הנדסה רחבים יותר (למשל, צמצום טביעת הרגל של הדיסק) עלולים לפגוע בביצועים של צינור עיבוד הנתונים.
הנה כמה סיבות נפוצות לצינורות עיבוד נתונים הקשורים לקלט:
- אין חפיפה בין הנתונים בתהליך האימון, מה שגורם לזמן אחזור של קלט/פלט. לדוגמה, קריאת נתוני אימונים ברשת יכולה לגרום לזמן אחזור ב-I/O.
- עיבוד יקר של נתונים אונליין. כדאי לבצע עיבוד מראש ברגע שאין חיבור לאינטרנט, ולשמור את התוצאות.
- מחסומים לא רצויים בסנכרון שמפריעות לשליפה מראש של צינור עיבוד הנתונים. לדוגמה, כשמסנכרנים מדדים בין המכשיר והמארח ב-CommonLoopUtils.
אנחנו מציעים את ההתערבויות הבאות לצינורות עיבוד נתונים המחוברים לקלט:
- צינור קלט של מכשיר לשליפה מראש של דוגמאות (לדוגמה, tf.data.Dataset.prefetch).
- להסיר מ-Google את הפיצ'רים והמטא-נתונים שאינם בשימוש בהקדם האפשרי.
- הגדלת מספר המשרות שמייצרות דוגמאות לצינור עיבוד הנתונים, למשל באמצעות שירות tf.data.
הערכת ביצועי המודל
סיכום: הרצת הערכה בגדלים גדולים יותר מהאימון. מריצים הערכות במרווחי זמן קבועים, ולא במרווחי זמן קבועים.
הגדרות ההערכה
תוכלו להשתמש בהגדרות הבאות כדי להעריך את ביצועי המודלים שלכם:
- הערכה אונליין: איסוף המדדים כאשר המודל מספק חיזויים בסביבת ייצור. בדרך כלל ההערכה אונליין מספקת את ההערכה המציאותית ביותר של איכות המודל, כי היא תואמת לאופן השימוש במודל.
- הערכה אופליין: איסוף המדדים כשהמודל פועל בהדרכות, בשיטות אימות או בקבוצות של בדיקות אופליין שמייצגות את סביבת הייצור. בהתאם לבעיה, ההערכה אופליין יכולה להיות מעורבת בצורה יקרה, והאם החישוב שלה יקר.
- הערכה תקופתית: תוכלו לאסוף מדדים במהלך אימון המודל, שיכולים להיות שרת proxy להערכה אופליין ו/או קבוצת משנה של הנתונים המשמשים להערכה אופליין. הערכות תקופתיות הן האפשרות המעשית והכלכלית ביותר, אבל לא מייצגות את סביבת הייצור. המטרה היא להשתמש בשרת proxy יעיל של ההערכה אופליין, בלי לוותר על אות האות במהלך האימון.
הגדרה של הערכות תקופתיות
אנחנו ממליצים לבצע הערכות תקופתיות במהלך האימון מהסיבות הבאות:
- כדי לעקוב אחר ההתקדמות של האימון בזמן אמת.
- כדי לסייע בבחירה רטרוספקטיבית של נקודת הביקורת של המודל.
- כדי לבדוק את עקומות האימון בסוף האימון.
ההגדרות הפשוטות ביותר הן לבצע גם הדרכות וגם הערכות תקופתיות בתוך אותו מכונה ממוחשבת, ולפעמים לבצע לסירוגין בין האימון לבין ההערכה. במקרה כזה, הגודל של האצווה שישמש לביצוע הערכות צריך להיות גדול לפחות מהגודל של המקבץ שמשמש לאימון. הסיבה היא שאתם לא צריכים להפעיל הפעלות של מודלים במהלך ההערכה, מה שמונע את דרישות החישוב לדוגמה.
מבצעים הערכות תקופתיות במרווחי זמן קבועים, ולא במרווחי זמן. כשמבצעים הערכות לפי מרווחי זמן, קשה יותר לפרש את עקומות האימון, במיוחד כשניתן לחוות אימונים אלה לפני הזמן של הדרכות האימון, בעיות בזמן האחזור של הרשת וכו'.
שימוש תקופתי במדדי אימות ומדדי בדיקה (בשימוש בקבוצת אימון אקראית, בקבוצת אימות ובקבוצת ניסוי) יכול להצביע על באגים בהטמעה, כמו:
- נתוני הבדיקה חופפים לנתוני האימון.
- נתוני ההשמעה לא אקראים כראוי.
הערכה במרווחי זמן קבועים יכולה לעזור לכם לזהות את הבעיות בקלות.
מקבצים חלקיים יכולים להתרחש כשקבוצות ההערכה לא מתחלקות לפי גודל האצווה. מוודאים שהדוגמאות המרופדות משוקללות בצורה נכונה (כמו הממוצע המשוקלל, לפי הדוגמאות שמחושבות את הירידה הממוצעת באצווה), כדי למנוע הטיה של אותן פונקציות. לעיתים קרובות ניתן לתת משקל אפס של הדוגמאות המרופדות האלה.
שומרים מספיק מידע לכל הערכה כדי לתמוך בניתוח אופליין. באופן אידיאלי, כדאי לשמור חיזויים על מבחר דוגמאות ספציפיות, כי הן יכולות להועיל מאוד לניפוי באגים. יצירת חפצים כמו SavedModels מפשטת את הבדיקה של מודל אד-הוק אחרי שמשימות ההערכה מסתיימות.
בחירת דגימה לבדיקה תקופתית
יכול להיות שמשימת ההערכה התקופתית לא תפעל מהר מספיק כדי לחשב את המדדים בהערכה המלאה אופליין שהוגדרה בפרק זמן סביר. בעיה זו מחייבת לעיתים קרובות דגימת נתונים לצורך הערכה תקופתית. כשאתם בונים מערך נתונים לדוגמה, מומלץ לקחת בחשבון את הבעיות בגודל הדגימה ובבעיות מיוחדות במערכי נתונים לא מאוזנים.
גודל הדגימה
בדקו שהביצועים שמחושבים במערך הנתונים שנדגום ושנעשה בהם שימוש במשימה המחזורית תואמים לביצועים בכל קבוצת ההערכה אופליין. כלומר, ודאו שאין הטיה בין מערך הנתונים שנדגם לבין מערך הנתונים המלא.
מערך הנתונים שבו משתמשים להערכה תקופתית צריך להיות:
- קטן מספיק כדי ליצור בקלות חיזויים למודלים במלואם.
- גדול מספיק כדי לבצע את שתי הפעולות הבאות:
- יש למדוד את השיפורים באופן מדויק, כלומר לא כדאי להעמיס על המדידות את רעשי התוויות.
- לערוך כמה הערכות כאלה בתקופות ניסיון ברצף, ועדיין לייצר הערכות מדויקות. כלומר, מספיק גדולה כדי להימנע מ"התאמה" לאימות שהוגדר לאורך זמן באופן שלא יוצר החרגה כללית לקבוצת בדיקות מעוכבת. עם זאת, ההחלטה הזו היא תכלית לעתים רחוקות.
מערכי נתונים ללא איזון
במערכי נתונים לא מאוזנים, הביצועים של סיווגי מיעוטים נדירים הם בדרך כלל רועשים. במערכי נתונים שבהם מופיעות רק כמה דוגמאות קטנות, צריך לתעד את מספר הדוגמאות החזויות כדי לקבל תובנות נוספות לגבי שיפורי הדיוק. לדוגמה, שיפור הרגישות של .05 נשמע אולי מגניב, אבל האם השיפור היה רק כי עוד דוגמה אחת נכונה?
שמירה של נקודות ביקורת ובחירה רטרואקטיבית של נקודת הביקורת
סיכום: הריצו את האימון עבור מספר קבוע של שלבים ובחרו רטרואקטיבית בנקודת הביקורת הטובה ביותר.
רוב המסגרות של למידה עמוקה תומכות בתצפית לפי מודל. כלומר, המצב הנוכחי של המודל נשמר מדי פעם בדיסק. נקודות הביקורת מאפשרות לשמור על עמידות במשימת האימון כדי לחשב הפרעות במכונות. נקודת הביקורת הטובה ביותר היא לא תמיד נקודת הביקורת האחרונה, במיוחד כשהביצועים של קבוצת האימות לא הולכים וגדלים לאורך זמן – אלא משתנים בערך מסוים.
להגדיר את צינור עיבוד הנתונים כדי לעקוב אחרי N נקודות הרייטינג הטובות ביותר שהוצגו עד כה במהלך האימון. בסיום האימון, בחירת המודל פירושה פשוט לבחור את נקודת הביקורת הטובה ביותר. אנחנו מכנים את הגישה הזו בחירה רטרוספקטיבית של נקודת ביקורת. בדרך כלל אין צורך בעצירה מוקדמת אפשרית, כי אתם מציינים מראש תקציב לתקופת ניסיון ושומרים את N נקודות הביקורת הטובות ביותר שהוצגו עד כה.
הגדרת מעקב אחר ניסויים
סיכום: כשעוקבים אחרי ניסויים שונים, צריך לעקוב אחרי כמה מדדים חיוניים, כמו הביצועים הטובים ביותר של נקודת ביקורת במחקר, ותיאור קצר של המחקר.
מומלץ לעקוב אחר תוצאות הניסוי בגיליון אלקטרוני. הגיליונות האלקטרוניים שלנו בדרך כלל מכילים את העמודות הבאות:
- שם המחקר
- קישור למקום שבו נשמרת ההגדרה של המחקר.
- הערות או תיאור קצר של המחקר.
- מספר תקופות הניסיון
- הביצועים של קבוצת האימות של נקודת הביקורת הטובה ביותר במחקר.
- פקודות ספציפיות של רפליקות או הערות לגבי השינויים שלא הוגשו הכרחיים להשקת האימון.
מצאו מערכת מעקב נוחה לתיעוד של לפחות המידע שמפורט למעלה. ייתכן גם שלא יהיו ניסויים במעקב.
פרטי ההטמעה של נורמליזציה בכמות גדולה
סיכום: נכון לעכשיו, לעיתים קרובות אפשר להחליף את נרמול האצווה ב-LayerNorm, אבל במקרים שבהם אי אפשר לבצע את ההחלפה הזו, יש פרטים מורכבים כשמשנים את גודל האצווה או את מספר המארחים.
נורמליזציה של אצווה מנרמלת את ההפעלות באמצעות הממוצע וההבדלים שלהן באצווה הנוכחית. עם זאת, בהגדרה של מכשירים מרובים, הנתונים הסטטיסטיים האלה שונים בכל מכשיר, אלא אם הם מסונכרנים באופן מפורש. דוחות אנקדוטיים (בדרך כלל ב-ImageNet) מצביעים על כך שחישוב הנתונים הסטטיסטיים המנורמלים באמצעות כ-64 דוגמאות בלבד אכן עובד טוב יותר בפועל. (ראו את התיאור של נורמליזציה של רוחות רפאים באימון ארוך יותר, ליצור הכללה טובה יותר: סגירת פער האילוץ באימון גדול של רשתות נוירונים). ההתאמה בין גודל האצווה לבין מספר הדוגמאות המשמשות לחישוב הנתונים הסטטיסטיים של נורמות האצווה שימושית במיוחד לצורך השוואות של גודל האצווה.
הטמעות נורמליזציה של רוחות רפאים לא תמיד מטפלות כראוי במקרה שבו גודל האצווה בכל מכשיר גדול מהגודל הווירטואלי. במקרה כזה, צריך לבצע דגימה משנה של כל אצווה בכל מכשיר כדי לקבל את המספר הנכון של דוגמאות של נתונים סטטיסטיים על נורמות.
ממוצעים נעים מעריכיים (EMA) המשמשים לנורמליזציה של אצווה במצב בדיקה הם רק שילוב לינארי של נתונים סטטיסטיים של אימונים. לכן צריך לסנכרן רק את ה-EMA האלה לפני שמירתם בנקודות ביקורת. עם זאת, יש כמה הטמעות נפוצות של נורמליזציה של אצווה שלא מסתנכרנות עם ה-EMA האלה ושומרות את ה-EMA רק מהמכשיר הראשון.
שיקולים לצינורות עיבוד נתונים של מספר מארחים
סיכום: רישום ביומן, קללות, RNG, נקודות ביקורת ופיצול נתונים, הדרכה מרובת משתתפים יכולה להקל מאוד על באגים.
אם יש לכם כמה צינורות מארחים מארחים:
- מוודאים שצינור עיבוד הנתונים מבצע רישום ובדיקת נתונים במארח אחד בלבד.
- צריך לסנכרן נתונים סטטיסטיים של נורמליזציה של אצווה בין מארחים לפני הערכה או נקודת ביקורת.
- פיצול של קובצי נתונים בין מארחים, כי בדרך כלל הפעולה הזו משפרת את הביצועים.
קריטי: חשוב לוודא שיש לכם זרעי RNG שזהים בין מארחים (לאתחול מודל), וזרעים שונים בין מארחים (בסידור נתונים/עיבוד מראש). לכן, הקפידו לסמן אותם כראוי.