Escaping the Quicksand: A Call to Arms
एआई-संचालित विकास के कारण बढ़ते तकनीकी ऋण (टेक्निकल डेब्ट) के जोखिमों को संबोधित करने के लिए, यह शोध पत्र विशुद्ध रूप से गद्य-आधारित विनिर्देशों (स्पेसिफिकेशन्स) से हटकर परीक्षण, निष्पादन योग्य विनिर्देशों और औपचारिक प्रमाणों के एक लचीले संयोजन की ओर एक व्यावहारिक बदलाव का समर्थन करता है, जो मानव और एआई इंजीनियरों दोनों के लिए अधिक प्रभावी फीडबैक लूप बनाने हेतु नए सिमेंटिक्स इंफ्रास्ट्रक्चर द्वारा समर्थित हो।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
एक ऐसी दुनिया की कल्पना करें जहाँ आधुनिक जीवन की अदृश्य मशीनरी—हमारे बैंक, अस्पताल, पावर ग्रिड और संचार नेटवर्क—एक ऐसे आधार पर बनी है जो धीरे-धीरे धंस रहा है। आज कंप्यूटिंग उद्योग के सामने यही वास्तविकता है। दशकों से, सॉफ्टवेयर बनाने का मानक तरीका यह रहा है कि एक प्रोग्राम को क्या करना चाहिए इसका एक मोटा विवरण लिखा जाए, फिर कोड लिखा जाए, और अंत में इसे विभिन्न इनपुट्स के साथ चलाकर परीक्षण किया जाए कि क्या यह टूट जाता है। 'टेस्ट-एंड-डिबग' (परीक्षण और सुधार) विकास के रूप में जानी जाने वाली इस पद्धति ने तकनीक को फलने-फूलने में मदद तो की है, लेकिन यह सिस्टम को छिपे हुए दोषों से भर देती है। क्योंकि मूल विवरण अक्सर साधारण भाषा में लिखे गए अस्पष्ट होते हैं, इसलिए उन्हें मशीनों द्वारा जांचा नहीं जा सकता, और चूंकि परीक्षण केवल उन अरबों संभावित तरीकों के एक बहुत छोटे हिस्से को ही कवर कर सकता है जिनसे एक प्रोग्राम व्यवहार कर सकता है, इसलिए कई त्रुटियां निकल जाती हैं। जैसे-जैसे आर्टिफिशियल इंटेलिजेंस अधिक कोड लिखना शुरू कर रहा है, यह चक्र और भी तेज होने का खतरा पैदा करता है, जिससे ऐसे विशाल नए सिस्टम बनते हैं जो पहले की तुलना में और भी अधिक जटिल और नाजुक होते हैं, जो दशकों पुराने डिजाइन विकल्पों के "रेत के टीले" (quicksand) पर बने होते हैं, जो तब बनाए गए थे जब साइबर हमले दुर्लभ और कंप्यूटिंग शक्ति कम थी।
दो शोधकर्ता, कैम्ब्रिज विश्वविद्यालय से पीटर सेवेल और ऑरस विश्वविद्यालय से जीन पिचोन-फराबोड का तर्क है कि उद्योग पिछले पचहत्तर वर्षों से एक खतरनाक लूप में फंसा हुआ है। वे देखते हैं कि जबकि हम कोड लिखने में अविश्वसनीय रूप से कुशल हो गए हैं, हमने इस बात की सटीक परिभाषाओं की उपेक्षा की है कि वह कोड वास्तव में क्या हासिल करने के लिए है। वर्तमान दृष्टिकोण 'प्रोज़ स्पेसिफिकेशन' (गद्य विवरण) पर निर्भर करता है—पाठ के वे पैराग्राफ जो किसी सिस्टम के व्यवहार का वर्णन करते हैं। हालांकि ये मनुष्यों के पढ़ने में आसान होते हैं, लेकिन ये स्वाभाविक रूप से अस्पष्ट और अपूर्ण होते हैं। एक मानव पाठक एक वाक्य की व्याख्या एक तरह से कर सकता है, जबकि एक मशीन या दूसरा मानव उसे अलग तरह से समझ सकता है। क्योंकि इन विवरणों को कंप्यूटर द्वारा सीधे जांचा नहीं जा सकता, इसलिए डेवलपर्स को यह अनुमान लगाने के लिए मजबूर होना पड़ता है कि सही व्यवहार क्या होना चाहिए, और वे अक्सर केवल इस तरह की सरल जांचों पर निर्भर हो जाते हैं कि "क्या प्रोग्राम क्रैश हो रहा है?" बजाय इसके कि यह सत्यापित किया जाए कि क्या प्रोग्राम वास्तव में सही काम कर रहा है। लिखित इरादे और वास्तविक कोड के बीच का यह अंतर एक विशाल 'तकनीकी ऋण' (technical debt) पैदा करता है, जो एक छिपा हुआ खर्च है जो सुरक्षा कमजोरियों और सिस्टम विफलताओं के रूप में प्रकट होता है जिनका उपयोग हमलावर कर सकते हैं।
लेखक सुझाव देते हैं कि समाधान परीक्षण को छोड़ना नहीं है, बल्कि हम विशिष्टताओं (specifications) का उपयोग कैसे करते हैं, इसे बदलना है। अस्पष्ट पैराग्राफ लिखने के बजाय, वे 'एग्जीक्यूटेबल स्पेसिफिकेशन' (निष्पादन योग्य विशिष्टताएँ) बनाने का प्रस्ताव देते हैं, जिसका अर्थ है कि वे एक ऐसे रूप में लिखी गई हैं जिसे कंप्यूटर चला सके। एक ऐसी विशिष्टता की कल्पना करें जो विकास प्रक्रिया के दौरान एक लाइव रेफरी के रूप में कार्य करती है। जैसे-जैसे कोड लिखा या उत्पन्न किया जाता है, यह निष्पादन योग्य विशिष्टता उसके साथ चलती है, तुरंत यह जांचती है कि क्या कोड का व्यवहार इच्छित नियमों से मेल खाता है। यदि कोड कुछ ऐसा करने की कोशिश करता है जिसे विशिष्टता वर्जित करती है, तो सिस्टम इसे तुरंत चिह्नित कर देता है। यह एक बहुत ही सटीक फीडबैक लूप बनाता है, जिससे डेवलपर्स त्रुटियों को होने के तुरंत बाद पकड़ सकते हैं, न कि हफ्तों बाद। इस दृष्टिकोण को विभिन्न तरीकों से लागू किया जा सकता है: कोई कोड के साथ शुरुआत कर सकता है और उससे मेल खाने के लिए एक विशिष्टता लिख सकता है, विशिष्टता के साथ शुरुआत कर सकता है और ऐसा कोड उत्पन्न कर सकता है जो उसमें फिट हो, या दोनों को एक साथ बना सकता है। मुख्य बात यह है कि विशिष्टता केवल पढ़ने के लिए एक दस्तावेज़ नहीं है, बल्कि उपयोग के लिए एक उपकरण है।
हालाँकि, शोधकर्ता स्वीकार करते हैं कि यह कोई साधारण स्विच नहीं है जिसे बस चालू कर दिया जाए। इसे बड़े पैमाने पर काम करने के लिए, कंप्यूटिंग समुदाय को बुनियादी ढांचे की एक नई परत बनाने की आवश्यकता है। वर्तमान में, कई मौलिक तकनीकों, जैसे कि सी (C) प्रोग्रामिंग भाषा, रस्ट (Rust) भाषा, या कंप्यूटर चिप्स पर चलने वाले निर्देशों के व्यवहार के लिए कोई सार्वभौमिक रूप से स्वीकृत, मशीन-पठनीय परिभाषाएँ नहीं हैं। जबकि कुछ शोधकर्ताओं ने सिस्टम के विशिष्ट हिस्सों के लिए ये परिभाषाएँ सफलतापूर्वक बनाई हैं, लेकिन ऐसा कोई एकीकृत ढांचा नहीं है जो उन सभी को जोड़ता हो। लेखक बताते हैं कि इस बुनियादी ढांचे का निर्माण पैमाने और सहयोग की चुनौती है। इसके लिए हार्डवेयर से लेकर क्लाउड सेवाओं तक, कंप्यूटिंग तकनीक के पूरे स्टैक के लिए इन सटीक परिभाषाओं को बनाने, सत्यापित करने और बनाए रखने के लिए विश्वविद्यालयों, सरकारों और प्रौद्योगिकी कंपनियों के एक बड़े, समन्वित प्रयास की आवश्यकता है।
यह पत्र आर्टिफिशियल इंटेलिजेंस की भूमिका को भी संबोधित करता है। लेखक चेतावनी देते हैं कि बेहतर फीडबैक लूप के बिना केवल अधिक कोड लिखने के लिए एआई (AI) का उपयोग करना समस्या को और बदतर बना देगा। एआई मनुष्यों की तुलना में तेजी से कोड उत्पन्न कर सकता है, लेकिन यदि वह कोड कमजोर नींव पर बना है और केवल पुराने, अप्रभावी तरीकों से परीक्षण किया गया है, तो यह केवल अधिक छिपी हुई त्रुटियों वाले बड़े सिस्टम ही बनाएगा। इसके विपरीत, यदि एआई का उपयोग इन निष्पादन योग्य विशिष्टताओं को बनाने और जांचने में मदद करने के लिए किया जाता है, तो यह सॉफ्टवेयर की गुणवत्ता में सुधार के लिए एक शक्तिशाली उपकरण बन सकता है। लेखक एक ऐसे भविष्य की कल्पना करते हैं जहाँ एआई कठोर विशिष्टताएँ बनाने में मदद करता है, और जहाँ उन विशिष्टताओं का उपयोग यह सत्यापित करने के लिए किया जाता है कि मानव-लिखित और एआई-लिखित दोनों कोड सही हैं। यह एक क्रमिक विश्वास वृद्धि की अनुमति देगा, जिसमें सरल परीक्षणों से शुरू होकर सही होने के गणितीय प्रमाणों की ओर बढ़ा जा सकता है, और वह भी बिना हर डेवलपर को गणितज्ञ बनाए।
स्पष्ट मार्ग के बावजूद, लेखकों का तर्क है कि उद्योग को प्रोत्साहन के बेमेल होने के कारण पीछे धकेला गया है। प्रौद्योगिकी कंपनियाँ बाजार में हिस्सेदारी हासिल करने के लिए उत्पादों को जल्दी से जारी करने के लिए प्रेरित होती हैं, जबकि विफलता के जोखिम काफी हद तक समाज और अंतिम उपयोगकर्ताओं पर आते हैं। विफलताओं को रोकने के लिए आवश्यक मजबूत बुनियादी ढांचे का निर्माण महंगा और समय लेने वाला है, और कोई भी अकेली कंपनी उन समस्याओं को ठीक करने की पूरी लागत वहन नहीं करना चाहती जो सभी को प्रभावित करती हैं। शोधकर्ता एक सामूहिक प्रयास का आह्वान करते हैं, जैसा कि भौतिकी या जीव विज्ञान में देखे जाने वाले बड़े पैमाने के प्रोजेक्ट्स में देखा जाता है, ताकि इस 'सिमेंटिक इंफ्रास्ट्रक्चर' (अर्थगत बुनियादी ढांचे) के निर्माण के लिए वित्त पोषण और समन्वय किया जा सके। उनका सुझाव है कि हालांकि लागत महत्वपूर्ण है, यह आर्टिफिशियल इंटेलिजेंस पर वर्तमान खर्च का एक बहुत छोटा हिस्सा है और कंप्यूटिंग के भविष्य को सुरक्षित करने के लिए आवश्यक है। इस बदलाव के बिना, उद्योग बढ़ते जटिल सिस्टम बनाने के चक्र में फंसा हुआ है जो ऐसे आधारों पर बने हैं जो उन्हें सहारा देने के लिए बहुत कमजोर हैं, जिससे समाज निरंतर जोखिम के प्रति असुरक्षित रहता है।
लेखक निष्कर्ष निकालते हैं कि इस समस्या को हल करने के उपकरण और विधियाँ पहले से ही मौजूद हैं। शोधकर्ताओं ने सफलतापूर्वक प्रदर्शित किया है कि जटिल प्रणालियों को कैसे परिभाषित किया जाए और उच्च विश्वास के साथ उन्हें सत्यापित किया जाए। जो गायब है वह है इन विधियों को दैनिक अभ्यास में लाने और उस साझा बुनियादी ढांचे के निर्माण की इच्छा जो इसे सभी के लिए सुलभ बनाता है। यह पत्र अनुसंधान समुदाय, उद्योग जगत के नेताओं और वित्त पोषण एजेंसियों के लिए इस कार्य पर सहयोग करने के लिए एक आह्वान है। अस्पष्ट विवरणों से हटकर सटीक, निष्पादन योग्य विशिष्टताओं की ओर बढ़कर, कंप्यूटिंग जगत तकनीकी ऋण के रेत के टीले से बच सकता है और एक ऐसा भविष्य बना सकता है जो न केवल अधिक अभिनव है बल्कि मौलिक रूप रूप से सुरक्षित और अधिक विश्वसनीय भी है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।