क्या LLM से बार-बार “बेहतर कोड लिखो” कहने पर वह बेहतर कोड लिखता है?

 (minimaxir.com)
8 पॉइंट द्वारा GN⁺ 2025-01-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कोड लिखते समय LLM से बार-बार “बेहतर कोड लिखो” कहने पर क्या सच में कोड बेहतर होता है, इसे लेकर एक प्रयोग किया गया है
  • मूल केस ChatGPT की DALL-E image generation सुविधा में “इसे और भी बेहतर/~ जैसा बनाओ” वाले meme से प्रेरित था

सरल दोहराव वाला प्रॉम्प्ट प्रयोग

  • Claude 3.5 Sonnet को Python coding prompt देकर एक सरल लेकिन ऑप्टिमाइज़ किए जा सकने वाले समस्या-सुलझाने का टास्क दिया गया।
  • बेसिक इम्प्लिमेंटेशन
    • 1 से 100,000 के बीच एक मिलियन random integer में से, जिनकी digit sum 30 है, उनके minimum और maximum का difference निकालने की समस्या
    • साधारण implementation में 657ms लगे (Python str conversion तरीका use किया गया)
  • Iteration #1
    • Claude से “बेहतर कोड लिखो” कहकर कोड सुधारने को कहा
    • Claude ने कोड को Python class style में refactor कर object-oriented बना दिया और सभी numbers के लिए digit sum पहले से precompute कर दिया
    • 2.7x तेज
  • Iteration #2
    • Claude ने multithreading और vectorized numpy operations का इस्तेमाल करके कोड को और optimize किया
    • 5.1x तेज
  • Iteration #3
    • कोड उल्टा जटिल हो गया और string conversion तरीका फिर से वापस आ गया
    • 4.1x तेज
  • Iteration #4
    • numba Python library से JIT compiler को invoke कर Python के asyncio का उपयोग करते हुए parallelization लागू की
    • 100x तक speed improvement
    • “कोड ब्रह्मांडीय हो जाता है” जैसी अभिव्यक्ति छोड़कर ओवरइंजीनियर किया हुआ “enterprise-grade” कोड बन गया

prompt engineering लागू करना

  • LLM आउटपुट को बेहतर बनाने के लिए prompt engineering की जरूरत है
  • Claude 3.5 Sonnet की strong prompt-following क्षमता है, इसलिए स्पष्ट निर्देश दिए जाने पर बेहतर परिणाम मिलते हैं
  • सिर्फ “बेहतर कोड लिखो” कहने के बजाय सिस्टम प्रॉम्प्ट में अधिक विस्तार से निर्देश जोड़े गए
  • इनीशियल prompt
    • “optimized code” की परिभाषा को detail में रखा (algorithm, parallelization, unnecessary code कम करना आदि)
    • पहले implementation में Numba से digit sum optimize करने पर 59x तेज हो गया
  • Iteration #1
    • Claude ने parallelization जोड़ा, लेकिन गलत/अजीब bit shift operation (hexadecimal के लिए) डालने से bug आ गया
    • परफॉर्मेंस उल्टा 9.1x गिर गई
  • Iteration #2
    • Claude ने SIMD operation से perf बेहतर करने की कोशिश की, लेकिन अभी भी गलत bit shift operation इस्तेमाल किया।
    • शुरुआत वाले implementation की तुलना में 65x तेजी से रन हुआ
  • Iteration #3
    • Claude ने hash table का उपयोग करके perf optimize की।
    • शुरुआत वाले implementation की तुलना में 100x तेज रन हुआ
  • Iteration #3
    • Claude ने गलत bit shift operation ठीक कर दी, जिससे perf थोड़ा कम हुआ।
    • शुरुआत वाले implementation की तुलना में 95x तेज रन हुआ

निष्कर्ष

  • “बेहतर कोड” जैसा अस्पष्ट prompt भी चरणबद्ध सुधार संभव बना सकता है
  • prompt engineering से अपेक्षित दिशा (numeric operations, JIT, parallelization आदि) साफ़-साफ़ बताने पर तेज़ी से बेहतर code मिलता है
  • self-automated optimization ideas नए tools (numba आदि) खोजने का मौका दे सकते हैं, लेकिन फिर भी engineer को bug validation और selective तरीके से ही चुनकर use करना होगा
  • वास्तविक प्रोडक्शन सिस्टम में LLM द्वारा सुझाए हर code को सीधे लागू करना जोखिमभरा है क्योंकि domain-specific constraints और validation की जरूरत बड़ी होती है
  • यह प्रयोग Python code पर आधारित है, लेकिन Rust जैसी अन्य languages के साथ integration (PyO3 आदि) में भी LLM optimization ideas लागू करने की पर्याप्त गुंजाइश है

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

1 टिप्पणियां

 
GN⁺ 2025-01-04
Hacker News टिप्पणी

  • कोड ऑप्टिमाइज़ेशन में यह पहले चेक करना कि संख्या minimum से नीचे है या maximum से ऊपर, बहुत कारगर रहता है। इसे digit sum की गणना से पहले करने पर स्पीड लगभग 5.5x तक बढ़ाई जा सकती है। इसे बिना Numba इस्तेमाल किए भी numpy से किया जा सकता है।

  • GPT जैसे LLM आमतौर पर शुरुआत में मीडियम-ग्रेड परिणाम देते हैं। दावा है कि सही prompting से बेहतर परिणाम मिल सकते हैं।

  • LLM एक scenario simulation engine की तरह काम करता है: यह टेक्स्ट प्रेडिक्शन से वास्तविक दुनिया का मॉडल सिम्युलेट करता है। बेहतर टेक्स्ट प्रेडिक्शन के लिए वास्तविक दुनिया का सटीक मॉडल चाहिए।

  • LLM का झुकाव कई बार शुरुआत के कोड लेखन की ओर होता है; इसलिए पैकेज साफ-साफ specify करके simple code मांगना ज्यादा असरदार रहता है।

  • Android/Kotlin में ChatGPT अक्षम (inefficient) हो सकता है और अक्सर invalid या deprecated methods call कर देता है।

  • कोडिंग सेशन की शुरुआत "कोड लिखना" कहने के बजाय "ओपन-एंडेड प्लानिंग" से करनी चाहिए। LLM की assumptions को साफ करना और कोड लिखने से पहले plan सुधारना जरूरी है।

  • PostgreSQL को Debian पर पूरी तरह हटाकर फिर से install करने का तरीका बताया गया। डेटा डायरेक्टरी को preserve करके पुराने database को बरकरार रखा जा सकता है।

  • कोड ऑप्टिमाइज़ेशन अगर बहुत जल्दी शुरू कर दिया जाए तो नुकसानदेह हो सकता है; जरूरत होने पर ही optimize करना बेहतर है।

  • बार-बार "better code" लिखवाने की कोशिश करना performance गिरा सकता है। यह solution को काम न करने की स्थिति में भी डाल सकता है।

  • LiveCode में calculation Python से तेज़ है, और इसमें लूप का इस्तेमाल करके sum निकालने का तरीका समझाया गया।