שיטות מומלצות לשימוש בשירותים

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

כדאי גם לעיין במדריך עיצוב כללי של סוכנים לכל סוגי הסוכנים, ובמדריך עיצוב סוכני קול לעיצוב סוכני קול.

העברה לסביבת ייצור

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

הפעלה של יומני ביקורת

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

גרסאות של סוכנים

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

יצירת גיבוי של סוכן

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

שימוש חוזר בלקוח

כדי לשפר את הביצועים של האפליקציה, אפשר לעשות שימוש חוזר ב*Clientמופעים של ספריית לקוח*Clientלמשך משך החיים של ביצוע האפליקציה.

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

לפרטים נוספים, אפשר לעיין במפרט של המאפיין סשנים.

מידע נוסף בנושא זמין במדריך השיטות המומלצות לשימוש בספריות לקוח.

עדכונים של חבילות לסוכן

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

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

  • במקום לשלוח הרבה בקשות EntityTypes‏ create, patch או delete, כדאי להשתמש בשיטות batchUpdate או batchDelete.
  • במקום לשלוח הרבה בקשות Intents‏ create,‏ patch או delete, אפשר להשתמש ב-methods‏ batchUpdate או batchDelete.

ניסיונות חוזרים של שגיאות API

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

בנוסף, כדאי להטמיע השהיה מעריכית לפני ניסיון חוזר (exponential backoff) לניסיונות חוזרים. כך המערכת יכולה למצוא קצב קביל בזמן שעומס כבד מופעל על שירות ה-API.

שגיאות ב-Cloud API

אם אתם משתמשים בספריית לקוח שסופקה על ידי Google, מיושמים בשבילכם ניסיונות חוזרים לתיקון שגיאות ב-Cloud API עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).

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

שגיאות ב-webhook

אם קריאה ל-API מפעילה קריאה ל-webhook, יכול להיות שה-webhook יחזיר שגיאה. גם אם אתם משתמשים בספריית לקוח שסופקה על ידי Google, לא יתבצע ניסיון חוזר אוטומטי לשליחת שגיאות של webhook. הקוד צריך לנסות שוב 503 Service Unavailable שגיאות שהתקבלו מה-webhook. בתיעוד של שירות ה-webhook מוסבר על סוגי השגיאות של webhook ואיך בודקים אותן.

בדיקות עומס

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

סיכום פרטים
הגדלת העומס. בבדיקת העומס, העומס שמופעל על שירות Dialogflow צריך לעלות בהדרגה. השירות לא מיועד לטפל בעומסים פתאומיים, שקורים לעיתים רחוקות בתנועה אמיתית. לוקח זמן עד שהשירות מתאים את עצמו לדרישות העומס, לכן צריך להגדיל את קצב הבקשות בהדרגה עד שהבדיקה תשיג את העומס הרצוי.
הקריאות ל-API כרוכות בתשלום. תחויבו על קריאות ל-API במהלך בדיקה, והקריאות יוגבלו על ידי מכסת הפרויקט.
משתמשים ב-test doubles. יכול להיות שלא תצטרכו לבצע קריאה ל-API במהלך בדיקת העומס. אם המטרה של בדיקת העומס היא לקבוע איך המערכת שלכם מתמודדת עם עומס, לרוב הכי טוב להשתמש בכפיל בדיקה במקום בקריאות בפועל ל-API. הכפיל לבדיקה יכול לדמות את התנהגות ה-API בעומס.
להשתמש בניסיונות חוזרים. בבדיקת העומס צריך לבצע ניסיונות חוזרים עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).

התקשרות מאובטחת אל Dialogflow ממכשיר של משתמש קצה

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

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

ביצועים

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

כשיוצרים כלים למעקב ולהתראות, חשוב לזכור שבדרך כלל מודלים גדולים של שפה (LLM) ועיבוד דיבור מטופלים באמצעות שיטות סטרימינג. התשובות נשלחות ללקוח בהקדם האפשרי, ולעתים קרובות הרבה לפני משך הזמן הכולל של הפעלת method. מידע נוסף זמין במאמר בנושא שיטות מומלצות לשימוש במודלים גדולים של שפה (LLM).

ביצועים לכל פעולה

בטבלה הבאה מפורטים נתוני הביצועים הטיפוסיים של פעולות Dialogflow:

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

נקודות מרכזיות:

  • סטרימינג: בשיחות סטרימינג (זיהוי וסינתזה של דיבור), הנתונים מעובדים כשהם מגיעים, והתשובות מוחזרות בהקדם האפשרי. המשמעות היא שהמענה הראשוני בדרך כלל מהיר בהרבה מהזמן הכולל של השיחה.
  • Playbooks: הנחיה ל-LLM נוצרת על סמך ההוראות ב-Playbook, ההקשר של השיחה והקלט של הכלי. אפשר להריץ כמה הנחיות ל-LLM בקריאה אחת של playbook. לכן, הביצוע של תוכנית הפעולה משתנה בהתאם למספר ההנחיות שניתנו ולמורכבות של הקריאות.

שיקולים חשובים לגבי זמן האחזור

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