SWE-bench (benchmark) (HI)

From Systems analysis Wiki
Jump to navigation Jump to search

SWE-bench — यह एक विशाल benchmark (परीक्षण कार्यों का संग्रह) है जो बड़े भाषा मॉडलों (LLM) की स्वचालित सॉफ़्टवेयर विकास और डीबगिंग के क्षेत्र में क्षमताओं का मूल्यांकन करने के लिए बनाया गया है[1]। इसे Princeton University और अन्य संस्थाओं के शोधकर्ताओं के एक समूह द्वारा विकसित किया गया था और ICLR 2024 सम्मेलन में प्रस्तुत किया गया था[2]। SWE-bench पारंपरिक कोड benchmarks से इस मायने में अलग है कि यह विकास अभ्यास से वास्तविक कार्यों का उपयोग करता है: परीक्षण संग्रह में GitHub के 12 लोकप्रिय ओपन-सोर्स Python repositories से बंद issues और संबंधित सुधारों (pull requests) पर आधारित 2294 कार्य शामिल हैं[1][3]। प्रत्येक कार्य में समस्या का विवरण (issue) होता है और मॉडल को संबंधित प्रोजेक्ट के source code तक पहुँच प्रदान की जाती है; मॉडल का लक्ष्य codebase में न्यूनतम परिवर्तन (patch) उत्पन्न करना है जो उल्लिखित समस्या को ठीक करे[1][3]।

मूल्यांकन की पद्धति और विशेषताएँ

SWE-bench सॉफ़्टवेयर विकास की वास्तविक प्रक्रिया का अनुकरण करता है। प्रत्येक कार्य के लिए मॉडल को मूल GitHub issue का पाठ (समस्या का विवरण) और सुधार लागू होने से पहले की repository के code का snapshot प्रस्तुत किया जाता है[4]। मॉडल (या मॉडल-आधारित agent) को source code का विश्लेषण करना होता है, त्रुटि या आवश्यक परिवर्तन की प्रकृति को समझना होता है और समस्या को दूर करते हुए संबंधित code फ़ाइलों में सुधार करना होता है[4][5]। समाधान का सत्यापन स्वचालित है: प्रत्येक कार्य से उस pull request के वास्तविक unit tests जुड़े होते हैं जिसने उस समस्या को बंद किया था। इनमें «fail-to-pass» परीक्षण (जो मूल code पर पास नहीं होते, लेकिन सही सुधार लागू होने के बाद पास होने चाहिए) और regression tests (pass-to-pass, जो शुरू में पास होते हैं और परिवर्तन के बाद भी पास होते रहने चाहिए) दोनों होते हैं[3]। मॉडल द्वारा प्रस्तावित patch को code पर लागू किया जाता है, जिसके बाद संबंधित परीक्षण चलाए जाते हैं: यदि सभी fail-to-pass परीक्षण पास होने लगते हैं और pass-to-pass परीक्षण बाधित नहीं होते, तो कार्य को सही ढंग से हल माना जाता है[3]। मूल्यांकन का यह दृष्टिकोण न केवल मॉडल की वाक्यात्मक रूप से सही code उत्पन्न करने की क्षमता की जाँच करता है, बल्कि मौजूदा कार्यक्षमता को बाधित किए बिना वास्तव में समस्या हल करने की योग्यता की भी जाँच करता है। इस प्रक्रिया में मॉडल को बड़े context (पूरी code repository) के साथ काम करना पड़ता है, components के बीच संबंधों को समझना पड़ता है और एक साथ कई फ़ाइलों में परिवर्तनों का समन्वय करना पड़ता है[1] — यह सब किसी विवरण के आधार पर function लिखने के सामान्य कार्यों से कहीं अधिक जटिल है।

SWE-bench के मूल्यांकन में आमतौर पर केवल LLM स्वयं नहीं, बल्कि agentive systems भाग लेती हैं, जो मॉडल को सहायक उपकरणों (जैसे फ़ाइल नेविगेशन, code निष्पादन, debugger उपयोग आदि) से लपेटती हैं[4][6]। ऐसी प्रणाली वास्तविक विकास चक्र का अनुकरण करती है: मॉडल क्रमिक रूप से फ़ाइलें देख सकता है, परीक्षण या scripts चला सकता है और सफल परिणाम प्राप्त होने तक समाधान को चरणबद्ध तरीके से बेहतर बना सकता है[4]। यह उल्लेखनीय है कि SWE-bench कार्यों को हल करने की प्रभावशीलता काफी हद तक इस «scaffolding» (agent की infrastructure) की गुणवत्ता पर निर्भर करती है: समान मूल मॉडल इस बात के आधार पर अलग-अलग परिणाम दिखा सकते हैं कि repository और उपकरणों के साथ interaction कैसे व्यवस्थित किया गया है[4][7]। इस प्रकार, SWE-bench मॉडल और उसकी कार्य-समाधान रणनीति की संयुक्त क्षमताओं का मापदंड है, जो मूल्यांकन को स्वायत्त AI-developer की वास्तविक कार्य परिस्थितियों के करीब लाता है[4][7]।

कार्य संग्रह के प्रकार

SWE-bench के लेखकों और समुदाय ने बाद में विभिन्न मूल्यांकन उद्देश्यों के लिए कई व्युत्पन्न संग्रह प्रस्तुत किए:

  • SWE-bench Lite — benchmark का एक हल्का संस्करण, जिसमें ~300 कार्य[8] शामिल हैं, जिन्हें मॉडलों के परीक्षण की जटिलता और कम्प्यूटेशनल लागत को कम करने के लिए चुना गया है। यह उप-संग्रह मॉडलों के साथ त्वरित प्रयोग के लिए बनाया गया था और मुख्य समस्याओं की प्रतिनिधित्वशीलता बनाए रखते हुए सबसे अधिक श्रम-साध्य सत्यापनों को बाहर करता है[7]। सार रूप में, Lite में बग सुधार के अपेक्षाकृत सरल और संक्षिप्त कार्य हैं, और Lite पर मॉडलों के परिणाम आमतौर पर सबसे कठिन मामलों को हटाने के कारण पूर्ण संग्रह की तुलना में अधिक होते हैं[7]।
  • SWE-bench Verified — मैन्युअल सत्यापन द्वारा फ़िल्टर किया गया उप-संग्रह, जिसे अगस्त 2024 में OpenAI के साथ मिलकर प्रस्तुत किया गया[7]। शोधकर्ताओं ने मूल benchmark के प्रत्येक कार्य का विश्लेषण करने के लिए 93 पेशेवर डेवलपर्स को शामिल किया और उन मामलों को बाहर किया जहाँ मूल समस्या का विवरण बहुत अस्पष्ट था या परीक्षणों द्वारा अपेक्षित व्यवहार कार्य की शर्तों से स्पष्ट रूप से नहीं निकलता था[7]। उन कार्यों को भी हटाया गया जिन्हें environment की समस्याओं या गलत परीक्षणों के कारण व्यवहार में हल करना असंभव था[7]। परिणामस्वरूप 500 कार्यों का एक संग्रह बनाया गया, जो गारंटी के साथ हल करने योग्य और सही ढंग से तैयार किए गए हैं[7]। SWE-bench Verified का उद्देश्य मॉडलों की क्षमताओं का अधिक विश्वसनीय मूल्यांकन सुनिश्चित करना है, उन मामलों को समाप्त करके जहाँ सही समाधान भी परीक्षणों या कार्य की अपर्याप्तता के कारण अस्वीकार कर दिया जाता है[7]। यह संग्रह मॉडलों की तुलना के लिए मुख्य संदर्भ के रूप में SWE-bench के मूल परीक्षण नमूनों (पूर्ण और Lite) की जगह ले चुका है[7]। इसके अलावा, Verified के साथ कार्यों की कठिनाई के मूल्यांकन प्रकाशित किए गए (उदाहरण के लिए, «सरल» कार्य जो किसी इंसान द्वारा <15 मिनट में हल हो सकते हैं, और «कठिन» कार्य जिनके लिए >1 घंटे की आवश्यकता होती है)[7], और अधिक स्थिर और पुनरुत्पादनीय परीक्षण प्रक्रिया के लिए Docker-आधारित एक नया instrumental framework भी जारी किया गया[7]।
  • SWE-bench Multimodal — benchmark का विस्तार, जिसे जनवरी 2025 में प्रस्तुत किया गया, जिसमें ऐसे कार्य शामिल हैं जहाँ समस्या के विवरण में न केवल पाठ है, बल्कि दृश्य तत्व भी हैं (जैसे interface की images, error screenshots आदि)[8]। यह संग्रह (517 कार्य[8]) प्रोग्रामिंग कार्यों को हल करते समय मॉडलों और agents की visual information को समझने और उपयोग करने की क्षमता की जाँच करता है। Multimodal संग्रह पर मूल्यांकन उसी प्रकार आयोजित किया जाता है, लेकिन मॉडल से multi-modal क्षमताओं (जैसे images पर text पहचान) की आवश्यकता होती है। SWE-bench Multimodal का परीक्षण भाग ज्ञात उत्तरों के लिए समाधानों को अनुकूलित करने से रोकने के लिए बंद (छिपा हुआ) रखा गया है; डेवलपर्स इन कार्यों पर अपने मॉडलों के मूल्यांकन के लिए एक दूरस्थ leaderboard पर समाधान प्रस्तुत कर सकते हैं[2]।

इन मुख्य रूपांतरों के अलावा, SWE-bench के आसपास उपकरणों का एक ecosystem बन गया है: SWE-agent — एक ओपन-सोर्स सॉफ़्टवेयर «agent»-solver जो benchmark कार्यों पर अग्रणी परिणाम दर्शाता है[2]; SWE-smith — अपने स्वयं के developer models को प्रशिक्षित करने का framework; SWE-REX — repositories से जानकारी के विस्तारित निष्कर्षण और प्रसंस्करण का उपकरण आदि। ये परियोजनाएँ परिणामों के पुनरुत्पादन को सरल बनाने और स्वायत्त प्रोग्रामिंग प्रणालियों के क्षेत्र में शोध को आगे बढ़ाने के लिए निर्देशित हैं।

मॉडलों के परिणाम और प्रगति

SWE-bench के पहली बार प्रकट होने पर इसने आधुनिक LLM और अनुभवी प्रोग्रामरों के कौशल के बीच एक महत्वपूर्ण अंतर उजागर किया। लेखकों ने बताया कि 2023 की शुरुआत के सबसे शक्तिशाली मॉडल भी केवल कुछ प्रतिशत कार्यों को ही पूरा कर पाते थे: उदाहरण के लिए, Anthropic का Claude 2 मॉडल पूर्ण संग्रह के 2% से कम कार्यों को सफलतापूर्वक हल करता था[1]। benchmark के लेखकों द्वारा विशेष रूप से प्रशिक्षित मॉडल (LLaMA पर आधारित, SWE-Llama नाम से) और GPT-4 जैसे proprietary मॉडल मुख्यतः केवल सबसे सरल त्रुटियों को ही हल कर सकते थे[1]। इन कम प्रारंभिक metrics ने SWE-bench की जटिलता को रेखांकित किया और नए दृष्टिकोणों के विकास को प्रेरित किया।

2024 के दौरान, अधिक उन्नत मॉडलों और agentive schemes के प्रकट होने के साथ, परिणामों में उल्लेखनीय सुधार हुआ। Princeton के शोधकर्ताओं ने SWE-agent प्रणाली प्रस्तुत की, जो GPT-4 को code खोज, planning और अन्य उपकरणों के साथ जोड़ती है; इसने पूर्ण संग्रह पर लगभग 12.5% हल किए गए कार्यों का लक्ष्य प्राप्त किया, जो academic models के लिए एक नया संदर्भ स्थापित करता है[5]। 2024 के मध्य तक, SWE-bench के आधिकारिक leaderboard पर सर्वश्रेष्ठ समाधान (proprietary सहित) पूर्ण benchmark पर लगभग 20% सफल समाधानों तक और सरल Lite संग्रह पर 43% तक पहुँच गए[7]। यह वृद्धि मॉडलों के सुधार (जैसे GPT-4, Claude 2 और 3 का प्रकट होना) और विशेष रूप से «scaffolding» — बाहरी रणनीतियों के विकास — से जुड़ी है जो मॉडल को कार्य को चरणों में प्रभावी ढंग से विभाजित करने, दस्तावेज़ीकरण पढ़ने, debugging sessions चलाने आदि की अनुमति देती हैं[7]।

2024 के अंत में Verified संग्रह (गलत कार्यों से शुद्ध) के शुरू होने के बाद, मापी गई कार्यक्षमता और भी अधिक बढ़ गई। GPT-4 मॉडल (GPT-4o variant) ने तुरंत Verified पर लगभग 33% सफल समाधान दिखाए, जबकि पहले मूल संग्रह पर यह ~16% था[7]। सर्वश्रेष्ठ ओपन-सोर्स agent frameworks (जैसे Agentless) ने Verified पर अपना परिणाम ~16% से दोगुना करके 32% कर लिया[7]। इसने इस धारणा की पुष्टि की कि मूल benchmark अहल करने योग्य मामलों की उपस्थिति के कारण metrics को कुछ हद तक कम आंकता था[7]। साथ ही, Verified बनाम Lite पर परिणामों में सुधार इतना नाटकीय नहीं है (सर्वश्रेष्ठ मॉडल पहले ही Lite पर ~43% तक पहुँच चुके थे), जो तार्किक है: Lite ने शुरू में आसान उदाहरणों का चयन किया था, जबकि Verified ने अहल करने योग्य को हटाया लेकिन जटिल कार्यों को रखा[7]। यह ध्यान देना महत्वपूर्ण है कि Verified पर जाने पर metrics में वृद्धि कार्यों की कठिनाई की सभी श्रेणियों में हुई, न कि केवल सबसे कठिन को हटाने से — अर्थात फ़िल्टरिंग ने संग्रह को अपेक्षाकृत सरल कार्यों में छिपे अहल करने योग्य मामलों से भी मुक्त किया[7]।

2025 की शुरुआत तक, अग्रणी AI प्रणालियाँ verified कार्य संग्रह पर पहले से ही मानव-समान कार्यक्षमता के करीब दिखाती हैं, हालाँकि 100% की सीमा अभी भी दूर है। जनवरी 2025 में Anthropic ने बताया कि उसके नए Claude 3.5 Sonnet मॉडल ने एक बेहतर agent के साथ मिलकर SWE-bench Verified के 49% कार्यों को हल किया[4], जो अस्थायी रूप से पहले स्थान पर आ गया। बड़ी प्रौद्योगिकी कंपनियाँ और स्वतंत्र टीमें भी इस benchmark पर अनौपचारिक प्रतिस्पर्धाओं में सक्रिय रूप से भाग लेती हैं। इस प्रकार, CodeStory टीम ने एक बहु-मॉडल approach विकसित किया जिसमें विकल्पों की खोज («Midwit Agent») शामिल है, जिसने Verified पर रिकॉर्ड 62.2% हल किए गए कार्यों का आँकड़ा प्राप्त किया (2025 की शुरुआत के डेटा)[5][9]। यह उल्लेख किया गया कि इसके लिए मॉडल inference के चरण (तथाकथित inference time scaling) पर कम्प्यूटेशनल संसाधनों का खर्च बड़े पैमाने पर बढ़ाना पड़ा, कई समाधान प्रयास चलाकर सर्वश्रेष्ठ परिणाम का चयन किया[5]। बदले में, OpenAI की सामग्रियों में एक प्रायोगिक GPT-o3 प्रणाली का उल्लेख था, जो पर्याप्त computing scaling के साथ कथित तौर पर Verified पर 70% की सीमा पार करने में सक्षम थी (अनौपचारिक डेटा)[5]। हालाँकि, इन परिणामों का स्वतंत्र सत्यापन अनुपस्थित है, और इतना उच्च संकेतक भविष्य के शोध के लिए एक दिशानिर्देश बना हुआ है, न कि प्राप्त लक्ष्य।

Microsoft Research (2025) के एक अध्ययन के अनुसार, नवीनतम मॉडल भी debugging उपकरणों से लैस होने पर SWE-bench Lite से बग सुधारों में 50% की सीमा को पार नहीं कर पाते[6]। इस परीक्षण में Claude 3.7 Sonnet ~48.4% हल किए गए कार्यों के साथ सर्वश्रेष्ठ रहा, जबकि GPT-4 (OpenAI o1) पर आधारित प्रणाली ने लगभग 30% हल किए, और अधिक हल्का o3-mini मॉडल केवल 22%[6]। ये परिणाम इस बात को रेखांकित करते हैं कि तेज़ प्रगति के बावजूद, आधुनिक AI अभी भी अनुभवी प्रोग्रामरों से पीछे है: एक इंसान के लिए ऐसे कार्यों को हल करना (code की समझ होने पर) कठिन नहीं है, जबकि मॉडल अक्सर debugging उपकरणों का प्रभावी ढंग से उपयोग नहीं कर पाता या बहु-चरणीय bug-fixing प्रक्रिया को दर्शाने वाले training data की कमी से पीड़ित होता है[6]।

सीमाएँ और संभावनाएँ

SWE-bench intelligent code agents के मूल्यांकन के लिए एक मानकीकृत मंच बन गया है, हालाँकि शोध ने इसकी कई सीमाएँ भी उजागर की हैं। मुख्य समस्या — परीक्षण की अपूर्णता है: प्रत्येक कार्य के लिए सत्यापन परीक्षणों का संग्रह एक विशिष्ट pull request से लिया जाता है, और इसमें आमतौर पर केवल वे unit tests शामिल होते हैं जो bug fix के दौरान बदले गए थे[3]। जैसा कि Zhejiang University और Stuttgart University के वैज्ञानिकों के एक समूह के विश्लेषण (Wang et al. 2025) से पता चला, प्रोजेक्ट के शेष परीक्षणों को नज़रअंदाज़ करने से कुछ समाधानों की गलतता छिप सकती है[3]। repository के परीक्षणों के पूर्ण संग्रह पर समाधानों की पुनर्जाँच से पता चला कि औसतन 7.8% patches जिन्हें SWE-bench में सफल के रूप में चिह्नित किया गया, वास्तव में प्रोजेक्ट के अन्य परीक्षणों से पास नहीं होते[3]। इससे «हल किए गए कार्य» की metric लगभग 4-6 प्रतिशत अंकों से अधिक आंकी जाती है[3]। और भी सूक्ष्म मामला तब होता है जब उत्पन्न patch सभी मूल परीक्षणों को पास करता है, लेकिन developer के समाधान के समतुल्य नहीं है और program के व्यवहार को अपेक्षित तरीके से नहीं बदलता। अतिरिक्त test cases उत्पन्न करके (PatchDiff methodology) शोधकर्ताओं ने पाया कि लगभग 30% AI-प्रस्तावित सुधार reference patches से अलग व्यवहार करते हैं, और लगभग 11% — स्पष्ट रूप से गलत हैं, हालाँकि मौजूदा परीक्षणों द्वारा पकड़े नहीं जाते[3]। इस प्रकार, यदि केवल सीमित परीक्षणों को पास करने पर भरोसा किया जाए तो मॉडलों की वास्तविक क्षमताओं को अधिक आंका जा सकता है। SWE-bench के निर्माता इस कमज़ोरी को स्वीकार करते हैं और ज़ोर देते हैं कि benchmark को समय के साथ विकसित होना चाहिए: परीक्षण coverage में सुधार होना चाहिए, अनावश्यक side effects की अनुपस्थिति की जाँच जोड़ी जानी चाहिए, कार्यों के प्रकारों का संग्रह विस्तारित होना चाहिए[7]। ऐसे मूल्यांकन साधनों का विकास — तेज़ी से अधिक स्वायत्त और शक्तिशाली AI-developers के उद्भव की तैयारी का एक महत्वपूर्ण हिस्सा है, और SWE-bench का अनुभव benchmarks की गुणवत्ता पर सावधानीपूर्वक ध्यान देने की आवश्यकता दर्शाता है[7]।

SWE-bench, केवल एक स्थिर कार्य संग्रह होने के बावजूद, प्रोग्रामिंग के सभी पहलुओं को पूरी तरह कवर नहीं करता, लेकिन code models के तुलनात्मक विश्लेषण के लिए de-facto standard बन चुका है[3]। इसका उपयोग नए तरीकों और algorithms को प्रदर्शित करने के लिए वैज्ञानिक कार्यों में, और प्रोग्रामिंग को स्वचालित करने के लिए लक्षित प्रणालियों की क्षमता का मूल्यांकन करने के लिए औद्योगिक शोध समूहों द्वारा किया जाता है[3]। 2023-2025 के दौरान SWE-bench पर परिणामों की निरंतर वृद्धि व्यावहारिक विकास कार्यों को हल करने में LLM की क्षमताओं में तेज़ सुधार को स्पष्ट रूप से दर्शाती है। साथ ही यह जटिलता का एक barometer है: 50-60% हल किए गए कार्यों के करीब पहुँचने पर भी, मॉडल अभी भी मनुष्य के पूर्ण प्रतिस्थापन से दूर हैं, विशेष रूप से सीमित जानकारी की परिस्थितियों में और आवश्यकताओं की सूक्ष्म समझ की आवश्यकता होने पर[4][7]। फिर भी, प्रगति रुकती नहीं — SWE-bench जैसी पहलों की बदौलत, समुदाय अपने लक्ष्यों और सीमाओं को स्पष्ट रूप से देखता है, और एक पूर्ण AI-developer बनाने की दिशा में आगे बढ़ता रहता है जो मानव विशेषज्ञ के स्तर पर स्वायत्त रूप से program code को समझने और सुधारने में सक्षम हो[4][7]।

संदर्भ

  • GitHub पर SWE-bench
  • SWE-bench का आधिकारिक leaderboard

साहित्य

  • 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. [१]
  2. ↑ 2.0 2.1 2.2 «SWE-bench/SWE-bench». GitHub. [२]
  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. [३]
  4. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 «Claude SWE-Bench Performance». Anthropic. [४]
  5. ↑ 5.0 5.1 5.2 5.3 5.4 Jain, Sulbha. «SWE Benchmark: LLM evaluation in Software Engineering Setting». Medium. [५]
  6. ↑ 6.0 6.1 6.2 6.3 Hatmaker, Taylor. «AI models still struggle to debug software, Microsoft study shows». TechCrunch. [६]
  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. [७]
  8. ↑ 8.0 8.1 8.2 «SWE-bench Leaderboard». [८]
  9. ↑ «SOTA on swebench-verified: relearning the bitter lesson». Hacker News (Y Combinator). [९]
Retrieved from "https://systems-analysis.info/int/index.php?title=SWE-bench_(benchmark)_(HI)&oldid=6524"