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

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

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

לפני שיוצרים נציג

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

מטרה

חשבו על המטרה הכוללת של הסוכן:

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

פלטפורמה

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

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

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

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

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

ישויות מערכת

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

שיחת חולין

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

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

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

ברכות ופרידות

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

למידת מכונה ואימון

שיטה מומלצת: פרטים
לכל כוונה צריכים להיות לפחות 10-20 ביטויי אימון (בהתאם למורכבות הכוונה). מורכבות הנציג תקבע את המספר בפועל של ביטויי האימון שצריכים להיות לכל כוונה, אבל 10-20 (בהתאם למורכבות הכוונה) הוא מספר מינימלי טוב. ככל שיש יותר פרמטרים בכוונות, כך צריך לספק יותר ביטויים כדי לאמן את המודל של למידת המכונה.
ביטויי ההדרכה צריכים להיות מגוונים. כדאי לכלול וריאציות של שאלות, פקודות, פעלים ומילים נרדפות לשמות עצם נפוצים, כדי לוודא שהביטויים מכסים מגוון רחב של בקשות אפשריות.
ההערות צריכות להיות עקביות.
  • בודקים את ביטויי האימון ומוודאים שההערות המודגשות מצביעות על הישויות הנכונות.
  • לא מומלץ להשתמש בטקסט בביטויי אימון שמוסיפים לו הערות במקרים מסוימים, אבל לא במקרים אחרים.
  • קטע הטקסט שנבחר להערה צריך לכלול את כל הטקסט שנדרש כדי להתאים לישות, ולא יותר מכך.
  • חשוב לוודא שהטקסט עם ההערות בכמה ביטויי אימון מכיל חלקים דומים של ביטוי האימון. לדוגמה, נניח שיש לכם את ביטוי האימון "Set alarm at 6 a.m.", שבו "6 a.m." מסומן כ-@sys.date. אם יש לכם עוד ביטוי לאימון, "תעיר אותי ב-7:00", צריך להוסיף הערה ל-"7:00", אבל לא ל-"אותי ב-7:00".
השתמשו בהערות בעלות משמעות סמנטית לישויות מערכת. המשמעות הסמנטית של חלק מביטוי אימון שנבחר להערה יכולה להיות מושפעת משאר הטקסט בביטוי האימון. לדוגמה:
  • אני בן 7 (המשמעות הסמנטית של הטקסט המסומן היא גיל של אדם)
  • החוזה תקף למשך 7 שנים (המשמעות הסמנטית של הטקסט המתויג היא משך זמן)
המודלים של למידת המכונה של Dialogflow מביאים בחשבון את המשמעות הסמנטית כשהם מתאימים ישויות מערכת. המשמעות הסמנטית של החלק בביטוי לאימון חייבת להתאים למשמעות הסמנטית המיועדת של ישות המערכת.

לדוגמה, אל תשתמשו בישות המערכת @sys.duration כדי להוסיף הערה לדוגמה הראשונה של "7 שנים" שלמעלה. המשמעות הסמנטית של "7 שנים" לא תואמת למשך זמן פשוט. במקום זאת, צריך להשתמש בישות המערכת @sys.age.
ישויות בהתאמה אישית צריכות לכלול מגוון רחב של דוגמאות. ישויות הן רשימות של פריטים. למידת המכונה תטפל בצורות הדקדוקיות, אבל אתם צריכים לכלול את כל הפריטים האפשריים. כדאי גם לסמן את האפשרות הגדרת מילים נרדפות ולכלול כמה וריאציות.
השביתו את למידת המכונה לכמה שפחות כוונות. ביטויי אימון לכוונות שה-ML מושבת בהן לא משמשים לאימון הנציג. אם שאילתת משתמש דומה מאוד לביטוי לאימון ב-intent שבו ה-ML מושבת, יכול להיות שהיא תותאם ל-intent הלא נכון אם יש intents אחרים שבהם ה-ML מופעל והם דומים קצת לשאילתת המשתמש. אם אתם נתקלים בבעיות של זיהויים חיוביים שגויים, כדאי להעלות את סף הסיווג של למידת המכונה במקום להשבית את למידת המכונה.
אל תגדירו סף סיווג גבוה של למידת מכונה לנציג עם מעט נתוני אימון. אם הסף גבוה ואין הרבה נתוני אימון, רק שאילתות של משתמשים שיש להן התאמות כמעט מדויקות לביטויי האימון יגרמו להתאמה של כוונה. אם אתם רוצים להגדיר סף גבוה, אתם צריכים לספק הרבה נתוני אימון.
לנציגים צריכה להיות כוונה חלופית. בלי כוונות חלופיות, שאילתות של משתמשים שלא תואמות לכוונות קיימות יגרמו לתשובות ריקות.
הנציגים צריכים לספק דוגמאות שליליות. דוגמאות שליליות מונעות מצב שבו שאילתות של משתמשים שדומות קצת לביטויי אימון יתאימו בטעות לכוונות.
אל תגדירו ישויות שתואמות כמעט לכל דבר. זה פוגע בביצועים ובאיכות של למידת המכונה. כמעט כל דבר בכל ביטוי לאימון ייבדק כהתאמה אפשרית. כדאי להשתמש ב-@sys.any במקום זאת. באופן דומה, ישויות מורכבות לא צריכות להכיל @sys.any יחיד כמילה נרדפת.
אל תגדירו ישויות שמורכבות ממילים ריקות או מטקסט חסר משמעות. דוגמאות למילות מילוי וטקסט חסר משמעות: "אממ", "בוא נראה", "בבקשה", "אפשר בבקשה". אם אתם מנסים להשתמש בישויות כאלה כדי ליצור גיוון, אתם רק פוגעים בביצועים של למידת המכונה. ‫Dialogflow כבר מגדיל את הנתונים כדי לטפל במגוון כזה. כדאי להוסיף ביטויים כאלה לביטויי האימון, ולא לישויות.
היקף הישויות צריך להיות מוגבל, כך שהן יתעדו ערכים נפרדים של סוג מידע אחד. הישויות צריכות להיות ממוקדות, קצרות ופשוטות. אם ערכי הישויות שלכם מורכבים, יכול להיות שביטויי אימון של כוונה מתאימים יותר למצב שלכם. לדוגמה, נניח שמשתמשי קצה מזינים ביטויים כמו "איך אפשר לבצע שיחה בינלאומית עם תוכנית א'?" ו"שימוש בנדידת נתונים בינלאומית עם תוכנית ב'". אל תיצרו ישויות גם לפעולות ("איך אפשר לבצע שיחה בינלאומית" ו"שימוש בנדידת נתונים בינלאומית") וגם לתוכניות ("תוכנית א'", "תוכנית ב'"). במקום זאת, צריך להשתמש בביטויי אימון ובהתאמת כוונה כדי לתעד את הפעולות, ובישויות כדי לתעד את התוכניות.
הטקסט עם ההערות בביטויי הניסוח צריך להיות מגוון. לדוגמה, אם אתם מספקים ערכי זמן שצריך לנתח כישויות מערכת מסוג @sys.time בביטויי אימון, אל תספקו את אותו הזמן בכל ביטויי האימון. ביטויי האימון צריכים לכלול מגוון דוגמאות של זמנים, כמו: "7 בבוקר", "8 p.m.", "9:00".
כוונות עם הרבה פרמטרים צריכות לכלול גם הרבה ביטויי אימון. ככלל, כדאי לנסות להגדיר לפחות פי שלושה ביטויי אימון מאשר פרמטרים, ולפחות 10-20 ביטויי אימון (בהתאם למורכבות של כוונת המשתמש).
כל פרמטר צריך להופיע בהרבה ביטויי אימון. ככלל, צריך להשתמש בכל פרמטר ב-5 ביטויי אימון לפחות.
מומלץ להימנע משימוש בכמה ישויות מסוג @sys.any בביטוי לאימון. ביטוי לאימון לא יכול להכיל שתי ישויות ‎ @sys.any עוקבות או שלוש ישויות ‎ @sys.any בסך הכול. יכול להיות ש-Dialogflow לא יוכל להבחין ביניהם.
אל תשתמשו בביטויי אימון דומים בכוונות שונות. כוונות שונות לא צריכות להכיל ביטויי אימון דומים, כי זה ימנע מ-Dialogflow ללמוד איך לזהות את הביטויים האלה.
הפעלת תיקון איות אוטומטי. אם אתם משתמשים בקלט טקסט, כדאי להפעיל את תיקון האיות האוטומטי.
לא להטמיע ישויות מורכבות אל תשתמשו ביותר מרמה אחת של הטמעה בישויות מורכבות. כל רמה של הטמעה פוגעת באופן משמעותי באיכות.
הימנעו משימוש בתווים מיוחדים בביטויי האימון. תווים מיוחדים בביטויי אימון, כמו {, ‏ _, ‏ # ו-[, לא יילקחו בחשבון. אפשר להשתמש בסמלי אמוג'י, הם פועלים כצפוי.

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

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

תכונות שימושיות של Intent

שיטה מומלצת: פרטים
הנציגים צריכים לתמוך בבקשות לפי הקשר. לדוגמה, אם הנציג מטפל בבקשות בנושא מזג האוויר ומשתמש שואל "מזג האוויר בתל אביב", חשוב להוסיף הקשרים כדי לתמוך בבקשות נוספות כמו "ומה לגבי מחר?"
הנציגים צריכים להגיב בהתאם לתשובות של המשתמשים, כמו "כן", "לא", "ביטול", "הבא", "חזרה" וכו'. כוונות (intent) לצורכי מעקב משמשות כדי להשיב לתגובות נפוצות. כדי להוסיף כוונה לצורכי מעקב, מעבירים את העכבר מעל כוונה ולוחצים על Add follow-up.
לכל כוונה צריכה להיות לפחות תשובת טקסט אחת. קטע התגובה נמצא בתחתית הדף של ה-intent. הוספת וריאציות תגרום לערבוב של התשובות שנבחרו, וכך החוויה תהיה פחות מונוטונית.
הנציגים צריכים לאסוף את כל המידע הדרוש כדי למלא את בקשת המשתמש. כדאי להגדיר פרמטרים נדרשים. הסוכן ימשיך לשאול את המשתמש עד שהוא יקבל את המידע שהוא צריך. התהליך הזה נקרא "מילוי משבצות".
התשובות צריכות לחזור על מידע לפי הצורך, כמו אישור הזמנה. כשהמשתמש מבצע פעולה כמו ביצוע הזמנה או שינוי מידע, הנציג צריך לחזור על מה שקורה כדי לאשר את הפעולה. כשיוצרים את תגובות האישור האלה, חשוב לכלול את כל השילובים האפשריים של ישויות ופרמטרים חוזרים.

תיקון השיחה

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

פרסונה

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

עיצוב ממשק קולי

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

מידע נוסף על עיצוב סוכן קולי זמין במאמר עיצוב סוכן קולי.

הגנה על פרטיות הצרכנים

שיטה מומלצת: פרטים
להשבית את רישום הנתונים בהגדרות הנציג כדי לעמוד בתקנות ה-GDPR. בהגדרות הנציג, אתם יכולים להשבית את רישום האינטראקציות ביומן ב-Dialogflow. אם משביתים את התכונה הזו, לא נשמרים פרטים אישיים מזהים (PII) ב-Dialogflow. המשמעות היא גם שתכונות מסוימות, כמו ניתוח נתונים, לא יהיו זמינות.
אחסון נתוני השיחות בצ'אט ב-BigQuery כדי לשלוט באחסון האזורי. באמצעות Cloud Logging או Dialogflow API, אתם יכולים לשלוח ל-BigQuery את הצ'אט הנכנס. כך תוכלו לשלוט באזור שבו אתם רוצים לאחסן את הנתונים. בנוסף, אתם יכולים להשתמש ב-Data Loss Prevention API כדי להסתיר מידע רגיש. תוכנית לבניית שירות לקוחות מבוסס-AI ב-GCP

שימוש במחבר של מאגר הידע

שיטה מומלצת: פרטים
כשמייבאים שאלות נפוצות שגלויות לכולם, צריך להשתמש בתגי עיצוב תקינים של HTML5. לדוגמה, השתמשו ברכיבי מאמר עם סימון schema.org כמו schema.org/Question ו-schema.org/Answer.
מוודאים שהאתר של השאלות הנפוצות נוסף לאינדקס על ידי Google Robots האתר צריך לאפשר גישה לרובוטים של Google, וצריך להוסיף אותו למנוע החיפוש של Google באמצעות כלי מנהל האתרים של Google. אתרים כמו pages.github לא יעבדו, כי אי אפשר לסרוק אותם.
שימוש ב-1 עד 200 שאלות נפוצות צריך יותר מזוג אחד של שאלה ותשובה, ולא יותר מ-200 לכל מאגר ידע. אם צריך, אפשר לטעון כמה מאגרי ידע.

הטמעה של ממשקי Dialogflow API

שיטה מומלצת: פרטים
אל תחשפו את המפתח הפרטי של חשבון השירות בבסיסי קוד של לקוחות באפליקציות לנייד או באפליקציות אינטרנט. זה לא נחשב בטוח. כל מי שיודע להשתמש בכלי הפיתוח של Chrome יכול לגנוב את המפתח שלכם ולבצע קריאות ל-API (בתשלום) דרך החשבון שלכם. עדיף תמיד לאפשר לשרת proxy ל-API לטפל באימות של Google Cloud. כך חשבון השירות לא ייחשף לציבור, ואפשר יהיה לאחסן את המפתחות בצורה בטוחה.}

עיצוב לנציג אחד עם קול וטקסט

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

בדיקה

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

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

מדריכים נוספים לפיתוח ממשק שיחה

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