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

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

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

עצה כללית

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

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

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

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

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

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

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

שילובים

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

Dialogflow CX API

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

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

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

משאבים לנציגים

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

דפים ו-Flows

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

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

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

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

• קבלת היתרה בחשבון העו"ש
• קבלת יתרת החיסכון
• קבלת יתרת המשכנתה
• קבלת יתרת הקרדיטים

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

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

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

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

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

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

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

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

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

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

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

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

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

שימוש חוזר ב-Intent

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

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

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

confirmation.no לדוגמה, כוונת משתמש יכולה לכלול ביטויי אימון כמו:

• לא
• לא
• לא
• אין מצב
• לא לטעמי
• ממש לא
• לא, תודה

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

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

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

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

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

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

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

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

טיפול בהזמנות

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

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

מתן שמות

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

מתן שמות ל-Intent

אם לסוכן שלכם יש הרבה כוונות, כדאי להשתמש בסכימת שמות שתעזור לכם לשמור על סדר. מקובל לפלח שמות של כוונות באמצעות סימני פיסוק, כשהספציפיות עולה משמאל לימין. בנוסף, שם ה-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 לטובת הכוונות הגדולות יותר בגלל נתונים לא מאוזנים. הטיה כזו יכולה לקרות אם יש הבדל של סדר גודל או יותר בין מספר הביטויים לאימון.

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

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

ביטויי אימון של כוונת A	ביטויים לאימון של כוונת B	הטיה לכוונת רכישה ב'
20	50	לא
20	200	יכול להיות
20	2000	כן

שימוש בישויות וכמות ביטויי ההדרכה

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

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

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

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

מגוון ביטויי אימון נדרש

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

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

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

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

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

Standard NLU

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

גישות חלופיות אפשריות:

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

NLU מתקדם

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

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

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

• שימוש באותיות רישיות: אם אתם משתמשים במודל NLU רגיל, מומלץ להימנע מביטויים כפולים כמו except "Order a ticket" ו-"order a ticket", אלא אם מדובר במקרים נדירים. עם זאת, מודל ה-NLU המתקדם הוא תלוי-אותיות רישיות וקטנות, ונדרשים לו יותר ביטויי אימון כדי להגדיל את ההתאמות לכוונות. פרטים נוספים זמינים בקטע אפשרויות שונות לשימוש באותיות רישיות.
• מילות מילוי: לדוגמה, "אוקיי, תזמין כרטיס" ו "תזמין כרטיס".
• סימני פיסוק: לדוגמה, "can you please help?" ו-"can you please help!?"

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

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

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

טוב	Bad
יציאה ב-7 בספטמבר	‫7 בספטמבר
יציאה ב4 ביולי	יציאה ב-4 ביולי

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

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

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

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

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

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

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

אל תשתמשו ב[e-mail]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סוג הישות של הפעולות	סוג הישות Plans
"איך אפשר להתקשר לחו"ל"	‫"Plan A"
'שימוש בנדידת נתונים בינלאומית'	"Plan B"

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

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

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

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

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

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

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

אם שני ביטויי אימון מייצגים את אותה כוונה, הם צריכים להיות שייכים לאותה כוונה. לדוגמה, הביטויים "שינוי התאריך האחרון לתשלום" ו "הארכת זמן התשלום" צריכים להיות שייכים לאותה כוונה, כי בשניהם מבוקש שינוי של התאריך האחרון לתשלום. עם זאת, השאלות: "Can I make an international call with Plan A?" and "Can I use international data roaming with Plan A?" יכולות להיות שייכות לכוונות שונות, כי המשתמש רוצה לקבל תשובה שונה בכל מקרה.

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

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

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

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

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

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

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

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

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

• אנא
• can you please
• המממ
• מה דעתך

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

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

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

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

תגובה למשתמש הקצה

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

קבלת משתמש הקצה

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

אישור פרטי משתמשי קצה

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

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

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

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

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

הנחיית השיחה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    פרמטר	ערך
    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.

כלים

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

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

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

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

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