Two-Tower ו-FAISS: מערכת המלצות AI להתאמה אישית

למה הקטלוג לא מוכר: פיתוח מערכת המלצות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מסלול ההטמעה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה הראו המדידות

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

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

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

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

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

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

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

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

בירור ספקות: איכות נתונים, עומס, תמיכה

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

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

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

איך אתם מזהים ירידה באיכות?

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

נוכל לאמן את המודל בעצמנו?

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

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

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

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

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