במסמך הזה מוסבר איך לבחור רכיבי ארכיטקטורה לאפליקציות AI אקטיבי ב- Google Cloud. במאמר הזה מוסבר איך להעריך את המאפיינים של האפליקציה ועומס העבודה כדי לבחור מוצר או שירות מתאימים שיענו על הצרכים שלכם בצורה הטובה ביותר. תהליך התכנון של ארכיטקטורת AI אקטיבי הוא איטרטיבי. כדאי להעריך מחדש את הארכיטקטורה שלכם מדי פעם, ככל שמאפייני עומס העבודה משתנים, ככל שהדרישות מתפתחות או ככל שמוצרים ותכונות חדשים של Google Cloud Google הופכים לזמינים.
סוכני AI יעילים לאפליקציות שפותרות בעיות פתוחות, שעשויות לדרוש קבלת החלטות אוטונומית וניהול מורכב של תהליכי עבודה מרובי-שלבים. סוכנים מצטיינים בפתרון בעיות בזמן אמת באמצעות נתונים חיצוניים, והם מצטיינים באוטומציה של משימות שדורשות ידע רב. היכולות האלה מאפשרות לסוכנים לספק ערך עסקי רב יותר מאשר היכולות של מודל AI גנרטיבי.
אפשר להשתמש בסוכני AI לבעיות דטרמיניסטיות עם שלבים מוגדרים מראש. עם זאת, יש גישות אחרות שיכולות להיות יעילות ומשתלמות יותר. לדוגמה, לא צריך תהליך עבודה מבוסס-סוכן למשימות כמו סיכום מסמך, תרגום טקסט או סיווג משוב מלקוחות.
למידע על פתרונות חלופיים של AI שאינם מבוססי-סוכן, אפשר לעיין במקורות המידע הבאים:
סקירה כללית של ארכיטקטורת הסוכן
סוכן הוא אפליקציה שמשיגה יעד על ידי עיבוד קלט, ביצוע ניתוח באמצעות כלים זמינים וביצוע פעולות על סמך ההחלטות שלה. סוכן משתמש במודל AI כמנוע הליבה שלו לחשיבה רציונלית, כדי להפוך משימות מורכבות לפעולות אוטומטיות. הסוכן משתמש בסדרה של כלים שמאפשרים למודל ה-AI ליצור אינטראקציה עם מערכות חיצוניות ומקורות נתונים. סוכן יכול להשתמש במערכת זיכרון כדי לשמור על ההקשר וללמוד מאינטראקציות. המטרה של ארכיטקטורה מבוססת-סוכנים היא ליצור מערכת אוטונומית שיכולה להבין את הכוונה של המשתמש, ליצור תוכנית מרובת שלבים ולבצע את התוכנית באמצעות הכלים הזמינים.
התרשים הבא מציג סקירה כללית של רכיבי הארכיטקטורה של מערכת מבוססת-סוכנים:
ארכיטקטורת המערכת מבוססת-הסוכנים כוללת את הרכיבים הבאים:
- מסגרת Frontend: אוסף של רכיבים, ספריות וכלים מוכנים מראש שמשמשים לבניית ממשק המשתמש של האפליקציה.
- מסגרת לפיתוח סוכנים: המסגרות והספריות שבהן משתמשים כדי לבנות את הלוגיקה של הסוכן ולתת לה מבנה.
- כלים של סוכנים: אוסף של כלים, כמו ממשקי API, שירותים ופונקציות, שמחלצים נתונים ומבצעים פעולות או טרנזקציות.
- זיכרון הסוכן: המערכת שבה הסוכן משתמש כדי לאחסן מידע ולשלוף אותו.
- דפוסי עיצוב של סוכנים: גישות ארכיטקטוניות נפוצות לבניית אפליקציה מבוססת-סוכנים.
- זמן ריצה של סוכן: סביבת המחשוב שבה פועל הלוגיקה של אפליקציית הסוכן.
- מודלים של AI: מנוע הליבה של החשיבה הרציונלית שמפעיל את יכולות קבלת ההחלטות של הסוכן.
- זמן הריצה של המודל: התשתית שמארחת את מודל ה-AI ומספקת אותו.
בסעיפים הבאים מופיע ניתוח מפורט של הרכיבים, שיעזור לכם לקבל החלטות לגבי האופן שבו כדאי לבנות את הארכיטקטורה. הבחירה שלכם ברכיבים תשפיע על הביצועים, יכולת ההתאמה, העלות והאבטחה של הסוכן. המסמך הזה מתמקד ברכיבים הארכיטקטוניים החיוניים שבהם משתמשים כדי ליצור ולפרוס את הלוגיקה הבסיסית של הנימוק והביצוע של סוכן. נושאים כמו מסגרות של אתיקה של בינה מלאכותית לניהול בטיחות וניהול זהויות של סוכנים לא נכללים במסגרת המסמך הזה.
Frontend framework
ה-frontend framework הוא אוסף של רכיבים, ספריות וכלים מוכנים מראש שמשמשים לבניית ממשק המשתמש של האפליקציה מבוססת-הסוכן. מסגרת הקצה הקדמי שבוחרים מגדירה את הדרישות של הבק-אנד. ממשק פשוט להדגמה פנימית עשוי לדרוש רק API סינכרוני של HTTP, בעוד שאפליקציה ברמת ייצור דורשת קצה עורפי שתומך בפרוטוקולים של סטרימינג ובניהול מצב חזק.
כדאי להביא בחשבון את הקטגוריות הבאות של מסגרות:
- מסגרות ליצירת אב טיפוס וכלים פנימיים: כדי לפתח במהירות, ליצור הדגמות פנימיות ולפתח אפליקציות להוכחת היתכנות, כדאי לבחור מסגרות שמתמקדות בחוויית המפתחים ובמהירות הפיתוח. בדרך כלל, המסגרות האלה מעדיפות מודל פשוט וסינכרוני שנקרא מודל בקשה-תגובה. מודל של בקשה ותגובה מאפשר לכם ליצור ממשק משתמש פונקציונלי עם מינימום קוד וקצה עורפי פשוט יותר בהשוואה למסגרת ייצור. הגישה הזו אידיאלית לבדיקה מהירה של הלוגיקה של הסוכן ושילוב הכלים, אבל היא לא מתאימה לאפליקציות ציבוריות שניתנות להרחבה גבוהה ודורשות אינטראקציות בזמן אמת. דוגמאות למסגרות נפוצות בקטגוריה הזו: Mesop ו-Gradio.
- מסגרות Production: כדי ליצור אפליקציות עשירות בתכונות, מדרגיות, רספונסיביות ומתאימות למשתמשים חיצוניים, כדאי לבחור מסגרת שמאפשרת ליצור רכיבים בהתאמה אישית. המסגרות האלה דורשות ארכיטקטורה של קצה עורפי שיכולה לתמוך בחוויית משתמש מודרנית. מסגרת ייצור צריכה לכלול תמיכה בפרוטוקולי סטרימינג, עיצוב API בלי שמירת מצב ומערכת זיכרון חיצונית חזקה לניהול מצב השיחה בכמה סשנים של משתמשים. מסגרות נפוצות לאפליקציות בסביבת ייצור כוללות את Streamlit, React ו-Flutter AI Toolkit.
כדי לנהל את התקשורת בין המסגרות האלה לבין סוכן ה-AI, אפשר להשתמש בפרוטוקול Agent–User Interaction (AG-UI). AG-UI הוא פרוטוקול פתוח שמאפשר לסוכני AI בבק-אנד ליצור אינטראקציה עם מסגרת הפרונט-אנד שלכם. הספרייה AG-UI אומרת למסגרת ה-frontend מתי לרנדר את התגובה של ה-Agent, לעדכן את מצב האפליקציה או להפעיל פעולה בצד הלקוח. כדי לפתח אפליקציות אינטראקטיביות מבוססות-AI, אפשר לשלב בין AG-UI לבין Agent Development Kit (ADK). מידע על ADK מופיע בקטע הבא, 'מסגרות לפיתוח סוכנים'.
מסגרות לפיתוח סוכנים
מסגרות לפיתוח סוכנים הן ספריות שמפשטות את התהליך של בנייה, בדיקה ופריסה של אפליקציות AI אקטיבי. כלי הפיתוח האלה מספקים רכיבים מובנים והפשטות ליכולות ליבה של סוכנים, כולל לולאות נימוקים, זיכרון ושילוב כלים.
כדי לפתח סוכנים מהר יותר ב- Google Cloud, מומלץ להשתמש ב-ADK. ADK הוא פריימוורק מודולרי, קבוע ובעל קוד פתוח, שמספק רמה גבוהה של הפשטה לבנייה ולתזמור של תהליכי עבודה, ממשימות פשוטות ועד למערכות מורכבות מרובות סוכנים.
ערכת ה-ADK מותאמת למודלים של Gemini ו- Google Cloud, אבל היא מיועדת לתאימות למסגרות אחרות. ערכת ה-ADK תומכת במודלים אחרים של AI ובזמני ריצה, כך שאפשר להשתמש בה עם כל מודל או שיטת פריסה. במערכות מרובות סוכנים, ADK תומך באינטראקציה באמצעות מצבי סשן משותפים, בהעברת הרשאות מבוססת-מודל לניתוב משימות בין סוכנים ובהפעלה מפורשת שמאפשרת לסוכן אחד לקרוא לסוכן אחר כפונקציה או ככלי.
כדי לעזור לכם להתחיל במהירות, ב-ADK יש דוגמאות לקוד ב-Python, ב-Java וב-Go שמדגימות מגוון תרחישי שימוש בתחומים שונים. למרות שרבים מהדוגמאות האלה מדגישות זרימות שיחה, ערכת ה-ADK מתאימה גם ליצירת סוכנים אוטונומיים שמבצעים משימות בקצה העורפי. לתרחישי השימוש הלא אינטראקטיביים האלה, מומלץ לבחור דפוס עיצוב של סוכן שמצטיין בעיבוד של בקשה אחת עצמאית, ומיישם טיפול חזק בשגיאות.
כדי ליצור ארכיטקטורה של סוכן בהתאמה אישית, אפשר גם להשתמש במסגרת AI למטרות כלליות כמו Genkit. Genkit מספק פרימיטיבים שמאפשרים לכם לשלוט במדויק בלוגיקה של הסוכן בלי ההפשטה ברמה גבוהה ש-ADK מציע. עם זאת, פלטפורמה ייעודית לסוכנים כמו ADK מספקת כלים מיוחדים לפיתוח אפליקציות עם סוכנים.
כלים לנציגים
היכולת של סוכן ליצור אינטראקציה עם מערכות חיצוניות באמצעות כלים מגדירה את היעילות שלו. כלים של סוכנים הם פונקציות או ממשקי API שזמינים למודל ה-AI, והסוכן משתמש בהם כדי לשפר את הפלט ולאפשר אוטומציה של משימות. כשמחברים סוכן AI למערכות חיצוניות, כלים הופכים את הסוכן מכלי ליצירת טקסט למערכת שיכולה לבצע אוטומטית משימות מורכבות שכוללות כמה שלבים.
כדי להפעיל אינטראקציות עם כלי, בוחרים אחת מהאפשרויות הבאות:
| תרחיש לדוגמה | דפוס השימוש בכלי |
|---|---|
| אתם צריכים לבצע משימה נפוצה כמו השלמת חיפוש באינטרנט, ביצוע חישוב או הפעלת קוד, ואתם רוצים להאיץ את הפיתוח הראשוני. | כלים מובנים |
| אתם רוצים לבנות מערכת מודולרית או מערכת עם כמה סוכנים שדורשת כלים שניתן להשתמש בהם שוב ושוב ושיכולים לפעול יחד. | Model Context Protocol (MCP) |
| אתם צריכים לנהל, לאבטח ולנטר מספר גדול של כלים מבוססי API בקנה מידה ארגוני. | פלטפורמה לניהול API |
| אתם צריכים לבצע שילוב עם API פנימי או של צד שלישי שאין לו שרת MCP. | כלים לפונקציות מותאמות אישית |
כשבוחרים כלים לסוכן, חשוב להעריך את היכולות הפונקציונליות שלהם ואת המהימנות התפעולית שלהם. כדאי לתת עדיפות לכלים שניתן לצפות בהם, שקל לבצע בהם ניפוי באגים ושכוללים טיפול חזק בשגיאות. היכולות האלה עוזרות לכם לעקוב אחרי פעולות ולפתור בעיות במהירות. בנוסף, כדאי להעריך את היכולת של הסוכן לבחור את הכלי הנכון כדי להשלים בהצלחה את המשימות שהוקצו לו.
כלים מובנים
ADK מספק כמה כלים מובנים שמשולבים ישירות בזמן הריצה של הסוכן. אפשר להשתמש בכלים האלה כפונקציות בלי להגדיר פרוטוקולי תקשורת חיצוניים. הכלים האלה מספקים פונקציות נפוצות, כולל גישה למידע בזמן אמת מהאינטרנט, הפעלת קוד באופן פרוגרמטי בסביבה מאובטחת, אחזור מידע מנתונים פרטיים של ארגונים כדי להטמיע RAG ואינטראקציה עם נתונים מובנים במסדי נתונים בענן. הכלים המובנים פועלים לצד כלים בהתאמה אישית שאתם יוצרים.
MCP
כדי לאפשר לרכיבים של המערכת האגנטית שלכם אינטראקציה, אתם צריכים להגדיר פרוטוקולי תקשורת ברורים. MCP הוא פרוטוקול פתוח שמספק ממשק סטנדרטי לסוכנים כדי לגשת לכלים, לנתונים ולשירותים אחרים שדרושים להם ולהשתמש בהם.
ה-MCP מפריד את לוגיקת הליבה של הסוכן מההטמעה הספציפית של הכלים שלו, בדומה לאופן שבו יציאת חומרה רגילה מאפשרת לציוד היקפי שונה להתחבר למכשיר. פלטפורמת ה-MCP מפשטת את שילוב הכלים כי היא מספקת רשימה גדלה של מחברים מוכנים מראש ודרך עקבית ליצירת שילובים בהתאמה אישית. הגמישות בשילוב כלים מקדמת יכולת פעולה הדדית בין מודלים וכלים שונים.
אתם יכולים להתחבר לשרת MCP מרוחק אם יש כזה, או לארח שרת MCP משלכם. כשמארחים שרת MCP משלכם, יש לכם שליטה מלאה על האופן שבו אתם חושפים את ה-API הקנייני או של צד שלישי לסוכנים שלכם. כדי לארח שרת MCP מותאם אישית משלכם, אתם יכולים לפרוס אותו כאפליקציה בקונטיינר ב-Cloud Run או ב-GKE.
פלטפורמה לניהול API
פלטפורמה לניהול ממשקי API היא מערכת מרכזית שמאפשרת לאבטח, לנטר ולשלוט בשירותים פנימיים או חיצוניים באמצעות ממשקי API. פלטפורמה לניהול ממשקי API מספקת מיקום מרכזי לקטלוג של כל ממשקי ה-API בארגון, מפשטת את האופן שבו חושפים נתונים ומספקת יכולת צפייה באמצעות מעקב אחר השימוש.
כדי לנהל את הכלים מבוססי ה-API של הסוכן בקנה מידה ארגוני ב- Google Cloud, מומלץ להשתמש ב-Apigee API hub. מרכז ה-API מאפשר לסוכנים להתחבר לנתונים באופן מיידי באמצעות קריאות HTTP ישירות, מחברים מוכנים מראש, ממשקי API מותאמים אישית שרשומים במרכז או גישה ישירה למקורות נתונים. Google Cloud הגישה הזו מאפשרת לסוכנים שלכם לקבל גישה מיידית למידע שהם צריכים, בלי הצורך לבנות צינורות מורכבים לטעינה ולשילוב של נתונים בהתאמה אישית.
פלטפורמה לניהול API ופרוטוקול תקשורת כמו MCP פותרים בעיות שונות בארכיטקטורה. פרוטוקול תקשורת קובע את הפורמט של האינטראקציה בין הסוכן לבין הכלי, וכך מבטיח שאפשר לעשות שימוש חוזר ברכיבים ולהחליף אותם. לעומת זאת, פלטפורמה לניהול API שולטת במחזור החיים ובאבטחה של נקודת קצה ל-API, ומטפלת במשימות כמו אימות, הגבלת קצב של יצירת בקשות ומעקב. הדפוסים האלה משלימים זה את זה. לדוגמה, סוכן יכול להשתמש ב-MCP כדי לתקשר עם כלי, והכלי הזה יכול להיות נקודת קצה ל-API מאובטחת שמנוהלת ומוגנת על ידי API Hub.
כלי פונקציה מותאמת אישית
כלי פונקציות מעניק לסוכן יכולות חדשות. אתם יכולים לכתוב כלי פונקציה בהתאמה אישית כדי להעניק לסוכן יכולות מיוחדות, כמו שילוב עם API חיצוני או עם מערכת עסקית קניינית. הדפוס הנפוץ ביותר להרחבת היכולות של סוכן מעבר למה שכלי מובנים יכולים להציע הוא כתיבת כלי פונקציה בהתאמה אישית.
כדי ליצור כלי פונקציה בהתאמה אישית, כותבים פונקציה בשפת התכנות המועדפת, ואז מספקים תיאור ברור בשפה טבעית של המטרה, הפרמטרים וערכי ההחזרה שלה. המודל של הסוכן משתמש בתיאור הזה כדי להבין מתי צריך להשתמש בכלי, אילו קלט צריך לספק ואיך לפרש את הפלט כדי להשלים את הבקשה של המשתמש.
אפשר גם ליצור כלי פונקציה בהתאמה אישית שמטמיע פונקציה של סוכן ככלי. פונקציה מסוג 'סוכן ככלי' חושפת סוכן אחד כפונקציה שאפשר להפעיל, וסוכן אחר יכול להפעיל אותה. הטכניקה הזו מאפשרת לכם לבנות מערכות מורכבות עם כמה סוכנים, שבהן סוכן יכול לתאם ולהקצות משימות מיוחדות לסוכנים אחרים. מידע נוסף על דפוסי עיצוב של סוכנים ועל תיאום של אורקסטרציה מרובת סוכנים זמין בהמשך המאמר בקטע בנושא דפוסי עיצוב של סוכנים.
הזיכרון של הסוכן
היכולת של נציג לזכור אינטראקציות קודמות היא חיונית כדי לספק חוויה עקבית ומועילה בשיחה. כדי ליצור סוכנים עם מצב ועם מודעות להקשר, צריך להטמיע מנגנונים לזיכרון לטווח קצר ולזיכרון לטווח ארוך. בקטעים הבאים נסביר על אפשרויות העיצוב ועל השירותים שבהם אפשר להשתמש כדי להטמיע זיכרון לטווח קצר ולטווח ארוך בסוכן. Google Cloud
זיכרון לטווח קצר
הזיכרון לטווח קצר מאפשר לסוכן לשמור על ההקשר בשיחה אחת מתמשכת. כדי להטמיע זיכרון לטווח קצר, צריך לנהל גם את הסשן וגם את המצב שמשויך אליו.
- Session: סשן הוא רצף השיחה בין משתמש לבין הנציג, מהאינטראקציה הראשונית ועד לסיום הדיאלוג.
- מצב: מצב הוא הנתונים שהסוכן משתמש בהם ואוסף אותם במהלך סשן ספציפי. נתוני המצב שנאספים כוללים את היסטוריית ההודעות שהמשתמש והסוכן החליפו ביניהם, את התוצאות של כל קריאות הכלים ומשתנים אחרים שהסוכן צריך כדי להבין את ההקשר של השיחה.
אלה האפשרויות להטמעת זיכרון לטווח קצר באמצעות ADK:
- אחסון בזיכרון: לצורך פיתוח, בדיקה או אפליקציות פשוטות שפועלות במופע יחיד, אפשר לאחסן את מצב הסשן ישירות בזיכרון של האפליקציה. הסוכן משתמש במבנה נתונים, כמו מילון או אובייקט, כדי לאחסן רשימה של צמדי מפתח-ערך, והוא מעדכן את הערכים האלה במהלך הסשן. עם זאת, כשמשתמשים באחסון בזיכרון, מצב הסשן לא נשמר. אם האפליקציה תופעל מחדש, כל היסטוריית השיחות תימחק.
ניהול מצב חיצוני: לאפליקציות בייצור שנדרשת בהן מדרגיות ומהימנות, מומלץ ליצור אפליקציית סוכן בלי שמירת מצב ולנהל את מצב הסשן בשירות אחסון חיצוני. בארכיטקטורה הזו, בכל פעם שאפליקציית הסוכן מקבלת בקשה, היא מאחזרת את מצב השיחה הנוכחי מהמאגר החיצוני, מעבדת את התור החדש ואז שומרת את המצב המעודכן בחזרה במאגר. העיצוב הזה מאפשר לכם להרחיב את האפליקציה באופן אופקי, כי כל מופע יכול לטפל בבקשה של כל משתמש. אפשרויות נפוצות לניהול מצב חיצוני כוללות את Memorystore for Redis, Firestore או סשנים של Vertex AI Agent Engine.
אם משתמשים ב-ADK, ל-
DatabaseSessionServiceנדרש מסד נתונים רלציוני, כמו Cloud SQL.
זיכרון לטווח ארוך
זיכרון לטווח ארוך מספק לנציג מאגר ידע קבוע שקיים בכל השיחות עם משתמשים ספציפיים. הזיכרון לטווח ארוך מאפשר לסוכן לאחזר מידע חיצוני ולהשתמש בו, ללמוד מאינטראקציות קודמות ולספק תשובות מדויקות ורלוונטיות יותר.
אלה האפשרויות להטמעת זיכרון לטווח ארוך באמצעות ADK:
- אחסון בזיכרון: לצורך פיתוח ובדיקה, אפשר לאחסן את מצב הסשן ישירות בזיכרון של האפליקציה. הגישה הזו פשוטה להטמעה, אבל היא לא קבועה. אם האפליקציה תופעל מחדש, היסטוריית השיחות תימחק. בדרך כלל מטמיעים את התבנית הזו באמצעות ספק בזיכרון במסגרת פיתוח, כמו
InMemoryMemoryServiceשכלול ב-ADK לצורך בדיקה. - התקן אחסון חיצוני: באפליקציות Production, מומלץ לנהל את מאגר הידע של ה-Agent בשירות אחסון מתמיד חיצוני. שירות אחסון חיצוני מבטיח שהידע של הסוכן יהיה עמיד, ניתן להרחבה ונגיש בכמה מופעים של האפליקציה. אפשר להשתמש ב-Memory Bank לאחסון לטווח ארוך עם כל סביבת זמן ריצה של סוכן ב- Google Cloud.
תבניות עיצוב של סוכנים
תבניות עיצוב של סוכנים הן גישות אדריכליות נפוצות לבניית אפליקציות מבוססות-סוכנים. הדפוסים האלה מציעים מסגרת ברורה לארגון הרכיבים של המערכת, לשילוב של מודל ה-AI ולתיאום של סוכן יחיד או של כמה סוכנים כדי להשלים תהליך עבודה. כדי לקבוע איזו גישה היא הטובה ביותר לתהליך העבודה שלכם, צריך לקחת בחשבון את המורכבות של המשימות, את תהליך העבודה, את זמן האחזור, את הביצועים ואת דרישות העלות.
מערכת עם סוכן יחיד מסתמכת על יכולות החשיבה הרציונלית של מודל אחד כדי לפרש את בקשת המשתמש, לתכנן רצף של שלבים ולהחליט באילו כלים להשתמש. הגישה הזו היא נקודת התחלה יעילה שמאפשרת לכם להתמקד בשיפור הלוגיקה הבסיסית, בהנחיות ובהגדרות הכלים לפני שאתם מוסיפים מורכבות ארכיטקטונית. עם זאת, הביצועים של סוכן יחיד עלולים להידרדר ככל שהמשימות ומספר הכלים נעשים מורכבים יותר.
בבעיות מורכבות, מערכת מרובת סוכנים מתזמרת כמה סוכנים מומחים כדי להשיג מטרה שסוכן יחיד לא יכול לנהל בקלות. העיצוב המודולרי הזה יכול לשפר את יכולת ההתאמה, את המהימנות ואת יכולת התחזוקה של המערכת. עם זאת, בהשוואה למערכת עם סוכן יחיד, היא גם מחייבת שיקולים נוספים לגבי הערכה, אבטחה ועלויות.
כשמפתחים מערכת מרובת סוכנים, צריך להטמיע אמצעי בקרה מדויקים לגישה לכל סוכן מומחה, לתכנן מערכת תזמור חזקה כדי להבטיח תקשורת מהימנה בין הסוכנים ולנהל את העלויות התפעוליות המוגדלות שנובעות מהתקורה החישובית של הפעלת כמה סוכנים. כדי לאפשר תקשורת בין נציגים, משתמשים בפרוטוקול Agent2Agent (A2A) עם ADK. A2A הוא פרוטוקול תקני פתוח שמאפשר לסוכני AI לתקשר ולשתף פעולה בין פלטפורמות ומסגרות שונות, ללא קשר לטכנולוגיות הבסיסיות שלהם.
מידע נוסף על דפוסי עיצוב נפוצים של סוכנים ועל אופן הבחירה של דפוס בהתאם לדרישות העומס שלכם זמין במאמר בחירת דפוס עיצוב למערכת AI אקטיבי.
מודלים של AI
אפליקציות מבוססות-סוכן מסתמכות על יכולות החשיבה הרציונלית וההבנה של מודל כדי לפעול ככלי תזמור המשימות הראשי. לתפקיד הליבה הזה של הסוכן, מומלץ להשתמש ב-Gemini Pro.
מודלים של Google, כמו Gemini, מספקים גישה למודלים הקנייניים הכי מתקדמים באמצעות API מנוהל. הגישה הזו מתאימה במיוחד לצמצום התקורה התפעולית. לעומת זאת, מודל פתוח שמתארח באופן עצמאי מספק את השליטה המעמיקה שנדרשת כשמבצעים כוונון עדין של נתונים קנייניים. גם עומסי עבודה עם דרישות מחמירות לגבי אבטחה ומיקום הנתונים דורשים מודל באירוח עצמי, כי הוא מאפשר להריץ את המודל ברשת שלכם.
כדי לשפר את הביצועים של ה-Agent, אפשר לשנות את יכולות החשיבה הרציונלית של המודל. מודלים כמו המודלים העדכניים של Gemini Pro ו-Flash כוללים תהליך חשיבה מובנה שמשפר את החשיבה הרציונלית ואת התכנון הרב-שלבי. לצורך ניפוי באגים ושיפורים, אתם יכולים לעיין בסיכומי המחשבות של המודל, או בגרסאות מסונתזות של המחשבות הפנימיות שלו, כדי להבין את תהליך החשיבה שלו. אתם יכולים לשלוט ביכולות הנימוק של המודל על ידי שינוי תקציב החשיבה, או מספר הטוקנים של החשיבה, בהתאם למורכבות המשימה. תקציב חשיבה גבוה יותר מאפשר למודל לבצע תהליכי הסקת מסקנות ותכנון מפורטים יותר לפני שהוא מספק תשובה. תקציב חשיבה גבוה יותר יכול לשפר את איכות התשובות, אבל הוא גם עלול להגדיל את זמן האחזור ואת העלות.
כדי לבצע אופטימיזציה של הביצועים והעלויות, כדאי להטמיע ניתוב מודלים כדי לבחור באופן דינמי את המודל המתאים ביותר לכל משימה על סמך המורכבות, העלות או דרישות זמן האחזור של המשימה. לדוגמה, אפשר להפנות בקשות פשוטות למודל שפה קטן (SLM) למשימות מובנות כמו יצירת קוד או סיווג טקסט, ולהשתמש במודל חזק ויקר יותר להסקת מסקנות מורכבת. אם מטמיעים ניתוב מודלים באפליקציה מבוססת-סוכנים, אפשר ליצור מערכת חסכונית שמספקת ביצועים גבוהים.
Google Cloud מאפשרת גישה למבחר רחב של מודלים של Google, מודלים של שותפים ומודלים פתוחים שאפשר להשתמש בהם בארכיטקטורה של AI אקטיבי. למידע נוסף על המודלים שזמינים ועל אופן הבחירה של מודל שמתאים לצרכים שלכם, אפשר לעיין במאמר בנושא Model Garden ב-Vertex AI.
זמן הריצה של המודל
זמן ריצה של מודל הוא הסביבה שמארחת את מודל ה-AI ומספקת אותו, ושמאפשרת לסוכן להשתמש ביכולות החשיבה הרציונלית שלו.
בחירת זמן ריצה של מודל
כדי לבחור את זמן הריצה הטוב ביותר כשמארחים מודלים של AI, אפשר להיעזר בהנחיות הבאות:
| תרחיש לדוגמה | זמן הריצה של המודל |
|---|---|
| אתם צריכים ממשק API מנוהל כדי להשתמש במודלים של Gemini, במודלים של שותפים, במודלים פתוחים או במודלים בהתאמה אישית עם אבטחה, יכולת הרחבה וכלים של AI גנרטיבי ברמה שמתאימה לארגונים. | Vertex AI |
| צריך לפרוס מודל פתוח או מותאם אישית שמבוסס על קונטיינרים, ולתת עדיפות לפשטות ולחסכוניות של בלי שרת (serverless) עבור תנועה משתנה. | Cloud Run |
| אתם צריכים שליטה מקסימלית בתשתית כדי להפעיל מודל פתוח או מותאם אישית של קונטיינר על חומרה ייעודית, או כדי לעמוד בדרישות מורכבות של אבטחה ורשת. | GKE |
בקטעים הבאים מופיעה סקירה כללית של זמני הריצה של המודלים הקודמים, כולל תכונות עיקריות ושיקולי עיצוב. במאמר הזה נתמקד ב-Vertex AI, ב-Cloud Run וב-GKE. עם זאת, Google Cloud יש שירותים אחרים שאפשר להשתמש בהם בזמן הריצה של המודל:
- Gemini API: Gemini API מיועד למפתחים שזקוקים לגישה מהירה וישירה למודלים של Gemini, בלי תכונות השליטה הארגוניות שמערכות מורכבות מבוססות-סוכנים דורשות בדרך כלל.
- Compute Engine: Compute Engine הוא מוצר של תשתית כשירות (IaaS) שמתאים לאפליקציות מדור קודם. הוא יוצר תקורה תפעולית משמעותית בהשוואה לסביבות זמן ריצה מודרניות שמבוססות על קונטיינרים.
מידע נוסף על התכונות שמבדילות בין כל אפשרויות השירות של זמני הריצה של המודלים זמין במאמר תשתית לאירוח מודלים.
Vertex AI
Vertex AI מספק סביבה מנוהלת ללא שרתים (serverless) שבה מתארחים מודלים של AI. אתם יכולים להפעיל ולכוונן מודלים של Google, מודלים של שותפים ומודלים פתוחים באמצעות API מאובטח וניתן להרחבה. הגישה הזו מאפשרת להסתיר את כל ניהול התשתית, ולהתמקד בשילוב של אינטליגנציית המודל באפליקציות.
כשמשתמשים ב-Vertex AI כזמן ריצה של מודל, התכונות והשיקולים העיקריים כוללים את הדברים הבאים:
- שליטה בתשתית: ממשק API מנוהל מלא למודלים שלכם. Google מנהלת את התשתית הבסיסית.
- אבטחה: הגדרות אבטחה מנוהלות כברירת מחדל ותקני תאימות מספיקים לצרכים שלכם. כדי לספק הגנה על הנחיות ותשובות וכדי להבטיח שיטות לפיתוח אחראי של AI, אתם יכולים לשלב את הגנה מוגברת על המודל ב-Vertex AI.
- זמינות של מודלים: גישה למבחר רחב של מודלים, כולל מודלי Gemini העדכניים ביותר, דרך API מנוהל.
- עלות: מודל תמחור של תשלום לפי שימוש, שמתרחב בהתאם לתנועה באפליקציה. מידע נוסף מפורט במאמר עלות הפיתוח והפריסה של מודלים של AI ב-Vertex AI.
Cloud Run
Cloud Run מספק סביבת ריצה ללא שרת שמארחת את המודלים שלכם בתוך קונטיינרים בהתאמה אישית. Cloud Run מציע איזון בין הפשטות המנוהלת באופן מלא של Vertex AI לבין השליטה המעמיקה בתשתית של GKE. הגישה הזו מתאימה במיוחד כשרוצים להריץ את המודל בסביבה מבוססת-קונטיינרים בלי לנהל שרתים או אשכולות.
כשמשתמשים ב-Cloud Run כזמן ריצה של מודל, התכונות והשיקולים העיקריים כוללים את הדברים הבאים:
- שליטה בתשתית: אפשר להריץ כל מודל בקונטיינר בהתאמה אישית, שמספק שליטה מלאה בסביבת התוכנה, בזמן שהפלטפורמה מנהלת את התשתית הבסיסית ללא שרת (serverless).
- אבטחה: מספקת אבטחה באמצעות מופעי מחשוב ארעיים ומבודדים, ומאפשרת חיבורים מאובטחים למשאבים פרטיים באמצעות תעבורת נתונים יוצאת (egress) ישירה של VPC או מחבר של Serverless VPC Access. מידע נוסף זמין במאמר רשת פרטית ו-Cloud Run.
- זמינות המודל: אפשר להפעיל מודלים פתוחים כמו Gemma או להפעיל מודלים מותאמים אישית משלכם. אי אפשר לארח או להפעיל מודלים של Gemini ב-Cloud Run.
- Cost: מודל תמחור לפי בקשה, שבו משלמים רק על מה שמשתמשים בו, וניתן להרחבה עד לאפס. לכן, הוא חסכוני מאוד למודלים עם תנועה משתנה או לא סדירה. מידע נוסף זמין במאמר בנושא תמחור של Cloud Run.
GKE
GKE מספק את השליטה והגמישות הכי גדולות לאירוח מודלים של AI. כדי להשתמש בגישה הזו, מריצים את המודלים בקונטיינרים באשכול GKE שמגדירים ומנהלים. GKE היא הבחירה האידיאלית כשצריך להפעיל מודלים על חומרה ייעודית, למקם אותם יחד עם האפליקציות כדי להשיג זמן אחזור מינימלי או כשנדרש שליטה מדויקת בכל היבט של סביבת ההגשה.
כשמשתמשים ב-GKE כזמן ריצה של מודל, התכונות והשיקולים העיקריים כוללים את הדברים הבאים:
- שליטה בתשתית: מאפשרת שליטה מקסימלית ומפורטת בסביבת ההגשה כולה, כולל הגדרות הצמתים, מאיצי מכונה ייעודיים ותוכנת ההגשה הספציפית של המודל.
- אבטחה: מאפשרת את הרמה הגבוהה ביותר של אבטחה ובידוד נתונים, כי אפשר להריץ מודלים באופן מלא בתוך הרשת שלכם וליישם מדיניות אבטחה מפורטת של Kubernetes. כדי לסנן תנועה אל אשכול GKE וממנו, ולהגן על כל האינטראקציות עם מודלים של AI, אפשר לשלב את הגנה מוגברת על המודל עם GKE .
- זמינות המודל: אפשר להפעיל מודלים פתוחים כמו Gemma, או להפעיל מודלים מותאמים אישית משלכם. אי אפשר לארח או להפעיל מודלים של Gemini ב-GKE.
- Cost: כולל מודל עלויות שמבוסס על משאבי הליבה של מחשוב ושל אשכולות שאתם צורכים, ולכן הוא מותאם במיוחד לעומסי עבודה צפויים בהיקף גדול כשמשתמשים בהנחות תמורת התחייבות לשימוש (CUD). מידע נוסף זמין במאמר בנושא תמחור של Google Kubernetes Engine.
Agent runtime
כדי לארח ולפרוס את האפליקציה מבוססת-הסוכן, צריך לבחור זמן ריצה של סוכן. השירות הזה מריץ את קוד האפליקציה שלכם – הלוגיקה העסקית והתיאום שאתם כותבים כשאתם משתמשים במסגרת לפיתוח סוכנים. מסביבת זמן הריצה הזו, האפליקציה שלכם מבצעת קריאות API למודלים שמתארחים ומנוהלים על ידי סביבת זמן הריצה של המודל שבחרתם.
בחירת זמן ריצה של סוכן
כדי לבחור את זמן הריצה כשמארחים סוכני AI, צריך לפעול לפי ההנחיות הבאות:
| תרחיש לדוגמה | Agent runtime |
|---|---|
| האפליקציה שלכם היא סוכן Python ונדרשת חוויה מנוהלת מלאה עם תקורה תפעולית מינימלית. | Vertex AI Agent Engine |
| האפליקציה שלך מבוססת על קונטיינרים ונדרשת לה יכולת התאמה (scaling) ללא שרת (serverless) שמבוססת על אירועים, עם גמישות בשפה. | Cloud Run |
| האפליקציה שלך מופעלת בתוך קונטיינר, יש לה דרישות מורכבות של מצב (stateful) והיא צריכה הגדרה מדויקת של התשתית. | GKE |
אם אתם כבר מנהלים אפליקציות ב-Cloud Run או ב-GKE, אתם יכולים להשתמש באותה פלטפורמה גם לעומס העבודה של הסוכן כדי להאיץ את הפיתוח ולפשט את הפעולות לטווח הארוך.
בקטעים הבאים מופיעה סקירה כללית של כל זמן ריצה של סוכן, כולל תכונות מרכזיות ושיקולי תכנון.
Vertex AI Agent Engine
Vertex AI Agent Engine הוא סביבת זמן ריצה מנוהלת במלואה, שניתן להשתמש בה כדי לפרוס, להפעיל ולהתאים לעומס (scaling) אפליקציות מבוססות-סוכנים. Vertex AI Agent Engine מסתיר את התשתית הבסיסית, כך שאתם יכולים להתמקד בלוגיקה של הסוכן במקום בפעולות.
אלה התכונות והשיקולים של Vertex AI Agent Engine:
- גמישות בשפת התכנות ובמסגרת העבודה: אפשר לפתח סוכנים ב-Python עם כל מסגרות העבודה הנתמכות.
- פרוטוקולי תקשורת: תיאום בין סוכנים וכלים שמשתמשים ב-MCP וב-A2A. Vertex AI Agent Engine מנהל ביעילות את זמן הריצה של הרכיבים האלה, אבל הוא לא תומך באירוח של שרתי MCP בהתאמה אישית.
- זיכרון: מספק יכולות זיכרון מובנות ומנוהלות, כך שלא צריך להגדיר מסדי נתונים חיצוניים לזיכרון הליבה של הסוכן.
דרישה אפשרויות זמינות זיכרון לטווח קצר סשנים של Vertex AI Agent Engine זיכרון לטווח ארוך Memory Bank חיפוש ואחזור של מסד נתונים - יכולת הרחבה: המערכת מתרחבת אוטומטית כדי לעמוד בדרישות של עומס העבודה של הסוכן, כך שלא צריך לבצע הגדרה ידנית.
- ניראות (observability): מספקת רישום ביומן, מעקב וגישוש משולבים באמצעות שירותי Google Cloud Observability.
- אבטחה: מספקת את האמינות, יכולת ההתאמה לעומס והתאימות הבאות ברמת הארגון:
- זהות שירות מובנית לקריאות מאובטחות ומאומתות ל-Google Cloud APIs.
- להריץ קוד בארגז חול מאובטח, מבודד ומנוהל באמצעות Vertex AI Agent Engine Code Execution.
- הגנה על הנתונים באמצעות מפתח הצפנה בניהול הלקוח (CMEK) משלכם ב-Secret Manager.
- כדי למנוע קריאות לא רצויות לרשת, צריך להגביל את הרשאות IAM ולהשתמש בכללי חומת אש של VPC.
מידע על תכונות האבטחה של Vertex AI Agent Engine זמין במאמר אבטחה בארגונים.
Vertex AI Agent Engine מקצר את הדרך להפעלת סוכנים בסביבת ייצור, כי הוא מספק סביבה מנוהלת שנוצרה במיוחד לטיפול בהרבה היבטים מורכבים של הפעלת סוכנים, כמו מחזור חיים וניהול הקשר. Vertex AI Agent Engine פחות מתאים לתרחישי שימוש שבהם נדרש התאמה אישית נרחבת של סביבת המחשוב, או שנדרשות שפות תכנות שאינן Python. עבור עומסי עבודה עם דרישות אבטחה מחמירות לניהול תלות פרטי, Cloud Run ו-GKE מציעים נתיב הגדרה ישיר יותר שמבוסס על IAM.
Cloud Run
Cloud Run היא פלטפורמה מנוהלת ללא שרת (serverless), שמאפשרת להריץ את קוד האפליקציה של הסוכן בקונטיינר ללא שמירת מצב. Cloud Run הוא פתרון אידיאלי כשרוצים לפרוס את כל אפליקציית הסוכן, רכיבים נפרדים או כלים בהתאמה אישית כנקודות קצה של HTTP שאפשר להתאים לעומס, בלי לנהל את התשתית הבסיסית.
אלה תכונות ושיקולים לגבי Cloud Run:
- גמישות בשפת התכנות ובמסגרת העבודה: כשיוצרים חבילה של האפליקציה במאגר, אפשר לפתח סוכנים בכל שפת תכנות ובכל מסגרת עבודה.
- פרוטוקולי תקשורת: תיאום בין סוכנים וכלים שמשתמשים ב-MCP וב-A2A. אירוח של לקוחות ושרתים של MCP עם תעבורת HTTP שניתנת להזרמה ב-Cloud Run.
- זיכרון: מכונות של Cloud Run הן חסרות מצב (stateless),
כלומר מכונה מאבדת את כל הנתונים בזיכרון אחרי שהיא מסיימת את הפעולה. כדי להטמיע זיכרון מתמשך, צריך לקשר את השירות לשירות אחסון מנוהל שלGoogle Cloud :
דרישה אפשרויות זמינות זיכרון לטווח קצר זיכרון לטווח ארוך - Firestore
- Memory Bank עם Cloud Run
חיפוש ואחזור של מסד נתונים - Cloud SQL
- AlloyDB ל-PostgreSQL
- יכולת הרחבה: התאמה אוטומטית של מספר המכונות בהתאם לתעבורת הנתונים הנכנסת, וגם הקטנה של מספר המכונות עד לאפס. התכונה הזו עוזרת להפוך את Cloud Run לחסכוני עבור אפליקציות עם עומסי עבודה משתנים.
- ניראות (observability): מספקת רישום ביומן, מעקב וניתוח משולבים באמצעות שירותי Google Cloud Observability. מידע נוסף מופיע במאמר סקירה כללית על מעקב ורישום ביומן.
- אבטחה: מספק את אמצעי הבקרה הבאים בנושא אבטחה לסוכנים שלכם:
- שירות זהות מובנה לקריאות מאובטחות ומאומתות ל-Google Cloud APIs.
- הפעלת קוד שלא נבדק בסביבה מאובטחת באמצעות סביבת ארגז החול של Cloud Run או באמצעות הרצת קוד ב-Vertex AI Agent Engine.
- אחסון מידע רגיש שמשמש את Cloud Run על ידי הגדרת סודות ב-Secret Manager.
- כדי למנוע שיחות לא רצויות ברשת, מגבילים את הרשאות IAM ומשתמשים בכללי חומת אש של VPC.
Cloud Run מציע פשטות תפעולית משמעותית וחסכוניות כי הוא מבטל את הצורך בניהול תשתית. עם זאת, בגלל האופי חסר המצב של Cloud Run, צריך להשתמש בשירות אחסון כדי לנהל את ההקשר בתהליך עבודה רב-שלבי. בנוסף, הזמן הקצוב לתפוגה של בקשות בשירותי Cloud Run הוא עד שעה אחת, מה שעשוי להגביל משימות ארוכות של סוכנים.
GKE
Google Kubernetes Engine (GKE) הוא שירות מנוהל של תזמור קונטיינרים, שמאפשר שליטה מדויקת בארכיטקטורה ובתשתית של האפליקציה מבוססת-הסוכן. GKE מתאים למערכות מורכבות שמבוססות על סוכנים ודורשות יכולות חזקות ברמת הייצור, או אם אתם כבר לקוחות של GKE ואתם רוצים להטמיע תהליך עבודה שמבוסס על סוכנים בנוסף לאפליקציה הקיימת שלכם.
אלה התכונות והשיקולים שזמינים ב-GKE:
- גמישות בשפת התכנות ובמסגרת העבודה: כשיוצרים חבילה של האפליקציה במאגר, אפשר לפתח סוכנים בכל שפת תכנות ובכל מסגרת עבודה.
- פרוטוקולי תקשורת: תיאום בין סוכנים וכלים שמשתמשים ב-MCP וב-A2A. אירוח של לקוחות ושרתים של MCP ב-GKE כשמארזים אותם כקונטיינרים.
- זיכרון: פודים של GKE הם זמניים.
עם זאת, אתם יכולים ליצור סוכנים עם מצב (stateful) וזיכרון מתמשך באמצעות משאבים בתוך האשכול או באמצעות חיבור לשירותים חיצוניים:
דרישה אפשרויות זמינות זיכרון לטווח קצר זיכרון לטווח ארוך - Firestore
- Memory Bank with GKE
חיפוש ואחזור של מסד נתונים - StatefulSets וPersistent Volumes לאחסון עמיד באשכול.
- Cloud SQL
- AlloyDB ל-PostgreSQL
- יכולת מדרגיות: אשכולות GKE מספקים ומתאימים באופן אוטומטי את מאגרי הצמתים בהתאם לדרישות של עומס העבודה.
- Observability: מספק רישום ביומן, מעקב וניתוח משולבים ברמות האשכול, הצומת וה-Pod באמצעות Google Cloud Observability. כדי לאסוף מדדים מוגדרים של צד שלישי ומדדים שהוגדרו על ידי המשתמש ואז לשלוח אותם אל Cloud Monitoring, אפשר גם להשתמש בשירות מנוהל של Google Cloud ל-Prometheus. מידע נוסף זמין במאמר סקירה כללית על יכולות התצפית ב-GKE.
- אבטחה: מספקת אמצעי בקרה מדויקים לאבטחת הסוכנים.
- משתמשים באיחוד שירותי אימות הזהות של עומסי עבודה ל-GKE כדי לבצע אימות מאובטח ל-Google Cloud APIs.
- בידוד קוד לא מהימן באמצעות GKE Sandbox.
- אחסון נתונים רגישים שמשמשים את אשכולות GKE ב-Secret Manager.
- כדי למנוע קריאות לא רצויות לרשת, צריך להגביל את הרשאות IAM ולהשתמש בכללי חומת אש של VPC ובמדיניות רשת.
GKE מספק שליטה וגמישות מקסימליות, ומאפשר לכם להפעיל סוכנים מורכבים עם שמירת מצב. עם זאת, אמצעי הבקרה הזה מוסיף מורכבות והוצאות תקורה משמעותיות. אתם צריכים להגדיר ולנהל את אשכול Kubernetes, כולל מאגרי צמתים, רישות ומדיניות שינוי גודל. זה דורש יותר מומחיות ומאמצי פיתוח מאשר פלטפורמה בלי שרת (serverless).
המאמרים הבאים
- כלים לנציגים:
- זיכרון של סוכן:
- דפוסי עיצוב של סוכנים:
- זמן הריצה של הסוכן:
- מקורות מידע נוספים על AI אקטיבי ב Google Cloud:
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: סמנתה הי | כותבת טכנית
תורמי תוכן אחרים:
- אמינה מנסור | ראש צוות הערכות של Cloud Platform
- Amit Maraj | Developer Relations Engineer
- Casey West | Architecture Advocate, Google Cloud
- ג'ק וות'רספון | אחראי קשרי מפתחים
- ג'ו פרננדז | כותב טכני
- Joe Shirey | Cloud Developer Relations Manager
- קרל ויינמייסטר | Director of Cloud Product Developer Relations
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- Lisa Shen | Senior Outbound Product Manager, Google Cloud
- מנדי גרובר | ראש תחום מרכז הארכיטקטורה
- מייגן או'קיף | אחראית קשרי מפתחים
- אוליבייה בורז'ואה | מהנדס קשרי מפתחים
- פולונג לין | מנהל הנדסה של קשרי מפתחים
- ריאן פיי | מנהל מוצר, Google Cloud
- שיר מאיר לדור | מנהלת הנדסה של קשרי מפתחים
- Vlad Kolesnikov | Developer Relations Engineer