פיתוח צ'אטבוט AI למסחר אלקטרוני: RAG וחיפוש סמנטי

צ'אטבוט בינה מלאכותית לחנות מקוונת: היכן החיפוש נשבר

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

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

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

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

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

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

מה נותנים חיפוש סמנטי ועוזר דיאלוגי

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

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

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

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

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

פורמטי פתרון: חיפוש בקטלוג, עוזר, היברידי

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

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

שלבי העבודה: אבחון, סכמה, הגדרה, קבלה

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

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

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

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

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

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

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

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

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

מה מדדנו ומה השתנה

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

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

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

מה לעשות אם צ'אטבוט כבר בנוי על פלטפורמה מוכנה

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

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

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

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

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

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

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

איך העוזר עונה אם המוצר אזל מהמלאי?

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

מאיפה מגיעים מלאי ומחירים עדכניים?

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

איך אתם שולטים באיכות התשובות של העוזר?

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

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

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

מה כדאי להכין ומה ננתח בשיחה:

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

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