बड़े भाषा मॉडल प्रोग्रामिंग को बदल देंगे ... बहुत कुछ

अधिकांश जो मुझे अच्छी तरह से जानते हैं, वे जानते हैं कि मेरे पास एक विरोधाभासी लकीर है। मैं हमेशा बहस के दूसरे पक्ष को लेने में दिलचस्पी रखता हूं। मैं आम तौर पर एक पुनरावृत्त हेगेलियन थीसिस/एंटी-थीसिस प्रवचन से बहुत कुछ प्राप्त करने के लिए देखता हूं, यहां तक ​​​​कि उन विषयों पर भी जिनके लिए मुझे दृढ़ विश्वास है। कभी-कभी यह मेरे लेखन को पढ़ने वाले लोगों के लिए भ्रमित करने वाला होता है, क्योंकि उन्हें लगता है कि मुझे पिन करना मुश्किल है। मैं वास्तव में क्या विश्वास करता हूँ? मेरे वास्तविक मूल्य क्या हैं?

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

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

लेकिन अब तक, इन सभी में मेरा पसंदीदा ग्रेग लिटिल का कीवर्ड प्रोग्रामिंग का कॉन्सेप्ट था2000 के मध्य में वापस। ग्रेग ने देखा, एक आधार के रूप में, कि दुनिया के अधिकांश संभावित कार्यक्रम बेकार हैं; उपयोगी खोज स्थान वास्तव में आकार में अनंत होने के बावजूद काफी छोटा है, और इसलिए यह मामला होना चाहिए कि उपयोगी कार्यक्रमों को खोजने के लिए थोड़ी सी जानकारी पर्याप्त होनी चाहिए। उन्होंने कार्यालय उत्पादकता मैक्रोज़ और यहां तक ​​​​कि जावा सिस्टम प्रोग्रामिंग के कुछ डोमेन में कुछ प्रोटोटाइप के माध्यम से प्रदर्शित किया कि कई सबसे सामान्य कार्यक्रमों के लिए, यहां तक ​​​​कि कुछ कीवर्ड भी सामान्य कार्यों के लिए सार्थक कार्यक्रम उत्पन्न करने के लिए पर्याप्त थे। ये सिस्टम हमेशा किनारे के मामलों या उपन्यास आवश्यकताओं में अच्छे नहीं थे, लेकिन वितरण का गैर-लंबी पूंछ वाला हिस्सा, बहुत कम इनपुट के साथ कई कार्यक्रमों को आसानी से प्राप्त किया जा सकता है। मैं उस बिंदु से (लगभग बीस साल पहले इस बिंदु पर) आश्वस्त था कि अंततः हमारे पास एक ऐसी दुनिया होगी जिसमें अधिकांश आवश्यकताओं के लिए अधिकांश कार्यक्रम स्वचालित रूप से उत्पन्न करना आसान होगा। यह सिर्फ डेटा, इंजीनियरिंग और उन सभी को एक साथ जोड़ने के लिए शायद थोड़ा सा इनोवेशन का मामला था।

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

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

तो अगर यह भविष्य 15 साल पहले शोध में दिख रहा था, तो अब क्या दिख रहा है जो 15 साल में आ रहा है? मेरे विचार में, मेरा मानना ​​है कि प्रोग्रामिंग और सॉफ्टवेयर इंजीनियरिंग के बारे में अधिकांश केंद्रीय मुद्दे कोड निर्माण के बारे में नहीं होंगे, बल्कि निर्माण से पहले और बाद में सब कुछ के बारे में होंगे: अर्थात्, आवश्यकताएं और सत्यापन। क्या बनाना है, क्यों बनाना है, और क्या बनाया गया है, यह तय करना वास्तव में इन लक्ष्यों को प्राप्त करता है, ये सॉफ्टवेयर की अगली सीमा हैं ।

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

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

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

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