SWE-bench (benchmark) (TL)

From Systems analysis Wiki
Jump to navigation Jump to search

SWE-bench — ito ay isang malawak na benchmark (koleksyon ng mga pagsubok na gawain) para sa pagsusuri ng mga kakayahan ng malalaking modelo ng wika (LLM) sa larangan ng awtomatikong pagbuo at pag-aayos ng software[1]. Ito ay binuo ng isang grupo ng mga mananaliksik mula sa Princeton University at iba pang mga organisasyon at ipinakita sa kumperensyang ICLR 2024[2]. Naiiba ang SWE-bench mula sa mga tradisyonal na benchmark ng code sa pamamagitan ng paggamit ng mga tunay na gawain mula sa praktika ng pagbuo: ang test set ay naglalaman ng 2294 na gawain, batay sa mga saradong isyu (issues) at kaukulang mga pag-aayos (pull request) mula sa 12 sikat na bukas na Python-repositoryo sa GitHub[1][3]. Ang bawat gawain ay naglalaman ng paglalarawan ng problema (issue) at nagbibigay sa modelo ng access sa source code ng kaukulang proyekto; ang layunin ng modelo ay bumuo ng pinakamaliit na mga pagbabago sa codebase (patch), na magtatama ng tinukoy na problema[1][3].

Pamamaraan at Mga Katangian ng Pagtatasa

Ang SWE-bench ay nag-imodelo ng tunay na proseso ng pagbuo ng software. Para sa bawat gawain, ipinakita sa modelo ang teksto ng orihinal na GitHub issue (paglalarawan ng problema) at isang snapshot ng code ng repositoryo sa bersyon bago ang pag-aayos[4]. Kailangan ng modelo (o ng ahente batay sa modelo) na suriin ang source code, maunawaan ang kalikasan ng error o ng kinakailangang pagbabago, at gumawa ng mga pagwawasto sa kaukulang mga file ng code, na inaalis ang problema[4][5]. Ang pagpapatunay ng solusyon ay awtomatiko: ang bawat gawain ay nakatali sa mga tunay na unit test mula sa pull request na nagsara ng problemang iyon. Kasama sa mga ito ang parehong «fail-to-pass» na mga pagsubok (na hindi pumapasa sa orihinal na code, ngunit dapat pumasa pagkatapos ng tamang pag-aayos), at regression test (pass-to-pass, na pumapasa sa simula at dapat patuloy na pumasa pagkatapos ng mga pagbabago)[3]. Ang patch na inaalok ng modelo ay inilalapat sa code, pagkatapos ay pinapatakbo ang kaukulang mga pagsubok: kung ang lahat ng fail-to-pass na pagsubok ay nagsisimulang pumasa at hindi nasira ang mga pass-to-pass na pagsubok, ang gawain ay itinuturing na nalutas nang tama[3]. Ang pamamaraang ito ng pagtatasa ay nagbibigay-daan hindi lamang upang suriin ang kakayahan ng modelo na bumuo ng syntactically na tamang code, kundi pati na rin ang kakayahan na tunay na malutas ang naibigay na gawain nang hindi sinisira ang umiiral na functionality. Sa kasong ito, kailangang gamitin ng modelo ang malaking konteksto (buong repositoryo ng code), maunawaan ang mga relasyon sa pagitan ng mga bahagi at i-coordinate ang mga pagbabago sa ilang file nang sabay-sabay[1] — lahat ng ito ay higit na mas kumplikado kaysa sa mga karaniwang gawain ng pagsulat ng function batay sa paglalarawan.

Sa mga pagtatasa ng SWE-bench, kadalasang nakikilahok hindi lamang ang mismong mga LLM, kundi ang mga agentic na sistema, na bumabalot sa modelo ng mga pantulong na kagamitan (halimbawa, para sa pag-navigate sa mga file, pagpapatakbo ng code, paggamit ng debugger, atbp.)[4][6]. Ang ganitong sistema ay ginagaya ang tunay na ikot ng pagbuo: maaaring sunud-sunod na tingnan ng modelo ang mga file, magpatakbo ng mga pagsubok o script at unti-unting pagbutihin ang solusyon hanggang makamit ang matagumpay na resulta[4]. Kapansin-pansin na ang bisa ng paglutas ng mga gawain ng SWE-bench ay malaki ang depende sa kalidad ng «scaffolding» na ito (imprastraktura ng ahente): ang parehong mga base na modelo ay maaaring magpakita ng iba't ibang resulta depende sa kung paano nakaayos ang pakikipag-ugnayan sa repositoryo at mga kagamitan[4][7]. Kaya, ang SWE-bench ay nagsisilbing sukatan ng mga kakayahan ng kombinasyon ng modelo at ng estratehiya nito sa paglutas ng mga gawain, na inilalapit ang pagtatasa sa mga tunay na kondisyon ng trabaho ng isang autonomous na AI developer[4][7].

Mga Variant ng Test Set

Ang mga may-akda ng SWE-bench at ang komunidad ay nagpakita ng ilang derived na set para sa iba't ibang layunin ng pagtatasa:

  • SWE-bench Lite — isang magaang na bersyon ng benchmark, na naglalaman ng ~300 na gawain[8], na pinili upang mabawasan ang kumplikasyon at mga gastos sa pagkalkula para sa pagsubok ng mga modelo. Ang subset na ito ay nilikha para sa mabilis na eksperimento sa mga modelo at inaalis ang mga pinaka-matagal na validasyon, habang pinapanatili ang representatibidad ng mga pangunahing problema[7]. Sa esensya, ang Lite ay naglalaman ng mas simple at mas maikling mga gawain sa pag-aayos ng error, at ang mga resulta ng mga modelo sa Lite ay karaniwang mas mataas kaysa sa buong set, dahil sa pagbubukod ng pinaka-kumplikadong mga kaso[7].
  • SWE-bench Verified — isang subset na na-filter sa pamamagitan ng manu-manong pagsusuri, na ipinakita noong Agosto 2024 kasama ang OpenAI[7]. Nag-anyaya ang mga mananaliksik ng 93 propesyonal na developer upang suriin ang bawat gawain ng orihinal na benchmark at alisin ang mga kaso kung saan ang orihinal na paglalarawan ng problema ay masyadong malabo o ang kinakailangang gawi na sinusubok ay hindi malinaw na sumusunod mula sa kondisyon ng gawain[7]. Inalis din ang mga gawaing sa praktika ay imposibleng malutas dahil sa mga problema sa kapaligiran o maling mga pagsubok[7]. Bilang resulta, nabuo ang isang set ng 500 na gawain, na garantisadong malulutas at wastong nabalangkas[7]. Ang SWE-bench Verified ay naglalayong magbigay ng mas maaasahang pagtatasa ng mga kakayahan ng mga modelo, na inaalis ang mga kaso kung saan ang kahit tamang solusyon ay tinatanggihan dahil sa hindi sapat na mga pagsubok o takdang aralin[7]. Pinalitan ng set na ito ang mga orihinal na test sample ng SWE-bench (buong at Lite) bilang pangunahing sanggunian para sa paghahambing ng mga modelo[7]. Bukod dito, kasama ng Verified ay nailathala ang mga pagtatasa ng kahirapan ng gawain (halimbawa, tinukoy ang «madali» na mga gawain, malulutas sa loob ng <15 minuto ng isang tao, at «mahirap», na nangangailangan ng >1 oras)[7], at inilabas din ang isang bagong instrumental na balangkas batay sa Docker para sa mas matatag at mas mapagpalit na pagpapatakbo ng mga pagsubok[7].
  • SWE-bench Multimodal — isang extension ng benchmark, na ipinakita noong Enero 2025, na naglalaman ng mga gawain kung saan ang paglalarawan ng problema ay naglalaman hindi lamang ng teksto, kundi pati na rin ng mga visual na elemento (halimbawa, mga larawan ng interface, mga screenshot ng error, atbp.)[8]. Ang set na ito (517 na gawain[8]) ay sinusuri ang kakayahan ng mga modelo at ahente na maunawaan at gamitin ang visual na impormasyon sa paglutas ng mga gawain sa programming. Ang pagtatasa sa multimodal na set ay katulad ng nakaayos, ngunit nangangailangan ng multimodal na kakayahan mula sa modelo (halimbawa, pagkilala ng teksto sa mga larawan). Ang bahagi ng pagsubok ng SWE-bench Multimodal ay nanatiling sarado (nakatago) upang maiwasan ang pag-aaral mula sa mga kilalang sagot; maaaring magsumite ang mga developer ng mga solusyon sa isang remote leaderboard upang suriin ang kanilang mga modelo sa mga gawaing ito[2].

Bukod sa mga pangunahing variant na ito, nabuo sa paligid ng SWE-bench ang isang ecosystem ng mga kagamitan: SWE-agent — isang bukas na software «agent»-solver na nagpapakita ng mga pinakabagong resulta sa mga gawain ng benchmark[2]; SWE-smith — isang framework para sa pagsasanay ng sariling mga modelo ng developer; SWE-REX — isang kagamitan para sa pinahabang pagkuha at pagpoproseso ng impormasyon mula sa mga repositoryo, at iba pa. Ang mga proyektong ito ay naglalayong gawing mas simple ang pagpaparami ng mga resulta at isulong ang pananaliksik sa larangan ng mga autonomous na sistema ng programming.

Mga Resulta at Pag-unlad ng mga Modelo

Sa unang pagkakataon na lumabas ang SWE-bench, natuklasan nito ang malaking agwat sa pagitan ng mga makabagong LLM at ng mga kakayahan ng mga bihasang programmer. Iniulat ng mga may-akda na kahit ang pinakamakapangyarihang mga modelo noong simula ng 2023 ay nakayanan lamang ang ilang porsyento ng mga gawain: halimbawa, ang modelo ng Claude 2 mula sa kumpanyang Anthropic ay matagumpay na nakayanan ang wala pang 2% ng mga gawaing nasa buong set[1]. Ang modelo na espesyal na sinanay ng mga may-akda ng benchmark (batay sa LLaMA, na pinangalanang SWE-Llama) at mga proprietary na modelo tulad ng GPT-4 ay nakayanan lamang ang mga pinaka-simpleng error[1]. Ang mga mababang paunang sukatan na ito ay nagpapahiwatig ng kumplikasyon ng SWE-bench at nagsilbing insentibo para sa pagbuo ng mga bagong pamamaraan.

Sa loob ng 2024, habang lumitaw ang mas advanced na mga modelo at agentic na pamamaraan, ang mga resulta ay lubos na napabuti. Nagpakita ang mga mananaliksik mula sa Princeton ng SWE-agent na sistema, na pinagsasama ang GPT-4 sa paghahanap ng code, pagpaplano at iba pang mga kagamitan; nakamit nito ang humigit-kumulang 12.5% ng mga nalutas na gawain sa buong set, na nagtatag ng bagong pamantayan para sa mga akademikong modelo[5]. Sa kalagitnaan ng 2024, sa opisyal na leaderboard ng SWE-bench ang pinakamahusay na mga solusyon (kasama ang mga proprietary) ay nakamit ang humigit-kumulang 20% ng matagumpay na solusyon sa buong benchmark at hanggang 43% sa pinasimpleng set na Lite[7]. Ang ganitong paglago ay nauugnay sa pagpapabuti ng mga modelo (halimbawa, ang paglabas ng GPT-4, Claude 2 at 3) at lalo na sa pagpapaunlad ng «scaffolding» — mga panlabas na estratehiya na nagbibigay-daan sa modelo na epektibong hatiin ang gawain sa mga hakbang, basahin ang dokumentasyon, magpatakbo ng mga debugging session, atbp.[7].

Pagkatapos ng pagpapakilala ng Verified set noong katapusan ng 2024 (na nalinis mula sa mga maling gawain), ang nasusukat na pagganap ay higit pang tumaas. Ang modelo ng GPT-4 (variant na GPT-4o) ay agad na nagpakita ng humigit-kumulang 33% ng matagumpay na solusyon sa Verified kumpara sa ~16% dati sa orihinal na set[7]. Ang pinakamahusay na bukas na mga agentic na framework (halimbawa, Agentless) ay nag-doble ng kanilang resulta mula ~16% hanggang 32% sa Verified[7]. Kinumpirma nito ang palagay na ang orihinal na benchmark ay medyo nagpapababa ng mga sukatan dahil sa presensya ng mga hindi malulutas na kaso[7]. Kasabay nito, ang pagpapabuti ng mga resulta sa Verified kumpara sa Lite ay hindi gaanong dramatiko (ang mga pinakamahusay na modelo ay nakamit na ~43% sa Lite), na lohikal: ang Lite ay paunang pumipili ng mas madaling mga halimbawa, at ang Verified ay nag-alis ng mga hindi maisakatuparan, ngunit nag-iwan ng mga mahirap na gawain[7]. Mahalaga ring tandaan na ang paglago ng mga sukatan sa paglipat sa Verified ay naganap sa lahat ng kategorya ng kahirapan ng gawain, at hindi lamang dahil sa pag-alis ng pinaka-mahirap — ibig sabihin, ang pag-filter ay nag-alis din ng mga nakatagong hindi maisakatuparan na kaso kabilang ang medyo simpleng mga gawain[7].

Noong simula ng 2025, ang mga nangunguna na AI sistema ay nagpapakita ng pagganap na malapit na sa antas ng tao sa verified na set ng mga gawain, bagaman ang kisame na 100% ay malayo pa. Noong Enero 2025, iniulat ng kumpanyang Anthropic na ang kanyang bagong modelo na Claude 3.5 Sonnet kasama ang isang pinahusay na ahente ay nakalutas ng 49% ng mga gawain ng SWE-bench Verified[4], na pansamantalang kumuha ng unang lugar. Ang malalaking kumpanya ng teknolohiya at mga independiyenteng koponan ay aktibo rin na nakikilahok sa mga hindi opisyal na kompetisyon sa benchmark na ito. Kaya, binuo ng koponan ng CodeStory ang isang multi-model na pamamaraan na may pagbilang ng mga opsyon («Midwit Agent»), na nakamit ang rekord na 62.2% ng mga nalutas na gawain sa Verified (data sa simula ng 2025)[5][9]. Napansin na para dito ay kinailangang lubos na dagdagan ang mga gastos sa computational resources sa yugto ng paggawa ng modelo (tinatawag na inference time scaling), na nagpapatakbo ng maraming pagtatangka sa solusyon at pumipili ng pinakamahusay na resulta[5]. Sa turn, sa mga materyales ng OpenAI ay binanggit ang isang eksperimental na sistema ng GPT-o3, na sa sapat na pag-scale ng mga kalkulasyon ay diumano'y nakayanan ang hangganan na 70% sa Verified (hindi opisyal na data)[5]. Gayunpaman, walang independiyenteng pag-verify ng mga resultang ito, at ang gayong mataas na sukatan ay nananatiling isang gabay para sa mga hinaharap na pananaliksik kaysa sa isang nakamit na antas.

Ayon sa pananaliksik ng Microsoft Research (2025), kahit ang mga pinakabagong modelo na nilagyan ng mga kagamitan sa pag-debug ay hindi pa rin nakakaabot sa hangganan na 50% ng matagumpay na pag-aayos ng mga bug mula sa SWE-bench Lite[6]. Sa pagsubok na ito, ang pinakamahusay ay naging Claude 3.7 Sonnet na may ~48.4% ng mga nalutas na gawain, habang ang sistema sa GPT-4 (OpenAI o1) ay nakalutas ng humigit-kumulang 30%, at ang mas magaan na modelo na o3-mini — 22% lamang[6]. Ang mga resultang ito ay nagpapahiwatig na, sa kabila ng mabilis na pag-unlad, ang mga modernong AI ay nag-iiwan pa rin sa mga bihasang programmer: para sa isang tao ang paglutas ng ganitong mga gawain (sa pag-unawa ng code) ay hindi mahirap, habang ang modelo ay madalas na hindi epektibong ginagamit ang mga kagamitan sa pag-debug o nagdurusa mula sa kakulangan ng training data na sumasalamin sa multi-step na proseso ng pag-aayos ng error[6].

Mga Limitasyon at Pananaw

Ang SWE-bench ay naging isang standardisadong platform para sa pagtatasa ng mga matalinong code agent, gayunpaman ang pananaliksik ay nagsiwalat din ng ilang limitasyon nito. Ang pangunahing problema ay ang hindi kumpleto ng pagsubok: ang set ng mga verification test para sa bawat gawain ay kinukuha mula sa isang partikular na pull request, at karaniwang naglalaman lamang ng mga unit test na nabago sa panahon ng pag-aayos ng error[3]. Tulad ng ipinakita ng pagsusuri ng isang grupo ng mga siyentipiko mula sa Zhejiang University at Stuttgart University (Wang et al. 2025), ang pagwawalang-bahala sa iba pang mga pagsubok ng proyekto ay maaaring magtatago ng hindi tamang ilang solusyon[3]. Ang muling pagsuri ng mga solusyon sa buong set ng mga pagsubok ng repositoryo ay nagsiwalat na sa average na 7.8% ng mga patch na minarkahan bilang matagumpay sa SWE-bench, sa katunayan ay hindi pumapasa sa iba pang mga pagsubok sa proyekto[3]. Ito ay nagdudulot ng overestimation ng sukatan na «mga nalutas na gawain» ng humigit-kumulang 4-6 na porsyentong puntos[3]. Ang mas banayad na kaso ay kapag ang nabuong patch ay pumapasa sa lahat ng orihinal na pagsubok, ngunit sa parehong oras ay hindi katumbas ng solusyon ng developer at nagbabago ng gawi ng programa sa ibang paraan kaysa inaasahan. Sa pamamagitan ng pagbuo ng mga karagdagang test case (pamamaraan ng PatchDiff), natuklasan ng mga mananaliksik na halos 30% ng mga iminumungkahing AI na pag-aayos ay kumikilos nang iba kaysa sa mga reference patch, at humigit-kumulang 11% — ay malinaw na mali, bagaman hindi natutuklas ng mga umiiral na pagsubok[3]. Kaya, ang mga tunay na kakayahan ng mga modelo ay maaaring ma-overestimate kung umaasa lamang sa pagpapasa ng isang limitadong set ng mga pagsubok. Kinilala ng mga tagalikha ng SWE-bench ang kahinaan na ito at binibigyang-diin na ang benchmark ay dapat na mag-evolve sa paglipas ng panahon: pagpapabuti ng saklaw ng pagsubok, pagdaragdag ng mga pagsusuri para sa kawalan ng hindi gustong mga side effect, pagpapalawak ng hanay ng mga uri ng gawain[7]. Ang pagpapaunlad ng ganitong mga paraan ng pagtatasa ay isang mahalagang bahagi ng paghahanda para sa hitsura ng lalong mas autonomous at makapangyarihang mga AI developer, at ang karanasan sa SWE-bench ay nagpapakita ng pangangailangan ng maingat na saloobin sa kalidad ng mga benchmark[7].

Ang SWE-bench, bilang isang static na set ng mga gawain lamang, ay hindi ganap na sumasaklaw sa lahat ng aspeto ng programming, ngunit naging de facto na pamantayan na para sa comparative analysis ng mga code model[3]. Ginagamit ito sa mga siyentipikong gawa upang ipakita ang mga bagong pamamaraan at algorithm, pati na rin ng mga pangkat ng pananaliksik sa industriya upang masuri ang potensyal ng mga sistema na nilalayong i-automate ang programming[3]. Ang patuloy na paglago ng mga resulta sa SWE-bench sa loob ng 2023-2025 ay malinaw na nagpapakita ng mabilis na pagpapabuti ng mga kakayahan ng LLM sa paglutas ng mga praktikal na gawain sa pagbuo. Kasabay nito, nagsisilbi ito bilang barometro ng kumplikasyon: kahit na papalapit sa 50-60% ng mga nalutas na gawain, ang mga modelo ay malayo pa rin mula sa ganap na pagpapalit ng tao, lalo na sa mga kondisyon ng limitadong impormasyon at pangangailangan para sa maselang pag-unawa sa mga kinakailangan[4][7]. Gayunpaman, hindi humihinto ang pag-unlad — salamat sa ganitong mga inisyatiba tulad ng SWE-bench, malinaw na nakikita ng komunidad ang mga layunin at limitasyon nito, at nagpapatuloy sa paggalaw patungo sa paglikha ng isang ganap na AI developer, na may kakayahang awtonomyosong maunawaan at itama ang source code sa antas ng isang human expert[4][7].

Mga Sanggunian

  • SWE-bench sa GitHub
  • Opisyal na leaderboard ng SWE-bench

Panitikan

  • 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.

Mga Tala

  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)_(TL)&oldid=6535"