SWE-bench (benchmark) (BG)
SWE-bench — това е мащабен benchmark (набор от тестови задачи) за оценка на възможностите на големите езикови модели (LLM) в областта на автоматизираната разработка и отстраняването на грешки в софтуера[1]. Той е разработен от група изследователи от Принстънския университет и други организации и е представен на конференцията ICLR 2024[2]. SWE-bench се отличава от традиционните кодови benchmark-ове с използването на реални задачи от практиката на разработка: тестовият набор включва 2294 задачи, основани на затворени проблеми (issues) и съответните поправки (pull request) от 12 популярни отворени Python-хранилища в GitHub[1][3]. Всяка задача съдържа описание на проблема (issue) и предоставя на модела достъп до изходния код на съответния проект; целта на модела е да генерира минимални промени в кодовата база (пач), които да отстранят посочения проблем[1][3].
Методика и особености на оценяването
SWE-bench моделира реалния процес на разработка на софтуер. За всяка задача на модела се предоставя текстът на оригиналния GitHub issue (описание на проблема) и снимка на кода на хранилището в версията преди внасянето на поправката[4]. От модела (или от агент, базиран на модела) се изисква да анализира изходния код, да разбере естеството на грешката или на исканата промяна и да внесе корекции в съответните файлове с код, като отстрани проблема[4][5]. Валидирането на решението е автоматизирано: към всяка задача са прикрепени реални модулни тестове от pull request-а, затворил съответния проблем. Сред тях има както тестове „от неуспешен към успешен" (fail-to-pass — тестове, които не преминават върху оригиналния код, но трябва да преминат след прилагане на правилната поправка), така и регресионни тестове (pass-to-pass — тестове, които първоначално преминават и трябва да продължат да преминават след внасянето на промените)[3]. Предложеният от модела пач се прилага към кода, след което се изпълняват съответните тестове: ако всички fail-to-pass тестове започнат да преминават и при това pass-to-pass тестовете не са нарушени, задачата се счита за решена правилно[3]. Този подход към оценяването позволява да се провери не само способността на модела да генерира синтактично коректен код, но и умението му действително да реши поставената задача, без да нарушава съществуващата функционалност. При това моделът трябва да оперира с голям контекст (цяло хранилище с код), да разбира взаимовръзките между компонентите и да координира промени в няколко файла едновременно[1] — всичко това е значително по-сложно от типичните задачи за написване на функция по описание.
В оценките на SWE-bench обикновено участват не просто самите LLM, а агентни системи, които обвиват модела с помощни инструменти (например за навигация по файлове, изпълнение на код, използване на дебъгер и др.)[4][6]. Такава система имитира реалния цикъл на разработка: моделът може последователно да преглежда файлове, да изпълнява тестове или скриптове и постепенно да подобрява решението, докато не постигне успешен резултат[4]. Показателно е, че ефективността при решаването на задачите на SWE-bench до голяма степен зависи от качеството на този „скафолдинг" (инфраструктурата на агента): едни и същи базови модели могат да показват различен резултат в зависимост от това как е организирано взаимодействието с хранилището и инструментите[4][7]. По този начин SWE-bench служи като мярка за възможностите на съвкупността от модел и стратегията му за решаване на задачи, доближавайки оценяването до реалните условия на работа на автономен разработчик-ИИ[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 минути, и „трудни", изискващи >1 час)[7], а също беше пуснат нов инструментален каркас на базата на Docker за по-стабилно и възпроизводимо изпълнение на тестовете[7].
- SWE-bench Multimodal — разширение на benchmark-а, представено през януари 2025 г., включващо задачи, в които описанието на проблема съдържа не само текст, но и визуални елементи (например изображения на интерфейс, скрийншоти на грешки и др.)[8]. Този набор (517 задачи[8]) проверява способността на моделите и агентите да разбират и използват визуална информация при решаването на задачи по програмиране. Оценяването на мултимодалния набор е организирано по подобен начин, но изисква от модела мултимодални възможности (например разпознаване на текст върху изображения). Тестовата част на SWE-bench Multimodal е оставена затворена (скрита) с цел предотвратяване на нагласяне на решения към известни отговори; разработчиците могат да изпращат решения към отдалечен лидерборд за оценка на своите модели по тези задачи[2].
Освен тези основни варианти около SWE-bench се формира екосистема от инструменти: SWE-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) и особено на развитието на „скафолдинга" — външни стратегии, позволяващи на модела ефективно да разбива задачата на стъпки, да чете документация, да стартира сесии за отстраняване на грешки и др.[7].
След въвеждането в края на 2024 г. на набора Verified (очистен от некоректни задачи) измерваната производителност нарасна още повече. Моделът GPT-4 (вариантът GPT-4o) веднага показа около 33% успешни решения на Verified срещу ~16% по-рано на оригиналния набор[7]. Най-добрите отворени framework-агенти (например 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 в комбинация с подобрен агент е решил 49% от задачите на SWE-bench Verified[4], временно заемайки първо място. Големите технологични компании и независимите екипи също активно участват в неофициалните състезания по този benchmark. Така екипът на CodeStory разработи многомоделен подход с преглед на варианти („Midwit Agent"), който достигна рекордни 62,2% решени задачи на Verified (данни към началото на 2025 г.)[5][9]. Отбелязано бе, че за целта се е наложило съществено увеличаване на изчислителните ресурси на етапа на извод на модела (т.нар. inference time scaling) — стартиране на множество опити за решение и избиране на най-добрия резултат[5]. От своя страна, в материалите на OpenAI се споменаваше за експериментална система GPT-03, на която при достатъчно мащабиране на изчисленията уж се е отдало да преодолее прага от 70% на Verified (неофициални данни)[5]. Независима верификация на тези резултати обаче липсва и толкова висок показател остава по-скоро ориентир за бъдещи изследвания, отколкото достигната граница.
Според изследване на Microsoft Research (2025 г.), дори най-новите модели, снабдени с инструменти за отстраняване на грешки, все още не преодоляват прага от 50% успешни поправки на грешки от SWE-bench Lite[6]. В това изпитание най-добър резултат показа Claude 3.7 Sonnet с ~48,4% решени задачи, докато системата на GPT-4 (OpenAI o1) реши около 30%, а по-облекченият модел o3-mini — само 22%[6]. Тези резултати подчертават, че въпреки бързия прогрес, съвременните AI системи все още отстъпват на опитните програмисти: за човек решаването на подобни задачи (при наличие на разбиране на кода) не представлява трудност, докато моделът често не умее ефективно да прилага инструменти за отстраняване на грешки или страда от недостиг на обучаващи данни, отразяващи многостъпковия процес на поправка на грешки[6].
Ограничения и перспективи
SWE-bench се превърна в стандартизирана платформа за оценка на интелигентни кодови агенти, но изследванията разкриха и редица негови ограничения. Основният проблем е непълнотата на тестването: наборът от проверочни тестове за всяка задача се взима от конкретен pull request и обикновено включва само онези юнит-тестове, които са били променени при поправката на грешката[3]. Както показа анализ на група учени от Университета Чжецзян и Щутгартския университет (Wang et al. 2025), игнорирането на останалите тестове на проекта може да прикрие некоректността на някои решения[3]. Повторната проверка на решенията върху пълния набор от тестове на хранилището разкри, че средно 7,8% от пачовете, отбелязани като успешни в SWE-bench, всъщност не преминават други тестове в проекта[3]. Това води до завишаване на метриката „решени задачи" с приблизително 4-6 процентни пункта[3]. Още по-деликатен случай е когато генерираният пач преминава всички оригинални тестове, но при това е неравностоен на решението на разработчика и променя поведението на програмата по различен от очаквания начин. С помощта на генериране на допълнителни тест-случаи (методиката PatchDiff) изследователите установиха, че близо 30% от предложените от AI поправки се държат по различен начин от еталонните пачове, а около 11% са недвусмислено грешни, макар и да не се откриват от съществуващите тестове[3]. Така реалните способности на моделите могат да бъдат надценени, ако се разчита само на преминаването на ограничен набор от тестове. Създателите на SWE-bench признават тази уязвимост и подчертават, че benchmark-ът трябва с течение на времето да еволюира: да се подобрява покритието с тестове, да се добавят проверки за отсъствие на нежелани странични ефекти, да се разширява наборът от типове задачи[7]. Развитието на такива средства за оценка е важна част от подготовката за появата на все по-автономни и мощни AI разработчици, а опитът със SWE-bench показва необходимостта от внимателно отношение към качеството на benchmark-овете[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.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.0 2.1 2.2 «SWE-bench/SWE-bench». GitHub. [2]
- ↑ 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.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 «Claude SWE-Bench Performance». Anthropic. [4]
- ↑ 5.0 5.1 5.2 5.3 5.4 Jain, Sulbha. «SWE Benchmark: LLM evaluation in Software Engineering Setting». Medium. [5]
- ↑ 6.0 6.1 6.2 6.3 Hatmaker, Taylor. «AI models still struggle to debug software, Microsoft study shows». TechCrunch. [6]
- ↑ 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.0 8.1 8.2 «SWE-bench Leaderboard». [8]
- ↑ «SOTA on swebench-verified: relearning the bitter lesson». Hacker News (Y Combinator). [9]