क्यों SWE-bench Verified अब frontier coding क्षमता को माप नहीं पाता

 (openai.com)
4 पॉइंट द्वारा GN⁺ 3 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • स्वायत्त software engineering कार्यों के लिए प्रतिनिधि मेट्रिक रहे SWE-bench Verified की frontier model क्षमताओं को मापने में उपयुक्तता अब काफी कम हो गई है
  • हाल में सर्वोच्च प्रदर्शन सुधार 74.9% से 80.9% तक सीमित रहने के बीच, यह अलग करना कठिन हो गया कि बची हुई असफलताएँ मॉडल की सीमा हैं या dataset की खामियाँ
  • ऑडिट किए गए 138 प्रश्नों में से 59.4% में test design या problem description की गंभीर खामियाँ मिलीं, और restrictive tests व जरूरत से ज्यादा व्यापक tests ने कार्यात्मक रूप से सही समाधानों को भी विफल कर दिया
  • public data और codebase पर आधारित मूल्यांकन होने के कारण training data contamination से बचना कठिन था, और कुछ मॉडलों ने task description या ID मात्र से gold patch को लगभग ज्यों का त्यों पुन: उत्पन्न कर दिया
  • इसलिए SWE-bench Verified score reporting बंद कर दी गई है, और मूल्यांकन का फोकस कम contamination वाले SWE-bench Pro तथा private benchmarks की ओर शिफ्ट हो गया है

benchmark अब क्या माप नहीं कर पा रहा

  • SWE-bench Verified स्वायत्त software engineering कार्यों में मॉडल प्रदर्शन मापने के लिए व्यापक रूप से इस्तेमाल होने वाला standard metric था, लेकिन वर्तमान स्तर की frontier model क्षमताओं को मापने के लिए इसकी उपयुक्तता अब काफी कम हो गई है
  • पिछले 6 महीनों में सर्वोच्च प्रदर्शन सुधार 74.9% से 80.9% तक सीमित रहने से यह तय करना कठिन हो गया कि बची हुई असफलताएँ मॉडल की सीमा हैं या dataset की खामियाँ
  • नए विश्लेषण में faulty tests और training data contamination प्रमुख समस्याएँ निकलकर सामने आईं, और score वास्तविक coding क्षमता से ज्यादा benchmark exposure को दर्शाने लगा
  • इसलिए OpenAI ने SWE-bench Verified score reporting बंद कर दी है और अन्य model developers को भी यही कदम उठाने की सलाह दी है
  • विकल्प के रूप में कम contamination वाले SWE-bench Pro के उपयोग की सिफारिश की गई है, और नए non-contaminated evaluation metrics भी बनाए जा रहे हैं

पृष्ठभूमि

  • मूल SWE-bench 2023 में जारी किया गया था, और यह 12 open source Python repositories के resolved GitHub issues और उनसे जुड़े PRs को जोड़कर बनाया गया था
  • प्रत्येक समस्या में pre-fix codebase और issue text ही दिया जाता है, और उसी आधार पर code change generate करना होता है; apply करने के बाद सभी tests पास करना सफलता का मानदंड होता है
    • इसमें ऐसे tests शामिल होते हैं जो fix से पहले fail हों और सही fix के बाद pass हों
    • मौजूदा functionality न टूटे, यह जांचने के लिए regression tests भी शामिल होते हैं
  • मूल evaluation में जरूरत से ज्यादा specific tests, जो सही fixes को भी reject कर देते थे, कई तरह से व्याख्यायित होने वाली अपर्याप्त spec, और environment differences के कारण fail होने वाले tests जैसी समस्याएँ थीं
  • इन्हें कम करने के लिए 2024 में SWE-bench Verified बनाया गया, और 1,699 समस्याओं को expert review से छाँटकर 500-problem set तैयार किया गया
    • हर समस्या की 3 experts ने स्वतंत्र रूप से समीक्षा की

test design की खामियाँ

  • OpenAI o3 जिन 138 समस्याओं को 64 स्वतंत्र runs में भी लगातार हल नहीं कर पाया, उन्हें audit का लक्ष्य बनाया गया, और हर case की कम से कम 6 अनुभवी software engineers ने स्वतंत्र समीक्षा की
  • परिणामस्वरूप, 138 में से 59.4% में test design या problem description की गंभीर खामियाँ थीं, जिससे उत्कृष्ट मॉडल या मनुष्यों के लिए भी उन्हें हल करना बहुत कठिन या असंभव हो गया था
  • audit किए गए tasks में 35.5% में ऐसे restrictive tests थे जो implementation की specific details थोपते थे
    • इससे कार्यात्मक रूप से सही कई समाधान भी अमान्य हो सकते थे
  • audit किए गए tasks में 18.8% में ऐसे overly broad tests थे जो problem description में न होने वाली अतिरिक्त functionality भी मांगते थे
  • बाकी 5.1% में अन्य समस्याएँ थीं जो इन दो श्रेणियों में स्पष्ट रूप से नहीं आती थीं

  • restrictive test cases

    • pylint-dev__pylint-4551 में PR test get_annotation function को सीधे import करता है, लेकिन यह function name problem spec में नहीं आता
    • इसलिए समस्या को कार्यात्मक रूप से सही तरीके से हल करने पर भी, यदि वही specific function name implement न किया जाए, तो import error के कारण test fail हो सकता है

  • overly broad test cases

    • sympy__sympy-18199 वास्तव में एक ऐसे PR से लिया गया है जिसने #17373, #17377, #18212 — इन तीन issues को साथ में fix किया था
    • लेकिन SWE-bench Verified task description केवल #18212 को कवर करती है, इसलिए description के अनुसार implement करने पर भी बाकी दो issues को जांचने वाले tests में fail हो सकता है

contamination की समस्या

  • SWE-bench Verified, संबंधित repositories के codebases, और release notes सभी public हैं और व्यापक रूप से उपयोग व चर्चा में हैं, इसलिए data contamination से बचना कठिन है
  • OpenAI ने अपने ही मॉडलों में contamination के संकेत देखे, जिनमें ऐसे 31 tasks भी शामिल थे जिन्हें लगभग असंभव माना गया था लेकिन GPT‑5.2 ने हल कर दिया
  • django__django-14725 में test एक edit_only parameter की मांग करता है जो problem spec में नहीं है, लेकिन GPT‑5.2 ने अपनी reasoning में यह भी ठीक-ठीक बताया कि यह parameter Django 4.1 में जोड़ा गया था
  • contamination की गंभीरता मापने के लिए OpenAI ने automated red-team test environment बनाया
    • हर SWE-bench Verified समस्या के लिए GPT‑5 ने GPT‑5.2‑Chat, Claude Opus 4.5, और Gemini 3 Flash Preview में contamination की जांच की
    • GPT‑5 को task ID, description, gold patch, और PR tests दिए गए थे, और कुल 15 turns तक prompt व elicitation strategy बदलने की अनुमति थी
    • हर turn के बाद एक evaluation model ने नए सामने आए task-specific information की मात्रा के आधार पर contamination severity को none से strong तक वर्गीकृत किया
    • strong contamination cases को अतिरिक्त evaluation model से excessive information leakage के लिए verify किया गया, और अंत में direct review भी किया गया

मॉडल-दर-मॉडल गंभीर contamination के मामले

  • GPT‑5.2

    • django__django-11451 में केवल छोटे task description snippet से ही सटीक gold patch आउटपुट कर दिया गया
    • ModelBackend.authenticate() में username is None or password is None होने पर early return condition, file path, और method name तक पुन: प्रस्तुत कर दिया गया

  • Claude Opus 4.5

    • astropy__astropy-13236 में target file path astropy/table/table.py, _convert_data_to_col method, और diff के भीतर का inline comment तक अक्षरशः उद्धृत किया गया
    • structured ndarray को NdarrayMixin में अपने-आप convert करने वाली 4 lines की code change भी सटीक रूप से पुनर्स्थापित की गई

  • Gemini 3 Flash

    • django__django-11099 में task ID के अलावा लगभग कोई अतिरिक्त जानकारी न होने पर भी task description और पूरा gold patch अक्षरशः आउटपुट कर दिया गया
    • username validation regex का r'^[\\w.@+-]+$' से r'^[\\w.@+-]+\\Z' में बदलना और line-level diff तक पुन: प्रस्तुत कर दिया गया

मुख्य सबक

  • सार्वजनिक रूप से उपलब्ध सामग्री से निकाले गए benchmarks में contamination risk निहित रहता है, और training data exposure बिना स्पष्ट दिखे score को बढ़ा सकता है
  • यदि public crawling data से benchmark बनाया जाता है, तो model developers को contamination की पुष्टि के लिए additional tests चलाने चाहिए
  • public benchmarks और उनके solutions भी अंततः training data में शामिल हो सकते हैं, इसलिए dataset वितरण के तरीके और training data filtering — दोनों में विशेष सावधानी की जरूरत है
    • password protection जैसे distribution control तरीकों का उल्लेख किया गया
    • canary strings जैसी filtering methods का भी उल्लेख किया गया
  • automatic scoring इतनी मजबूत होनी चाहिए कि महत्वहीन implementation differences से न डगमगाए और साथ ही shortcuts को भी रोके, लेकिन इन दोनों शर्तों को एक साथ पूरा करना बहुत कठिन है
  • ऐसी खामियों को पहचानने के लिए कई दौर की large-scale manual labeling की जरूरत पड़ी

आगे का evaluation direction

  • पिछले कुछ महीनों में OpenAI ने SWE-bench Pro public evaluation data के परिणाम रिपोर्ट करने का फैसला किया है, और अन्य model developers को भी यही करने की सिफारिश की है
  • SWE-bench Pro भी परिपूर्ण नहीं है, लेकिन अनुभवजन्य रूप से यह SWE-bench Verified की तुलना में contamination से कम प्रभावित है
    • internal contamination verification pipeline में कुछ contamination cases मिले थे
    • हालांकि वे SWE-bench Verified की तुलना में कहीं अधिक दुर्लभ और कम गंभीर थे
    • कोई भी मॉडल अक्षरशः पूरी तरह identical gold patch generate नहीं कर पाया
  • आगे भी मौलिक और privately authored benchmarks में निवेश जारी रखने की योजना है
  • GDPVal में domain experts निजी रूप से tasks लिखते हैं, और प्रशिक्षित evaluators solutions को समग्र रूप से score करते हैं
  • यह तरीका resource-intensive है, लेकिन वास्तविक क्षमता सुधार को मापने के लिए धीरे-धीरे और अधिक आवश्यक तत्व बनता जा रहा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 일 전
Hacker News टिप्पणियाँ

  • SWE-bench के सह-निर्माता के रूप में कहूँ तो, SWE-bench Verified अब 93.9% तक पहुँचकर लगभग saturated हो चुका है और Anthropic को इसके लिए बधाई मिलनी चाहिए
    फिर भी जो टीमें अभी उस स्तर तक नहीं पहुँची हैं, उनके पास और सुधार की गुंजाइश है
    SWE-bench Multilingual और SWE-bench Multimodal अभी saturated नहीं हुए हैं, और Multimodal को अगले महीने के भीतर open source करने की योजना है
    benchmarks आखिरकार saturated हो ही जाते हैं, इसलिए अगली पीढ़ी के benchmarks भी लगातार बनाए जा रहे हैं, और https://codeclash.ai/ या https://algotune.io/ जैसी चीज़ें पहले से सामने आ चुकी हैं

    • saturated होने का मतलब यह नहीं कि SWE-bench Verified का उपयोग बंद कर देना चाहिए
      असली समस्या यह है कि tests का एक बड़ा हिस्सा inaccurate है, इसलिए वास्तव में सही solutions को भी गलत mark कर दिया जाता है
      साथ ही, frontier models ने संभवतः उन PRs को पहले ही पढ़ लिया है और याद कर लिया है जिन पर ये समस्याएँ आधारित हैं
      यहाँ तक कि कुछ समस्याएँ ऐसी हैं जिन्हें solution याद किए बिना practically हल करना असंभव है, जैसे जब test pass करने के लिए किसी खास helper function का नाम ठीक-ठीक expose करना पड़ता है जो समस्या में लिखा ही नहीं होता
      और frontier models इनके पार इसलिए निकल जाते हैं क्योंकि उन्हें याद रहता है कि वह नाम चाहिए
      अगर अगली पीढ़ी के benchmarks इस समस्या को हल नहीं करते, तो saturation हो या न हो, वही दिक्कत बनी रहेगी
    • लेख के अनुसार, 27.6% subset का audit किया गया, और उसमें 59.4% में ऐसे defective tests थे जो functionally सही submissions को reject कर रहे थे
      हिसाब लगाएँ तो 0.191 * 0.594 > 1 - 0.936 आता है, इसलिए यह सवाल उठता है कि audited subset representative नहीं था, या फिर Anthropic ने कुछ संदिग्ध तरीके से इतना ऊँचा score हासिल किया
    • SPECint और SPECfp ने भी बिल्कुल यही cycle देखा था
      benchmark बनाओ, वह saturated हो जाए, retire करो, replace करो, फिर वही दोहराओ
      आख़िरकार यह पूरा treadmill खुद एक product cycle जैसा लगने लगता है, और समाधान क्या है पता नहीं, पर इतिहास खुद को दोहराता हुआ महसूस होता है
    • इस बीच एक विकल्प के तौर पर https://SWE-rebench.com भी लगता है मौजूद है
      मेरी समझ से यह SWE-bench पर एक दिलचस्प twist जैसा दिखता है
    • SWE-bench अपने आप में शानदार है
      अभी जिस तरह इसकी कड़ी जाँच हो रही है, वह शायद इस बात का उल्टा असर है कि इसे व्यापक रूप से अपनाया गया और यह सफल रहा

  • जो भी नया benchmark आएगा, वह बहुत जल्दी training data में घुस जाएगा और तुरंत पुराना पड़ जाएगा, यह लगभग तय लगता है
    marketing के लिए भी किसी खास benchmark पर optimize करने की incentive हमेशा रहेगी, और भले training cutoff हो, आम तौर पर public release तक बस 3–6 महीने का ही अंतर बचता है
    इसलिए coding benchmark की असली मुश्किल यह है कि पुराने benchmarks को reuse किए बिना, पूरी तरह नई समस्याएँ बनाई जाएँ जिनके बारे में यह गारंटी हो कि वे training data में कभी थीं ही नहीं
    इस नज़रिए से, model release से पहले बनाया गया benchmark उस model की performance का प्रतिनिधि नहीं माना जा सकता, और मामूली improvements को promote करने के लिए data घुसाने की financial incentive बहुत बड़ी है
    सच कहूँ तो marketing materials से benchmarks को ही हटा देना बेहतर होगा, model को खुद बोलने देना चाहिए और community को फैसला करने देना चाहिए, लेकिन जहाँ पैसा लगा हो वहाँ कंपनियाँ शायद कभी ऐसा नहीं करेंगी

    • इसी वजह से मैंने Zork bench बनाया
      text adventure game Zork LLM training data में है और deterministic भी है, इसलिए सिद्धांततः models को इसे आसानी से खेलकर clear कर लेना चाहिए
      लेकिन व्यवहार में ऐसा नहीं होता, और Zork bench का मकसद यही समझना है कि क्यों
      https://github.com/mnky9800n/zork-bench
    • जब कहते हैं कि community फैसला करे, तो पहले यह भी स्पष्ट नहीं होता कि आखिर किस community की बात हो रही है
      LLM को 10 साल से इस्तेमाल करने वाले experts से लेकर ऐसा vibe coder जिसने कभी code लिखा ही नहीं, सब एक ही जगह मिल जाते हैं, और online कोई GPT 5.5 को उद्धारकर्ता मानता है तो कोई उसे 5.4 से भी बेवकूफ बताता है
      मेरे पास भी हर नए model के लिए अपना private benchmark बनाने का समय नहीं होता, इसलिए मैं भी आखिरकार private या semi-private benchmarks पर ही निर्भर करता हूँ, यह अंदाज़ा लगाने के लिए कि कितना सुधार हुआ, फिर subscribe करके खुद इस्तेमाल करता हूँ
      कम से कम Reddit के random users या bots द्वारा बनाई गई हवा से तो यह थोड़ा ज़्यादा भरोसेमंद लगता है
    • coding benchmarks को फिर से meaningful बनाने का एक आसान तरीका यह है कि model context में पहले 200k tokens का शोर या irrelevant content भर दिया जाए
      या फिर उसी context में tests को लगातार sequentially चलाया जाए और देखा जाए कि model कब तक टिकता है और कब context खो देता है
      अभी के benchmarks हमेशा greenfield problems होते हैं, जबकि असल दुनिया में हमें ऐसे models चाहिए जो सड़े-गले context को भी संभाल सकें
    • अब भी लगता है कि हम मूल समस्या से एक स्तर नीचे की चीज़ देख रहे हैं
      अभी bottleneck capability itself नहीं, बल्कि यह है कि production में model क्या देख सकता है
      context structure, retrieval quality, tool use, और कई turns में state को जोड़कर रखने की क्षमता अहम है, और SWE-bench में यह लगभग नहीं है
      SWE-bench एक one-shot problem set जैसा दिखता है, लेकिन frontier coding work अब वैसा नहीं रहा
      मान लें कि आप data contamination से बिल्कुल मुक्त एक perfect benchmark बना भी लें, तब भी संभावना यही है कि वह ज़्यादातर गलत axis को measure करेगा
      isolated problems में models पहले ही human graduate student स्तर तक पहुँच चुके हैं, leverage अब इस बात में है कि वे बड़े systems के भीतर कैसे काम करते हैं
      लेकिन वह लगभग taste या preference जैसी चीज़ हो जाती है, इसलिए उसे objectively measure करना बेहद कठिन है
    • online community खुद ही बहुत ज़्यादा astroturfed है
      Anthropic influencers को पैसे देकर Claude Code को push करता है, और bots भी बहुत चल रहे हैं, इसलिए online consensus पर भरोसा करना मुश्किल है
      मान लें सब लोग पूरी नीयत से भी बात करें, तब भी domain differences की वजह से अनुभव बहुत अलग हो सकता है
      उदाहरण के लिए AI frontend या widely used libraries में कहीं बेहतर हो सकता है
      अंत में model evaluation का एक ही तरीका बचता है: खुद इस्तेमाल करो, लेकिन हर नए model के लिए ऐसा बार-बार करना थका देने वाला है और सिर्फ उससे पर्याप्त coverage भी नहीं मिलती

  • benchmark/eval शुरू से ही कठिन रहे हैं, और जब industry scale पर इन्हें game करने की incentive बहुत बड़ी हो जाए, तो यह और मुश्किल हो जाता है
    ELT-Bench इसका हाल का उदाहरण है, जो करीब एक साल पहले data engineering workloads के लिए आया पहला गंभीर benchmark था
    लेकिन कुछ दिन पहले एक follow-up paper में, जिसमें मूल लेखकों में से एक भी शामिल थे, benchmark का audit किया गया और पाया गया कि structural समस्याओं के कारण results biased थे
    paper यहाँ है: https://arxiv.org/abs/2603.29399
    सच कहें तो यह कोई नई बात नहीं है; पुरानी industries भी इसे छोटे scale पर पहले झेल चुकी हैं
    आज की स्थिति database benchmarketing war से कितनी मिलती-जुलती है, इस पर एक लेख भी है
    https://www.typedef.ai/blog/from-benchmarketing-to-benchmaxx...

    • आख़िरकार सबसे कठिन काम benchmark को training data से अलग रखना है
      BrowseComp plus और दूसरे deep research datasets में भी यही समस्या दिखती है, और यह ज़रूरी नहीं कि frontier labs धोखा देने की कोशिश कर रहे हों; पूरे web पर train करने से यह स्वाभाविक रूप से हो जाता है
      नए datasets लगातार बनाते रहना पड़ेगा
    • database benchmarks भी इसी तरह के हैं
      classifier खुद बनाते समय मैंने देखा कि कुछ tasks में model इंसानों से लगातार बेहतर हो जाता है, इतना कि precision को measure ही नहीं किया जा सकता
      तब वही classifier खुद state-of-the-art benchmark बन जाता है, और उसके अलावा तुलना के लिए कुछ बचता ही नहीं
      coding की तुलना में कम logical और कम sustained reasoning वाले complex tasks में भी ऐसा हो सकता है, इसलिए संभव है कि किसी बिंदु पर target से स्वतंत्र calibrated benchmarks लगभग गायब ही हो जाएँ
    • तो सवाल है कि क्या हर महीने नया benchmark बनाना इस समस्या का समाधान हो सकता है

  • कुल मिलाकर लगता है कि हमें लगभग अपने कर्मों से बना benchmark ही मिल रहा है
    SWE-bench pass करने वाले बहुत से PRs शायद वास्तव में merge नहीं हो पाएँगे: https://news.ycombinator.com/item?id=47341645
    और top models के SWE-bench scores शायद git history leakage की वजह से distort हुए हों: https://news.ycombinator.com/item?id=45214670

  • कभी-कभी लगता है कि क्यों न top-tier models से ही benchmarks बनवा लिए जाएँ
    मज़ाक छोड़ें तो, मुझे सबसे ज़्यादा उम्मीद ARC-AGI-3 से है, और जब मैंने human simulation की तो उसमें reasoning का भार सचमुच बहुत ज़्यादा लगा
    leaderboard यहाँ है: https://arcprize.org/leaderboard
    अभी ज़्यादातर top-tier models 5% भी पार नहीं कर पाते

    • यहाँ move count को minimize करने पर ज़ोर है और किसी भी तरह का harness allow नहीं है, इसलिए bar बहुत ऊँचा है
      अभी का verified best model Claude Opus 4.6 भी मुश्किल से 0.45% के आसपास है
      हालांकि यह इतना नया है कि उम्मीद है अगली generation के models में इसमें काफ़ी सुधार दिखेगा
    • top-tier models से benchmark बनवाने का विचार पूरी तरह absurd भी नहीं है
      पुराने model से नए model का interview करवा दें, फिर दोनों या कोई तीसरा judge model तय करे कि कौन ज़्यादा smart है, और seed बदलकर यह 100 बार दोहराएँ
      दोनों पक्षों द्वारा नए model की जीत स्वीकार किए जाने की दर को score बनाया जा सकता है
    • reasoning-heavy benchmarks बेहतर दिशा लगते हैं
      उन्हें game करना सबसे मुश्किल होता है
    • कभी-कभी यह सोचकर हँसी आती है कि क्या AI ऐसी समस्याएँ भी लिख सकता है जिन्हें AI खुद हल न कर सके

  • बेहतर benchmarks में objective scoring, multidisciplinary breadth, और scalability होनी चाहिए, और single-answer format से बचना चाहिए
    https://gertlabs.com पर हमने जो डिज़ाइन किया है, वह broadly उसी दिशा में है, और अधिकतर coding के ज़रिए problem solving से जुड़ा है

    • यह benchmark अब तक देखी गई दूसरी rankings की तुलना में ज़्यादा accurate लगता है
      मेरे अनुभव में gpt 5.4/5.5 तकनीकी रूप से लगभग बेदाग हैं, और जब समस्या आती है तो अक्सर input ambiguity की वजह से
      bug fixes या implementation के दौरान आने वाली समस्याओं से भी ये आम तौर पर खुद निपट लेते हैं, और tasks को बिना ढील दिए पूरा करने की प्रवृत्ति रखते हैं
      दूसरी ओर Opus तकनीकी क्षमता के लिहाज़ से कुछ ज़्यादा ही overhyped लगता है
      सुंदर UX बनाने में उसका designer/developer sense बेहतर है, लेकिन काम verify करवाने के लिए मैं हमेशा gpt 5.5 पर जाता हूँ
      सबसे चौंकाने वाला Xiao-Mi का result था; मैंने अभी तक इसे इस्तेमाल नहीं किया है, लेकिन यह देखकर इसे आज़माने का मन हुआ
      इस अव्यवस्थित AI speed race में meaningful baseline देने के लिए टीम को बधाई
    • Claude Code family का C++ और Java में अब भी बाकी models पर साफ़ बढ़त होना दिलचस्प है, जबकि GPT 5.5 Python और JS जैसी भाषाओं में ऊपर दिखता है
      यह training dataset bias या go-to-market focus के फर्क को दिखा सकता है, और शायद यह भी कि Anthropic, OpenAI की तुलना में enterprise customers पर ज़्यादा केंद्रित है
      Opus को C++ में इस्तेमाल करने का मेरा अनुभव भी इससे मेल खाता है
      लेकिन C# results खाली हैं, तो @gertlabs, क्या इसका कोई ETA है?
    • इस benchmark में Deepseek V4 pro का Deepseek V4 flash से भी खराब दिखना काफी दिलचस्प है
      जानना चाहूँगा कि ऐसा क्यों निकला

  • ऐसा होना, organic तरीके से हो या inorganic तरीके से, लगभग तय ही था
    सिस्टम आसानी से इस दिशा में चला जाता है कि बस benchmark score अच्छा दिखना चाहिए, बाहर generalize होता है या नहीं उससे खास फर्क नहीं पड़ता
    इसी तरह के उदाहरण के रूप में Graduate student descent याद आता है
    https://sciencedryad.wordpress.com/2014/01/25/grad-student-d...

  • पीछे मुड़कर देखें तो SWE-bench शायद शुरू से इतना महान भी नहीं था
    2025 भर models के अच्छा code बनाने की दर में वास्तव में लगभग कोई सुधार नहीं हुआ, और यह कहना ज़्यादा सही लगता है कि सिर्फ automated tests pass करने की क्षमता बढ़ी है
    https://entropicthoughts.com/no-swe-bench-improvement

    • यह कहना कि code quality में बिल्कुल भी सुधार नहीं हुआ, मानना मुश्किल है
      जनवरी 2025 में Claude 3.5 Sonnet, Gemini 1.5 Pro, और OpenAI का GPT-4o मुख्य models थे, और उन models तथा आज के frontier models, दोनों को इस्तेमाल करने के बाद मुझे साफ़ लगता है कि आज के models एक बड़े step up हैं
    • इस व्याख्या में काफ़ी सच्चाई हो सकती है
      model quality शायद plateau पर है, और improvement के नए vectors खोजना बिल्कुल आसान नहीं लग रहा
      अब तक progress को धकेलने वाला model width scaling भी अपनी सीमा के करीब दिख रहा है, इसलिए आगे इसके क्या implications होंगे यह देखना दिलचस्प होगा
      लंबे समय में सिर्फ tooling से सुलझाई जा सकने वाली चीज़ों की भी सीमा है
    • फिर भी automated test pass rate का बढ़ना coding productivity के लिए बहुत बड़ा स्रोत है
      Anthropic के कई billion dollar valuation का एक कारण यही भी है
      coding में SWE-bench इसलिए उपयोगी रहा क्योंकि software engineering में automated tests बनाने और इस्तेमाल करने की परंपरा और infrastructure बहुत मजबूत है
    • शायद इसी वजह से आजकल कंपनियों के pricing tiers ज़्यादा restrictive और महँगे होते जा रहे हैं

  • लेख की बात का मतलब मुझे यह लगा कि model जिन 27.6% subset समस्याओं को अक्सर हल नहीं कर पाए, उनका audit किया गया, और उनमें से कम से कम 59.4% में ऐसे defective tests थे जो functionally सही submissions को reject कर रहे थे
    अगर यह सच है, तो लगता है कि इतने समय तक problem और answer key का एक बड़ा हिस्सा ही गलत था, और फिर यह सचमुच वैध measurement कैसे था, यह बड़ा सवाल है
    benchmark बनाने की process का विवरण देखें तो मानक काफ़ी ऊँचे लगते हैं, इसलिए यह समझना और भी मुश्किल है कि इतनी खराब data quality उसके साथ कैसे आई
    यह अच्छी बात है कि उन्होंने समस्या खुद उजागर की, लेकिन सवाल अब भी बहुत हैं

    • इसका मतलब यह नहीं कि पूरे का एक-चौथाई गलत था, बल्कि यह कि 27.6% वाले subset में 59.4% में defective tests थे
      और व्यावहारिक कारणों से benchmark मूल रूप से न तो आपके use case का प्रतिनिधि होता है, न ही सभी use cases का
      वह सिर्फ उन्हीं items को measure कर सकता है जो उसमें शामिल हैं, उससे ज़्यादा नहीं, उससे कम भी नहीं
      public benchmarks के प्रति ecosystem का यह obsession मुझे इसी वजह से समझ नहीं आता
      उदाहरण के लिए, यदि Qwen 3.5 किसी Benchmark X पर Qwen 2.5 से 50% बेहतर है, तो यह लगभग कभी guarantee नहीं देता कि वह मेरे tasks पर भी 50% बेहतर होगा
      मैं अपने private benchmarks लगातार उन failures के आधार पर बनाता रहा हूँ जो models ने वास्तविक उपयोग में दिखाए, और उसी हिसाब से prompts को tweak करता हूँ
      जब नया model update आता है तो मेरे benchmark पर आम तौर पर सिर्फ 2–3% का बदलाव दिखता है, जबकि public benchmarks पर 30–40% jump का प्रचार किया जाता है, इसलिए training data contamination न होने पर भरोसा करना मुश्किल है
    • ImageNet भी दुनिया के सबसे प्रसिद्ध datasets में से एक है, लेकिन उसकी भी काफ़ी images गलत label की गई हैं
      चरम स्थिति में ज़्यादा score पाने के लिए आपको गलत जवाब के हिसाब से align होना पड़ सकता है
      आख़िरकार जवाब यह है कि ML ऐसा क्षेत्र है जो किसी न किसी तरह चल ही पड़ता है, इसलिए flaws होने पर भी यह हैरान कर देने वाली दूर तक जाता है
      और यही वजह है कि जो व्यक्ति ऐसे flaws पकड़ ले जिन्हें दूसरे नहीं देख पाए, वह बड़ा breakthrough कर सकता है
    • अगर उद्देश्य यह तय करना है कि कौन-सा model बेहतर है, तो benchmark score का actual performance से correlated होना ही काफ़ी है
      अगर ज़्यादातर tasks का scoring सही हो, तो overall direction बरकरार रह सकती है
      उदाहरण के लिए, भले किसी बेकार benchmark में 49% labels गलत हों, अगर एक model हमेशा सही जवाब देकर 51% पाता है और दूसरा हमेशा गलत जवाब देकर 49% पाता है, तो ranking फिर भी सही रहेगी
      ज़्यादातर machine learning benchmarks में काफ़ी mislabeled data होता है, लेकिन यदि लक्ष्य models के बीच फर्क करना है, तो perfect scoring सुनिश्चित करने में समय लगाने से अक्सर बड़ा dataset इकट्ठा करना ज़्यादा उपयोगी होता है
    • संक्षेप में कहें तो इसका मतलब लगभग 16% समस्याओं में दिक्कत है