במדריך הזה מפורטות שיטות מומלצות כלליות לעיצוב כל סוגי הסוכנים.
מומלץ גם לעיין במדריך עיצוב סוכנים קוליים, שמתמקד בעיצוב סוכנים קוליים, ובמדריך שיטות מומלצות לשימוש בשירות Dialogflow.
לפני שיוצרים סוכן
בקטע הזה מפורט מידע שכדאי לקרוא לפני שמתחילים לבנות סוכן.
מטרה
כדאי לחשוב על המטרה הכוללת של הסוכן:
- מה העסק שלך מנסה להשיג?
- מה המשתמשים יצפו מהסוכן?
- באיזו תדירות המשתמשים יקיימו אינטראקציה עם הנציג?
פלטפורמה
חשוב לחשוב איך המשתמשים יוכלו לגשת לסוכן. לפני שיוצרים תוכן, כדאי לעיין בפלטפורמות שנתמכות על ידי Dialogflow. כשבוחרים פלטפורמות לתמיכה, צריך להכין את התוכן בהתאם. חלק מהשילובים של פלטפורמת Dialogflow תומכים בהודעות מתקדמות שיכולות לכלול אלמנטים כמו תמונות, קישורים וצ'יפים של הצעות.
יצירת סוכנים באופן איטרטיבי
אם הסוכן שלכם יהיה גדול או מורכב, כדאי להתחיל בבניית דיאלוג שמתייחס רק לבקשות ברמה העליונה. אחרי שיוצרים את המבנה הבסיסי, צריך לחזור על נתיבי השיחה כדי לוודא שכל המסלולים האפשריים שהמשתמש יכול לבחור מכוסים.
סוכנים מוכנים מראש
ב-Dialogflow יש סוכנים מוכנים מראש שיעזרו לכם להתחיל. סוכנים מוכנים מראש מכסים תרחישי שימוש נפוצים כמו הזמנת חדר במלון, ניווט וקניות אונליין. הסוכנים האלה כוללים כוונות וישויות שמכסות את השאילתות הנפוצות ביותר של משתמשים. מוסיפים תשובות שספציפיות לעסק שלכם, ותוכלו ליצור במהירות סוכן וירטואלי מתפקד.
ישויות מערכת
כשמשתמש שולח בקשה, צריך לנתח את מה שהוא אמר כדי לחלץ ממנה מידע חשוב. ב-Dialogflow, הן נקראות ישויות. בפרט, ישויות מערכת הן ישויות מובנות מראש שסופקו על ידי Dialogflow ומטפלות בסוגי המידע הפופולריים ביותר.
שיחת חולין
יכול להיות שחשבתם לטפל בבקשות שלא קשורות לנושא כשפיתחתם את הדיאלוג. ב-Dialogflow יש תכונה אופציונלית שנקראת שיחה קלילה. כשהתכונה הזו מופעלת, הסוכן הווירטואלי מגיב לשיחות כלליות, לתגובות רגשיות ולשאלות לגבי הסוכן עצמו. אפשר להתאים אישית את כל התשובות לשיחות קלילות כדי לוודא שהחוויה, בין אם היא קלילה, רצינית או משהו באמצע, מייצגת את המותג שלכם.
שיטות מומלצות לעיצוב סוכנים
בקטע הזה מפורטות שיטות מומלצות ליצירת סוכן חזק, מדויק, יעיל ושימושי.
פתיחים וסיומים
| שיטה מומלצת | פרטים |
|---|---|
| האינטראקציות הראשוניות צריכות להציג למשתמשים את היכולות של הנציג, תוך התחשבות במיתוג. | בכוונת קבלת הפנים של הנציג צריך להופיע מידע על 2-3 משימות שהנציג יכול לעזור בהן, וגם תיאורים קצרים (במידת הצורך) של אופן השימוש בתכונות האלה. |
| סוכנים צריכים להגדיר הודעת סיום מתאימה לאינטראקציה מוצלחת. | כשמשתמש משלים משימה בסוכן, הסוכן צריך לסכם את העסקה או המשימה ולומר משהו כמו "נתראה בפעם הבאה" וכו'. |
למידת מכונה והדרכה
| שיטה מומלצת | פרטים |
|---|---|
| לכל כוונת משתמש צריכות להיות לפחות 10-20 (בהתאם למורכבות הכוונה) ביטויי אימון. | מורכבות הנציג תקבע את המספר בפועל של משפטי אימון שצריכים להיות לכל כוונה, אבל 10-20 (בהתאם למורכבות הכוונה) הוא מספר מינימלי טוב. ככל שיש יותר פרמטרים בכוונה, כך צריך לספק יותר ביטויים כדי לאמן את מודל למידת המכונה. |
| חשוב להשתמש במגוון ביטויים לאימון. | כדי לוודא שהביטויים שלכם יכסו מגוון רחב של בקשות אפשריות, כדאי לכלול וריאציות של שאלות, פקודות, פעלים ומילים נרדפות לשמות עצם נפוצים. |
| ההערות צריכות להיות עקביות. |
|
| השתמשו בהערות בעלות משמעות סמנטית עבור ישויות מערכת. | המשמעות הסמנטית של חלק מביטוי אימון שנבחר להערה יכולה להיות מושפעת משאר הטקסט בביטוי האימון. לדוגמה:
לדוגמה, אל תשתמשו בישות המערכת @sys.duration להערה של הדוגמה הראשונה '7 שנים' שמופיעה למעלה. המשמעות הסמנטית של '7 שנים' לא תואמת למשך זמן פשוט. במקום זאת, צריך להשתמש בישות המערכת @sys.age. |
| יש לכלול מגוון רחב של דוגמאות לישויות מותאמות אישית. | ישויות הן רשימות של פריטים. למידת מכונה תטפל בצורות דקדוקיות, אבל אתם צריכים לכלול את כל הפריטים האפשריים. כדאי גם לסמן את האפשרות הגדרת מילים נרדפות ולכלול כמה וריאציות. |
| השבתה של למידת מכונה בכמה שפחות כוונות. | כשמשביתים את למידת המכונה, לא נעשה שימוש בביטויים לאימון כוונות במהלך אימון הסוכן. שאילתת משתמש שדומה מאוד לביטוי לאימון בכוונת משתמש שהלמידה מחישובים סטטיסטיים מושבתת בה, עשויה להיות מותאמת לכוונת משתמש שגויה אם כוונות משתמש אחרות שהלמידה מחישובים סטטיסטיים מופעלת בהן דומות מעט לשאילתת המשתמש. אם נתקלתם בבעיות שקשורות לזיהוי חיובי שגוי, כדאי להגדיל את סף הסיווג של למידת המכונה במקום להשבית את למידת המכונה. |
| אל תגדירו סף סיווג גבוה לנציג שיש לו רק מעט נתוני אימון. | אם ערך הסף גבוה ואין הרבה נתוני אימון, רק שאילתות משתמשים שיש להן התאמה כמעט מדויקת לביטויי האימון יניבו התאמה לכוונות. אם רוצים להגדיר סף גבוה, צריך לספק הרבה נתוני אימון. |
| לסוכנים צריכה להיות כוונת גיבוי. | בלי כוונות חלופיות, שאילתות משתמשים שלא תואמות לאף כוונה יניבו תשובות ריקות. |
| הסוכנים צריכים לספק דוגמאות שליליות. | דוגמאות שליליות מונעות התאמה לא מכוונת של כוונות לשאילתות משתמשים שדומות מעט לביטויי אימון. |
| אל תגדירו ישויות שתואמות כמעט לכל דבר. | הפעולה הזו פוגעת בביצועים ובאיכות של למידת המכונה. כמעט כל דבר בכל משפט אימון ייבדק כהתאמה אפשרית. במקומה, כדאי להשתמש ב-@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
אם לסוכן שלכם יש הרבה כוונות, כדאי להשתמש בסכימת שמות שתעזור לכם לשמור על סדר. מקובל לפלח שמות של כוונות באמצעות סימני פיסוק, כשהספציפיות עולה משמאל לימין. בנוסף, שם ה-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.