בדיקות תוכנה לעומסי עבודה של סוכנים: הנחות מסורתיות שנשברות

בטור דעה שפורסם ב-SiliconANGLE, כותב מ. תוהיד (M. Touheed), מומחה צמיחה בחברת Imagine Art, כי רוב המערכות הארגוניות המסורתיות נבנו סביב שלוש הנחות יסוד: משימות מסתיימות במהירות, ביצוע ניסיון חוזר אינו עולה כסף, ואותו קלט תמיד מניב את אותו פלט. עומסי עבודה של סוכני בינה מלאכותית (Agentic workloads) שוברים את כל שלוש הציפיות הללו, וזו הסיבה לכך שפיילוטים שמפגינים ביצועים טובים הופכים לבעיות תפעוליות ברגע שהם פועלים ללא השגחה אנושית. לפי תוהיד, הקושי נובע לעיתים נדירות מהמודל עצמו; במקום זאת, הבעיה נעוצה בתשתית המקיפה ובנוהלי הניהול שמניחים תכונות שעומסי עבודה אלו אינם מחזיקים בהן עוד.

שלושה הבדלים בין עבודת סוכנים לתוכנה מסורתית

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

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

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

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

מדוע סביבות פיילוט מסתירות את הבעיות התפעוליות

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

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

שלושה סיכונים הדורשים תשומת לב

הטור מונה שלושה סיכונים מרכזיים בתפעול סוכנים:

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

2. כשלים שמדווחים על הצלחה: הפגמים היקרים ביותר אינם שגיאות קריסה, אלא תוצאות שנראות תקינות מבחינה מבנית אך שגויות מבחינה מהותית. סוכנים הסתברותיים אינם יכולים לזהות את השגיאות הלוגיות של עצמם, ולכן הם מייצרים פלטים בעלי מבנה נכון המכילים נתונים שגויים. מערכות אוטומטיות במורד הזרם מקבלות ומעבדות אותם מבלי להפעיל התראות, וניטור קונבנציונלי מפספס שגיאות אלו משום ששום דבר לא נכשל טכנית. איכות הפלט של ה-AI חייבת להימדד באמצעות קריטריונים תוכנתיים מוגדרים מראש (כגון בדיקות assertion, כללי מודל-כשופט או מדדי ביצוע סמנטיים) ולא באמצעות הסתמכות על זמן פעילות תקין או יומני שגיאות סטנדרטיים.

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

חמש שאלות שיש להציג לצוותי הפיתוח

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

• מה מגדיר פלט מקובל, והאם הדבר כתוב מראש לפני שהעבודה רצה? אוטומציה דורשת קריטריוני קבלה ברורים וניתנים לשחזור. אם קריטריוני ההצלחה משתנים על סמך דעה אנושית אישית במהלך סקירה, תוכנה אינה יכולה לאמת את הפלט באופן אוטומטי.
• כמה ניסיונות דורשת בדרך כלל יחידה שהושלמה, והאם קיים לכך רף עליון (cap)? לולאת ניסיונות חוזרים בלתי מוגבלת מול תקן עמום היא המקור הנפוץ ביותר להוצאות יתר.
• מה נרשם ומתועד עבור כל הרצה, והאם הצוות יוכל לספק את התיעוד הזה לפי דרישה בעוד שישה חודשים? נתוני המשימה צריכים לכלול את מטען הקלט המדויק, גרסת הפרומפט והמודל, חותמת זמן, זמני השהיית ביצוע, ספירת ניסיונות חוזרים, עלות טוקנים ואת תוצר הפלט הסופי.
• מי מאשר סוגים שונים של פלט, בשמו המפורש? הכוונה היא לאדם יחיד ולא לצוות כללי, משום שכאשר משהו יוצא שגוי, זו השאלה הראשונה שתישאל.
• מה קורה כאשר הספק מעדכן את המודל? עדכוני מודל עשויים לשנות בעדינות את עיצוב התגובה, הדיוק או לוגיקת ההסקה. שינויים אלה יכולים לשבור צינורות אוטומטיים במורד הזרם, ולכן יש לבדוק שינויי גרסאות מודל בסביבת staging לפני פריסתם לייצור.

איחוד סביבת העבודה ופערי מיומנויות

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

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