AI की दीर्घकालिक कार्य पूरा करने की क्षमता का मापन

 (metr.org)
10 पॉइंट द्वारा GN⁺ 2025-12-23 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • AI मॉडल पूरी तरह से पूरा कर सकने वाले कार्यों की ‘लंबाई’ के आधार पर प्रदर्शन मापने के लिए एक नया मेट्रिक प्रस्तावित किया गया है
  • विश्लेषण के अनुसार, पिछले 6 वर्षों में AI द्वारा स्वायत्त रूप से पूरे किए जा सकने वाले कार्यों की लंबाई लगभग हर 7 महीने में दोगुनी हुई है
  • जिन कार्यों को मानव विशेषज्ञ 4 मिनट के भीतर समाप्त कर देते हैं, उनमें सफलता दर लगभग 100% है, लेकिन 4 घंटे से अधिक समय लेने वाले कार्यों में सफलता दर 10% से कम है
  • यदि यह रुझान जारी रहता है, तो अनुमान है कि कुछ ही वर्षों में AI कई हफ्तों की परियोजनाएँ स्वतंत्र रूप से पूरा कर सकेगा
  • इस शोध के AI benchmark, भविष्य की क्षमताओं के पूर्वानुमान, और जोखिम प्रबंधन पर महत्वपूर्ण निहितार्थ हैं

शोध का अवलोकन

  • METR ने AI कितनी लंबी अवधि के कार्य पूरे कर सकता है इसे मापने का एक नया तरीका प्रस्तुत किया
    • मापन का आधार वह समय है जो मानव विशेषज्ञ को वही कार्य करने में लगता है
    • मॉडल की सफलता की संभावना और मानव कार्य-समय के बीच संबंध को logistic curve के रूप में मॉडल किया गया
  • यह दृष्टिकोण AI की वास्तविक उपयोगिता का आकलन करने के लिए एक उपयोगी मेट्रिक के रूप में प्रस्तुत किया गया
    • यह मौजूदा benchmarks की उस सीमा को पूरा करता है जो एकल समस्या-समाधान क्षमता पर अधिक केंद्रित हैं

मुख्य परिणाम

  • वर्तमान मॉडलों की प्रदर्शन सीमा
    • जिन कार्यों को मनुष्य 4 मिनट के भीतर करते हैं, उनमें सफलता लगभग 100% है
    • 4 घंटे से अधिक समय लेने वाले कार्यों में सफलता दर 10% से कम है
    • उदाहरण: Claude 3.7 Sonnet लगभग 1 घंटे लंबे कार्यों में 50% सफलता दर दिखाता है
  • प्रदर्शन सुधार की प्रवृत्ति
    • पिछले 6 वर्षों में 50% विश्वसनीयता के साथ पूरे किए जा सकने वाले कार्यों की लंबाई लगभग हर 7 महीने में दोगुनी हुई है
    • log scale विश्लेषण से निरंतर exponential growth की पुष्टि हुई
    • यदि यह रुझान बना रहता है, तो 2~4 वर्षों में सप्ताह-स्तरीय कार्य संभव हो सकते हैं

कार्यप्रणाली और सत्यापन

  • dataset-आधारित सत्यापन
    • विभिन्न कार्य-समूहों (software, reasoning आदि) के लिए मानव द्वारा लगने वाला समय दर्ज किया गया
    • SWE-Bench Verified dataset में भी इसी तरह की exponential वृद्धि की पुष्टि हुई
    • उस डेटा में 3 महीनों से कम का doubling time देखा गया
  • sensitivity analysis
    • मॉडल, कार्य-चयन, noise आदि विभिन्न कारकों के प्रति robustness की जाँच की गई
    • 1 महीने लंबे कार्यों को पूरा करने के समय का अनुमान लगाने वाले simulation में मापन त्रुटि बड़ी होने पर भी रुझान बना रहा

व्याख्या और सीमाएँ

  • यह AI के benchmark प्रदर्शन और वास्तविक उपयोगिता के बीच के अंतर को समझाने में मदद करता है
    • परीक्षा-प्रकार के प्रश्नों में AI मनुष्यों से बेहतर हो सकता है, लेकिन वास्तविक दीर्घकालिक परियोजनाओं के निष्पादन में अभी कमजोर है
  • रुझान के extrapolation में अनिश्चितता को स्वीकार किया गया
    • यदि केवल 2024~2025 के डेटा का उपयोग किया जाए, तो महीना-स्तरीय कार्य निष्पादन का समय लगभग 2.5 वर्ष पहले आ सकता है
    • यह भी कहा गया कि पुराने डेटा की तुलना में हालिया रुझान भविष्य के प्रदर्शन का बेहतर पूर्वानुमान दे सकते हैं

निष्कर्ष और महत्व

  • AI प्रदर्शन को ‘कार्य की लंबाई’ से मापने का दृष्टिकोण
    • विभिन्न कठिनाई स्तरों और domains में प्रदर्शन सुधार को मात्रात्मक रूप से माप सकता है
    • वास्तविक दुनिया के प्रभाव से सीधे जुड़े हुए पूर्ण प्रदर्शन-आधारित अर्थ प्रदान करता है
  • यदि निरंतर exponential growth जारी रहती है, तो
    • 10 वर्षों के भीतर स्वायत्त महीना-स्तरीय परियोजनाएँ संभव हो सकती हैं
    • इसके साथ विशाल संभावित लाभ और जोखिम दोनों जुड़े होंगे
  • शोध डेटा और analysis code GitHub पर सार्वजनिक हैं, जिससे आगे के शोध और replication experiments को प्रोत्साहन मिलता है

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

2 टिप्पणियां

 
crawler 2025-12-23

काफ़ी अच्छा benchmark लग रहा है
आजकल AI coding tools को देखें तो कई मामलों में वे पहले से Plan बनाते हैं और Agent mode में काम करते हैं, तो यह भी जानने की जिज्ञासा है कि क्या इससे वास्तव में long-term success rate पर कोई meaningful असर पड़ता है।
 
GN⁺ 2025-12-23
Hacker News की राय
  • हाल ही में मैंने अपने hobby project में सिर्फ “vector search जोड़ो” कहा था, और Opus ने manticore सेट कर दिया, embedding model ले आया, मौजूदा keyword index को migrate करने का tool बना दिया, और frontend तक तैयार कर दिया
    यह बस एक लाइन के tweet जैसा prompt था, और 15 मिनट में पूरा हो गया, जबकि मैं उस दौरान Kirby Air Riders खेल रहा था
    लेकिन अफसोस यह रहा कि इस प्रक्रिया से मैंने vector search बनाना लेकर कुछ भी नहीं सीखा. आखिरकार मकसद feature था, सीखना नहीं, और सीखना बस द्वितीयक चीज़ थी
    • मुझे नहीं लगता कि जानबूझकर किसी चीज़ को धीमे तरीके से बनाना बेहतर learning method है
      4 घंटे खुद बनाकर लगाने से बेहतर है कि agent उसे 15 मिनट में बना दे, उस दौरान आप कुछ और करें, और बाद में 30 मिनट code पढ़ने, बदलने और सवाल पूछने में लगाएँ
      30 मिनट की focused learning शायद 4 घंटे की trial-and-error से बेहतर हो सकती है
    • लेकिन ऐसा करने पर आखिर में maintain न हो सकने वाला बहुत बड़ा code blob बन जाता है
      AI भी किसी बिंदु पर code की structure खो देता है, और आखिरकार आप Opus पर निर्भर ग्राहक बन जाते हैं
    • Opus या Anthropic निश्चित रूप से top tier हैं, लेकिन हर बार इस्तेमाल करने पर यह intellectual fast food जैसा लगता है
      पहले music सुनते हुए Scala में problem solve करने की प्रक्रिया मज़ेदार लगती थी, लेकिन अब नतीजा बहुत आसानी से मिल जाने से उल्टा खालीपन सा लगता है
    • “मुझे feature चाहिए था, उसे बनाना सीखना नहीं” इस बात से मैं पूरी तरह सहमत हूँ
      मैं भी trading model बनाते समय charting खुद सीखने के बजाय चाहता हूँ कि LLM मेरे लिए code लिख दे
      इससे छोटी-मोटी API handling पर समय बर्बाद नहीं होता और मैं सिर्फ उन हिस्सों पर ध्यान दे सकता हूँ जहाँ सच में decision-making चाहिए
    • क्या वह vector search code share किया जा सकता है?
  • “long task” की अवधारणा को मैंने खुद अनुभव करने से पहले ठीक से नहीं समझा था
    Python HTML5 parser को JavaScript में port करते समय मैंने Codex CLI को 9,200 html5lib-tests पर चलाया, और 4 घंटे से ज़्यादा loop में घूमते हुए समस्याएँ हल करते देखना प्रभावशाली था
    संबंधित लेख यहाँ है
    • METR का “4 घंटे का task” यह नहीं कहता कि AI को सचमुच 4 घंटे लगते हैं, बल्कि इसका मतलब है ऐसी कठिनाई जिसे इंसान को 4 घंटे लगें
      Opus 4.5 ऐसे स्तर के task को 50% reliability के साथ कर सकता है, और वास्तविक execution time इससे काफी कम होता है
      आगे 8 घंटे, 40 घंटे जैसे मानदंड पार होंगे तो बात और दिलचस्प होगी
    • यह metric AI की असली speed नहीं, बल्कि मानव-आधारित कठिनाई को मापता है
      benchmark जल्दी टूट जाते हैं, लेकिन वास्तविक work automation अब भी कठिन है — यह बात इसे अच्छी तरह दिखाती है
    • METR का “human hours equivalent” में यह महत्वपूर्ण है कि किस इंसान को आधार माना जा रहा है
      jq, PyPI ecosystem या TypeScript annotations से परिचित व्यक्ति शायद इसे बहुत जल्दी खत्म कर दे
      आखिर AI की असली आकर्षक बात यही है कि आपको ऐसा expert-level help तुरंत मिल सकता है
    • लेकिन Codex या Claude code से long task चलाने पर permission request बहुत बार आती है, और बीच में रुक जाना भी आम है
      ज़्यादातर model “चलो अगले step पर चलते हैं” कहकर खुद ही रुक जाते हैं
    • GPT5.2 खासकर ज़रूरत से ज़्यादा user input माँगता है, इसलिए उससे 2 मिनट से ज़्यादा लगातार काम कराना मुश्किल है
      क्या किसी ने इसका कोई हल निकाला है?
  • Models के बारे में राय देते समय सावधानी चाहिए, लेकिन Opus 4.5 और Sonnet 4.5 का फ़र्क निश्चित रूप से महसूस हुआ
    पहले की तुलना में price gap भी कम हुआ है, इसलिए practical use value बढ़ी है, और Haiku 4.5 भी reasoning ऑन करने पर काफ़ी उपयोगी है
    छोटे tools या single-page editing के लिए यह खास तौर पर उपयुक्त है
  • मेरा मानना है कि software learning को exploration और exploitation — इन दो चरणों में बाँटा जा सकता है
    LLM की वजह से ये दोनों चरण स्वाभाविक रूप से जुड़ जाते हैं
    उदाहरण के लिए, AnimeJS animation बनाते समय मैं CCAgent को code लिखते हुए देखकर सीखता हूँ, और बाद में खुद structure बनाता और refactor करता हूँ
    इससे समय की बचत और creative control दोनों मिलते हैं
  • Opus, GPT 5.1 की तुलना में बड़ा छलाँग जैसा लगता है, लेकिन 80% reliability के मानदंड पर अभी भी GPT 5.1 आगे है
    यानी छोटे task के लिए GPT 5.1, और लंबे task के लिए Opus ज़्यादा उपयुक्त है
    • 50% success rate पर महंगे token की बर्बादी बहुत बड़ी है, लेकिन उम्मीद है कि अगले साल तक open source models भी इस स्तर तक पहुँच जाएँगे
  • METR की मुख्य बात यह है कि वह complexity को ‘human-equivalent time’ के आधार पर मापता है
    50% success rate पर 4 घंटे का task सौंपना असल में लगभग जुआ है, और fail होने पर debugging जोड़ दें तो नुकसान बड़ा हो जाता है
    इसलिए मुझे लगता है कि हर 30 मिनट पर human review checkpoint रखना बेहतर है
    हालांकि बीच में अटकने पर AI की खुद recover करने की क्षमता भी अहम है
    • लेकिन 30 मिनट में AI इतना ज़्यादा output बना देता है कि उसकी review करना दुःस्वप्न जैसा हो जाता है
      ऊपर से सब ठीक लगता है, लेकिन बाद में सूक्ष्म bug सामने आते हैं
      इसलिए महत्वपूर्ण कामों में मैं अब भी agent का इस्तेमाल नहीं करता, क्योंकि यह काम का आनंद भी छीन लेता है
    • अगर 4 घंटे बर्बाद भी हुए हों, तब भी अगर उस दौरान आपने कुछ और किया हो तो यह घाटा नहीं है
      अगर आधी संभावना पर नतीजा मिल जाता है, तो यह time efficiency के हिसाब से अच्छा bet हो सकता है
    • fail होने पर भी वास्तव में आपका नुकसान सिर्फ AI के काम करने के कुछ मिनटों का होता है, इसलिए prototype exploration के लिए यह शानदार है
      आप कई कोशिशें जल्दी-जल्दी कर सकते हैं, और असफलता से भी सीख मिलती है
  • 95% या 99% reliability के आधार पर graph भी चाहिए
    तभी यह और साफ़ दिखेगा कि LLM अब भी वे काम क्यों बार-बार fail करता है जो इंसान आसानी से कर लेते हैं
  • मेरा मानना है कि performance optimization, AI की वास्तविक बुद्धिमत्ता मापने के लिए अच्छा benchmark है
    result को संख्या में verify किया जा सकता है, code जितना छोटा हो उतना बेहतर, और इसमें साधारण combination नहीं बल्कि system-level thinking चाहिए
    अब तक SIMD code optimization में Gemini Pro 3 सबसे बेहतर रहा है
  • 50% success rate की समस्या यह है कि retry करने पर probability तेज़ी से गिरती है
    4 घंटे वाले task को कई बार दोहराने पर success probability 6.25% तक गिर जाती है
    • हालांकि यह सिर्फ “किस्मत खराब” होने की बात नहीं है; एक बार fail हुआ task अगली कोशिश में अलग success probability रख सकता है
      यह task की प्रकृति पर निर्भर करता है