כללים ללמידת מכונה:

שיטות מומלצות למהנדסי למידת מכונה

מרטין זינקיוויץ' (Martin Zinkevich)

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

מרטין זינקיוויץ' מציג 10 מהכללים האהובים עליו בתחום למידת המכונה. כדאי להמשיך לקרוא כדי לקבל מידע על כל 43 הכללים!

הסברים על המונחים

המונחים הבאים יופיעו שוב ושוב במהלך הדיון שלנו בנושא למידת מכונה יעילה:

  • Instance: הדבר שרוצים לחזות לגביו. לדוגמה, המופע יכול להיות דף אינטרנט שרוצים לסווג כ'מידע על חתולים' או כ'לא מידע על חתולים'.
  • תווית: תשובה למטלת חיזוי – התשובה שנוצרה על ידי מערכת למידת מכונה או התשובה הנכונה שסופקה בנתוני האימון. לדוגמה, התווית של דף אינטרנט עשויה להיות 'מידע על חתולים'.
  • מאפיין: מאפיין של מכונה שמשמש במשימה של חיזוי. לדוגמה, דף אינטרנט יכול לכלול את המאפיין 'מכיל את המילה 'חתול''.
  • עמודת תכונות: קבוצה של תכונות קשורות, כמו הקבוצה של כל המדינות האפשריות שבהן המשתמשים עשויים לגור. לדוגמה, יכול להיות שעמודת תכונות תכלול תכונה אחת או יותר. המונח 'עמודת תכונה' הוא מונח ספציפי ל-Google. עמודת תכונה נקראת 'מרחב שמות' במערכת VW (ב-Yahoo או ב-Microsoft), או שדה.
  • דוגמה: מכונה (עם המאפיינים שלה) ותווית.
  • מודל: ייצוג סטטיסטי של משימה של חיזוי. אתם מארגנים מודלים על סמך דוגמאות, ואז משתמשים במודלים האלה כדי לבצע חיזויים.
  • מדד: מספר שחשוב לכם. יכול להיות שהם יעברו אופטימיזציה ישירה, ויכול להיות שלא.
  • יעד: מדד שהאלגוריתם מנסה לבצע אופטימיזציה שלו.
  • צינור עיבוד נתונים: התשתית שמקיפה אלגוריתם של למידת מכונה. כולל איסוף הנתונים מהחזית, הכנסתם לקובצי נתוני אימון, אימון מודל אחד או יותר וייצוא המודלים לסביבת הייצור.
  • שיעור קליקים: אחוז המבקרים בדף אינטרנט שלוחצים על קישור במודעה.

סקירה כללית

כדי ליצור מוצרים מעולים:

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

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

  1. מוודאים שהצינור שפועל מקצה לקצה תקין.
  2. מתחילים עם יעד סביר.
  3. הוספת תכונות הגיוניות בצורה פשוטה.
  4. מוודאים שהצינור שפועל להעברת הנתונים נשאר יציב.

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

אחרי שתנסו את כל הטריקים הפשוטים, יכול להיות שלמידת מכונה מתקדמת תהיה הפתרון בשבילכם. אפשר לעיין בקטע בנושא שלב III בפרויקטים של למידת מכונה.

המסמך הזה מחולק כך:

  1. החלק הראשון יעזור לכם להבין אם זה הזמן הנכון לפתח מערכת למידת מכונה.
  2. החלק השני עוסק בפריסה של צינור עיבוד הנתונים הראשון.
  3. החלק השלישי עוסק בהשקה ובביצוע שינויים חוזרים תוך הוספת תכונות חדשות לצינור עיבוד הנתונים, בהערכת מודלים ובשימוש ב-training-serving skew.
  4. בחלק האחרון נסביר מה עושים כשמגיעים לשלב שבו העלייה בנתונים נעצרת.
  5. לאחר מכן מופיעה רשימה של עבודות קשורות ונספח עם רקע על המערכות שבהן נעשה שימוש בדוגמאות במסמך הזה.

לפני למידת המכונה

כלל מס' 1: אל תפחדו להשיק מוצר בלי למידת מכונה.

למידת מכונה היא כלי נהדר, אבל היא דורשת נתונים. באופן תיאורטי, אפשר להשתמש בנתונים מבעיה אחרת ואז לשנות את המודל למוצר חדש, אבל סביר להניח שהביצועים יהיו נמוכים יותר מאשר בשיטות ניתוח 'היגוריסטיות' בסיסיות. אם לדעתכם למידה חישובית תשפר את הביצועים ב-100%, שיטה heuristic תשפר אותם ב-50%.

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

כלל מס' 2: קודם צריך לעצב ולהטמיע מדדים.

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

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

צוות Google Plus מודד את מספר ההרחבות לכל קריאה, מספר השיתופים מחדש לכל קריאה, מספר ה-1+ לכל קריאה, מספר התגובות לכל קריאה, מספר התגובות לכל משתמש, מספר השיתופים מחדש לכל משתמש וכו', ומשתמש בנתונים האלה כדי לחשב את רמת האיכות של פוסט בזמן הצגתו. חשוב גם לזכור שחשוב ליצור מסגרת לניסוי שבה אפשר לקבץ משתמשים לקטגוריות ולצבור נתונים סטטיסטיים לפי ניסוי. כלל מס' 12

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

כלל מס' 3: עדיף לבחור בלמידת מכונה במקום בהיגוריית מורכבת.

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

שלב ראשון ב-ML: צינור עיבוד הנתונים הראשון

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

כלל מס' 4: מומלץ לשמור על המודל הראשון פשוט ולבחור את התשתית הנכונה.

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

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

בחירה בתכונות פשוטות מאפשרת לכם לוודא:

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

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

כלל מס' 5: בודקים את התשתית בנפרד מלמידת המכונה.

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

  1. בודקים את הכנסת הנתונים לאלגוריתם. בודקים אם עמודות המאפיינים שצריך לאכלס מאוכלסות. כשהדבר אפשרי מבחינת פרטיות, כדאי לבדוק באופן ידני את הקלט של אלגוריתם האימון. אם אפשר, כדאי לבדוק את הנתונים הסטטיסטיים בצינור עיבוד הנתונים בהשוואה לנתונים הסטטיסטיים של אותם נתונים שעברו עיבוד במקום אחר.
  2. בדיקה של אחזור מודלים מהאלגוריתם של האימון. מוודאים שהמודל בסביבת האימון מניב את אותו ציון כמו המודל בסביבת ההצגה (ראו כלל מס' 37).

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

כלל מס' 6: חשוב להיזהר מנתונים שנמחקים כשמעתיקים צינורות עיבוד נתונים.

לרוב אנחנו יוצרים צינור עיבוד נתונים על ידי העתקה של צינור עיבוד נתונים קיים (כלומר, תכנות של פולחן דת), וצינור עיבוד הנתונים הישן משאיר נתונים שאנחנו צריכים לצינור עיבוד הנתונים החדש. לדוגמה, צינור עיבוד הנתונים של 'מה חם' ב-Google Plus משאיר מאחור פוסטים ישנים (כי הוא מנסה לדרג פוסטים חדשים). צינור עיבוד הנתונים הזה הועתק לשימוש ב-Stream של Google Plus, שבו פוסטים ישנים עדיין רלוונטיים, אבל צינור עיבוד הנתונים עדיין השמיט פוסטים ישנים. דפוס נפוץ נוסף הוא לרשום ביומן רק נתונים שהמשתמש ראה. לכן, הנתונים האלה לא מועילים אם רוצים ליצור מודל לבחירת פוסט מסוים שלא מוצג למשתמש, כי כל הדוגמאות השליליות הוסרו. אירעה בעיה דומה ב-Play. במהלך העבודה על דף הבית של אפליקציות Play, נוצר צינור עיבוד נתונים חדש שהכיל גם דוגמאות מדף הנחיתה של Play Games, בלי תכונה כלשהי שתעזור להבין מאיפה כל דוגמה הגיעה.

כלל מס' 7: הופכים את שיטות הניתוח ההשוואתי לתכונות, או מטפלים בהן באופן חיצוני.

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

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

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

מעקב

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

כלל מס' 8: חשוב לדעת מהן דרישות הרענון של המערכת.

עד כמה הביצועים יורדים אם יש לכם מודל בן יום? שבוע? רבעון? המידע הזה יכול לעזור לכם להבין את סדר העדיפויות של המעקב. אם איכות המוצרים נפגעת באופן משמעותי אם המודל לא מתעדכן במשך יום, כדאי להקצות מהנדס שיעקוב אחריו באופן שוטף. רוב המערכות להצגת מודעות צריכות לטפל במודעות חדשות מדי יום, והן צריכות להתעדכן מדי יום. לדוגמה, אם מודל ה-ML של חיפוש Google Play לא יתעדכן, יכול להיות שיהיו לכך השפעות שליליות תוך פחות מחודש. בחלק מהמודלים של 'מה הכי חם' ב-Google Plus אין מזהה פוסט, ולכן אפשר לייצא את המודלים האלה לעיתים רחוקות. מודלים אחרים שיש להם מזהים של פוסטים מתעדכנים בתדירות גבוהה בהרבה. חשוב גם לזכור שהרעננות יכולה להשתנות עם הזמן, במיוחד כשמוסיפים או מסירים עמודות של תכונות מהמודל.

כלל מספר 9: זיהוי בעיות לפני ייצוא מודלים.

במערכות רבות של למידת מכונה יש שלב שבו מייצאים את המודל לצורך הצגה. אם יש בעיה במודל שיוצאו, זו בעיה שמשפיעה על המשתמשים.

מומלץ לבצע בדיקות תקינות לפני ייצוא המודל. באופן ספציפי, חשוב לוודא שהביצועים של המודל סבירים בנתונים ששמורים לצורך בדיקה. לחלופין, אם יש לכם חששות לגבי הנתונים, אל לייצא מודל. צוותים רבים שמפרסים מודלים באופן שוטף בודקים את השטח מתחת לעקומת ROC (או AUC) לפני הייצוא. בעיות שקשורות למודלים שלא יוצאו צריכות להישלח בתור התראה באימייל, אבל בעיות במודל שגלוי למשתמשים עשויות לדרוש דף. לכן, עדיף להמתין עד שתהיה לכם ודאות לפני שתשפיעו על המשתמשים.

כלל מס' 10: חשוב לבדוק אם יש כשלים שקטים.

זו בעיה שקיימת יותר במערכות למידה חישובית מאשר בסוגים אחרים של מערכות. נניח שטבלה מסוימת שמשתתפת בחיבור כבר לא מתעדכנת. מערכת למידת המכונה תתאים את עצמה, וההתנהגות תמשיך להיות טובה למדי, ותתדרדר בהדרגה. לפעמים מוצאים טבלאות שלא עודכנו כבר חודשים, ורענון פשוט שלהן משפר את הביצועים יותר מכל השקות אחרות ברבעון. הכיסוי של תכונה מסוימת עשוי להשתנות עקב שינויים בהטמעה: לדוגמה, עמודת תכונה יכולה להיות מאוכלסת ב-90% מהדוגמאות, ולרדת פתאום ל-60% מהדוגמאות. פעם הייתה ב-Play טבלה שלא עודכנה במשך 6 חודשים, ועדכון הטבלה לבדו הוביל לעלייה של 2% בשיעור ההתקנות. אם תעקבו אחרי הנתונים הסטטיסטיים וגם תבדקו את הנתונים באופן ידני מדי פעם, תוכלו לצמצם את סוגי הכשלים האלה.

כלל מס' 11: צריך להקצות עמודות תכונות לבעלים ולספק להן תיעוד.

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

היעד הראשון

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

כלל מס' 12: אל תשקיעו יותר מדי מחשבה בבחירת היעד לאופטימיזציה ישירה.

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

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

כלל מס' 13: בוחרים מדד פשוט, שניתן לצפות בו ולשייך אותו ליעד הראשון.

לרוב אתם לא יודעים מה היעד האמיתי. אתם חושבים שאתם יודעים, אבל כשאתם מעיינים בנתונים ובניתוח מקביל של המערכת הישנה ושל מערכת ה-ML החדשה, אתם מבינים שאתם רוצים לשנות את היעד. בנוסף, לעתים קרובות חברי צוות שונים לא מסכימים על היעד האמיתי. יעד ה-ML צריך להיות משהו שקל למדוד, ומשמש כמדד ביניים ליעד 'האמיתי'. למעשה, לעיתים קרובות אין יעד 'אמיתי' (ראו כלל מס' 39). לכן, כדאי לאמן את המערכת לפי היעד הפשוט של למידת המכונה, ולשקול להוסיף "שכבת מדיניות" שמאפשרת להוסיף לוגיקה נוספת (לפי רצונכם, לוגיקה פשוטה מאוד) כדי לבצע את הדירוג הסופי.

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

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

בשלב הראשון, מומלץ להימנע מהצגת מודל של השפעות עקיפות:

  • האם המשתמש ביקר ביום הבא?
  • כמה זמן המשתמש ביקר באתר?
  • מה היה מספר המשתמשים הפעילים היומי?

השפעות עקיפות הן מדדים מצוינים, וניתן להשתמש בהן במהלך בדיקות A/B ובמהלך קבלת החלטות לגבי השקה.

לבסוף, אל תנסו לגרום ללמידת המכונה להבין:

  • האם המשתמש מרוצה מהמוצר?
  • האם המשתמש מרוצה מהחוויה?
  • האם המוצר משפר את הרווחה הכללית של המשתמש?
  • איך זה ישפיע על המצב הכללי של החברה?

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

כלל מס' 14: קל יותר לנפות באגים כשמתחילים עם מודל שניתן לפרש.

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

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

קל יותר לטפל במשובים במעגלים של מודלים פשוטים (ראו כלל מס' 36). לעיתים קרובות אנחנו משתמשים בתחזיות המבוססות על הסתברות כדי לקבל החלטות: לדוגמה, דירוג פוסטים לפי ערך צפוי יורד (כלומר, הסבירות ללחיצה/להורדה וכו'). עם זאת, חשוב לזכור שכאשר מגיע הזמן לבחור איזה מודל להשתמש בו, ההחלטה חשובה יותר מהסבירות של הנתונים בהתאם למודל (ראו כלל מס' 27).

כלל מס' 15: הפרדה בין סינון ספאם לבין דירוג לפי איכות בשכבת מדיניות.

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

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

שלב 2 ב-ML: הנדסת פיצ'רים

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

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

כלל מס' 16: תכנון ההשקה וחזרה על התהליך.

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

  • אתם מפתחים תכונות חדשות.
  • אתם משנים את ההתאמה של הרגולריזציה ומשלבים תכונות ישנות בדרכים חדשות.
  • אתם מבצעים התאמה של היעד.

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

כלל מס' 17: כדאי להתחיל עם תכונות שנצפו ונמסרו ישירות, ולא עם תכונות שנלמדו.

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

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

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

כלל מס' 18: כדאי לבדוק את התכונות של התוכן שאפשר להכליל בהקשרים שונים.

לרוב, מערכת למידת מכונה היא חלק קטן מתמונה גדולה בהרבה. לדוגמה, אם נדמיין פוסט שעשוי להופיע בקטע 'מה הכי חם', הרבה אנשים ילחצו על סמל הפלוס, ישתפו אותו מחדש או ישתפו עליו תגובה לפני שהוא יוצג בקטע 'מה הכי חם'. אם תספקו את הנתונים הסטטיסטיים האלה למערכת הלמידה, היא תוכל לקדם פוסטים חדשים שאין לה נתונים לגבי ההקשר שבו היא מבצעת אופטימיזציה. בקטע 'הצעות לצפייה ב-YouTube יכולים להופיע סרטונים לפי מספר הצפיות או לפי צפיות משותפות (מספר הפעמים שסרטון אחד נצפה אחרי שסרטון אחר נצפה) בחיפוש ב-YouTube. אפשר גם להשתמש בדירוגי משתמשים בוטים. לבסוף, אם יש לכם פעולת משתמש שאתם משתמשים בה בתור תווית, יכול להיות שתכונה נהדרת היא הצגת הפעולה הזו במסמך בהקשר אחר. כל התכונות האלה מאפשרות לכם להוסיף תוכן חדש להקשר. חשוב לזכור שמדובר לא בנושא של התאמה אישית: קודם צריך לבדוק אם התוכן מוצא חן בעיני מישהו בהקשר הזה, ואז לבדוק למי הוא מוצא חן בעיני יותר או פחות.

כלל מס' 19: כשאפשר, כדאי להשתמש בתכונות ספציפיות מאוד.

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

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

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

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

צמתים משלבים בין שתי עמודות תכונות או יותר. עמודת תכונה, במונחים של TensorFlow, היא קבוצה של תכונות הומוגניות (למשל {male, female},‏ {US,‏ Canada,‏ Mexico} וכו'). צלב הוא עמודה חדשה של תכונות עם תכונות, למשל, {male, female} × {US,Canada, Mexico}. עמודה התכונה החדשה הזו תכיל את התכונה (זכר, קנדה). אם אתם משתמשים ב-TensorFlow ומבקשים ממנו ליצור את הצלב הזה, התכונה (זכר, קנדה) תופיע בדוגמאות שמייצגות גברים בקנדה. חשוב לזכור שנדרשים כמויות אדירות של נתונים כדי ללמד מודלים עם צירופי שלוש, ארבע או יותר עמודות של מאפיינים בסיסיים.

אם נעשה שימוש במכפילים שמניבים עמודות תכונות גדולות מאוד, יכול להיות שיהיה התאמה יתר. לדוגמה, נניח שאתם מבצעים חיפוש כלשהו, ויש לכם עמודה של מאפיין עם מילים בשאילתה, ויש לכם עמודה של מאפיין עם מילים במסמך. אפשר לשלב אותם עם צלב, אבל בסוף יהיו לכם הרבה תכונות (ראו כלל מס' 21).

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

כלל מס' 21: מספר משקלי המאפיינים שאפשר ללמוד במודל לינארי הוא ביחס ישיר לכמות הנתונים שיש לכם.

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

  1. אם אתם עובדים על מערכת לדירוג חיפושים, ויש מיליוני מילים שונות במסמכים ובשאילתה, ויש לכם 1,000 דוגמאות מתויגות, כדאי להשתמש במכפלת נקודה בין מאפייני המסמך למאפייני השאילתה, ב-TF-IDF ובחצי תריסר מאפיינים אחרים שנוצרו על ידי בני אדם. 1,000 דוגמאות, תריסר תכונות.
  2. אם יש לכם מיליון דוגמאות, עליכם לחצות בין העמודות של המסמך לבין העמודות של מאפייני השאילתה, באמצעות רגולריזציה ואולי גם באמצעות בחירת מאפיינים. כך תקבלו מיליוני תכונות, אבל אם תבצעו רגולריזציה, תקבלו פחות תכונות. עשרה מיליון דוגמאות, אולי מאה אלף תכונות.
  3. אם יש לכם מיליארדי דוגמאות או מאות מיליארדי דוגמאות, תוכלו לחצות את עמודות המאפיינים עם אסימונים של מסמכים ושאילתות, באמצעות בחירת מאפיינים ורגולריזציה. יהיו לכם מיליארד דוגמאות ו-10 מיליון מאפיינים. תיאוריית הלמידה הסטטיסטית מספקת לעתים רחוקות גבולות הדוקים, אבל היא מספקת הנחיות מצוינות לנקודת התחלה.

בסופו של דבר, תוכלו להיעזר בכלל מס' 28 כדי להחליט באילו תכונות להשתמש.

כלל מס' 22: מסירים תכונות שלא משתמשים בהן יותר.

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

חשוב לזכור את הכיסוי כשמחליטים אילו תכונות להוסיף או להשאיר. כמה דוגמאות מכוסות בתכונה? לדוגמה, אם יש לכם כמה תכונות של התאמה אישית, אבל רק ל-8% מהמשתמשים יש תכונות כאלה, ההתאמה האישית לא תהיה יעילה במיוחד.

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

ניתוח אנושי של המערכת

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

כלל מס' 23: אתם לא משתמשי קצה רגילים.

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

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

אם אתם רוצים לקבל משוב ממשתמשים, השתמשו בשיטות של חוויית משתמש. כדאי ליצור דמויות משתמש (תיאור אחד מופיע בספר Sketching User Experiences של ביל בקסטון) בשלב מוקדם בתהליך, ולבצע בדיקות נוחות שימוש (תיאור אחד מופיע בספר Don't Make Me Think של סטיב קרוג) בשלב מאוחר יותר. יצירת דמויות משתמשים כוללת יצירה של משתמש היפותטי. לדוגמה, אם כל הצוות שלכם מורכב מגברים, כדאי ליצור פרופיל משתמש נשי בגיל 35 (עם מאפייני משתמש מלאים) ולבחון את התוצאות שהוא מניב, במקום 10 תוצאות לגברים בגילאי 25 עד 40. אפשר גם לקבל נקודת מבט חדשה על האתר על ידי הצגת האתר לאנשים אמיתיים (במקומיות או מרחוק) במסגרת בדיקת נוחות השימוש.

כלל מס' 24: מודדים את ההפרש בין המודלים.

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

כלל מס' 25: כשבוחרים מודלים, הביצועים התועלתניים חשובים יותר מיכולת החיזוי.

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

כלל מס' 26: מחפשים דפוסים בשגיאות שנמדדו ויוצרים תכונות חדשות.

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

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

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

כלל מס' 27: נסו לכמת התנהגות לא רצויה שנצפתה.

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

כלל מס' 28: חשוב לזכור שהתנהגות זהה בטווח הקצר לא מחייבת התנהגות זהה בטווח הארוך.

נניח שיש לכם מערכת חדשה שמסתכלת על כל doc_id ו-exact_query, ואז מחשבת את הסבירות לקליק לכל doc לכל שאילתת חיפוש. אתם מגלים שההתנהגות שלה כמעט זהה לזו של המערכת הנוכחית שלכם, גם בבדיקות מקבילות וגם בבדיקות A/B, ולכן אתם משיקים אותה בגלל הפשטות שלה. עם זאת, אתם מבחינים שאין אפליקציות חדשות שמוצגות. למה? מכיוון שהמערכת מציגה מסמך רק על סמך ההיסטוריה שלה עם השאילתה הזו, אין לה דרך לדעת שצריך להציג מסמך חדש.

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

הטיה של אימון-הצגה

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

  • אי התאמה בין האופן שבו מטפלים בנתונים בצינורות עיבוד הנתונים של האימון וההצגה.
  • שינוי בנתונים בין האימון להצגה.
  • לולאת משוב בין המודל לבין האלגוריתם.

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

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

גם אם אי אפשר לעשות זאת לכל דוגמה, כדאי לעשות זאת לחלק קטן מהן כדי שתוכלו לוודא את העקביות בין ההצגה לאימון (ראו כלל מס' 37). צוותים ב-Google שערכו את המדידה הזו הופתע לפעמים מהתוצאות. דף הבית של YouTube עבר לשימוש בתכונות של רישום ביומן בזמן ההצגה, עם שיפורים משמעותיים באיכות וצמצום המורכבות של הקוד. צוותים רבים עוברים כרגע לשדרוג התשתית שלהם.

כלל מס' 30: נתונים שנלקחו מדגימה לפי משקל חשיבות, אל תמחקו אותם באופן שרירותי!

כשיש יותר מדי נתונים, יש נטייה לבחור את הקבצים 1-12 ולהתעלם מהקבצים 13-99. זו טעות. אפשר להשמיט נתונים שלא הוצגו למשתמש אף פעם, אבל משקל חשוב הוא הפתרון הטוב ביותר לשאר הנתונים. שימוש במדד החשיבות פירושו שאם אתם מחליטים לבחור דוגמה X עם הסתברות של 30%, נותנים לה משקל של 10/3. גם כשמשתמשים בשיוך משקלים לחשיבות, כל מאפייני הכיול שצוינו בכלל מס' 14 עדיין רלוונטיים.

כלל מס' 31: חשוב לזכור שאם משלבים נתונים מטבלה בזמן האימון וההצגה, הנתונים בטבלה עשויים להשתנות.

נניח שאתם משלבים מזהי מסמכים עם טבלה שמכילה מאפיינים של המסמכים האלה (כמו מספר התגובות או הקליקים). בין שלב האימון לבין שלב ההצגה, יכול להיות שיהיו שינויים בתכונות בטבלה. כתוצאה מכך, התחזית של המודל לגבי אותו מסמך עשויה להיות שונה באימון ובזמן ההצגה. הדרך הקלה ביותר למנוע בעיות כאלה היא לתעד את התכונות בזמן ההצגה (ראו כלל מס' 32). אם הטבלה משתנה באיטיות, אפשר גם ליצור קובץ snapshot של הטבלה מדי שעה או מדי יום כדי לקבל נתונים קרובים למדי. לתשומת ליבך, הפעולה הזו עדיין לא פותרת את הבעיה באופן מלא.

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

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

כלל מס' 33: אם יוצרים מודל על סמך הנתונים עד 5 בינואר, צריך לבדוק את המודל על הנתונים מ-6 בינואר ואילך.

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

כלל מס' 34: בסיווג בינארי לסינון (כמו זיהוי ספאם או זיהוי אימיילים מעניינים), כדאי להקריב ביצועים קטנים לטווח קצר כדי לקבל נתונים נקיים מאוד.

במשימה של סינון, דוגמאות שמסומנות כשלילה לא מוצגות למשתמש. נניח שיש לכם מסנן שחוסם 75% מהדוגמאות השליליות במהלך ההצגה. יכול להיות שתתפתתו להוסיף נתוני אימון מהמכונות שמוצגות למשתמשים. לדוגמה, אם משתמש מסוים מסמן כספאם אימייל שהמסנן שלכם לא חסם, כדאי להפיק מכך לקחים.

אבל הגישה הזו מובילה לשגיאות דגימה. כדי לאסוף נתונים נקיים יותר, תוכלו לתייג 1% מכל התנועה כ'קבוצת בקרה' ולשלוח את כל הדוגמאות מקבוצת הבקרה למשתמש. עכשיו המסנן חוסם לפחות 74% מהדוגמאות השליליות. הדוגמאות האלה ששמורות לבדיקה יכולות להפוך לנתוני האימון שלכם.

לתשומת ליבכם: אם המסנן חוסם 95% מהדוגמאות השליליות או יותר, הגישה הזו פחות רלוונטית. עם זאת, אם אתם רוצים למדוד את ביצועי ההצגה, תוכלו ליצור דגימה קטנה עוד יותר (למשל 0.1% או 0.001%). עשרת אלפים דוגמאות מספיקות כדי להעריך את הביצועים בצורה די מדויקת.

כלל מס' 35: חשוב להיזהר מההטיה הטבעית בבעיות שקשורות לדירוג.

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

  1. יש רגולריזציה גבוהה יותר בתכונות שמכסות יותר שאילתות, בהשוואה לתכונות שפועלות רק בשאילתה אחת. כך המודל יעדיף תכונות ספציפיות לשאילתה אחת או לשאילתות ספורות על פני תכונות שחלות באופן כללי על כל השאילתות. הגישה הזו יכולה למנוע זליגה של תוצאות פופולריות מאוד לשאילתות לא רלוונטיות. חשוב לזכור שההמלצה הזו מנוגדת להמלצה המקובלת יותר, שלפיה צריך להשתמש ברגולריזציה רבה יותר בעמודות המאפיינים עם יותר ערכים ייחודיים.
  2. לאפשר רק משקלים חיוביים למאפיינים. לכן, כל תכונה טובה תהיה טובה יותר מתכונה שהיא 'לא ידועה'.
  3. לא כוללות תכונות שמיועדות למסמכים בלבד. זו גרסה קיצונית של השיטה הראשונה. לדוגמה, גם אם אפליקציה מסוימת פופולרית להורדה ללא קשר לשאילתה, לא כדאי להציג אותה בכל מקום. העובדה שאין תכונות שמתאימות למסמכים בלבד עוזרת לשמור על הפשטות. הסיבה לכך שאתם לא רוצים להציג אפליקציה פופולרית ספציפית בכל מקום קשורה לחשיבות של גישה לכל האפליקציות הרצויות. לדוגמה, אם משתמש מחפש 'אפליקציה לצפייה בציפורים', יכול להיות שהוא יוריד את 'Angry Birds', אבל זו בהחלט לא הייתה הכוונה שלו. הצגת אפליקציה כזו עשויה לשפר את שיעור ההורדות, אבל בסופו של דבר המשתמש לא ייהנה ממנה.

כלל מס' 36: הימנעו ממעגלים של משוב עם תכונות מיקום.

המיקום של התוכן משפיע באופן משמעותי על הסבירות שהמשתמש יבצע איתו אינטראקציה. אם תציבו אפליקציה במיקום הראשון, היא תקבל יותר קליקים, ותוכלו להיות בטוחים שיש לה סיכוי גבוה יותר לקבל קליקים. אחת מהדרכים להתמודד עם הבעיה הזו היא להוסיף מאפייני מיקום, כלומר מאפיינים לגבי המיקום של התוכן בדף. אתם מארגנים את המודל באמצעות מאפייני מיקום, והוא לומד לתת משקל גבוה, למשל, למאפיין 'מיקום ראשון'. לכן, המודל נותן משקל נמוך יותר לגורמים אחרים בדוגמאות עם הערך '1st­position=true'. לאחר מכן, בשלב ההצגה לא מקצים למופעים אף מאפיין מיקומי, או מקצים להם את אותו מאפיין ברירת מחדל, כי אתם נותנים ניקוד למועמדים לפני שאתם מחליטים בסדר שבו הם יוצגו.

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

כלל מס' 37: מדידת הטיה של אימון/הצגה.

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

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

שלב שלישי ב-ML: צמיחה איטית, שיפור האופטימיזציה ומודלים מורכבים

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

כלל מס' 38: אל תבזבזו זמן על תכונות חדשות אם הבעיה היא מטרות לא תואמות.

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

כלל מס' 39: החלטות השקה הן חלופה ליעדים ארוכי טווח של המוצר.

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

האמת היא שהעולם האמיתי הוא לא משחק מחשב: אין בו 'נקודות חולשה' שמזהות את בריאות המוצר. הצוות צריך להשתמש בנתונים הסטטיסטיים שהוא אוסף כדי לנסות לחזות בצורה יעילה את רמת הביצועים של המערכת בעתיד. הם צריכים להתייחס למדדים כמו התעניינות, משתמשים פעילים ביום (DAU), משתמשים פעילים ב-30 יום (DAU), הכנסות ותשואה להוצאה של המפרסם. המדדים האלה, שאפשר למדוד בבדיקות A/B, הם רק מדדים משניים ליעדים ארוכי טווח יותר: שביעות רצון של משתמשים, הגדלת מספר המשתמשים, שביעות רצון של שותפים ורווחים. גם המדדים האלה הם רק מדדים משניים ליעדים ארוכי טווח יותר: יצירת מוצר שימושי באיכות גבוהה וחברה משגשגת בעוד 5 שנים.

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

ניסוי משתמשים פעילים ביום הכנסה ליום
A מיליון 1 4 מיליון ש"ח
B 2 מיליון 2 מיליון דולר

אם המערכת הנוכחית היא A, סביר להניח שהצוות לא יעבור ל-B. אם המערכת הנוכחית היא מערכת ב', סביר להניח שהצוות לא יעבור למערכת א'. נראה שהדבר סותר התנהגות רציונלית, אבל יכול להיות שהתחזיות לגבי שינוי המדדים יתגשמו או לא, ולכן יש סיכון גבוה בכל שינוי. כל מדד מכסה סיכון מסוים שהצוות מודאג ממנו.

בנוסף, אף מדד לא עונה על השאלה החשובה ביותר של הצוות: "איפה המוצר שלי יהיה בעוד חמש שנים?"

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

כלל מס' 40: כדאי לשמור על פשטות של אנסמבלים.

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

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

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

הוספתם מידע דמוגרפי מסוים על המשתמש. הוספת מידע על המילים במסמך. ביצעתם ניתוח של התבנית ושיניתם את ההתאמה. לא ראיתם השקה עם שיפור של יותר מ-1% במדדי המפתח שלכם ב-4 רבעונים. מה עכשיו?

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

כלל מס' 42: אל תצפו שהמגוון, ההתאמה האישית או הרלוונטיות יהיו קשורים לפופולריות כמו שאתם חושבים.

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

הבעיה היא שקשה להתחרות בדברים הרגילים.

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

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

כלל מס' 43: בדרך כלל, החברים שלכם זהים במוצרים שונים. תחומי העניין שלכם בדרך כלל לא יהיו כאלה.

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

יש מסמכים רבים בנושא למידת מכונה ב-Google וגם מחוץ ל-Google.

תודות

תודה ל-David Westbrook,‏ Peter Brandt,‏ Samuel Ieong,‏ Chenyu Zhao,‏ Li Wei,‏ Michalis Potamias,‏ Evan Rosen,‏ Barry Rosenberg,‏ Christine Robson,‏ James Pine,‏ Tal Shaked,‏ Tushar Chandra,‏ Mustafa Ispir,‏ Jeremiah Harmsen,‏ Konstantinos Katsiapis,‏ Glen Anderson,‏ Dan Duckworth,‏ Shishir Birmiwal,‏ Gal Elidan,‏ Su Lin Wu,‏ Jaihui Liu,‏ Fernando Pereira ו-Hrishikesh Aradhye על התיקונים, ההצעות והדוגמאות השימושיות הרבות שסייעו לנו לכתוב את המסמך הזה. תודה גם ל-Kristen Lefevre, ל-Suddha Basu ול-Chris Berg שעזרו בגרסה קודמת. כל שגיאה, השמטה או (אוי!) דעה לא פופולרית הן באחריותי.

נספח

במסמך הזה יש מגוון הפניות למוצרי Google. כדי לספק הקשר נוסף, הנה תיאור קצר של הדוגמאות הנפוצות ביותר.

סקירה כללית על YouTube

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

סקירה כללית על Google Play

ב-Google Play יש הרבה מודלים לפתרון מגוון בעיות. אנחנו משתמשים בלמידת מכונה בחיפוש Play, בהמלצות המותאמות אישית בדף הבית של Play ובאפליקציות בקטע 'משתמשים התקינו גם'.

סקירה כללית על Google Plus

ב-Google Plus נעשה שימוש בלמידת מכונה במגוון מצבים: דירוג פוסטים ב'עדכונים' שמוצגים למשתמש, דירוג פוסטים ב'מה הכי חם' (פוסטים שפופולריים מאוד כרגע), דירוג אנשים שאתם מכירים וכו'. כל החשבונות האישיים ב-Google Plus‎ נסגרו ב-2019, וב-6 ביולי 2020 חשבונות העסקים הוחלפו ב-Google Currents.