נניח שאתם מפתחים אפליקציה להמלצה על אוכל, שבה המשתמשים מזינים את הארוחות האהובות עליהם, והאפליקציה מציעה ארוחות דומות שהם עשויים לאהוב. אתם רוצים לפתח מודל למידת מכונה (ML) שיכול לחזות את הדמיון בין אוכל, כדי שהאפליקציה שלך תוכל ליצור איכות גבוהה "מאחר שאתה אוהב פנקייקים, אנחנו ממליצים על קרפים").
כדי לאמן את המודל, צריך ליצור מערך נתונים של 5,000 ארוחות, כולל בורשט, נקניקייה, סלט, פיצה, ו-שווארמה.
אתם יוצרים תכונה meal
שמכילה
בקידוד חד-פעמי
שייצג כל אחד מפריטי הארוחה במערך הנתונים.
מלכודות של ייצוגי נתונים מועטים
עברתם על הקידודים החד-פעמיים האלה, ואתם מבחינים בשתי בעיות עיקריות ייצוג בווקטור של הנתונים.
- מספר המשקולות. וקטורי קלט גדולים מציינים מספר עצום
משקולות
לרשת נוירונים.
עם רשומות M בקידוד חד-פעמי, ו-N
בשכבה הראשונה של הרשת אחרי הקלט, המודל צריך לאמן את
משקולות MxN לשכבה הזו. משקלים רבים גורמים לבעיות נוספות:
- מספר נקודות הנתונים. ככל שהמודל מכיל יותר משקלים, כך יהיו לה יותר נתונים צריכים לאמן ביעילות.
- סכום החישוב. ככל שיש יותר משקולות, כך נדרש יותר חישובים כדי לאמן את המודל ולהשתמש בו. קל להתגבר על היכולות של חומרה.
- נפח זיכרון. ככל שיש יותר משקלים במודל, כך שנדרש במאיצים שמאמנים ומגישים אותו. הרחבה נוספת וקשה מאוד.
- קושי בתמיכה למידת מכונה במכשיר (ODML). אם רוצים להריץ מודל למידת מכונה במכשירים מקומיים (בניגוד להצגת אותם), תצטרכו להתמקד בהקטנת המודל, כדי להפחית את מספר המשקולות.
- היעדר קשרים משמעותיים בין וקטורים. ערכי הווקטורים קידודים חמים אחד למזון לא מספקים מידע משמעותי על דמיון בין פריטי מזון. מבחינה מתמטית, אינדקס 1 ("נקניקייה") הוא קרוב יותר לאינדקס 2 ("סלט") מאשר לאינדקס 4999 ("שווארמה"), למרות הכלב דומה יותר לשווארמה (בשניהם יש בשר ולחם) מאשר לסלט.
במודול הזה תלמדו איך ליצור הטמעות, עם ממדים נמוכים יותר של נתונים מועטים, שמטפלים בשתי הבעיות האלה.