תרחיש שימוש ב-AI אקטיבי: תיאום הגישה למערכות ארגוניות שונות

Last reviewed 2025-12-03 UTC

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

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

ארכיטקטורה

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

ארכיטקטורה של אפליקציית AI אקטיבי שמתאמת גישה למערכות ארגוניות שונות. ארכיטקטורה של אפליקציית AI אקטיבי שמתאמת גישה למערכות ארגוניות שונות.

הרכיבים בארכיטקטורה מאורגנים בשכבות הבאות:

שכבה רכיבים
ערוצי אינטראקציה

בדוגמה לארכיטקטורה, לקוחות יוצרים אינטראקציה עם מערכת ה-AI האקטיבי דרך כמה ערוצים:

  • קצה קדמי מותאם אישית, כמו אפליקציית אינטרנט שמתקשרת עם הסוכן באמצעות API בארכיטקטורת REST מאובטח ותומך בתהליכים שכוללים האדם שבתהליך.
  • ממשק צ'אט אד-הוק ב-Gemini Enterprise שמפעיל את הסוכן ככלי מאובטח ומאפשר למשתמשים לקיים אינטראקציה עם מערכות מורכבות בעורף באמצעות שפה טבעית.
  • אפליקציה חיצונית שמתחילה תהליכי עבודה של אוטומציה ממערכת למערכת על ידי פרסום אירועים עסקיים בנושא Pub/Sub.
ליבה אקטיבית

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

כדי לשמור על מצב בין משימות מרובות שלבים, הסוכן משתמש בתמיכה מובנית ב-ADK כדי לשמור נתוני מצב ב-Vertex AI Session Service או ב-Cloud Storage.

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

לתקשורת בין הסוכן לבין מערכות הקצה העורפי, הארכיטקטורה משתמשת בשרתי Model Context Protocol‏ (MCP) שנפרסים ב-Cloud Run.

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

מערכות קצה עורפי

בדוגמת הארכיטקטורה, סוכן ה-AI מתאם את הגישה למערכות הבאות של ה-Backend:

  • מסד נתונים תפעולי ב-Cloud SQL.
  • אפליקציה שפרוסה במכונות וירטואליות של Compute Engine.
  • אפליקציה שפועלת מחוץ ל- Google Cloud.

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

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

  • Vertex AI: פלטפורמה ללמידת מכונה שמאפשרת לאמן ולפרוס מודלים של למידת מכונה ואפליקציות מבוססות-AI, ולהתאים אישית מודלים גדולים של שפה (LLM) לשימוש באפליקציות מבוססות-AI.
  • Cloud Run: פלטפורמת מחשוב ללא שרת שמאפשרת להריץ קונטיינרים ישירות על גבי התשתית הניתנת להרחבה של Google.
  • Pub/Sub: שירות העברת הודעות אסינכרוני וניתן להרחבה שמפריד בין שירותים שמפיקים הודעות לבין שירותים שמבצעים עיבוד של ההודעות האלה.
  • ‫Gemini Enterprise: פלטפורמה מאובטחת בניהול מלא לפריסה ולניהול של סוכני AI בארגון.
  • Gemini: משפחה של מודלים מולטי-מודאליים של AI שפותחו על ידי Google.
  • Cloud Storage: מאגר אובייקטים ללא הגבלה בעלות נמוכה, לשימוש עם סוגים שונים של נתונים. אפשר לגשת לנתונים מתוך Google Cloudומחוץ לה, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
  • Cloud SQL: שירות מנוהל של מסד נתונים רלציוני, שעוזר לכם להקצות, להפעיל ולנהל את מסדי הנתונים של MySQL,‏ PostgreSQL ו-SQL Server ב- Google Cloud.

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

הארכיטקטורה הזו שימושית בתרחישי השימוש הבאים:

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

הארכיטקטורה מספקת את היתרונות הבאים:

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

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

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

  • אבטחה: בשירותי Cloud Run, מומלץ להשתמש בחשבונות שירות ייעודיים של IAM עם הרשאות שמבוססות על העיקרון של הרשאות מינימליות. כדי להגן על ממשק ה-API של הסוכן, מגדירים אמצעי בקרה לכניסה ב-Cloud Run כדי להגביל את הגישה למתקשרים מאומתים.
  • יכולת מעקב: במערכות מבוזרות, רישום ביומן ומעקב הם קריטיים לפתרון בעיות. כדי לקבל תמונה מלאה של תהליך העבודה של הסוכן, צריך להגדיר את השירותים כך שיכתבו יומנים מובנים ל-Cloud Logging וישלחו נתוני מעקב ל-Cloud Trace.
  • ביצועים: Cloud Run מתאים את עצמו אוטומטית לעומס העבודה, ומתכווץ לאפס כשאין עומס. באפליקציות שרגישות לזמן האחזור, אפשר לצמצם את ההתחלות הקרות על ידי הגדרת מספר מינימלי של מופעים.
  • אוטומציה של פריסה: אפשר להשתמש בכלי של תשתית כקוד (IaC) כמו Terraform כדי להפוך את הקצאת המשאבים והניהול שלהם לאוטומטיים. הגישה של IaC עוזרת להבטיח פריסות שניתנות לשחזור ולבדיקה בסביבות פיתוח, ביניים וייצור.
  • ניהול: אפשר לייעל את התכנון והפריסה של התשתית של האפליקציה באמצעות Application Design Center. אתם יכולים להשתמש ב-App Design Center כדי להגדיר תבניות שכוללות כללי ניהול ושיטות מומלצות לארגון שלכם.

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

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

מחבר: קייסי ווסט | Architecture Advocate, Google Cloud

תורמי תוכן אחרים: