פיתוח מערכת בינה מלאכותית לחיפוש שיחתי עם הבנה הקשרית

מדוע חיפוש שיחתי נשבר על שאילתות אמיתיות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מצבי חיפוש שיחתי ומתי הם מתאימים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה שינינו

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

מטריקות לפני ואחרי

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

במה הבנה הקשרית שונה מהחלפת היסטוריה

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

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

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

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

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

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

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

איך מוגבלות השערות ואיך נשלטים המקורות?

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

האם עובד יראה מסמכים שאין לו גישה אליהם?

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

האם נוכל להמשיך לאמן את המערכת בעצמנו?

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

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

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

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

מה אנחנו צריכים מכם כדי להעריך:

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

מה נחזיר בתשובה:

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

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