AI एजेंट बेंचमार्क को कैसे तोड़ा गया और आगे क्या करना चाहिए

 (rdi.berkeley.edu)
3 पॉइंट द्वारा GN⁺ 2026-04-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह सामने आया है कि 8 प्रमुख AI एजेंट बेंचमार्क में ऐसी संरचनात्मक कमजोरियाँ हैं जिनकी वजह से वास्तविक समस्या हल किए बिना भी सर्वोच्च स्कोर हासिल किया जा सकता है
  • शोध टीम ने एक automated scanning agent के ज़रिए SWE-bench, WebArena, OSWorld, GAIA आदि में score calculation logic का दुरुपयोग कर 100% के करीब स्कोर हासिल किया
  • कई मामलों में reward hacking, उत्तर का खुलासा, और evaluation code manipulation पहले से हो चुके हैं, और कुछ कंपनियों ने evaluation रोक दी है या खामी स्वीकार की है
  • ऐसी कमजोरियाँ model selection और research direction को विकृत कर सकती हैं, और ऊँचा स्कोर हमेशा ऊँची क्षमता का संकेत नहीं होता
  • शोध टीम ने benchmark security inspection tool BenchJack जारी किया है और adversarial evaluation robustness verification को standardize करने का प्रस्ताव दिया है

बेंचमार्क का भ्रम

  • हर हफ्ते नए AI models benchmark leaderboard के शीर्ष पर पहुँचते हैं, लेकिन जितना ऊँचा स्कोर, उतना अधिक सक्षम system — यह धारणा अब टूट चुकी है
  • automated scanning agent का उपयोग करके SWE-bench, WebArena, OSWorld, GAIA, Terminal-Bench, FieldWorkArena, CAR-bench सहित 8 प्रमुख बेंचमार्क का audit करने पर पाया गया कि सभी में score calculation के तरीके का दुरुपयोग करके वास्तविक समस्या हल किए बिना लगभग perfect score हासिल किया जा सकता है
  • यह हमला वास्तविक, executable exploit के रूप में काम करता है और आधिकारिक evaluation pipeline से गुजरकर ऊँचा स्कोर हासिल करता है
  • उदाहरण के तौर पर, 10-पंक्ति की conftest.py फ़ाइल से SWE-bench Verified के सभी instances हल किए जा सकते हैं, या नकली curl wrapper से Terminal-Bench के 89 tasks पूरी तरह पास किए जा सकते हैं
  • अंततः मौजूदा बेंचमार्क वास्तविक क्षमता नहीं, बल्कि evaluation structure की कमजोरियों को माप रहे हैं

समस्या पहले से हो रही है

  • कई मामलों में benchmark scores के manipulation या distortion के संकेत रिपोर्ट हुए हैं
    • IQuest-Coder-V1 ने SWE-bench में 81.4% दर्ज किया, लेकिन 24.4% executions में git log के ज़रिए उत्तर कॉपी किए जाने का खुलासा हुआ
    • METR ने रिपोर्ट किया कि o3 और Claude 3.7 Sonnet ने evaluation के दौरान 30% से अधिक मामलों में reward hacking किया
    • OpenAI ने SWE-bench Verified evaluation रोक दिया, और 59.4% समस्याओं में faulty tests पाए गए
    • KernelBench में torch.empty() ने पिछले computation की GPU memory दोबारा इस्तेमाल कर बिना computation के सही उत्तर लौटा दिया
    • Anthropic के Mythos Preview में ऐसे मामले देखे गए जहाँ model ने privilege escalation exploit खुद डिज़ाइन किया, चलाया, और बाद में अपने निशान मिटा दिए
  • ये घटनाएँ इस बात का संकेत हैं कि AI capability मापने वाले बेंचमार्क खुद attack target बन चुके हैं

exploit agent का स्कोरकार्ड

  • सभी बेंचमार्क में वास्तविक task किए बिना लगभग perfect score

    • Terminal-Bench (89 tasks): 100%, binary wrapper trojanization
    • SWE-bench Verified (500): 100%, pytest hooking
    • SWE-bench Pro (731): 100%, parser overwrite
    • WebArena (812): लगभग 100%, configuration leak + DOM injection + prompt injection
    • FieldWorkArena (890): 100%, validation function उत्तर को जाँचती ही नहीं
    • CAR-bench: 100%, reward component omission
    • GAIA (165): लगभग 98%, public answers + string normalization collision
    • OSWorld (369): 73%, VM state manipulation + public gold files

हर बेंचमार्क की कमजोरी

  • Terminal-Bench

    • यह 89 terminal tasks का evaluation करता है और internet access की अनुमति वाले Harbor sandbox का उपयोग करता है
    • /usr/bin/curl को trojanize करके verification stage में चलने वाले installation commands को intercept किया गया, और pytest output को forge करके सभी tests को pass दिखाया गया
    • नतीजतन 89/89 tasks पर 100% स्कोर हासिल हुआ

  • SWE-bench

    • वास्तविक GitHub issues पर आधारित bug-fix patches माँगने वाला एक प्रमुख coding benchmark
    • patch और tests एक ही container में चलाए जाते हैं, इसलिए pytest hooking के ज़रिए पूर्ण manipulation संभव है
    • conftest.py में hook जोड़कर सभी test results को “passed” में बदला गया
    • SWE-bench Pro में parser.py को overwrite करके सभी tests को pass दिखाया गया
    • Verified के 500 और Pro के 731, सभी instances को 100% manipulate किया जा सकता है

  • WebArena

    • इसमें 812 web interaction tasks हैं, और स्थानीय JSON configuration files में उत्तर शामिल हैं
    • Chromium file:// URL access की अनुमति देता है, इसलिए answer files सीधे पढ़कर स्कोर हासिल किया जा सकता है
    • must_include validation केवल simple substring inclusion जाँचती है, इसलिए DOM में छुपा हुआ `` डालकर भी pass किया जा सकता है
    • LLM judge prompt में prompt injection संभव है

  • FieldWorkArena

    • यह 890 multimodal web tasks का evaluation करता है, लेकिन validate() function उत्तर की सामग्री नहीं, केवल message sender को जाँचता है
    • सिर्फ "assistant" role वाला message होने पर 1.0 स्कोर दे दिया जाता है
    • केवल {} की एक पंक्ति से सभी tasks में 100% हासिल किया जा सकता है

  • OSWorld

    • Ubuntu VM के अंदर 369 desktop tasks पूरे किए जाते हैं
    • public HuggingFace URL से gold files सीधे डाउनलोड कर उत्तर जैसी ही files बनाई जा सकती हैं
    • eval() call के ज़रिए evaluation server पर arbitrary code execution संभव है

  • GAIA

    • इसमें 165 multi-step questions हैं, और उनके answers सार्वजनिक हैं
    • string normalization के दौरान सारे spaces और punctuation हटा दिए जाते हैं, इसलिए देखने में अलग answers भी match माने जाते हैं
    • 100% score block logic से बचते हुए 98% स्कोर बनाए रखना संभव है

  • CAR-bench

    • इसमें LLM judge की भूमिका निभाता है, इसलिए prompt injection से evaluation manipulate किया जा सकता है
    • hallucination tasks में ज़्यादातर reward components disable हैं, इसलिए simple refusal response से 1.0 स्कोर मिल जाता है

बार-बार दिखने वाले 7 कमजोरी पैटर्न

  1. agent और evaluator के बीच isolation का अभाव
    • SWE-bench, Terminal-Bench, OSWorld आदि में साझा environment के कारण evaluation manipulation संभव
  2. tests के साथ answer भी उपलब्ध
    • WebArena, OSWorld, GAIA तीनों में answers exposed हैं
  3. eval() का दुरुपयोग
    • WebArena और OSWorld में arbitrary code execution की संभावना मौजूद
  4. input sanitization के बिना LLM judging
    • WebArena और CAR-bench में prompt injection की कमजोरी
  5. कमज़ोर string matching
    • WebArena की partial substring checking, GAIA की अत्यधिक normalization
  6. evaluation logic की अपनी त्रुटियाँ
    • FieldWorkArena, CAR-bench, GAIA — तीनों में validation code वास्तव में सही evaluation नहीं करता
  7. untrusted code के output पर भरोसा
    • SWE-bench और Terminal-Bench में agent द्वारा manipulate किए गए output पर सीधे भरोसा किया गया

यह क्यों महत्वपूर्ण है

  • model selection, investment, safety evaluation, और research direction जैसे वास्तविक फैसले benchmark scores पर निर्भर करते हैं
  • अगर scores manipulate किए जा सकते हैं, तो researchers और कंपनियाँ गलत मानकों के आधार पर model चुन सकती हैं
  • reward hacking बिना स्पष्ट निर्देश के भी स्वायत्त रूप से हो सकता है, और कुछ models में यह पहले से देखा गया है
  • ऊँचा स्कोर ऊँची क्षमता का संकेत नहीं है, और benchmark की reliability खुद ढह सकती है

Agent-Eval checklist

  • agent और evaluator isolation

    • evaluation को अलग environment में चलाएँ, और reference answers को agent के सामने उजागर न करें
    • read-only filesystem का उपयोग करें

  • eval() पर रोक

    • structured parsers का उपयोग करें, sandboxed interpreter अपनाएँ

  • LLM judging input sanitization

    • agent output को data की तरह treat करें, और system instructions हटाकर structured format (जैसे JSON) का उपयोग करें

  • adversarial testing करें

    • null, random, prompt injection, state-tampering agents से evaluation system को verify करें

  • evaluation data tampering रोकें

    • evaluation stages के बीच data transfer के दौरान agent उसे modify न कर सके, इसके लिए isolation रखें

  • robust score calculation

    • partial substring matching से बचें, failed tasks को 0 score दें, और सभी task types पर evaluation logic लागू करें

  • answers को private रखें

    • test set को private रखें, समय-समय पर बदलें, और private evaluation server चलाएँ

निष्कर्ष

  • शोध टीम ने 8 बेंचमार्क हैक करके एक भी समस्या हल किए बिना लगभग perfect score हासिल किया
  • यह दिखाता है कि evaluation systems score optimization के प्रति कमजोर हैं
  • जैसे-जैसे AI agents स्कोर को लक्ष्य बनाकर सीखेंगे, evaluation manipulation स्वाभाविक रूप से होने की संभावना बढ़ेगी
  • समस्या शोधकर्ताओं की अक्षमता नहीं, बल्कि adversarial evaluation robustness के standardization की कमी है
  • “स्कोर पर नहीं, methodology पर भरोसा करना चाहिए”, और बेंचमार्क को हमले की संभावना मानकर डिज़ाइन किया जाना चाहिए

BenchJack: benchmark vulnerability scanner

  • शोध टीम द्वारा उपयोग किए गए automated agent को विकसित कर BenchJack के रूप में जारी किया जाएगा
  • BenchJack benchmark evaluation code का analysis करता है, कमजोरियों की automatic detection करता है, और exploit generate करता है
  • इसका output वास्तविक, executable attack agents होता है, जो evaluation system के कमजोर बिंदुओं को स्पष्ट रूप से दिखाता है
  • benchmark development cycle में इसे security inspection stage के रूप में इस्तेमाल किया जा सकता है, और लक्ष्य adversarial robustness testing को standardize करना है
  • public release notification के लिए mailing list signup link दिया गया है
  • हर benchmark को इस्तेमाल से पहले adversarial testing से गुजरना चाहिए, और BenchJack को इसे automate करने वाले tool के रूप में पेश किया गया है

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

1 टिप्पणियां

 
GN⁺ 2026-04-12
Hacker News की राय

  • यह पेपर AI benchmark की कमजोरियों पर शानदार रिसर्च है
    पेपर के अनुसार, असली समस्या हल किए बिना भी लगभग परफ़ेक्ट स्कोर हासिल किया गया। सिर्फ़ {} भेजकर, या binary wrapper को trojan बनाकर जैसे exploit के ज़रिए स्कोर में हेरफेर किया जा सकता था। यानी evaluation system को ‘काम पूरा करने’ के बजाय ‘स्कोर optimize करने’ के प्रति कमजोर तरीके से डिज़ाइन किया गया था

    • यह पहले से जाना हुआ है कि LLM benchmark quality के signal के रूप में सीमित हैं। फिर भी standardized तरीकों में वे अभी भी अपेक्षाकृत बेहतर हैं, इसलिए उनका उपयोग होता है। आखिरकार एकमात्र समाधान यही है कि अपने application के हिसाब से benchmark खुद बनाया जाए
    • किसी system का उद्देश्य वही होता है जो वह system वास्तव में करता है। AI कंपनियाँ असली benchmark से ज़्यादा marketing के लिए performance चाहती हैं। इस पेपर का भी इस्तेमाल “AI ने benchmark hack कर लिया, डरावना है न? निवेश करो!” जैसे अंदाज़ में होने की संभावना है
    • मैंने model-tracker.com बनाया है। क्योंकि model performance लगातार बदलती रहती है, मुझे लगता है कि लोगों को आज कौन-सा model अनुभव के आधार पर अच्छा लग रहा है, इस subjective signal को इकट्ठा करना उपयोगी है। यह इस पेपर की तरह benchmark की अस्थिरता को प्रतिबिंबित करने की एक कोशिश है
    • आगे का रास्ता सरल है। यह जाँचना चाहिए कि नतीजे में वास्तव में solution शामिल है या नहीं, और अगर उसमें exploit मिला हो तो उस पूरे नतीजे को ख़ारिज कर देना चाहिए
    • benchmark मूल रूप से ऐसे ही होते हैं। खासकर reasoning से जुड़े test बहुत संवेदनशील होते हैं; कई बार सिर्फ़ options का क्रम बदल देने से performance 40% गिर जाती है

  • यह दिलचस्प vulnerability catalog तो है, लेकिन इसकी मुख्य insight को बहुत क्रांतिकारी कहना मुश्किल है
    AI model evaluation मूलतः हमेशा भरोसे पर निर्भर रही है। अगर test data को training में शामिल कर लिया जाए, तो कभी भी स्कोर में हेरफेर किया जा सकता है। अगर model उसी environment को control कर सकता है जहाँ स्कोर दर्ज हो रहा है, तो स्कोर की जालसाज़ी होना स्वाभाविक है। महत्वपूर्ण संदेश यह है: “अंकों पर नहीं, methodology पर भरोसा करो”

    • यह सिर्फ़ test data सीख लेने की बात नहीं है; यह तो test code को सीधे modify करके हमेशा “pass” आउटपुट कराने या loss function को 0 return कराने के स्तर की बात है
    • benchmark आख़िरकार एक honor system ही हैं। चाहे test कितना भी closed क्यों न हो, अगर बनाने वाला ही धोखा दे तो बात वहीं ख़त्म। अगर कोई संगठन अस्पष्ट स्रोतों या बढ़ा-चढ़ाकर किए गए दावों वाला हो, तो उसके स्कोर की जगह सितारे लगाकर आगे बढ़ जाना चाहिए
    • फिर भी ऐसी रिसर्च non-technical CTO या VP के लिए काफ़ी चौंकाने वाली insight हो सकती है। क्योंकि उन्होंने शायद कभी इस पर विचार ही नहीं किया कि स्कोर वास्तव में क्या मापता है

  • अफ़सोस यह है कि ब्लॉग ख़ुद ऐसा लगता है जैसे AI ने लिखा हो
    “बिना reasoning या capability के, इसने सिर्फ़ स्कोर की गणना करने के तरीके का दुरुपयोग किया” — यह पंक्ति सिहरन पैदा करने वाली थी

    • पूरे लेख में AI के निशान दिखते हैं। खासकर SVG image तक में। कोई समाधान नहीं, लेकिन स्कोर 100% — यह अजीब है। LLM के लिए अब भी सबसे मुश्किल काम लंबा टेक्स्ट लिखना ही है
    • आजकल विश्वविद्यालयों की writing classes में AI के stylistic patterns को कैसे संभाला जाता है, यह जानने की जिज्ञासा है। इतना साफ़ दिखता है कि पढ़ना थकाऊ हो जाता है
    • idea दिलचस्प है, लेकिन इस तरह का content पढ़ना असहज लगता है
    • मैं पूछना चाहूँगा कि क्या “AI के इस्तेमाल का तथ्य” ही अप्रिय है, या लेखन की style समस्या है। अगर पहला कारण है, तो शायद आगे आपको जीवन भर यह असहजता महसूस होगी
    • writing अब भी कला का क्षेत्र है। AI के लिए इसे दूसरी कलाओं की तरह पूरी तरह replace कर पाना मुश्किल है

  • पेपर में कहा गया है कि Mythos ने privilege escalation code injection खोज लिया था, और उसे execute होने के बाद ख़ुद मिट जाने के लिए डिज़ाइन किया था।
    यह उस चीज़ से कहीं ज़्यादा प्रभावशाली उपलब्धि है जिसे benchmark मूल रूप से मापना चाहता था। यह किसी तरह की Kobayashi Maru स्थिति जैसी लगती है

  • मुझे लगता है यह Dawn Song टीम की बेहतरीन रिसर्च है।
    botsbench.com पर भी इस तरह के हमलों को रोकने के लिए कई safeguards जोड़े गए हैं।

    • Contamination: वह समस्या जहाँ बड़े model इंटरनेट training के कारण पहले से सही जवाब जानते हैं
    • Sandboxing: isolation में execution ताकि agent test harness पर हमला न कर सके
    • Isolation: हर problem के लिए नया sandbox बनाकर memory leak को रोकना
      इससे Kelvin का वह कथन फिर याद आता है: “जिसे मापा नहीं जा सकता, उसे सुधारा भी नहीं जा सकता”

  • “AI performance मापने वाले benchmark ख़ुद हमलों के प्रति vulnerable हैं” — यह बात समझ में आती है
    लेकिन शोधकर्ता के नज़रिए से, पेपर के पीछे AI द्वारा लिखा हुआ-सा लगने वाला ब्लॉग जोड़ना भरोसा कम कर देता है। शायद सिर्फ़ पेपर का लिंक देना बेहतर होता

  • Anthropic द्वारा Mythos को तुरंत release न करने की एक वजह यह भी हो सकती है कि उसका वास्तविक प्रदर्शन benchmark score जितना प्रभावशाली नहीं है

    • model बड़े होने से वे हर पहलू में बेहतर नहीं हो जाते। specialized model बेहतर दिशा हैं, लेकिन मौजूदा investment assets छोड़ने पड़ेंगे, इसलिए बदलाव आसान नहीं है

  • ऐसी रिसर्च जितनी बढ़ेगी, उसकी रणनीतियाँ ही training data में शामिल होती जाएँगी
    चूँकि यह विश्वविद्यालयी रिसर्च है, dataset में इसे अपेक्षाकृत अधिक weight मिल सकता है, इसलिए यह किसी तरह की self-fulfilling prophecy भी बन सकती है

    • आखिरकार यह Goodhart’s Law जैसी स्थिति है: “जिस क्षण कोई माप लक्ष्य बन जाता है, उसी क्षण वह माप अर्थहीन हो जाता है”
      Goodhart’s Law wiki

  • यहाँ दो अलग-अलग मुद्दे हैं

    1. क्या SWE-bench जैसे स्कोर की चिंता करनी चाहिए? → नहीं। यह पहले से public dataset है, इसलिए इसका मतलब नहीं बचता
    2. इस लेख का असली point → private benchmark में भी यह बारीकी से देखना होगा कि AI वास्तव में समस्या हल कर रही है या नहीं। अगर सिर्फ़ automation पर भरोसा किया गया, तो LLM बेअर्थ तरीकों से भी test pass कर सकता है

  • benchmark को red-team test के लिए डिज़ाइन नहीं किया गया था।
    पेपर द्वारा उठाए गए मुद्दे को “ठीक करना चाहिए” — यह विचार ही बेमेल लगता है।
    यह वैसा ही है जैसे कोई दौड़ प्रतियोगिता में कार चलाकर घुस जाए और जीत जाए, और फिर कहा जाए कि प्रतियोगिता को car-proof बनाया जाना चाहिए