SlopCodeBench पर Opus 5 का बेंचमार्किंग

मूल लेख ↗ Hacker News चर्चा ↗

SlopCodeBench के बेंचमार्क परिणाम संकेत देते हैं कि Anthropic का नया Claude Opus 5 बहु-चरणीय कोडिंग कार्यों में Opus 4.x पर केवल मामूली बढ़त देता है, जबकि अक्सर अधिक जटिल, “sloppier” कोड बनाता है। टिप्पणीकारों का तर्क है कि मौजूदा LLM अभी भी लंबे समय की अनुरक्षणीयता, refactoring, और अनावश्यक abstractions से बचने में संघर्ष करते हैं, और कि harness डिज़ाइन और prompts, underlying model जितने ही महत्वपूर्ण हो सकते हैं। कई लोग बेहतर बेंचमार्क, human baselines, और ऐसे RL signals की मांग करते हैं जो स्पष्ट रूप से सरलता और code health को पुरस्कृत करें, खासकर जब कुछ डेवलपर जटिल, लंबे काम के लिए पुराने मॉडलों या Anthropic के Fable को प्राथमिकता देना रिपोर्ट करते हैं.

Opus 5 बनाम पहले के मॉडलों पर समग्र प्रतिक्रिया

  • कई लोगों का कहना है कि Opus 5, Opus 4.8 की तुलना में बस थोड़ा-सा बेहतर लगता है, कोई “wow” वाला उछाल नहीं।
  • कुछ लोग 4.8 के व्यवहार और टोन को अधिक पसंद करते हैं; Opus 5 को आत्मविश्वासी, शब्दबहुल और पांडित्यपूर्ण बताया गया है, जो “slop” और पेडैंटिक रिव्यू बनाता है।
  • एक छोटा वर्ग वास्तविक उत्पादकता लाभ की रिपोर्ट करता है, खासकर जब Opus 5 medium को 4.8 x-high के तेज़, सस्ते विकल्प के रूप में इस्तेमाल किया जाए, और सबसे कठिन कामों के लिए Fable को रखा जाए।

SlopCodeBench और कोड की अनुरक्षणीयता

  • SlopCodeBench की सराहना एक दुर्लभ बेंचमार्क के रूप में की गई है जो अनुदैर्ध्य व्यवहार का परीक्षण करता है: कई फ़ीचर जोड़ और समय के साथ कोड की गुणवत्ता कैसे बदलती है।
  • Opus 5 की लगभग 24% strict pass rate बनाम Opus 4.6 की लगभग 17% दर का उल्लेख किया गया; कुछ लोग इसे मामूली लेकिन वास्तविक सुधार मानते हैं, जबकि अन्य इसे अभी भी अस्वीकार्य रूप से कम मानते हैं।
  • मुख्य चिंता: मॉडल समय के साथ बहुत सारे फ़ंक्शन और जटिलता जोड़ देते हैं; मौजूदा RL/बेंचमार्क शायद ही कभी जटिलता को दंडित करते हैं, इसलिए मॉडल सरल बनाने के लिए नहीं सीखते।

हैर्नेस, प्रॉम्प्ट, और एजेंट वर्कफ़्लो

  • कई लोगों का तर्क है कि “slop” अक्सर हैर्नेस/सिस्टम-प्रॉम्प्ट की समस्या है: बहुत अधिक स्वतंत्रता वाले और कहाँ संपादन करना है इस पर बिना बाधाओं वाले एजेंट गड़बड़ियाँ जमा कर देते हैं।
  • स्थिर “skills” या टेम्पलेटेड वर्कफ़्लो कभी-कभी SlopCodeBench पर प्रदर्शन को नुकसान पहुँचाते हैं, संभवतः क्योंकि वे संदर्भ बर्बाद करते हैं और greenfield कार्यों पर उप-इष्टतम वर्कफ़्लो थोपते हैं।
  • दूसरों ने इनमें सफलता की रिपोर्ट की है:
    • संपादनों को संकीर्ण seams तक सीमित करना।
    • समय-समय पर समर्पित “refactor turns” या पूरे कोडबेस की समीक्षा पास।
    • प्रोजेक्ट कॉन्फ़िगरेशन फ़ाइलों में सरलता और DRY code को प्राथमिकता देने वाले स्पष्ट निर्देश।

मॉडल व्यवहार, गिरावट, और बेंचमार्किंग

  • कुछ उपयोगकर्ताओं को लगता है कि मॉडल (Fable सहित) लॉन्च के बाद खराब होते जाते हैं, संभवतः quantization जैसी लागत-प्रेरित बदलावों के कारण; अन्य सार्वजनिक ट्रैकर्स का हवाला देते हैं जो ज़्यादातर एकदिशीय सुधार दिखाते हैं।
  • चिंता है कि लैब्स बेंचमार्क-जैसे इनपुट के लिए विशेष-case कर सकती हैं, जिससे सार्वजनिक बेंचमार्क कम विश्वसनीय हो जाते हैं।
  • प्रतिभागी अधिक मजबूत eval suites की मांग करते हैं (जिसमें अनुरक्षणीयता मीट्रिक्स शामिल हों) और नोट करते हैं कि अधिकांश टीमों के पास इन्हें बनाने की विशेषज्ञता नहीं होती।

क्या “slop” सच में मायने रखता है?

  • एक थ्रेड पूछता है कि यदि दोष कम रहें और क्लाइंट खुश हों, तो क्या कुरूपता/जटिलता मायने रखती है।
  • जवाब इसे सीधे लंबे समय की बदलाव लागत और AI agent दक्षता से जोड़ते हैं: गंदे कोड को इंसानों और मॉडलों, दोनों के लिए संशोधित करना कठिन होता है।
  • हाल की कुछ papers (जिनका उल्लेख है, लेकिन विस्तार नहीं दिया गया) कथित तौर पर पाती हैं कि “cleaner” code agent नेविगेशन और दक्षता को बेहतर बनाता है।