ארכיטקטורה ומושגי מפתח של Conversational Analytics API

במסמך הזה מוסבר על מושגים מרכזיים לשימוש ב-API של Conversational Analytics (שאפשר לגשת אליו דרך geminidataanalytics.googleapis.com או נקודות קצה אזוריות). ה-API הזה מאפשר ליצור סוכני נתונים ולקיים איתם אינטראקציה. סוכני הנתונים משתמשים בשפה טבעית כדי לענות על שאלות לגבי הנתונים המובְנים שלכם. במסמך הזה מתוארת ארכיטקטורת הסוכן, תהליכי עבודה אופייניים, מצבי שיחה, תפקידים של ניהול זהויות והרשאות גישה (IAM) ועיצוב של מערכת מרובת סוכנים.

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

איך סוכני נתונים עובדים

סוכני נתונים של Conversational Analytics API משתמשים בהקשר (מידע עסקי ונתונים) שאתם מספקים, ובכלים (כמו SQL ו-Python) כדי לפרש שאלות בשפה טבעית וליצור תשובות מהנתונים המובְנים שלכם.

הדיאגרמה הבאה מציגה את השלבים בתהליך העבודה של נציג כשהמשתמש שואל שאלה:

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

1. קלט: המשתמש שולח שאלה בשפה טבעית, יחד עם כל הקשר נוסף שסיפקתם קודם.
2. מקורות נתונים: הסוכן מתחבר לנתונים שלכם ב-Looker, ב-BigQuery (כולל טבלאות או תרשים), ב-Data Studio או במקורות נתונים של מסד נתונים (AlloyDB,‏ GoogleSQL for Spanner,‏ Cloud SQL ל-MySQL ו-Cloud SQL ל-PostgreSQL בגרסת Preview ב-v1beta).
3. מנוע חשיבה רציונלית: ליבת הסוכן מעבדת את השאלה של המשתמש באמצעות כלים זמינים כדי ליצור תשובה.
4. פלט: הסוכן מחזיר זרם של הודעות, שיכולות להכיל טקסט, נתונים או תרשימים. ההודעות האלה עשויות לכלול ציטוטים שמקשרים בין חלקים ספציפיים של טקסט התשובה לבין מקורות ההקשר שסיפקתם, כמו מונחים במילון מונחים או שאילתות לדוגמה. בחלק ממקורות הנתונים, הודעות הטקסט מספקות תובנות מפורטות לגבי ההיגיון של הסוכן, מדווחות על התקדמות בפעולה או מספקות את התשובה הסופית לשאילתה.

תהליכי עבודה לעיצוב סוכנים ולשימוש בהם

ה-API של ניתוח שיחות תומך בתהליכי עבודה של יוצרי סוכנים (שבונים ומגדירים סוכנים) ושל משתמשי סוכנים (שמנהלים אינטראקציה עם סוכנים קיימים).

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

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

תהליך העבודה של יוצר הסוכן

יוצר הסוכן אחראי להגדרת הסוכנים. תהליך העבודה הזה כולל את השלבים הבאים:

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

תהליך העבודה של הלקוח עם הסוכן

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

1. חיפוש סוכן: המשתמש מתחיל בחיפוש סוכן ששותף איתו.
2. שואלים שאלה: המשתמש שואל שאלה בשפה טבעית. השאלה יכולה להיות שאילתה אחת או חלק משיחה רב-שלבית.
3. הסוכן "חושב": מנוע ההיגיון של הסוכן מעבד את השאלה. מנוע החשיבה הרציונלית משתמש בידע המוגדר מראש של הסוכן ובכלים הזמינים של הסוכן (כמו SQL,‏ Python ותרשימים) ב"לולאת חשיבה רציונלית" כדי לקבוע את הדרך הטובה ביותר לענות על השאלה.
4. הסוכן מגיב: הסוכן מחזיר זרם של הודעות, שיכולות להכיל טקסט, נתונים או תרשימים. בחלק ממקורות הנתונים, הודעות הטקסט מספקות תובנות מפורטות לגבי ההיגיון של הסוכן, מדווחות על התקדמות בפעולה או מספקות את התשובה הסופית לשאילתה.

מצבי שיחה

סוכני AI של Conversational Analytics API תומכים במצבי שיחה שונים שקובעים איך הסוכן מטפל בהיסטוריית השיחות ובשמירת ההקשר בין האינטראקציות. אלה מצבי השיחה שזמינים:

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

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

תפקידי IAM

תפקידי IAM קובעים מי יכול ליצור סוכנים של Conversational Analytics API, לנהל אותם, לשתף אותם ולקיים איתם אינטראקציה. בטבלה הבאה מפורטים התפקידים העיקריים ב-IAM עבור Conversational Analytics API:

תפקיד	היקף אופייני	מה התפקיד מאפשר	מי יכול להשתמש בתפקיד הזה
‫Gemini Data Analytics Data Agent Creator (roles/geminidataanalytics.dataAgentCreator)	פרויקט	ליצור סוכנים ולקבל בירושה הרשאות בעלים בסוכן.	כל מנתח נתונים
בעלים של סוכן נתונים של Gemini Data Analytics‏ (roles/geminidataanalytics.dataAgentOwner)	פרויקט, סוכן	עריכה, שיתוף או מחיקה של סוכנים עם משתמשים אחרים.	מנתח נתונים בכיר
עריכה ב-Gemini Data Analytics Data Agent Editor (roles/geminidataanalytics.dataAgentEditor)	סוכן, פרויקט	עדכון ההגדרות או ההקשר של סוכן.	מנתח נתונים מתחיל
‫Gemini Data Analytics Data Agent User (roles/geminidataanalytics.dataAgentUser)	סוכן, פרויקט	צ'אט עם נציג.	משווק, בעל חנות
‫Gemini Data Analytics Data Agent Viewer‏ (roles/geminidataanalytics.dataAgentViewer)	פרויקט, סוכן	הצגת רשימת הסוכנים וקבלת הפרטים שלהם. אי אפשר לערוך את הסוכן.	כל משתמש
משתמש בשאילתות נתונים ב-Gemini Data Analytics‏ (roles/geminidataanalytics.queryDataUser)	פרויקט	שליחת שאילתות לנתונים ממקורות מסדי נתונים נתמכים באמצעות השיטה QueryData.	מפתח אפליקציות, מנתח נתונים
משתמש ב-Gemini Data Analytics ללא שמירת מצב (roles/geminidataanalytics.dataAgentStatelessUser)	פרויקט	צ'אט עם נציג בלי לשמור את ההקשר או את היסטוריית השיחות.	כל משתמש

מערכות עם כמה סוכנים

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

ה-API של ניתוח שיחות תומך בפרוטוקול הפתוח Agent-to-Agent (A2A), שמספק ממשק סטנדרטי לגילוי יכולות, להעברת שאילתות ולהזרמת פריטי מידע מובְנים של SQL ושל תרשימים בין סוכנים. כדי ללמוד איך להטמיע תהליכי עבודה מרובי סוכנים באמצעות פרוטוקול A2A, אפשר לעיין במאמר תיאום בין סוכני נתונים באמצעות A2A.

בתרשים הבא מוצג דפוס רב-סוכני, ומוסבר איך סוכן ראשי יכול להעביר שאלה לגבי נתונים לסוכן מומחה של Conversational Analytics:

תהליך העבודה הטיפוסי במערכת מרובת סוכנים כולל את השלבים הבאים:

1. משתמש עסקי או אנליסט נתונים שואל שאלה בשפה טבעית, למשל: "תראה לי את שלוש החנויות המובילות לפי הכנסות".
2. סוכן 'תזמור' ראשי מעביר את הבקשה לסוכן המתאים שמתמחה בנושא.
3. סוכן ייעודי מקבל את הבקשה שהועברה אליו, מתחבר למקורות הנתונים הרלוונטיים, משתמש בכלים שלו כדי ליצור את שאילתות ה-SQL והתרשימים הנדרשים, ומפיק תשובה.
4. התשובה של הסוכן המומחה מוחזרת למשתמש, למשל: "החנויות 4, 9 ו-3 מניבות את ההכנסה הגבוהה ביותר. הנה תרשים".

המאמרים הבאים

אחרי שמבינים את המושגים העיקריים של Conversational Analytics API, אפשר ללמוד איך להטמיע את התכונות האלה:

• איך מתזמנים סוכני נתונים באמצעות A2A
• משווים בין תבניות שילוב של ארכיטקטורות כדי לקבוע מהי הגישה הכי טובה לאפליקציה.
• להבין את ניהול המצב של סוכני נתונים ואיך ה-API מנהל את ההקשר של השיחה.
• איך מאמתים ומתחברים למקור נתונים
• איך יוצרים סוכן ומגדירים אותו באמצעות HTTP
• איך יוצרים וקובעים הגדרות לסוכן באמצעות Python
• מידע נוסף על הנחיית התנהגות של סוכן באמצעות הקשר שנוצר
• הסבר על בקרת גישה באמצעות IAM ל-Conversational Analytics API
• איך מגינים על סוכני הנתונים והשיחות באמצעות CMEK
• איך מעבדים תשובות של סוכנים למקורות נתונים של Looker