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

מדוע מערכת ההמלצות מפסיקה לקלוע לתחומי העניין

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

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

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

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

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

אפקט ההטמעה: צפיות מלאות, נטישה, זמן תגובת ההמלצות

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

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

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

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

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

כיצד נבנית מערכת המלצות: שלושה מצבי עבודה

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

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

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

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

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

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

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

חפצי מסירה: תרשימי זרימות, קונפיגורציות, תקנונים

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

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

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

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

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

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

מה שינו בנתונים ובכללים

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

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

מדדים לפני ואחרי

• צפייה מלאה בפרק הראשון: 41% → 63%
• שיעור הצופים שחזרו בתוך חודש: 28% → 44%
• שיעור הפריטים החדשים בעשרת המקומות הראשונים: 7% → 31%
• חזרות על אותו כותר בהפעלה: 4.1 → 1.3

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

במה שונה סינון שיתופי מסינון תוכן?

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

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

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

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

ספקות טכניים נפוצים: התנעה קרה ואיכות נתונים

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

מה לעשות עם רעש בסימון?

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

האם אפשר לעדכן את המודל בלי לעצור את השירות?

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

למי שייכים המודלים והנתונים?

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

מדוע האוספים נראים אחידים?

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

נדון במשימה ונחזור עם הערכה ותכנית הטמעה

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

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

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