LLM और 2024 की शुरुआत में प्रोग्रामिंग के रुझान
(antirez.com)- ChatGPT और लोकल LLM अब अनुभवी प्रोग्रामरों के लिए सीधे कोड लिखने से ज़्यादा, दस्तावेज़ खोजने, जटिल API सीखने, और थोड़ी देर में फेंक दिए जाने वाले प्रोग्राम लिखने जैसे थकाऊ कामों को कम करने वाले टूल बन गए हैं
- LLM कोई अलौकिक बुद्धि नहीं हैं, बल्कि ट्रेनिंग डेटा के दायरे के भीतर सीमित रूप से interpolation करते हैं; लेकिन प्रोग्रामिंग जैसे उन क्षेत्रों में जहाँ उच्च-गुणवत्ता वाला डेटा बहुत है, वे “बहुत कुछ जानने वाले मूर्ख” की तरह काफ़ी उपयोगी हो सकते हैं
- PyTorch tensor reshaping, macOS Objective-C BLE client, ONNX मॉडल के input/output की व्याख्या, और CSV analysis script जैसे जिन समस्याओं के नतीजे सत्यापित किए जा सकते हैं उनमें GPT-4 काम का समय काफ़ी घटा देता है
- C-आधारित system programming और algorithm implementation जैसे जटिल reasoning वाले कामों में Bloom filter hash design और llama.cpp Q6_K quantization format की व्याख्या करते समय इसकी सीमाएँ सामने आती हैं
- अगर प्रोग्रामिंग का बड़ा हिस्सा पुराने pattern को थोड़ा बदलकर दोहराने का काम है, तो LLM का अच्छे से उपयोग करने की क्षमता और समस्या को स्पष्ट रूप से समझाने की क्षमता और ज़्यादा महत्वपूर्ण हो जाती है
अनुभवी प्रोग्रामर LLM का उपयोग क्यों करते हैं
- LLM के उपयोग का उद्देश्य सिर्फ़ कोड को तेज़ी से लिखना नहीं है
- अजीब या मुश्किल दस्तावेज़ खोजना
- ज़रूरत से ज़्यादा जटिल API सीखना
- कुछ घंटों बाद फेंक दिए जाने वाले प्रोग्राम लिखना
- बौद्धिक रूप से दिलचस्प न लगने वाली बारीकियों को संभालना
- Google के spam से भरे search space में बदल जाने के बाद, LLM ज़रूरी जानकारी जल्दी पाने का वैकल्पिक रास्ता बन गए हैं
- Python जैसे high-level code में LLM का उपयोग बढ़ा है, लेकिन C code में इसका उपयोग बहुत कम है
- असली फ़र्क यह पहचानने में है कि LLM कब काम को तेज़ करता है और कब उल्टा धीमा कर देता है
- Wikipedia या YouTube lecture की तरह, LLM भी इच्छाशक्ति, क्षमता और अनुशासन वाले लोगों के लिए बहुत मददगार हैं, जबकि पीछे चल रहे लोगों के लिए उनकी सीमाएँ हो सकती हैं
LLM न तो सर्वज्ञ हैं, न ही सिर्फ़ तोता
- neural network और LLM की आंतरिक कार्यप्रणाली अभी भी काफ़ी अस्पष्ट है
- कुछ AI विशेषज्ञों ने LLM को advanced Markov chain या ट्रेनिंग डेटा की विकृत पुनरावृत्ति करने वाली प्रणाली मानकर कम आँका, लेकिन ऐसे “तोता” दृष्टिकोण को सबूतों के सामने ज़्यादातर वापस लेना पड़ा
- दूसरी ओर, LLM को ऐसी अलौकिक क्षमताएँ देना जो वास्तविकता में हैं ही नहीं, वह भी ग़लत है
- LLM ट्रेनिंग के दौरान देखे गए डेटा से बने स्पेस के भीतर सीमित रूप से interpolation कर सकते हैं
- वे ऐसे प्रोग्राम भी लिख सकते हैं जिन्हें उन्होंने ठीक उसी रूप में पहले नहीं देखा हो
- वे ट्रेनिंग डेटा में बार-बार आने वाले कई विचारों को मिलाकर काम कर सकते हैं
- लेकिन जहाँ सूक्ष्म reasoning चाहिए, वहाँ वे बुरी तरह असफल हो सकते हैं
- इन सीमाओं के बावजूद, LLM को AI के इतिहास की सबसे बड़ी उपलब्धियों में से एक माना जा सकता है
“बहुत कुछ जानने वाले मूर्ख” के रूप में प्रोग्रामिंग सहायक
- LLM बुनियादी और अक्सर ग़लत reasoning, hallucination, और अस्तित्वहीन तथ्यों की रचना कर सकते हैं
- साथ ही, प्रोग्रामिंग जैसे ऐसे क्षेत्रों में जहाँ अच्छी गुणवत्ता का डेटा बहुत है, वे विशाल ज्ञान वाले savant की तरह काम करते हैं
- pair programming करने वाले साथी के रूप में वे कमज़ोर हो सकते हैं, लेकिन ऐसे ढाँचे में जहाँ उपयोगकर्ता सवाल पूछे और जवाबों की जाँच करे, वे उपयोगी हैं
- पहले कुछ भाषाएँ, क्लासिक algorithm और मुख्य library जानना बहुत से कामों के लिए काफ़ी होता था
- अब framework, language और library की बाढ़ से जटिलता बहुत बढ़ गई है, और ऐसे माहौल में “सब कुछ जानने वाला मूर्ख” एक उपयोगी साथी बन जाता है
high-level code और data interpretation में सफलता के उदाहरण
- Keras से PyTorch पर जाते समय, LLM ने PyTorch documentation को शुरू से पढ़े बिना मॉडल बनाने के लिए ज़रूरी कोड लिखने में मदद की
- उपयोगकर्ता embedding या residual network जैसे concepts पहले से जानता था
- ज़रूरी मॉडल संरचना और सवालों को साफ़-साफ़ रखना प्रभावी रहा
- GPT-4 ने PyTorch model और batch format देखकर neural network input के अनुकूल tensor reshape करने वाला कोड लिखा
- उपयोगकर्ता ने Python CLI में tensor dimensions और data batch की संगति जाँची
- ESP32-आधारित डिवाइस के लिए BLE client बनाते समय, macOS native API इस्तेमाल करने हेतु Objective-C code जल्दी लिखा गया
- multi-platform Bluetooth binding को कुल मिलाकर उपयोग योग्य नहीं माना गया
- Objective-C BLE API और बहुत पहले इस्तेमाल की गई Objective-C की बारीकियों को फिर से संभालना पड़ा
- अंतिम कोड SerialBTE.m में है
- LLM ने ज़्यादातर कोड सीधे नहीं लिखा, लेकिन उसने समस्या के कारण और समाधान समझाए, जिससे लिखने की गति काफ़ी बढ़ी
- इस सहायक प्रोग्राम का लाभ-की-तुलना-में-प्रयास कम था, इसलिए ChatGPT न होता तो शायद इसे शुरू ही नहीं किया जाता
ONNX मॉडल की व्याख्या और फेंक दिए जाने वाले प्रोग्राम लिखना
- जब दस्तावेज़ीकरण कम वाले ONNX format के convnet का उपयोग करना था, LLM ने input/output metadata और test image के raw output values के आधार पर उसके काम करने के तरीके की व्याख्या की
- शुरू में input image का format और size पता नहीं था
- output साधारण binary classification नहीं था, बल्कि सैकड़ों मानों से बना था
- ChatGPT ने अनुमान लगाया कि output में image के भीतर संभावित defect region को दिखाने वाले normalized box और defect probability हो सकती है
- कुछ दौर की बातचीत के बाद Python inference script और input tensor conversion code तैयार हो गया
- “फेंक दिए जाने वाले प्रोग्राम” के मामले में कभी-कभी LLM को पूरा कोड लिखने के लिए छोड़ दिया जाता है
- छोटे neural network के training के दौरान loss curve को visualize करने के लिए GPT-4 ने CSV format देखकर plot.py तैयार किया
- उससे कहा गया कि command line पर कई CSV फ़ाइलें मिलने पर हर experiment की validation loss curve की तुलना करे
- पूरा काम 30 सेकंड में हो गया
- AirBnB CSV report पढ़कर apartment के हिसाब से month/year group करना, cleaning fee और ठहरने के दिनों को ध्यान में रखकर monthly average rent निकालने वाला pandas प्रोग्राम भी पहली कोशिश में काम कर गया
- ऐसे प्रोग्राम लिखना अपने आप में उबाऊ और कम दिलचस्प होता है, इसलिए LLM के करने पर उपयोगकर्ता महत्वपूर्ण कामों पर ध्यान दे सकता है
C और system programming में दिखी सीमाएँ
- C प्रोग्राम लिखते समय LLM का उपयोग लगभग हमेशा सिर्फ़ अधिक सुविधाजनक दस्तावेज़ के रूप में किया जाता है
- system programming में जटिल reasoning चाहिए, और मौजूदा LLM अक्सर इसी बिंदु पर असफल होते हैं
- Bloom filter implementation माँगने पर GPT-4 को 100,000 elements और अधिकतम 5% false positive probability की शर्त दी गई, लेकिन वह अच्छा implementation नहीं दे पाया
- उसने सिर्फ़ दो मिलते-जुलते hash function इस्तेमाल किए
- उसी string से K काफ़ी हद तक decorrelated hash निकालने की abstraction उसमें नहीं थी
- अगर स्पष्ट रूप से N decorrelated output बनाने को कहा जाए, तो वह बेहतर hash function सुझाता है
- GPT-4 छोटे subproblem में बाँटने पर अधिक उपयुक्त hash function लिख सका, लेकिन Bloom filter के पूरे design में वह उस विचार को खुद लागू नहीं कर पाया
- इस तरह के नतीजों को कमज़ोर reasoning, विषय-विशेष सामग्री की कमी, और कम-गुणवत्ता सामग्री के मिश्रण के असर के रूप में देखा जा सकता है
लोकल मॉडल और बड़े मॉडल के बीच अंतर
- system programming समस्याओं में छोटे और बड़े मॉडल के बीच फ़र्क साफ़ दिखता है
- Mixtral ने उसी hash_id समस्या में hash result के अंत में
hash_idजोड़ने का तरीका सुझाया, जिसे बहुत ख़राब समाधान माना गया - deepseek-coder 34B को 4-bit quantization के साथ MacBook M1 Max पर चलाने का परिणाम बेहतर था
- उपयोगकर्ता ने संकेत दिया कि अंत में hash_id जोड़ने से distribution ख़राब हो जाती है
- मॉडल ने पहचाना कि साधारण जोड़ ही समस्या का कारण हो सकता है
- उसने
hash_idको मिलाने के लिए XOR जैसी bitwise operation वाले विकल्प सुझाए
- यह उदाहरण सिर्फ़ documentation या Google search से मुश्किल से मिलने वाले उस प्रकार के कारण-पहचान और समाधान-सुझाव के क़रीब है
- फिर भी, अनुभवी system programmer के लिए LLM अब भी आम तौर पर संतोषजनक समाधान बहुत कम दे पाते हैं
llama.cpp Q6_K format की व्याख्या का मामला
- ggufflib प्रोजेक्ट एक ऐसी library है जो llama.cpp द्वारा quantized model लोड करते समय इस्तेमाल किए जाने वाले GGUF format की फ़ाइलें पढ़ती और लिखती है
- quantization encoding में गति के लिए हर quant के bit को जटिल तरीके से संग्रहीत किया जाता है
- शुरुआत में encoding समझने के लिए ChatGPT का उपयोग करने की कोशिश की गई, लेकिन llama.cpp code का सीधे reverse engineering करना कहीं तेज़ निकला
- फ़ंक्शन इतना छोटा था कि GPT-4 के context में आ सकता था, फिर भी struct declaration और decoding function देखकर data format document दोबारा बनाने का उसका नतीजा बेकार था
- Q6_K format की व्याख्या माँगने पर भी वह यह साफ़ नहीं बता सका कि weight की position के अनुसार lower/upper bit
qlऔरqhमें कैसे संग्रहीत होते हैं- जब और सरल storage explanation function माँगा गया, तब भी index ग़लत थे
- 6-bit से 8-bit sign extension की प्रक्रिया भी ग़लत थी
- यह काम आख़िरकार कागज़-कलम, code reading, और decoder द्वारा निकाले जाने वाले bit को ट्रैक करके पूरा हुआ
- फिर भी, अनुमान है कि थोड़ा और scaling और बिना किसी बड़े breakthrough के भी कुछ महीनों में यह दायरा संभव हो सकता है
प्रोग्रामिंग कार्य की प्रकृति और LLM उपयोग की क्षमता
- आज प्रोग्रामिंग का बड़ा हिस्सा उसी चीज़ को थोड़ा अलग रूप में दोहराने का काम है, और अक्सर इसमें उच्च-स्तरीय reasoning की ज़रूरत नहीं होती
- LLM इस तरह की दोहरावदार प्रोग्रामिंग में काफ़ी मज़बूत हैं, लेकिन context size की सीमा अब भी बड़ी बाधा है
- यह सोचना ज़रूरी है कि सिर्फ़ उसी प्रकार के प्रोग्राम लिखना, जिनका कुछ हिस्सा LLM कर सकता है, 5 या 10 साल बाद भी अच्छी स्थिति होगी या नहीं
- LLM की reasoning क्षमता कमज़ोर और अधूरी है, लेकिन जो परिणाम दिखते हैं उन्हें सिर्फ़ शब्दों की पुनरावृत्ति मानकर समझाना मुश्किल है
- next token prediction का training objective किसी न किसी रूप में abstract model बनाने के लिए मजबूर करता है, और वह model कमज़ोर, छिद्रों से भरा और अपूर्ण होता है
अभी LLM का उपयोग क्यों करें
- प्रोग्रामिंग में LLM का उपयोग न करने के कारण कमज़ोर हैं
- LLM से सही सवाल पूछने की क्षमता एक महत्वपूर्ण skill बन रही है
- समस्या को स्पष्ट रूप से समझाने की क्षमता सिर्फ़ LLM ही नहीं, इंसानों के साथ संवाद में भी उपयोगी है
- बहुत से प्रोग्रामर किसी खास क्षेत्र में बेहतरीन होते हैं, लेकिन उनकी communication कमज़ोर हो सकती है
- Google के उपयोग में कठिन होने की स्थिति में, LLM compressed documentation की तरह इस्तेमाल करने के लिए भी अच्छे हैं
- अस्पष्ट communication protocol या जटिल library details जैसे “junk knowledge” को कम सीधे सीखना पड़े, यही LLM का व्यावहारिक मूल्य है
1 टिप्पणियां
Hacker News की राय
असली बात यह हिस्सा है: “क्या मैं यह ChatGPT के बिना कर सकता था? बिल्कुल कर सकता था, लेकिन इसमें ज़्यादा समय लगता—यह सबसे दिलचस्प बात नहीं है। असल बात यह है कि शायद यह इतना भी महत्वपूर्ण नहीं लगता कि मैं कोशिश ही करता”
code assistance में LLM की असली क्षमता यह है कि यह नए काम शुरू करने की बाधा कम कर देता है, ताकि जो काम भविष्य के प्रोजेक्ट ढेर में अनिश्चितकाल तक पड़ा रहता, उसे सचमुच उठाकर पूरा किया जा सके
Internet और open source का भी ऐसा ही असर था, और जिन प्रोजेक्ट्स में रुचि तो थी लेकिन खुद हाथ नहीं लगाया, समय के साथ कोई न कोई वैसी समस्या को काफ़ी हद तक हल कर देता है ताकि उसे reuse या modify किया जा सके, और इस तरह उपयोगी apps और libraries की संख्या विस्फोटक रूप से बढ़ी
LLM अपने आप में इतना सक्षम नहीं है, लेकिन जिन लोगों के पास बुनियादी कौशल और motivation है, उनके लिए यह एक amplifier बन जाता है—लेखक की इस बात से मैं सहमत हूँ
फिर पता चला कि यह उम्मीद से कहीं कम मेहनत में किया जा सकता है
सही इंसान के साथ ideas bounce करके भी ऐसा असर मिल सकता है, लेकिन ऐसा व्यक्ति, जिसे पूरे problem domain की गहराई से जानकारी होना ज़रूरी न हो फिर भी meaningful input दे सके, 24 घंटे एक click पर इंतज़ार करता नहीं मिलता
कुछ चीज़ों में यह मददगार रहा, लेकिन आम तौर पर जहाँ मैं नहीं जानता कि मैं क्या कर रहा हूँ, वहाँ model भी मुझसे ज़्यादा नहीं जानता
बाकी मामलों में prompt बनाना, सीधे code लिखने से ज़्यादा तेज़ नहीं पड़ता
सोचता हूँ क्या मैं ही इन tools का सही इस्तेमाल नहीं कर पा रहा
ow2 asm library की मुझे काफ़ी जानकारी थी, लेकिन exact descriptor format याद करने के लिए इधर-उधर खोजने में जो समय जाता, वह इसने बचा दिया
इसने यह समझने में भी मदद की कि दूसरी static analysis libraries मेरे लिए पर्याप्त क्यों नहीं थीं, खासकर state को संभालने के उनके तरीकों की वजह से
मेरे लिए ChatGPT दो काम करता है: यह मामूली StackOverflow searches और library code की खोजबीन को कम करके खास सवालों के जवाब दिलाता है, और प्रोजेक्ट शुरू करने से पहले की research phase में यह समझने में मदद करता है कि जो approach मैं लेना चाहता हूँ वह viable है या नहीं
अगर ADHD गंभीर हो, तो सबसे सरल काम सबसे कठिन हो जाते हैं, और कूड़ा फेंकना या डाक खोलना भी लगभग असंभव लग सकता है
दिमाग़ के भीतर की आवाज़ घंटों तक बस यही चिल्लाती रहती है कि वह काम कर लो, लेकिन शरीर मानता नहीं
इसे executive dysfunction कहते हैं, और यह मेरी ज़िंदगी की बड़ी परेशानी है
LLM अगर सिर्फ़ वह काम शुरू करवा दे, तो भी यह बहुत बड़ी बात है
programming के बारे में मैं पूरी तरह सहमत हूँ
LLM इस्तेमाल करने की सबसे अच्छी स्थिति तब होती है जब आप उस विषय के बारे में पहले से इतना जानते हों कि output को verify कर सकें, और इतना भी कि जो चाहिए उसे detail में, और हो सके तो सीधे मुद्दे पर, समझा सकें
यह आपको काम तेज़ी से करने देता है, ऐसे काम भी करवा देता है जो आप वरना नहीं करते, और छोटे लेकिन उपयोगी ऐसे programs बनाने में बहुत मदद करता है जिन्हें बाद में फेंक भी सकते हैं
एक और बहुत उपयोगी क्षेत्र programming हो या न हो, पूरी तरह नए विषयों की खोज है
बस कहिए कि आप इस विषय को अच्छी तरह नहीं जानते, details ज़रूरी नहीं हैं, लेकिन आप इस बारे में बात करना चाहते हैं और अपने विचार व्यवस्थित करने में मदद चाहते हैं
जो लोग सुनी हुई बातों के आधार पर आगे खुद research करने या और सवाल पूछने के लिए तैयार हों, उनके लिए यह खास तौर पर उपयोगी है
कई क्षेत्रों में प्रवेश की पहली दहलीज़ बुनियादी terminology समझना, लोग कौन-कौन से distinctions करते हैं और क्यों करते हैं यह सुनना, और यह जानना है कि उस विषय के authority figures कौन हैं
वे तब तक इसे कुरेदते रहते हैं जब तक कोई ऐसा राक्षसी ढांचा न बन जाए जिसे वे समझते नहीं, लेकिन build pass हो जाता है
सीखने वाले लोगों को मदद की ज़रूरत होती है, लेकिन Copilot-शैली के LLM जो मदद देते हैं, वह सही तरह की मदद नहीं है
यह दिलचस्प होगा अगर ऐसा Copilot model train किया जाए जो junior के अस्पष्ट या ग़लत तरह से बताए गए सवालों पर किसी तरह code उगलने की कोशिश करने के बजाय, clarification questions पूछे और साथ मिलकर समाधान तय करे
हर बार इसने या तो हल्की-सी ग़लत बात कही या पूरी तरह hallucinated premise पेश कर दी, और जब तक मुझे समझ आता कि यह ग़लत है, तब तक मेरा समय बर्बाद हो चुका होता
अगर इसमें ग़लत जवाब को बेवजह पूरे आत्मविश्वास से पेश करने की आदत न होती, तो मैं कह सकता था कि यह मेरे अपने अधूरे ज्ञान को जोड़ने से बहुत बुरा नहीं है, लेकिन अभी के लिए यह rubber duck या autocomplete के विकल्प के तौर पर ठीक है
अच्छा होगा अगर किसी नई language की website पर जाकर उसी documentation के बारे में बातचीत और सवाल-जवाब करके समझने में मदद करने वाला LLM मिले
अगर वह उस language या framework के वास्तविक code examples पर trained हो और वहीं उसी समय नया program या function लिखने में मदद कर सके, तो और भी बेहतर
अगर वह online REPL से जुड़कर inline मदद दे सके, तो यह और बड़ा फ़ायदा होगा
मेरा मानना है कि LLM का सबसे कम आंका गया पहलू, जिसका लेख में ज़िक्र तो था लेकिन सीधे चर्चा नहीं हुई, एक तरह से सब कुछ जानने वाले डेवलपर जैसी भूमिका है
चाहे कोई कितना भी senior programmer हो, आखिरकार उसे ऐसी तकनीकें मिलती ही हैं जिनके बारे में वह लगभग कुछ नहीं जानता
हर कोई किसी न किसी क्षेत्र में junior होता है
आप Win32, C++, COM के उस्ताद हों, फिर भी software को package करते समय पेचीदा NSIS script में अटक सकते हैं
आपने 25 साल तक web app बनाए हों और PHP language committee में रहे हों, फिर भी अगर आपको credit card network से बात करने वाले जटिल ISO standard को implement करने का काम मिले, तो हो सकता है आपने उस स्तर पर कभी credit card network से communication न किया हो
आपने पहले iPhone से ही iOS app बनाए हों, उससे पहले Mac app बनाए हों, Apple में कई साल काम किया हो, ज़्यादातर iOS API याद हों और कुछ को खुद design भी किया हो, फिर भी अगर आपको app में CalDAV support implement करने को कहा जाए, तो हो सकता है आपको CalDAV क्या है यह भी न पता हो
ऐसे हालात में LLM मदद कर सकता है, और भले वह सारा code न लिख पाए, कम से कम आपको सही दिशा में ले जा सकता है
दिमाग दूसरी technologies से भर जाने के बाद, कभी ऐसा वक्त आता है जब पहले सीखी हुई लेकिन नई तकनीकों के कारण पीछे छूट गई चीज़ों को फिर से याद और revise करना पड़ता है
यह एक अजीब एहसास होता है
स्वाभाविक रूप से आप उस median के साथ चलते रहते हैं जो आपकी company का काम होता है, और फिर एक दिन लगता है कि CSS को छुए हुए “काफी समय हो गया”
Python dataclass की समझ वापस लाने के लिए शायद weekend में पढ़ाई करनी पड़े
जो चीज़ Google में मिल सकती है, उसे LLM शायद ज़्यादा तेज़ी से और बेहतर तरीके से ढूँढकर व्यवस्थित कर दे
अच्छी बात यह है कि तब तक शायद मैं retire हो चुका होऊँगा
“मैंने ज़्यादातर code ChatGPT से copy-paste करके लिखा” वाला रुझान चौंकाने वाला है
यह बात लगातार हैरान करती है कि इतने लोग इतना तकलीफ़देह workflow सह लेते हैं
मूल लेख का लेखक GPT से अपनी जानकारी से परे coding करने वाला कोई beginner नहीं, बल्कि साफ़ तौर पर एक अनुभवी engineer है
आम तौर पर वह coding workflow और tools की usability और efficiency की परवाह करने वाला व्यक्ति होगा, फिर भी बहुत से लोग GPT और local files के बीच code को बार-बार copy-paste करना सहते रहते हैं
इसी घुटन भरे workflow ने शुरू में aider बनाने की प्रेरणा दी
aider local git repository को GPT के साथ share करता है ताकि नया code और बदलाव सीधे files में लागू हो सकें
यह संबंधित code context भी GPT के साथ share करता है, इसलिए वह ऐसा code लिख सकता है जो project के साथ integrate हो
इस तरह सिर्फ copy-paste के लायक isolated code ही नहीं, बल्कि ज़्यादा परिष्कृत योगदान भी संभव हो जाता है
नतीजतन, यह एक smooth pair programming workflow बन जाता है जिसमें बातचीत करते हुए मैं और GPT साथ में files edit करते हैं
https://github.com/paul-gauthier/aider
लेकिन क्या इसे code के बारे में सिर्फ बातचीत करने के लिए इस्तेमाल करने का कोई तरीका है?
मैं LLM का इस्तेमाल अलग-अलग approaches के फायदे-नुकसान पर चर्चा करने या किसी समस्या को rubber duck की तरह सुलझाने के लिए करता हूँ
उसके लिए code copy करना पड़ता है, लेकिन aider का focus changes apply करने पर है, इसलिए इस तरह के उपयोग के लिए यह ठीक नहीं लगा
आम तौर पर सही तरीका क्या है इस पर कई बार बातचीत होने के बाद ही तय करता हूँ कि बदलाव लागू करने हैं या नहीं
वह Redis के संस्थापक हैं
अगर आप पहले से subscription fee दे रहे हैं, तो API पर अतिरिक्त पैसे देने की बजाय copy-paste करना समझदारी हो सकती है
इसके अलावा, productivity improvement किसी और के project पर निर्भर होने लायक है या नहीं, इस पर हर व्यक्ति का मानदंड अलग होता है, और ऐसे project के paid हो जाने या छोड़ दिए जाने का जोखिम भी होता है
पहली बार जिस वास्तविक file पर इसे चलाया, वह इतनी बड़ी थी कि सब कुछ फेल हो गया, और दूसरी वास्तविक file भी अभी भी बहुत बड़ी थी
यह देखकर हैरानी हुई कि aider बड़ी files को token limit के हिसाब से बाँट नहीं सकता
GPT की token limit इतनी बड़ी source files को समेट नहीं पाती
अगर मुझे पहले खुद काम की files चुननी हों, और GPT को टूटने से बचाने के लिए surgery भी करनी पड़े, तो पता नहीं यह IDE के Copilot का इस्तेमाल करने से ज़्यादा समय बचाता है या नहीं
शुरू में मुझे लगा था कि “code size ≫ token limit” समस्या को संभालना ही aider का मुख्य योगदान है, लेकिन शायद ऐसा नहीं था
मैं इसे फिर से आज़माना चाहता हूँ, लेकिन aider उस नुकसानदेह श्रेणी में आता है जहाँ “aider जितनी simple problem और codebase ढूँढनी पड़ती है जिसे aider संभाल सके”
वहीं Copilot और ChatGPT रोज़ मेरे पास आते हैं और असली नौकरी में असली codebase की कमियों समेत मेरी मदद करते हैं
मुझे लगता है कि अपने मौजूदा features के साथ यह chat और confirmation वाले use case को बेहतरीन ढंग से cover करता है
यहाँ की टिप्पणियाँ शायद ज़्यादातर software users की ऊँची संतुष्टि को पूरी तरह न दिखाती हों
Aider, antirez द्वारा लेख में बताए गए use case को वास्तव में लागू करने में मदद करता है
खासकर, जैसा antirez ने कहा, जैसे-जैसे LLM से सही सवाल पूछने की कला बेहतर होती जाती है, यह और भी ज़्यादा मददगार बनता है
पिछले कुछ दिनों से मैं एक closed-source Mac app के bug को ठीक करने की कोशिश कर रहा था
मुझे वह app पसंद है, लेकिन यह bug कई सालों से मुझे परेशान कर रहा था
मुझे काफ़ी यक़ीन था कि कौन-सा Objective-C method लगभग यह bug पैदा कर रहा है, लेकिन मुझे पता नहीं था कि वह method करता क्या है, और उसका decompiled version पूरी तरह बेतुका कचरा था
ऐसा लग रहा था जैसे मैं दीवार से टकरा गया हूँ
फिर मैंने decompiler के उगले हुए शोर को GPT-4 में डाला और उससे कहा कि इसे साफ़-सुथरे version में बदल दे
नतीजा perfect नहीं था, लेकिन मैं उसे ठीक-ठाक बना सका, और उस नतीजे को app में swizzling करने पर bug गायब होता हुआ लगा
मैंने कभी reproduction steps नहीं ढूँढे, लेकिन आम तौर पर अब तक समस्या सामने आ जाती
GPT-4 के बिना मैं यह कभी नहीं कर पाता
बेशक, अगर code के एक हिस्से को पूरी तरह से फिर से लिखा जाए, तो भले आप यह समझे बिना LLM का उपयोग करें कि वह क्या कर रहा है, मूल implementation वाला वही bug बने रहने की संभावना कम होगी
लेकिन दूसरे bug आ सकते हैं, और मैं उम्मीद करता हूँ कि कोई भी इस तरह का तरीका उस code पर न अपनाए जहाँ bug के नतीजे महत्वपूर्ण हों, जैसे system outage या customer cost
यह लेख मेरे लिए पूरी तरह चौंकाने वाला है
Salvatore आज काम कर रहे सबसे सक्षम software engineers में से एक हैं
वह साफ़ देख सकते हैं कि यह तथाकथित tool उनके अपने विशेषज्ञता-क्षेत्र में बिल्कुल बेकार है
फिर भी, इसे गलत और टेढ़े screwdriver की तरह फेंक देने के बजाय, वह इस धारणा को मान लेते हैं कि किसी न किसी तरह इसका उपयोग ढूँढना चाहिए
जैसा कि शुरुआती macroeconomics की कक्षा में पढ़ाया जाता है, अगर एक द्वीप widget A बनाने में श्रेष्ठ हो, तो दूसरे द्वीप की B उत्पादन क्षमता कितनी भी खराब क्यों न हो, A द्वीप द्वारा B द्वीप का उपयोग करने वाली specialization फिर भी उभरती है
इसलिए यह स्वाभाविक है कि antirez की system programming में सापेक्ष क्षमता LLM को दूसरी programming tasks की ओर धकेल दे
लेकिन हम अलग-थलग अस्तित्व में नहीं रहते
हमारे आसपास बहुत से इंसान हैं जो तकनीकी चुनौतियाँ और भोजन चाहते हैं
उनमें से कई के पास ऐसे skills हैं, या वे हासिल कर सकते हैं, जो हमारे पूरक हैं
साथ काम करने पर सहयोग का परिणाम उसके हिस्सों के योग से बड़ा हो सकता है
शायद LLM, antirez से बेहतर PyTorch code लिख सके
लेकिन सिर्फ इसलिए कि garage में एक पुराना और टेढ़ा screwdriver पड़ा है, यह ज़रूरी नहीं कि हमें वही इस्तेमाल करना पड़े
आज hardware store जाना बेहतर हो सकता है
क्योंकि सटीक syntax या tensor reshaping मेरे लिए उतने महत्वपूर्ण नहीं हैं
अगर यह मेरे images पर convnet बनाने और train करने जैसा निजी उपयोग है, तो किसी Torch expert को परेशान करने की ज़रूरत नहीं है
अगर मैं convnet को पर्याप्त रूप से समझता हूँ और Torch syntax या methods को पर्याप्त रूप से नहीं जानता, तो मैं इसे कर सकता हूँ
विकल्प यह है कि Torch manual की बारीकियाँ पढ़ी जाएँ, और परिणाम वही होगा
इस काम में महत्वपूर्ण चीज़ MLX, Keras, PyTorch की details नहीं, बल्कि machine learning concepts पर नियंत्रण है
अभी यह कुछ हद तक उपयोगी है, लेकिन सच में उतना भी नहीं, और इसका इस्तेमाल न करने से आप “पीछे” भी नहीं रह जाते
इससे जुड़े सभी लोग इसे और सक्षम बनाने की पूरी कोशिश कर रहे हैं, इसलिए जब वह दिन आएगा तो आप जो चाहेंगे उसे prompt में कह देंगे
अभी की पीढ़ी से ज़बरदस्ती कुछ निचोड़ने की जल्दबाज़ी की ज़रूरत नहीं है, और फिलहाल यह अक्सर productivity बढ़ाने के बजाय घटाता है
यहाँ तक कि यह संदेह होता है कि क्या आपने वही लेख पढ़ा भी था
उन्होंने एक नया tool देखा जिसे दूसरे लोग दिलचस्प मान रहे थे, अपने लिए उपयोगी तरीके खोजे, और साथ ही जहाँ यह बेकार है उसे भी माना
उन्होंने उन उदाहरणों का भी पर्याप्त समर्थन किया जहाँ यह बेकार नहीं था
यह developers के लिए कोई खास क्रांतिकारी insight नहीं है
हम हमेशा programming languages जैसे अलग-अलग tools इस्तेमाल करते हैं, और हर tool की अपनी strengths और weaknesses होती हैं
सिर्फ LLM को इतना अलग क्यों होना चाहिए, यह मुझे समझ नहीं आता
यह दावा करना कि इसमें कोई strength ही नहीं है, मूर्खतापूर्ण लगता है
क्या वह महीने के 20 डॉलर से कम में हो सकता है?
नया project शुरू करते समय एक impedance problem होती है
शुरुआत में काम 0% पूरा होता है, और चाहे वह hello world हो, CMakeLists file हो, या Python script, कहीं न कहीं से शुरू करना पड़ता है, और वही कठिन होता है
ChatGPT/LLM से पहले वह मेहनत मुझे अपने भीतर से उँगलियों के सिरे तक खींचकर लानी पड़ती थी
अब वह काम ChatGPT को सौंपा जा सकता है
वास्तव में यह “बैठकर खुद करने” की तुलना में कम efficient और कम powerful है, लेकिन यह “बैठकर खुद करने का फैसला लेने” की लागत हटा देता है
फिर भी GitHub code search, StackOverflow, random blog posts, docs, Discord वगैरह से कॉपी किए गए टुकड़ों को जोड़ना-घटाना तो वैसा ही रहता है
कुछ कोशिशों और दोबारा कोशिशों के बाद project का 5% वाला शुरुआती बिंदु बन जाता है, और जब आखिरकार उसका आकार दिखने लगता है, तब आप सच में काम कर सकते हैं
अंत में, ChatGPT द्वारा उगले गए उथले और कचरा proof-of-concepts को copy-paste करके जल्दी से कुछ बनाया जाता है, और फिर जब पर्याप्त momentum मिल जाता है तो खुद गहराई में उतरने की तरफ स्विच किया जाता है
इसलिए यह ज़्यादा धीमा और कम efficient है, और ऐसा भी नहीं कि ChatGPT यह मुझसे बेहतर करता हो, लेकिन यह आसान है और इसमें शुरुआत में गहराई तक नहीं खोदना पड़ता
आख़िरकार project के सच में महत्वपूर्ण हिस्सों, यानी बीच और अंत, तक पहुँचते-पहुँचते आप कहीं अधिक टिके रह पाते हैं, और शुरुआत में burnout नहीं होता
क्या मैं शुरुआत से ही सही सवाल पूछ रहा था, और अगर नहीं, तो क्या उस काम को प्रभावी ढंग से बचाया जा सकता है?
sunk cost 20 डॉलर की subscription fee में गायब हो जाती है
मेरे हिसाब से मुख्य insight यह पंक्ति है: “जब कोई समस्या होती है और LLM बकवास करता है, तो मुझे जल्दी से यह जानना होता है कि मैं क्या verify कर सकता हूँ. ऐसे मामलों में मैं उस गति को बढ़ाने के लिए LLM का इस्तेमाल करता हूँ जिस पर मुझे knowledge चाहिए होती है”
programming के LLM के लिए खास तौर पर उपयुक्त होने की एक वजह यह है कि सही उत्तर का verification आम तौर पर तुच्छ होता है
मैं इस विचार के साथ प्रयोग कर रहा हूँ कि किसी task के लिए LLM सही tool है या नहीं, इसका आकलन कैसे किया जाए
जैसे “output का सही होना कितना महत्वपूर्ण है” और “output सही है या नहीं, यह verify करना कितना आसान है” का graph बनाना
ChatGPT से उन songs की list बनवाना जिनमें किसी Emmy जीतने वाली महिला artist ने भाग लिया हो, accuracy verify करने में समय लेता है, लेकिन उसका महत्व भी कम है और कुछ errors हों तो भी चल जाता है
तो फिर software में bugs बिल्कुल नहीं होते?
समाधान सोचना मुश्किल होता है, लेकिन संभावित समाधानों को verify करना आसान होता है
और हम सब जानते हैं कि उस समस्या-वर्ग को क्या कहा जाता है
दुनिया पहले से ही अप्रासंगिक और गलत बकवास से भरी हुई है, और हमें उसके उत्पादन को तेज़ करने के बजाय घटाना चाहिए
यह किसी खास उदाहरण की बात नहीं, बल्कि पूरे विचार की बात है
मैं ChatGPT को कोड लिखने के लिए सोच का पार्टनर की तरह इस्तेमाल करता हूँ
हर दिन पूरे दिन उससे बातचीत करते हुए काम खत्म करता हूँ
कंपनी ने Copilot को मंज़ूरी दी थी, लेकिन Copilot autocomplete का अनुभव भयानक था
कंपनी ने Copilot Chat को मंज़ूरी नहीं दी, जिसकी मुझे ज़रूरत थी
फिर भी अच्छा होगा अगर कोई ऐसा मिलता-जुलता टूल हो जो मेरे लैपटॉप पर मेरे कोड के लिए unit test या code comments जैसी चीज़ें generate कर दे
बेशक, मेरी input और मार्गदर्शन को आधार मानकर
सहकर्मियों ने इसकी बहुत तारीफ़ की थी, इसलिए लगा कि शायद मुझमें ही कुछ गड़बड़ है, लेकिन यह बेहद ध्यान भटकाने वाला था और कुछ दिनों बाद मैंने इसे बंद कर दिया
ऐसा लगता था जैसे मैं अभी बोल ही रहा हूँ और कोई मेरी बात पूरी करने की कोशिश कर रहा है
जब यह सही भी होता था तब भी झुंझलाहट होती थी, flow टूट जाता था, और बहुत बार यह गलत होता था
[0] https://continue.dev/
[1] https://ollama.ai/
मैंने कुछ दिन पहले Codeninja आज़माया था
जहाँ तक मुझे याद है, यह Copilot backend चलाने वाले 4 के स्तर का बिल्कुल नहीं है, लेकिन संवेदनशील डेटा के लिए जिसे बाहर नहीं जाना चाहिए, यह व्यावहारिक रूप से एकमात्र विकल्प है
या फिर OpenAI से dedicated instance लेने का तरीका भी हो सकता है
यह इस लेख का सबसे महत्वपूर्ण हिस्सा हो सकता है, और 2024 में जो होने वाला है उसे देखते हुए इसे जितनी बार दोहराया जाए कम है
“तो क्या LLM में कुछ हद तक reasoning क्षमता है, या यह सब दिखावा है? जैसा कि semioticians कहते हैं, हो सकता है कि ‘signifier’ कभी-कभी reasoning का आभास देता हो, क्योंकि वह ऐसे अर्थ का प्रभाव पैदा करता है जो वास्तव में मौजूद नहीं है। लेकिन जिन लोगों ने LLM के साथ पर्याप्त काम किया है, वे इसकी सीमाएँ स्वीकार करते हुए भी जानते हैं कि सिर्फ इससे बात पूरी नहीं होती। पहले से देखी हुई चीज़ों को मिलाने की क्षमता, शब्दों को बस बेतरतीब उगल देने से कहीं आगे जाती है। भले ही इसका अधिकांश training pretraining के दौरान next token की भविष्यवाणी करने के तरीके से हुआ हो, यह लक्ष्य मॉडल को किसी न किसी तरह का abstract model बनाने के लिए मजबूर करता है। यह मॉडल कमज़ोर है, इसमें बहुत से छेद हैं, और यह अधूरा है, लेकिन अगर हम वही देख रहे हैं जो हम देख रहे हैं, तो इसका होना ज़रूरी है। अगर गणितीय निश्चितता संदेहास्पद है और शीर्ष विशेषज्ञ भी अक्सर एक-दूसरे के विरोध में खड़े हैं, तो अपनी आँखों से जो दिख रहा है उस पर भरोसा करना समझदारी लगती है”