מערכת AI עם סוכן יחיד באמצעות ADK ו-Cloud Run

Last reviewed 2025-12-09 UTC

במסמך הזה מוצגת ארכיטקטורה לדוגמה, שתעזור לכם לתכנן מערכת AI עם סוכן יחיד ב- Google Cloud. המערכת עם הסוכן היחיד בארכיטקטורה הזו נוצרת באמצעות הערכה לפיתוח סוכנים (ADK) ונפרסת ב-Cloud Run. אפשר גם לפרוס את הסוכן ב-Agent Runtime ב-Gemini Enterprise Agent Platform או ב-Google Kubernetes Engine ‏ (GKE). הארכיטקטורה משתמשת ב-Model Context Protocol‏ (MCP), שמאפשר לסוכן לגשת למידע ממקורות מרובים ולעבד אותו כדי לספק תובנות עם הקשר עשיר.

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

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

ארכיטקטורה

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

ארכיטקטורה של סוכן יחיד שנפרסת ב-Cloud Run. ארכיטקטורה של מערכת AI אקטיבי מרובת סוכנים ב- Google Cloud.

רכיבי הארכיטקטורה

הארכיטקטורה לדוגמה מורכבת מהרכיבים הבאים:

רכיב תיאור
קצה קדמי המשתמשים יוצרים אינטראקציה עם הנציג דרך ממשק קצה (frontend), כמו ממשק צ'אט, שפועל כשירות Cloud Run ללא שרת (serverless).
סוכן הנציג מקבל בקשות מהמשתמשים, מפרש את כוונת המשתמש, בוחר את הכלים המתאימים ואז מסנתז מידע כדי לענות על שאילתות.
Agent runtime הסוכן נוצר באמצעות ADK ונפרס בתור שירות Cloud Run בלי שרת (serverless). אתם יכולים גם לפרוס את הסוכן ב-Agent Runtime ב-Gemini Enterprise Agent Platform או כאפליקציה בקונטיינר ב-GKE. למידע על איך לבחור Agent Runtime, ראה איך בוחרים את הרכיבים של ארכיטקטורת ה-AI האקטיבי.
ADK ה-ADK מספק כלים ומסגרת לפיתוח, לבדיקה ולפריסה של סוכנים. ה-ADK מפשט את המורכבות של יצירת סוכנים ומאפשר למפתחי AI להתמקד בלוגיקה וביכולות של הסוכן. כשאתם מפתחים סוכנים באמצעות ADK, אתם יכולים להגדיר אותם כך שיוכלו לגשת לכלים מובנים כמו חיפוש Google ולהשתמש בהם.
מודל AI וזמן ריצה של המודל כדי להציג את ההסקה, הסוכן בארכיטקטורה לדוגמה משתמש במודל Gemini AI ב-Gemini Enterprise Agent Platform.
ארגז הכלים של MCP ‫MCP Toolbox for Databases מספק כלים ספציפיים למסדי נתונים בשביל הסוכן. הוא יכול לטפל במשימות מורכבות כמו איחוד חיבורים ואימות.
לקוחות, שרתים וכלים של MCP ‫MCP מאפשר גישה לכלים על ידי סטנדרטיזציה של האינטראקציה בין הסוכנים לכלים. לכל צמד של סוכן וכלי, לקוח MCP שולח בקשות לשרת MCP שדרכו הסוכן ניגש לכלי, כמו מערכת קבצים או API. לדוגמה, כלים חיצוניים כמו StackOverflow LangChain וכלי חיפוש Google יכולים לספק נתונים ומידע לביסוס.
ניראות (observability) הסוכן מנוטר באמצעות Google Cloud Observability לצורך רישום ביומן, מעקב ויומני מעקב.

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

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

  1. המשתמש מזין הנחיה דרך ממשק קצה (frontend), כמו ממשק צ'אט, שפועל כשירות Cloud Run בלי שרת (serverless).
  2. ה-frontend מעביר את ההנחיה לסוכן.
  3. הנציג משתמש במודל ה-AI כדי להבין את ההנחיה של המשתמש וליצור תשובה:
    • מודל ה-AI קובע באילו כלים להשתמש כדי לאסוף מידע לפי הקשר או כדי לבצע משימה.
    • הסוכן מפעיל את הכלים ומוסיף את התשובה להקשר שלו.
    • הנציג מבצע אימות ביניים ואימות מול מקורות מידע.

המוצרים שהשתמשו בהם

ארכיטקטורת העזר הזו משתמשת במוצרים ובכלים הבאים של Google Cloud ושל קוד פתוח:

  • ‫ Cloud Run: פלטפורמת מחשוב בלי שרת (serverless computing) שמאפשרת להריץ קונטיינרים ישירות בתשתית של Google, שניתנת להתאמה לעומס.
  • ‫ Gemini: קבוצה של מודלי AI מולטי-מודאליים שפותחו על ידי Google.
  • ‫ Gemini Enterprise Agent Platform: פלטפורמה מקיפה שמאפשרת ליצור, לנהל, לבצע אופטימיזציה ולהתאים לעומס (scale) סוכני AI ברמה שמתאימה לארגונים.
  • ‫ Model Context Protocol‏ (MCP): תקן קוד פתוח לחיבור אפליקציות AI למערכות חיצוניות.
  • ‫ MCP Toolbox for Databases: שרת Model Context Protocol (MCP) בקוד פתוח שמאפשר לסוכני AI להתחבר בצורה מאובטחת למסדי נתונים, על ידי ניהול המורכבות של מסדי הנתונים כמו מאגר חיבורים, אימות וניראות.
  • ‫ Google Cloud Observability: שירותי ניראות, כולל Cloud Monitoring, ‏ Cloud Logging ו-Cloud Trace, שעוזרים לכם להבין את ההתנהגות, התקינות והביצועים של האפליקציות.

תרחישים לדוגמה

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

מיון אוטומטי של דוחות על באגים

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

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

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

הארכיטקטורה הזו מתאימה לכל ארגון שמפתח תוכנה ורוצה לשפר את היעילות והאפקטיביות של תהליך פתרון הבאגים. מידע נוסף ואפשרויות פריסה זמינים במאמרים Software Bug Assistant – ADK Python Sample Agent ו-Tools Make an Agent: From Zero to Assistant with ADK.

שירות לקוחות

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

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

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

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

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

הארכיטקטורה הזו מתאימה לכל ארגון קמעונאי שרוצה לשפר את חוויית הלקוח, להגדיל את המכירות ולפשט את ניהול ההזמנות והתזמון. למידע נוסף ולאפשרויות פריסה, ראו נציג שירות הלקוחות של Cymbal Home & Garden.

חיזוי של סדרות זמנים

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

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

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

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

אחזור מסמכים

אתם יכולים להתאים את הארכיטקטורה הזו כדי להשתמש ב-RAG Engine ב-Gemini Enterprise Agent Platform וליצור סוכן שינהל את אחזור הנתונים לפי הקשר. סוכן לאחזור מסמכים יכול לאחזר נתונים רלוונטיים מקבוצה של מסמכים שנבחרו בקפידה, כדי לספק תשובות עובדתיות עם ציטוטים מחומר המקור.

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

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

חלופות עיצוב

בקטע הזה מוצגות גישות עיצוב חלופיות שאפשר להשתמש בהן לפריסת סוכן ה-AI ב- Google Cloud.

Agent runtime

בארכיטקטורה שמתוארת במסמך הזה, הנציג והכלים שלו נפרסים ב-Cloud Run. אתם יכולים גם להשתמש ב-GKE או ב-Agent Runtime כסביבת זמן ריצה חלופית. במאמר "בחירת רכיבי הארכיטקטורה של ה-AI האקטיבי", בקטע Agent Runtime מוסבר איך בוחרים Agent Runtime.

סביבת זמן ריצה של מודל AI

בארכיטקטורה שמתוארת במסמך הזה, סביבת זמן הריצה של מודל ה-AI היא Agent Platform. אפשר גם להשתמש ב-Cloud Run או ב-GKE כסביבת זמן ריצה חלופית. במאמר "בחירת רכיבי הארכיטקטורה של ה-AI האקטיבי", בקטע סביבת זמן ריצה של מודל, מוסבר איך בוחרים סביבת זמן ריצה של מודל.

שיקולים בתכנון

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

עיצוב המערכת

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

בחירת אזור

כשבוחרים אזורים ב- Google Cloud לאפליקציות מבוססות-AI, כדאי להביא בחשבון את הגורמים הבאים:

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

  • Google Cloud כלי לבחירת אזור: כלי אינטראקטיבי מבוסס-אינטרנט לבחירת האזור האופטימלי של Google Cloudלאפליקציות ולנתונים שלכם, על סמך גורמים כמו טביעת רגל פחמנית, עלות וזמן אחזור.
  • ‫Cloud Location Finder API: ממשק API ציבורי שמאפשר למצוא באופן פרוגרמטי מיקומי פריסה ב- Google Cloud, ב-Google Distributed Cloud ובספקי שירותי ענן אחרים.

עיצוב הסוכן

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

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

זיכרון ואחסון הסשן

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

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

ערכת ADK יכולה לעקוב אחרי סשנים בזיכרון לטווח קצר באמצעות האובייקט Session והמאפיינים state. ‫ADK תומך גם בזיכרון לטווח ארוך בסשנים עם אותו משתמש, כולל באמצעות Memory Bank. כדי לאחסן את מצב הסשן, אפשר גם להשתמש בשירותים כמו Memorystore for Redis.

איך בוחרים את רכיבי הארכיטקטורה של ה-AI האקטיבי

אבטחה

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

שיקולי אבטחה לסוכנים

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

  • פיקוח אנושי: לפעמים מערכת AI אקטיבי עלולה להיכשל או לא לפעול כמו שצריך. לדוגמה, המודל עלול ליצור תוכן לא מדויק או שהסוכן עלול לבחור כלים לא מתאימים. במערכות AI אקטיביות שקריטיות לעסק, כדאי לשלב תהליך עבודה שכולל האדם שבתהליך כדי לאפשר למפקחים אנושיים לעקוב אחרי הסוכנים, לשנות את הפעולות שלהם ולהשהות אותם. לדוגמה, משתמשים אנושיים יכולים לבדוק את הפלט של הנציגים, לאשר או לדחות את הפלט ולתת הנחיות נוספות כדי לתקן שגיאות או לקבל החלטות אסטרטגיות. הגישה הזו משלבת את היעילות של מערכות AI אקטיבי עם החשיבה הביקורתית והמומחיות בתחום של משתמשים אנושיים.
  • זהות הסוכן וגישה עם הרשאות מינימליות:
  • ניהול תעבורת הנתונים הנכנסת והיוצאת: אתם יכולים להפנות את תעבורת הנתונים של הנציג דרך Agent Gateway כדי לאכוף כללי מדיניות אבטחה בזמן הריצה, גם בגבולות של תעבורת הנתונים הנכנסת וגם בגבולות של תעבורת הנתונים היוצאת. במאמר סביבות זמן ריצה נתמכות של סוכנים מפורטות סביבות זמן הריצה שתומכות ב-Agent Gateway.
    • ‫Client-to-Agent (ingress)‎: פורסים את Agent Gateway לפני Agent Runtime. השער עוזר לאמת את המתקשרים ולבדוק את ההנחיות הנכנסות בזמן אמת באמצעות הגנה מוגברת על המודל.
    • מסוכן לכל מקום (תעבורת נתונים יוצאת):
      • ניתוב בקשות יוצאות מסוכן לסוכן (A2A) ומסוכן לכלי (MCP) דרך Agent Gateway במצב תעבורת נתונים יוצאת.
      • אכיפה של מדיניות גישה שמוגדרת כדחייה כברירת מחדל, באמצעות מדיניות גישה של IAM ושרת proxy לאימות זהויות (IAP).
      • מוודאים שהסוכנים והכלים הרלוונטיים רשומים ב-Agent Registry.
      • לבדוק את הקריאות והתשובות של כלים יוצאים באמצעות Model Armor כדי למנוע זליגת נתונים, החדרת פרומפטים עקיפה ושימוש לרעה בכלים.
  • מעקב: מעקב אחרי התנהגות הנציג באמצעות יכולות מעקב מקיפות שמאפשרות לכם לראות כל פעולה שהנציג מבצע, כולל תהליך החשיבה שלו, בחירת הכלים ונתיבי הביצוע. מידע נוסף זמין במאמרים רישום ביומן של סוכן ב-Agent Runtime ורישום ביומן ב-ADK.

מידע נוסף על אבטחת סוכני AI זמין במאמר בטיחות ואבטחה של סוכני AI.

שיקולי אבטחה ב-Agent Platform

כדי לוודא שההגדרות והשימוש ב-Agent Platform עומדים בדרישות האבטחה שלכם, כדאי לפעול לפי ההמלצות הבאות:

  • אחריות משותפת: האבטחה היא באחריות משותפת. פלטפורמת הסוכנים מאבטחת את התשתית הבסיסית ומספקת כלים ואמצעי בקרה לאבטחה כדי לעזור לכם להגן על הנתונים, הקוד והמודלים שלכם. אתם אחראים להגדיר נכון את השירותים, לנהל את אמצעי בקרת הגישה ולאבטח את האפליקציות שלכם. מידע נוסף זמין במאמר אחריות משותפת ב-Agent Platform.
  • אמצעי בקרה לאבטחה: פלטפורמת Agent תומכת Google Cloud באמצעי בקרה לאבטחה שבהם אתם יכולים להשתמש כדי לעמוד בדרישות שלכם לגבי מיקום אחסון הנתונים, מפתחות הצפנה בניהול הלקוח (CMEK), אבטחת רשת באמצעות VPC Service Controls ו-Access Transparency. מידע נוסף זמין במשאבי העזרה הבאים:
  • בטיחות: מודלי AI עלולים ליצור תגובות פוגעניות, לפעמים בתגובה להנחיות זדוניות.
    • כדי לשפר את הבטיחות ולצמצם את הסיכון לשימוש לרעה במערכת ה-AI האקטיבי, אתם יכולים להגדיר מסנני תוכן שישמשו כמחסומים לקלטים ולתשובות שעלולים להזיק. מידע נוסף זמין במאמר מסנני בטיחות ותוכן.
    • כדי לבדוק בקשות להסקת מסקנות, הנחיות לסוכנים, קריאות לכלים ותשובות, ולסנן מהם איומים כמו החדרת הנחיות ותוכן פוגעני, אתם יכולים להשתמש בהגנה מוגברת על המודל לקריאות ישירות ל-API של המודל וגם לבקשות שמועברות דרך Agent Gateway. הגנה מוגברת על המודל עוזרת למנוע קלט זדוני, לאמת את בטיחות התוכן, להגן על מידע אישי רגיש, לשמור על תאימות ולאכוף מדיניות בטיחות ואבטחה באופן עקבי.
  • גישה למודלים: אתם יכולים להגדיר כללי מדיניות בארגון כדי להגביל את הסוג והגרסאות של מודלי ה-AI שאפשר להשתמש בהם בפרויקט ב- Google Cloud . מידע נוסף מופיע במאמר שליטה בגישה למודלים של Model Garden.
  • הגנה על נתונים: כדי לזהות מידע רגיש בהנחיות, בתשובות ובנתוני היומנים ולהסיר ממנו את פרטי הזיהוי, אתם יכולים להשתמש ב-Cloud Data Loss Prevention API. מידע נוסף זמין בסרטון הגנה על מידע אישי רגיש באפליקציות AI.

שיקולי אבטחה של MCP

כדי לוודא שהטמעת ה-MCP עומדת בדרישות האבטחה, כדאי לפעול לפי ההמלצות הבאות:

  • רישום וגילוי של כלים: רישום שרתי MCP וכלים ב-Agent Registry כדי שהסוכנים יתחברו רק לנקודות קצה (endpoints) של MCP שנמצאות במלאי ומאושרות על ידי האדמין.
  • בקרת גישה ובדיקת תנועה: אתם יכולים לנתב את התנועה מהסוכן ל-MCP דרך Agent Gateway במצב Agent-to-Anywhere (תנועה יוצאת), ולהגן על שרתי MCP (כמו שרתי MCP שמתארחים ב-Cloud Run) באמצעות IAP וכללי מדיניות גישה של IAM. הגדירו את Model Armor או מדיניות פיקוח בשפה טבעית ב-Agent Gateway כדי לבדוק את הקלט והפלט של כלי ה-MCP, וכך למנוע חשיפה של מידע רגיש והחדרת פרומפטים עקיפה.
  • אבטחה כללית של MCP: כשמגדירים את הסוכנים לשימוש ב-MCP, חשוב לוודא שהגישה לנתונים ולכלים חיצוניים מאושרת, להטמיע אמצעי בקרה על פרטיות כמו הצפנה, להחיל מסננים כדי להגן על נתונים רגישים ולעקוב אחרי האינטראקציות של הסוכנים. מידע נוסף זמין במאמר MCP ואבטחה.

שיקולי אבטחה של A2A

כדי לוודא שההטמעה של A2A עומדת בדרישות האבטחה, כדאי לפעול לפי ההמלצות הבאות:

  • אבטחת תעבורה: פרוטוקול A2A מחייב שימוש ב-HTTPS לכל תקשורת A2A בסביבות ייצור, ומומלץ להשתמש בגרסאות 1.2 ומעלה של Transport Layer Security (‏TLS).
  • אימות: פרוטוקול A2A מעביר את האימות למנגנוני אינטרנט סטנדרטיים כמו כותרות HTTP ולתקנים כמו OAuth2 ו-OpenID Connect. כל נציג מפרסם את דרישות האימות בכרטיס הנציג שלו. מידע נוסף זמין במאמר אימות A2A.
  • פיקוח על סוכנים: רושמים סוכני A2A ב-Agent Registry ומנתבים בקשות בין סוכנים דרך Agent Gateway. אם משלבים את Agent Gateway עם Agent Identity,‏ IAP וכללי מדיניות גישה של IAM, אפשר לאמת באופן קריפטוגרפי את הזהות של הסוכן ששולח את הבקשה, לאכוף הרשאות ברמה מפורטת בין סוכני תיאום לסוכני משנה ולבדוק את המטען הייעודי (payload) בין הסוכנים באמצעות Model Armor.

שיקולי אבטחה ב-Cloud Run

כדי לוודא שההטמעה של Cloud Run עומדת בדרישות האבטחה, כדאי לפעול לפי ההמלצות הבאות:

  • אבטחת תעבורת נתונים נכנסת (לשירות החזיתי): כדי לשלוט בגישה לאפליקציה, משביתים את כתובת ה-URL שמוגדרת כברירת מחדל ב-run.app של השירות החזיתי ב-Cloud Run ומגדירים מאזן עומסים חיצוני אזורי של אפליקציות. בנוסף לאיזון העומסים של התנועה הנכנסת לאפליקציה, מאזן העומסים מטפל בניהול של אישורי ה-SSL. כדי להוסיף עוד שכבת הגנה, אתם יכולים להשתמש במדיניות האבטחה של Google Cloud Armor כדי לסנן בקשות, להגן מפני מתקפות DDoS ולהגביל את קצב יצירת הבקשות לשירות.
  • אימות משתמשים:

    • משתמשים בתוך הארגון: כדי לאמת את הגישה של משתמשים פנימיים לשירות Cloud Run של ממשק הקצה, משתמשים ב-IAP. כשמשתמש מנסה לקבל גישה למשאב שמאובטח באמצעות IAP, האימות ובדיקת ההרשאות מתבצעים על ידי IAP.
    • משתמשים מחוץ לארגון: כדי לאמת את הגישה של משתמשים חיצוניים לשירות החזיתי, משתמשים ב-Identity Platform או באימות ב-Firebase. כדי לנהל את הגישה של משתמשים חיצוניים, צריך להגדיר את האפליקציה כך שתטפל בתהליך הכניסה ותבצע קריאות מאומתות ל-API של שירות Cloud Run.

    מידע נוסף זמין במאמר אימות משתמשים.

  • אבטחת שרת MCP וסוכן: כשמארחים סוכנים או שרתי MCP ב-Cloud Run, מגדירים את התכונות של Agent Platform ל-Cloud Run כדי להקצות זהות מנוהלת של סוכן לשירות, ומשתמשים ב-IAP עם Agent Gateway כדי לאמת ולאשר בקשות נכנסות של סוכנים וכלים.

  • אבטחה של קובצי אימג' של קונטיינרים: כדי לוודא שרק קובצי אימג' מורשים של קונטיינרים נפרסים ב-Cloud Run, אתם יכולים להשתמש ב-Binary Authorization. כדי לזהות סיכוני אבטחה בקובצי האימג' של הקונטיינרים ולצמצם אותם, אתם יכולים להשתמש ב-Artifact Analysis כדי להריץ באופן אוטומטי סריקות לאיתור נקודות חולשה. למידע נוסף, קראו את הסקירה הכללית על סריקת קונטיינרים.

  • מיקום אחסון הנתונים: ב-Cloud Run אפשר לעמוד בדרישות לגבי מיקום אחסון הנתונים. שירותי Cloud Run פועלים באזור שנבחר.

למידע נוסף על אבטחת קונטיינרים, קראו את הטיפים הכלליים לפיתוח ב-Cloud Run.

שיקולי אבטחה לכל מוצרי Google Cloud בארכיטקטורה

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

  • הצפנת נתונים: כברירת מחדל, Google Cloud מצפין נתונים במנוחה באמצעות Google-owned and Google-managed encryption keys. כדי להגן על נתוני הנציגים באמצעות מפתחות הצפנה שבשליטתכם, אתם יכולים להשתמש ב-CMEK שאתם יוצרים ומנהלים ב-Cloud KMS. למידע על שירותי Google Cloud שתואמים ל-Cloud KMS, קראו את המאמר שירותים תואמים.
  • צמצום הסיכון לזליגת נתונים: כדי לצמצם את הסיכון לזליגת נתונים, צרו מתחם של VPC Service Controls מסביב לתשתית. ב-VPC Service Controls יש תמיכה בכלGoogle Cloud השירותים שבהם משתמשים בארכיטקטורה לדוגמה.
  • בקרת גישה: כשמגדירים הרשאות למשאבים בטופולוגיה, צריך לפעול לפי העיקרון של הרשאות מינימליות.
  • אבטחת סביבת הענן: משתמשים בכלים של Security Command Center כדי לזהות נקודות חולשה, לזהות איומים ולצמצם אותם, להגדיר ולפרוס מצב אבטחה ולייצא נתונים לניתוח נוסף.
  • אופטימיזציה אחרי הפריסה: אחרי שפורסים את האפליקציה ב-Google Cloud, אפשר לקבל המלצות לשיפור האבטחה באמצעות Active Assist. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. איך מוצאים המלצות ב-Active Assist

המלצות נוספות בנושא אבטחה

אמינות

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

רכיב שיקולים והמלצות לתכנון
סוכן

‫סימולציה של כשלים: לפני שפורסים את מערכת ה-AI האקטיבי בסביבת הייצור, מאמתים אותה באמצעות סימולציה של סביבת הייצור. לזהות ולתקן בעיות והתנהגויות לא צפויות.

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

התאוששות מהפסקות חשמל: כדי לוודא שהסוכן יכול לטפל בהפעלות מחדש בצורה חלקה ולשמור על ההקשר, צריך להפריד את המצב מזמן הריצה. כדי להטמיע אפליקציית נציג ללא שמירת מצב, צריך להשתמש במאגר נתונים חיצוני כמו מסד נתונים או מטמון מבוזר. לדוגמה, אתם יכולים להשתמש ב-Memory Bank, ב-Memorystore for Redis או בשירות של מסד נתונים כמו Cloud SQL.

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

Agent Platform

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

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

Cloud Run

עמידות בפני הפסקות בתשתית: Cloud Run הוא שירות אזורי. הוא מאחסן נתונים באופן סינכרוני בכמה אזורים בתוך מיקום, ומאזן באופן אוטומטי את העומס של התנועה בין האזורים. אם יש הפסקה זמנית בשירות באזור מסוים, Cloud Run ממשיך לפעול והנתונים לא אובדים. אם מתרחשת הפסקה זמנית בשירות באזור, השירות מפסיק לפעול עד ש-Google פותרת את הבעיה.

התאמה אופקית לעומס (Horizontal scaling): שירותי Cloud Run מטפלים בשבילכם בהתאמה אוטומטית לעומס של מכונות. התאמה אוטומטית לעומס עוזרת לוודא שהמכונות יכולות לטפל בכל הבקשות הנכנסות, האירועים וניצול ה-CPU שנדרשים כדי להבטיח זמינות גבוהה.

כל המוצרים בארכיטקטורה

אופטימיזציה אחרי הפריסה: אחרי שפורסים את האפליקציה ב- Google Cloud, אפשר לקבל המלצות לשיפור האבטחה באמצעות Active Assist. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. איך מוצאים המלצות ב-Active Assist?

במאמר נקודת מבט על AI ו-ML: אמינות ב-Well-Architected Framework, תוכלו לקרוא על עקרונות והמלצות לאמינות שספציפיים לעומסי עבודה של AI ו-ML.

תפעול

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

רכיב שיקולים והמלצות לתכנון
סוכן

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

Agent Platform

מעקב באמצעות יומני הפעילות של סוכן: כברירת מחדל, יומני הפעילות של סוכן שנכתבים בסטרימינג של stdout ו-stderr מנותבים ל-Cloud Logging. לרישום מתקדם ביומן, אפשר לשלב את כלי הרישום ביומן של Python עם Logging. אם אתם צריכים שליטה מלאה על הרישום ביומן ועל יומנים מובְנים, השתמשו בלקוח של Logging. מידע נוסף זמין במאמרים רישום ביומן של סוכן ורישום ביומן ב-ADK.

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

Cloud Run

תקינות וביצועים: מעקב אחרי שירותי Cloud Run באמצעות Google Cloud Observability. הגדירו התראות ב-Cloud Monitoring כדי לקבל הודעות על בעיות פוטנציאליות, כמו עלייה בשיעורי השגיאות, זמן אחזור ארוך או ניצול חריג של משאבים.

מסדי נתונים

תקינות וביצועים: מעקב אחרי מסד הנתונים באמצעות Google Cloud Observability. הגדירו התראות ב-Monitoring כדי לקבל התראות על בעיות פוטנציאליות, כמו עלייה בשיעורי השגיאות, זמן אחזור ארוך או ניצול חריג של משאבים.

MCP

כלים למסדי נתונים: כדי לנהל ביעילות את הכלים למסדי נתונים של סוכני ה-AI, ולוודא שהסוכנים מטפלים בצורה מאובטחת במשימות מורכבות כמו איחוד חיבורים ואימות, השתמשו ב-MCP Toolbox for Databases. הוא מספק מיקום מרכזי לאחסון ולעדכון של כלי מסד נתונים. אתם יכולים לשתף את הכלים בין הסוכנים ולעדכן את הכלים בלי לפרוס מחדש את הסוכנים. ארגז הכלים כולל מגוון רחב של כלים למסדי נתונים של Google Cloud , כמו AlloyDB ל-PostgreSQL, ולמסדי נתונים של צד שלישי, כמו MongoDB.

מודלים גנרטיביים של בינה מלאכותית כדי לאפשר לסוכני בינה מלאכותית להשתמש במודלים של בינה מלאכותית גנרטיביים של גוגל כמו Imagen ו-Veo, ניתן להשתמששרתי MCP עבור Google Cloud ממשקי API של מדיה יצירתית.

מוצרים וכלי אבטחה של גוגל: כדי לאפשר ל<b>סוכני AI</b> שלכם גישה למוצרים וכלי אבטחה של גוגל כמו Google Security Operations, Google Threat Intelligence ו- Security Command Center, השתמשו ב<b>שרתי MCP</b> עבור מוצרי אבטחה של גוגל.

כל המוצרים של Google Cloud בארכיטקטורה

מעקב: איסוף וניתוח של נתוני מעקב באופן רציף באמצעות Trace. נתוני המעקב מאפשרים לזהות במהירות בעיות של זמן אחזור ב-Agentic Workflows מורכבים, ולאבחן אותן. אתם יכולים לבצע ניתוח מעמיק באמצעות תצוגות חזותיות בדף Trace explorer במסוף Google Cloud . מידע נוסף זמין במאמר מעקב אחרי נציג.

כדי לקרוא על עקרונות והמלצות למצוינות תפעולית שספציפיים לעומסי עבודה של AI ו-ML, קראו את המאמר נקודת מבט על AI ו-ML: מצוינות תפעולית ב-Well-Architected Framework.

הוזלת עלויות

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

שיקולי עלות ב-Agent Platform

כדי לוודא שההגדרות והשימוש ב-Agent Platform עומדים בדרישות העלות, כדאי לפעול לפי ההמלצות הבאות:

  • ניתוח וניהול עלויות: כדי לנתח ולנהל את העלויות של Agent Platform, מומלץ ליצור מדדי בסיס לשאילתות לשנייה (QPS) ולטוקנים לשנייה (TPS). לאחר מכן, עוקבים אחרי המדדים האלה אחרי הפריסה. קו הבסיס גם עוזר לתכנן את הקיבולת. לדוגמה, בעזרת ערך הבסיס תוכלו לקבוע מתי כדאי להשתמש בהקצאת משאבים לפי התפוקה שנקבעה.
  • בחירת מודל: המודל שתבחרו לאפליקציית ה-AI משפיע ישירות על העלויות ועל הביצועים. כדי לזהות את המודל שמספק איזון אופטימלי בין ביצועים לעלות בתרחיש השימוש הספציפי שלכם, כדאי לבדוק מודלים באופן איטרטיבי. מומלץ להתחיל עם המודל הכי חסכוני ולהתקדם בהדרגה לאפשרויות חזקות יותר.
  • הנדסת פרומפטים חסכונית: אורך הפרומפטים (קלט) והתשובות שנוצרות (פלט) משפיעים ישירות על הביצועים והעלות. כתבו הנחיות קצרות וישירות, וספקו מספיק הקשר. כדאי לנסח את ההנחיות כך שהמודל ייתן תשובות תמציתיות. לדוגמה, אפשר להוסיף ביטויים כמו "סכם ב-2 משפטים" או "ציין 3 נקודות עיקריות". מידע נוסף זמין במאמר שיטות מומלצות לעיצוב הנחיות.
  • שמירת הקשר במטמון: כדי להוזיל את העלות של בקשות שכוללות תוכן חוזר עם מספר גבוה של טוקנים לקלט, אתם יכולים להשתמש בשמירת הקשר במטמון.
  • בקשות Batch: במקרים רלוונטיים, כדאי לשקול חיזוי באצווה. העלות של בקשות Batch נמוכה יותר מהעלות של בקשות רגילות.

שיקולי עלות ב-Cloud Run

כדי לוודא שההטמעה של Cloud Run עומדת בדרישות העלות, כדאי לפעול לפי ההמלצות הבאות:

שיקולי עלות לכל מוצרי Google Cloud בארכיטקטורה

אחרי שפורסים את האפליקציה ב- Google Cloud, אפשר לקבל המלצות לייעול נוסף של העלויות באמצעות Active Assist. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. איך מוצאים המלצות ב-Active Assist

כדי להעריך את העלות של המשאבים ב- Google Cloud , אתם יכולים להשתמש במחשבון העלויות שלGoogle Cloud .

במאמר נקודת מבט של AI ו-ML: אופטימיזציה של עלויות ב-Well-Architected Framework, תוכלו לקרוא על עקרונות והמלצות לאופטימיזציה של עלויות שספציפיות לעומסי עבודה של AI ו-ML.

אופטימיזציה של הביצועים

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

שיקולי ביצועים של נציגים

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

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

שיקולי ביצועים ב-Agent Platform

כדי לוודא שההגדרות והשימוש ב-Agent Platform עומדים בדרישות הביצועים, כדאי לפעול לפי ההמלצות הבאות:

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

שיקולי ביצועים ב-Cloud Run

בהתאם לדרישות הביצועים, מגדירים את הזיכרון ואת המעבד (CPU) שיוקצו לשירות Cloud Run. מידע נוסף זמין במאמרים הגדרת מגבלות זיכרון לשירותים והגדרת מגבלות מעבד (CPU) לשירותים.

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

שיקולי ביצועים לכל מוצרי Google Cloud בארכיטקטורה

אחרי שפורסים את האפליקציה ב- Google Cloud, אפשר לקבל המלצות לשיפור הביצועים באמצעות Active Assist. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. איך מוצאים המלצות ב-Active Assist

במאמר נקודת מבט על AI ו-ML: אופטימיזציה של ביצועים ב-Well-Architected Framework, תוכלו לקרוא על עקרונות והמלצות לאופטימיזציה של ביצועים שספציפיים לעומסי עבודה של AI ו-ML.

פריסה

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

במאמר כלי MCP יש דוגמאות קוד שיעזרו לכם להתחיל להשתמש ב-ADK יחד עם שרתי MCP.

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

  • קניות בהתאמה אישית: הצגת המלצות מותאמות אישית למוצרים של מותג, מוכר או זירת מסחר ספציפיים.
  • ניהול אירועים: אימות של האסימון והזהות של משתמש הקצה על בסיס כל בקשה, באמצעות הפצה דינמית של זהויות.
  • עיבוד הזמנות: עיבוד ואחסון של הזמנות, וניהול של אישור באימייל עם בדיקה אנושית מותנית לכמויות הזמנה מסוימות.
  • הנדסת נתונים: פיתוח צינורות עיבוד נתונים ב-Dataform, פתרון בעיות בצינורות עיבוד נתונים וניהול הנדסת נתונים – משאילתות SQL מורכבות ועד לטרנספורמציות של נתונים ותלויות בנתונים.
  • אחזור מסמכים: אתם יכולים להשתמש ב-RAG כדי לשלוח שאילתות למסמכים שאתם מעלים ל-RAG Engine ב-Gemini Enterprise Agent Platform, ולקבל תשובות עם ציטוטים מהמסמכים ומהקוד.

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

שותפים ביצירת התוכן