Agentic AI at Scale: ראיון בלעדי עם בנג'מין מייר מחברת NiCE (Cognigy)

במסגרת הנסיעה שלי לסיקור הכנס השנתי של NiCE היה לי את הזכות לראיין את בנג'מין מייר (Benjamin Mayr), לשעבר מייסד-שותף וארכיטקט תוכנה ראשי ב-Cognigy וכיום סגן נשיא וראש תחום ארכיטקטורה ב-NiCE (בעקבות רכישת הענק בסך כמיליארד דולר). נפגשנו לשיחה מרתקת בכנס NiCE World בלונדון כדי להבין איך בונים ומנהלים מערכות Agentic AI בסקייל (Scale) עצום עבור החברות הגדולות והמפוקחות ביותר בעולם, החל ממוסדות פיננסיים ועד חברות תעופה. סקרן אותי לצלול אל מתחת למכסה המנוע של פלטפורמת תפעול סוכנים, ולפענח כיצד מתכננים ארכיטקטורה הנדסית יציבה ומבוזרת שלא קורסת תחת עומסי שיא.

המעטפת שסביב המודל: LLM Gateway, פולינג וניתוב בזמן אמת

כששאלתי את בנג'מין מה התובנה ההנדסית החשובה ביותר שצברה החברה לאורך השנים, הופתעתי לגלות שלתפיסתו המודל עצמו (LLM) אינו הרכיב הקריטי ביותר במערכת. לדבריו, מודלים מתקדמים מציעים יכולות הסקה (Reasoning) מרשימות ביותר, אך אינם מתאימים כשלעצמם לריצה בסביבת שירות לקוחות בזמן אמת בשל שיהוי (Latency) גבוה ועלויות אדירות. מה שבאמת קובע את שרידות המערכת ואמינותה בפרודקשן (Production) הוא המעטפת ההנדסית (Harness) והאורקסטרציה הנבנית סביב המודל.

כדי להתמודד עם אתגרי זמינות (High Availability) ונקודות כשל בודדות (Single Point of Failure), פיתחה NiCE רכיב ייעודי בשם LLM Gateway. רכיב מרכזי זה מיישם אלגוריתם פולינג (Clever Pooling) מתקדם המנהל נקודות קצה של מודלים בפיזור גיאוגרפי נרחב (כדוגמת נקודות קצה בגרמניה, אמסטרדם ושוואדיה). המערכת מודדת ברציפות את ה-Latency של כל שאילתה ומנתבת את ה-Prompt בזמן אמת ל-Endpoint המהיר והזמין ביותר.

נדהמתי לראות כיצד המנגנון מתמודד עם תקלות תפעוליות בזמן אמת: במידה ומפתח באחד הארגונים משנה API Key ב-Azure OpenAI או שנקודת קצה מסוימת מציגה שגיאה, המערכת מזהה זאת מיידית, מבצעת ניסיון חוזר (Retry) ומנתבת את הקריאה באופן שקוף למודל חלופי מתוך ה-Pool המוגדר. בצורה זו מובטחת רציפות תפקודית מוחלטת גם בזמני עומס חריגים.

הפרדת רשויות הנדסית: סביבות Serverless מבודדות ואינטגרציות דטרמיניסטיות

כשצללנו לעומק הארכיטקטורה של הפעלת כלים (Tool Use), סקרן אותי להבין איך הם פותרים את בעיית הריצה של קוד מותאם אישית בסביבות מרובות משתמשים (Multi-tenant). בעוד שחלק מהלקוחות המתקדמים מחברים שרתי Model Context Protocol (MCP), רוב ארגוני ה-Enterprise משתמשים במערכות legacy עם API קיימים שלא תוכננו מראש להזנת מודלי שפה גדולים. אם תגובת JSON משרת ה-CRM מכילה 100 שדות (Key-Value Pairs) ורק 3 מהם נדרשים להמשך השיחה, הזרמת כל המידע ל-LLM תגרום לבזבוז עצום של טוקנים ולעלייה דרסטית בעלויות.

הפתרון של NiCE מבוסס על הפרדה מוחלטת בין השכבה הדטרמיניסטית לבין שכבת ה-AI:

• שכבת האינטגרציה והזרימה: מערכת ויזואלית (Cognigy Flows / Flow Studio) המריצה תהליכים דטרמיניסטיים. המערכת מבצעת קריאות HTTP, מריצה קוד JavaScript ומזקקת את המידע לפני שהוא מועבר למודל השפה.
• סביבת הרצה מבודדת (Cognigy Serverless): ארכיטקטורת Runtime פנימית המבצעת בידוד מלא (Isolation) של הקוד המותאם אישית שנכתב על ידי מהנדסי הלקוח. המערכת מסוגלת להריץ מיליוני פונקציות בדקה בצורה מבודדת ומאובטחת ללא חשש מזליגת מידע בין לקוחות שונים.

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

ניהול FinOps והערכת סוכנים בסקייל: סימולציות אוטונומיות ו-Model Catalog

כששאלתי את בנג'מין על אתגרי העלויות (FinOps) ובקרת האיכות, הוא הציג גישה הנדסית מקיפה המבוססת על בדיקות אוטונומיות מקצה לקצה. המערכת מנטרת באופן שוטף את צריכת הטוקנים ברמת ה-Input, ה-Output וטוקני ההסקה (Reasoning Tokens) עבור כל תור בשיחה.

אחד הכלים המרשימים ביותר שהציג הוא מנוע הסימולציה (Simulator). מכיוון שבלתי אפשרי לבחון ידנית תרחישי קצה בלתי מוגבלים של סוכני AI, פיתחה החברה מנוע סימולציה מבוסס LLM בעצמו. המנוע מקבל הגדרות תרחיש (למשל: "נסה לרכוש את כל כרטיסי הקולנוע הזמינים במערכת" או תרחישי הזרקת הנחיות – Prompt Injection) ומריץ אלפי סימולציות במקביל בתוך כ-3 דקות.

הסימולטור מאפשר לבצע בדיקות עומסים, לבחון עמידות לאיומי סייבר ולהשוות עלויות בין מודלים שונים. בנג'מין הדגים כיצד הרצת 10,000 אינטראקציות על מודל מסוים יכולה להראות עלות ממוצעת של $0.07 לשיחה, אך במידה והסוכן נתקע במצבי קצה, מעבר למודל חזק יותר יעלה את מחיר השיחה ל-$0.09 תוך פתרון מלא של הבעיה. בנוסף, החברה מפעילה קטלוג מודלים פנימי (Model Catalog) שבו מבוצע בנצ'מארק (Benchmark) אוטומטי יומי למודלים חדשים בשוק כדי להתאים את המודל האופטימלי לפי מורכבות המשימה, מספר הכלים (Tools) והאילוצים ההנדסיים של כל תעשייה.

עמידות בעומסי קיצון: מקרה הבוחן של Lufthansa ושמירה על אבטחה

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

בתוך 7 עד 8 דקות, עומס המערכת מזנק מקצב שגרתי של כ-600–700 הודעות בדקה לקצב אדיר של למעלה מ-16,000 הודעות בדקה. המערכת לא רק עונה על שאלות נפוצות (FAQ), אלא מנהלת תהליך שינוי הזמנה (Rebooking) מקצה לקצה: שולפת חלופות משרתי ה-Backend, מציגה אותן באמצעות רכיבים אינטראקטיביים (Adaptive Cards) ומבצעת את הרכישה מחדש באופן אוטונומי.

במישור האבטחה, המערכת מתמודדת עם נסיונות הונאה וגניבת שירותים על ידי שילוב של פילטרי תוכן (Guardrails) ברמת המודל, נתיבי גיבוי דטרמיניסטיים, ניטור בדיעבד (Post-conversation Auditing) של שיחות החורגות מנהלי האבטחה, ומנגנון Mocking המאפשר לדמות נפילה של API בזמן סימולציה כדי לוודא שהסוכן מגיב בצורה בטוחה ומבוקרת.

מבט לעתיד: תקשורת Agent-to-Agent והיעלמות אתרי האינטרנט המסורתיים

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

בעתיד הלא רחוק, המשתמש הקצה לא ייכנס לאתר אינטרנט או יוריד אפליקציה, אלא ינחה את הסוכן האישי שלו (במכשיר הנייד, בבית החכם או ברובוט אנושי) לבצע משימה. הסוכן האישי יפנה במקביל לעשרות סוכנים ארגוניים, יבצע השוואות, ינהל מו"מ ויסגור עסקה. התפתחות זו תוביל למצב שבו נפח התנועה (Load) שארגונים יידרשו לנהל יגדל פי 10 עד פי 100, כאשר רוב הלקוחות הפונים אל הארגון יהיו סוכני AI אוטונומיים.

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

לצפייה בפרק המלא, לחצו כאן.

להאזנה באפל או בפודבין.