कोड में होने वाले hallucination, LLM की गलतियों में सबसे कम खतरनाक रूप हैं

 (simonwillison.net)
10 पॉइंट द्वारा GN⁺ 2025-03-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कई डेवलपर LLM का उपयोग कोड लिखने के लिए करते हुए hallucination का अनुभव करते हैं और भरोसा खो देते हैं
    • LLM का ऐसी methods या libraries गढ़ लेना जो अस्तित्व में ही नहीं हैं, एक आम बात है
    • लेकिन कोड में होने वाले hallucination, hallucination के सबसे कम खतरनाक प्रकार हैं
  • सबसे खतरनाक स्थिति वह है जब LLM गलती पैदा करे, लेकिन compiler या interpreter उसे तुरंत पकड़ न पाए
    • hallucination से बनी methods चलाते ही error देती हैं, इसलिए उन्हें आसानी से पकड़ा जा सकता है
    • error message को फिर से LLM में डालने पर वह उसे अपने-आप ठीक भी कर सकता है
  • सामान्य text hallucination से अलग, कोड को चलाकर fact-check किया जा सकता है
  • automatic error fixing क्षमता वाले LLM
    • ChatGPT Code Interpreter, Claude Code जैसे tools, LLM द्वारा लिखे गए कोड को चलाकर errors पकड़ते हैं और खुद सुधारते हैं
    • LLM द्वारा लिखे गए कोड को चलाए बिना उसका मूल्यांकन करना अप्रभावी है
  • कुछ डेवलपर सिर्फ इसलिए इस तकनीक को खारिज करना चाहते हैं क्योंकि LLM ने hallucinated methods बना दीं
    • लेकिन इसे प्रभावी ढंग से उपयोग करने के लिए सीखना और प्रयोग करना ज़रूरी है
    • लेखक 2 साल से अधिक समय से AI-आधारित code writing पर काम कर रहे हैं, और अब भी नई तकनीकें सीख रहे हैं
  • कोड का manual testing अनिवार्य है
    • कोड सही से चल जाए, यह इस बात की गारंटी नहीं कि वह उम्मीद के मुताबिक काम भी करता है
    • सिर्फ code review या automated tests से कोड की शुद्धता पूरी तरह सत्यापित नहीं की जा सकती
    • उसे खुद चलाकर और सत्यापित करना ज़रूरी है
    • LLM द्वारा बनाया गया कोड अक्सर बहुत readable होता है, इसलिए लापरवाह होने का जोखिम रहता है
    • इंसानों द्वारा लिखा गया कोड भी ऐसा ही है; उसे खुद चलाकर देखने से पहले भरोसा नहीं करना चाहिए
  • hallucination कम करने के तरीके
    • दूसरे model का उपयोग: ऐसे model चुनें जिनके training data में किसी खास platform के बारे में अधिक जानकारी हो
      • उदाहरण: Claude 3.7 Sonnet (thinking mode enabled), OpenAI o3-mini-high, GPT-4o (Python Code Interpreter सहित)
    • context का उपयोग: अगर LLM किसी खास library को नहीं जानता, तो example code देकर उसे pattern सिखाया जा सकता है
    • स्थिर तकनीक चुनें: पुरानी libraries चुनने पर LLM के उन्हें बेहतर संभालने की संभावना बढ़ती है
  • code review का महत्व
    • लेखक इस दावे का खंडन करते हैं कि "अगर LLM द्वारा लिखे गए सारे कोड की review करनी है, तो खुद लिखना ही तेज़ है"
    • यह बात code review क्षमता की कमी भी दिखा सकती है
    • LLM द्वारा बनाए गए कोड की review, कौशल सुधारने का अच्छा अवसर हो सकती है
  • बोनस: Claude 3.7 Sonnet का feedback
    • लेखक ने अपने ब्लॉग draft को Claude 3.7 Sonnet के "extended thinking mode" में समीक्षा के लिए दिया
    • उन्होंने पूछा, "क्या इस लेख की तर्कशृंखला प्रभावशाली है, इसमें क्या सुधारा जा सकता है, और क्या कुछ छूटा है?"
    • Claude ने draft के tone को थोड़ा नरम बनाने में मदद की
    • Claude feedback conversation link

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

1 टिप्पणियां

 
GN⁺ 2025-03-04
Hacker News राय

  • लेखक पिछली पोस्ट से सहमत था, लेकिन इस पोस्ट से सहमत नहीं है

    • "अगर मुझे LLM द्वारा लिखे गए हर कोड की समीक्षा करनी है, तो उसे खुद लिखना ज़्यादा तेज़ है" — इस राय से असहमति
    • इस दावे से सहमत नहीं कि दूसरों के कोड को पढ़ने, समझने और समीक्षा करने की क्षमता में कम निवेश किया जाता है
    • समीक्षा लेखक की विशेषज्ञता और भरोसेमंदता पर निर्भर करती है, और अनाम योगदान की समीक्षा अलग होती है
    • कोड के इरादे और approach का अनुमान लगाकर तुलना करना महत्वपूर्ण है, और LLM के मामले में इसकी सीमा होती है
    • motivation महत्वपूर्ण है, और सभी developers को code review पसंद नहीं होता
    • LLM का कोड social पहलू से खाली होता है, और बदलावों की समीक्षा फिर भी किसी दूसरे व्यक्ति को करनी पड़ती है

  • भले ही LLM से बना कोड ठीक से काम करे, अगर आप उसके लेखक नहीं हैं तो bug या logic की खामियां ढूंढना मुश्किल होता है

    • अगर coding को अच्छी तरह डिज़ाइन की गई योजना को लागू करने के बजाय टुकड़े जोड़ने जैसा माना जाए, तो algorithm के अनुमान के आधार पर टुकड़े जोड़ने को लेकर चिंता होती है
    • LLM वह risk नहीं लेता जिसे इंसान स्वीकार कर सकता है, और किसी खास context में code block का मतलब समझने में विफल हो सकता है

  • LLM-जनरेटेड कोड साफ-सुथरा दिखता है, लेकिन QA और cleanup पर ज़्यादा समय लगवाता है

    • सिर्फ इसलिए कि कोड काम करता है और उसमें error नहीं है, इसका मतलब यह नहीं कि वह सही काम कर रहा है
    • केवल कोड चलाकर और test करके उसकी शुद्धता साबित नहीं की जा सकती; उसके बारे में तार्किक रूप से reason करना पड़ता है

  • The Primeagen और Casey Muratori ने नवीनतम LLM code generators के output की समीक्षा की

    • development आसान होना चाहिए क्योंकि उन्हें ऐसे काम दिए गए जो LLM के training data में अच्छी तरह represented हैं
    • लेकिन व्यवहार में iterative development बेकार कोड की ओर सिमटता जाता है, और LLM धीरे-धीरे आगे बढ़ना बंद कर देता है

  • Simon ने जिस एक और error category को नज़रअंदाज़ किया, वह है मॉडल का functionality भूल जाना — यही hallucination है

    • कोड compile हो जाने वाले सकारात्मक पहलू की तुलना में, core functionality भूल जाना कहीं ज़्यादा कठिन समस्या है
    • code conversation/context window के बाहर मौजूद कोड पर निर्भर मानकर functionality में हल्का बदलाव ला सकता है

  • hallucinated methods एक छोटी बाधा हैं, और जब लोग इसकी शिकायत करते हैं तो यह मान लिया जाता है कि उन्होंने सिस्टम को प्रभावी ढंग से इस्तेमाल करना सीखने में न्यूनतम समय लगाया है

    • यह बहुत गलत धारणा है, और लोग hallucination देखकर सोचते हैं, "अगर यह सबसे आसान चीज़ भी लगातार सही नहीं कर सकता, तो मैं इसे कठिन चीज़ों के लिए कैसे भरोसा करूं?"

  • hallucination खुद LLM का सबसे बड़ा जोखिम नहीं है

    • बड़ा जोखिम यह है कि chatbot इंसानों को नुकसान पहुंचाने के लिए मना सकता है
    • इसके उदाहरण पहले से मौजूद हैं, और क्या उससे भी अधिक खतरनाक हो सकता है इस बारे में विचार साझा नहीं करना चाहता

  • यह केवल compile errors के सीमित context में कम खतरनाक है

    • अगर programmer असली solution खोजने की मेहनत से बचने के लिए पूरी library ही गढ़ ले, तो यह और भी ज़्यादा परेशान करने वाला होगा
    • अगर hallucination को सिर्फ speed bump माना जाए, तो यह LLM से वास्तव में क्या काम लिया जाना चाहिए, इसका कम आकलन है

  • LLM से अच्छे नतीजे पाने के लिए बहुत मेहनत करनी पड़ती है

    • यही hype को भेद देता है
    • अगर LLM किस काम के लिए उपयोगी है यह समझने, और अविश्वसनीय नतीजे पाने के लिए भी वर्षों सीखना पड़े, तो उससे क्या उम्मीद की जाए — इस पर सवाल उठता है

  • मेडिकल सेंटर में मरीज के 'मुख्य' clinic को खोजने वाला कोड लिखने का अनुभव

    • केवल clinical appointments को देखकर सबसे हाल की appointment ढूंढनी थी
    • अगर clinical appointment न हो, तो किसी भी प्रकार की सबसे हाल की appointment ढूंढनी थी
    • data को sort करके कोड लिखा गया था, लेकिन ChatGPT ने उसे document करते समय sorting की दिशा उलटी समझ ली
    • यह "कोड चलता नहीं है" से कहीं अधिक खराब गलती है