למי זה לא קרה?
נכנסת
הקלטת שם של מוצר וקיבלת תוצאות גרועות,
לא רלוונטיות או
חלקיות
ואז דילגת לגוגל,
הקלטת את אותה שאילתה בדיוק
וגוגל החזיר לך את דף המוצר המדויק לאותו אתר בדיוק.
המוצר קיים כספי מכירה אותו אבל
מנוע החיפוש שלה פשוט
לא עובד.
טוב,
לא חוכמה,
גוגל השקיע בחיפוש יותר כסף דאטה
וכוח מחשוב מכל חברה מסחרית בעולם.
אבל איך אפשר לבנות
חיפוש טוב לאתר בעצמנו?
רוב האתרים מתייחסים לחיפוש כפעולה על טקסט המשתמש כתב מילים,
בואו נחפש את
המילים בתוך רשומות.
גוגל מתייחסת לחיפוש כניסיון לצמצם אי-וודאות.
אדם מסוים בהקשר מסוים
רוצה משהו,
אבל כל מה שיש לנו ממנו הוא כמה מכרוזות קצרות לעיתים לא מדויקות.
מנוע החיפוש צריך לקחת את
הרמזים האלה,
להבין
למה המשתמש התכוון,
למצוא קבוצה רחבה מספיק של אפשרויות,
לצמצם אותה,
לסדר אותה
וללמוד מהתגובה.
וזה בדיוק מה שנלמד בפרק הזה.
חיפוש טוב הוא לא רק אלגוריתם שמוצא תוצאה,
הוא שרשרת של מערכות שכל אחת מהן
מקלפת סוג אחר של אי-וודאות.
יש במערכת הזאת AI כמובן אבל אי אפשר להחליף את
כולה באיי ולסגור עניין
בכל
שלב בשרשרת משהו עופד באלף משהו משתפר ונוצרת בעיה חדשה
ששלב נוסף צריך לפתור אם נבין את השרשרת הזו
נבין למה מנוע החיפוש באתרים כל כך גרוע
ואיך אפשר לדמות אותו לגוגל בלי התקציב של גוגל.
היא הוודאות הראשונה היא השפה.
משתמשים לרוב לא דוברים את שפת הקטלוג.
קטלוג מכיל את השורה קרם לחות היפואלרגני ללא בישום
והמשתמש מחפש קרם פנים שלא יעשה לי אדום.
הקטלוג מכיל את השורה
תקנסיות 40 ליטר והמשתמש מחפש
טרולי שאפשר לעלות לאלה.
בהרבה מקרים
קטלוג מתאר תכונות בעוד משתמש מתאר שימוש,
כאב,
מגבלה
או תוצאה רצויה.
אם כל המשתמשים היו יודעים להקליד נייק איירפורס,
לבנות,
מידה
39,
כנראה שלא היינו צריכים את הפרק הזה,
זו שילטה קלה שיש בה מותג,
דגם צבע ומידה,
נעליים נוחות לטיול בקיץ היא שילטה
הרבה יותר קשה ולא מכילה אפילו
מילה אחת
משם המוצר.
בנוע החיפוש לא יכול רק לאתר טקסט,
הוא צריך לתרגם
בין שני תיאורים שונים של המציאות.
התרגום הזה מתחיל עוד
לפני שהגיעה השאילתה הראשונה,
אם אתן ליעל מחר משימה לבנות
חיפוש עבור מיליון מוצרים,
הצעד הראשון שלה לא יהיה אלגוריתם או מודל ספציפי,
הוא יהיה סכמה.
איך ליצור מבנה טבלאי
ששומר על הקטלוג המקורי אבל מוסיף לצידו כותרת נקייה,
תיאור נקי,
מאפיינים מסודרים.
מותג,
צבע,
חומר,
נפח וקטגוריה
לא יכולים להמשיך להתחבא בתוך
פסקת תיאור מפי היבואן,
צריך לחלץ אותם מהטקסט,
לייבא אותם,
להשאיר אותם.
זה החלק שבו מודל שפה גדול שימושי מאוד דווקא כי הוא
לא פוגש את המשתמש בזמן אמת,
פשוט מריצים העשרה אינרימנט אוף ליין בבצים זולים.
ומבקשים מהמודל לנרמל כותרת,
להשלים
תיאור חסר ולחלץ
attributes לתוך סכמת ג'ייסון קשיחה.
זה יאפשר לו להבין ש-100 מיליליטר ו-0.1 ליטר
מייצגים
אותו נפח ושקרם,
שינה ואופ ווייט
קרובים מספיק כדי להיכנס לאותה פלט הצבעים.
אלה להם יכול גם להמציא,
אז ממש לא כדאי לקבל כל תוצאה שלו כתורה מסיני,
נפח
חייב להיות ביחידות הנכונות,
מותג חייב להגיע מרשימה סגורה
ופלט שאינו עומד בסכמה
נדחה.
לפני שתריצו מיליון מוצרים,
בואו תריצו אלף
ותבדקו אותם הקראית,
אחר כך תוסיפו דגל שעוקב מתי מוצר עבר אינריצ'מנט.
זה לא סתם בירוקרטיה,
זה הדרך שלכם למנוע ממודל שפה לעזות
ולהשאיר את הקטלוג במידע
שלא היה בו מעולם.
לאחר שלב האשרה מתבצע שלב הטבעה או אימבדינג,
כל המידע עובר במודל וקטורי שממקם את המוצר ב-500,000 או 1,500
נקודות במרחב
התוצאה של המודל הזה,
והיא בעיקר מספרים לא מובנים.
צריכה להישמר
בדאטאבייס לצד
המוצר יחד עם גרסת
המודל שהטביע אותו.
אם בחרתם מודל מקומי של 512 מימדים כדי לחסור בזיכרון
ומישהו עם משקפיים מציע לעבור ל-1536 של אופן AI
זה אומר להטביע מחדש
כל מוצר.
אגב,
עבור קטלוג של מיליון מוצרים הפוסטקאסט שלכם
מספיק בהחלט לא צריך אלסטיק סארץ או וקטור דאטאבייס,
לא צריך קווקא,
צריך רק להחליט מאיפה לצרוך את
מודל האמבדינג
וממי.
בשלב ראשון אפשר לקנות אותם.
סיימנו את שלב ההכנות הבסיסי,
יש דאטאבייס של מיליון מוצרים,
שדות חפיסים ווקטורים לצידם,
גזרנו את הסרט והשאילתה הראשונה מגיעה אלינו דרך האתר.
לפני שהיא תגיע לאינדקסים היא זקוקה לניקוי קצר,
lower case,
הסרת רווחים כפולים,
סימני פיסוק ותיקון שגיאות.
שגיאת כתיב יכולה לקלקל את כל השרשרת.
זה
נכון שמשתמש שכתב אדידס עם שלוש דן
יקבל משהו,
אבל אם אפשר לנקות
ולתקן את השאילתה פעם אחת,
היא תישלח
נכון לכל המנגנונים
מבלי שיצטרכו להמציא
פרשנות נפרדת.
שימו לב,
אנחנו לא מחליפים למשתמש
את השאילתה המקורית,
זה יהיה מוזר.
אנחנו משתמשים במתוקנת,
אבל
שומרים את שתיהן כדי לדעת בהמשך
אילו תיקונים עזרו
ומה הפך שאילתה טובה
למשהו אחר.
אבל איך מתקנים של את הפתרון הנאיבי
הוא לעבור על כל המילים במילון ולחשב את
המרחק עריכה בינן
לבין המילה שהמשתמש קטע
מרחק עריכה בדרך כלל לוינשטיין
סופר כמה הכנסות מחיקות החלפת אותיות או סיכול אותיות
נדרשו כדי להפוך מילה אחת
לאחרת
במילון קטן זה עובד במנוע חיפוש שמקבל כמה מאות שאילטות לשנייה.
זה מתחיל להיות יקר.
הפתרון המפורסם של פיטר נורוויג מייצר בזמן
השאילתה את כל המילים האפשרויות במרחק העריכה נתון
ובודק אלו מהן באמת קיימות במילון.
יעיל אבל למילה של 9 אותיות ומרחק 2
אפשר להגיע ל-114,000 מועמדים.
אלגוריתם יעילים יותר מייצרים מחיקות גם מהמילה השגויה ומצמצמים את אותן 9 אותיות
ל-36 מועמדים
בלבד.
הם גם עושים את זה
תרום שאילתה ובעיבוד מוקדם,
בדיוק המקום שאנחנו מעדיפים לשלם בו.
אבל איך יוצרים מילון?
לוקחים אחד ומאבים אותו בעצמנו
מתוך כל המופעים של כל המילים,
מכל המוצרים
מסודרים לפי שכיחות.
אנחנו
סוף סוף מבצעים חיפוש לשוני ראשון,
פעם TFIDFI BN25
אלגוריתמים שמעניקים חשיבות למילים,
לפי התדירות שלהם במסמך,
אבל גם בכלל האוסף.
כרית פלוצים שווה יותר מכרית שינה
והתאמה בכותרת יכולה לקבל משקל גבוה יותר מהתאמה לתיאור.
BM25 לא מבין כוונה,
אבל הוא מצטיין בדברים שחיפוש סמנטי
נוטה לטשטש,
שם,
מותג,
דגם,
מט ובינוחים מדויקים.
אם המשתמש כתב אייפון 17 פרו,
הוא כנראה רוצה אפל מאוד ספציפי ולא טלפון למקצועני.
חיפוש שני יהיה סמנטי.
השאילתה הנקייה עוברת וקטוריזציה בעצמה עם אותו מודל וקטורי שהפעלנו על המוצרים,
תוצאה היא שוב 500,000 או 1,500 ממדים שאפשר למצוא להם
שכנים קרובים.
אם חיפשתי נעליים לעמוד איתן כל היום,
אז מוצרים שיש בהם תיאור של תמיכה,
ריפוד,
נעלי עבודה
יחזרו קודם.
חיפוש סמנטי
לא זקוק לחפיפה מילולית מושלמת.
כי הוא
משווה ייצוגים של
משמעויות או קירובים של מונחים
במרחב,
אבל
זו גם החולשה שלו.
קרבה סמנטית בין כבל,
מטען,
מפצל,
מטעם,
מטען
אינה אומרת שהמוצרים תחליפים.
חיפוש סמנטי יודע להחליק הבדלים,
אבל
ההחלקה הזו לפעמים מגליצ'ה משתמשים
אל מחוץ לאתר.
חיפוש שלישי הוא בתוך ביקורות.
תראו,
המוצר נכתב כדי למכור ביקורת נכתבת אחרי
שימוש,
ולכן
מכילה מידע מסוג אחר.
היצרן נכתוב סוליה ארגונומית,
המשתמש יוסיף,
חרשתי איתה את ליסבון בכיף במשך שלושה ימים.
היצרן נכתוב ניחוח עדין,
המשתמש יוסיף,
אין סיכון לשבת עם הבושם הזה
בקרון סגור.
ושאילתות שעוסקות בחוויה
ולא במפרט ביקורות הן מקור מעולה,
לא מצרפים את כל הביקורות לטקסט אחד ענק ועושים אימבדינג
גם כי אי אפשר במגבלות האורך
וגם כי אנחנו רוצים לשמור לכל ביקורת שני משקלים,
הסנטימנט,
כמה היא חיובית או שלילית
והסורס האם היא מגולש אנונימי,
רוכש מועמד
או אתר שלישי
ולנקד אותם בהתאם.
שלושת החיפושים האלה,
לשוני,
סמנטי וביקורות יכולים לרוץ במקביל ולהחזיר למשל
חמישים תוצאות כל אחד.
בשלב הזה יש ערבוב של מוצרים וביקורות לעתים של אותו מוצר.
בכל מוצר אנחנו רוצים לשמור את
ההתאמה הטובה ביותר
וציון משוקלל של הביקורות שלו.
אבל
עוד משהו מרובף כל
חיפוש חזר עם
סולם ציונים אחר,
ציון BM25 אינו בר השוואה
סימילריטי
ואם
בביקורות השתמשנו במודל אימבדינג אחר
הם יחזרו בהתפלגות שונה.
אפשר להחליט על משקל ידני,
למשל 40% ללשוני,
50% וקטור ו-10% ביקורת,
אבל
זה מצריך חיול מחדש בכל פער.
רסיפוקל רנק פיוז'ן או RRF נמנע מההשוואה הזאת,
הוא מתעלם מהציון הגולמי ומסתכל על
המיקום היחסי של המוצר
בכל אחת
מהרשימות.
מוצר שמדורג שני בשתי רשימות יכול לעקוף מוצר שמדואג ראשון.
ברשימה אחת בלבד.
הסכמה בין מנגנונים שונים
נחשבת חזקה יותר
מביטחון קיצוני
של מנגנון בודד.
התוצאה של הערף עדיין אינה דף תוצאות,
היא דף מועמדים,
נניח
100 מוצרים,
והיא הבחנה חשובה בין רטריבל שליפה לרנקינג,
מיון.
בשליפה אנחנו רוצים רול גבוה,
לוודא שהמוצרים הנכונים
נמצאים איתנו בחדר.
במיון אנחנו רוצים פז גבוה,
להחליט מי יישב בשורה הראשונה.
אבל אם המוצר הנכון הוא נכנס ל-100 מועמדים,
שום מיון
לא יעזור.
אנחנו
בשלושת רבעי הדרך,
המשתמש שאל משהו לפני פחות משנייה,
יש לנו את השאילתה שלו
ו-100 מועמדים פוטנציאליים.
זה הזמן להפעיל מודל רי-רנקר יקר ומדויק יותר.
בניגוד לחיפוש וקטורי שבו השאילתה והמוצר עברו הטבעה בנפרד,
הקרוסנקוד קורא אותם יחד
וממקם את השאילתה
לצד מאה תקצירי מוצר
ומחזיר ציון התאמה נוסף.
הרי רנקר לכל ה-100 מועמדים
מופעל בקריאת API אחת
קובעים גם טאט נניח
800 מילישניות,
אם
לא ענה לא מחזירים שגיאה,
חוזרים אחורה להערף,
אם האימבדינג נפל,
חוזרים אחורה
25
מערכת חיפוש טובה לא צריכה לעבוד בבריאות מניעה,
היא צריכה להישאר שימושית
גם שחלקים ממנה חולי.
הרלוונטיות שהרירנקר מחזיר אינה כלי לשלמות.
מוצר יכול להתאים כמו כפפה לשאילתה אבל
המשתמש כבר הזמין אותו,
יכול
לראות נפלא בטקסט,
אבל
לסבול מהחזרות על ידי רבע הלקוחות.
הוא
יכול להיראות קצת פחות נפלא,
אבל עם דירוג ואחוז המראה מעולה,
זה בדיוק השלב שבו עוברים
מרלוונס
חזרה לרנקינג,
אבל הפעם
מיון שלומד ומשתפר בעצמו.
בגרסה הראשונה אין עדיין דאטה שמצדיק מודל למידה,
אפשר לייצר איזה
בלנד ידני שלוקח דירוג ממוצע,
מכפיל אותו בסנטימנט,
מעלה בריבוע פופולריות,
מחלק בשורש החזרות,
אבל
זה יהיה בלנד שמנחש.
למידה
מתחילה רק כאשר המערכת
שומרת את התוצאות ומנטרת אותם.
בשביל זה צריך להצמיד לכל חיפוש,
מזהה איכותי,
search ID
ולפעפע אותו לכל פעולה.
קליק,
את to car,
checkout,
thumbs up,
thumbs down,
החזרה,
כולם ברמת המוצר הבודד
יישברו יחד עם
ID.
טכני ומייגע אני יודע אבל זה מה שיקבע אם יש לכם סתם אנליטיקס או טרינינג דאטה
אם מוצר נמכר אתם יודעים משהו על המוצר,
אם מוצר שהוצג במקום השישי עבור קרם פנים שלא שורף
נלחץ ונקנע בתוך חצי שעה אתם יודעים משהו
על החלטת החיפוש.
לאחר כמה שבועות של לוגים,
אפשר להתחיל לאמן מודל אג'יבוס,
כל אירוע מקבל משקל,
thumbs down,
למשל הוא שלילי חזק,
גם חזרה,
קליק הוא חיובי
to
to purchase
חיובי חזק.
כשהמודל מוכן,
וזה משהו שאפשר לאמן כל לילה תוך דקות,
אפשר להריץ עליו כל מועמד ולקבל ציון שלומד ומתעדכן
עם כל מידע חדש.
המנוע מוכן,
אפשר לשים אותו מאחורי פיצ'ר פג ולהציג אותו
לעובדים שיבדקו סייד ביי סייד מול המנוע הישן,
זה
שם אתכם כנראה במיון
של מנועי החיפוש לאתרים
בעולם,
אם תרצו להגיע לאלפיון
תצטרכו להוסיף
עוד כמה דברים.
קשינג,
לשמור את התוצאה במתמון,
למשל ברדיס,
זה חוסך לכם את הריטריבל,
את האימבדינג,
אתרינקינג,
אבל לא פותר אתכם.
מאיסוף הדאטה.
ניתור שיהוי עם יעד ל-95% מהשאילטות פחות מ-500 מילישניות מהמטמון או 1,500 מילישניות
לחיפוש קר,
שימו לב,
ליצור היסטוגרמה נפרדת מכל שלב
בתהליך.
ניצול מול גילוי או מיצול מול חיפוש אם נציג תמיד את אותן 20 התוצאות,
מוצרים באזלה וארוכו
שמעולם לא דורגו גבוה,
ימשיכו לנבול ויראו חלשים גם באימון הבא.
אקספוריישן פותר את בעיית הגיפרון,
אפשר ב-5% מהמקרים
להקפיץ תוצאות מהמקומות הנמוכים כדי לתת הזדמנות לאחרים.
וגם פיינט טיונינג לאבנינג מודל,
וזה רק אם המדידה
מראה קשל בריטריבל.
אפשר לבדוק למשל אם עגלת קניות שהושלמה
כללה מוצר שלא היה בה מהמועמדים.
אם המוצר נעדם
שוב ושוב
הייצוג הסמנטי
לא מספיק לדומיין שלכם,
ואפשר לשקול מודל התבעה
מותאם.
זה שינוי יקר יותר מאימון אקס ג'יבוס
כי הוא מחייב אתכם
להפיק מחדש את כל הוקטורים
בקטלוג.
נסכם.
הוספנו רכיבים כי זה שקדם להם לא מסוגל לפתור סוג מסוים
של אי-וודאות.
Enrichment מסדר את המציאות לפני שמחפשים בה.
תיקון שגיאות מסדר את כוונת המשתמש,
חיפוש לשוני שומר על פרטים מילוליים,
חיפוש סמנטי מחבר בין ניסוחים שונים,
ביקורות מוסיפות ניסיון אנושי,
RRF מאחד ציונים בלתי ניתנים להשוואה,
רטריבל מגן על הרירנקר,
מודל אקס שיבוס מחבר רלוונטיות למציאות העסקית,
לוגינג הופך דאטה לבית אימון
ואקספלוריישן
מונע ממך לקבע ההטיות.
עכשיו,
זה גם ברור למה גוגל טובה כל כך,
לא בגלל שיש לה אלגוריתם סודי אחד,
אלא כי היא בנתה.
במשך עשורים,
שרשרת שמצמצמת אי ודאות,
מודדת את עצמה
ולומדת מהאופן
שבו אנשים מגיבים.
רוב האתרים פשוט שם שורת חיפוש כמו בגוגל,
דחו אותה לאינדקס אחד ואז הופתעו שהחיפוש יוצא גרוע.
אתר עם מיליון מוצרים לא צריך להישען על חיפוש בגוגל,
הוא צריך להתייחס לחיפוש כאל מוצר
עם סכמה
ופייפליין,
גרסאות,
שירוי,
פולבק,
ניסויים
ומדדי איכות.
במשך
שנים חיפוש היה הדרך שבה
המשתמש למד את המבנה שהאתר כפל עליו.
הוא היה צריך להכיר את שם הקטגוריה,
את המונח המקצועי,
את הפילטר הנכון,
את העיות שבו בחר היבואן
במדויק.
מערכת חיפוש חדשה
הופכת את היחסים האלה,
המשתמש
לא צריך ללמוד את השפה של הקטלוג,
הקטלוג צריך ללמוד איך המשתמש שלו חושב
ולהסתגל עליו,
אל הרצונות שלו
מדי
יום.
עד הפעם הבאה,
תהיו טובים,
תמשיכו להיות סקרלי.
יאללה,
ביי.