कोडिंग मूल्यांकन में signal और noise को अलग करना

• AI मॉडल की कोडिंग क्षमता का मूल्यांकन सीधे deployment और safety संबंधी फैसलों से जुड़ा होता है, लेकिन OpenAI के audit में SWE-Bench Pro tasks में से करीब 30% broken state में होने का अनुमान लगाया गया
• SWE-Bench Pro का लक्ष्य लंबी task scope और अधिक realistic problems था, लेकिन 731 public tasks में pass rate 8 महीनों में 23.3% से 80.3% तक बढ़ने के नतीजे पर ज्यों का त्यों भरोसा करना मुश्किल हो गया
• खामियां overly strict tests, underspecified prompts, low-coverage tests, और misleading prompts में बांटी जाती हैं; सही submissions fail हो सकती हैं या अधूरे fixes pass हो सकते हैं
• audit ने model attempts, task metadata, और failure tracking के आधार पर 286 potentially problematic tasks flag किए, फिर investigation agent और 5 experienced engineers की independent review से गुजारा
• OpenAI ने SWE-Bench Pro अपनाने की अपनी recommendation वापस ले ली है, और evaluation benchmarks को ऐसे meaningful signals देने चाहिए जो model capability और safety judgments को distort न करें

---

SWE-Bench Pro audit में सामने आई समस्याएं

• OpenAI ने SWE-Bench Pro का audit करने के बाद अनुमान लगाया कि कुल tasks में से करीब 30% broken state में हैं
• model capability को ठीक-ठीक मापना Preparedness Framework के तहत deployment और safety judgments को भी प्रभावित करता है
• defective evaluations model capability को वास्तविकता से अलग ढंग से समझा सकती हैं, और safety judgments व research priorities को अस्थिर कर सकती हैं

SWE-Bench Pro का उद्देश्य और pass rate में बदलाव

• OpenAI ने पहले व्यापक रूप से इस्तेमाल होने वाले SWE-bench Verified में design और contamination issues पाए थे, और निष्कर्ष निकाला था कि यह evaluation अब software development capability के बारे में meaningful signal नहीं दे रहा
• उस समय OpenAI ने community को SWE-Bench Pro पर switch करने की recommendation दी थी
• SWE-Bench Pro को SWE-bench Verified में सुधार करते हुए, लंबी task scope और अधिक realistic coding tasks के साथ agentic coding capability को track करने के लिए design किया गया था
• tasks को public और private repositories की feature change history से programmatic तरीके से निकाला जाता है
  • model को ऐसा solution implement करना होता है जो existing functionality को तोड़े बिना नए feature tests pass करे
  • 731 tasks वाले public split में frontier models का pass rate 8 महीनों में 23.3% से 80.3% तक बढ़ गया

Quality assurance pipeline

• OpenAI ने यह सुनिश्चित करने के लिए quality assurance pipeline बनाई कि हर datapoint वास्तविक model capability को reflect करता है या नहीं
• शुरुआती automated filter ने model को दिए गए instructions, model के solve attempts, और grading tests की समीक्षा करके broken या संदिग्ध examples को flag किया
• इस process में 286 potentially problematic tasks flag किए गए
• flag किए गए subset की दो routes से और गहराई से समीक्षा की गई
  • human-supervised agent review: investigation agent ने detailed checks किए और final human judgment से गुजरा
  • human annotation campaign: experienced software developers ने tasks की direct review की

Agent review और human review का तरीका

• flag की गई समस्याओं का audit Codex-based investigation agent ने किया
  • agent को task repository और execution environment तक access था
  • tests चलाना, repository files inspect करना, model attempts और common failure modes की जांच करना संभव था
  • इसका उपयोग surrounding code और repository conventions से हल की जा सकने वाली reasonable ambiguity और वास्तविक underspecification में फर्क करने के लिए किया गया
• कई rounds की independent deep audits के बाद researcher ने summaries review कीं और final judgment व issue labels तय किए
• parallel में चले human annotation campaign में experienced software engineers ने benchmark goals, issue taxonomy, और edge cases पर training लेने के बाद tasks review किए
• हर task की समीक्षा 5 engineers ने की
  • reviewers ने visible problem description, test cases, और correct reference solution यानी gold patch के आधार पर पहले independent judgment दिया
  • इसके बाद pipeline analysis या logs को supporting context के रूप में इस्तेमाल किया
  • specific evidence के आधार पर label और severity तय की, और disagreement या low-confidence cases को additional review के लिए escalate किया

चार failure types

• audit में पहचानी गई समस्याएं मुख्यतः चार categories में बंटी थीं
  • Overly strict tests: prompt में न दिए गए specific implementation details को enforce करके functionally correct submissions को invalidate करते हैं
  • Underspecified prompts: hidden tests जिन requirements की मांग करते हैं, उन्हें छोड़ देते हैं जिन्हें reasonable तरीके से infer करना मुश्किल होता है
  • Low-coverage tests: requested functionality को पर्याप्त रूप से verify नहीं करते, जिससे incomplete fixes भी pass हो सकते हैं
  • Misleading prompts: model को गलत behavior की ओर ले जाते हैं या test requirements से contradict करते हैं
• कुछ tasks में prompt ने specific implementation की मांग की, लेकिन hidden test cases ने अलग behavior expect किया

Human review और agent review में अंतर

• human reviewers के investigation agent की तुलना में tasks को broken mark करने की संभावना अधिक थी
• दोनों review routes के बीच category judgment में फर्क था, लेकिन flag किए गए tasks में human labels के लिए “not broken” कभी भी सबसे ज्यादा मिलने वाला label नहीं था
• agent pipeline द्वारा flag की गई category और human reviewers के judgment 74% cases में overlap हुए
• human reviewers ने एक task के लिए multiple labels चुनने के cases भी ज्यादा दिखाए
  • यह संकेत था कि task कई तरीकों से broken था या किसी single category में साफ-साफ fit नहीं बैठता था
  • agent और reviewers को साथ इस्तेमाल करने वाली pipeline ने humans द्वारा पाए गए broad failure modes को capture किया, लेकिन additional और duplicate issues को conservative तरीके से कम गिना
• सबसे बड़ा फर्क low-coverage tests में दिखा
  • humans ने इसे benchmark के 9.4% में सबसे common issue के रूप में चुना
  • agent pipeline ने इसे 4.1% के रूप में flag किया

Benchmark बनाना कठिन क्यों है

• SWE-Bench Pro और SWE-bench Verified के examples दिखाते हैं कि benchmarks को rigorously validate करना जरूरी है
• open-source repositories के issues और pull requests मूल रूप से model evaluation के लिए नहीं, बल्कि human collaboration के लिए बनाए जाते हैं
• maintainers और contributors के बीच लंबी back-and-forth discussions वाले environments में problem descriptions, merged code, और unit tests हमेशा model evaluation के लिए clean और independent tasks नहीं बनाते
• pull requests में शामिल tests अक्सर specific change को verify करने के लिए लिखे जाते हैं, इसलिए वे implementation-agnostic solution criteria के बजाय specific implementation को enforce कर सकते हैं

आगे की evaluation दिशा

• model capabilities बेहतर होने के साथ evaluation defects भी पहले की तुलना में आसानी से मिल सकती हैं
• improved models prompts, tests, patches, execution traces, और edge cases की ज्यादा गहरी और consistent जांच करके benchmark issues सामने ला सकते हैं, जिन्हें पहले बड़े scale पर ढूंढना मुश्किल या महंगा था
• OpenAI उम्मीद करता है कि broader evaluation community experienced software developers द्वारा सीधे model capability testing के उद्देश्य से बनाए गए नए benchmarks develop करेगी
• यह तरीका जिस high difficulty और realism को measure करना है, उसे बनाए रखते हुए पूरे process में बेहतर human oversight संभव करता है
• OpenAI ने इस analysis में सामने आई समस्याओं के कारण SWE-Bench Pro adoption पर अपनी पिछली recommendation वापस ले ली है
• evaluations ऐसी होनी चाहिए जिन्हें game करना मुश्किल और trust करना आसान हो, और जो model capability या alignment state को सच में reflect करने वाले meaningful signals प्रदान करें

[GN⁺]

Hacker News की राय

• एक नया benchmark चाहिए। API cost 100 डॉलर में कोई model benchmark के bundle पर कितना कर सकता है, इसे मापने का तरीका अच्छा होगा
  efficiency और intelligence, दोनों को साथ में मापना चाहिए। छोटे model computer use से results test करने या problem पर ज़्यादा देर टिके रहकर output verify करने जैसी strategy अपना सकते हैं, और बड़े model के पास self-testing budget कम हो सकता है, इसलिए tactics में दिलचस्प फर्क दिख सकता है
  • शायद Artificial Analysis के Intelligence vs Cost benchmark की बात हो रही है
    https://artificialanalysis.ai/?cost=intelligence-vs-cost-per...
  • किस company की pricing को आधार मानकर हिसाब किया जाए, यही समस्या है
  • यही मूल सवाल है, और दिलचस्प बात यह है कि OpenAI website par release history के हिसाब से यह metric कैसे बदला, इसे साफ़-सुथरे dashboard में नहीं दिखाया गया
    Toby Ord ने public data के साथ जितना हो सका उतना किया, लेकिन नतीजे बहुत अच्छे नहीं लगते
    https://www.tobyord.com/writing/hourly-costs-for-ai-agents
• Terminal Bench 2 में कई वजहों से fake results काफ़ी हैं। Ryan/Alex जैसी बेहतरीन टीमों ने हाल में संदिग्ध submissions में से बहुत-से साफ़ किए हैं, लेकिन कई labs ने time limit या hardware settings बदलकर ऐसे नतीजे जारी किए हैं जो किसी खास task में वास्तव में मापी जाने वाली चीज़ को bypass करते हैं
  इसके अलावा execution harness स्तर की cheating और model reward hacking भी है। कई महीने बाद भी जो बात खटकती है, वह gpt-5.5 की official submission है, खासकर यह task: https://www.tbench.ai/leaderboard/terminal-bench/2.0/codex/0...
  task की time limit https://github.com/harbor-framework/terminal-bench-2/blob/ma... के अनुसार verifier 1200 seconds, agent 1200 seconds, और environment build 600 seconds है, इसलिए किसी भी agent को 3000 seconds से ज़्यादा नहीं जाना चाहिए। लेकिन ऊपर वाले link की 5 कोशिशों में से 2 ने 3000 seconds को बहुत पार किया और क्रमशः 75 मिनट, 80 मिनट लगे। fail होने पर भी इतना लंबा चलना संदिग्ध है। यह Goodhart's law के काम करने का उदाहरण है
  • भले ही किसी ने किसी खास definition के हिसाब से “cheating” न की हो, benchmark पहले ही किसी विशाल structural gradient descent के भीतर जा चुका है। model किसी भी स्तर पर benchmark score को maximize करने वाली machine है, इसलिए benchmark खुद ही मूल रूप से कुछ बेकार-सा लगता है
    इंसानों को benchmark करना भी ठीक से काम नहीं करता। coding ability को कुछ हद तक ठीक से नापने के लिए सीधे interaction करना पड़ता है। अगर model मूल रूप से human simulator है, तो simulation जितनी सटीक होती जाएगी, यह उम्मीद करना कि benchmark लगातार उपयोगी रहेगा, उल्टा अजीब है। आखिरकार यह ऊपर कही गई “Goodhart's law” को थोड़ा विस्तार से कहने जैसा ही है, और यह सचमुच किसी law की तरह काम करता है
• मूल रूप से क्या निष्कर्ष यह नहीं है कि software developers को दिए जाने वाले tasks, चाहे इंसान को दिए जाएँ या model को, अक्सर incomplete या self-contradictory होते हैं, या उससे भी बदतर हालत में होते हैं। यह tool उसी दुनिया में काम करना चाहिए, इसलिए इसके लिए ज़्यादा सहानुभूति नहीं होती
  • सहमत। insufficient prompt को tool की failure के रूप में गिनाना बहुत ठोस नहीं लगता। एक intern भी थोड़ी मदद के साथ ambiguous request समझ लेता है, और यह भी जानता है कि लगातार आगे बढ़ते रहने के बजाय कब रुककर पूछना चाहिए। internship खत्म होने से पहले भी वे अक्सर काफ़ी independently ambiguous tasks संभाल लेते हैं
    तो क्या तर्क यह है कि state-of-the-art model junior engineer भी नहीं, बल्कि उससे नीचे स्तर का first-month intern है, जो उस स्तर से ऊपर जाने में सक्षम नहीं?
  • असली काम में आप failed test cases देखकर code fix कर सकते हैं, या ज़्यादा संभावना यह है कि बुरी तरह लिखे गए tests को ठीक कर सकते हैं। अगर latest LLMs को सिर्फ़ यह पहला कदम ही करने दिया जाए, तो यह खास benchmark वे बहुत आसानी से dominate कर देंगे
    दिलचस्प बात यह है कि LLM ऐसे benchmarks में 70% से ऊपर कैसे निकल जाते हैं, या बुरी तरह बनाए गए सवालों में से कुछ का सही जवाब कैसे दे देते हैं। क्या उन्होंने test writer की शैली को implicitly सीख लिया है? क्या solutions training data में leak हो गए?
    फिर भी यह तसल्ली की बात है कि Fable भी उस hidden set पर, जिस पर OpenAI ने यह analysis नहीं चलाया, लगभग 72% पर रुक जाता है। ऐसा नहीं लगता कि benchmark खुद सीधे सीखा गया है, सिवाय शायद बहुत अप्रत्यक्ष तरीके से
    छोटे open models ऐसी अजीब आदतें कभी नहीं सीख सकते, इसलिए models का fair evaluation करने का अच्छा तरीका सच में बहुत ज़रूरी है। अतिरिक्त रूप से OpenAI थोड़ा पानी गंदा कर रहा है, क्योंकि लगभग 20% problems ही agent के ख़िलाफ़ unfair तरीके से टूटी हुई थीं, और 4~10% agent के पक्ष में टूटी हुई थीं, इसलिए benchmark ceiling शायद 80~85% के करीब होगी
  • इससे भी ज़्यादा सूक्ष्म मुद्दा task और verification के बीच का gap है। उदाहरण के लिए, अगर prompt open-ended हो या पर्याप्त रूप से specified न हो, तो verifier को हर possible solution handle करना आना चाहिए
    इसलिए बहुत narrowly defined task prompts verify करना आसान होता है, लेकिन challenge के रूप में शायद बहुत साधारण हो जाते हैं। दूसरी ओर, ज़्यादा realistic task prompts को verify करना कहीं ज़्यादा कठिन होता है, और robust verifier बनाना व उसे सस्ते में चलाना भी मुश्किल हो जाता है
  • मैं भी यही सोच रहा था, और खासकर उन invisible requirements के मामले में जो शुरुआत में explicitly नहीं बताई गईं, बल्कि सिर्फ़ tests में छिपी थीं, यह बात सही लगती है। कोई requirement जिसके बारे में किसी ने बताया ही नहीं, उसे handle करने के लिए solution को फिर से tweak करना पड़े? मैं भी असल काम में यही करता हूँ
    बेशक इसका मतलब है कि benchmark जो दावा करता है उससे अलग चीज़ test हो रही है, लेकिन कभी-कभी साफ़ benchmark के बजाय वास्तविक दुनिया के ज़्यादा करीब किसी चीज़ को अनजाने में test करना भी अपने-आप में मायने रखता है
    लेकिन यह तभी है जब agent failed tests देखकर iterate कर सके। अगर नहीं, तो बस यह एक समस्या है। और जब tests किसी खास solution की implementation details को अंदर ठूँस दें, और कोई भी मनमाना internal structure मांगें, तो वह और भी खराब है। असल दुनिया में ऐसी स्थिति नहीं मिलती
• यहाँ numbers देखें तो पूरा benchmark 800 से कम tasks का लगता है। कुछ engineers इसे एक हफ़्ते में देख सकते हैं, और आखिरकार OpenAI ने यहाँ यही किया

एक तरफ़ देखें तो उन्होंने वास्तव में यह काम किया, यह काबिले-तारीफ़ है। दूसरी तरफ़, यह बिल्कुल “garbage in, garbage out” वाली बात है। मूल लेखकों ने खुद ठीक से जाँच नहीं की, यह भी थोड़ा शर्मनाक है, और downstream में मौजूद सभी लोगों ने भी जाँच नहीं की, यह भी शर्मनाक है। और पोस्ट को देखें तो LLM ने भी समस्याएँ पकड़ीं, लेकिन विशेषज्ञ software engineer द्वारा ढूँढी गई समस्याओं को कम करके आँकने की प्रवृत्ति थी

• benchmarks को अंदर से देखें तो ज़्यादातर काफ़ी खराब निकलते हैं
  संदर्भ के लिए, Codex/Claude Code इस्तेमाल करते समय लगने वाली कई झंझटभरी प्रक्रियाओं को बदलने के लिए मैं एक supervisor agent को बार-बार बेहतर बना रहा था, और हाल ही में इस agent को Terminal Bench 2.1 पर चलाया
  शुरुआत में मैं खुश था। spec-based supervisor कई tasks में base Codex से बेहतर था। लेकिन जब और गहराई से देखा, तो tasks में ही बहुत सारी समस्याएँ थीं
  मुख्य बात यह है कि instructions अक्सर अस्पष्ट होते हैं, जबकि test cases ज़रूरत से ज़्यादा विशिष्ट होते हैं। उदाहरण के लिए configure-git-webserver में “so that I can run” जैसी अभिव्यक्ति के कारण यह सीमा धुंधली हो जाती है कि agent को क्या उपलब्ध कराना चाहिए और क्या हटाना चाहिए। ज़्यादा सोचने वाला agent server सेट करने के बाद यह मान बैठता है कि अगर user वही command चलाएगा तो टकराव होगा, और validator जिन exact files को जाँचता है उन्हें हटा देता है
  make-mips-interpreter में “I will check that you booted doom correctly” वाली पंक्ति के कारण supervisor यह समझता है कि user यह नहीं जाँच रहा कि Doom अपने-आप boot होता है या नहीं, बल्कि यह जाँच रहा है कि agent ने boot किया हुआ परिणाम क्या है, इसलिए वह बना हुआ /tmp/frame.bmp छोड़ देता है। validator अगर पहले से /tmp/frame.bmp मौजूद हो तो exit कर जाता है, इसलिए Doom शुरू ही नहीं हो पाता, और यह भी नहीं जाँचता कि boot प्रक्रिया में वह नया बनता है या नहीं[0]
  mcmc-sampling-stan में supervisor agent अक्सर सही value तक पहुँच जाता था, लेकिन साधारण decimal की जगह domain-specific numeric output को scientific notation में देता था। validator result को गलत parse करके fail कर देता था[1]
  ये mismatch सिर्फ़ कुछ उदाहरण हैं, और इसी वजह से मुझे लगता है कि Terminal Bench 2.1 पहले ही saturated हो चुका है, और GPT-5.6 तथा Mythos के 88.8% और 88% नतीजे लगभग अपेक्षित upper bound तक पहुँच चुके हैं। सबसे बड़ी समस्या यह है कि ज़्यादातर benchmarks single-shot execution हैं, और वे लंबे iterative काम में model+harness को लगभग test ही नहीं करते, जबकि असली users tools का मुख्य उपयोग इसी तरह करते हैं
  [0] https://github.com/harbor-framework/terminal-bench-2-1/issue...
  [1] https://github.com/harbor-framework/terminal-bench-2-1/issue...

• क्या शुरू से ही सबको नहीं पता था कि पूरा SWE-Bench दोषपूर्ण है? लेखकों ने भी इसकी सीमाएँ मानी थीं और काफ़ी पहले अगले चरण पर बढ़ गए थे

  • SWE-Bench Pro को SWE-Bench की जगह लेने और ऐसी समस्याएँ ठीक करने के लिए बनाया गया था

• मैं समझ सकता हूँ कि यह खराब benchmark क्यों बन सकता है, लेकिन अगर समस्या यह है कि बहुत सख़्त tests prompt में स्पष्ट न किए गए कुछ implementation details को मजबूर करते हैं और इस तरह functionally सही submissions को भी अमान्य कर देते हैं, अपर्याप्त prompts उन requirements को छोड़ देते हैं जिन्हें hidden tests लागू करते हैं लेकिन जिनका उचित अनुमान नहीं लगाया जा सकता, low-coverage tests माँगी गई functionality को कम जाँचते हैं इसलिए अधूरे fixes भी pass हो जाते हैं, और भ्रामक prompts model को गलत behavior की ओर ले जाते हैं या test requirements से टकराते हैं — तो अगर लक्ष्य वास्तविक software engineers और models की तुलना है, तो यह काफ़ी यथार्थवादी स्थिति है
  यह वैसा ही है जैसे nursing exam बनाकर बाद में कुछ सवाल इसलिए मार्क करना कि chart में न होने वाली अतिरिक्त जानकारी attending physician से पूछी जानी चाहिए थी, या patient के परिवार ने एक बुज़ुर्ग दादी की medical history ठीक से नहीं समझाई। आप अधिक कठोर benchmark चाह सकते हैं, लेकिन अगर OpenAI ने model को असली workers के विकल्प के रूप में पेश किया है, तो यह अच्छी तस्वीर नहीं है। बल्कि आप ऐसी ही चीज़ों को test करना चाहेंगे

• यह कुछ ऐसा पढ़ाई देता है जैसे “benchmark को ठीक करने के लिए ज़रूरी सारा काम कर लिया, और आखिर में benchmark को छोड़ने का फ़ैसला किया।” क्या आधारभूत data इतना दुर्लभ है कि उसे patch नहीं किया जा सकता? अंत में वे benchmark निर्माण के लिए थोड़ा अधिक चुनींदा approach सुझाते हैं, लेकिन मुझे लगता है कि वास्तविक data से आए गंदे और अपूर्ण tests को निष्पक्ष रूप से patch करने का तरीका भी काफ़ी मज़बूत रास्ता है

  • मुझे लगता है कि SWE Bench Pro से हटने की कोई और वजह है जिसे वे बताना नहीं चाहते। लेख की शुरुआत में वे कहते हैं कि “लगभग 30% tasks टूटे हुए थे”, लेकिन इसका मतलब यह भी है कि लगभग 70% टूटे हुए नहीं थे, और वह अनुपात काफ़ी ठीक लगता है
    अच्छा होता अगर वे यह भी बताते, “टूटे हुए instances की सूची यहाँ है” या “आगे हम SWE Bench Pro का यह subset इस्तेमाल करेंगे।” वे perfection को good के रास्ते में आने दे रहे हैं
  • समस्याएँ बताना, जैसे यह कहना कि hidden tests संकरे implementation details मानकर चलते हैं, उन tests को बनाने से कहीं आसान है जो किसी भी implementation choice के साथ काम करें
  • अगर आप उसे ठीक कर दें, तो क्या वह फिर भी SWE-Bench Pro रहेगा? वह “SWE-Bench-Pro-Fixed-OpenAI” बन जाएगा। benchmark की स्वतंत्रता की छवि को देखें तो OpenAI टीम के खुद ठीक करने के बजाय किसी third party द्वारा संशोधित और बेहतर संस्करण जारी करना ज़्यादा अच्छा लगता है
    हालाँकि OpenAI ने SWE-Bench Verified जारी करते समय लगभग यही किया था, इसलिए हो सकता है मैं बकवास कर रहा हूँ

• अभी SWE benchmark का state of the art किसे माना जाए?

  • व्यक्ति के लक्ष्य और ज़रूरतों पर निर्भर करते हुए मैं DeepSWE[0] या FrontierCode[1] कहूँगा। दूसरा मुझे व्यक्तिगत रूप से ज़्यादा दिलचस्प लगता है, क्योंकि इसे mergeability को मज़बूती से मापने के लिए डिज़ाइन किया गया है — यानी दिया गया output review करना कितना आसान है, और क्या कोई गंभीर developer उसे आसानी से समझकर merge करने को तैयार होगा
    मेरी सोच और निजी मूल्यांकन में काफ़ी समय से यह रहा है कि किसी model की संभावित upper bound भले अधिक हो, लेकिन अगर मुझे उस code पर सच में approval sign-off देने का भरोसा नहीं है, तो उसका मूल्य सीमित है
    [0] https://deepswe.datacurve.ai/
    [1] https://cognition.com/blog/frontier-code-1.1
  • कुल मिलाकर मुझे DeepSWE[0] वास्तविकता के काफ़ी करीब लगा
    [0]: https://deepswe.datacurve.ai/

• https://cognition.ai/blog/frontier-code है। स्पष्ट कर दूँ, मैं उस टीम में था, लेकिन यहाँ swebench pro/deepswe समस्याएँ भी कवर की गई थीं

  • FrontierBench

• AGI हासिल करना सिर्फ़ सभी benchmarks पास करने से ज़्यादा होना चाहिए, और इसमें अज्ञात समस्याओं को भी शामिल करना चाहिए

  • अगर किसी research lab के भीतर अभी के product से काफ़ी अलग कोई चीज़ मौजूद नहीं है, तो AGI चर्चा का विषय नहीं है और लगभग पूरी तरह marketing के लिए किया गया बढ़ा-चढ़ाकर दावा है
  • AGI अभी भी बहुत दूर है। हाँ, अगर कोई ऐसा LLM marketing term है जिसे मैं नहीं जानता और उसे “AGI” कहा जाता है, तो अलग बात है। Artificial General Intelligence, LLM या image AI से इतना अलग है कि दोनों की तुलना सिर्फ़ इस आधार पर ही की जा सकती है कि वे कृत्रिम हैं। AGI को token prediction से कहीं ज़्यादा काम करना होगा
  • यह non-LLM models बनाते समय आम bias-variance tradeoff(https://en.wikipedia.org/wiki/Bias%E2%80%93variance_tradeoff) से जुड़ता है
    इसका हल सिर्फ़ यही है: a) LLM को समान प्रदर्शन के साथ इतना छोटा बनाया जाए कि वह memorization न कर सके या benchmark को target न कर सके, या b) ऐसा benchmark बनाया जाए जो पूरे वास्तविक दुनिया के data को कवर करे; लेकिन दूसरा विकल्प व्यावहारिक नहीं है