דפוסי שילוב של סוכני נתונים

בדף הזה מתוארים דפוסי שילוב להטמעת חוויות של סוכני נתונים באפליקציות. הדפוסים האלה משתנים ברמת המורכבות שלהם, החל מרכיב צ'אט מוטמע ועד למערכת מרובת סוכנים (MAS).

המדריך הזה מיועד לאדריכתי ענן ולמהנדסי נתונים שמתכננים אפליקציות מבוססות-AI גנרטיבי. צריכה להיות לכם הבנה בסיסית של Google Cloud מושגים, ניהול זהויות והרשאות גישה (IAM) וממשקי REST API. כדאי גם להכיר את הארכיטקטורה של מקור הנתונים שבו האפליקציה משתמשת.

סקירה כללית של דפוסי שילוב

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

  • Looker track: בוחרים באפשרות הזו אם רוצים לספק פונקציונליות של צ'אט באמצעות הטמעה של Looker,‏ Looker API או Conversational Analytics API.
  • BigQuery ומסד נתונים: בוחרים באפשרות הזו אם אתם בונים אפליקציה בהתאמה אישית שמשתמשת ב-BigQuery, ב-Data Studio או במסד נתונים תפעולי נתמך.

בטבלה הבאה מפורטים דפוסי השילוב הזמינים:

תבנית שילוב תיאור מקור הנתונים
הטמעה של iframe ב-Looker הוספת ממשק צ'אט רגיל לאפליקציה שדורשת מינימום קוד. Looker
‫Looker API ו-SDK יצירת ממשק צ'אט בהתאמה אישית שמשתמש ב-Looker API לאימות. Looker
‫Conversational Analytics API (מקור Looker) ניהול סוכני נתונים של Looker כמשאבים Google Cloud שפועלים בכמה פלטפורמות ובמערכות מרובות סוכנים. Looker
Direct API (single-agent) משתמשת בשילוב ישיר של API לזרימות של טקסט לתשובה. ‫BigQuery, מסדי נתונים, Looker
‫Direct API (orchestrator) מנתב שאילתות בין ה-API לבין כלים אחרים באמצעות בקשות להפעלת פונקציות. ‫BigQuery, מסדי נתונים, Looker
‫ADK (מבוסס סכימה) עם BigQueryToolset יצירת תובנות מהירות מהפניות בטבלה באמצעות הכלי ask_data_insights. BigQuery
‫ADK (מנוהל) עם DataAgentToolset השאילתות מוגדרות מראש לסוכני נתונים שמשתמשים בכלי ask_data_agent כדי להבטיח התנהגות עקבית. ‫BigQuery, מסדי נתונים, Looker
‫ADK (סטרימינג בהתאמה אישית) תומך בהזרמה בזמן אמת של תרשימים ו-SQL באמצעות מחלקה מותאמת אישית של סוכן. ‫BigQuery, מסדי נתונים, Looker
MCP עם McpToolset או ToolboxToolset חיבור אפליקציות לכלים לנתונים שמשתמשים ב-Model Context Protocol‏ (MCP). BigQuery Looker
פרוטוקול A2A מאפשר שיתוף פעולה מאובטח בין סוכנים ייעודיים שפועלים במערכות שונות. תלות ב-Framework

אפשרויות שילוב ל-Looker

אם אתם משתמשים ב-Looker, אתם יכולים לספק למשתמשים שלכם את ניתוח נתונים שיחתי ב-Looker באמצעות הדפוסים הבאים:

סיכום של דפוסי שילוב עם Looker

בטבלה הבאה מפורטים דפוסי השילוב העיקריים של Looker:

דוגמת קוד מתאים במיוחד בשביל יתרונות לתשומת ליבכם
הטמעה באמצעות iframe: שיטה עם תכנות מינימלי להוספה מהירה של חוויית הצ'אט הסטנדרטית של Looker לאפליקציה. צוותים שזקוקים לחוויית ניתוח נתונים של שיחות שמוכנה לשימוש עם מינימום פיתוח בהתאמה אישית.
  • ההטמעה שלו דורשת קוד מינימלי.
  • מחיל אוטומטית את מודל האבטחה הקיים של Looker.
  • לא נדרש אימות נפרד של Google Cloud .
  • תמיכה ב-Looker Embed SDK, שמאיץ את הפיתוח על ידי ניהול מחזורי חיים של iframe והעברת אירועים.
  • האפשרויות להתאמה אישית של ממשק המשתמש מוגבלות, והוא מבוסס על ממשק המשתמש הרגיל של הצ'אט ב-Looker.
  • המכונה של Looker צריכה להיות מאוחסנת ב-Looker.
פיתוח באמצעות Looker API וערכות SDK: גישה גמישה לפיתוח ממשק צ'אט בהתאמה אישית, תוך שמירה על אימות וניהול סוכנים בתוך Looker. צוותים שנדרשת להם חוויית משתמש מותאמת אישית בצ'אט, אבל רוצים לשמור על אימות משתמשים וניהול סוכנים בסביבה העסקית של Looker. התבנית הזו מתאימה במיוחד לאפליקציות שכבר משתמשות בהטמעה של Looker או ב-API.
  • מספקת שכבת אימות אחת ושליטה מלאה בממשק המשתמש.
  • מפשט את הארכיטקטורה של לקוחות Looker קיימים.
  • משתמש בשכבה הסמנטית של Looker כדי לשפר את הדיוק של השאילתות.
  • לא נדרש אימות נפרד של Google Cloud .
  • נדרשת מומחיות בפיתוח Looker API.
  • האפשרות הזו מוגבלת למקורות נתונים של Looker.
  • הסוכנים מנוהלים ב-Looker ולא ניתן להעביר אותם לשירותים אחרים של Google Cloud Google.
שימוש ב-Conversational Analytics API: שילוב ישיר עם ה-API לניהול סוכנים כמשאבים ברמת הענן. לקוחות Looker שנדרשת להם ניידות בין פלטפורמות לסוכני הנתונים שלהם.
  • הסוכן מבטיח ניידות של הנתונים בכל הפלטפורמות של Google Cloud Google.
  • מנוהל באופן מרכזי על ידי IAM.
  • מאפשר לשלב סוכני נתונים בתהליכי עבודה של ADK או MCP.
  • האפשרות הזו מחייבת ניהול של כל חבילת השילוב, כולל אימות של Google Cloud ושל Looker.
  • ניהול סוכני הנתונים מתבצע בנפרד מממשק המשתמש של Looker.

הטמעה באמצעות iframes

אתם יכולים להטמיע את ניתוח הנתונים בשיחה כ-iframe כדי לספק את חוויית הצ'אט מחוץ לממשק המשתמש של Looker. הדפוס הזה הוא דרך ישירה לספק ניתוח שיחות שלא דורש פיתוח ממשק משתמש בהתאמה אישית, תזמור של קצה העורפי או ניהול מצב של API. כדי להשתמש בתבנית הזו, מוסיפים לאפליקציה כתובת URL מעוצבת מראש.

‫Embed SDK של Looker מספק כלים לניהול משימות כמו יצירה מאובטחת של כתובות URL, ניהול מחזור החיים של iframe והעברת אירועי JavaScript בין אפליקציית המארח לבין ה-iframe. אתם יכולים להטמיע את הדף סוכנים, את הדף שיחות או שיחה ספציפית על ידי הוספת כתובת URL מעוצבת מראש לאפליקציה.

אפשר להשתמש בשיטות האימות הבאות לתוכן מוטמע:

  • הטמעה פרטית: מאמתת משתמשים באמצעות פרטי הכניסה הקיימים שלהם ל-Looker. כשמגדירים את כתובת ה-URL להטמעה כמקור של ה-iframe, המשתמשים נכנסים באמצעות חשבונות Looker שלהם. בשיטה הזו, המערכת אוכפת באופן אוטומטי תפקידים קיימים, גישה לתוכן והרשאות ברמת הנתונים, כמו מסנני גישה או מענקי גישה, בלי שנדרשת הגדרה נוספת של IAM או מיפוי טוקנים.
  • הטמעה עם חתימה: אימות משתמשים דרך האפליקציה באמצעות כניסה יחידה (SSO). אתם יוצרים כתובת URL חתומה שכוללת את נתיב התוכן של Conversational Analytics, וכך יכולים לציין באופן דינמי בדיוק אילו הרשאות להעניק.

פיתוח באמצעות Looker API וערכות SDK

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

השילוב עם Looker API מספק את היתרונות הבאים:

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

למידע על הטמעה לדוגמה, אפשר לעיין במדריך Conversational Analytics Looker API ב-GitHub.

שימוש ב-Conversational Analytics API עם נתונים מ-Looker

אם אתם צריכים לבצע אחת מהמשימות הבאות, תוכלו לבצע שילוב ישירות עם Conversational Analytics API בכתובת geminidataanalytics.googleapis.com:

  • לשתף את אותו סוכן נתונים בכמה ממשקי Google Cloud משתמש, כמו אפליקציות אינטרנט בהתאמה אישית, Google Chat ו-Gemini Enterprise.
  • לשלב מקורות נתונים של Looker עם מקורות של BigQuery או של מסד נתונים תפעולי במערכת רב-סוכנים אחת.
  • ניהול סוכן הנתונים כמשאב ברמת הענן שכפוף ל-IAM ולא למודל ההרשאות של Looker.

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

אפשרויות שילוב ל-BigQuery, ל-Data Studio ולמסדי נתונים

בקטע הזה מתוארים דפוסי ארכיטקטורה של אפליקציות שמשתמשות ב-BigQuery, ב-Data Studio או במסדי נתונים תפעוליים נתמכים Google Cloud כדי ליצור חוויות בהתאמה אישית באמצעות Conversational Analytics API.

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

השיטות העיקריות לאינטראקציה עם נתונים ב-Conversational Analytics API הן:

  • ‫chat method: תומך ב-BigQuery, ב-Looker, ב-Data Studio ובמסדי נתונים תפעוליים.
  • שיטת queryData: תומכת במסדי נתונים תפעוליים כמו AlloyDB,‏ GoogleSQL ל-Spanner,‏ Cloud SQL ל-MySQL ו-Cloud SQL ל-PostgreSQL.

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

  • שילוב ישיר של API: גישה מותאמת אישית שמאפשרת הכי הרבה גמישות, אבל מחייבת אתכם לבנות את התשתית לאימות, לניהול שיחות ולניתוח תשובות.
  • תיאום מבוסס-מסגרת (ADK): גישה שמשתמשת בערכה לפיתוח סוכנים (ADK) לניתוב בין סוכנים, להפעלת כלים ולניהול מצב.
  • שילוב אנכי (MCP): גישה שמשתמשת ב-Model Context Protocol‏ (MCP) כדי לספק דרך אחידה לחבר אפליקציות AI לכלים ולמקורות נתונים בסביבות שונות.
  • תיאום אופקי (A2A): גישה שמשתמשת בפרוטוקול Agent-to-Agent (A2A) כדי לאפשר לסוכנים מיוחדים במערכות שונות לשתף פעולה בצורה מאובטחת בלי לדרוש קוד שילוב בהתאמה אישית.

סיכום של דפוסי שילוב של BigQuery ומסדי נתונים

בטבלה הבאה מפורטים דפוסי ההטמעה הספציפיים ל-BigQuery ולמסדי נתונים תפעוליים:

דוגמת קוד מתאים במיוחד בשביל יתרונות לתשומת ליבכם
שילוב של סוכן יחיד (API ישיר): תבנית שבה האפליקציה קוראת ל-API ישירות כדי להחזיר תובנות ממקורות הנתונים. אפליקציות עם סוכן יחיד, אבות טיפוס או מיקרו-שירותים שנדרש בהם שליטה ישירה בכל קריאה ל-API.
  • מאפשר שליטה מפורטת בלי תלות במסגרת.
  • מספק את הארכיטקטורה הפשוטה ביותר לתרחישי שימוש בסוכן יחיד.
  • יש תמיכה במצבים עם שמירת נתונים ובמצבים ללא שמירת נתונים.
  • נדרש לבנות את כל התשתית לאימות, לניהול מצב, לניתוח תגובות, לטיפול בשגיאות, להזרמה ולפריסה.
  • לא מתאים לתרחישים שבהם יש כמה סוכנים.
אורקסטרטור בהתאמה אישית (API ישיר): תבנית שמשתמשת בסוכן ראשי ובקריאת פונקציות כדי לנתב שאילתות בין Conversational Analytics API לבין כלים או שירותים אחרים. אפליקציות שמשלבות שאילתות נתונים עם משימות אחרות, כמו אימייל או מסמכים, בתהליך שיחה יחיד.
  • מספק שליטה מקסימלית בתיאום ללא תלות במסגרת.
  • מאפשרת להגדיר בדיוק איך המודל עובר בין הכלים.
  • פועל עם כל מודל Gemini.
  • נדרש ניהול ידני של הגדרות הכלים, לולאות השיחה, מצב רב-שלבי, טיפול בשגיאות ופריסה.
  • התקורה של הפיתוח עלולה להיות גבוהה בהשוואה לשימוש במסגרת כמו ADK.
שילוב מבוסס סכימה עם BigQueryToolset (ADK): תבנית שמשתמשת בהפניות לטבלאות כדי להחזיר תובנות לגבי נתונים במהירות. אב טיפוס מהיר, כלים פנימיים שבהם משילות מידע פחות קריטית, או תרחישים שבהם תובנות מנתונים הן אחת מכמה יכולות בסוכן ADK.
  • האפשרות הזו מספקת את נתיב השילוב המהיר ביותר במסגרת ADK.
  • לא נדרשת הגדרה מראש של סוכן נתונים.
  • פועל ישירות עם שמות של טבלאות במסד נתונים.
  • אין לו יכולות של ניהול סמנטי, והוא יוצר SQL רק מתוך היסק סכמטי.
  • פועל במצב בלי שמירת מצב ברמת ה-API.
  • מספק תשובות מבוססות-טקסט בלבד ולא תומך בתרשימים.
שילוב מנוהל עם DataAgentToolset (ADK): תבנית ששולחת שאילתה לסוכן נתונים שהוגדר מראש באמצעות הפניה למזהה של הסוכן. אפליקציות לייצור שדורשות גישה עקבית לנתונים או מערכות מרובות סוכנים שבהן סוכן הנתונים הוא רכיב מהימן לשימוש חוזר.
  • מספק ניהול סמנטי והתנהגות עקבית לכל הצרכנים.
  • הדיוק משתפר באמצעות שאילתות מאומתות ומילון המונחים הארגוני.
  • היא מוודאת שאפשר לעשות שימוש חוזר בסוכני נתונים ב-ADK, ב-MCP ובשילובים ישירים של API.
  • נדרשת הגדרה מראש של משאבי סוכן הנתונים.
  • פועל במצב בלי שמירת מצב ברמת ה-API.
  • התשובות הן טקסט בלבד, ואין תמיכה בתרשימים.
‫Custom sub-agents (ADK): תבנית שמשתמשת במחלקת סוכן בהתאמה אישית כדי להתחבר ישירות ל-API ולהזרים נתחים של נתונים בחזרה למשתמש. אפליקציות שפונות למשתמשים שבהן זמן האחזור הנמוך בתגובה הוא בעדיפות גבוהה, או צינורות (pipelines) של כמה סוכנים שבהם אחזור נתונים מזין סוכנים במורד הזרם.
  • התלמידים מקבלים משוב בזמן אמת.
  • גישה לכל סוגי התשובות, כמו תרשימים, טבלאות ו-SQL.
  • אפשר להרכיב אותו עם סוכני ADK אחרים באמצעות מצב הסשן.
  • נדרש מאמץ פיתוח רב יותר כדי ליצור מחלקה של סוכן ADK בהתאמה אישית.
  • האפשרות הזו מחייבת ניהול ישיר של חיבור הסטרימינג וניתוח התגובה.
‫Model Context Protocol‏ (MCP): תבנית שמשתמשת בתקן פתוח כדי לחבר אפליקציות AI למקורות נתונים ולכלים בסביבות שונות. ארגונים שנדרשת בהם יכולת פעולה הדדית של כלים בכמה לקוחות AI וסביבות IDE, או צוותים שצריכים גישה לאותם כלי נתונים ממסגרת ADK, מסביבות IDE ומאפליקציות בהתאמה אישית.
  • השימוש בתקן כלים אוניברסלי שפועל עם כל לקוח שתואם ל-MCP.
  • ההטמעה של כלי לא קשורה לאפליקציות צרכניות.
  • מציע אפשרויות של שרתים מנוהלים, כמו שרת ה- Google Cloud MCP.
  • נדרשת שכבת תשתית נוספת לשרת של ערכת הכלים.
  • השילוב פחות הדוק מאשר בערכות הכלים של ADK.
  • תלוי במערכת האקולוגית המתפתחת של MCP Toolbox.
  • פועל במצב בלי שמירת מצב שמחייב ניהול חיצוני של מצב שיחה רב-שלבי.
‫Agent-to-Agent (A2A): תבנית שמשתמשת בפרוטוקול A2A, תקן פתוח שמאפשר לסוכנים מיוחדים במערכות שונות לשתף פעולה בצורה מאובטחת בלי לדרוש קוד שילוב בהתאמה אישית. סביבות ארגוניות מבוזרות מאוד שבהן סוכן ניתוב מרכזי צריך להקצות משימות לסוכני נתונים שפועלים במערכות או ברשתות שונות.
  • מפחית את הצורך בקוד שילוב מותאם אישית בין מסגרות שונות.
  • היא מאפשרת פעולה הדדית חלקה בין פלטפורמות שונות.
  • מספק גילוי מאובטח וסטנדרטי של יכולות.
  • זמן האחזור ברשת קצר יותר בהשוואה לסוכני משנה פנימיים.
  • כדי לעשות את זה צריך להגדיר את הגדרות השרת של A2A.

שילוב ישיר של API

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

הנושאים בקטע הזה:

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

שילוב של סוכן יחיד

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

התבנית הזו תומכת בצ'אט עם שמירת מצב, שבו Google מנהלת את היסטוריית השיחות, ובצ'אט בלי שמירת מצב, שבו האפליקציה שלכם מנהלת את ההיסטוריה.

לעיון בהטמעות לדוגמה, אפשר לעבור אל המדריך לתחילת העבודה עם Conversational Analytics API או אל הדמו המצוין של Conversational Analytics API ב-GitHub.

שילוב של כלי לניהול סוכנים בהתאמה אישית

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

בקשה להפעלת פונקציה כוללת את השלבים הבאים:

  1. הצהרה: הגדרת סכימות של כלים כאובייקטים מסוג FunctionDeclaration שכוללים הגדרות של פרמטרים.
  2. הפעלה: המודל מחזיר הודעה מובנית functionCall שמכילה את שם הפונקציה והארגומנטים.
  3. ביצוע: האפליקציה מבצעת את הקריאה ל-API ומחזירה את התוצאה בהודעה FunctionResponse.
  4. סינתזה: מודל Gemini משתמש בתוצאה כדי ליצור תשובה סופית או כדי לקבוע את הפעולה הבאה.

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

לדוגמה להטמעה, אפשר לעיין בדפים orchestrate או multimodal בהדגמה המושלמת של Conversational Analytics API ב-GitHub.

תזמור מבוסס-מסגרת (ADK)

הערכה לפיתוח סוכנים (ADK) היא פלטפורמה שמתבססת על קוד ליצירת סוכני AI, שמנהלת את המורכבות של ניתוב בין סוכנים, הפעלת כלים וניהול מצב. מסגרת ה-ADK היא אותה מסגרת שמפעילה את Gemini Enterprise.

באמצעות ADK, אפשר לשרשר את Conversational Analytics API עם כלים וסוכנים אחרים כדי לבצע פעולות מורכבות.

הנושאים בקטע הזה:

שילוב מבוסס סכימה עם BigQueryToolset

ערכת הכלים BigQueryToolset ב-ADK כוללת את הכלי ask_data_insights שנוצר מראש. כדי להשתמש בכלי הזה, מעבירים לו שמות של טבלאות ואת השאלה של המשתמש. הכלי קורא ל-Conversational Analytics API באמצעות הקשר מוטבע.

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

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

שילוב מנוהל עם DataAgentToolset

ערכת הכלים DataAgentToolset במסגרת ADK מספקת שילוב מוכן מראש שמפנה לסוכן נתונים שהוגדר מראש באמצעות המזהה שלו. הסוכן ADK מעביר את השאלה של המשתמש לכלי ask_data_agent, שקורא ל-Conversational Analytics API עם ההקשר שצוין של סוכן הנתונים.

אפשר ליצור סוכן נתונים באופן פרוגרמטי באמצעות Conversational Analytics API או דרך קטלוג הסוכנים במסוף Google Cloud . סוכן נתונים מגיע עם הרכיבים הבאים:

  • מקורות מידע: טבלאות, תצוגות או פונקציות בהגדרת משתמש (UDF) שהסוכן יכול לשלוח להן שאילתות
  • הקשר מובנה: תיאורים של טבלאות ועמודות שעוזרים לסוכן להבין את הנתונים הבסיסיים
  • הוראות: הנחיות נוספות לסוכן לפרש את מקורות הנתונים ולשאול אותם שאלות
  • שאילתות מאומתות: שאילתות SQL שעברו אימות מראש ומשמשות כדוגמאות לשאלות נפוצות
  • מילון מונחים: הגדרות של מונחים עסקיים שעוזרות לסוכן להבין את השפה הספציפית לתחום

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

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

שילוב מתקדם של UX עם סוכני משנה בהתאמה אישית

ערכות הכלים BigQueryToolset ו-DataAgentToolset לא מחזירות תוצאות למשתמש עד שעיבוד בקשת ה-API מסתיים. מכיוון ש-ADK framework מתייחס ל-API כאל כלי שחוסם תשובות עד לסיום, יכול להיות שמשתמשים לא יקבלו משוב על שאילתות שפועלות זמן רב יותר.

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

  • הודעות מחשבה: תהליך החשיבה של סוכן הנתונים בזמן שהוא מפרש את השאלה.
  • הודעות התקדמות: עדכוני סטטוס במהלך אחזור הנתונים ממקורות נתונים.
  • יצירת שאילתות: שאילתת ה-SQL או Looker שנוצרה, שמוזרמת בזמן שהיא נוצרת.
  • נתונים: תוצאות הנתונים בפורמט JSON.
  • Visualization: מפרטים של תרשימי Vega-Lite.
  • סיכום: התשובה הסופית שמבוססת על טקסט.

רשימה מלאה של סוגי הנתונים שמוחזרים מופיעה בסוג SystemMessage במסמכי העזר של ה-API.

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

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

שילוב אנכי (MCP)

‫Model Context Protocol‏ (MCP) הוא תקן פתוח שמאפשר לאפליקציות מבוססות-AI להתחבר בצורה אחידה לכלים ולמקורות נתונים חיצוניים. פרוטוקול MCP מבצע סטנדרטיזציה של הממשק בין מודלים של AI לבין הכלים שבהם הם משתמשים.

הנושאים בקטע הזה:

‫MCP Toolbox for Databases

אין שרת MCP ייעודי ל-Conversational Analytics API, אבל אפשר לגשת ל-API דרך השרת MCP Toolbox for Databases. השרת הזה בקוד פתוח מספק כלים מוכנים מראש ותואמים ל-MCP שחושפים את השיטה chat ב-Conversational Analytics API:

‫MCP היא שכבת יכולת פעולה הדדית שחושפת יכולות ניתוח ככלים ללקוחות שתואמים ל-MCP, ולא כמודל ביצוע נפרד של Conversational Analytics API.

דפוסי הטמעה של MCP בארכיטקטורות עצמאיות ובארכיטקטורות ADK

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

דוגמת קוד פרטים
MCP עצמאי (ללא ADK)

אפשר להשתמש בשרת MCP Toolbox for Databases כשרת עצמאי כדי להתחבר לכל לקוח שתואם ל-MCP. הדפוס הזה משמש בדרך כלל למשימות הבאות:

  • שילוב עם סביבת פיתוח משולבת (IDE): אפשר לחבר סביבת פיתוח משולבת (IDE) – כמו Antigravity,‏ Cursor או VS Code – לשרת כדי להריץ שאילתות על נתונים בצורה שיחתית מתוך עורך.
  • לקוח MCP בהתאמה אישית: פיתוח אפליקציה שמשתמשת בשרת כדי לספק ממשק כלי אחיד בכמה ספקי AI.
  • ‫Gemini CLI: אפשר להשתמש ב-CLI כלקוח MCP לשיחות מבוססות-נתונים בטרמינל.
MCP בתוך ADK

מסגרת ה-ADK מספקת את המנגנונים הבאים לשילוב שרתי MCP בתהליכי עבודה של סוכנים:

  • ‫ToolboxToolset: גרסה מיוחדת של שרת MCP Toolbox for Databases שתומכת בכמה שיטות אימות.
  • ‫McpToolset: חיבור סוכן ADK לכל שרת MCP באמצעות חיבורים מקומיים או מרוחקים לשרת MCP. הכלי מגלה באופן אוטומטי את הכלים של השרת ומציג אותם לסוכן.

אפשר גם ליצור שרתי MCP באמצעות מסגרת FastMCP כדי לחשוף כלים שנבנו באמצעות מסגרת ADK לכל לקוח שתואם ל-MCP. הגישה הזו מאפשרת להשתמש בסוכני ADK ככלים במערכות אקולוגיות אחרות.

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

  • שימוש בערכות כלים מובנות לפיתוח סוכנים (ADK), כמו BigQueryToolset או DataAgentToolset, מאפשר שילוב הדוק יותר ללא תלות בשרתים חיצוניים. הגישה הזו מתאימה למערכות שקיימות באופן מלא במסגרת ADK.
  • השימוש בכלים ב-MCP Toolbox מאפשר פעולה הדדית בין לקוחות שתואמים ל-MCP. הגישה הזו מתאימה במיוחד לכלים לנתונים שצריכים לשרת כמה אפליקציות צרכניות או סביבות פיתוח משולבות (IDE) של צד שלישי.

תזמור אופקי (A2A)

‫Agent-to-Agent (A2A) protocol הוא תקן פתוח שמאפשר לסוכנים ייעודיים במערכות שונות לתקשר ולשתף פעולה בצורה מאובטחת בלי שיידרש קוד שילוב בהתאמה אישית.

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

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

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

בחירה של תבנית שילוב

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

רמות המורכבות מוגדרות כך:

  • נמוך: דפוסים שלא דורשים קוד מותאם אישית רב ומסתמכים על ממשקי משתמש או כלים מוכנים מראש.
  • בינוני: תבניות שדורשות פיתוח מותאם אישית של חזית האתר ושילוב של API או SDK, אבל לא דורשות תשתית מורכבת של תזמור עורפי.
  • גבוהה: דפוסים שדורשים פיתוח אפליקציות full-stack, ניהול מצב שיחה, שכבות אימות מרובות או תשתית ביניים של כלי תזמור.
  • משתנה: דפוסים שבהם המורכבות תלויה בשיטת השילוב הבסיסית שבוחרים.
תבנית שילוב מורכבות התאמה אישית פיקוח על סוכני AI בקרת גישה כמה סוכנים סטרימינג ניידות מידע
הטמעה של iframe ב-Looker נמוכה נמוכה מנוהל דרך Looker Looker לא מובנה Looker בלבד
‫Looker API ו-SDK בינוני גבוהה מנוהל באמצעות Looker Looker לא מובנה Looker בלבד
‫Conversational Analytics API עם מקור Looker משתנה גבוהה מנוהלות באמצעות API Looker ו-IAM כן כן כל Google Cloud פלטפורמה
סוכן יחיד (API ישיר) בינוני גבוהה מנוהלות באמצעות API IAM לא כן (יש תמיכה) כל Google Cloud פלטפורמה
כלי תזמור מותאם אישית גבוהה גבוהה מאוד מנוהלות באמצעות API IAM גלילה ידנית גלילה ידנית כל Google Cloud פלטפורמה
מבוסס סכימה עם BigQueryToolset (ADK) נמוכה בינוני ללא (היקש של סכימה) IAM כן (ADK) לא (חסימה) הסביבה העסקית של ADK
מנוהל באמצעות DataAgentToolset (ADK) נמוכה בינוני מנוהלות באמצעות API IAM כן (ADK) לא (חסימה) הסביבה העסקית של ADK
סוכן משנה מותאם אישית להזרמת נתונים (ADK) גבוהה גבוהה מאוד מנוהלות באמצעות API IAM כן (ADK) כן (בהתאמה אישית) הסביבה העסקית של ADK
Standalone MCP בינוני בינוני ללא (היקש של סכימה) IAM לא לא כל לקוח MCP
MCP בתוך ADK בינוני גבוהה ללא (היקש של סכימה) IAM כן (ADK) לא לקוחות ADK ו-MCP
פרוטוקול A2A גבוהה גבוהה תלות ב-Framework IAM כן כן פלטפורמות שונות

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