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

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

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

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

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

טרמינולוגיה

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

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

סקירה כללית

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

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

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

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

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

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

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

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

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

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

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

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

כלל מס' 2: ראשית, תכנן ויישם ערכים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מעקב

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

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

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

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

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

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

כלל מס' 10: היזהר מפני כשלים שקטים.

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

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

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

המטרה הראשונה שלכם

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

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

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

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

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

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

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

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

תחילה, יש להימנע מיצירת מודלים של השפעות עקיפות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כלל מס' 16: תכנון השקה ואיטרציה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הסטה להגשה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כלל מס' 40: יצירת הרכבים פשוטים.

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

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

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

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

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

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

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

הבעיה היא שקשה לנצח את הרגיל.

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

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

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

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

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

אישורים

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

נספח

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

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

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

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

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

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

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