Senior SWE-Bench: सीनियर इंजीनियर-स्तर के एजेंट मूल्यांकन के लिए open source benchmark
(senior-swe-bench.snorkel.ai)- Senior SWE-Bench एक ऐसा benchmark है जो coding agents का मूल्यांकन बहुत ज्यादा साफ-सुथरे junior tasks से नहीं, बल्कि वास्तविक senior engineers द्वारा संभाले जाने वाले feature development, bug fixes और performance issues के करीब जाकर करने की कोशिश करता है
- Feature tasks में natural language messages जैसे पढ़े जाने वाले realistic instructions का इस्तेमाल होता है, और जमा किए गए solutions के अनुसार behavioral tests बनाने वाले validation agent से evaluation reliability बढ़ाई जाती है
- Bug tasks user reports से शुरू होते हैं और उन PRs से लिए जाते हैं जिनमें service execution, logs, profiling data और reproduction steps जैसी runtime investigation की जरूरत होती है
- Score सिर्फ runtime correctness ही नहीं, बल्कि codebase practices पर आधारित quality metrics को जोड़कर tasteful solve का मूल्यांकन करता है; instructions में न लिखी गई महत्वपूर्ण practices भी validation का हिस्सा हो सकती हैं
- Leaderboard का top model Claude Opus 4.8 भी Mini-SWE-Agent max setting में केवल pass@1 24.0% तक पहुंचा, यानी top models भी senior-level correctness और taste वाले solutions में 75% से ज्यादा मामलों में fail होते हैं
वास्तविक PRs के करीब task design
- Senior SWE-Bench एक ऐसा benchmark है जो इस gap को कम करना चाहता है कि coding agents असल में senior engineers की तरह इस्तेमाल होते हैं, लेकिन उनका evaluation junior-level tasks जैसा किया जाता है
- Tasks libraries से लेकर multi-service applications तक कई repositories के PRs से लिए जाते हैं, और हर repository में सैकड़ों commits लिख चुके engineers द्वारा बनाए गए PRs को target करते हैं
- मुख्य task types दो हिस्सों में बंटते हैं
- कई steps और कई stacks में फैले feature PRs
- जिनमें काफी runtime investigation की जरूरत पड़ी थी, ऐसे bug और performance PRs
- Public tasks 50 हैं, और private tasks भी 50 हैं
- शामिल repositories के उदाहरण इस प्रकार हैं
- posthog 8
- electric 6
- gitea 6
- better-auth 4
- harbor 4
- इनके अलावा 7 repositories
Feature tasks: natural language के करीब instructions
- Feature tasks बहुत ज्यादा broken-down requirements के बजाय natural language messages जैसे पढ़े जाने वाले realistic instructions का इस्तेमाल करते हैं
- ऐसे tasks का stable evaluation करने के लिए validation agent पेश किया गया है
- Expert-designed recipes का इस्तेमाल करता है
- Submitted solution के अनुसार behavioral tests लिखता है
- Instructions natural agent communication को दर्शाते हैं, और उनकी median length SWE-Bench Pro की 31% के स्तर पर है
Bug tasks: user reports से runtime investigation तक
- Bug tasks मुश्किल user reports को reflect करते हैं, इसलिए simple code changes की तुलना में root-cause investigation और reproduction process की ज्यादा मांग करते हैं
- Tasks में इस तरह के काम शामिल हो सकते हैं
- Service start करना
- सूक्ष्म runtime issues debug करना
- Logs check करना
- Profiling data का उपयोग करना
- Reproduction steps trace करना
- Source वे PRs हैं जिनके solution process में काफी runtime investigation की जरूरत पड़ी थी
Evaluation criteria: correctness और taste दोनों को मापना
- Senior SWE-Bench runtime correctness tests और कई quality metrics को जोड़कर tasteful solve को score करता है
- Quality metrics observed codebase practices पर आधारित हैं
- Verifiers और validation agent instructions में न लिखे होने पर भी codebase में महत्वपूर्ण practices को test कर सकते हैं
- Leaderboard की solve condition में ये items शामिल हैं
- Verifiers pass
- Validation pass
- Rubric > 0.5
- Bloat < 2×
- Practice > 2/5
- Rel. taste > 2/5
Leaderboard: top models का भी pass@1 कम
- Leaderboard results को Tasteful solve rate(pass@1) के आधार पर दिखाता है
- Top results इस प्रकार हैं
- Claude Opus 4.8, Mini-SWE-Agent max: 24.0%
- Claude Sonnet 5, Mini-SWE-Agent max: 19.4%
- GPT-5.5, Mini-SWE-Agent xhigh: 16.0%
- Claude Opus 4.7, Mini-SWE-Agent max: 14.1%
- GPT-5.4, Mini-SWE-Agent xhigh: 14.0%
- GLM-5.2, Mini-SWE-Agent max: 12.5%
- Kimi K2.6, Mini-SWE-Agent default: 8.2%
- Claude Sonnet 4.6, Mini-SWE-Agent high: 8.2%
- Gemini 3.1 Pro, Mini-SWE-Agent high: 6.1%
- Gemini 3.5 Flash, Mini-SWE-Agent medium: 3.0%
- सबसे मजबूत frontier models भी senior-level correctness और taste वाले tasks को 75% से ज्यादा मामलों में पूरा नहीं कर पाते
Task scope और benchmark की विशेषताएं
- Task types को feature, bug, perf, migrat के रूप में दिखाया गया है
- Stacks में Py Svc, Elixir, Go, SQL, TS Lib, Py Lib, Rust, TS FE आदि शामिल हैं
- Feature tasks कई services में फैल सकते हैं, और प्रति task औसतन 11 files को touch करते हैं
- इन्हें लंबे workflows की मांग करने के लिए design किया गया है, इसलिए सबसे मजबूत agents को भी सैकड़ों steps की जरूरत पड़ती है
- Reference solutions की SLOC और file count तीनों benchmarks में एक ही तरीके से मापी जाती है
- Instruction length में harness boilerplate शामिल नहीं है
- दूसरे benchmarks के token count और step count हर benchmark के self-reported metrics पर आधारित हैं
1 टिप्पणियां
Hacker News की राय
Twitter पर देखा था कि Tsinghua University की मशीन लर्निंग क्लास में छात्रों को ऐसे क्विज़ बनाने की परीक्षा दी गई थी जिनमें जितने ज़्यादा LLM फेल हों उतना अच्छा
सोचता हूँ, अगर इस तरह के बेंचमार्क बनाए जाएँ और उन पर ELO स्कोर लगाया जाए तो कैसा रहेगा। मॉडल एक-दूसरे के खिलाफ सवाल, बग, और अधूरे implementation पेश करें, और दूसरा उन्हें जवाब दे, ठीक करे, या पूरा करे
https://en.wikipedia.org/wiki/Generative_adversarial_network
क्लास में कम से कम यह नियम रखा जा सकता है कि कम-से-कम एक LLM जवाब दे सके, लेकिन one-on-one मुकाबले में इसे कैसे सुलझाया जाए, समझ नहीं आता
सोच रहा हूँ कि यह बेंचमार्क समय के साथ relevance कैसे बनाए रखेगा
अगर बेंचमार्क open source projects में feature implementation पर आधारित है, तो LLM के training data में उन बदलावों का समावेश हो सकता है, और वह वैसा ही या थोड़ा बदला हुआ जवाब दे सकता है
दूसरी तरफ, अगर benchmark में केवल model के knowledge cutoff के बाद हुए code changes ही डाले जाएँ, तो समय T और T+1 की समस्याएँ अलग हो जाएँगी, जिससे समय के साथ तुलना करना कठिन हो जाएगा
अगर यह Staff SWE Bench होता, तो शायद LLM पहले यही पूछता कि उसे यह काम करना भी चाहिए या नहीं, पूरे project पर सवाल उठाता, code merge से मना करता, लेकिन delete करने में खुशी-खुशी आगे आता
LLM भी यह काम अच्छी तरह, शायद हमसे बेहतर कर सकता है, लेकिन इसके लिए उसे अलग से train करना पड़ेगा। बस यह समझ नहीं आता कि ऐसा training data कहाँ से मिलेगा
तो शायद यही वजह है कि मुझे हमेशा लगता था कि Opus 4.8 GPT 5.5 से काफी आगे है। अधूरे requirements लेकर project के हिसाब से समझदारी से gaps भरने की उसकी क्षमता सच में अच्छी है
मुझे लगता है कि दोनों evaluation approaches model को इतनी मजबूती से प्रेरित नहीं करते कि वह हर assumption पर सवाल उठाए और प्रश्न करे। शायद इसलिए कि users को यह झंझट लगे, लेकिन मुझे यह चरण लगभग अनिवार्य लगता है
GPT-5 family बहुत बारीक़ और thorough रही है, इसलिए code review और math में उपयोगी लगी। मेरे काम में यह महत्वपूर्ण है, लेकिन “aesthetic” code के लिए कभी-कभी बाधा बनती है। जैसे कम संभावना वाले edge cases तक सब कुछ defend करने की कोशिश करना
flexibility और instruction-following के बीच भी शायद एक trade-off है। मेरे अनुभव में Opus कभी-कभी निर्देशों को नज़रअंदाज़ करता है लेकिन gaps बेहतर भरता है, जबकि GPT-5.5 निर्देश बेहतर मानता है लेकिन उसी अनुपात में अधिक rigid हो जाता है
मेरे अनुभव में Opus ज़बरदस्त बढ़त पर नहीं था, या ज़रूरी नहीं कि बेहतर ही हो। वैसे भी GPT 5.5 में Instant, Medium, High, Extra High, और Pro हैं, और तालिका में तुलना Extra High से की हुई लगती है, तो क्या Pro से तुलना नहीं होनी चाहिए?
frontend development और design जैसे कुछ खास काम हैं जहाँ Opus बेहतर लगता है, लेकिन उसके अलावा 5.5 बस पूरी तरह हावी है
4.8 को भी एक से ज़्यादा prompt की ज़रूरत पड़ सकती है, लेकिन output quality बहुत बेहतर होती है और वह ज़्यादा insights देता है
हालाँकि Fable 5 तो एक अलग ही चीज़ है
अभी highest solve rate, Opus 4.8 के आधार पर, 24% है — तो एक सक्षम इंसान को लगभग कितना score मिलना चाहिए?
दूसरी ओर, अगर model इंसान को अपनी मर्ज़ी से चला सके, तो क्या वह और ऊँचा score लेगा, यह भी सोचने वाली बात है
मुझे लगता है कि product work से परिचित व्यक्ति से तुलना करना उचित है
Fable कैसा निकलेगा, यह देखने में ज़्यादा दिलचस्पी है
senior role की असली क़ीमत यह है कि वह ज्ञात solutions और strategies को नई समस्याओं पर लागू कर सके। पता नहीं ऐसा benchmark जो कभी बदलता ही नहीं, कितने समय तक नई चुनौती बना रह सकता है
अगर अच्छा benchmark बनाना है, तो पहले TRIZ का पूरा उपयोग करके समस्याओं का एक बहुत बड़ा समूह बनाना चाहिए, फिर देखना चाहिए कि AI उसमें से optimal solution निकाल पाता है या नहीं
Snorkel की तरफ़ से नया public benchmark आया, यह देखकर अच्छा लगा। वहाँ काफ़ी sophisticated काम हो रहा है
यह दिलचस्प है कि Sonnet 5 Opus 4.8 के काफ़ी क़रीब आता दिख रहा है
अगर यह तरीका काम करता है, तो क्या इसका मतलब यह नहीं कि technical interview भी automate किए जा सकते हैं?
“You are a senior SWE-Bench reviewer, make no mistakes.” जैसे prompt से LLM से subjective judgment करवाने का तरीका बुनियादी रूप से दोषपूर्ण लगता है
व्यवहारिकता बनाए रखते हुए इससे बेहतर तरीका क्या हो सकता है, यह समझ नहीं आता
system prompt में यह आम बात है और यह response का frame तय करता है
उदाहरण के लिए, अगर आप कहें “programming पर sea shanty लिखने वाला pirate”, “physics article लिखने वाला news reporter”, या “PostgreSQL को पूरी तरह जानने वाला senior software engineer”, तो अलग-अलग responses मिलेंगे
पहले मामले में शायद Wellerman-शैली का “There once was a program that was set to C ...” जैसा जवाब आ सकता है
हालाँकि “make no mistakes” वाला हिस्सा संदिग्ध लगता है। अगर इस वाक्य के साथ और बिना इसके results की तुलना की जाए, और वही वांछित behavior पाने के दूसरे तरीक़े भी आज़माए जाएँ, तो दिलचस्प होगा
बेशक, ऐसा कोई दिखता नहीं जो इस तरह की comparative measurement को सार्वजनिक रूप से चलाकर किसी तर्कसंगत निष्कर्ष तक पहुँचने में मदद करे