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

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

מרטין זינקביץ'

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

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

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

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

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

סקירה כללית

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

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

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

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

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

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

המסמך מסודר כך:

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

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

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

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

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

כלל מס' 2: קודם כל, מתכננים ומטמיעים מדדים.

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

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

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

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

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

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

שלב 1 של למידת מכונה: צינור עיבוד הנתונים הראשון

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

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

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

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

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

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

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

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

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

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

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

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

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

כלל 7: הפכו את היוריסטיקה לתכונות או לטפל בהן באופן חיצוני.

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

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

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

מעקב

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

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

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

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

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

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

כלל מס' 10: שימו לב לכשלונות שקטים.

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

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

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

היעד הראשון שלכם

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

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

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

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

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

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

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

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

הימנעו בהתחלה של בניית מודלים של השפעות עקיפות:

  • האם המשתמש ביקר באתר למחרת?
  • במשך כמה זמן המשתמש ביקר באתר?
  • מה היו המשתמשים הפעילים ביום (DAU)?

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

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

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

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

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

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

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

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

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

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

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

שלב 2 של למידת מכונה: הנדסת פיצ'רים (feature engineering)

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

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

כלל מס' 16: מתכננים להשיק אותו שוב ושוב.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בסוף, משתמשים כלל מס' 28 כדי להחליט באילו תכונות להשתמש.

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

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

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

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

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

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

כלל מס' 23: אתם לא משתמשי קצה טיפוסיים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הטיה להגשה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כלל מס' 40: הקפידו על שילובים פשוטים.

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

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

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

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

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

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

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

הבעיה היא שבדרך כלל קשה לעקוף את הרגיל.

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

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

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

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

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

אישורים

תודה דייוויד ווסטברוק, פיט ברנדט, סמואל יאונג, צ'ניו ז'או, לי וויי, Michalis Potamias, Evan Rosen, בארי רוזנברג, כריסטין רובסון (James Pine), ג'יימס פיין (James Pine) טל שקד, טושר צ'אנדרה, מוסטפא איספיר, ג'רמיה הארסן, קונסטנטינוס Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Linux וו, ג'איהואי ליו, פרננדו פריירה והרישיקש ארדהה, לביצוע תיקונים רבים, ודוגמאות מועילות עבור המסמך הזה. וגם, תודה ל-Kristen לפבר, סודהה באסו וכריס ברג שעזרו להם ליצור גרסה קודמת. כלשהו השמטות, השמטות או דעות לא פופולריות הן שלי.

נספח

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

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

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

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

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

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

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