תרחיש שימוש ב-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

מידע על בחירת רכיבים חלופיים למערכת ה-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 הבאים:

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

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

מחברים:

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