כשמפתחים באמצעות Conversational Analytics API, ניהול מצב הוא שיקול ארכיטקטוני חשוב. אתם מנהלים את מצב השיחה של ה-API, ואם מדובר באפליקציות שמשתמשות בערכה לפיתוח סוכנים (ADK), אתם מנהלים גם את מצב הסשן של המסגרת.
מצבי סטטוס של API
השיטה chat ב-Conversational Analytics API תומכת בפרמטרים של הקשר שאינם תלויים זה בזה, שקובעים איך לטפל במצבי שיחה.
בעזרת הטבלה הבאה אפשר להשוות בין המצבים האלה:
| מצב | מדינה | היסטוריית השיחות | סוכן | פרמטר | תיאור |
|---|---|---|---|---|---|
| צ'אט עם הפניה לשיחה | עם שמירת מצב | מנוהל על ידי ה-API | כן | ConversationReference |
המשך שיחה עם שמירת סטטוס על ידי הפניה לשיחה קיימת ולסוכן המשויך שלה. Google Cloud מאחסן ומנהל את היסטוריית השיחות. אתם שולחים רק את ההודעה החדשה בכל תור. |
| צ'אט עם נציג נתונים | בלי שמירת מצב | מנוהל על ידי האפליקציה | כן | DataAgentContext |
שולחת הודעה ללא מצב (stateless) שמפנה לסוכן נתונים שנשמר כדי לקבל הקשר. האפליקציה צריכה לנהל ולספק את היסטוריית השיחות המלאה בכל בקשה. |
| צ'אט עם הקשר מוטבע | בלי שמירת מצב | מנוהל על ידי האפליקציה | לא | InlineContext |
שולחת הודעה חסרת מצב שמספקת את כל ההקשר ישירות בבקשה. במצב הזה לא נעשה שימוש בסוכן נתונים שמור. האפליקציה שלכם צריכה לנהל את היסטוריית השיחות המלאה ולספק אותה. |
מצב הסשן ב-ADK
אם אתם משתמשים ב-framework של ADK לאורקסטרציה, ה-ADK מספק שכבת ניהול מצב שפועלת באופן עצמאי ממצב ה-API של ניתוח שיחות. כדי לבנות מערכות מרובות סוכנים שפועלות בצורה תקינה, חשוב להבין את שתי השכבות.
ה-ADK משתמש במוסכמות של קידומות מפתחות כדי לשלוט בהיקף ובמשך החיים של משתני מצב. כדי להעריך את היקפי ההרשאות האלה, אפשר להיעזר בטבלה הבאה:
| תחילית של מפתח | היקף | כל התאריכים | גלוי ל | דוגמאות |
|---|---|---|---|---|
| (ללא קידומת) | אירוע | רק בסשן הנוכחי | כל הנציגים בסשן | הנושא של השיחה הנוכחית או התוצאות של השאילתה האחרונה |
user: |
משתמש | בכל הסשנים של אותו משתמש | כל הסוכנים והסשנים של המשתמש שצוין | העדפות משתמש, מזהים של סוכני נתונים שנשמרו או הגדרות שפה |
app: |
בקשת הצטרפות | בכל הסשנים של כל המשתמשים | כל הנציגים וכל המשתמשים | הגדרת אפליקציה גלובלית, מזהי סוכן של נתונים משותפים או דגלים של תכונות |
temp: |
הפעלה | הפעלה נוכחית בלבד | הסוכן הנוכחי בהפעלה הפעילה | נתוני תגובה ביניים, כמו נתחי סטרימינג או חישובים בתהליך |
מידע נוסף על שיתוף מצב במערכות מרובות סוכנים זמין במסמכי ה-ADK.
איך הסטטוס של ה-API והסטטוס של ה-ADK פועלים יחד
כשמשתמשים ב-Conversational Analytics API עם ה-framework של ADK, שכבות המצב פועלות באופן עצמאי:
- מצב ה-API: אם האפליקציה שלכם משתמשת בהפניות לשיחות (מצב עם שמירת נתונים), ה-API מנהל את היסטוריית השיחות. אם האפליקציה שלכם משתמשת בהקשר של סוכן נתונים או בהקשר מוטבע (מצבים בלי שמירת מצב), ה-API נשאר בלי שמירת מצב לכל קריאה.
- מצב הסשן של ADK: מסגרת ADK מנהלת סשן, אירועים ומשתני מצב משלה, ללא קשר למצב שבו נעשה שימוש ב-Conversational Analytics API.
לדוגמה, כשמשתמשים בכלים ask_data_insights או ask_data_agent ב-ADK, כל קריאה היא עצמאית ובלי שמירת מצב ברמת ה-API, למרות ש-ADK שומר על הקשר הרחב יותר של הסשן. הדמו של הזרמת ADK ממחיש את התבנית המומלצת לאינטראקציה הזו: סוכן משנה של נתונים כותב נתוני תגובה שנותחו למצב temp:, שסוכנים במורד הזרם קוראים אותם באותו קריאה לפונקציה.
המאמרים הבאים
- משווים בין דפוסי שילוב ארכיטקטוניים כדי לקבוע את הגישה הכי טובה לאפליקציה.
- מידע על הארכיטקטורה של Conversational Analytics API ועל מושגים מרכזיים
- איך מאמתים ומתחברים למקור נתונים
- איך יוצרים סוכן ומגדירים אותו באמצעות HTTP
- איך יוצרים וקובעים הגדרות לסוכן באמצעות Python
- מידע נוסף על הנחיית התנהגות של נציג באמצעות הקשר שנוצר
- הסבר על בקרת גישה באמצעות IAM ל-Conversational Analytics API
- איך מגינים על סוכני הנתונים והשיחות באמצעות CMEK
- איך מעבדים תשובות של סוכנים למקורות נתונים של Looker