תרחיש לדוגמה לשימוש ב-AI אקטיבי: תזמור של משאבי GraphRAG מולטי-מודאליים

Last reviewed 2026-10-13 UTC

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

‫GraphRAG היא גישה מבוססת-תרשים ל-Retrieval-Augmented Generation (יצירה משולבת-אחזור, RAG). ‫RAG עוזר לעגן תשובות שנוצרו על ידי AI על ידי הוספת נתונים רלוונטיים להקשר להנחיות, שנשלפים באמצעות חיפוש וקטורי. ‫GraphRAG משלב חיפוש וקטורי עם שאילתה של גרף ידע כדי לאחזר נתונים לפי הקשר, שמשקפים טוב יותר את הקשרים בין נתונים ממקורות שונים. הנחיות שמשופרות באמצעות GraphRAG יכולות ליצור תשובות מפורטות ורלוונטיות יותר מ-AI.

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

בקטע פריסה במסמך הזה יש דוגמת קוד שמראה איך להגדיר סכימה של Spanner Graph ולקשר ישויות מולטי-מודאליות לשליפה אג'נטית.

ארכיטקטורה

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

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

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

  • תהליך העבודה של הטמעת הנתונים מאחד רשומות מפוצלות ממקורות שונים ל-Knowledge Graph מאוחד. בתהליך העבודה הזה נעשה שימוש בתבנית של כמה סוכנים ברצף כדי להעלות נתונים גולמיים ל-Cloud Storage, לחלץ קשרים מורכבים באמצעות Gemini ולעדכן את תרשים הידע של Spanner Graph כדי לוודא שהנתונים זמינים לאחזור.
  • תהליך העבודה search מאפשר לאחזר תובנות ולבסס תשובות באמצעות תהליך GraphRAG. תהליך העבודה הזה משתמש ב-Gemini ובסוכני משנה ייעודיים כדי לנווט ב-Knowledge Graph ולגבש ממצאים על סמך נתונים מסשנים קודמים.

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

תהליך הטמעת הנתונים

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

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

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

  1. המשתמש יוצר אינטראקציה עם אפליקציית האינטרנט כדי להעלות נתונים חדשים. לדוגמה, מנתח פיננסי יכול להעלות קובץ PDF של רווחים, הקלטה של פגישת בעלי מניות או תרשים של ביצועי השוק.
  2. אפליקציית האינטרנט מעבירה את הבקשה לסוכן הבסיס. סוכן הבסיס הוא סוכן מתאם שמקבל בקשות ונפרס בשירות Cloud Run.
  3. הנציג הראשי מאחזר נתוני סשן קבועים מ-Memory Bank כדי להתאים אישית את תוצאות החיפוש על סמך ההעדפות של המשתמש מסשנים קודמים.
  4. סוכן הבסיס משתמש ב-Gemini ב-Gemini Enterprise Agent Platform כדי לפרש את הבקשה, ומעביר את המשימה לסוכן המולטימדיה כדי להפעיל את צינור עיבוד הנתונים של הטמעת הנתונים.
  5. סוכן המולטימדיה מפעיל את התבנית הרציפה ומעביר את הקלט הגולמי לסוכן ההעלאה.
  6. סוכן ההעלאה מבצע את המשימות הבאות:
    1. שומרת את הקובץ הגולמי בקטגוריה של Cloud Storage ומזהה את סוג המדיה.
    2. מעביר לנציג החילוץ סיכום ביניים של הפעולות שהוא ביצע.

  7. סוכן החילוץ מבצע את המשימות הבאות:
    1. שליפת ה-URI של הנתונים מקטגוריית האחסון ושימוש ב-Gemini כדי לנתח את הנתונים ולזהות ישויות מובְנות. לדוגמה, הישויות של נתונים פיננסיים יכולות לכלול חברות בת, רבעונים פיסקליים וסנטימנט הכנסות.
    2. מעביר לסוכן הגרף את הישויות המובנות ואת סיכום הביניים של הפעולות שהוא ביצע.
  8. הסוכן של התרשים מבצע את המשימות הבאות:
    1. מקבל את הישויות המובְנות ומעלה את הנתונים ל-Knowledge Graph. Spanner Graph יוצר או מקשר צמתים שמייצגים מנפיקים, בעלי עניין וכלים פיננסיים.
    2. מעביר לסוכן הסיכום סיכום ביניים של הפעולות שהוא ביצע.
  9. הסוכן המסכם יוצר תשובה שמכילה סיכום טקסט של תוצאות ההטמעה והפעולות שבוצעו על ידי כל סוכני המשנה. הסוכן לסיכום שולח את התשובה לסוכן המולטימדיה.
  10. הסוכן המולטימדיה מעביר את התשובה המסוכמת בחזרה לסוכן הראשי.
  11. הסוכן הראשי מפעיל פונקציית קריאה חוזרת כדי לשמור את נתוני הסשן ב-Gemini Enterprise Agent Platform Sessions . הסוכן הראשי מחלץ נושאי זיכרון מותאמים אישית מהסשן כדי לשמור מידע על תחומי מיקוד קריטיים. לדוגמה, אנליסט פיננסי יכול ליצור נושא בזיכרון כדי לעקוב אחרי סימונים רגולטוריים או מגמות במגזר מסוים.
  12. הסוכן הראשי מעביר את התשובה המסוכמת לאפליקציית האינטרנט.
  13. אפליקציית האינטרנט מעבירה את התשובה בחזרה למשתמש.

תהליך עבודה של חיפוש

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

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

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

  1. משתמש יוזם בקשת חיפוש באפליקציית האינטרנט. לדוגמה, מנהל תיק השקעות שולח בקשה לזהות דפוסים של עסקאות מעגליות שכוללות יותר מ-3 ישויות, כשהנפח הכולל חורג ממיליון דולר בטווח של 24 שעות.
  2. אפליקציית האינטרנט מעבירה את הבקשה לסוכן הבסיס. סוכן הבסיס הוא סוכן מתאם שמקבל בקשות ונפרס בשירות Cloud Run.
  3. הנציג הראשי מאחזר נתוני סשן קבועים מ-Memory Bank כדי להתאים אישית את תוצאות החיפוש על סמך ההעדפות וההקשר ההיסטוריים של מנהל תיק ההשקעות.
  4. סוכן הבסיס משתמש ב-Gemini ב-Agent Platform כדי לקבוע את אסטרטגיית החיפוש האופטימלית:
    • חיפוש מילות מפתח: שימוש בסעיפי LIKE ב-SQL כדי להתאים קטגוריות או מיקומים מדויקים.
    • חיפוש RAG סמנטי: משתמש ב מודל ההטמעה ובמרחק קוסינוס כדי למצוא רשומות נתונים דומות מבחינה סמנטית.
    • חיפוש היברידי: מבצע חיפוש של מילות מפתח וחיפוש RAG סמנטי, וממזג את התוצאות באמצעות Reciprocal Rank Fusion‏ (RRF) כדי להבטיח רלוונטיות וכיסוי גבוהים.
  5. הנציג הראשי מבצע את אסטרטגיית החיפוש המתאימה ב-Knowledge Graph, שמאוחסן ב-Spanner Graph, ומאחזר את תוצאות החיפוש.
  6. הנציג הראשי מפעיל פונקציית קריאה חוזרת (callback) כדי לשמור את נתוני הסשן ב-Agent Platform Sessions. הנציג הראשי מחלץ מהסשן נושאי זיכרון בהתאמה אישית. לדוגמה, מנהל תיקי השקעות יכול ליצור נושא בזיכרון כדי לעקוב אחרי דגלים רגולטוריים או מגמות חדשות בתחום.
  7. הסוכן הראשי מעביר את התשובה המסוכמת לאפליקציית האינטרנט.
  8. אפליקציית האינטרנט מעבירה את התשובה בחזרה למשתמש.

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

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

  • ‫ Cloud Run: פלטפורמת מחשוב בלי שרת (serverless computing) שמאפשרת להריץ קונטיינרים ישירות בתשתית של Google, שניתנת להתאמה לעומס.
  • ‫ Gemini: קבוצה של מודלי AI מולטי-מודאליים שפותחו על ידי Google.
  • ‫ Gemini Enterprise Agent Platform: פלטפורמה מקיפה שמאפשרת ליצור, לנהל, לבצע אופטימיזציה ולהתאים לעומס (scale) סוכני AI ברמה שמתאימה לארגונים.
  • ‫ Cloud Storage: מאגר אובייקטים ללא הגבלה ובעלות נמוכה, לסוגי נתונים שונים. אפשר לגשת לנתונים מתוך Google Cloudומחוץ לו, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
  • ‫ Spanner Graph: מסד נתונים של גרפים שמספק את תכונות המדרגיות, הזמינות והעקביות של Spanner.
  • סשנים ב-Gemini Enterprise Agent Platform: שירות אחסון מתמיד ששומר ומאחזר את היסטוריית האינטראקציות בין משתמשים לסוכנים.
  • ‫ Memory Bank: שירות אחסון מתמיד שיוצר, משפר, מנהל ושולף זיכרונות לטווח ארוך על סמך השיחות של המשתמש עם הנציג.

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

תרחיש לדוגמה

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

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

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

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

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

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

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

עיצוב סוכן AI

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

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

אבטחה, פרטיות ותאימות

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

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

  • ‫Agent Registry: מוודאים שהסוכנים מתחברים רק לסוכני משנה ולכלי MCP שאושרו.

  • הטמעת בקרת גישה מפורטת (FGAC): השתמשו בבקרת גישה מפורטת כדי לאשר גישה ברמת הטבלה והעמודה. מגבילים את המדיניות של הקטגוריה ב-Cloud Storage, כך שרק לחשבון השירות של Cloud Run תהיה גישה.

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

אמינות

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

יעילות תפעולית

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

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

הוזלת עלויות

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

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

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

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

  • ניתוב של הסוכן הראשי: כדי לצמצם את זמן האחזור ולמנוע הפעלות מיותרות של סוכני משנה, הגדירו בבירור את לוגיקת הניתוב בהוראות לסוכן. חשוב לוודא שהמטרה, הפרמטרים של הקלט והפלט הצפוי של כל כלי מתועדים במחרוזות מילוליות, כדי לעזור למודל לבחור את הכלי הנכון.
  • מודלים של AI במסד הנתונים: כדי לצמצם את זמן האחזור, אפשר להשתמש בפונקציה ML.PREDICT של Spanner כדי להפעיל מודלים בתוך השורה בשאילתות SQL. לעקוב אחרי השימוש במכסה של Agent Platform, כי עומסי עבודה של חיפוש היברידי יכולים להפעיל כמה קריאות למודל לכל שאילתה.
  • הקצאת משאבים: בהתאם לדרישות הביצועים, מגדירים את מגבלות הזיכרון ואת מגבלות המעבד (CPU) שיוקצו לשירות Cloud Run.

פריסה

כדי לפרוס הטמעה לדוגמה של הארכיטקטורה הזו, נסו את שיעור ה-Codelab בנושא Way Back Home ברמה 2.

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

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

מחברים:

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