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

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

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

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

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

  • 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:

דוגמת קוד מתאים במיוחד ל יתרונות לתשומת ליבכם
הטמעה באמצעות iframes: שיטה עם תכנות מינימלי להוספה מהירה של חוויית הצ'אט הסטנדרטית של 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
שימוש ב-Conversational Analytics API: שילוב ישיר עם ה-API לניהול סוכנים כמשאבים ברמת הענן. לקוחות Looker שנדרשת להם ניידות בין פלטפורמות שונות עבור סוכני הנתונים שלהם.
  • הסוכן מבטיח ניידות של הנתונים בכל הפלטפורמות של Google Google Cloud .
  • מנוהל באופן מרכזי על ידי 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.
  • השימוש ב-Agent Mode מחייב ניהול ידני של הגדרות הכלים, לולאות השיחה, מצב השיחה רב-השלבי, טיפול בשגיאות ופריסה.
  • התקורה של הפיתוח עלולה להיות גבוהה בהשוואה לשימוש במסגרת כמו ADK.
שילוב מבוסס סכימה עם BigQueryToolset (ADK): תבנית שמשתמשת בהפניות לטבלאות כדי להחזיר תובנות לגבי הנתונים במהירות. אב טיפוס מהיר, כלים פנימיים שבהם משילות מידע (data governance) פחות קריטית או תרחישים שבהם תובנות לגבי נתונים הן אחת מכמה יכולות בסוכן ADK.
  • האפשרות הזו מספקת את נתיב השילוב המהיר ביותר במסגרת ADK.
  • לא נדרשת הגדרה מראש של סוכן נתונים.
  • פועל ישירות עם שמות של טבלאות במסד נתונים.
  • אין לו יכולות של ניהול סמנטי, והוא יוצר SQL רק מתוך היסק סכמה.
  • פועל במצב בלי שמירת מצב ברמת ה-API.
  • מספק תשובות טקסט בלבד ולא תומך בתרשימים.
שילוב מבוקר עם DataAgentToolset (ADK): תבנית ששולחת שאילתה לסוכן נתונים שהוגדר מראש באמצעות הפניה למזהה של הסוכן. אפליקציות לייצור שדורשות גישה עקבית לנתונים או מערכות מרובות סוכנים שבהן סוכן הנתונים הוא רכיב מהימן לשימוש חוזר.
  • מספק ניהול סמנטי והתנהגות עקבית לכל הצרכנים.
  • הדיוק משתפר באמצעות שימוש בשאילתות מאומתות ובמילון המונחים הארגוני.
  • היא מוודאת שאפשר לעשות שימוש חוזר בסוכני נתונים ב-ADK, ב-MCP ובשילובים ישירים של API.
  • נדרשת הגדרה מראש של משאבי סוכן הנתונים.
  • פועל במצב בלי שמירת מצב ברמת ה-API.
  • מחזיר תשובות טקסט בלבד ולא תומך בתרשימים.
סוכני משנה מותאמים אישית (ADK): תבנית שמשתמשת במחלקת סוכנים מותאמת אישית כדי להתחבר ישירות ל-API ולהזרים נתחים של נתונים בחזרה למשתמש. אפליקציות שפונות למשתמשים שבהן זמן האחזור של התגובה הוא בעדיפות גבוהה, או צינורות (pipelines) של כמה סוכנים שבהם אחזור נתונים מזין סוכנים במורד הזרם.
  • התלמידים מקבלים משוב בזמן אמת.
  • גישה לכל סוגי התשובות, כמו תרשימים, טבלאות ו-SQL.
  • ניתן להרכיב אותו עם סוכני ADK אחרים באמצעות מצב הסשן.
  • נדרש מאמץ פיתוח רב יותר כדי ליצור מחלקה מותאמת אישית של סוכן ADK.
  • נדרש ניהול ישיר של חיבור הסטרימינג וניתוח התגובה.
‫Model Context Protocol‏ (MCP): תבנית שמשתמשת בתקן פתוח כדי לחבר אפליקציות AI למקורות נתונים ולכלים בסביבות שונות. ארגונים שנדרשת בהם יכולת פעולה הדדית של כלים בכמה לקוחות AI וסביבות IDE, או צוותים שצריכים גישה לאותם כלי נתונים ממסגרת ADK, מסביבות IDE ומאפליקציות בהתאמה אישית.
  • הכלי משתמש בתקן אוניברסלי שפועל עם כל לקוח שתואם ל-MCP.
  • ההטמעה של הכלי לא תלויה באפליקציות לצרכנים.
  • מציע אפשרויות של שרתים מנוהלים, כמו Google Cloud שרת MCP.
  • נדרשת שכבת תשתית נוספת לשרת של ארגז הכלים.
  • השילוב פחות הדוק מאשר בערכות הכלים של ADK.
  • תלוי בסביבה העסקית המתפתחת של ערכת הכלים ל-MCP.
  • הוא פועל במצב בלי שמירת מצב, ולכן צריך לנהל את המצב של שיחות רב-שלבי באופן חיצוני.
‫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. ‫Invoke: המודל מחזיר הודעת 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 מתייחסת ל-API כאל כלי שחוסם תשובות עד לסיום, יכול להיות שמשתמשים לא יקבלו משוב על שאילתות שפועלות זמן רב יותר.

כחלופה לאפליקציות שבהן זמן האחזור של התגובה הוא בעדיפות גבוהה או שבהן אחזור הנתונים מועבר לסוכנים במורד הזרם, אפשר ליצור מחלקה מותאמת אישית של סוכן ADK שמתחברת ישירות ל-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 באמצעות הדפוסים הבאים:

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

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

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

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

  • נמוך: דפוסים שלא דורשים קוד מותאם אישית רב ומסתמכים על ממשקי משתמש או כלים מוכנים מראש.
  • בינוני: דפוסים שדורשים פיתוח מותאם אישית של חזית האתר ושילוב של 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 כן כן פלטפורמות שונות

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