מדדי ביצועים לקידוד סוכני, כמו SWE-bench ו-Terminal-Bench, משמשים לעיתים קרובות להשוואת יכולות הנדסת התוכנה של מודלי חזית – כאשר המקומות הראשונים בלוחות הדירוג נפרדים לעיתים קרובות בפער של אחוזים בודדים בלבד. ציונים אלה נחשבים לעיתים קרובות כמדידות מדויקות של יכולת המודל היחסית, ומשמשים יותר ויותר בבסיס החלטות לגבי אילו מודלים לפרוס. עם זאת, גילינו כי תצורת התשתית לבדה יכולה לייצר הבדלים העולים על פערים אלו. בניסויים פנימיים, הפער בין ההגדרות עתירות המשאבים ביותר לפחותות המשאבים ב-Terminal-Bench 2.0 עמד על 6 נקודות אחוז (p < 0.01).
מדדי ביצועים סטטיים מנקדים את פלט המודל ישירות – סביבת הריצה אינה נלקחת בחשבון בתוצאה. הערכות קידוד סוכני שונות: מודלים מקבלים סביבה מלאה שבה הם כותבים תוכניות, מריצים בדיקות, מתקינים תלויות ומבצעים איטרציות מרובות. סביבת הריצה אינה עוד קונטיינר פסיבי, אלא רכיב אינטגרלי בתהליך פתרון הבעיות. שני סוכנים עם תקציבי משאבים ומגבלות זמן שונים אינם ניגשים לאותו מבחן.
מפתחי הערכות החלו להתחשב בכך. Terminal-Bench 2.0, למשל, מפרטת המלצות למעבד וזיכרון RAM על בסיס משימה-משימה במהדורת 2.0 האחרונה שלה. עם זאת, הגדרת משאבים אינה זהה לאכיפה עקבית שלהם. יתרה מכך, גילינו שמתודולוגיית האכיפה יכולה לשנות את מה שמדד הביצועים מודד בפועל.
איך הגענו לכאן
אנו מריצים את Terminal-Bench 2.0 על גבי אשכול Google Kubernetes Engine. בזמן כיול ההגדרה, שמנו לב שהציונים שלנו אינם תואמים את לוח הדירוג הרשמי של מדד הביצועים, ושיעורי שגיאות התשתית היו גבוהים באופן מפתיע: עד 6% מהמשימות נכשלו עקב שגיאות Pod, שרובן לא היו קשורות ליכולת המודל לפתור את המשימות.
הפער בציונים נבע מאכיפה. מימוש ה-Kubernetes שלנו התייחס למפרטי המשאבים לכל משימה הן כרצפה והן כתקרה קשיחה: לכל קונטיינר הובטחו המשאבים שצוינו, אך הוא הופסק ברגע שחרג מהם. סביבות ריצה של קונטיינרים אוכפות משאבים באמצעות שני פרמטרים נפרדים: הקצאה מובטחת – המשאבים השמורים מראש – ומגבלה קשיחה שבגינה הקונטיינר מופסק. כאשר אלה מוגדרים לאותו ערך, אין מרווח לנסיקות חולפות: תנודת זיכרון רגעית יכולה לגרום להריגת קונטיינר עקב חוסר זיכרון (OOM-kill) שהיה מצליח אחרת. כדי להתמודד עם זאת, לוח הדירוג של Terminal-Bench משתמש בספק sandboxing אחר, שהמימוש שלו גמיש יותר, ומאפשר הקצאת יתר זמנית מבלי לסיים את הקונטיינר, כדי להעדיף יציבות תשתיתית.
ממצא זה העלה שאלה גדולה יותר: עד כמה תצורת המשאבים משפיעה על ציוני ההערכה?
כדי לכמת את השפעת התשתית, הרצנו את Terminal-Bench 2.0 על פני שש תצורות משאבים שונות, החל מאכיפה קפדנית של מפרטי המשימה (1x), שבהם המשאבים שימשו גם כרצפה וגם כתקרה, ועד לתצורה בלתי מוגבלת לחלוטין. כל השאר נשאר קבוע: אותו מודל Claude, אותו מנגנון בדיקה, ואותו סט משימות.
בניסויים שלנו, שיעורי ההצלחה עלו עם מרווח המשאבים. זה נבע בעיקר מירידה מונוטונית בשיעורי שגיאות התשתית בכל שלב, מ-5.8% באכיפה קפדנית ועד ל-0.5% כשהמשאבים היו בלתי מוגבלים. הירידה בין אכיפה קפדנית למרווח של פי 3 (5.8% ל-2.1%) הייתה מובהקת סטטיסטית ברמת p < 0.001. עם יותר מרווח, פחות קונטיינרים הופסקו עקב חריגה מהקצאה.
מ-1x ועד 3x, ציוני ההצלחה נעים בתוך מרווחי הרעש (p=0.40). רוב המשימות שקרסו ב-1x היו נכשלות בכל מקרה – וזה משהו שצפינו בנתונים. הסוכן חוקר, נתקל בקיר משאבים, ומושהה, אך הוא מעולם לא היה במסלול לפתרון נכון.
החל מסביבות 3x, מגמה זו משתנה: שיעורי ההצלחה מטפסים מהר יותר מאשר שגיאות התשתית יורדות.
בין 3x למצב בלתי מוגבל, שגיאות התשתית יורדות ב-1.6 נקודות אחוז נוספות, בעוד שההצלחה קופצת בכמעט 4 נקודות אחוז. המשאבים הנוספים מאפשרים לסוכן לנסות גישות שעובדות רק עם הקצאות נדיבות, כגון משיכת תלויות גדולות, הפעלת תהליכי משנה יקרים, והרצת חבילות בדיקה עתירות זיכרון. במשאבים בלתי מוגבלים, השיפור הכולל לעומת 1x עומד על 6+ נקודות אחוז (p < 0.01). במקרים מסוימים, משימות כמו rstan-to-pystan ו-compile-compcert משפרות משמעותית את שיעורי ההצלחה שלהן כשהן מקבלות מרווח זיכרון.
איך זה משפיע על המדידה
עד לסביבות פי 3 ממפרטי Terminal-Bench, המשאבים הנוספים מתקנים בעיות אמינות תשתיתיות, כלומר נסיקות משאבים חולפות. ספק ה-sandboxing המשמש את מתחזקי Terminal-Bench עושה זאת באופן מרומז מאחורי הקלעים; ההערכה הופכת יציבה יותר מבלי להיות קלה יותר.
מעל לסימן ה-3x, לעומת זאת, משאבים נוספים מתחילים לעזור באופן פעיל לסוכן לפתור בעיות שלא הצליח לפתור קודם לכן, מה שמראה שמגבלות יכולות למעשה לשנות את מה שההערכה מודדת. מגבלות הדוקות מתגמלות ללא כוונה אסטרטגיות יעילות מאוד, בעוד שמגבלות נדיבות סלחניות יותר ומתגמלות סוכנים שיכולים לנצל טוב יותר את כל המשאבים הזמינים.
סוכן שכותב קוד רזה ויעיל במהירות רבה יצליח תחת אילוצים הדוקים. סוכן שפורץ פתרונות בכוח גס עם כלים כבדים יצליח תחת אילוצים נדיבים. שניהם דברים לגיטימיים לבדוק, אך קיבוץ שלהם לציון יחיד מבלי לציין את תצורת המשאבים מקשה על פרשנות ההבדלים – ועל יכולת ההכללה לעולם האמיתי.
במשימה bn-fit-modify, משימת Terminal-Bench הדורשת התאמת רשתות בייסיאניות, הצעד הראשון של חלק מהמודלים הוא להתקין את מחסנית מדעי הנתונים הסטנדרטית של Python: pandas, networkx, scikit-learn, וכל שרשרת הכלים שלהם. תחת מגבלות נדיבות, זה עובד. תחת מגבלות הדוקות, ה-Pod נגמר לו הזיכרון במהלך ההתקנה, עוד לפני שהסוכן כותב שורת קוד פתרון אחת. קיימת אסטרטגיה רזה יותר (יישום המתמטיקה מאפס באמצעות הספרייה הסטנדרטית בלבד), וחלק מהמודלים אכן נוקטים בה כברירת מחדל. אחרים לא. למודלים שונים יש גישות ברירת מחדל שונות, ותצורת המשאבים קובעת אילו מהגישות הללו מצליחות. שכפלנו את הממצא המרכזי על פני מודלים שונים של Anthropic. כיוון ההשפעה היה עקבי, בעוד שהעוצמה השתנתה. אותן מגמות נראות נכונות גם במודלים שאינם Claude, אך לא בחנו אותם בקפדנות.
בדקנו גם אם דפוס זה תקף להערכות מחוץ ל-Terminal-Bench על ידי ביצוע ניסוי הצלבה ב-SWE-bench. שינינו את סך זיכרון ה-RAM הזמין עד פי 5 מהבסיס על פני 227 בעיות עם 10 דגימות לכל אחת. אותה השפעה נשמרה, אם כי העוצמה הייתה קטנה יותר: הציונים שוב עלו באופן מונוטוני עם ה-RAM, אך היו גבוהים רק ב-1.54 נקודות אחוז ב-5x לעומת 1x. משימות SWE-bench פחות עתירות משאבים, ולכן צפויה השפעה קטנה יותר, אך זה מראה שהקצאת משאבים אינה ניטרלית גם שם.
מקורות שונות נוספים
הקצאת משאבים אינה המשתנה הנסתר היחיד. בתצורות מסוימות, גם מגבלות זמן מתחילות לשחק תפקיד.
באופן עקרוני, כל אלמנט בהגדרת ההערכה יכול להשפיע על הציון הסופי, מבריאות האשכול ועד למפרטי החומרה, מרמת ההקבלה ועד לרוחב פס היציאה. הערכות סוכני AI הן בדיקות מערכת מקצה לקצה מעצם מהותן, וכל רכיב במערכת זו יכול לשמש כמשתנה מתערב. צפינו באופן אנקדוטי, למשל, ששיעורי המעבר משתנים לפי שעות היום, ככל הנראה מכיוון ששיהוי ה-API משתנה בהתאם לדפוסי תעבורה ותקלות. לא כימתנו באופן רשמי השפעה זו, אך היא ממחישה נקודה רחבה יותר: הגבול בין 'יכולת המודל' ל'התנהגות התשתית' מטושטש יותר ממה שציון מדד ביצועים יחיד מרמז. ספק מודל יכול להגן על תשתית ההערכה שלו מפני זה על ידי הקצאת חומרה ייעודית, אך מעריכים חיצוניים אינם יכולים לעשות זאת בקלות.
מדדי ביצועים ציבוריים נועדו בדרך כלל למדוד יכולות מודל טהורות, אך בפועל הם מסתכנים בבלבולן עם מוזרויות תשתיתיות. לעיתים הדבר עשוי להיות רצוי, מכיוון שהוא מאפשר בדיקת קצה-לקצה של הערימה כולה, אך לרוב זה לא המצב. עבור הערכות קידוד שמיועדות לשיתוף פומבי, הרצה בזמנים מרובים ובימים מרובים תעזור לממוצע את הרעש.
מה אנו ממליצים
התרחיש האידיאלי הוא להריץ כל הערכה תחת תנאי חומרה זהים לחלוטין – הן התשתית המריצה את ההערכה והן ערימת ההסקה – שכן הדבר יבטיח יכולת שחזור מושלמת באופן גורף. עם זאת, הדבר לא תמיד יהיה מעשי.
בהתחשב באופן שבו סביבות ריצה של קונטיינרים אוכפות משאבים בפועל – באמצעות הקצאה מובטחת וסף הפסקה קשיח נפרד – אנו ממליצים שהערכות יפרטו את שני הפרמטרים לכל משימה, ולא ערך יחיד וקבוע. מפרט מדויק יחיד מגדיר את ההקצאה המובטחת שווה לסף ההפסקה, ומשאיר אפס מרווח: נסיקות הזיכרון החולפות שתיעדנו ב-1x מספיקות כדי לערער את יציבות ההערכה. הפרדה בין שני הפרמטרים מאפשרת לתת לקונטיינרים מספיק מרווח נשימה כדי למנוע הפסקות OOM שגויות, תוך כדי אכיפה של תקרה קשיחה המונעת ניפוח ציונים.
הטווח ביניהם צריך להיות מכויל כך שהציונים ברצפה ובתקרה ייפלו בתוך מרווח הרעש זה מזה. לדוגמה, ב-Terminal-Bench 2.0, תקרה של פי 3 מעל מפרטי המשימה קיצצה את שיעורי שגיאות התשתית בכשני שלישים (מ-5.8% ל-2.1%, p < 0.001) תוך שמירה על שיפור ציון מתון ובהחלט בתוך הרעש (p = 0.40). זוהי פשרה סבירה: המשתנה המתערב של התשתית מנוטרל ברובו מבלי להסיר לחץ משאבים משמעותי. המכפיל המדויק ישתנה לפי מדד ביצועים והתפלגות משימות, ולכן צריך להיות מדווח, אך עקרון הכיול האמפירי הוא כללי.
למה זה חשוב לנו
לממצאים אלו יש השלכות מעשיות מעבר לתשתית ההערכה. ציוני מדדי ביצועים משמשים יותר ויותר כקלט לקבלת החלטות, אך תשומת הלב המוגברת (וההסתמכות) לא תמיד לוותה בקפדנות מקבילה באופן שבו הם מורצים או מדווחים. כיום, יתרון של 2 נקודות בלוח דירוג עשוי לשקף הבדל יכולות אמיתי, או שהוא עשוי לשקף שהערכה אחת הורצה על חומרה חזקה יותר, או אפילו בזמן מוצלח יותר ביום, או שניהם יחד. ללא תצורות הגדרה מפורסמות (או מתוקננות), קשה לדעת מבחוץ, אלא אם כן גורמים מעוניינים עושים מאמץ נוסף לשחזר תוצאות אובייקטיביות בתנאים זהים.
עבור מעבדות כמו Anthropic, המשמעות היא שתצורת משאבים להערכות סוכני AI צריכה להיחשב כמשתנה ניסיוני ממדרגה ראשונה, מתועדת ונשלטת באותה קפדנות כמו פורמט פרומפט או טמפרטורת דגימה. עבור מתחזקי מדדי ביצועים, פרסום מפרטי משאבים מומלצים (כפי ש-Terminal-Bench 2.0 עושה) יכול לעזור רבות, בעוד שציון מתודולוגיית האכיפה יסגור את הפער שזיהינו. ולכל מי שצורך תוצאות מדדי ביצועים, התובנה המרכזית היא שהבדלי ציונים קטנים בהערכות סוכני AI טומנים בחובם יותר אי-ודאות מאשר הדיוק של המספרים המדווחים מרמז – במיוחד מכיוון שחלק מהמשתנים המתערבים פשוט קשים מדי לשליטה.
עד שמתודולוגיית המשאבים תתוקנן, הנתונים שלנו מצביעים על כך שהבדלי דירוג בלוחות דירוג הנמוכים מ-3 נקודות אחוז ראויים לסקפטיות עד שתצורת ההערכה תתועד ותותאם. הפיזור שנצפה על פני הטווח המתון של תצורות המשאבים ב-Terminal-Bench הוא קצת פחות מ-2 נקודות אחוז. רווחי סמך בינומיים נאיביים כבר מכסים 1-2 נקודות אחוז; המשתנים המתערבים של התשתית שאנו מתעדים כאן מתווספים על כך, ולא נמצאים בתוכו. בקיצוניות של טווח ההקצאה, הפיזור מגיע ל-6.
יתרון של כמה נקודות עשוי לאותת על פער יכולות אמיתי – או שזו פשוט מכונה וירטואלית (VM) גדולה יותר.
תודות
נכתב על ידי ג'יאן סגאטו (Gian Segato). תודה מיוחדת לניקולס קרליני (Nicholas Carlini), ג'רמי הדפילד (Jeremy Hadfield), מייק מריל (Mike Merrill) ואלכס שו (Alex Shaw) על תרומותיהם. עבודה זו משקפת את המאמצים המשותפים של מספר צוותים העובדים על הערכות לסוכני קידוד. מועמדים המעוניינים לתרום מוזמנים להגיש מועמדות ב-anthropic.com/careers.
