हाल ही में मेरे ट्वीट देखने से पता चलता है कि मैं लगभग LLM के बारे में ही बात कर रहा हूँ। मैं इस कदर इसमें डूबा हुआ हूँ। खाली समय मिलते ही मैं तुरंत LLM से कुछ न कुछ करने या सवाल पूछने लगता हूँ। खासकर, एजेंट से कोड लिखवाना तो ऐसा लगता है जैसे मैंने अभी-अभी कोई सोशल गेम खेलना शुरू किया है और मैं उसमें बिना समय बर्बाद किए डूब गया हूँ।
एजेंट का उपयोग करके कोड लिखवाना मजेदार है। मैं RDBMS बना रहा हूँ, लेकिन "अगला क्या करें?" "क्या पोस्टग्रेSQL संगत इंटरफेस जोड़ें?" "क्या? क्या यह संभव है?" "हो गया!" इस तरह की भावना के साथ एक के बाद एक कार्यान्वयन आ रहे हैं। बेशक, यह शुरू से ही परिपूर्ण नहीं है, इसलिए यूनिट परीक्षण लिखने के दौरान कई कमियाँ सामने आती हैं, लेकिन फिर भी विकास की गति इतनी अधिक है कि यह इसकी भरपाई कर देती है। सबसे बढ़कर, काम के बीच में एक और चैट पार्टनर मिलने जैसा लगता है और लगभग 100,000 लाइनों का कोड तुरंत बन जाता है, जो आश्चर्य से परे विस्मय पैदा करता है।
SNS पर मेरे विचारों को फॉलो करने वाले लोग जानते होंगे कि मुझे लंबे समय से सॉफ्टवेयर विकास इंजीनियरिंग पर भरोसा नहीं था। यह एक ऐसे प्रोग्रामर के लिए नहीं है जो सीखता है और कुछ करता है, बल्कि यह एक ऐसा विज्ञान है जो प्रोग्रामिंग को सामूहिक रूप से करते समय समूह के व्यवहार को लक्षित करता है, और मुझे दृढ़ता से संदेह था कि क्या यह सभी प्रकार के प्रोग्रामिंग क्षेत्रों पर लागू होता है। हालाँकि, कई एजेंटों को काम पर रखते समय, कोड को पढ़े बिना बग की उपस्थिति का पता लगाने या धीरे-धीरे विश्वसनीय स्थानों का विस्तार करने जैसी भावनाओं की आवश्यकता होती है, और मुझे एहसास होता है कि मैं स्वाभाविक रूप से सॉफ्टवेयर विकास इंजीनियरिंग दृष्टिकोण अपना रहा हूँ। मैं विशेष रूप से बग घनत्व या अभिसरण वक्र को शामिल नहीं कर रहा हूँ, लेकिन मुझे पता है कि मैं एक सिंहावलोकन में देखने पर उनसे बहुत दूर नहीं हूँ।
एक नौसिखिया शायद एजेंट पर चिल्लाएगा, "बग-मुक्त सॉफ़्टवेयर बनाओ!", लेकिन सॉफ़्टवेयर के बारे में ज्ञान के साथ, लगातार निर्देश देने और छोड़े गए काम को बातचीत के माध्यम से छाँटने और फिर से निर्देश देने से, अधिकांश समस्याएं हल हो जाती हैं। इस तरह के कार्यों को दोहराने से मुझे राहत मिलती है कि अब तक विकसित की गई मेरी भावनाएँ व्यर्थ नहीं थीं, लेकिन साथ ही मुझे दृढ़ता से लगता है कि एजेंट के लिए इस हद तक समस्याओं को स्वतंत्र रूप से हल करने में समय की बात है। इस संबंध में, मेरे पास प्रोग्रामर के काम के भविष्य के बारे में बहुत निराशावादी दृष्टिकोण है।
एजेंट द्वारा लिखा गया कोड स्पष्ट रूप से अपरिचित घाटी जैसा है, और यह मुझे इसे बनाए रखने के लिए बहुत आकर्षित नहीं करता है, लेकिन मूल आधार यह है कि सॉफ्टवेयर इंजीनियर वास्तव में कोड को बनाए रखना नहीं चाहते हैं। वे केवल इसलिए मजबूरी में इसे बनाए रखते हैं क्योंकि यह कोड काम पर पैसा पैदा करता है, और कोड को पढ़ना एक पेशेवर प्रोग्रामर के लिए रखरखाव के अंतिम उपाय के रूप में तैनात है (कारीगर प्रोग्रामर कोड को एक उद्देश्य के रूप में मानते हैं और खुशी से विशिष्ट कोड में फेरबदल करते हैं, वे जो चाहें कर सकते हैं, मैं भी मूल रूप से उसी तरफ झुका हुआ हूँ)। प्रोग्रामिंग निर्माण के समय का काम है, जबकि सॉफ्टवेयर इंजीनियरिंग एक सतत प्रयास है ताकि यह लगातार मूल्य उत्पन्न करे, और यदि मैं गलत होने से नहीं डरता, तो यह पिछले कुछ दशकों में प्रयास की परिणति है ताकि जो कोड पढ़ना भी नहीं चाहते हैं, उसकी गुणवत्ता कैसे सुनिश्चित की जाए।
x.com
नियमों में काफी बदलाव आया है, इसलिए कुछ चीजें हैं जिनका उपयोग किया जा सकता है और कुछ ऐसी हैं जिनका नहीं किया जा सकता है, मैं जितना सोच सकता हूँ, मैं वर्तमान में महसूस किए जा रहे सुझावों को नीचे लिखूंगा।
संदर्भ इंजीनियरिंग एक संगठनात्मक सिद्धांत है
AI से कोड लिखवाया जाए या नहीं, सॉफ्टवेयर का सार्वभौमिक सत्य यह है कि कोड लगातार बढ़ता रहेगा। मुझे लगता है कि LLM की संदर्भ लंबाई भविष्य में बढ़ती रहेगी, लेकिन सॉफ्टवेयर कोड की विकास दर हमेशा इसे पार कर जाएगी। भले ही LLM संदर्भ समस्या से बच जाए, लेकिन अंततः अच्छी तरह से ध्यान केंद्रित करने में सक्षम संदर्भ सीमा सीमित होती है, और घास के ढेर से सुई खोजने जैसी समस्याएँ हमेशा बनी रहेंगी। बेशक, उत्पादन कोड का पूरा विवरण टीम के सभी सदस्यों द्वारा याद नहीं किया जा सकता है, इसलिए भूमिकाएँ बिना किसी को बताए विभाजित की जाएंगी। वह भूमिका आवंटन एक अलग दृष्टिकोण से देखा जाने वाला संदर्भ इंजीनियरिंग है। संक्षेप में, यदि आप पूरी परियोजना छवि को संदर्भ में डालते हैं, तो यह बहुत बड़ी हो जाएगी और आप कुछ भी सोचने में सक्षम नहीं होंगे, इसलिए "मैं चाहता हूं कि आप इस मॉड्यूल की इस सुविधा में इस फ़ंक्शन को जोड़ें, और आपको इस कार्य को करने के लिए अनावश्यक चीजों को जानने की आवश्यकता नहीं है" काम को विभाजित करने का तरीका है, जो लगभग हर पेशे में नवागंतुकों के लिए किया जाता है, और यह केवल AI एजेंटों तक ही सीमित नहीं है। मुझे लगता है कि जब आप AI एजेंटों का उपयोग करते हैं तो आप समझते हैं कि वे 0 को 1 में बदलने के लिए रोगजनक रूप से तेज़ होते हैं। उन्हें ऐसे बेंचमार्क सेट पर पाला गया है, और मनुष्यों को परेशान करने वाले बगों को हल करना केवल एक बोनस है। 0 को 1 में बदलना तेज़ है क्योंकि उस कार्य को करने के लिए उन्हें जिन मौजूदा कोड को याद रखने की आवश्यकता है, वे शून्य हैं, इसलिए वे संपर्क के बारे में बहुत कम परवाह करते हैं। प्रोग्रामर भी जितना छोटा संदर्भ होता है, माइक्रोसेवाएँ उतनी ही अधिक बनाना चाहते हैं, क्योंकि माइक्रोसेवाएँ होने का मतलब है कि उन्हें अपने दिमाग में कम संदर्भ रखने की आवश्यकता होती है। माइक्रोसेवाएँ एक चरम उदाहरण हैं, लेकिन सॉफ़्टवेयर का निर्माण करते समय आंतरिक रूप से विभाजित करने का कार्य उन लोगों की सीमा को सीमित करना है जिन्हें परवाह करने की आवश्यकता है, और "चिंता का पृथक्करण" जिसे अब तक कहा जाता है, वह जानकारी का पृथक्करण भी है जिसे एजेंट के दिमाग में डाला जाना चाहिए। "सॉफ्टवेयर आर्किटेक्चर" क्या है, इस बारे में अभी भी पूरी सहमति नहीं है, लेकिन मेरी भावना यह है कि यह संदर्भ का विभाजन है जिसे उस पर काम करने वाले लोगों के दिमाग में डाला जाना चाहिए। भले ही शीर्ष पर बैठे किसी व्यक्ति के कहने पर एक मूल्य वस्तु पेश की जाए, यदि अधीनस्थ प्रोग्रामर के दिमाग में डालने के लिए संदर्भ नहीं बदलता है, तो यह नहीं कहा जा सकता है कि वास्तुकार ने सही काम किया है। एजेंट के लिए काम करना आसान बनाने के लिए कार्यों को विभाजित करना और मनुष्यों के लिए काम करना आसान बनाने के लिए सॉफ़्टवेयर के अंदर विभाजित करना काफी समान है। मेरी वर्तमान प्रवृत्ति यह है कि उस परत पर चिंता करने के लिए अधिक चीजें हैं जितना मैं कल्पना करता हूँ, इसलिए मुझे लगता है कि संदर्भ बड़ा है और मैं एक बुद्धिमान उच्च-अंत मॉडल का उपयोग करता हूँ, लेकिन यदि मैं आश्चर्यजनक रूप से जांच एजेंटों आदि को सफलतापूर्वक ऑफलोड करता हूँ, तो हो सकता है कि कम महंगे मॉडल भी अच्छी तरह से काम करें।
LLM महंगा है
हर कोई कह रहा है कि हाई-एंड मॉडल स्पष्ट रूप से बेहतर कोड देते हैं, लेकिन हाई-एंड मॉडल की कीमत 1M टोकन के लिए $10 या $20 जितनी है। उस संदर्भ का उपयोग करके किया गया कार्य एक प्रोग्रामर के कुछ घंटों का होगा, इसलिए मुझे लगता है कि यह फायदेमंद होगा, लेकिन अगर सस्ते मॉडल को कार्य सौंपा जा सकता है, तो यह सबसे अच्छा होगा। कीमत प्रतिस्पर्धा के अंत में, वर्तमान हाई-एंड मॉडल के समकक्ष बहुत सस्ता हो सकता है और पानी की तरह इस्तेमाल किया जा सकता है, लेकिन उस समय तक, उस समय के हाई-एंड मॉडल जारी किए जाएंगे और यह विज्ञापित किया जाएगा कि वे कठिनाई की समस्याओं को हल कर सकते हैं जो अन्यथा हल नहीं की जा सकती हैं। नतीजतन, मुझे लगता है कि भविष्य में भी ऐसी स्थिति बनी रहेगी जहाँ ऐसे कार्य जो प्रोग्राम लिखते समय इतने कठिन नहीं होते हैं, वे सस्ते मॉडल द्वारा लिखे जाते हैं। यदि कुछ भी हो, तो स्थानीय LLM, जो सस्ते मॉडल का शिखर है, एक आकर्षक ऑफलोड गंतव्य है, और उच्च-अंत मॉडल का उपयोग करके परिभाषित कार्यों को उप-अनुबंधित करने वाले स्थानीय एजेंटों का समूह एक यथार्थवादी कहानी है, मुझे नहीं पता कि वर्तमान स्थानीय LLM कितना जटिल कोडिंग कार्य कर सकते हैं, लेकिन सस्ते लोगों के साथ लिखने और डीबग करने में सक्षम नहीं होने पर तौलिया में फेंकने और ज्ञान के साथ एक बुद्धिमान मॉडल तक बढ़ने की कहानी जल्द ही सामान्य ज्ञान बनने की संभावना है। उप-एजेंट कॉल के रूप में स्थानीय और उच्च-अंत एक साथ काम करेंगे, और सॉफ्टवेयर विकास कंपनियों की वास्तविक पूर्णता कुछ लोगों की टीम हो सकती है जो बड़ी संख्या में स्थानीय LLM को पकड़ते और चलाते रहते हैं। AMD के Ryzen AI Max श्रृंखला भी जल्द ही मूल्य में बढ़ने की संभावना है, क्योंकि प्रतिस्पर्धी उत्पाद रक्त और मांस वाले मानव प्रोग्रामर हैं।
AI एजेंट अस्थिर हैं
मुझे नहीं पता कि कौन सा कार्यान्वयन कितना बुरा है, इसलिए मैं निश्चित रूप से कुछ नहीं कहूंगा, लेकिन अज्ञात कारणों से स्टॉपेज या आंतरायिक त्रुटियां या अजीब चीजें हमेशा होती रहती हैं। यहां तक कि ऐसी चीजें भी असामान्य नहीं हैं जैसे कर्नेल क्रैश नहीं होता है, लेकिन संपादक की प्रतिक्रिया गति प्रति मिनट में हो जाती है। इसके अलावा, पुनर्लेखन की गुणवत्ता में बहुत भिन्नता है, और पुनर्लेखन गंतव्य के लाइन नंबर बहुत गड़बड़ हैं और वे अक्सर बहुत विनाशकारी तरीके से टूट जाते हैं। अगर वे टूट जाते हैं तो वे स्वेच्छा से ध्यान देते हैं और इसे ठीक करने जाते हैं, इसलिए यह विशेष रूप से घातक नहीं है, लेकिन इसके लिए अस्थिर चीजों को अस्थिर के रूप में उपयोग करने के लिए युक्तियां हैं, और जहां तक मैं जानता हूं, रैलफ लूप और इसके साथ प्रगति ट्रैकिंग प्रभावी है।
x.com
संक्षेप में, रैलफ लूप एजेंट के लॉन्च को ही एक लूप में डालना है। हालाँकि, संकेत के अंदर, प्रगति को कहीं लिखने का निर्देश दें और लूप की शुरुआत में प्रगति को पढ़ने का निर्देश दें। तो एजेंट "अब तक की प्रगति" को संदर्भ के रूप में प्राप्त करेगा और फिर "इस बार का कार्य" करेगा। इसका क्या फायदा है कि भले ही एजेंट रास्ते में रुक जाए या OOM से मर जाए, वह किसी न किसी तरह चलेगा। अगर प्रगति नोट बहुत बड़ा हो जाता है तो यह एक समस्या है, लेकिन आप उचित रूप से संक्षेप में और संपीड़ित करने के लिए एक संकेत लिख सकते हैं। हालांकि, यदि यह एक एकल लूप है, तो सभी कार्य एक एकल, महंगे मॉडल द्वारा किए जाते हैं, इसलिए कार्यों को डिजाइन और विभाजित करने का चरण महंगे मॉडल पर छोड़ दिया जाता है, और कार्यों को आसान दिखने वाले कार्यों को सस्ते एजेंटों द्वारा करने दिया जाता है, आदि, आप उस लूप के अंदर सामग्री को कितना भी जटिल बना सकते हैं, क्योंकि आप प्रोग्राम कर रहे हैं कि कोडिंग एजेंट को कॉल करना है या नहीं, इसलिए यह एक शानदार मेटाप्रोग्रामिंग है। मैं अभी तक इस क्षेत्र में नहीं पहुंचा हूं...उस लूप को ही LLM द्वारा बेहतर बनाना जल्द ही एक सामान्य बात होगी।
bsky.app
antirez ने कोड को गति देने के लिए जो संकेत दिया, उसमें "5. प्रगति को ट्रैक करने के लिए इस फ़ाइल का उपयोग करें" का निर्देश देना दिलचस्प है, कार्य समाप्त होने पर भी उसी पाठ का संदर्भ लेते हुए जारी रखने के लिए, पाठ में पिछली प्रगति को शामिल करना बहुत तर्कसंगत है।
5 बार स्व-समीक्षा
कोडिंग एजेंट द्वारा आउटपुट किया गया 90% कोड अच्छी तरह से काम करता है, लेकिन जब यह एक ठोस राशि बन जाती है, तो हर बार जब आप इसे स्व-समीक्षा करते हैं तो सुधार के लिए क्षेत्र पाए जाते हैं। मैं चाहता हूं कि आप शुरू से ही समीक्षा की आवश्यकता के बिना एक पूर्ण कोड लिखें, लेकिन चूंकि मनुष्यों के लिए भी ऐसा करना मुश्किल है, इसलिए एलएलएम में दोष हैं जो समीक्षा नहीं करने पर अन्य संदर्भों में नहीं पाए जा सकते हैं। मनुष्यों को अपने लिखे कोड को प्रतिबिंबित करने में समय लग सकता है, लेकिन विदेशी इंजीनियरों के अनुसार, जब एक कोडिंग एजेंट को स्व-समीक्षा करने के लिए कहा जाता है, तो यह अक्सर 5 बार में अभिसरण करता है।
https://steve-yegge.medium.com/six-new-tips-for-better-coding-with-agents-d4e9c86e42a9
लागत के संदर्भ में, बेशक, यह बहुत अधिक है, लेकिन यह अभी भी मनुष्यों की तुलना में बहुत सस्ता है, और यदि इसे एक तंत्र के रूप में शामिल किया जाता है, तो मनुष्यों के हस्तक्षेप के लिए कोई जगह नहीं होगी। मुझे नहीं पता कि 5 नंबर का कोई ठोस अर्थ है या नहीं, और यह भविष्य में एक अलग संख्या होगी, लेकिन एक अनुभव के रूप में, यहां तक कि अगर आप एजेंट द्वारा लिखे गए कोड को कई बार समीक्षा करवाते हैं, तो सुधार के लिए कई क्षेत्र हैं, एलएलएम की विशेषता प्रतिबिंब है। (ऐसे समीक्षा टिप्पणियां भी हैं जो संवाद स्थापित करने के लिए दोषों की तरह दिखती हैं, इसलिए समीक्षा टिप्पणियों की समीक्षा भी आवश्यक हो सकती है)। ऐसा लगता है कि कोडिंग एजेंट द्वारा लिखे गए कोड को अभी भी उत्पादन में उपयोग किए जाने पर अंत में एक मानव द्वारा समीक्षा की जानी चाहिए, लेकिन एक मानव द्वारा समीक्षा करने से पहले मशीन द्वारा एन बार स्व-समीक्षा करना सामान्य ज्ञान बन जाएगा। ऐसा लगता है कि रचनात्मक और निंदक पक्ष एक-दूसरे को ऊंचा करते हैं। कई कंपनियों के एजेंटों द्वारा समीक्षा करने से नए दृष्टिकोण सामने आ सकते हैं।
यह थोड़ा बहुत लंबा हो गया है इसलिए मैं इसे यहीं पोस्ट करूँगा।