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