דוח חדש שפרסמה חברת אינטל (Intel) מציג תובנות מתוך אלפי ניסויים שערכה על עומסי עבודה של סוכני בינה מלאכותית (Agentic AI) בסביבות ארגוניות. לפי ממצאי החברה, ההבטחה של סוכני בינה מלאכותית בארגונים גדולים חורגת משמעותית מעבר ליכולות של צ'אטבוטים משופרים. מדובר בתוכנות עצמאיות המבצעות משימות עסקיות מקצה לקצה תוך שילוב בין בני אדם, תהליכי עבודה עסקיים, נתונים ומערכות שונות. כדי להריץ סוכנים אלו בצורה אופטימלית, נדרשת פלטפורמה שנבנתה עם קיבולת מעבד (CPU) מתאימה, גישה עמידה לנתונים, שימוש בכלים המודעים למדיניות הארגונית, יכולות תצפיתיות (observability), ניהול זיכרון, והיכולת לתכנן ולשנות את קנה המידה של הסוכנים בצורה צפויה מראש. בעקבות אלפי הניסויים שביצעה, אינטל מציגה חמישה לקחים מעשיים עבור מנהלים בארגונים, ומסבירה כיצד יש לבנות את התשתית המתאימה ביותר להרצת סוכנים אלו באופן יעיל וחסכוני.
מעבר להסקה: סוכנים כאוטומציה של תהליכי עבודה
אינטל מדגישה כי סוכני בינה מלאכותית הם הרבה מעבר להסקה של מודלי שפה גדולים (LLM inference). הערך של סוכנים אלו בארגונים תלוי במערכת המלאה, בניהול המשימות (task orchestration), בגישה לנתונים, בהפעלת הכלים, בניהול זמני התגובה (latency), בממשל תאגידי (governance) ובתשתית הניתנת להרחבה. סוכן מוגדר כתהליך עבודה ארגוני אוטומטי המונחה על ידי מטרות קבועות: הוא מתכנן משימה רב-שלבית, מפעיל כלים חיצוניים, קורא את התוצאות ומבצע ניסיונות חוזרים (retries) כאשר שלב מסוים נכשל. מסיבה זו, סוכני בינה מלאכותית אינם מייצגים רק בעיה של הסקת מודלים, אלא אתגר מערכתי רחב ומורכב בהרבה. רוב כלי הבדיקה הקיימים כיום מוגבלים ואינם מודדים את ביצועי המערכת הכוללים, ולכן יש צורך בגישה מקיפה יותר למדידת ההצלחה.
הגדרת מדדי ההצלחה בעולם הארגוני
רוב המדדים הקיימים כיום עבור סוכני בינה מלאכותית מתמקדים בהערכת מודל השפה הגדול (LLM) שבו נעשה שימוש. עם זאת, צוותי הפלטפורמה בארגונים זקוקים למידע רחב בהרבה: כמה זמן אורכות המשימות, בכמה סוכנים יכול צי השרתים לתמוך בו-זמנית, מה חווים משתמשי הקצה בסיום תהליך ההרצה, וכיצד משתנות העלויות כאשר סוכנים מרובים פועלים במקביל. כדי לענות על שאלות אלו, מציעה אינטל להסתכל על שישה מדדים מרכזיים להערכת ביצועים בארגון: שיעור הצלחת המשימות (Task success rate), העלות עבור כל משימה (Cost per task), הזמן הנדרש לביצוע משימה (Time per task), קצב תפוקת המשימות (Task throughput), צפיפות הסוכנים, הנמדדת לפי מספר הסוכנים לכל ליבת מעבד וירטואלית (Agent density או agents per vCPU), וזמני תגובה ושהות (Latency). מדדים אלו מאפשרים למפעילי מערכות הבינה המלאכותית בארגון לקבוע האם המערכת מתפקדת כמצופה, בכמה סוכנים היא יכולה לתמוך באופן בר-קיימא, וכיצד יש להרחיב אותה כדי לתמוך בסוכנים נוספים.
הרחבת פלטפורמת Terminal-Bench למדידה מדויקת
כדי להבין לעומק את ביצועי עומסי העבודה של סוכני בינה מלאכותית, אינטל הרחיבה את כלי הבדיקה בקוד פתוח Terminal-Bench, המשמש להערכת סוכני AI, והוסיפה לו יכולות ניתוח פרופילים (profiling), טלמטריה (telemetry) ויכולת שחזור הרצות (replay). הרחבה זו אפשרה לחברה להבין היכן בדיוק הסוכנים מבלים את זמנם מעבר לתהליך הסקת ה-LLM עצמו. כדי לנטרל את ההשפעה של השינויים הפנימיים במעני ה-LLM ולבודד את ביצועי הסוכנים עצמם, הרחבת ה-benchmark עשתה שימוש בהקלטה ושחזור דטרמיניסטיים של תגובות ה-LLM. תגובות מודל השפה הוקלטו פעם אחת ושוחזרו בצורה זהה לחלוטין בין ההרצות השונות, דבר שהפחית את השונות בין הרצה להרצה ויצר בסיס השוואה אמין ומדויק בהרבה. תמהיל המשימות שבו נעשה שימוש ב-Terminal-Bench היה רחב במכוון כדי לדמות סביבות ארגוניות אמיתיות. הוא כלל משימות של הידור קוד (compilation), בדיקות (testing), פעולות במסדי נתונים (database operations), לוגיקה בוליאנית, פרשנות (interpretation), מעקב אחר קרני אור (ray tracing), דחיסת נתונים, אלגברה ליניארית, המרת פורמטי וידאו (video transcoding) ואימון של למידת מכונה (machine learning training).
תכנון קיבולת לפי צפיפות סוכנים ולא לפי כמותם
המימד הראשון בפריסת סוכני בינה מלאכותית הוא תכנון הקיבולת. אינטל ממליצה לתכנן את משאבי המחשוב לפי צפיפות הסוכנים (הנמדדת במספר סוכנים לכל vCPU) ולא לפי כמות הסוכנים הכוללת. צפיפות הסוכנים היא האות המוביל לזיהוי רוויה של המערכת. לדוגמה, 10 סוכנים הרצים על מערכת בעלת 8 ליבות מעבד וירטואליות (vCPUs) ו-20 סוכנים הרצים על מערכת בעלת 16 ליבות מעבד וירטואליות יתנהגו בצורה דומה מאוד, מכיוון שהצפיפות שלהם זהה. גישה זו מעניקה לאדריכלי מערכות דרך ניידת ופשוטה להשוות קיבולת בין גדלי מופעים (instance sizes) ודורות שונים של מעבדים. הצפיפות הנכונה תלויה במטרה העסקית של הארגון. עוזרים אישיים אינטראקטיביים (interactive copilots ו-user-facing assistants) צריכים לפעול בצפיפות נמוכה יותר, מכיוון שזמן התגובה עבור משתמשי הקצה הוא קריטי. לעומת זאת, עומסי עבודה של עיבוד אצווה (batch workloads), כמו תהליכי עבודה של מחלקות טכנולוגיית מידע (IT workflows), יכולים לעיתים קרובות לפעול בצפיפות גבוהה יותר. אבחנה זו מאפשרת לצוותים לכוונן את ציי הסוכנים בהתאם ליעדי רמת השירות (service-level objectives) ועלות הבעלות הכוללת (TCO).
ניטור ביצועים ודפוסים מתפרצים של עבודה
המימד השני עוסק בצורך בשיטות תצפיתיות וניטור חדשות. מדד ממוצע ניצול המעבד (average CPU utilization) הוא אות חלש ובלתי מספק לניטור ביצועים של סוכני בינה מלאכותית. הסיבה לכך היא שסוכנים נוטים להפגין דפוס עבודה "מתפרץ" (bursty): הם נעים לסירוגין בין המתנה ארוכה יחסית לתגובת המודל לבין ביצוע פרצים קצרים של עבודה תובענית הדורשת כוח מחשוב רב. בשל דפוס זה, ניצול המעבד הממוצע עשוי להיראות תקין ומקובל לחלוטין, גם כאשר אותם פרצי עבודה יוצרים תורים ארוכים ומאטים את חוויית המשתמש. על כן, המדד המוביל והנכון יותר לניטור הוא זמני השהות והתגובה של המשימות באחוזון ה-95 (P95 task latency). מדד זה מראה מתי תהליכי העבודה מתחילים להמתין בתור, עוד לפני שמשך הזמן הממוצע של המשימות מראה הידרדרות משמעותית. מודל הפעלה מעשי הוא להגדיר התראות קודם כל על זמני שהות של P95, ולאחר מכן לאמת את קיומה של הבעיה על ידי בחינת משך הזמן הכולל של המשימות לאורך זמן.
אסטרטגיית גידול: העדפת פריסה לרוחב
המימד השלישי הוא העדפת פריסה לרוחב (scale-out) כברירת מחדל בעת הרחבת המערכת, במקום פריסה לגובה (scale-up). פריסה לרוחב משמעותה הוספת מערכות ושרתים נוספים כדי להגדיל את קיבולת הסוכנים הכוללת. לעומת זאת, פריסה לגובה משמעותה הוספת ליבות מעבד או זיכרון למערכת בודדת כדי להתמודד עם פרצי מחשוב כבדים יותר של סוכנים ספציפיים. נתוני הבדיקות של אינטל הראו כי פריסה לרוחב היא בדרך כלל ברירת המחדל הטובה והמועדפת יותר. הדבר תואם את העובדה שסוכנים הם בדרך כלל עצמאיים למחצה (semi-independent) ומציגים פרצי עבודה צנועים יחסית לכל סוכן בודד. פריסה לרוחב משפרת את הביצועים הכוללים, תומכת בזמינות גבוהה (high availability), לרוב מפחיתה עלויות, ומקילה על שמירת היחס הרצוי של מספר סוכנים לכל vCPU ככל שהפלטפורמה גדלה. עם זאת, יש לבצע פריסה לגובה במקרים ספציפיים שבהם הסוכנים דורשים מחשוב מקבילי כבד יותר, כאשר מצב משותף (shared state) מגביל את היכולת לחלוקה למחיצות (partitioning), כאשר יש חשיבות למיקום הזיכרון (memory locality), או כאשר קיימות מגבלות רישוי (licensing constraints).
השלכות עסקיות ויישום מעשי בארגון
היכן סוכני בינה מלאכותית ייצרו ערך עסקי ראשון עבור הארגון? לפי ממצאי הניסויים, הארגונים שמשיגים תוצאות ברמת ייצור (production-grade results) הם אלו שעוטפים בשכבת אוטומציה תהליכי עבודה שכבר יש להם חוקים מוגדרים מראש ורמות שירות הניתנות למדידה. דוגמאות לכך כוללות יצירת קוד (code creation), חוות בדיקות נסיגה (regression test farms), ניתוב וסיווג פניות תמיכה וכרטיסים (ticket triaging), ניתוח שוק (market analysis) וביקורת אבטחה (security review). הדמות הארגונית האידיאלית להובלת פרויקטים של סוכני בינה מלאכותית אינה המשתמש הניסיוני שמחפש חידושים טכנולוגיים לשמם, אלא המנהל האחראי שחייב לשפר את זמני המחזור והפרודוקטיביות, להגן על איכות השירות, לאכוף מדיניות ארגונית ולשנות את קנה המידה של האימוץ תוך שמירה על מסגרת התקציב והעלויות. הערך האמיתי של סוכני בינה מלאכותית נובע מסיוע לארגונים להשלים עבודה ממשית בין צוותים, מערכות, נתונים ותהליכים שונים. עבור ארגונים, בעלי העניין אינם מחפשים רק ביצועי מודל טובים יותר, אלא יצירת סביבה אמינה שבה סוכני בינה מלאכותית יכולים לתמוך בתהליכי עבודה עסקיים, לשפר פרודוקטיביות, לפעול תחת דרישות ממשל תאגידי, ולגדול ככל שקצב האימוץ מתרחב. הצלחה מעשית בפריסת סוכנים תלויה בבניית הבסיס הנכון שיאפשר לספק תוצאות עקביות, לנהל עלויות, לשמור על שליטה ולעבור בביטחון משלבי פיילוט לייצור מלא.