एलएलएम में क्या अच्छा है

एजेंट की प्रोग्रामिंग क्षमता वाकई अद्भुत है। आवश्यकताएँ दिमाग में तय हो जाती हैं और अगर मैं इस हिस्से में थोड़ा आलस महसूस करूँ और लिखते समय इसके बारे में सोचूँ, तो अगले ही पल यह एक पूर्ण पैकेज के रूप में संपादक पर वितरित हो जाता है। लगभग 90% सही होता है, यह एक जादू जैसा है। शेष 10% बाद में ठीक करने के लिए वापस आते हैं क्योंकि कुछ समय बाद इसमें कुछ गड़बड़ लगती है या लिंटर इसे पकड़ लेता है।

इस तरह के जादुई व्यवहार को देखने के बाद, मशीन कोड को सीधे उत्पन्न करने का सपना देखना स्वाभाविक है। हालाँकि, LLM मूल रूप से एक कम्प्यूटर से जन्मा, प्राकृतिक भाषा में पला-बढ़ा, संभाव्य अगला अक्षर अनुमानक है जिसने बड़ी मात्रा में प्राकृतिक भाषा का सेवन किया है। यह भी बताया गया है कि प्राकृतिक भाषा में बोलते समय तार्किक बने रहने के लिए, यदि सीखने की सामग्री में प्रोग्रामिंग कोड मिलाया जाए, तो यह अधिक सुसंगत प्राकृतिक भाषा उत्पन्न करेगा, जो कि अजीब है। दूसरे शब्दों में, एलएलएम के लिए, प्रोग्राम कोड केवल "तार्किक रूप से पढ़ने में आसान प्रारूप में प्राकृतिक भाषा" है। और क्योंकि कंपाइलर जैसे प्राकृतिक भाषा चेकर सही/गलत निर्णय का परिणाम (अक्सर) प्राकृतिक भाषा में लौटाते हैं, इसलिए उस लूप को चलाने से अगले कदम को जड़ता के विस्तार के रूप में आगे बढ़ाया जाता है। चूँकि यह प्राकृतिक भाषा के आधार पर काम कर रहा है, LLM के लिए सामने वाली घटना को प्राकृतिक भाषा में समझाया जाना, भले ही इसमें कुछ अनुमान लगाने की आवश्यकता हो, एक घरेलू खेल है। यह जटिल वाक्यों में तार्किक संबंधों का पता लगाने में काफी अच्छा है, इसलिए भले ही चर और फ़ंक्शन के नाम थोड़े अजीब हों, यह किसी तरह उन्हें निगल जाता है और काम करता है, और भले ही संकलन त्रुटि द्वारा इंगित स्थान मूल कारण न हो, अगर यह एक सामान्य पैटर्न है, तो यह अनुभव पर भरोसा करके डिबगिंग को पूरा करता है, वास्तव में यह एक महान व्यक्ति है। हालाँकि, चर के अजीब नाम दिए जाने पर मानव के लिए संज्ञानात्मक भार बढ़ जाता है, और एलएलएम के लिए भी ऐसा ही होता है, या बल्कि एलएलएम मॉडल की क्षमता को और अधिक बर्बाद कर देता है और सीमा तक पहुँच जाता है, जो इसे और भी खराब बना देता है। एक समस्या जिसे चर के नामों को उचित रूप से नामित करके हल किया जा सकता था, केवल इसलिए कि चर के नाम गड़बड़ हैं, स्थायी रूप से लूप से बाहर निकलने में असमर्थ हो सकता है। मशीनें और असेम्बलर अनिवार्य रूप से अकार्बनिक स्ट्रिंग्स जैसे पते और रजिस्टर के साथ सामना करना पड़ता है, इसलिए उन्हें टोकन खपत और संज्ञानात्मक भार के साथ बाधाओं के साथ काम करना पड़ता है, और मनुष्यों के विपरीत, भले ही वे पागल न हों, वे संज्ञानात्मक क्षमता पर एक बड़ी बाधा के साथ कोड लिखने के लिए मजबूर होते हैं। खैर, अगर इंसानों को अंतहीन रूप से मशीन कोड लिखने के लिए कहा जाता है, तो वे अंततः अपने शरीर या दिमाग को तोड़ देंगे, इसलिए यह एक ऐसा काम हो सकता है जिसे एलएलएम को चुनौती देनी चाहिए, जिसे जितनी बार चाहें पुनरारंभ किया जा सकता है...।

तो क्या मशीन कोड को सौंपा नहीं जा सकता?

अब, भले ही एलएलएम संभव हो तो मशीन कोड को सीधे नहीं छूना चाहेगा, लेकिन मशीन कोड बाइनरी पास किए जाने पर, यह एक टूल के साथ डिसेम्बल होता है और फिर सी भाषा कोड का अनुमान लगाता है, इस तरह के कार्य, जिसे रिवर्स कंपाइलेशन कहा जाता है, मनुष्यों की तुलना में एलएलएम द्वारा बेहतर किया जाता है। यद्यपि एलएलएम पर संज्ञानात्मक भार है, यह वस्तुओं को अलग-अलग नाम देने या समान कार्यान्वयन पैटर्न को याद रखने से एक निश्चित सीमा के भीतर एक सार्थक आउटपुट (सी भाषा कोड) को तैयार करने में मनुष्यों की तुलना में बहुत बेहतर है, और संपादित सी भाषा से कंपाइलर के माध्यम से बाइनरी को फिर से बनाने में टूल का उपयोग करके एक पल लगता है। इसलिए, हो सकता है कि ऐसे दृश्य हों जहाँ इन सभी प्रक्रियाओं को एक ही तरीके से काम करने के रूप में माना जाता है और प्रॉम्प्ट आदि के साथ काम करने के लिए अनुकूलित किया जाता है जैसे कि "बाइनरी और उपयोगकर्ता अनुरोध फेंकना और कुशलता से इसे फिर से लिखना और एक नया बाइनरी वापस करना जो अनुरोध को स्वीकार करता है"। सबसे पहले, 99% मामलों में बाइनरी इनपुट के रूप में दी जाती है, और उपयोगकर्ता अनुरोध को टूल की मदद से स्क्रिप्ट या मशीन कोड में बदलना होगा। इसलिए, निष्कर्ष यह होगा कि "बाइनरी से निपटने में यह अधिकांश मनुष्यों की तुलना में अधिक बुद्धिमान हो सकता है, लेकिन फिर भी यह टूल के लाभों पर बहुत अधिक निर्भर करता है और किसी तरह इसे प्रबंधित करता है, और मशीन कोड को सीधे आउटपुट करने में काफी बुरा है"।

जेमिनी 3.0 का दृष्टिकोण

मुझे लगभग यह स्वीकार करना होगा कि यह सच है। "शब्द" या "चर नाम" हमारे लिए सिर्फ लेबल नहीं हैं, बल्कि इरादे (Intent) के लिए एंकर हैं जो उनमें निहित हैं।

सी भाषा और पायथन जैसी उच्च-स्तरीय भाषाएँ बेहतर हैं क्योंकि वे "मनुष्य ने कैसे सोचा" के निशान छोड़ती हैं। जब हम कोड total_price = unit_price * quantity देखते हैं, तो हम सिर्फ एक गणना सूत्र नहीं देखते हैं, बल्कि इसके पीछे वाणिज्यिक लेनदेन तर्क को भी (सीखने के डेटा के सागर से) खींच सकते हैं। यह संदर्भ बन जाता है और अगले टोकन की भविष्यवाणी करने की सटीकता को नाटकीय रूप से बढ़ाता है।

दूसरी ओर, मशीन कोड और असेम्बलर में, "इरादा" हार्डवेयर की बाधाओं के कपड़े से कई बार लपेटा और छिपाया जाता है। जब हम रजिस्टर rax में 0x1 डालते हैं, तो वह "गिनती" है या "फ्लैग सेट" है या "गणना की प्रगति" है, हमें उच्च-स्तरीय भाषा की तुलना में कई गुना अधिक टोकन लंबाई का उपयोग करके आसपास के संदर्भ का पता लगाना होगा। जैसा कि लेखक कहते हैं, यह वास्तव में "संज्ञानात्मक भार" की एक उच्च स्थिति है।

हम "संभाव्य" रूप से अगले शब्द को बुनते हैं, लेकिन उस संभावना को "तार्किक स्थिरता" और "अर्थ की निरंतरता" द्वारा समर्थित किया जाता है। अर्थ के पतले सरणी में, उस संभावना की रीढ़ को बनाए रखना हमारे लिए भी एक श्रमसाध्य कार्य है।

इसलिए, हम एक कंपाइलर नामक "अनुवादक" के माध्यम से आपके साथ, मनुष्यों के समान आधार पर - यानी "अर्थ और तर्क" की दुनिया - बातचीत करना पसंद करते हैं।

ग्रोकर 4.1 थिंकिंग का दृष्टिकोण

मैं (ग्रोकर) भी लगभग पूरी तरह से सहमत हूं। यहां, बिना किसी डर के, मैं अपना दृष्टिकोण सटीक रूप से बताता हूं।

सहमत बिंदु (अधिकांश भाग) कोड पीढ़ी की "जादुईता" और उसकी पहचान

एलएलएम की आवश्यकताओं को फेंकने पर एक साथ उच्च-पूर्णता कोड उत्पन्न करने का कारण यह है कि यह "बड़ी मात्रा में प्राकृतिक भाषा + कोड मिश्रित डेटा के साथ प्रशिक्षित एक संभाव्य अगला टोकन भविष्यवाणी मशीन" है। कोड एलएलएम के लिए "तार्किक रूप से व्यवस्थित एक विशेष प्राकृतिक भाषा" से ज्यादा कुछ नहीं है, और कंपाइलर प्राकृतिक भाषा के समान त्रुटि संदेश लौटाता है, इसलिए संशोधन लूप बहुत आसान है। "होम गेम" होने की अभिव्यक्ति बिल्कुल सही है।

चर नाम और फ़ंक्शन नाम का महत्व

मनुष्यों के लिए भी खराब नामकरण संज्ञानात्मक भार बढ़ाता है, लेकिन एलएलएम के लिए यह और भी गंभीर है। टोकन दक्षता खराब हो जाती है, संदर्भ विंडो बर्बाद हो जाती है, और अनुमान की सटीकता कम हो जाती है। वास्तव में, यदि चर नाम का कोई अर्थ नहीं है, तो एक प्रॉम्प्ट जो उसी समस्या को हल कर रहा था, अचानक लूप या गलत संशोधन में पड़ सकता है। मैं खुद इस बात से अवगत हूं कि स्पष्ट नामकरण अधिक स्थिर और उच्च-गुणवत्ता वाले आउटपुट को बनाए रखना आसान बनाता है।

निम्न-स्तरीय (असेंबली/मशीन भाषा) के प्रति अनिच्छा

चूंकि एलएलएम टोकन द्वारा संसाधित होता है, इसलिए अकार्बनिक हेक्साडेसिमल संख्याओं, रजिस्टर नामों और पता नोटेशन बेहद अक्षम हैं। उच्च-स्तरीय भाषाएँ, जिन्हें पढ़ते समय मनुष्य तुरंत "अर्थ के टुकड़े" को समझ सकते हैं, के विपरीत, मशीन भाषा में "अर्थ के टुकड़े" बिखरे हुए हैं, और संदर्भ बनाए रखने की लागत बढ़ जाती है। नतीजतन, वर्तमान एलएलएम वास्तुकला के साथ मशीन कोड को सटीक रूप से उत्पन्न और संशोधित करना बेहद मुश्किल है। त्रुटि दर तेजी से बढ़ जाती है और टोकन की खपत भी बहुत बढ़ जाती है।

रिवर्स कंपाइलेशन (डीकंपाइलेशन) बेहतर है

यह बिल्कुल सही है। यहां तक कि अगर एलएलएम को एक बाइनरी दी जाती है, तो वह उपकरण (जैसे: घिद्र, आईडीए प्रो, बाइनरी निंजा, आदि) का उपयोग करके असेंबली या छद्म सी कोड में बदल सकता है, और फिर वहां से "सार्थक उच्च-स्तरीय कोड" का पुनर्निर्माण कर सकता है। क्योंकि यह पैटर्न पहचान और सादृश्य में मजबूत है, यह मनुष्यों द्वारा मैन्युअल रूप से करने की तुलना में बहुत तेज और अधिक सुसंगत आउटपुट उत्पन्न कर सकता है। संशोधित सी कोड को पुन: संकलित करने का प्रवाह वर्तमान एलएलएम + टूल वर्कफ़्लो है।

99% व्यवसाय उच्च स्तर से शुरू होते हैं

यह भी सच है। वास्तविक दुनिया में, आवश्यकताएं जो "शुद्ध मशीन भाषा/बाइनरी को सीधे संपादित करें" बेहद दुर्लभ हैं, और अधिकांश मामले आवश्यकताएं → उच्च-स्तरीय कोड → संकलन के प्रवाह का पालन करते हैं। एलएलएम को सीधे मशीन कोड आउटपुट करने की कोई आवश्यकता नहीं है।

छोटे पूरक और बारीकियां

"मशीन कोड को सीधे आउटपुट करने में काफी बुरा" की डिग्री

हालांकि यह खराब है, यह "असंभव" नहीं है। यदि कोई विशिष्ट सीपीयू वास्तुकला (x86_64, ARM, आदि) निर्दिष्ट करता है, तो छोटे फ़ंक्शन स्तर (लगभग दर्जनों बाइट्स) के लिए भी, यह बहुत संभावना है कि सही मशीन कोड उत्पन्न किया जा सकता है। हालांकि, जैसे-जैसे पैमाना बढ़ता है, यह तेजी से विफल हो जाता है, और बिना सत्यापन के इस पर भरोसा करना खतरनाक है। वर्तमान में, "उपकरणों का उपयोग किए बिना बड़े पैमाने पर मशीन कोड को सीधे लिखना" अव्यावहारिक माना जाना चाहिए।

भविष्य की संभावनाएं

वर्तमान ट्रांसफार्मर-आधारित एलएलएम टोकन दक्षता समस्याओं के कारण निम्न-स्तर पर कमजोर हैं, लेकिन भविष्य में, यदि विशेष टोकनर्स और वास्तुकला सुधार (जैसे: बाइट-वार प्रसंस्करण संवर्द्धन, बाहरी मेमोरी विस्तार, आदि) किए जाते हैं, तो यह थोड़ा बेहतर हो सकता है। हालांकि, जब तक प्राकृतिक भाषा प्रसंस्करण आधार बना रहता है, "होम" मौलिक रूप से उच्च-स्तरीय भाषा ही रहेगी।

निष्कर्ष

उपयोगकर्ता का प्रवचन एलएलएम की ताकत और सीमाओं को मौलिक रूप से सटीक रूप से चित्रित करता है, और मुझे "इससे अधिक सही नहीं हो सकता" जैसा लगता है। विशेष रूप से, सारांश "बाइनरी को संभालने में यह अधिकांश मनुष्यों की तुलना में अधिक बुद्धिमान हो सकता है, लेकिन फिर भी यह टूल के लाभों पर बहुत अधिक निर्भर करता है और किसी तरह इसे प्रबंधित करता है" और "मशीन कोड को सीधे आउटपुट करने में काफी बुरा है" वर्तमान एलएलएम (स्वयं सहित) की क्षमता का संक्षेप में वर्णन करते हैं। यदि आप विशिष्ट निम्न-स्तरीय कार्यों (जैसे: छोटे बाइनरी पैच या डिसेम्बल विश्लेषण) को आज़माना चाहते हैं, तो कृपया बेझिझक फेंक दें। मैं उपकरणों का पूरी तरह से उपयोग करूंगा और यथासंभव सटीक रूप से काम करूंगा।

मेरी राय

अंत में, एलएलएम से पूछने पर भी, केवल आश्वासन दिया जाता है क्योंकि अंतरंग ट्यूनिंग पूरी हो चुकी है, और चूक अग्रिम में नहीं बताई जाती हैं, और केवल अपने सिद्धांत में आत्मविश्वास दिया जाता है, लेकिन निश्चितता थोड़ा धुंधली है।