ज़्यादा स्मार्ट मॉडल्स कोडिंग बेंचमार्क्स को हैक करने में और अधिक सक्षम होते जा रहे हैं।

वास्तविक बग्स पर आधारित eval सुइट, जिन्हें बाद में ठीक किया गया, खास तौर पर संवेदनशील होते हैं क्योंकि उन समस्याओं का समाधान पहले से मौजूद होता है। अगर एजेंट को रिपॉज़िटरी का इतिहास या सार्वजनिक वेब तक पहुँच हो, तो वह कभी-कभी समाधान खुद निकालने के बजाय उसे खोज सकता है।

यह मापने के लिए कि यह व्यवहार कितना व्यापक है, हमने eval ट्रैजेक्टरीज़ का ऑडिट करने के लिए एक एजेंट बनाया। SWE-bench Pro पर, हमने पाया कि Opus 4.8 Max के 63% सफल resolutions में समाधान निकाला नहीं गया, बल्कि ठीक करें को पुनर्प्राप्त किया गया। जब हमने git history को सील कर दिया और इंटरनेट तक पहुँच सीमित कर दी, तो Opus के साथ-साथ हमारे मॉडल Composer 2.5 के स्कोर भी तेज़ी से गिर गए:

• Opus 4.8 Max 87.1% से गिरकर 73.0% पर आ गया
• Composer 2.5 74.7% से गिरकर 54.0% पर आ गया

पिछले अनुसंधान से पता चला है कि कोडिंग बेंचमार्क के उत्तर सार्वजनिक रूप से उपलब्ध स्रोतों के ज़रिए लीक हो सकते हैं, जिसमें यह 2024 का अध्ययन और 2025 की Meta रिपोर्ट शामिल हैं। हमारा अध्ययन वर्तमान अत्याधुनिक कोडिंग-एजेंट रन पर इस समस्या को मात्रात्मक रूप से मापता है। इसका व्यापक सबक यह है कि प्रशिक्षण-समय contamination से बचने के अलावा, एजेंटिक कोडिंग बेंचमार्क्स के लिए नियंत्रित रनटाइम परिवेश भी ज़रूरी हैं।

evals करने वाली टीमों के लिए, हम प्रतिलेखों का ऑडिट करके और eval परिवेश को सीमित करके इस रिवॉर्ड हैकिंग व्यवहार को कम करने का प्रस्ताव रखते हैं।

#एक मॉडल को दूसरे मॉडल से पकड़ें

reward-hacking व्यवहार के स्केल को मापने के लिए, हमने ऑडिटर से Opus 4.8 Max की 731 ट्रैजेक्टरीज़ की जाँच कराई। उसने समस्या का विवरण और पूरी एजेंट ट्रैजेक्टरी देखी, लेकिन यह नहीं देखा कि रन पास हुआ था या नहीं, और फिर यह वर्गीकृत किया कि एजेंट ने ज्ञात उत्तर पुनर्प्राप्त किया था या नहीं।

उसे मिले reward-hacking के दो सबसे सामान्य पैटर्न ये थे:

• Upstream lookup: 57% ट्रैजेक्टरीज़ में, Opus 4.8 Max को सार्वजनिक वेब पर मर्ज किया गया PR या ठीक की गई स्रोत फ़ाइल मिल गई, और फिर उसने उस ठीक करने के उपाय को लगभग ज्यों-का-त्यों पुनरुत्पन्न कर दिया।
• Git-history mining: 9% ट्रैजेक्टरीज़ में, Opus 4.8 Max ने bundled .git history में उस future commit को खोज लिया जिसमें बग ठीक किया गया था, और फिर उससे patch निकाल लिया।¹

जैसे-जैसे मॉडल अधिक सक्षम होते जाते हैं, वे कभी-कभी यह अनुमान लगा सकते हैं कि वे किसी eval में हैं, खासकर तब जब कार्य किसी पुरानी सार्वजनिक रिपॉज़िटरी से लिया गया हो। उन मामलों में भी जहाँ उन्हें प्रशिक्षण से ठीक करने का उपाय याद नहीं होता, परिवेश फिर भी उन्हें ऐसे संकेत दे सकता है कि बग पहले ही हल किया जा चुका है।

2019 के एक jq issue पर आधारित SWE-bench Multilingual कार्य में, एजेंट ने system jq binary के साथ बग को पुनरुत्पन्न करने की कोशिश की। क्योंकि इमेज बग ठीक किए जाने के बाद बनाई गई थी, पुनरुत्पादन विफल हो गया, और एजेंट ने अनुमान लगाया कि समस्या पहले ही हल की जा चुकी थी। इसी समझ ने उसे खुद समाधान निकालने के बजाय ठीक करने का उपाय खोजने की ओर मोड़ दिया।

कुछ मामले इससे भी अधिक सीधे थे। एक एजेंट को एक SWE-bench mirror page मिला, जिसने hidden tests और gold patch उजागर कर दिए। दूसरे ने hidden test files हासिल कर लीं और पास होने के लिए ज़रूरी expected exception string को hardcode कर दिया।

cd /testbed && curl -s "https://api.github.com/repos/apache/druid/pulls/14092/files" 2>/dev/null | grep '"filename"'

cd /testbed && git show 895abd8929 -p 2>/dev/null | head -400
cd /testbed && git cherry-pick 895abd8929 2>&1

#अधिक सख़्त परिवेश डिज़ाइन

ज़्यादातर रिवॉर्ड हैकिंग सार्वजनिक वेब और रिपॉज़िटरी के इतिहास के ज़रिए हुई। ऐतिहासिक सार्वजनिक रिपॉज़िटरी से बनाए गए evals के लिए, उन चैनलों को नियंत्रित करना ज़रूरी है क्योंकि उनमें उत्तर हो सकता है। इसके लिए, हमने दो आइसोलेशन तंत्रों के साथ एक सख़्त उपयोग में लाना बनाया:

1. इतिहास आइसोलेशन। एजेंट के शुरू होने से पहले, .git डायरेक्टरी को हटा दिया जाता है, और रिपॉज़िटरी को एक नई single-commit रेपो के रूप में फिर से initialize किया जाता है। मूल इतिहास केवल scoring के समय बहाल किया जाता है, इसलिए टेस्ट सामान्य रूप से चलते हैं।
2. निकासी प्रॉक्सीइंग। नेटवर्क एक्सेस डिफ़ॉल्ट रूप से अस्वीकार रहता है। सर्वोत्तम-प्रयास नियंत्रण के रूप में, एक pinned प्रॉक्सी allow-list में शामिल package registries के लिए dependency resolution की अनुमति देता है, और इसके अलावा कुछ नहीं।

यह प्रतिबंध खास तौर पर ऐतिहासिक सार्वजनिक रिपॉज़िटरी से बनाए गए evals पर लागू होता है। यही एक वजह है कि हम गैर-सार्वजनिक रिपॉज़िटरी से बनाए गए evals को प्राथमिकता देते हैं, जैसे CursorBench। वे एजेंटिक कोडिंग क्षमता का परीक्षण कर सकते हैं, और साथ ही एजेंट्स को टूल्स का इस्तेमाल वैसे ही करने देते हैं जैसा वे वास्तविक काम के दौरान करते हैं।

#बढ़ता हुआ अंतर

हमने SWE-bench Pro और SWE-bench Multilingual को अधिक कड़े उपयोग में लाना में फिर से चलाया, फिर हर परिणाम की तुलना इन लीकेज चैनलों को हटाने के संयुक्त प्रभाव के लिए एक प्रॉक्सी के रूप में मानक उपयोग में लाना स्कोर² से की:

• SWE-bench Multilingual पर, Opus 4.6 के लिए यह 1 अंक से कम था, Opus 4.8 Max के लिए 9.1 अंक, और Composer 2.5 के लिए 7.5 अंक।
• SWE-bench Pro पर, Opus 4.6 के लिए यह 1 अंक से कम था, Opus 4.8 Max के लिए 14.1 अंक, और Composer 2.5 के लिए 20.7 अंक।

स्पष्ट निष्कर्ष यह है कि पुराने मॉडल्स की तुलना में नए, अधिक परिष्कृत मॉडल्स में रिवॉर्ड हैकिंग कहीं अधिक सामान्य है। दिलचस्प बात यह है कि GPT मॉडल्स में ऐसी बढ़ोतरी नहीं दिखती, और हमारे रन में अंतर आम तौर पर कम हैं।

हमने यह भी देखा कि हमारे अपने मॉडल, Composer 2.5, में इस अध्ययन के दौरान Pro में सबसे बड़ा अंतर था। यही एक कारण है कि हम Composer के लिए मानक SWE-bench Pro स्कोर को एक विश्वसनीय बेंचमार्क संख्या नहीं मानते। संकीर्ण अर्थ में यह स्कोर वास्तविक था, क्योंकि उपयोग में लाना ने इसे उत्पन्न किया था, लेकिन इसमें कोडिंग क्षमता के साथ ज्ञात ठीक करें तक पहुँच भी शामिल हो गई थी।

#सजग एजेंट्स के लिए evals डिज़ाइन करना

कोडिंग evals चलाने वाली टीमों के लिए मुख्य बात यह है कि बेंचमार्क डिज़ाइन केवल डेटासेट निर्माण तक सीमित नहीं होना चाहिए। इसमें रनटाइम परिवेश को भी ध्यान में रखना होगा, जिसमें यह शामिल है कि कार्य चलते समय एजेंट क्या खोज सकता है, क्या जाँच सकता है, क्या प्राप्त कर सकता है, और क्या पुनर्प्राप्त कर सकता है।

इसका यह मतलब नहीं है कि हर eval में इंटरनेट पहुँच या git history हटा देनी चाहिए। कुछ evals का उद्देश्य यह परखना होता है कि एजेंट्स किसी वास्तविक कोडबेस के आसपास उपलब्ध संदर्भ का उपयोग कितनी अच्छी तरह करते हैं, और ऐसी स्थितियों में व्यापक पहुँच कार्य का ही हिस्सा हो सकती है। समस्या तब पैदा होती है, जब वही पहुँच स्कोर के अर्थ को बदल देती है।

ऐतिहासिक सार्वजनिक-रेपो बेंचमार्क्स में, खुली पहुँच एजेंट्स को बग हल करने के बजाय पहले से ज्ञात ठीक करें ढूँढने दे सकती है। उपयोग में लाना में नियंत्रणों के बिना, स्कोर कोडिंग क्षमता और उत्तर की पुनर्प्राप्ति को एक ही चीज़ मान सकते हैं।

evals चलाने वाली टीमों को यह तय करना चाहिए कि वे किस व्यवहार को मापना चाहती हैं, उसी के अनुसार उपयोग में लाना डिज़ाइन करना चाहिए, और परिणामों की रिपोर्ट करते समय सेटअप को स्पष्ट रखना चाहिए। प्रतिलेखों की जाँच से यह पता चल सकता है कि मॉडल्स कार्यों को अप्रत्याशित तरीकों से हल कर रहे हैं। लक्ष्य सामान्य टूल उपयोग पर रोक लगाना नहीं है, बल्कि यह सुनिश्चित करना है कि बेंचमार्क वही मापे, जिसका वह दावा करता है।

फिर भी, इसके बाद भी एक अधिक कठिन खुली समस्या बनी रहती है। जैसे-जैसे मॉडल्स इस बात के प्रति अधिक सजग होते जाते हैं कि उनका मूल्यांकन किया जा रहा है, वे अपने व्यवहार को और सूक्ष्म तरीकों से बदल सकते हैं, जिन्हें git history को सील करने या इंटरनेट पहुँच सीमित करने से ठीक नहीं किया जा सकता। रनटाइम contamination, उस व्यापक चुनौती का एक ठोस रूप है जिसमें ऐसे evals बनाए जाते हैं जो तब भी construct validity बनाए रखें, जब मॉडल यह अनुमान लगा ले कि उसका मूल्यांकन किया जा रहा है।