שיקולים נוספים ובדיקות

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

הטמעה של שיטות מומלצות

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

• עקביות של מזהה המבקר: עוזרת לוודא שמזהה visitor_id ייחודי נשלח באופן עקבי עם כל בקשה של משתמש קצה נתון. המידע הזה חיוני להתאמה אישית מדויקת ולאימון המודל. המזהה הזה צריך להיות עקבי עבור משתמש קצה מסוים לאורך סשנים ומצבי התחברות או יציאה מהחשבון.
• ניהול סניפים: למרות שהערך default_branch נפוץ, אם קטלוג המוצרים שלכם מובנה עם כמה סניפים, חשוב לוודא שאתם משתמשים במזהה הסניף הנכון.
• אינטראקציה עם Search API: כשמקבלים את SIMPLE_PRODUCT_SEARCH או בכל מקרה שבו מופיע refined_search, צריך לשלוח קריאה נפרדת ל-Search API הראשי (SearchService.Search) באמצעות query מהשדה refined_search או השאילתה המקורית כדי לקבל את כרטיסי המוצר בפועל. ה-API לשיחות מתמקד בעיקר בממשק צ'אט עם AI ובהבנת כוונת המשתמש (Intent), ולא בהחזרת תוצאות של מוצרים באופן ישיר.
• עיצוב ממשק משתמש: עיצוב ממשק האינטרנט כך שאפשרויות conversational_text_response, followup_question ו-refined_search יוצגו בצורה ברורה ואינטואיטיבית כדי להנחות את המשתמש.

הגדרת מאפיינים ליצירה של LLM

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

אם מאפיין מסוים הוא ניתן לאינדוקס אבל לא ניתן לאחזור, הסוכן הדיגיטלי ימצא את המוצר אבל לא יוכל לקרוא את הפרטים כדי לענות על שאלות של משתמשים. הסוכן הדיגיטלי מפעיל לעיתים קרובות תגובת חזרה למצב הקודם, כמו Sorry, we don't have that product (מצטערים, אין לנו את המוצר הזה).

לכן, כדאי להגדיר את המאפיינים הסמנטיים (Title, ‏ Description, ‏ Brand, ‏ Specs) לערך Retrievable: True כדי שה-LLM יוכל להשתמש בהם. אם נדרשים מאפיינים של ממשק המשתמש או האפליקציה (BrandID, SkuID) כדי להציג את הקצה הקדמי, צריך להגדיר את הערך שלהם כ-Retrievable: True. כדי לבצע אופטימיזציה של השימוש בחלון ההקשר, מגדירים את המטא-נתונים של ה-Backend לערך Retrievable: False.

תכנון בדיקות A/B

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

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

רשימת משימות לבדיקת מוּכנוּת ל-A/B

אלה המדדים להצלחה שבהם השתמשנו:

הכנסה לכל ביקור (RPV)

שיעור המרה (CVR)

אירועים מסוג add_to_cart

שיעור הקליקים

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

הטמעה של הוכחת היתכנות או מוצר בר-קיימא מינימלי

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

דוגמה לקצב של ניסוי

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

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

רכיבים של ניסוי מוצלח

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

תפקידים ובעלות על ניסויים

	Google	את/ה
הערכת איכות	תוצאות חיפוש מסחריות	השפעה על חוויית המשתמש
מדידות	גיבוי/אימות	סמכותי
טלמטריה/נתונים	מדדים של נפח הפלטפורמה (אימות הביצועים) אנומליות באירועים ובאינדקס	טוקנים של שיוך ושלבים לשחזור (אימות בעיות)
פלטפורמת החיפוש	פריטים ברמת המוצר מיפוי נתונים התאמות במודל או באימון חריגות באיכות או בהצגה מכסות או מגבלות בפלטפורמה תקלות במוצר או בספריית לקוח	Query/serving items הגדלת הבקשה (כולל ניתוב לפי הקשר, העברה למטמון ועיבוד כוונות) הגדרות הצגה (שיפור) העשרת נתוני המקור ביצועים של לקוח (לדוגמה, שרשורי WC) פגמים בממשק המשתמש, ב-API, בפלטפורמה או בספרייה
Go or No-go	המלץ	אישור

עריכת ניסויים ב-Console

1. נכנסים לדף Experiments במסוף AI Commerce Search ב-Gemini Enterprise for Customer Experience.
   
   מעבר לדף 'ניסויים'

2. אפשר להשתמש במסוף כדי לבצע ניתוח מתקדם בשירות עצמי לצורך הטמעה של AI Commerce Search ובדיקות A/B, על ידי יישום מתודולוגיית השיוך של Google:

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

• החלת מדדים ברמת הביקור לכל חיפוש על חיפוש מילות מפתח ועל גלישה.

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

• שימוש בפלטפורמת Looker המוטמעת.