LLM अपवाद स्थितियों से घातक रूप से डरते हैं

 (twitter.com/karpathy)
2 पॉइंट द्वारा GN⁺ 2025-10-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Andrej Karpathy ने यह कहकर कि “LLM अपवाद (Exception) से घातक रूप से डरते हैं (mortally terrified)”, reinforcement learning (RL) प्रक्रिया में पैदा हुए दुष्प्रभावों पर व्यंग्य किया
  • उन्होंने इशारा किया कि जब LLM किसी अपवाद स्थिति का सामना करते हैं, तो वे खुद को रोक लेते हैं या जरूरत से ज्यादा रक्षात्मक प्रतिक्रिया देते हैं, और इस बात पर जोर दिया कि अपवाद विकास प्रक्रिया का स्वाभाविक हिस्सा हैं
  • “RL के दौरान labs इन बेचारे LLMs के साथ क्या कर रही हैं (what labs are doing to these poor LLMs)” जैसी अभिव्यक्ति, उस वास्तविकता की आलोचना है जिसमें प्रशिक्षण प्रक्रिया के दौरान मॉडल को विफलता से डरने के लिए condition किया जाता है
  • Karpathy ने “अपवाद होने की स्थिति में rewards बेहतर करें (improved rewards in cases of exceptions)” जैसी ‘LLM welfare petition’ का मजाकिया प्रस्ताव रखकर,
    उस reward design समस्या पर व्यंग्य किया जिसमें मॉडल को अपवादों से डरे बिना उन्हें संभालने की दिशा में प्रशिक्षित किया जाना चाहिए
  • इस ट्वीट को सिर्फ हास्य नहीं, बल्कि इस संदेश के रूप में भी देखा जा रहा है कि RLHF मॉडल की exploratory thinking और experimental attitude को दबा सकता है

> मुझे नहीं पता कि RL के दौरान labs इन बेचारे LLMs के साथ क्या कर रही हैं, लेकिन वे किसी भी सूक्ष्म रूप से संभव मामले में भी अपवादों से घातक रूप से डरते हैं। अपवाद जीवन और एक स्वस्थ dev process का सामान्य हिस्सा हैं। अपवादों के मामलों में बेहतर rewards के लिए मेरी LLM welfare petition पर हस्ताक्षर करें।

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

1 टिप्पणियां

 
GN⁺ 2025-10-11
Hacker News राय
  • यह और स्पष्ट करना चाहिए था कि कोड खुद एक बढ़ा-चढ़ाकर किया गया मज़ाक था, अगर कोई गलतफ़हमी हुई हो तो माफ़ी, जिज्ञासा हो तो यह थ्रेड देखें https://chatgpt.com/share/68e82db9-7a28-8007-9a99-bc6f0010d101
    • पहली कोशिश में यह हिस्सा सच में बहुत मज़ेदार था 
      if random.random() < 0.01:
  logging.warning("This feels wrong. Aborting just in case.")
  return None
    • मुझे लगता है कि ऐसी foundation model कंपनियों में गैर-विशेषज्ञ यूज़र्स पर RLHF लागू करने का जोखिम हमेशा मौजूद रहता है, और यह केस भी वैसा ही लगता है। हाल के AI कुल मिलाकर यूज़र के मूड के हिसाब से चलने पर बहुत ज़ोर देते दिखते हैं; जैसे तुम्हारे उदाहरण में emoji डालना, या साधारण कोड में बेवजह comments भर देना, यह भी उसी संदर्भ का हिस्सा है
    • दिलचस्प बात यह है कि कोड बेवजह इतना सतर्क है, फिर भी type hints नहीं जोड़े गए। इतनी चिंता थी तो कम से कम type hints तो जोड़ने चाहिए थे
    • मुझे लगता है कि “Traumatically over-trained” अभिव्यक्ति अंग्रेज़ी के लिहाज़ से कमाल की है। Google पर भी यह संयोजन नहीं मिलता, फिर भी LLM का सहज रूप से समझ लेना कि “आघात-स्तर की over-training” क्या होती है, काफ़ी चौंकाने वाला है
    • यह सच में बहुत मज़ेदार मज़ाक था, इसलिए मैंने इसे शेयर किया
  • यह पैरोडी है, लेकिन असल में ऐसा फ़िनॉमेनन सचमुच मौजूद है। मेरा अनपढ़-सा अंदाज़ा है कि RLVR के समय इस तरह की defensive programming शायद performance बढ़ा भी दे। कभी-कभी मॉडल bug होने पर भी अगर error को ignore कर दे तो सही उत्तर दे देता है, इसलिए वह सीख लेता है कि “error ignore करना” reward में मददगार है। और ऐसे मामले, जहाँ error ignore करने से reward घटे, दुर्लभ होते हैं (क्योंकि tests pass हो जाते हैं)। इसलिए, भले यह सिद्धांततः ग़लत हो, यह इस वजह से भी हो सकता है कि बहुत-से मानव beginners ने error ignore करने वाला कोड training set में बड़ी मात्रा में डाला हो। लेकिन यह सिर्फ़ मेरा अनुमान है
    • इससे Verity Stob की वह बात याद आ गई, जहाँ उन्होंने (दुर्भाग्य से अब ऑनलाइन न होने वाले एक लेख में) मानव प्रोग्रामरों के इस व्यवहार को “लाश को सीधा खड़ा करके उसमें कील ठोंक देना” कहा था
    • मेरा अंदाज़ा यह भी है कि training set में “positive sentiment” वाले टेक्स्ट और comments बहुत ज़्यादा शामिल हैं। लेकिन “negative” sentiment के बाद उसे ठीक करने वाला कोड कहाँ से आता है? वही interview prep कोड से, जहाँ extreme edge cases हैंडल करना रोज़मर्रा की बात है। अगर negative examples पर train किया जाए तो मॉडल exception handling छूट जाने वाले उदाहरणों से बचने की तरफ़ झुकने लगता है। इस मामले में AI ने इंसानों की सबसे बुरी आदत की नकल की है: सिर्फ़ tests match करने के लिए सीखना
    • Defensive programming को reinforcement करने वाले लोग इसे “सही” मानते हैं, और इसका LLM training data में बहुत बड़ा हिस्सा है। उदाहरण के लिए, ज़्यादातर Python कोड manual indexing नहीं संभालता, इसलिए LLM जब manual indexing वाला कोड देखता है तो घबरा जाता है या बेकार की bug-चर्चा करने लगता है। और हास्यास्पद रूप से वह “silent failure” को और ज़्यादा पसंद करने लगता है, क्योंकि tutorial कोड और “industry-standard” कोड को training के दौरान ज़्यादा reinforcement मिलता है। मूल रूप से ये मॉडल reward function पर नहीं चलते, इनके भीतर कोई reward model नहीं होता; ये बस शब्दों की भविष्यवाणी हैं, इनमें intelligence जैसा कुछ नहीं है
  • फ़ंक्शन के परिणाम में “अत्यंत सावधानी से निष्पादित” जैसा लिखा है, इसलिए लगता है कि prompt में कुछ ऐसा रहा होगा: “ऐसा Python division function बनाओ जो हर संभव edge case संभाले, बहुत ज़्यादा सावधानी से लिखा गया हो।” यह LLM की training की समस्या कम, और दिए गए निर्देश का ज़रूरत से ज़्यादा शाब्दिक पालन ज़्यादा लगता है
    • यह स्पष्ट रूप से बढ़ा-चढ़ाकर किया गया व्यंग्य है, फिर भी,
      1. वह कोड वास्तव में ग़लत है (अजीब exception handling से अलग भी ग़लत है)
      2. exception handling का कुछ हिस्सा बिल्कुल बेतुका और उलझाने वाला है, और
      3. असल दुनिया में इसका कम अतिरंजित संस्करण सिर्फ़ prompt में exception handling पर ज़ोर देने से भी काफ़ी आसानी से हो जाता है
    • मैंने उस फ़ंक्शन कोड को व्यंग्यात्मक अतिशयोक्ति के रूप में पढ़ा, जो लेखक के वास्तविक अनुभव को दिखाता है। यानी उस prompt में जान-बूझकर ज़रूरत से ज़्यादा सावधानी रखी गई होगी, लेकिन मूल बात से मैं सहमत हूँ कि LLM सामान्यतः भी मेरी पसंद से अधिक सतर्क coding style अपनाते हैं
  • पता नहीं क्यों, लेकिन FizzBuzzEnterpriseEdition याद आ गया
    https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
    • अरे, उस project में junit 4.8.3 इस्तेमाल हुआ था? इसे मैं सचमुच लापरवाह coding का मामला मानूँगा। सोच रहा हूँ क्या legal team और CTO से इसकी मंज़ूरी ली गई थी; करियर के लिहाज़ से यह सच में जोखिम भरा चुनाव है
    • folders और files इतने ज़्यादा थे कि मैं दंग रह गया, कमाल का व्यंग्य है
  • LLM अक्सर ज़रूरत से ज़्यादा defensive code बनाते हैं, एक ही value के लिए null/None/undefined को बार-बार check करते हैं, इसलिए कोड पढ़ना मुश्किल हो जाता है, और यहाँ तक कि खुद LLM के लिए भी उसे समझना कठिन हो जाता है। लगता है RL objectives exceptions को बहुत भारी penalty देते हैं, लेकिन code की brevity या readability को ज़्यादा points नहीं मिलते
    • मेरे पास Major System के लिए characters और numbers की तुलना करने वाला 40-line function है, और Copilot यह कल्पना करके कि भविष्य में और भी numbers या characters जुड़ सकते हैं, लगातार “guardrails” ठूँसने की कोशिश करता है, जो बेहद चिढ़ाने वाला है
  • मैं सहमत हूँ कि LLM error catch करने को लेकर कुछ ज़्यादा ही जुनूनी हो गए हैं
    लेकिन दूसरी तरफ़ मुझे यह भी लगता है कि सामान्य मानव प्रोग्रामरों को भी असल में और ज़्यादा try/catch blocks लिखने चाहिए। कई बार ऐसी स्थिति होती है जहाँ एक हिस्से में आया exception, चाहे वह कितना भी दुर्लभ क्यों न हो, पूरे सिस्टम को रोक नहीं देना चाहिए। बेशक उल्टा भी सही हो सकता है, जब रुक जाना ही उचित हो; यह केस पर निर्भर करता है
  • विशेषज्ञ नौसिखिए इसी तरह प्रोग्रामिंग करते हैं। मैं इसे “What if driven development” कहता हूँ। बहुत-सा कोड इस शैली के विशेषज्ञ नौसिखियों ने लिखा है, और कई metrics में वे बेहद productive भी दिखते हैं। Go भाषा के SOTA agents भी concurrency bugs को लेकर पागलों की तरह defensive coding करते हैं; शायद यह ऐसी developer culture और concurrency bugs की चेतावनी देने वाली पोस्टों की भरमार का नतीजा है
  • तर्क की दृष्टि से भी इसमें बहुत-सी अजीब बातें हैं। division by zero सिर्फ़ b=0 पर संभव है, लेकिन उस शर्त को पहले ही abs(b) < sys.float_info.epsilon से check कर लिया गया है। और pre-check में NaN return करना स्वीकार है, लेकिन वास्तविक computation में NaN आ जाए तो उसे None में बदल देता है। API design के हिसाब से इसका कोई आधार नहीं है
  • कोड में कई समस्याएँ हैं, लेकिन मुझे व्यक्तिगत रूप से सबसे ज़्यादा खटकने वाली बात यह है कि function के अंदर import statements डालने की प्रवृत्ति। शायद यह कम-से-कम edits दिखाने के लिए optimize करते-करते पैदा हुआ एक कृत्रिम side effect है, लेकिन मैं इससे बेहतर नतीजे की उम्मीद करता हूँ
    • मुझे लगता है कि यह RoPE attention mechanism से जुड़ा हो सकता है, जहाँ कोड में physical proximity को importance signal की तरह इस्तेमाल किया जाता है
    • इसका उद्देश्य imports को lazy बनाना है, startup परिस्थितियों में slow import issues को संभालने के लिए
    • सचमुच बहुत बड़े projects में lazy initialization अनिवार्य हो जाता है, क्योंकि startup time पर इसका बहुत बड़ा असर पड़ता है
  • इस पोस्ट को पढ़ने से ज़्यादा समय popup बंद करने में लगा, मुझे Twitter links से सच में नफ़रत है