שיטות מומלצות כלליות לעיצוב סוכנים

במדריך הזה מפורטות שיטות מומלצות כלליות לתכנון של כל סוגי הנציגים.

מומלץ גם לעיין במדריך עיצוב נציג קולי, שמיועד ספציפית לעיצוב נציגים קוליים, ובמדריך שיטות מומלצות לשימוש בשירות Dialogflow CX.

ייעוץ כללי

פיתוח סוכנים באופן איטרטיבי

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

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

סוכנים מוכנים מראש

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

שילובים וקישור השירותים שלכם

יש כמה דרכים לשלב סוכנים של Dialogflow CX. בקטע הזה מפורטות שיטות מומלצות לבחירת שיטת השילוב.

שילובים

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

Dialogflow CX API

אם אף אחד מהשילובים המוכנים לשימוש לא מתאים, או אם אתם רוצים להתאים אישית את הממשק למערכת שלכם, אתם יכולים להשתמש ישירות ב-Dialogflow CX API. בגישה הזו, תצטרכו להטמיע את ממשק המשתמש של הנציג או להשתמש בממשק משתמש קיים.

תגובות לפעולה מאתר אחר (webhook)

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

מקורות מידע לנציגים

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

תהליכים ודפים

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

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

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

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

• מה היתרה בחשבון העו"ש שלי?
• קבלת היתרה בחשבון החיסכון
• קבלת היתרה של המשכנתה
• קבלת יתרת הזכות

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

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

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

1. נציגים (נציג אחד מטפל בכל השיחות)
2. תהליכים (תהליך אחד מטפל בנושא שיחה אחד או יותר)
3. דפים (דף אחד מטפל בחלק אחד או יותר של שיחה קשורה)
4. נתיבים (נתיב אחד מטפל בכוונת המשתמש או בבדיקת תנאי)

פרמטרים של Intent לעומת פרמטרים של טופס

הדרך העיקרית שבה המערכת מקבלת נתונים מובְנים ממשתמש הקצה היא באמצעות פרמטרים. אפשר להשתמש בפרמטרים של כוונה (intent parameters) או של דפים (form parameters).

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

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

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

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

מסלולים וקבוצות של מסלולים

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

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

שימוש חוזר בכוונות

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

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

• כן
• כן
• אכן
• אוקיי
• כן, יש לי
• בטח
• בהחלט
• כן בבקשה

כוונה מסוג confirmation.no יכולה לכלול ביטויי אימון כמו:

• לא
• לא
• לא
• אין מצב
• לא בשבילי
• absolutely not
• לא, תודה

אפשר להשתמש בכוונות האלה לאישור חוזר בתרחישים רבים של הנציג.

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

• הסדר נראה לי טוב
• אני מאשר/ת את ההזמנה הזו

וגם כוונה מיוחדת של order.confirmation.no עם ביטויי אימון כמו:

• אני לא רוצה את ההזמנה הזו
• אני לא מאשר/ת את ההזמנה הזו

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

כוונה שלילית שמוגדרת כברירת מחדל

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

מילוי בקשות

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

• מילוי בקשה בכניסה לדף: מילוי הבקשה הזה נקרא כשהדף הופך לפעיל בהתחלה. הוא שימושי כשרוצים להוסיף הודעה שמתארת את מטרת הדף, וצריך להשמיע אותה רק פעם אחת כשהדף פעיל. לדוגמה:
  • מה היית רוצה לדעת על חשבון העו"ש שלך?
  • איזה סוג מוצר ברצונך לרכוש?
  • אני צריך לאסוף קצת מידע על החולצה שאתה רוצה להזמין.
• מסלולים: המילוי הזה נקרא כשנקרא מסלול כוונה או מסלול תנאי עם מילוי. האפשרות הזו שימושית כשרוצים שהודעה תגיב למשתמש הקצה לגבי ההתאמה ל-intent, התנאי שהתקיים (שיכול להיות תנאי להשלמת מילוי טופס) או המעבר. לדוגמה:
  • כן, התוכנית הבינלאומית שלכם כוללת את יפן. (התאמה לפי כוונה)
  • בטוח שאתה רוצה לקנות 300 חולצות? (תנאי ההשוואה מתקיים)
  • בסדר, הפגישה שלך נקבעה למחר ב-7:00 בבוקר. (השלמת מילוי הטופס)
  • אוקיי, בואו נדבר עכשיו על שנבובים. (מעבר)
• גורמים מטפלים באירועים: המילוי הזה נקרא כשמופעל אירוע. היא שימושית כשרוצים הודעה שמגיבה לאירוע. לדוגמה:
  • המניה שאתם שוקלים לקנות עלתה ב-10%. (אירוע מותאם אישית)
  • אפשר לנסח את זה אחרת? (אירוע ללא התאמה)
• הנחיות ראשוניות לטפסים: ה-fulfillment הזה נקרא כשהנציג ממלא טופס. ההודעות האלה צריכות להציג למשתמש הקצה שאלה ספציפית. לכל פרמטר של טופס יש מילוי הנחיה ראשוני משלו. לדוגמה:
  • איזו מידת חולצה היית רוצה?
  • איזה צבע חולצה היית רוצה?
• רכיבי handler של בקשות חוזרות לטפסים: המילוי הזה נקרא כשהנציג ממלא טופס, והוא לא מבין את הבחירה של משתמש הקצה בפרמטר הנוכחי. ה-fulfillment הזה נדרש רק אם רוצים שהודעת הבקשה החוזרת תהיה שונה מהודעת הבקשה הראשונית. אם אין handlers של בקשות חוזרות, הנציג ישתמש בהנחיה הראשונית כהודעת הבקשה החוזרת. לדוגמה:
  • לא הבנתי. אפשר לקבל צבע תקין לחולצה?

מתן שמות

בקטע הזה מופיעות עצות למתן שמות למשאבי הנציג.

מתן שמות לכוונות

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

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

• phone-service.order.cancel
• phone-service.order.create
• phone-service.order.change
• tv-service.order.cancel
• tv-service.order.create
• tv-service.order.change
• account.balance.get
• account.balance.pay
• account.address.get
• account.address.update

מעברים

מעברים שמוגדרים ב-state handlers מאפשרים לשלוט בשיחה על ידי שינוי הדף הפעיל. בקטע הזה אנחנו נותנים עצות לארגון המעברים בין הנציגים.

מעברים משלימים

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

לדוגמה:

• אם יש לכם נתיב כוונה ל-confirmation.yes, כדאי להגדיר נתיב נוסף ל-confirmation.no.
• אם מגדירים נתיב תנאי עם אופרטור בוליאני =, כדאי להגדיר נתיב נוסף שמשתמש ב-!=.

טיפול בקלט של משתמשי קצה

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

הגדירו לפחות 20 ביטויי אימון

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

שימו לב להטיה בכוונת הרכישה

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

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

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

ביטויי אימון של כוונה א'	ביטויי אימון של כוונה ב'	הטיה לכוונה ב'
20	50	לא
20	200	גבולי
20	2000	כן

שימוש בישויות וכמות ביטויי האימון

לכל סוגי הישויות שמשתמשים בהם בכוונה:

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

ביטויי האימון צריכים להיות טבעיים

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

מגוון ביטויי אימון נחוצים

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

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

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

מגוון אותיות רישיות

הרגישות לאותיות רישיות משתנה בהתאם למודל ה-NLU שבו הנציג משתמש.

‫NLU רגיל

מודל ה-NLU הרגיל לא תלוי אותיות רישיות (case-sensitive). במקרים נדירים, יכול להיות שתצטרכו להוסיף ביטויי אימון שונים רק באותיות רישיות. בדרך כלל זה קורה כשמצפים ממשתמשי הקצה להזין טקסט באותיות רישיות בלבד.

גישות חלופיות יכולות להיות:

• הורדת סף הסיווג של למידת המכונה
• המרת הקלט של משתמשי הקצה לאותיות קטנות לפני השליחה ל-Dialogflow CX.

‫NLU מתקדם

בניגוד למודל ה-NLU הרגיל, מודל ה-NLU המתקדם תלוי אותיות רישיות. מומלץ לבדוק ולהוסיף את נתוני האימון הרלוונטיים עם אותיות רישיות כדי להגדיל את שיעורי ההתאמה של הכוונה.

מגוון מיותר של ביטויי אימון

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

• אותיות רישיות: אם אתם משתמשים במודל ה-NLU הרגיל, אל תשתמשו בביטויים כפולים כמו "Order a ticket" ו-"order a ticket", אלא במקרים נדירים. עם זאת, מודל ה-NLU המתקדם תלוי אותיות רישיות (case-sensitive) ודורש יותר ביטויי אימון כדי להגדיל את ההתאמות לכוונות. פרטים נוספים זמינים בקטע מגוון אותיות רישיות.
• מילות קישור: לדוגמה, "אוקיי, תזמין כרטיס" ו "תזמין כרטיס".
• סימני פיסוק: לדוגמה, "אפשר עזרה בבקשה?" ו "אפשר עזרה בבקשה!?"

עקביות ההערות

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

לדוגמה, בטבלה הבאה מוצגות דרכים טובות ורעות להוסיף הערות באמצעות הישות של המערכת @sys.date:

טוב	גרועה
יציאה ב-7 בספטמבר	יציאה ב-7 בספטמבר
יציאה ב-4 ביולי	יציאה ב-4 ביולי

שימוש בהערות בעלות משמעות סמנטית לישויות מערכת

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

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

המודלים של למידת המכונה ב-Dialogflow CX מתייחסים למשמעות הסמנטית כשהם מתאימים ישויות מערכת. המשמעות הסמנטית של החלק בביטוי לאימון חייבת להתאים למשמעות הסמנטית המיועדת של ישות המערכת.

לדוגמה, אל תשתמשו בישות המערכת @sys.duration כדי להוסיף הערה לדוגמה הראשונה של "7 years" שלמעלה. המשמעות הסמנטית של "7 שנים" לא תואמת למשך זמן פשוט. במקום זאת, צריך לבחור את הערך "7" להערה ולהשתמש בישות המערכת @sys.number.

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

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

הימנעו משימוש ב-‎ @sys.any

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

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

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

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

ההערות צריכות לכלול מגוון ערכים של ישויות

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

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

ישויות בהתאמה אישית צריכות לכלול מגוון

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

הימנעות מישויות שמתאימות באופן אגרסיבי

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

ישויות של מפה ורשימה צריכות להתמקד בערכים נפרדים

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

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

• "איך אפשר לבצע שיחה בינלאומית עם תוכנית א'?"
• "שימוש בנדידת נתונים בינלאומית עם תוכנית ב'".

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

סוג הישות של הפעולות	סוג הישות של התוכניות
"איך אפשר לבצע שיחה בינלאומית"	"תוכנית א'"
"שימוש בנדידת נתונים בינלאומית"	"תוכנית ב'"

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

שימוש בישויות של ביטויים רגולריים כדי לתעד מזהים שהם לא מילים

כשמתעדים קלט של משתמשי קצה שכולל מזהים שהם לא מילים, צריך להשתמש בישויות של ביטויים רגולריים. לדוגמה, כדי לתעד מזהי מוצרים כמו "AA-256" או "AC-436", משתמשים בישות של ביטוי רגולרי כמו "‎[A-Z]{2}-\d{3}‎".

הימנעו מהטמעה של ישויות מורכבות

אל תשתמשו ביותר מרמה אחת של הטמעה בישויות מורכבות. כל רמה של הטמעה פוגעת באופן משמעותי באיכות.

הימנעו מכוונות דומות

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

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

הימנעו מסוגי ישויות דומים

כדאי להימנע מהגדרה של כמה סוגי ישויות עם רשומות דומות, כי זה עלול לגרום לבלבול במודל ה-NLU.

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

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

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

אל תשתמשו בתווים מיוחדים

המערכת מתעלמת מתווים מיוחדים בביטויי אימון ({,‏ _,‏ #,‏ [ וכו'). החריג היחיד הוא אמוטיקונים, שפועלים כמו שצריך.

הימנעו ממילים מיותרות

מילים ריקות הן מילים שאפשר להתעלם מהן ועדיין להבין את הטקסט. לדוגמה:

• אנא
• אפשר בבקשה
• המממ
• מה דעתך על

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

אל תגדירו ישויות שמורכבות ממילים מיותרות.

התנסות בהגדרות של למידת מכונה

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

מענה למשתמש הקצה

בקטע הזה מוסבר איך להשתמש במילוי בקשות כדי להשיב למשתמש הקצה.

ברכת שלום למשתמש הקצה

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

אישור המידע של משתמשי הקצה

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

כשיש התאמה ל-intent ומתרחש מעבר, כדאי להודיע למשתמש הקצה שהשיחה מתקדמת על סמך הבקשה שלו. לדוגמה:

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

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

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

הנחיית השיחה

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

• יש עוד משהו שאוכל לעזור בו?
• מה אתם רוצים לדעת על ביגלים?
• לבטל או לשלוח את ההזמנה?
• איך אוכל לעזור לך?
• אתם נוסעים לבד או עם מישהו?

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

• אתה עדיין כאן? לגבי איזה שירות ברצונך לברר?
• רוצה להמשיך בהזמנה? רוצה להוסיף משהו?

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

טיפול בשגיאות ובקלט לא צפוי של משתמשי קצה

בקטע הזה מוסבר איך לטפל בשגיאות ובקלט לא צפוי של משתמשי קצה.

יצירת גורמים מטפלים באירועים מובנים

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

טיפול בשגיאות ב-webhook

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

• אל תספקו יעד מעבר מה-state handler שמפעיל את הקריאה ל-webhook, אחרת גורם מטפל באירועים של השגיאה ב-webhook לא יופעל. במקום זאת, צריך להגדיר את יעד המעבר בתגובה של ה-webhook משירות ה-webhook.

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

  פרמטר	ערך
  webhook-error-count	0

• יוצרים דף שגיאה של webhook שמטפל באירועי שגיאה של webhook:

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

    פרמטר	ערך
    webhook-error-count	$sys.func.ADD($session.params.webhook-error-count, 1)

  • מגדירים נתיב תנאי עם תנאי שמספר השגיאות קטן מהמספר המקסימלי המותר. (לדוגמה, $session.params.webhook-error-count <= 3). המסלול הזה צריך לכלול מילוי בקשה שמודיע למשתמש הקצה שהנציג ינסה שוב. הנתיב הזה צריך לכלול יעד מעבר שמוגדר כ-PREVIOUS_PAGE, או כל דף שיכול לנסות שוב לקרוא ל-webhook.

  • מגדירים נתיב תנאי עם תנאי שמספר השגיאות גדול מהמספר המקסימלי המותר (לדוגמה, $session.params.webhook-error-count > 3). הנתיב הזה צריך לכלול מילוי בקשה שמודיע למשתמש הקצה שהנציג לא ינסה שוב. המסלול הזה צריך לכלול יעד מעבר שמוגדר לדף שלא יפעיל ניסיונות חוזרים של ה-webhook.

• לגורם המטפל באירועים של ה-webhook צריך להיות יעד מעבר שמעביר לדף השגיאה של ה-webhook.

כלים

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

שימוש בכלי האימות

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

שימוש בתכונה "מקרי בדיקה"

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