SWE-bench (benchmark) (HE)

From Systems analysis Wiki
Jump to navigation Jump to search

SWE-bench — הוא benchmark נרחב (אוסף משימות בדיקה) להערכת יכולות מודלי שפה גדולים (LLM) בתחום פיתוח תוכנה אוטומטי ואיתור שגיאות[1]. הוא פותח על ידי קבוצת חוקרים מאוניברסיטת פרינסטון וארגונים נוספים והוצג בכנס ICLR 2024[2]. SWE-bench נבדל מ-benchmark-ים מסורתיים של קוד בשימוש במשימות אמיתיות מתרגול הפיתוח: אוסף הבדיקות כולל 2294 משימות המבוססות על בעיות (issues) סגורות ותיקונים מקבילים (pull request) מ-12 מאגרי Python פופולריים בקוד פתוח ב-GitHub[1][3]. כל משימה מכילה תיאור בעיה (issue) ומספקת למודל גישה לקוד המקור של הפרויקט הרלוונטי; מטרת המודל היא לייצר שינויים מינימליים ב-codebase (patch) שיפתרו את הבעיה המצוינת[1][3].

מתודולוגיה ומאפייני הערכה

SWE-bench מדמה תהליך פיתוח תוכנה אמיתי. לכל משימה מוצג למודל טקסט ה-GitHub issue המקורי (תיאור הבעיה) ו-snapshot של קוד המאגר בגרסה שלפני ביצוע התיקון[4]. על המודל (או על ה-agent המבוסס על המודל) לנתח את קוד המקור, להבין את מהות השגיאה או השינוי הנדרש ולבצע עריכות בקבצי הקוד המתאימים כדי לפתור את הבעיה[4][5]. אימות הפתרון הוא אוטומטי: לכל משימה מצורפים בדיקות יחידה אמיתיות מה-pull request שסגר את הבעיה. ביניהן ישנן גם בדיקות "כישלון-להצלחה" (fail-to-pass, שאינן עוברות על הקוד המקורי אך צריכות לעבור לאחר החלת התיקון הנכון), וגם בדיקות רגרסיה (pass-to-pass, שעוברות מלכתחילה וצריכות להמשיך לעבור לאחר ביצוע השינויים)[3]. ה-patch שהמודל הציע מוחל על הקוד, ולאחר מכן מופעלות הבדיקות המתאימות: אם כל בדיקות ה-fail-to-pass מתחילות לעבור ובדיקות ה-pass-to-pass לא נפגעות — המשימה נחשבת כפתורה כראוי[3]. גישה זו להערכה מאפשרת לבדוק לא רק את יכולת המודל לייצר קוד תקין מבחינה תחבירית, אלא גם את יכולתו לפתור ממש את הבעיה המוצבת מבלי לפגוע בפונקציונליות הקיימת. בנוסף, על המודל לפעול עם context נרחב (מאגר קוד שלם), להבין את הקשרים בין הרכיבים ולתאם שינויים במספר קבצים בו-זמנית[1] — כל אלה מורכבים בהרבה ממשימות טיפוסיות של כתיבת פונקציה לפי תיאור.

בהערכות SWE-bench לרוב משתתפות לא רק ה-LLM עצמם, אלא מערכות אגנטיות המעטפות את המודל בכלים עזר (למשל, לניווט בקבצים, הרצת קוד, שימוש ב-debugger וכד')[4][6]. מערכת כזו מחקה מחזור פיתוח אמיתי: המודל יכול לעיין ברצף בקבצים, להריץ בדיקות או סקריפטים ולשפר את הפתרון שלב אחר שלב עד שיגיע לתוצאה מוצלחת[4]. יש לציין כי יעילות פתרון משימות SWE-bench תלויה במידה רבה באיכות ה"scaffolding" הזה (תשתית ה-agent): אותם מודלי בסיס עשויים להציג תוצאות שונות בהתאם לאופן שבו מאורגן הממשק עם המאגר והכלים[4][7]. לפיכך, SWE-bench משמש כמדד ליכולות של המודל ביחד עם אסטרטגיית פתרון הבעיות שלו, ומקרב את ההערכה לתנאי העבודה האמיתיים של מפתח AI אוטונומי[4][7].

גרסאות אוסף המשימות

מחברי SWE-bench והקהילה הציגו לאחר מכן מספר אוספים נגזרים למטרות הערכה שונות:

  • SWE-bench Lite — גרסה קלילה של ה-benchmark הכוללת ~300 משימות[8], שנבחרו כדי להפחית את המורכבות ואת עלויות החישוב לבדיקת מודלים. אוסף-המשנה הזה נוצר לצורך ניסוי מהיר עם מודלים ואינו כולל את האימותים הממושכים ביותר, תוך שמירה על ייצוגיות של הבעיות המרכזיות[7]. למעשה, Lite מכיל משימות תיקון שגיאות פשוטות וקצרות יותר, ותוצאות המודלים על Lite גבוהות בדרך כלל מאלו שעל האוסף המלא, עקב הוצאת המקרים המורכבים ביותר[7].
  • SWE-bench Verified — אוסף-משנה מסונן על ידי בדיקה ידנית, שהוצג באוגוסט 2024 בשיתוף OpenAI[7]. החוקרים גייסו 93 מפתחים מקצועיים לניתוח כל משימה מה-benchmark המקורי והדירו מקרים שבהם תיאור הבעיה המקורי עמום מדי או שהתנהגות הנדרשת על ידי הבדיקות אינה נובעת בבירור מתנאי המשימה[7]. בנוסף הוסרו משימות שבפועל אי-אפשר לפתור בשל בעיות בסביבה או בדיקות שגויות[7]. כתוצאה מכך נוצר אוסף של 500 משימות שניתן לפתור בוודאות ומנוסחות כראוי[7]. SWE-bench Verified נועד לספק הערכה אמינה יותר של יכולות המודלים, על ידי ביטול מקרים שבהם אפילו פתרון נכון נדחה בגלל בדיקות או משימות לא הולמות[7]. אוסף זה החליף את מדגמי הבדיקה המקוריים של SWE-bench (המלא ו-Lite) כנקודת ייחוס עיקרית להשוואת מודלים[7]. בנוסף, יחד עם Verified פורסמו הערכות קושי של משימות (למשל, הוגדרו משימות "קלות" שאדם פותר בפחות מ-15 דקות, ו"קשות" הדורשות יותר משעה)[7], וכן שוחרר מסגרת כלים חדשה מבוססת Docker לריצת בדיקות יציבה ובת-שחזור יותר[7].
  • SWE-bench Multimodal — הרחבה של ה-benchmark שהוצגה בינואר 2025, הכוללת משימות שבהן תיאור הבעיה מכיל לא רק טקסט אלא גם אלמנטים חזותיים (למשל, תמונות של ממשק, צילומי מסך של שגיאות וכד')[8]. אוסף זה (517 משימות[8]) בוחן את יכולת המודלים וה-agents להבין ולהשתמש במידע חזותי בעת פתרון משימות תכנות. ההערכה על האוסף המולטימודלי מאורגנת באופן דומה, אך דורשת מהמודל יכולות multi-modal (למשל, זיהוי טקסט בתמונות). חלק הבדיקה של SWE-bench Multimodal נותר סגור (נסתר) כדי למנוע התאמת פתרונות לתשובות ידועות; מפתחים יכולים לשלוח פתרונות ללוח תוצאות מרוחק להערכת מודליהם על משימות אלה[2].

מעבר לוואריאציות העיקריות הללו, סביב SWE-bench נוצרה אקוסיסטם של כלים: SWE-agent — "agent" פותר בקוד פתוח המציג תוצאות מתקדמות על משימות ה-benchmark[2]; SWE-smith — framework לאימון מודלי מפתחים משלך; SWE-REX — כלי לחילוץ ועיבוד מידע מורחב ממאגרים ועוד. פרויקטים אלה מכוונים להקל על שחזור תוצאות ולקדם מחקר בתחום מערכות תכנות אוטונומיות.

תוצאות והתקדמות מודלים

בהופעתו הראשונה, SWE-bench חשף פער משמעותי בין ה-LLM המודרניים לבין כישורי מתכנתים מנוסים. המחברים דיווחו כי אפילו המודלים החזקים ביותר של תחילת 2023 הצליחו לפתור רק אחוזים בודדים מהמשימות: לדוגמה, המודל Claude 2 של חברת Anthropic פתר בהצלחה פחות מ-2% מהמשימות באוסף המלא[1]. המודל שאומן במיוחד על ידי מחברי ה-benchmark (מבוסס LLaMA, שנקרא SWE-Llama) ומודלים קנייניים כגון GPT-4 הצליחו לפתור בעיקר רק את השגיאות הפשוטות ביותר[1]. מדדים נמוכים ראשוניים אלה הדגישו את מורכבות SWE-bench ושימשו כתמריץ לפיתוח גישות חדשות.

במהלך 2024, עם הופעת מודלים מתקדמים יותר ותכניות אגנטיות, התוצאות השתפרו משמעותית. חוקרים מ-Princeton הציגו את מערכת SWE-agent, המשלבת GPT-4 עם חיפוש בקוד, תכנון וכלים נוספים; היא השיגה כ-12.5% משימות פתורות באוסף המלא, ומינה אמת מידה חדשה למודלים אקדמיים[5]. עד אמצע 2024, בלוח התוצאות הרשמי של SWE-bench הגיעו הפתרונות הטובים ביותר (כולל קנייניים) לכ-20% פתרונות מוצלחים ב-benchmark המלא ועד 43% באוסף Lite המופשט[7]. עלייה זו קשורה לשיפור המודלים (למשל, הופעת GPT-4, Claude 2 ו-3) ובמיוחד לפיתוח ה-"scaffolding" — אסטרטגיות חיצוניות המאפשרות למודל לפרק משימה לשלבים ביעילות, לקרוא תיעוד, להריץ סשנים של debugging וכד'[7].

לאחר הכנסת אוסף Verified בסוף 2024 (מנוקה ממשימות שגויות), הביצועים הנמדדים עלו עוד יותר. המודל GPT-4 (הגרסה GPT-4o) הציג מיד כ-33% פתרונות מוצלחים על Verified לעומת ~16% קודם לכן על האוסף המקורי[7]. ה-frameworks האגנטיים הפתוחים הטובים ביותר (למשל, Agentless) הכפילו את תוצאתם מ-~16% ל-32% על Verified[7]. זה אישר את ההשערה שה-benchmark המקורי הוריד במקצת את המדדים בשל קיום מקרים שלא ניתן לפתור[7]. יחד עם זאת, שיפור התוצאות על Verified לעומת Lite אינו כה דרמטי (המודלים הטובים ביותר כבר הגיעו ל-~43% על Lite), וזה הגיוני: Lite בחר מלכתחילה דוגמאות קלות יותר, ואילו Verified הסיר את אלה שלא ניתן לבצע אך השאיר משימות קשות[7]. חשוב לציין כי עלייה במדדים במעבר ל-Verified התרחשה בכל קטגוריות הקושי של המשימות, ולא רק עקב הסרת הקשות ביותר — כלומר, הסינון פינה מהאוסף גם מקרים בלתי-ניתנים לביצוע באופן סמוי בין המשימות הקלות יחסית[7].

נכון לתחילת 2025, מערכות ה-AI המובילות מציגות כבר יעילות קרובה לזו האנושית על אוסף המשימות המאומת, אם כי תקרת 100% עדיין רחוקה. בינואר 2025 דיווחה חברת Anthropic כי מודלה החדש Claude 3.5 Sonnet בשיתוף עם agent משופר פתר 49% ממשימות SWE-bench Verified[4], ויצא זמנית למקום הראשון. חברות טכנולוגיה גדולות וצוותים עצמאיים גם הם משתתפים באופן פעיל בתחרויות לא-רשמיות על ה-benchmark הזה. כך, צוות CodeStory פיתח גישה רב-מודלית עם ניסוי אפשרויות ("Midwit Agent"), שהשיגה שיא של 62.2% משימות פתורות על Verified (נתונים מתחילת 2025)[5][9]. צוין כי לשם כך נדרש הגדלה משמעותית של הוצאות משאבי חישוב בשלב ה-inference של המודל (מה שמכונה inference time scaling), על ידי הפעלת ניסיונות פתרון רבים ובחירת התוצאה הטובה ביותר[5]. מצידה, בחומרים של OpenAI הוזכרה מערכת ניסיונית GPT-03, שלפי הדיווח הצליחה בהגדלת חישובים מספקת לעבור את סף 70% על Verified (נתונים לא-רשמיים)[5]. אולם אימות עצמאי לתוצאות אלה אינו קיים, ומדד גבוה כזה נותר יותר אבן-דרך למחקר עתידי מאשר רמה שהושגה.

לפי מחקר של Microsoft Research (2025), אפילו המודלים החדישים ביותר כשהם מצוידים בכלי debugging עדיין אינם עוברים את רף 50% של תיקוני bug מוצלחים מ-SWE-bench Lite[6]. בניסוי זה הטוב ביותר היה Claude 3.7 Sonnet עם ~48.4% משימות פתורות, בעוד שהמערכת מבוססת GPT-4 (OpenAI 01) פתרה כ-30%, והמודל הקל יותר 03-mini — רק 22%[6]. תוצאות אלה מדגישות כי למרות ההתקדמות המהירה, ה-AI המודרני עדיין נופל ממתכנתים מנוסים: עבור אדם פתרון משימות כאלה (בתנאי שמבין את הקוד) אינו מהווה קושי, בעוד שהמודל לעיתים קרובות אינו יודע להשתמש ביעילות בכלי debugging או סובל ממחסור בנתוני אימון המשקפים תהליך רב-שלבי של תיקון שגיאות[6].

מגבלות ופרספקטיבות

SWE-bench הפך לפלטפורמה מתוקננת להערכת agents קוד אינטליגנטיים, אולם מחקרים חשפו גם מספר מגבלותיו. הבעיה העיקרית היא חוסר שלמות הבדיקות: אוסף הבדיקות לכל משימה לקוח מ-pull request ספציפי, וכולל בדרך כלל רק את בדיקות היחידה שהשתנו עם תיקון השגיאה[3]. כפי שהראה ניתוח של קבוצת חוקרים מאוניברסיטת ג'ג'יאנג ואוניברסיטת שטוטגרט (Wang et al. 2025), התעלמות מיתר בדיקות הפרויקט עלולה להסתיר את אי-הנכונות של חלק מהפתרונות[3]. בדיקה חוזרת של פתרונות על אוסף הבדיקות המלא של המאגר חשפה כי בממוצע 7.8% מה-patches המסומנים כמוצלחים ב-SWE-bench, למעשה אינם עוברים בדיקות אחרות בפרויקט[3]. זה מוביל לניפוח המדד "משימות שנפתרו" בכ-4-6 נקודות אחוז[3]. מקרה עדין עוד יותר הוא כאשר ה-patch שנוצר עובר את כל הבדיקות המקוריות, אך אינו שקול לפתרון המפתח ומשנה את התנהגות התוכנה בצורה בלתי-צפויה. בעזרת יצירת test-cases נוספים (מתודולוגיית PatchDiff) גילו החוקרים כי כמעט 30% מהתיקונים שהוצעו על ידי AI מתנהגים אחרת מה-patches הייחוסיים, וכ-11% — שגויים בבירור, אם כי אינם מתגלים על ידי הבדיקות הקיימות[3]. לפיכך, יכולות המודלים האמיתיות עלולות להיות מוערכות יתר על המידה אם מסתמכים רק על מעבר אוסף בדיקות מוגבל. יוצרי SWE-bench מודים בפגיעות זו ומדגישים כי ה-benchmark צריך להתפתח עם הזמן: לשפר כיסוי הבדיקות, להוסיף בדיקות על העדר תופעות לוואי לא רצויות, להרחיב את מגוון סוגי המשימות[7]. פיתוח אמצעי הערכה כאלה הוא חלק חשוב מההכנה להופעת מפתחי AI אוטונומיים וחזקים יותר ויותר, וניסיון SWE-bench מצביע על הצורך ביחס קפדני לאיכות ה-benchmarks[7].

SWE-bench, שהוא בסך הכל אוסף סטטי של משימות, אינו מכסה את כל היבטי התכנות לחלוטין, אך כבר הפך לסטנדרט דה-פקטו לניתוח השוואתי של מודלי קוד[3]. הוא משמש בעבודות מחקריות להדגמת שיטות ואלגוריתמים חדשים, וכן על ידי קבוצות מחקר תעשייתיות להערכת פוטנציאל מערכות המיועדות לאוטומציה של תכנות[3]. הצמיחה המתמדת בתוצאות על SWE-bench בשנים 2023-2025 מדגימה בבירור את השיפור המהיר ביכולות ה-LLM בפתרון משימות פיתוח מעשיות. יחד עם זאת, הוא משמש כברומטר של מורכבות: אפילו כשמתקרבים ל-50-60% משימות פתורות, המודלים עדיין רחוקים מלהחליף לגמרי אדם, בעיקר בתנאים של מידע מוגבל וצורך בהבנה עדינה של דרישות[4][7]. ובכל זאת, ההתקדמות לא עוצרת — הודות ליוזמות כגון SWE-bench, הקהילה רואה בבירור את יעדיה ומגבלותיה, וממשיכה בדרך ליצירת מפתח AI מלא, המסוגל להבין ולתקן קוד תוכנה באופן אוטונומי ברמת מומחה אנושי[4][7].

קישורים

  • SWE-bench ב-GitHub
  • לוח התוצאות הרשמי של SWE-bench

ספרות

  • Liang, P. et al. (2022). Holistic Evaluation of Language Models (HELM). arXiv:2211.09110.
  • Chang, Y. et al. (2023). A Survey on Evaluation of Large Language Models. arXiv:2307.03109.
  • Ni, S. et al. (2025). A Survey on Large Language Model Benchmarks. arXiv:2508.15361.
  • Biderman, S. et al. (2024). The Language Model Evaluation Harness (lm-eval): Guidance and Lessons Learned. arXiv:2405.14782.
  • Kiela, D. et al. (2021). Dynabench: Rethinking Benchmarking in NLP. arXiv:2104.14337.
  • Ma, Z. et al. (2021). Dynaboard: An Evaluation‑As‑A‑Service Platform for Holistic Next‑Generation Benchmarking. arXiv:2106.06052.
  • Goel, K. et al. (2021). Robustness Gym: Unifying the NLP Evaluation Landscape. arXiv:2101.04840.
  • Xu, C. et al. (2024). Benchmark Data Contamination of Large Language Models: A Survey. arXiv:2406.04244.
  • Liu, S. et al. (2025). A Comprehensive Survey on Safety Evaluation of LLMs. arXiv:2506.11094.
  • Chiang, W.-L. et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. arXiv:2403.04132.
  • Boubdir, M. et al. (2023). Elo Uncovered: Robustness and Best Practices in Language Model Evaluation. arXiv:2311.17295.
  • Huang, L. et al. (2023). A Survey on Hallucination in Large Language Models. arXiv:2311.05232.

הערות

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 Jimenez, Carlos E. et al. «SWE-bench: Can Language Models Resolve Real-World GitHub Issues?». arXiv. [1]
  2. ↑ 2.0 2.1 2.2 «SWE-bench/SWE-bench». GitHub. [2]
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 Wang, Shuyang et al. «Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study». arXiv. [3]
  4. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 «Claude SWE-Bench Performance». Anthropic. [4]
  5. ↑ 5.0 5.1 5.2 5.3 5.4 Jain, Sulbha. «SWE Benchmark: LLM evaluation in Software Engineering Setting». Medium. [5]
  6. ↑ 6.0 6.1 6.2 6.3 Hatmaker, Taylor. «AI models still struggle to debug software, Microsoft study shows». TechCrunch. [6]
  7. ↑ 7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 «Introducing SWE-bench Verified». OpenAI. [7]
  8. ↑ 8.0 8.1 8.2 «SWE-bench Leaderboard». [8]
  9. ↑ «SOTA on swebench-verified: relearning the bitter lesson». Hacker News (Y Combinator). [9]
Retrieved from "https://systems-analysis.info/int/index.php?title=SWE-bench_(benchmark)_(HE)&oldid=6523"