ייצוג: נתוני ניקיון

זמן משוער: 10 דקות

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

שינוי קנה המידה של ערכי התכונות

Scaling הוא המרה של ערכי תכונות של נקודה צפה (floating-point) מהטווח הטבעי שלהם (לדוגמה, 100 עד 900) לטווח סטנדרטי (לדוגמה, מ-0 ל-1, או מ- -1 עד +1). אם קבוצת תכונות כוללת רק תכונה אחת, לקנה מידה יש יתרון מעשי מועט, אם בכלל. עם זאת, אם קבוצת תכונות מורכבת מכמה תכונות, הרחבת התכונות מספקת את היתרונות הבאים:

• עוזר להמרה בירידה הדרגתית במהירות רבה יותר.
• כך אפשר למנוע את "trap" של NaN, שבו מספר אחד במודל הופך ל-NaN (למשל, כשערך חורג ממגבלת הדיוק של הנקודה הצפה במהלך האימון), וכתוצאה מפעולות מתמטיות – כל מספר אחר במודל הופך בסופו של דבר ל-NaN.
• עוזר למודל ללמוד את המשקולות המתאימות לכל תכונה. אם לא ניתן לשנות את גודל התכונות, המודל יקדיש יותר מדי תשומת לב לתכונות שיש להן טווח רחב יותר.

לא חייבים לתת לכל פיצ'ר של נקודה צפה (floating-point) בדיוק אותו היקף. לא יקרה שום דבר רע אם תכונה א' עוברת שינוי מ-1 ל-1+, כאשר תכונה ב' משתנה מ-3- ל-3+. עם זאת, המודל יגיב בצורה גרועה אם תכונה ב' משוקללת מ-5,000 ל-100,000.

לוחצים על סמל הפלוס לקבלת מידע נוסף על שינוי קנה מידה.

אחת הדרכים הברורות לשנות את קנה המידה של נתונים מספריים היא למפות באופן לינארי את [ערך מינימלי, ערך מקסימלי] לקנה מידה קטן, כמו [ -1, +1].

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

$$scaled value = (value - mean) / stddev.$$

לדוגמה, בהינתן:

• ממוצע = 100
• סטיית תקן = 20
• ערך מקורי = 130

ואז:

  scaled_value = (130 - 100) / 20
  scaled_value = 1.5

כשמתרחבים בעזרת ציוני Z, המשמעות היא שרוב הערכים נעים בין 3- ל-3, אבל כמה ערכים יהיו מעט גבוהים יותר או נמוכים יותר מהטווח הזה.

טיפול בחריגות קיצוניות

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

איור 4. זנב ברררי לונה.

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

איור 5. קנה מידה לוגריתמי עדיין משאיר זנב.

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

איור 6. ערכי תכונת חיתוך של 4.0

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

כלי קיבול

התרשים הבא מציג את השכיחות היחסית של הבתים בקווי רוחב שונים בקליפורניה. שימו לב לקיבוץ - לוס אנג'לס נמצאת בקו הרוחב 34, וסן פרנסיסקו נמצאת בערך בקו הרוחב 38.

איור 7. בתים בכל קו רוחב.

במערך הנתונים, latitude הוא ערך של נקודה צפה (floating-point). עם זאת, לא הגיוני להציג במודל שלנו את latitude כתכונה צפה (floating-point). הסיבה לכך היא שלא קיים קשר לינארי בין ערכי קו הרוחב לדיור. לדוגמה, בתים בקו רוחב 35 לא \(\frac{35}{34}\) יקרים יותר (או פחות יקרים) מבתים בקו רוחב 34. עם זאת, קווי רוחב נפרדים הם כנראה חיזוי טוב למדי לערכי בתים.

כדי להפוך את קווי הרוחב לחיזוי שימושיים, נחלק את קווי הרוחב ל"סלים" לפי הדמות הבאה:

איור 8. מקבצים ערכים.

במקום להשתמש בתכונה אחת של נקודה צפה (floating-point), יש לנו עכשיו 11 תכונות בוליאניות ייחודיות (LatitudeBin1, LatitudeBin2, ..., LatitudeBin11). האפשרות של 11 פיצ'רים נפרדים היא לא אלגנטית, לכן נאחד אותם לווקטור אחד של 11 רכיבים. כך נוכל לייצג את קו הרוחב 37.4 באופן הבא:

[0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0]

בזכות binning, המודל שלנו יכול עכשיו ללמוד משקלים שונים לחלוטין לכל קו רוחב.

לוחצים על סמל הפלוס כדי לקבל מידע נוסף על bining גבולות.

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

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

קרצוף

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

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

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

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

• מקסימום ומינימום
• ממוצע וחציון
• סטיית תקן

כדאי ליצור רשימות של הערכים הנפוצים ביותר לתכונות נפרדות. לדוגמה, אם מספר הדוגמאות עם country:uk תואם למספר שציפיתם לו. האם language:jp היא באמת השפה הכי נפוצה בקבוצת הנתונים שלכם?

הכר את הנתונים שלך

חשוב להקפיד על הכללים הבאים:

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

יש להתייחס לנתונים בכל הקשור לקודים שחיוניים למשימה. למידת מכונה טובה מסתמכת על נתונים טובים.

מידע נוסף

כללים של למידת מכונה, שלב 2 של למידת מכונה: הנדסת תכונות

מונחי מפתח

binning	קבוצת תכונות
מלכודת NaN	יוצאים מן הכלל
התאמה לעומס (scaling)

מרכז העזרה