במאמר הזה מוסבר איך משתמשים בתהליכי עבודה ב-Dialogflow CX כדי ליצור סוכן. הוא מספק סקירה כללית של המושגים החשובים ביותר.
סוכנים
נציג Dialogflow CX הוא נציג וירטואלי שמטפל בשיחות מקבילות עם משתמשי הקצה. זהו מודול להבנת שפה טבעית שמבין את הניואנסים של השפה האנושית. Dialogflow CX מתרגם טקסט או אודיו של משתמשי קצה במהלך שיחה לנתונים מובנים שהאפליקציות והשירותים שלכם יכולים להבין. אתם מתכננים ויוצרים סוכן Dialogflow CX כדי לטפל בסוגי השיחות שנדרשים למערכת שלכם.
סוכן Dialogflow CX דומה לנציג אנושי במוקד טלפוני. אתם מאמנים את שניהם לטפל בתרחישי שיחה צפויים, והאימון לא צריך להיות מפורט מדי.
Flows
בשיחות מורכבות יש בדרך כלל כמה נושאים. לדוגמה, לסוכן משלוחי פיצה יכולים להיות הנושאים הנפרדים הזמנת אוכל, פרטי לקוח ואישור. לכל נושא נדרשות כמה אינטראקציות שיחה כדי שהנציג יקבל את המידע הרלוונטי ממשתמש הקצה.
תהליכים משמשים להגדרת הנושאים האלה ולנתיבי השיחה שמשויכים אליהם. לכל נציג יש תהליך אחד שנקרא Default Start Flow. יכול להיות שהתהליך הפשוט הזה יספיק לכם כדי ליצור סוכן פשוט. יכול להיות שנציגים מורכבים יותר ידרשו זרימות נוספות, וחברי צוות פיתוח שונים יכולים להיות אחראים לבנייה ולתחזוקה של הזרימות האלה. לדוגמה, התרשימים של סוכן משלוחי פיצה יכולים להיראות כך:
Pages
אפשר לתאר ולדמיין שיחה (סשן) ב-Dialogflow CX כמכונת מצבים. המצבים של סשן מיוצגים על ידי דפים.
לכל זרימה, מגדירים הרבה דפים, והדפים המשולבים יכולים לנהל שיחה מלאה בנושאים שהזרימה מיועדת להם. בכל רגע נתון, דף אחד בלבד הוא הדף הנוכחי, הדף הנוכחי נחשב פעיל, והתהליך שמשויך לדף הזה נחשב פעיל. לכל תהליך יש דף התחלה מיוחד. כשתהליך הופך לפעיל בפעם הראשונה, דף ההתחלה הופך לדף הנוכחי. בכל תור בשיחה, הדף הנוכחי יישאר ללא שינוי או יעבור לדף אחר.
אתם מגדירים כל דף לאיסוף מידע מהמשתמשים הרלוונטי למצב השיחה שמיוצג בדף. לדוגמה, יכול להיות שתיצרו את הדפים (בכחול) בתרשים שלמטה לזרימת הזמנת אוכל של סוכן משלוחי פיצה. הצומת Start בתרשים מייצג את דף ההתחלה של התהליך Food Order. בסיום התהליך, המשתמש מועבר לתהליך האישור.
סוגי הישויות
סוגי ישויות משמשים כדי לקבוע איך נתונים מקלט של משתמשי קצה יחולצו.Dialogflow CX מספק ישויות מערכת שהוגדרו מראש ויכולות להתאים לסוגים רבים של נתונים נפוצים. לדוגמה, יש ישויות מערכת להתאמת תאריכים, שעות, צבעים, כתובות אימייל וכו'. אפשר גם ליצור ישויות בהתאמה אישית כדי להתאים נתונים בהתאמה אישית. לדוגמה, אפשר להגדיר ישות של ירקות שיכולה להתאים לסוגי הירקות שזמינים לרכישה באמצעות סוכן של חנות מכולת.
פרמטרים
פרמטרים משמשים לתיעוד ערכים שסופקו על ידי משתמש הקצה במהלך סשן ולהפניה אליהם. לכל פרמטר יש שם וסוג ישות. בניגוד לקלט גולמי של משתמשי קצה, פרמטרים הם נתונים מובנים שאפשר להשתמש בהם בקלות כדי לבצע לוגיקה מסוימת או ליצור תשובות.Forms
לכל דף אפשר להגדיר טופס, שהוא רשימה של פרמטרים שצריך לאסוף מהמשתמש הסופי בדף. הסוכן מנהל אינטראקציה עם משתמש הקצה בכמה תורות שיחה, עד שהוא אוסף את כל פרמטרי הטופס הנדרשים, שנקראים גם פרמטרים של הדף. הסוכן אוסף את הפרמטרים האלה לפי הסדר שמוגדר בדף. לכל פרמטר חובה בטופס, צריך גם לספק הנחיות שהסוכן משתמש בהן כדי לבקש את המידע הזה ממשתמש הקצה. התהליך הזה נקרא מילוי טפסים.
לדוגמה, אפשר ליצור טופס לאיסוף השם ומספר הטלפון של משתמש הקצה בדף Collect Customer Info.
כוונות
כוונה מסווגת את הכוונה של משתמש הקצה בתור אחד של שיחה.
מאפיין הכוונה מכיל את הנתונים הבאים:
| מונח | הגדרה |
|---|---|
| השם המוצג | השם שמוצג במסוף עבור הכוונה. |
| תוויות | תוויות שעוזרות לסווג כוונות. לדוגמה: head intent. |
| ביטויים לאימון | ביטויי אימון הם דוגמאות לביטויים שמשתמשי קצה עשויים להקליד או לומר, שנקראים קלט של משתמשי קצה. כשקלט של משתמש קצה דומה לאחד מהביטויים האלה, מערכת Dialogflow CX מתאימה את הכוונה. אין צורך להגדיר כל דוגמה אפשרית, כי למידת המכונה המובנית של Dialogflow CX מרחיבה את הרשימה עם ביטויים דומים אחרים. |
| פרמטרים | אתם מגדירים את הביטויים לאימון כך שישתמשו בפרמטרים כדי לחלץ ערכים מחלקים ספציפיים בקלט של משתמש הקצה. |
| תבניות DTMF | מידע נוסף על DTMF לשילובים עם טלפוניה זמין במאמר DTMF לשילובים עם טלפוניה. |
Webhook
Webhooks הם שירותים שמארחים את הלוגיקה העסקית שלכם או קוראים לשירותים אחרים. במהלך סשן, ה-webhook מאפשר לכם להשתמש בנתונים שחולצו על ידי עיבוד השפה הטבעית (NLP) של Dialogflow CX כדי ליצור תגובות דינמיות, לאמת נתונים שנאספו או להפעיל פעולות בשרת העורפי.Webhook יכול להיות Webhook רגיל או Webhook גמיש. ב-webhook רגיל, שדות הבקשה והתגובה מוגדרים על ידי Dialogflow CX. ב-webhook גמיש, אתם מגדירים את שדות הבקשה והתגובה.
טיפול בהזמנות
בכל תור לשיחה של נציג, הנציג צריך להשיב למשתמש הקצה על שאלה, על בקשה למידע או על סיום השיחה. יכול להיות שהסוכן יצטרך גם ליצור קשר עם השירות כדי ליצור תגובות דינמיות או לבצע פעולות בתור. Fulfillment משמש להשגת כל זה.
ההשלמה יכולה לכלול כל אחד מהפריטים הבאים:
- הודעות תגובה סטטיות.
- קריאות לפעולות מאתר אחר (webhook) כדי לקבל תשובות דינמיות או לבצע פעולות.
- הגדרות קבועות מראש של פרמטרים להגדרה או לשינוי של ערכי פרמטרים.
במהלך תור של סוכן, אפשר (ולפעמים רצוי) להפעיל כמה תהליכי מילוי, שכל אחד מהם יכול ליצור הודעת תגובה. Dialogflow CX שומר את התשובות האלה בתור תשובות. אחרי שהתור של הסוכן מסתיים, Dialogflow CX שולח את התשובות לפי הסדר למשתמש הקצה.
מעבדי מצב
רכיבי State handlers, שנקראים גם handlers, משמשים לשליטה בשיחה על ידי יצירת תשובות למשתמשי הקצה או על ידי מעבר לדף הנוכחי. בכל תור בשיחה, המערכת מעריכה את ה-handlers, והם עשויים להשפיע על הסשן. יש שלושה סוגים כלליים של נתונים במטפלים:| מונח | הגדרה |
|---|---|
| דרישות לגבי המטפל | אלה הדרישות שצריך לעמוד בהן כדי שה-handler ישפיע על הסשן. אומרים ש-handler מופעל כשהוא עומד בדרישות שלו ומשפיע על הסשן בצורה כלשהי. |
| מילוי הזמנות על ידי מטפל | אם מופעל handler, נעשה שימוש בfulfillment אופציונלי כדי ליצור תשובות למשתמשי הקצה. התשובות האלה מוגדרות בנתונים סטטיים של הסוכן או מאוחזרות באופן דינמי משירות ה-webhook שלכם. |
| יעד מעבר של רכיב Handler | אם מפעילים handler, משתמשים ביעד מעבר אופציונלי כדי לשנות את הדף הנוכחי. הדף הבא יכול להיות רק דף התחלה של תהליך או דף בתהליך הפעיל הנוכחי. |
יש שני סוגים של רכיבי handler של מצב עם דרישות שונות:
| מונח | הגדרה |
|---|---|
| מסלולים | מסלולים מופעלים כשקלט של משתמש קצה תואם לכוונה או כשמתקיים תנאי מסוים בסטטוס הסשן. מסלול עם דרישה לכוונת המשתמש נקרא גם מסלול לכוונת המשתמש. נתיב עם דרישת תנאי בלבד נקרא גם נתיב תנאי. |
| גורמים מטפלים באירועים | גורמים מטפלים באירועים נקראים כשמופעל אירוע. חלק מהאירועים המובנים מופעלים כשמתקבל קלט לא צפוי ממשתמש הקצה, או כשמתרחשת שגיאת webhook. אפשר גם להגדיר אירועים מותאמים אישית שמופעלים כשקורה משהו מחוץ לשיחה. |
תהליך העיבוד של רכיב לניהול מצב כולל שלושה שלבים:
| מונח | הגדרה |
|---|---|
| 1. היקף | כדי שה-handler ישפיע על הסשן, הוא צריך להיות בהיקף. ההיקף נקבע לפי האופן שבו מוחל handler על זרימה, על דף או על פרמטר של טופס, ולפי המצב של הזרימה המשויכת (פעילה או לא), של הדף המשויך (פעיל או לא) או של הסוכן (מנסה כרגע למלא את הפרמטר המשויך של הטופס). |
| 2. הערכה | כל רכיב handler בהיקף נבדק לפי הסדר. אם הדרישות של אמצעי הטיפול מתקיימות, הוא עובר את ההערכה. |
| 3. התקשרות | אם handler נמצא בהיקף ועובר את ההערכה, הוא נקרא. כל פעולת מילוי משויכת מופעלת, וכל יעד מעבר משויך מוחל על הסשן. |
הגדרות אזור והגדרות מיקום
כשיוצרים סוכן, צריך לציין אזור כמיקום שלו. בקשות שנשלחות לסוכן שלכם מטופלות על ידי שירותי Google באזור הזה, ו-Dialogflow CX שומר נתונים במצב מנוחה באופן פיזי בתוך האזור או המיקום הגיאוגרפיים. כדי לקבל את הביצועים הטובים ביותר, כדאי לבחור אזור שקרוב לשירותים ולמשתמשי הקצה.
אחרי שיוצרים סוכן, אי אפשר לשנות את המיקום שלו. כדי לשנות את המיקום של סוכן, צריך לייצא ולשחזר לסוכן חדש עם מיקום שונה.
לכל מיקום יש הגדרות משויכות שחלות על כל הפרויקט. ברוב המקרים, אין צורך לערוך את הגדרות המיקום האלה, והגדרות ברירת המחדל יפעלו בצורה טובה. אם המערכת שלכם דורשת מפתחות הצפנה בניהול הלקוח (לרוב נדרש על ידי ישויות ממשלתיות או תעשיות מפוקחות), תוכלו לקרוא מידע נוסף על הגדרות מיקום.
המסוף
Dialogflow CX מספק ממשק משתמש באינטרנט שנקרא מסוף Dialogflow CX (למשאבי העזרה, לפתיחת המסוף). משתמשים במסוף הזה כדי ליצור, לבנות ולבדוק סוכנים. הוא יוצר תרשים של כל זרימת שיחה כמכונת מצבים שיחתית, כך שקל לעצב ולהבין סוכנים מורכבים.
מסוף Dialogflow CX שונה מ Google Cloud המסוף (למשאבי העזרה, לפתיחת המסוף). מסוף Dialogflow CX משמש לניהול סוכני Dialogflow CX, ומסוף Google Cloud משמש לניהול הגדרות ספציפיות ל- Google CloudDialogflow CX (לדוגמה, חיוב) ומשאבים אחרים של Google Cloud .
ברוב המקרים כדאי להשתמש במסוף Dialogflow CX כדי ליצור סוכנים, אבל אפשר גם להשתמש ב-Dialogflow API כדי ליצור סוכנים לתרחישים מתקדמים.
שילובים
Dialogflow CX מספק כמה שילובים מובנים עם פלטפורמות אחרות לניהול שיחות. השילובים האלה מספקים ממשק משתמש למשתמש הקצה, והם קוראים ל-API בשבילכם. כל מה שצריך לעשות הוא לבנות את הסוכן ולהטמיע שירות webhook (אופציונלי). כל שילוב מטפל באינטראקציות באופן ספציפי לפלטפורמה, ולכן כדאי לעיין במסמכי השילוב הספציפיים כדי לקבל פרטים.
אינטראקציות
בכל תור בשיחה מתרחשת אינטראקציה. במהלך אינטראקציה, משתמש קצה שולח קלט ל-Dialogflow CX, ו-Dialogflow CX שולח תגובה. יש שתי אפשרויות להטמעת המערכת לטיפול באינטראקציות: שימוש ב-API או שימוש בשילוב.
כשמשתמשים ב-API, המערכת צריכה לטפל בפעולות הבאות:
- ליצור סוכן.
- לספק ממשק משתמש למשתמשי קצה.
- שולחים קריאה ל-Dialogflow API בכל תור בשיחה כדי לשלוח את הקלט של משתמש הקצה ל-API.
- אלא אם התשובות של הסוכן שלכם הן סטטיות לחלוטין (לא נפוץ), אתם צריכים לארח שירות webhook כדי לטפל בביצוע הזמנות שמופעלות באמצעות webhook.
כשמשתמשים בשילוב, המערכת צריכה לטפל רק בדברים הבאים:
- ליצור סוכן.
- אפשר להטמיע שירות webhook.
בתרשים הבא מוצגים השלבים שמתרחשים במהלך תור אחד בשיחה.
- משתמש הקצה מקליד או אומר משהו, שנקרא קלט ממשתמש הקצה.
- ממשק המשתמש או מערכת השילוב מקבלים את הקלט ומעבירים אותו אל Dialogflow API בבקשה לזיהוי כוונות.
- Dialogflow API מקבל את הבקשה לזיהוי כוונות. הוא מתאים את הקלט לפרמטר של Intent או טופס, מגדיר פרמטרים לפי הצורך ומעדכן את מצב הסשן. אם צריך להתקשר ל-fulfillment עם webhook, הוא שולח בקשת webhook לשירות ה-webhook שלכם. אחרת, עוברים לשלב 6.
- שירות ה-webhook מקבל את בקשת ה-webhook. השירות מבצע את כל הפעולות הנדרשות, כמו קריאה לממשקי API חיצוניים, שליחת שאילתות למסד נתונים או עדכון שלו וכו'.
- שירות ה-webhook יוצר תגובה ושולח אותה בחזרה ל-Dialogflow CX.
- Dialogflow CX יוצר תגובה לזיהוי כוונות. אם בוצע קריאה ל-webhook, המערכת משתמשת בתשובה שסופקה בתגובת ה-webhook. אם לא הופעל webhook, נעשה שימוש בתגובה סטטית שהוגדרה בסוכן. Dialogflow CX שולח תגובה של זיהוי כוונות לממשק המשתמש או למערכת השילוב.
- ממשק המשתמש או מערכת השילוב מקבלים את התגובה של זיהוי הכוונה ומעבירים את התגובה הטקסטואלית או האודיו למשתמש הקצה.
- משתמש הקצה רואה או שומע את התשובה.