תרחיש שימוש ב-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. רכיב Agent Development Kit (ADK) LiveRequestQueue מעביר באופן רציף את נתוני הקלט לסוכן של רכיב השליחה.

  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.
  • Vertex AI: פלטפורמה ללמידת מכונה שמאפשרת לאמן ולפרוס מודלים של למידת מכונה ואפליקציות AI, ולהתאים אישית מודלים של שפה גדולה (LLM) לשימוש באפליקציות מבוססות-AI.
  • ערכה לפיתוח סוכנים (ADK): קבוצה של כלים וספריות לפיתוח, לבדיקה ולפריסה של סוכני AI.
  • פרוטוקול Agent2Agent‏ (A2A): פרוטוקול פתוח שמאפשר תקשורת ופעולה הדדית בין סוכנים, ללא קשר לשפת התכנות ולזמן הריצה שלהם.
  • חיבור לרשת (VPC) מאפליקציית serverless: שירות שמאפשר לסביבות 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 הבאים:

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

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

מחברים:

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