נתונים גולמיים צריכים להיות מיועדים לשימוש בתכונות (טרנספורמציה). מתי צריך לבצע טרנספורמציה ? באופן כללי, ניתן לבצע הנדסת פיצ'רים (feature engineering) במהלך שתי התקופות הבאות:
- לפני אימון המודל.
- בזמן אימון המודל.
טרנספורמציה של נתונים לפני האימון
בגישה הזו, פועלים לפי שני שלבים:
- לכתוב קוד או להשתמש בכלים מיוחדים כדי לבצע טרנספורמציה של הנתונים הגולמיים.
- שומרים את הנתונים שעברו טרנספורמציה במקום שהמודל יכול להטמיע, כמו כמו בדיסק.
היתרונות
- המערכת משנה נתונים גולמיים פעם אחת בלבד.
- המערכת יכולה לנתח את כל מערך הנתונים כדי לקבוע את הערך הטוב ביותר את האסטרטגיה שלנו לטרנספורמציה.
החסרונות
- צריך ליצור מחדש את הטרנספורמציות בזמן החיזוי. צריך להיזהר מ- train-serving skew !
סטיית הצגת האימון מסוכנת יותר כאשר המערכת מבצעת באופן דינמי (אונליין). במערכת שמשתמשת בהסקה דינמית, התוכנה שמשנה מערך הנתונים הגולמי בדרך כלל שונה מהתוכנה שמציגה חיזויים, מה שעלול לגרום לסטיות training-serving skew. לעומת זאת, מערכות שמשתמשות בהסקה סטטית (אופליין) יכולות לפעמים משתמשים באותה תוכנה.
טרנספורמציה של נתונים בזמן אימון
בגישה הזו, הטרנספורמציה היא חלק מקוד המודל. המודל מטמיעה נתונים גולמיים ומשנה אותם.
היתרונות
- אם משנים את הטרנספורמציות, עדיין אפשר להשתמש באותם קובצי נתונים גולמיים.
- יובטחו לכם טרנספורמציות זהות בזמן האימון והחיזוי.
החסרונות
- טרנספורמציות מורכבות יכולות להאריך את זמן האחזור של המודל.
- טרנספורמציות מתרחשות בכל קבוצה.
לא קל לשנות את הנתונים בכל קבוצה. לדוגמה, נניח שאתם רוצים להשתמש בנירמול של ציון ה-Z כדי להפוך נתונים מספריים גולמיים. נירמול של ציון ה-Z דורש את הממוצע סטיית תקן של התכונה. עם זאת, המשמעות של טרנספורמציות לכל קבוצת קבצים היא שתהיה לך גישה רק אצווה אחת של נתונים, ולא את מערך הנתונים המלא. כך שאם הקבוצות יהיו גבוהות לווריאנט, ציון Z, למשל, -2.5 בקבוצה אחת, לא יקבל את אותה משמעות. בתור -2.5 בקבוצה אחרת. כפתרון זמני, המערכת יכולה לחשב מראש את הממוצע ואת סטיית התקן. בכל מערך הנתונים ואז להשתמש בהם כקבועים במודל.