AI सिस्टमों का मूल्यांकन कैसे किया जाता है, इसमें कमज़ोरियों को उजागर करने वाला अध्ययन

 (oii.ox.ac.uk)
4 पॉइंट द्वारा GN⁺ 2025-11-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • दुनिया भर के 42 शोधकर्ताओं की भागीदारी वाले Oxford Internet Institute (OII) के नेतृत्व में किए गए एक बड़े अध्ययन ने पुष्टि की कि large language model (LLM) मूल्यांकन में उपयोग होने वाले benchmarks में वैज्ञानिक कठोरता की कमी है
  • 445 AI benchmarks की समीक्षा में पाया गया कि आधे से अधिक में अवधारणाओं की परिभाषाएँ अस्पष्ट थीं या विश्लेषण के तरीके कमजोर थे, जिससे विश्वसनीय निष्कर्ष निकालना कठिन बनाने वाली संरचना सामने आई
  • समीक्षा किए गए अध्ययनों में सिर्फ 16% ने सांख्यिकीय तरीकों का उपयोग किया, और ‘reasoning’ या ‘harmlessness’ जैसी अमूर्त अवधारणाओं को कई मामलों में स्पष्ट रूप से परिभाषित नहीं किया गया था
  • शोधकर्ताओं ने परिभाषाओं की स्पष्टता, प्रतिनिधिक मूल्यांकन, सांख्यिकीय विश्लेषण को मजबूत करने सहित 8 सुधारात्मक सिफारिशें पेश कीं और इसके लिए Construct Validity Checklist टूल जारी किया
  • AI benchmarks की वैज्ञानिक वैधता सुनिश्चित करना अब AI तकनीक के विकास और नियामकीय विश्वसनीयता का एक केंद्रीय प्रश्न बनकर उभरा है

अध्ययन का अवलोकन

  • यह अध्ययन Oxford Internet Institute (OII) के नेतृत्व में किया गया, जिसमें EPFL, Stanford, TUM, UC Berkeley, Yale सहित प्रमुख संस्थानों ने भाग लिया
  • पेपर का शीर्षक Measuring What Matters: Construct Validity in Large Language Model Benchmarks है, और इसे NeurIPS 2025 में प्रस्तुत किया जाना निर्धारित है
  • अध्ययन ने 445 AI benchmarks की व्यवस्थित समीक्षा कर मूल्यांकन मानकों की वैज्ञानिक वैधता का विश्लेषण किया

प्रमुख निष्कर्ष

  • सांख्यिकीय कठोरता की कमी: समीक्षा किए गए अध्ययनों में सिर्फ 16% ने सांख्यिकीय तुलना की विधियों का उपयोग किया
    • मॉडलों के बीच प्रदर्शन अंतर या श्रेष्ठता के दावे संयोगवश मिले परिणाम होने की संभावना रखते हैं
  • अस्पष्ट या विवादित परिभाषाएँ: लगभग आधे benchmarks ने ‘reasoning’, ‘harmlessness’ जैसी अमूर्त अवधारणाओं को स्पष्ट रूप से परिभाषित नहीं किया
    • स्पष्ट अवधारणा-परिभाषा के अभाव में मूल्यांकन के उद्देश्य और वास्तविक मापन के बीच असंगति पैदा होती है

समस्या के उदाहरण

  • फ़ॉर्मैट नियमों का भ्रम: यदि किसी सरल logic puzzle को हल करते समय उत्तर को जटिल फ़ॉर्मैट में जमा करना जरूरी हो, तो सही उत्तर देने पर भी फ़ॉर्मैट त्रुटि के कारण असफल माना जा सकता है
  • नाज़ुक प्रदर्शन: सरल गणित प्रश्नों में अच्छा प्रदर्शन करने के बावजूद, संख्या या वाक्य संरचना में थोड़ा सा बदलाव होने पर विफल होने के मामले मौजूद हैं
  • बिना आधार के दावे: medical exam के सवालों में ऊँचे अंक मिलने को डॉक्टर-स्तर की विशेषज्ञता समझ लेने की गलतफहमी हो सकती है

सुधार के लिए सिफारिशें

  • शोधकर्ताओं का मानना है कि इन समस्याओं का समाधान संभव है, और उन्होंने psychometrics और medicine क्षेत्र की validation methodology का संदर्भ लेते हुए 8 सिफारिशें दीं
    • परिभाषित करें और अलग करें (Define and isolate) : मापी जाने वाली अवधारणा को स्पष्ट रूप से परिभाषित करें और असंबंधित कारकों को नियंत्रित करें
    • प्रतिनिधिक मूल्यांकन तैयार करें (Build representative evaluations) : वास्तविक वातावरण को प्रतिबिंबित करें और लक्षित कौशल के पूरे दायरे को शामिल करें
    • विश्लेषण और औचित्य को मजबूत करें (Strengthen analysis and justification) : सांख्यिकीय अनिश्चितता की रिपोर्ट करें, error analysis करें, और benchmark की वैधता के समर्थन में तर्क प्रस्तुत करें
  • Construct Validity Checklist के माध्यम से शोधकर्ता, डेवलपर और नियामक संस्थाएँ benchmark डिज़ाइन की वैधता को पहले से जाँच सकती हैं

अध्ययन का महत्व

  • benchmarks AI अनुसंधान की दिशा, मॉडल प्रतिस्पर्धा, नीति और नियामकीय मानदंडों को तय करने वाले प्रमुख उपकरण की तरह काम करते हैं
  • कमजोर वैज्ञानिक आधार वाले benchmarks से AI प्रदर्शन और सुरक्षा के बारे में गलतफहमियाँ पैदा होने का जोखिम है
  • यह अध्ययन AI मूल्यांकन की विश्वसनीयता सुनिश्चित करने के लिए एक अंतरराष्ट्रीय सहयोग मॉडल के रूप में प्रस्तुत किया गया है

अतिरिक्त जानकारी

  • पेपर को 2–7 दिसंबर 2025 के दौरान NeurIPS 2025 में प्रस्तुत किया जाना है
  • अध्ययन को Clarendon Scholarship, ESRC, EPSRC, Meta LLM Evaluation Research Grant सहित कई संस्थानों का समर्थन मिला
  • OII पिछले 25 वर्षों से artificial intelligence, digital platforms, autonomous systems जैसी नई तकनीकों के सामाजिक प्रभावों पर शोध करता आया है

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

1 टिप्पणियां

 
GN⁺ 2025-11-09
Hacker News राय

  • मैं एक रिसर्च लैब में LLM benchmark और human evaluation पर काम करता हूँ
    सच कहूँ तो अभी यह क्षेत्र पूरी तरह वाइल्ड वेस्ट जैसा है। कोई ठोस समाधान नहीं है, और शोधकर्ता भी सिर्फ benchmarking में ही उलझे नहीं रहना चाहते
    आखिरकार product स्तर पर पारंपरिक A/B testing ही सबसे व्यावहारिक तरीका है। क्योंकि इससे direct metrics को बड़े पैमाने पर मापा जा सकता है
    बेशक ‘benchmarketing’ जैसी चीज़ें भी हैं, लेकिन ज़्यादातर लोग सच में अच्छे benchmark बनाना चाहते हैं। बस यह बहुत मुश्किल है, या शायद असंभव

    • मैं एक hyperscaler में platform infra पर काम करता हूँ, और हमारे क्षेत्र के benchmark भी बुरे हाल में हैं
      जबकि measurable metrics साफ़ हैं, फिर भी statistical processing बेहद खराब है। ज़्यादातर लोग सिर्फ averages का फ़र्क देखते हैं, और p-value की गणना पर भी भरोसा नहीं किया जा सकता
      ऊपर से, असली workload performance के साथ correlation भी लगभग नहीं के बराबर है। production experiments में noise इतना ज़्यादा होता है कि नुकसान छूट जाना आसान है
      AI में हालत और भी बदतर है। क्या मापना है वही अस्पष्ट है, और stock price के लिए noise मापने का incentive भी मौजूद है। ऐसे में LLM benchmark का खराब होना स्वाभाविक है
    • A/B testing भी जोखिमभरी है। आखिरकार यह user feedback optimization को परोक्ष रूप से करने जैसा है, और human evaluators को आसानी से manipulate किया जा सकता है
      B सिर्फ ‘लोगों को बेवकूफ़ बनाकर’ भी ज़्यादा score ले सकता है। OpenAI के 4o मामले में यही साफ़ दिखा
    • यह देखकर झटका लगा कि model प्राथमिक स्कूल स्तर के math problems तो हल कर लेता है, लेकिन numbers या sentences थोड़ा-सा बदलते ही गलती कर देता है। आखिर में यह सिर्फ pattern memorization ही है
    • मुझे लगता है कि इससे भी बड़ी समस्या यह है कि tech companies और media इन मुद्दों को पारदर्शी तरीके से सामने नहीं रखते। वे benchmark scores को objective metric की तरह प्रचारित करते हैं
    • मैं भी LLM evaluation करता हूँ, और अगर निंदक नज़रिए से देखूँ तो ज़्यादातर benchmark नकली tasks हैं। क्योंकि उनका वास्तविक use case लगभग नहीं है
      थोड़ा उदार नज़रिए से देखें तो बात यह है कि intelligence itself को benchmark करना मुश्किल है। इंसानों की job fit भी standardized questions से ठीक से नहीं आंकी जा सकती, तो AI के साथ यह और कठिन है

  • मैं TTS(Text-to-Speech) क्षेत्र में काम करता हूँ, और यहाँ की स्थिति LLM से भी ज़्यादा अराजक है
    डेमो तो परफेक्ट लगते हैं, लेकिन सैकड़ों मिनट की generation में volume drift, speed variation, और pronunciation errors लगातार आते रहते हैं
    सबसे बड़ी समस्या यह है कि long-form speech synthesis के लिए कोई standard benchmark नहीं है
    मैंने ऐसे मानदंडों का प्रस्ताव Death of Demo में लिखा है

  • मैंने Humanity’s Last Exam प्रोजेक्ट पर लिखा है
    इसमें दुनिया भर के experts AI models की परीक्षा लेने के लिए कठिन प्रश्न crowdsourcing के ज़रिए जुटाते हैं
    यह दिलचस्प था कि जो सवाल इंसानों के लिए आसान हैं, वे भी AI के लिए अब तक कठिन बने हुए हैं
    आखिरकार मुझे लगता है कि AI learning का भविष्य real world(meatspace) के अनुभव और reasoning annotations पर निर्भर करेगा

    • Mercor और Micro1 जैसी कंपनियाँ पहले ही इस approach से 9-digit annual revenue कमा रही हैं

  • मुझे benchmark SAT score जैसा लगता है। यह perfect prediction नहीं है, लेकिन एक मोटे signal के तौर पर काम का है
    LLM meaningful direction में आगे बढ़ रहे हैं, और benchmark भी कुछ हद तक इसे दिखाते हैं

    • लेकिन human exams के LLM की job performance predict करने की कोई वजह नहीं है। जैसे simple multiplication problems मानव बुद्धि से जुड़े हो सकते हैं, पर कंप्यूटर के लिए वे बेमानी हैं
    • यह कुछ वैसा है जैसे art critic को evaluate करने वाला exam। subjective नतीजों को objectively score करने की कोशिश अपने-आप में विरोधाभासी है
    • “स्पष्ट रूप से प्रगति हुई है” जैसी अभिव्यक्ति मुद्दे को धुंधला करती है। वास्तव में सार्थक प्रगति हुई भी है या नहीं, यही विवाद का विषय है

  • मौजूदा LLM boom में सबसे कमज़ोर कड़ी benchmark है
    models के बीच तुलना लगभग pseudo-scientific स्तर की अव्यवस्था है
    मैं LMArena leaderboard इस्तेमाल करता हूँ, लेकिन models के बीच results में ऐसा फ़र्क आता है जिसे समझाना मुश्किल है
    prompt model version से बहुत मज़बूती से बँधा होता है, इसलिए जो GPT-4 में अच्छा चलता था, वह GPT-5 में टूट जाता है
    इसलिए आजकल मेरा झुकाव बस Gemini इस्तेमाल करने की तरफ़ हो गया है

    • LMArena evaluation को बहुत आसानी से manipulate किया जा सकता है। human evaluators भी खुशामदी जवाबों से आसानी से प्रभावित हो जाते हैं
      ऐसी feedback-based tuning LLM की overconfidence समस्या को और बदतर बनाती है
    • मैंने AImodelReview नाम की एक साइट बनाई है जहाँ कई models के outputs की तुलना की जाती है
      लेकिन users खुद evaluate नहीं करना चाहते और leaderboard-style ranking चाहते हैं
      LLM को judge की तरह इस्तेमाल करने का तरीका भी है, लेकिन उसमें कुछ गड़बड़-सा लगता है
      आखिरकार expert reviewer-based evaluation की ज़रूरत है, लेकिन इसकी लागत बहुत ज़्यादा है
    • इससे यह भी याद आता है कि human psychometrics भी इसी तरह कठिन है

  • individual developer स्तर पर खुद benchmark बनाना ही समाधान है
    जिन code problems को आपने खुद हल किया है, उन्हीं के आधार पर tests बनाइए, और tok/s या TTFT जैसे metrics देखिए

    • मैं LLM को सिर्फ agent wrapper environment में इस्तेमाल करता हूँ, इसलिए benchmark सरल है। नए model से काम करवाता हूँ और अनुभव से pass/fail तय कर लेता हूँ
      आखिरकार user का खुद इस्तेमाल करके देखना ही सबसे व्यावहारिक evaluation है
    • OpenAI के GitHub में evaluation जोड़ने पर अगला model उस problem में और बेहतर हो जाता है
    • ऐसी self-evaluation को evals कहा जाता है, और किसी भी गंभीर AI project के लिए यह ज़रूरी है
    • AI Stupid Level जैसी साइट भी यही approach अपनाती है
    • लेकिन यह नहीं भूलना चाहिए कि “समस्या हल करना” सिर्फ pattern recognition भी हो सकता है

  • एक व्यक्ति ने calculator के बिना होने वाली परीक्षा(AIME) के सवालों का उदाहरण देते हुए कहा कि छोटे numbers तक सीमित benchmark वास्तविक क्षमता नहीं दिखाते
    लेकिन मेरा मानना है कि model का इंसानों की तरह exam tricks सीखना भी एक तरह की प्रगति है। यह human-like reasoning के ज़्यादा क़रीब है

    • इसके उलट, कुछ लोगों का कहना है कि अगर reasoning सच में है, तो बड़े numbers वाले सवाल भी हल होने चाहिए
    • कॉलेज के छात्र अगर exam tricks से सवाल हल करते हैं, तो वह human evaluation का सिर्फ एक हिस्सा है, लेकिन LLM उसे अपनी पूरी क्षमता की तरह पेश करता है
      मैं non-gamified evaluation चाहता हूँ। अभी यह बस एक स्मार्ट autocomplete जैसा है
    • calculation problems आखिरकार tool use ability आने पर गायब हो जाने वाली समस्या हैं
    • इस विषय पर Forbidden Technique वीडियो भी दिलचस्प है
    • अगर LLM को Excel या Mathematica जैसे external tools इस्तेमाल करने दिए जाएँ, तो वह इंसानों की तरह calculation problems हल कर सकेगा

  • किसी ने सुझाव दिया कि हम परेशान करने वाले bugs का Git repo बनाकर LLM को उस पर test करें
    उदाहरण के लिए Yjs/CRDT bug को Claude Code, GPT5-codex, और GLM-4.6 से हल कराने की कोशिश की गई, लेकिन आखिर में सिर्फ workaround ही निकल पाया
    frontend logs को backend में भेजकर AI को real-time में दिखाने के बाद ही कुछ प्रगति हुई

    • Playwright library को सीधे इस्तेमाल करने दिया जाए, तो frontend समस्याएँ सुलझाने में यह प्रभावी था
    • लेकिन ऐसा सुझाव असल में AI training के लिए high-quality data मुफ़्त में देने जैसा भी हो सकता है
    • मैंने भी निजी तौर पर bug collection बनाकर LLM से test code लिखवाया, लेकिन अभी नवीनतम models भी असफल हैं
    • सच तो यह है कि ज़्यादातर अनुभवी LLM users पहले से अपने निजी benchmark बनाए रखते हैं
      क्योंकि उन्हें सार्वजनिक करते ही वे training data में समा जाते हैं और बेअसर हो जाते हैं
      ऐसे निजी benchmark बनाए रखने से models की वास्तविक प्रगति की गति कहीं अधिक ठंडे दिमाग़ से देखी जा सकती है

  • benchmark आखिरकार किसी खास संदर्भ का spec भर है। यह सिर्फ दिखाता है कि किसी खास परिस्थिति में code ठीक चलता है, हर स्थिति में नहीं

    • Dijkstra के शब्दों में, “testing bugs की मौजूदगी दिखा सकती है, लेकिन उनकी अनुपस्थिति साबित नहीं कर सकती”
      इसे LLM पर लागू करें तो बात होगी, “benchmark सिर्फ यह दिखाते हैं कि क्या संभव है, यह साबित नहीं करते कि क्या असंभव है”

  • इस शोध में 445 benchmarks की समीक्षा की गई, और कहा गया कि उनमें से ज़्यादातर में construct validity की कमी है
    असली intelligence को मापना है तो novelty को evaluate करना होगा
    पहले से देखे गए सवालों जैसे patterns हल करना सिर्फ memorization है
    लेकिन सैकड़ों petabytes के training data से बचते हुए पूरी तरह नए सवाल बनाना लगभग असंभव है
    इसलिए intelligence का illusion पैदा होता है

    • problem solving को सिर्फ ‘memory’ बनाम ‘creativity’ में बाँटना गलत तरीका है
      वास्तव में इन दोनों के बीच अनगिनत grey areas मौजूद हैं।
      पूरी तरह नया problem भी हल करने के लिए कुछ न कुछ समानता तो होनी ही चाहिए