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

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

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

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

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

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

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

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

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

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

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

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

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

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

בוחרים פרוטוקול וגרסה להפניה של הסשן:

פרוטוקול V3 V3beta1
REST Session resource Session resource
RPC ממשק הסשן ממשק הסשן
C++‎ SessionsClient לא זמין
C#‎ SessionsClient לא זמין
המשך SessionsClient לא זמין
Java SessionsClient SessionsClient
Node.js SessionsClient SessionsClient
PHP לא זמין לא זמין
Python SessionsClient SessionsClient
Ruby לא זמין לא זמין

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

ניסיונות חוזרים של שגיאות 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. חשוב להבין את זמן האחזור כדי לתכנן סוכנים שמגיבים במהירות ולהגדיר ציפיות ריאליות לגבי הביצועים, למרות שהערכים האלה לא כלולים בהסכם רמת השירות (SLA) של Dialogflow.

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

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

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

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

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

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

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

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