במדריך הזה מפורטות שיטות מומלצות כלליות לעיצוב כל סוגי הסוכנים.
מומלץ גם לעיין במדריך עיצוב סוכנים קוליים, שמתמקד בעיצוב סוכנים קוליים, ובמדריך שיטות מומלצות לשימוש בשירות Dialogflow.
לפני שיוצרים סוכן
בקטע הזה מפורט מידע שכדאי לקרוא לפני שמתחילים לבנות סוכן.
מטרה
כדאי לחשוב על המטרה הכוללת של הסוכן:
- מה העסק שלך מנסה להשיג?
- מה המשתמשים יצפו מהסוכן?
- באיזו תדירות המשתמשים יקיימו אינטראקציה עם הנציג?
פלטפורמה
חשוב לחשוב איך המשתמשים יוכלו לגשת לסוכן. לפני שיוצרים תוכן, כדאי לעיין בפלטפורמות שנתמכות על ידי Dialogflow. כשבוחרים פלטפורמות לתמיכה, צריך להכין את התוכן בהתאם. חלק מהשילובים של פלטפורמת Dialogflow תומכים בהודעות מתקדמות שיכולות לכלול אלמנטים כמו תמונות, קישורים וצ'יפים של הצעות.
יצירת סוכנים באופן איטרטיבי
אם הסוכן שלכם יהיה גדול או מורכב, כדאי להתחיל בבניית דיאלוג שמתייחס רק לבקשות ברמה העליונה. אחרי שיוצרים את המבנה הבסיסי, צריך לחזור על נתיבי השיחה כדי לוודא שכל המסלולים האפשריים שהמשתמש יכול לבחור מכוסים.
סוכנים מוכנים מראש
Dialogflow מציע סוכנים מוכנים מראש שיעזרו לכם להתחיל. סוכנים מוכנים מראש מכסים תרחישי שימוש נפוצים כמו הזמנת חדר במלון, ניווט וקניות אונליין. הסוכנים האלה כוללים כוונות וישויות שמכסות את השאילתות הנפוצות ביותר של משתמשים. מוסיפים תשובות שספציפיות לעסק שלכם, ותוכלו ליצור במהירות נציג וירטואלי מתפקד.
ישויות מערכת
כשמשתמש שולח בקשה, חשוב לנתח את מה שהוא אמר כדי לחלץ ממנה מידע חשוב. ב-Dialogflow, הם נקראים ישות. בפרט, ישויות מערכת הן ישויות מוכנות מראש שסופקו על ידי Dialogflow ומטפלות בסוגי המידע הפופולריים ביותר.
שיחת חולין
יכול להיות שחשבתם לטפל בבקשות שלא קשורות לנושא כשפיתחתם את הדיאלוג. ב-Dialogflow יש תכונה אופציונלית שנקראת שיחה קלילה. כשהתכונה הזו מופעלת, הסוכן הווירטואלי מגיב לשיחות כלליות, לתגובות רגשיות ולשאלות לגבי הסוכן עצמו. אפשר להתאים אישית את כל התשובות לשיחות קלילות כדי לוודא שהחוויה, בין אם היא קלילה, רצינית או משהו באמצע, מייצגת את המותג שלכם.
שיטות מומלצות לתכנון סוכנים
בקטע הזה מפורטות שיטות מומלצות ליצירת סוכן חזק, מדויק, יעיל ושימושי.
פתיחים וסיומים
| שיטה מומלצת | פרטים |
|---|---|
| האינטראקציות הראשונות צריכות להציג למשתמשים את היכולות של הנציג, תוך התחשבות במיתוג. | בכוונת קבלת הפנים של הנציג צריך להיות מידע על 2-3 משימות שהנציג יכול לעזור בהן, וגם תיאורים קצרים (במידת הצורך) של אופן השימוש בתכונות האלה. |
| סוכנים צריכים להגדיר הודעת סיום מתאימה לאינטראקציה מוצלחת. | כשמשתמש משלים משימה בסוכן, הסוכן צריך לסכם את העסקה או המשימה ולומר משהו כמו "נתראה בפעם הבאה" וכו'. |
למידת מכונה והדרכה
| שיטה מומלצת | פרטים |
|---|---|
| לכל כוונת משתמש צריכות להיות לפחות 10-20 (בהתאם למורכבות הכוונה) ביטויי אימון. | מורכבות הנציג תקבע את המספר בפועל של משפטי אימון שצריכים להיות לכל כוונה, אבל 10-20 (בהתאם למורכבות הכוונה) הוא מספר מינימלי טוב. ככל שיש יותר פרמטרים בכוונות, כך צריך לספק יותר ביטויים כדי לאמן את מודל הלמידה החישובית. |
| חשוב להשתמש במגוון ביטויים לאימון. | כדי לוודא שהביטויים שלכם יכסו מגוון רחב של בקשות אפשריות, כדאי לכלול וריאציות של שאלות, פקודות, פעלים ומילים נרדפות לשמות עצם נפוצים. |
| ההערות צריכות להיות עקביות. |
|
| משתמשים בהערות בעלות משמעות סמנטית לישויות מערכת. | המשמעות הסמנטית של חלק מביטוי לאימון שנבחר להערה יכולה להיות מושפעת משאר הטקסט בביטוי לאימון. לדוגמה:
לדוגמה, אל תשתמשו בישות המערכת @sys.duration להערה של הדוגמה הראשונה '7 שנים' שמופיעה למעלה. המשמעות הסמנטית של '7 שנים' לא תואמת למשך זמן פשוט. במקום זאת, צריך להשתמש בישות המערכת @sys.age. |
| יש לכלול מגוון רחב של דוגמאות לישויות מותאמות אישית. | ישויות הן רשימות של פריטים. למידת מכונה תטפל בצורות דקדוקיות, אבל אתם צריכים לכלול את כל הפריטים האפשריים. בנוסף, מסמנים את האפשרות הגדרת מילים נרדפות וכוללים כמה וריאציות. |
| מומלץ להשבית את ה-ML בכמה שפחות כוונות. | כשמשביתים את למידת המכונה, לא משתמשים במשפטים לאימון כוונות לאימון הסוכן. שאילתת משתמש שדומה מאוד לביטוי לאימון בכוונת משתמש שהלמידה מחישובים סטטיסטיים מושבתת בה, עשויה להיות מותאמת לכוונת משתמש שגויה אם כוונות משתמש אחרות שהלמידה מחישובים סטטיסטיים מופעלת בהן דומות מעט לשאילתת המשתמש. אם נתקלתם בבעיות שקשורות לזיהוי חיובי שגוי, כדאי להגדיל את סף הסיווג של למידת המכונה במקום להשבית את למידת המכונה. |
| אל תגדירו סף סיווג גבוה לנציג שיש לו רק מעט נתוני אימון. | אם ערך הסף גבוה ואין הרבה נתוני אימון, רק שאילתות משתמשים שיש להן התאמה כמעט מדויקת לביטויי האימון יניבו התאמה לכוונות. אם רוצים להגדיר סף גבוה, צריך לספק הרבה נתוני אימון. |
| לסוכנים צריכה להיות כוונת גיבוי. | בלי כוונות חלופיות, שאילתות משתמש שלא תואמות לאף כוונה יניבו תשובות ריקות. |
| הסוכנים צריכים לספק דוגמאות שליליות. | דוגמאות שליליות מונעות התאמה לא מכוונת של כוונות לשאילתות משתמשים שדומות מעט לביטויי אימון. |
| אל תגדירו ישויות שתואמות כמעט לכל דבר. | הפעולה הזו פוגעת בביצועים ובאיכות של למידת המכונה. כמעט כל דבר בכל משפט אימון ייבדק כהתאמה אפשרית. מומלץ להשתמש במקומה ב-@sys.any. באופן דומה, ישויות מורכבות לא יכולות להכיל @sys.any יחיד כמילה נרדפת. |
| אל תגדירו ישויות שמורכבות ממילות מילוי או מטקסט חסר משמעות. | דוגמאות למילות מילוי ולטקסט חסר משמעות: "אהממ", "בוא נראה", "בבקשה", "אפשר בבקשה". אם אתם מנסים להשתמש בישויות כאלה כדי להוסיף מגוון, אתם רק פוגעים בביצועים של למידת המכונה. מערכת Dialogflow כבר משפרת את הנתונים כדי לטפל במגוון כמו זה. צריך להוסיף ביטויים כאלה לביטויי האימון, ולא לישויות. |
| לכל ישות צריך להיות היקף מוגבל שכולל ערכים נפרדים של סוג מידע אחד. | חשוב שהישויות יהיו ממוקדות, קצרות ופשוטות. אם ערכי הישויות מורכבים, יכול להיות שביטויי אימון לזיהוי כוונות מתאימים יותר למצב שלכם. לדוגמה, נניח שמשתמש קצה שואל שאלות כמו "איך אפשר לבצע שיחה בינלאומית עם תוכנית א'?" ו"איך משתמשים בנדידת נתונים בינלאומית עם תוכנית ב'?". אל תיצרו ישויות גם לפעולות ("איך אפשר לבצע שיחה לחו"ל" ו"שימוש בנדידת נתונים בינלאומית") וגם לתוכניות ("תוכנית א'", "תוכנית ב'"). במקום זאת, צריך להשתמש בביטויים לאימון ובהתאמה להבעת כוונה כדי לזהות את הפעולות והישויות שנדרשות לביצוע התוכניות. |
| הטקסט עם ההערות בביטויי האימון צריך להיות מגוון. | לדוגמה, אם אתם מספקים ערכי זמן שצריכים להיות מנותחים כ@sys.time ישויות מערכת בביטויי אימון, אל תספקו את אותו הזמן בכל ביטויי האימון. ביטויי האימון צריכים לכלול מגוון דוגמאות לציון זמן, כמו: "7 a.m.", "8 p.m.", "9 o'clock" (בשעה 9). |
| לכוונות עם הרבה פרמטרים צריכות להיות גם הרבה ביטויי אימון. | ככלל, כדאי להשתמש לפחות בפי שלושה יותר ביטויי אימון מפרמטרים, ולפחות ב-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
תכונות שימושיות לזיהוי כוונת רכישה
| שיטה מומלצת | פרטים |
|---|---|
| הסוכנים צריכים לתמוך בבקשות לפי ההקשר. | לדוגמה, אם הסוכן מטפל בבקשות לגבי מזג האוויר, ומשתמש שואל "מזג האוויר בתל אביב", חשוב להוסיף הקשרים כדי לתמוך בבקשות נוספות כמו "מה לגבי מחר?" |
| לסוכנים צריכות להיות תשובות למקרים שבהם המשתמש אומר כן, לא, ביטול, הבא, חזרה וכו'. | הכוונה היא להשתמש בכוונות למעקב כדי להשיב לתשובות נפוצות. כדי להוסיף כוונת מעקב, מעבירים את העכבר מעל כוונת מסוימת ולוחצים על הוספת מעקב. |
| לכוונות צריך להיות לפחות תגובה אחת בטקסט. | קטע התשובה נמצא בתחתית הדף של הכוונה. הוספת וריאציות תגרום להצגת התשובות בסדר אקראי, כך שהחוויה תהיה פחות חוזרת על עצמה. |
| הסוכנים צריכים לאסוף את כל המידע הדרוש כדי למלא את בקשת המשתמש. | כדאי להגדיר את הפרמטרים הנדרשים כחובה. הסוכן ימשיך לבקש מהמשתמש את המידע עד שהוא יקבל אותו. הפעולה הזו נקראת מילוי משבצת. |
| התשובות צריכות לחזור על מידע לפי הצורך, למשל לאשר הזמנה. | כשמשתמש שולח בקשה כמו ביצוע הזמנה או שינוי פרטים, הנציג צריך לחזור על הפעולה כדי לקבל אישור. כשיוצרים את תגובות האישור האלה, חשוב לכלול את כל השילובים האפשריים של ישויות ופרמטרים שחוזרים על עצמם. |
תיקון שיחות
| שיטה מומלצת | פרטים |
|---|---|
| לכל שלב בשיחה צריכות להיות הנחיות מועילות לשחזור. | לדוגמה, אם ההנחיה הראשונית היא "איזה צבע אתה רוצה?" והמשתמש משיב "תוכי ג'ונגל", כדאי להגדיר כוונה חלופית או כוונה למעקב שתנסח מחדש את השאלה, למשל "סליחה, איזה צבע אמרת?". |
| הסוכנים צריכים לספק תשובות מותאמות אישית שספציפיות למותג בכוונת ברירת המחדל. | כשמשתמש אומר משהו שלא תואם לאף כוונה, המערכת מתאימה אותו לכוונה לגיבוי שמוגדרת כברירת מחדל. ההודעה צריכה להיות מותאמת למותג שלכם, וגם לספק מידע שיעזור למשתמש לשלוח בקשה תקפה. |
| כדי לספק מילוי הזמנות בהתאמה אישית, לסוכנים צריכה להיות כוונה שמאפשרת למשתמשים לחזור על מידע. | אינטנט אחד יכול לטפל בבקשות כמו "תגיד את זה שוב", "תחזור על זה", "תפעיל את זה שוב" וכו'. זה יכול להיות אינטנט המשך. |
| עזרו למשתמשים להצליח, והנחו אותם לומר בדיוק מה הייתם רוצים לשמוע כתשובה | לדוגמה: אם אתם מספקים אפשרויות, אל תשאלות "רוצה A או B?". – כי אז משתמש יכול לענות 'כן'. במקום זאת, שואלים: 'יש לי A ויש לי B. איזו אפשרות מועדפת עליך? |
פרסונה
| שיטה מומלצת | פרטים |
|---|---|
| התשובות של הסוכן צריכות להיות בסגנון ובטון שמתאימים למותג שלכם, ועקביים לאורך כל האינטראקציה עם הסוכן. | במהלך השיחה של המשתמשים עם הסוכן, הם צריכים להרגיש שהם מדברים עם דמות אחת. חשוב לוודא שהתכונות והאישיות שבחרתם באות לידי ביטוי בכל התשובות. |
| הנציגים צריכים להיות רגישים לגבי תרבויות, מגדרים, אמונות דתיות, יכולות וגילאים. | יכול להיות שסטריאוטיפים יפגעו במשתמשים, גם אם הם נאמרים כבדיחה, והם לא יחזרו לסוכן שלכם. |
עיצוב לשימוש בקול
| שיטה מומלצת | פרטים |
|---|---|
| אל תשתמשו בתוכן שנדרשת לו ויזואליזציה או אינטראקציה עם מקלדת ועכבר. | אל תשתמשו בהיפר-קישורים, בטבלאות, בתמונות או בקיצורים. אפשר להתייחס לאתר לפי השם שלו. כשמציגים רשימה של אפשרויות, מחזירים את ההתאמה הטובה ביותר ושואלים אם המשתמש רוצה לשמוע אפשרויות חלופיות. |
| לא ליצור שתיקות מביכות. תמיד מסיימים בשאלה. לכוון את השיחה ולעודד אינטראקציות. | |
| כתבו דיאלוגים קצרים וקלים להבנה. | במסך, הטקסט יכול להיות ארוך ולכלול כמה פסקאות. אתם יכולים לדלג על החלקים שלא מעניינים אתכם. אבל אם המשתמשים ישמעו את הנציג הווירטואלי מדבר יותר מדי זמן, הם לא יהיו מרוצים. |
| שימוש ב-SSML | אפשר להשתמש ב-SSML כדי לבנות את המשפטים ולשנות את האינטונציה שלהם, וכך הקולות יישמעו טבעיים יותר. |
מידע נוסף על עיצוב ל-Voice זמין במאמר עיצוב סוכן וירטואלי ל-Voice.
הגנה על פרטיות הצרכנים
| שיטה מומלצת | פרטים |
|---|---|
| כדי לעמוד בדרישות של GDPR, צריך להשבית את רישום הנתונים בהגדרות הסוכן. | בהגדרות הסוכן, אפשר להשבית את הרישום ביומן של האינטראקציות ב-Dialogflow. אם משביתים את התכונה הזו, לא יישמרו ב-Dialogflow נתונים אישיים מזהים. המשמעות היא גם שחלק מהתכונות, כמו ניתוח נתונים, לא יהיו זמינות. |
| אחסון נתוני שיחות בצ'אט ב-BigQuery כדי לשלוט באחסון אזורי. | אפשר לשלוח ל-BigQuery את ההתבטאויות בצ'אט נכנס באמצעות Cloud Logging או Dialogflow API. הגישה הזו מאפשרת לכם לשלוט באזור שבו אתם רוצים לאחסן את הנתונים. בנוסף, אפשר להשתמש ב-Data Loss Prevention API כדי להסתיר מידע רגיש. כאן אפשר לראות תוכנית ליצירת שירות לקוחות מבוסס-AI ב-GCP. |
שימוש במחבר של מאגר הידע
| שיטה מומלצת | פרטים |
|---|---|
| כשמייבאים שאלות נפוצות ציבוריות, צריך להשתמש בתגי עיצוב תקינים של HTML5. | לדוגמה, אפשר להשתמש ברכיבי מאמר עם סימון schema.org כמו schema.org/Question ו-schema.org/Answer. |
| מוודאים שרובוטים של Google מוסיפים לאינדקס את האתר עם השאלות הנפוצות | האתר צריך לאפשר לרובוטים של Google לסרוק אותו, ולהיות מוסף למנוע החיפוש של Google באמצעות הכלי למנהלי אתרים של Google. אתרים כמו pages.github לא יפעלו, כי אי אפשר לסרוק אותם. |
| שימוש ב-1 עד 200 שאלות נפוצות | צריך יותר מזוג אחד של שאלות ותשובות, ולא יותר מ-200 לכל מאגר ידע. אם אתם צריכים עוד, אתם יכולים לטעון כמה בסיסי ידע. |
הטמעה של Dialogflow APIs
| שיטה מומלצת | פרטים |
|---|---|
| אל תחשפו את המפתח הפרטי של חשבון השירות בבסיסי קוד של לקוחות באפליקציות לנייד או באפליקציות לאינטרנט. | הפעולה הזו לא נחשבת בטוחה. כל מי שמכיר את כלי הפיתוח של Chrome יכול לגנוב את המפתח שלכם ולבצע קריאות ל-API (בתשלום) דרך החשבון שלכם. גישה טובה יותר היא תמיד לאפשר ל-proxy ל-API לטפל באימות של Google Cloud. כך חשבון השירות לא יהיה חשוף לציבור, והמפתחות יוכלו להישמר בצורה בטוחה.} |
תכנון של סוכן אחד עם תמיכה בקול ובטקסט
| שיטה מומלצת | פרטים |
|---|---|
| אין להשתמש ב-SSML בתשובות ברירת המחדל של הפלטפורמה. | אם הסוכן יכול להגיב גם בקול וגם בטקסט, תשובה טקסטואלית תכלול את קוד ה-SSML הגולמי. שימוש בטקסט פשוט בתשובת ברירת המחדל של הפלטפורמה וב-SSML בתשובות ספציפיות לפלטפורמה. אפשר גם להשתמש ב-webhook כדי ליצור SSML רק כשצריך תשובה קולית. |
בדיקה
| שיטה מומלצת | פרטים |
|---|---|
| בדקו את האפליקציה ביסודיות עם מישהו שלא היה מעורב בפיתוח שלה. | אם תתנו למישהו שלא מכיר את הסוכן להשתמש באפליקציה, תוכלו להבין עד כמה השיחה זורמת באופן טבעי. כדאי לבקש מהם לבדוק את רמת הדיוק, ההפסקות הארוכות, נתיבי שיחה חסרים, הקצב, מעברים לא נוחים וכו'. |
| בודקים את האפליקציה בכל הפלטפורמות שאתם מתכננים לתמוך בהן. | אם הסוכן שלכם יהיה זמין בפלטפורמה אחת או יותר, חשוב לוודא שהודעות מתקדמות והתשובות מוצגות כמו שצריך בכל הפלטפורמות. |
שיטות מומלצות לארגונים גדולים
מדריכים נוספים לעיצוב שיחות
- אפשר לעיין במדריך לפיתוח ממשק שיחה שסופק על ידי צוות Actions on Google.
- אפשר לעיין במדריך ל-SSML שסופק על ידי צוות Actions on Google.