פיתוח מערכת המלצות למרקטפלייס

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

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

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

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

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

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

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

מה משתנה אחרי ההטמעה: המרה, כיסוי, הזמנות חוזרות

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

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

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

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

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

גישות לבניית הצגה: השוואת אפשרויות

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

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

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

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

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

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

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

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

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

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

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

מה מוסרים לידיים: קונפיגורציות, סכימות זרימות, תקנונים

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

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

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

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

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

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

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

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

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

במה חוקים ומבחרים ידניים שונים ממודלים ניתנים לאימון

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

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

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

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

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

ספקות טכניים: התחלה קרה, תיוג, איכות נתונים

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

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

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

איך בודקים תיוג ואיכות אירועים לפני תחילת העבודה?

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

איך עוקבים אחרי איכות ההצגה אחרי ההשקה?

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

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

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

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

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