סוכן AI לשירות לקוחות - איך בונים אחד שלא ממציא תשובות
סוכן שירות שעונה מהר ובטוח בעצמו זה קל לבנות. סוכן שיודע מתי הוא לא יודע זה החלק הקשה. כאן נסביר איך נראית ארכיטקטורה שמצמצמת המצאות, איפה חייב להישאר אדם, ואיפה כלל פשוט מנצח מודל.
כמעט כל לקוח שפונה אלינו בנושא סוכן שירות מגיע אחרי שהוא כבר ניסה משהו. בדרך כלל זה היה כלי מוכן שחיברו אליו את האתר, והוא ענה יפה בהתחלה ואז אמר ללקוח משהו שלא נכון. לפעמים זה היה זמן אספקה, לפעמים מדיניות החזרות, ופעם אחת אצל לקוח שלנו זה היה מחיר שלא היה קיים מעולם.
המקרה האחרון מלמד את השיעור החשוב. הסוכן לא היה שבור. הוא עשה בדיוק את מה שמודל שפה עושה, כלומר הפיק תשובה סבירה בהינתן ההקשר. הבעיה הייתה שההקשר לא הכיל את המחיר, והמערכת לא נבנתה כדי לומר אני לא יודע.
מה סוכן שירות באמת עושה
כדאי לפרק את זה, כי המילה סוכן מכסה כמה דברים שונים מאוד ברמת הסיכון.
| סוג פעולה | דוגמה | רמת סיכון | מי מחליט |
|---|---|---|---|
| מענה מתוך מסמכים | מה מדיניות ההחזרות | נמוכה | סוכן, עם ציטוט |
| שליפת נתון אישי | איפה ההזמנה שלי | נמוכה עד בינונית | סוכן, אחרי אימות זהות |
| איסוף פרטים | פתיחת פנייה חדשה | נמוכה | סוכן |
| ניתוב | העברה לאיש המכירות הנכון | נמוכה | סוכן |
| התחייבות עסקית | הבטחת מועד אספקה או הנחה | גבוהה | אדם בלבד |
| פעולה שמשנה מצב | ביטול, זיכוי, שינוי הזמנה | גבוהה | אדם, או סוכן עם תקרה |
| טיפול בתלונה | לקוח כועס | גבוהה | אדם |
ארבע השורות הראשונות הן איפה שהערך נמצא, והן גם איפה שהסיכון נמוך. עסק שמגביל את הסוכן לשם מקבל רוב התועלת עם מעט מאוד חשיפה. הפיתוי הוא להרחיב, וזה בדיוק מה שהופך פרויקטים מוצלחים לכאב ראש.
למה מודל ממציא, ולמה זו לא תקלה
מודל שפה מייצר את ההמשך הסביר ביותר לטקסט. הוא לא שולף עובדות ממאגר, הוא מייצר טקסט. כשהמידע הנכון נמצא בהקשר, התשובה הסבירה ביותר היא בדרך כלל גם הנכונה. כשהמידע חסר, המודל עדיין מייצר משהו סביר, וסביר לא אומר נכון.
זה חשוב כי זה קובע את כיוון הפתרון. אי אפשר לתקן את זה על ידי בקשה מנומסת בהוראות. אפשר לצמצם את זה משמעותית על ידי שינוי הארכיטקטורה: לוודא שהמידע הרלוונטי אכן נמצא בהקשר, ולתת למערכת מסלול לגיטימי להיכשל.
השאלה הנכונה היא לא איך נמנע מהמודל לטעות. היא מה קורה כשהוא טועה, ומי משלם על זה.
ארכיטקטורה שמצמצמת המצאות
אלה השכבות שאנחנו בונים, לפי סדר החשיבות שלהן.
תשובה מבוססת מקור בלבד
הסוכן לא עונה מהידע הכללי שלו. בכל פנייה, המערכת שולפת קטעים רלוונטיים מהמסמכים של העסק והמודל מנסח תשובה רק מהם. אם השליפה לא החזירה משהו רלוונטי, הסוכן אומר שאין לו את המידע. זה משנה את התנהגות המערכת יותר מכל הוראה בהנחיות.
ציטוט פנימי לכל טענה
לכל תשובה מצורף מזהה של המקור, גם אם הלקוח לא רואה אותו. זה מאפשר לבדוק אחר כך מאיפה הגיעה טענה, וזה גם מאפשר בדיקה אוטומטית, כי תשובה בלי מקור מסומנת כחשודה.
רשימת נושאים אסורים
רשימה מפורשת של נושאים שהסוכן לא נוגע בהם: מחירים לא סטנדרטיים, מועדי אספקה מחייבים, ייעוץ משפטי, ייעוץ רפואי, וכל דבר שקשור לתלונה או לפיצוי. זיהוי נושא כזה מפעיל העברה לאדם באופן קשיח, לפני שהמודל בכלל מנסח.
בדיקת עובדות אחרי הניסוח
כשמדובר בנתונים מספריים כמו מחיר, תאריך או מספר, אנחנו בודקים אחרי הניסוח שהמספר בתשובה אכן מופיע במקור. זה תופס חלק ניכר מהמקרים שבהם מודל מעגל מספר או מצרף שני נתונים.
טונציה מרוסנת
פרט קטן עם השפעה גדולה: אנחנו מכווננים את הסוכן להיות ענייני ולא נלהב. סוכן שכותב בטון בטוח מדי גורם ללקוחות להאמין גם לתשובות שגויות. סוכן שמסייג לפי המידע שיש לי מייצר ציפייה מדויקת יותר.
איפה אדם חייב להישאר
אנחנו מגדירים את זה מראש ובכתב, כי זה נוטה להישחק עם הזמן כשהסוכן עובד טוב.
- כל פנייה שמכילה סימני מצוקה, כעס או איום. גם אם הסוכן יודע את התשובה.
- כל דבר שמערב כסף מעבר לסכום שהוגדר.
- פנייה שהסוכן לא הצליח לפתור בשני סבבים. אין טעם בסבב שלישי.
- לקוח שמבקש במפורש לדבר עם אדם. תמיד, ובלי משא ומתן.
- נושאים רגולטוריים או משפטיים.
- כל מקרה שבו מנגנון בדיקת המקורות סימן חוסר ודאות.
ההעברה עצמה צריכה להיות חלקה. הכשל הנפוץ הוא שהסוכן מעביר לאדם והלקוח נדרש לחזור על כל הסיפור. במקרה כזה עדיף שלא היה סוכן מלכתחילה. התמלול המלא צריך לעבור עם הפנייה.
מתי כלל פשוט מנצח מודל
זה חלק שאנחנו אומרים ללקוחות גם כשזה מקטין את הפרויקט. יש הרבה מקרים שבהם מודל שפה הוא הכלי הלא נכון.
- שאלה עם תשובה אחת קבועה, כמו שעות פתיחה או כתובת. תבנית תשובה קבועה מדויקת יותר, זולה יותר ומהירה יותר.
- בדיקת סטטוס - שאילתה למסד נתונים, לא ניסוח חופשי.
- ניתוב לפי מילת מפתח ברורה. כלל פשוט יעבוד תמיד ולא ישתנה מגרסה לגרסה.
- טפסים. אם צריך לאסוף חמישה שדות, טופס מובנה מהיר יותר לכולם.
- כל תהליך שחייב להיות זהה בכל פעם מסיבות רגולטוריות.
אצל אחד הלקוחות שלנו, אחרי שמיפינו את הפניות, התברר ששישים אחוז מהן היו ארבע שאלות. בנינו להן תשובות קבועות ונשארנו עם סוכן שמטפל בשאר. זה עלה פחות, עבד טוב יותר, והתחזוקה שלו זניחה.
מה קורה כשהמידע בעסק משתנה
התקלה שאנחנו רואים הכי הרבה בחודש השלישי היא לא הזיה. היא תשובה נכונה למידע ישן. מחיר עודכן, מדיניות השתנתה, מוצר הופסק - והסוכן ממשיך לענות לפי המסמך שהוזן לפני חצי שנה. זו תקלה מסוכנת יותר מהמצאה, כי אין בה שום סימן חיצוני. התשובה מבוססת מקור, מנוסחת היטב, ופשוט לא נכונה.
שלושה דברים שמצמצמים את זה. הראשון הוא חיבור למקור החי במקום העתקה: מחירים ומלאי נשלפים מהמערכת בזמן אמת, לא מתוך מסמך. השני הוא תאריך תוקף לכל מסמך בבסיס הידע, עם התראה כשהוא עובר. השלישי הוא נוהל פשוט בעסק שאומר שכל שינוי מדיניות מעדכן גם את המסמך המקורי, ולא רק את מי שיושב בחדר.
הנקודה השלישית היא ארגונית ולא טכנית, וזו בדיוק הסיבה שהיא נשברת ראשונה. אנחנו מבקשים מלקוחות להגדיר אדם אחד שאחראי על תוכן בסיס הידע לפני שאנחנו מעלים סוכן לאוויר. בלי זה, איכות המערכת יורדת בקצב שבו העסק משתנה.
מדידה ועלויות
| מדד | מה מודדים | למה זה חשוב |
|---|---|---|
| שיעור פתרון עצמאי | פניות שנסגרו בלי אדם | המדד המרכזי לערך |
| שיעור העברה לאדם | כמה עברו והאם מוצדק | העברה גבוהה מדי או נמוכה מדי, שתיהן בעיה |
| שיעור תשובות בלי מקור | תשובות שלא נשענו על מסמך | אינדיקטור מוקדם להמצאות |
| דירוג שביעות רצון | משוב אחרי שיחה | תופס בעיות שהמספרים מחמיצים |
| בדיקה ידנית מדגמית | 20 עד 30 שיחות בשבוע בקריאה אנושית | אין תחליף לזה |
הבדיקה הידנית היא לא זמנית. אנחנו ממשיכים איתה גם אחרי חודשים, כי המידע בעסק משתנה והסוכן לא יודע שהוא התיישן. עלות התפעול של מודל לעסק בינוני היא בדרך כלל 150 עד 600 שקל בחודש, נמוכה בהרבה ממה שאנשים מצפים. העלות האמיתית היא בבנייה ובתחזוקה, שנעה בין 15,000 ל־45,000 שקל לפרויקט ראשון ועוד ליווי חודשי.
ואם אחרי המיפוי מתברר שרוב הפניות שלכם ייחודיות ודורשות שיקול דעת, נגיד לכם שסוכן לא יעזור כאן. עדיף שנאמר את זה בפגישה הראשונה מאשר אחרי שלושה חודשים.
שאלות שחוזרות
- האם אפשר להגיע לאפס המצאות?
- לא, ומי שמבטיח את זה לא בנה מספיק מערכות כאלה. מה שאפשר זה להוריד את השיעור לרמה נמוכה מאוד ולהגביל את הנזק: לוודא שהסוכן לא מתחייב בשם העסק, שכל תשובה מבוססת מקור, ושכל נושא רגיש עובר לאדם. הכלי הוא ניהול סיכון, לא ביטול שלו.
- כמה מהפניות סוכן טוב באמת סוגר?
- בעסקים שאנחנו עובדים איתם, סוכן שמוגבל נכון סוגר בין 35 ל־65 אחוז מהפניות הנכנסות. הטווח תלוי בעיקר בכמה מהפניות הן שאלות חוזרות ומתועדות. עסק שרוב הפניות אליו ייחודיות יראה מספר נמוך בהרבה, וזה בסדר.
- מה עדיף, סוכן AI או שאלות נפוצות טובות?
- אם המידע שלכם קטן ויציב, דף שאלות נפוצות מסודר וחיפוש טוב יפתרו חלק גדול מהבעיה בעלות אפס. סוכן מצדיק את עצמו כשהמידע גדול, מפוזר בין מקורות, או כשהלקוחות שואלים באופן שלא תואם את המבנה של המסמכים.
- האם הסוכן יכול לבצע פעולות ולא רק לענות?
- כן, וזה מקום שדורש זהירות. פעולות קריאה כמו בדיקת סטטוס הזמנה או שליפת חשבונית בטוחות יחסית. פעולות שמשנות מצב, כמו ביטול או זיכוי, צריכות אישור אנושי או לפחות מגבלת סכום קשיחה.
- כמה זמן לוקח לבנות?
- גרסה ראשונה שמכסה את חמש עשרה השאלות הנפוצות לוקחת שלושה עד חמישה שבועות. מזה, החלק הגדול הוא לא בנייה אלא ארגון החומר הקיים. עסקים שמגיעים עם תיעוד מסודר מתקדמים מהר בהרבה.