בדקנו דרכים למיפוי נתונים גולמיים לווקטורים מתאימים של תכונות, אבל זה רק חלק מהעבודה. עכשיו עלינו לחקור אילו סוגי ערכים למעשה יוצרים תכונות טובות בווקטורים של תכונות אלה.
לא משתמשים בערכי תכונות נפרדים שמשמשים לעתים רחוקות
ערכים טובים של תכונות צריכים להופיע יותר מ-5 פעמים בקבוצת נתונים.
כך המודל יוכל ללמוד איך ערך התכונה הזה קשור לתווית.
כלומר, הוספת הרבה דוגמאות עם אותו ערך נפרד מאפשרת למודל לראות את התכונה בהגדרות שונות, וכתוצאה מכך לקבוע מתי זהו חיזוי טוב לתווית. לדוגמה, סביר להניח שתכונה house_type תכלול הרבה דוגמאות שבהן הערך שלה היה victorian:
✔This is a good example:house_type: victorian
לעומת זאת, אם ערך של תכונה מופיע רק פעם אחת או לעיתים רחוקות מאוד, המודל לא יכול ליצור חיזויים על סמך התכונה הזו. לדוגמה, unique_house_id היא תכונה גרועה כי בכל ערך נעשה שימוש פעם אחת בלבד, כך שהמודל לא היה יכול ללמוד ממנו דבר:
The following is an example of a unique value. This should be avoided.✘unique_house_id: 8SK982ZZ1242Z
העדף משמעויות ברורות וברורות
לכל עצם בפרויקט צריכה להיות משמעות ברורה וברורה. לדוגמה, לתכונה המוצלחת הבאה יש שם ברור, והערך שלה הגיוני ביחס לשם:
✔The meaning of the following value is clear from the label and value.house_age_years: 27
לעומת זאת, כמעט אף אחד לא יכול לפענח את המשמעות של ערך התכונה הבא, מלבד המהנדס שיצר אותה:
✘The following is an example of a value that is unclear. This should be avoidedhouse_age: 851472000
במקרים מסוימים, נתונים עם רעש (ולא החלטות הנדסיות גרועות) גורמים לערכים לא ברורים. לדוגמה, ה-user_age_years הבאים הגיעו ממקור שלא בדק ערכים מתאימים:
✘The following is an example of noisy/bad data. This should be avoided.user_age_years: 277
אין לשלב ערכים 'קסם' עם הנתונים האמיתיים
תכונות טובות של נקודה צפה (floating-point) לא כוללות אי-רציפות ייחודית מחוץ לטווח או ערכי "קסם". לדוגמה, נניח שתכונה מכילה ערך של נקודה צפה (floating-point) בין 0 ל-1. אז ערכים כמו אלה הם תקינים:
✔The following is a good example:quality_rating: 0.82 quality_rating: 0.37
עם זאת, אם משתמש לא הזין quality_rating, יכול להיות שמערך הנתונים
מייצג את ההיעדר שלו באמצעות ערך קסם כמו בדוגמה הבאה:
✘The following is an example of a magic value. This should be avoided.quality_rating: -1
כדי לסמן באופן מפורש ערכי קסם, צריך ליצור תכונה בוליאנית שמציינת
אם סופק quality_rating או לא. נותנים לתכונה בוליאנית שם כמו is_quality_rating_defined.
בתכונה המקורית, מחליפים את ערכי הקסם באופן הבא:
- למשתנים שמקבלים קבוצה סופית של ערכים (משתנים נפרדים), מוסיפים ערך חדש לקבוצה ומשתמשים בו כדי לציין שהערך של התכונה חסר.
- במשתנים רציפים, צריך לוודא שהערכים החסרים לא משפיעים על המודל, על ידי שימוש בערך הממוצע של נתוני התכונה.
התחשבות בחוסר יציבות בזרימה
ההגדרה של התכונה לא אמורה להשתנות עם הזמן. לדוגמה, הערך הבא שימושי מכיוון ששם העיר כנראה לא ישתנה. (שימו לב שעדיין נצטרך להמיר מחרוזת כמו "br/sao_paulo" לווקטור חם אחד).
✔This is a good example:city_id: "br/sao_paulo"
אך איסוף ערך שמוסק ממודל אחר כרוך בעלויות נוספות. אולי הערך '219' מייצג כרגע את סאו פאולו, אבל הייצוג הזה עשוי להשתנות בקלות בהפעלה עתידית של המודל האחר:
✘The following is an example of a value that could change. This should be avoided.inferred_city_cluster: "219"