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

Last reviewed 2026-04-06 UTC

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

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

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

ארכיטקטורה

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

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

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

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

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

תהליך העבודה של ההנחיות הטכניות

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

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

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

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

  2. לוח הבקרה של הלקוח יוצר חיבור WebSocket קבוע בין הקצה הקדמי לבין שרת הבק-אנד.

  3. הודעות WebSocket אורזות את נתוני המולטימדיה הגולמיים באובייקטים של Blob. רכיב LiveRequestQueue של ערכת פיתוח הסוכנים (ADK) מעביר באופן רציף את נתוני הקלט לסוכן השולח.

  4. הסוכן של המוקדנית מזהה פקודות קוליות או חזותיות שדורשות הדרכה טכנית, ושולח את זרם הקלט אל מודל Gemini Live.

  5. מודל Gemini Live מחפש בנתונים הגולמיים כדי לזהות אירועים. אירועים הם מילות מפתח אודיו, כמו "הרכבה" או "עזרה", או רמזים חזותיים, כמו תנועות ידיים.

    ‫Gemini בודק כל אירוע כדי לקבוע אם הוא רלוונטי לשאלה של המשתמש. לדוגמה, יכול להיות שמילים מגשרות או תנועות ידיים לא יהיו רלוונטיות, ולכן Gemini לא יעבד את האירועים האלה.

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

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

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

    3. סוכן השליחה משתמש בפרוטוקול Agent2Agent‏ (A2A) כדי לשלוח את הבקשה המובנית לסוכן הארכיטקט.

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

    5. מחבר הגישה ל-VPC ללא שרתים פועל עם הנתונים שבמטמון שמאוחסנים ב- Memorystore for Redis Cluster. אם הנתונים לא זמינים בשכבת המטמון, סוכן הארכיטקט מתקשר עם מופעי Compute Engine שמארחים את בסיס הידע.

    6. הסוכן של הארכיטקט מקבל את פרטי המוצר ממטמון הנתונים או ממסד הידע. הסוכן הארכיטקט שולח את פרטי המוצר אל Gemini כדי ליצור תשובה. לדוגמה, "קוד שגיאה 3B: תקלה במאוורר פעולה מומלצת: כדאי לבדוק אם יש חסימות".

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

    אם לא צריך עוד הקשר, Gemini יוצר תשובה לבקשת המשתמש ישירות.

  7. סוכן השליחה מקבל את התשובה מ-Gemini או מסוכן הארכיטקטורה, והוא יוצר תשובה מרובת-אופנים:

    1. משתמש במודל Gemini Live ובפונקציה ADK run_live כדי ליצור תשובה מולטי-מודאלית שמכילה את הפתרון הטכני.

    2. התגובה מאוחסנת כאובייקט Blob.

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

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

תהליך העבודה של ניטור הבטיחות

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

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

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

  1. לוח הבקרה של הלקוח יוצר חיבור WebSocket קבוע בין הקצה הקדמי לבין שרת הבק-אנד כדי לצפות בשידור החי של הסרטון. חבילות ההודעות של WebSocket אורזות את נתוני המולטימדיה הגולמיים האלה באובייקטים מסוג Blob ושולחות אותם באופן רציף למאגר הזמני של הסטרימינג, באמצעות רכיב LiveRequestQueue של ADK.
  2. מאגר הנתונים הזמני של הסטרימינג מפנה את נתוני הסטרימינג אל כלי סטרימינג שפועל בלולאה רציפה ברקע כדי לזהות סכנות בפריים של הסרטון.
  3. כלי הסטרימינג שולח את פריים הווידאו האחרון ממאגר הנתונים הזמני של הסטרימינג אל Gemini.
  4. ‫Gemini בוחן את הפריימים של הסרטון כדי לזהות סכנות, כמו אור בהיר או אדים.
    • אם לא מזוהה סכנה, לא קורה כלום.
    • אם מזוהה סכנה, Gemini יוצר תגובה מולטי-מודאלית שמכילה את סוג הסכנה, המאפיינים שלה והמיקום שלה, ושומר אותה כאובייקט Blob. ‫Gemini שולח את התשובה עם אזהרת הסכנה בחזרה לכלי הסטרימינג.
  5. הכלי לסטרימינג מעביר את התגובה לאזהרה על הסכנה למאגר הזמני של הסטרימינג.
  6. מאגר הנתונים הזמני של הסטרימינג משתמש בחיבור WebSocket הקבוע כדי להעביר את הפתרון הטכני ללוח הבקרה של הלקוח.
  7. לוח הבקרה של הלקוח מחלץ את נתוני Blob מהפתרון הטכני כדי לספק הדרכה מיידית עם קריינות, ומעדכן את ממשק המשתמש עם תמלילים רלוונטיים. כך מסתיים לולאת הבקשות, והזרם הדו-כיווני נשאר פעיל.

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

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

  • ‫ Cloud Run: פלטפורמת מחשוב ללא שרת שמאפשרת להריץ קונטיינרים ישירות על גבי התשתית הניתנת להרחבה של Google.
  • ‫ Gemini: משפחה של מודלים מולטי-מודאליים של AI שפותחו על ידי Google.
  • Gemini Enterprise Agent Platform: פלטפורמה מקיפה שמאפשרת לכם ליצור, לנהל, לבצע אופטימיזציה ולהתאים לעומס (scale) סוכני AI ברמה שמתאימה לארגונים.
  • ‫Agent Development Kit (ADK): ערכה של כלים וספריות לפיתוח, לבדיקה ולפריסה של סוכני AI.
  • פרוטוקול Agent2Agent‏ (A2A): פרוטוקול פתוח שמאפשר תקשורת ופעולה הדדית בין סוכנים, ללא קשר לשפת התכנות ולזמן הריצה שלהם.
  • Serverless VPC Access: שירות שמאפשר לסביבות serverless להתחבר למשאבים ברשת של ענן וירטואלי פרטי (VPC).
  • ענן וירטואלי פרטי (VPC): מערכת וירטואלית שמספקת פונקציונליות של רשתות גלובליות וניתנות להרחבה עבור עומסי העבודה שלכם ב- Google Cloud . ‫VPC כולל קישור בין רשתות VPC שכנות (peering),‏ Private Service Connect, גישה לשירותים פרטיים ו-VPC משותף.
  • ‫ Memorystore for Redis Cluster: שירות מאגרי נתונים בזיכרון מנוהל באופן מלא ל-Redis.
  • ‫ Compute Engine: שירות מחשוב מאובטח וניתן להתאמה אישית שמאפשר ליצור ולהריץ מכונות וירטואליות בתשתית של Google.

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

תרחיש שימוש

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

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

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

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

תכנון סוכני AI

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

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

עיצוב הפקה

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

  • אבטחת תעבורת נתונים נכנסת (ingress): כדי לשלוט בגישה לאפליקציה, משביתים את כתובת ה-URL שמוגדרת כברירת מחדל run.app של שירות Cloud Run בחזית האתר ומגדירים מאזן עומסים חיצוני אזורי של אפליקציות. בנוסף לאיזון העומסים של התנועה הנכנסת לאפליקציה, מאזן העומסים מטפל בניהול אישורי SSL. כדי להוסיף הגנה, אתם יכולים להשתמש במדיניות האבטחה של Google Cloud Armor כדי לספק סינון בקשות, הגנה מפני מתקפות DDoS והגבלת קצב לשירות.
  • בקרת גישה: כשמגדירים הרשאות למשאבים בטופולוגיה, חשוב לפעול בהתאם לעקרון של הרשאות מינימליות.
  • חציצה אסינכרונית: כדי להפריד בין מנות אודיו ווידאו נכנסות לבין מנוע ההסקה של המודל, צריך להשתמש במאגר נתונים (buffer) אסינכרוני מסוג First-In-First-Out‏ (FIFO) שמאובטח לשימוש בשרשור. המאגר הזה פועל כמרבב שמבטיח שהמערכת תמשיך להגיב להפרעות של המשתמשים בלי שהממשק יקפא במהלך חישובים כבדים.
  • עלויות של הכנסת נתונים: כדי להקטין את עלויות האסימונים ולמנוע את מיצוי חלון ההקשר, כדאי להשתמש בדגימת פריימים בתדירות נמוכה, למשל 2 פריימים לשנייה, ולדחוס את כל הנתונים לקובצי JPEG בקידוד Base64.
  • שמירה במטמון בזיכרון: כדי להשיג מהירויות קריאה של פחות מאלפית השנייה, צריך להשתמש במסד נתונים של Memorystore for Redis Cluster בזיכרון עבור הכספת הסכמטית של סוכן הארכיטקט. ההטמעה הזו ממזערת את זמן האחזור, מונעת שקט במהלך אינטראקציות קוליות בזמן אמת ומספקת מקור אמת יחיד שניתן להרחבה.
  • אבטחת WebSocket: הגנה על נתונים רגישים מרובי-אופנים, כמו טביעות קול וסרטונים, באמצעות אכיפה של הצפנת TLS לכל חיבורי WebSocket הדו-כיווניים.
  • תקשורת מאובטחת בין אפליקציות (A2A):
  • הקצאת משאבים: בהתאם לדרישות הביצועים, מגדירים את מגבלות הזיכרון ומגבלות המעבד שיוקצו לשירות Cloud Run.

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

פריסה

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

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

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

מחברים:

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