Measuring What a Specification Determines: A Formal Semantic-Block Model and an Execution-Judged Benchmark

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

शोधकर्ताओं की एक टीम ने इस मापन समस्या को हल करने के लिए एक विशिष्ट, जटिल कार्य का परीक्षण करके इसकी शुरुआत की: एक विशाल डेटाबेस को एक प्रकार के सिस्टम से दूसरे में स्थानांतरित करना। उन्होंने एक ओरेकल (Oracle) डेटाबेस से पोस्टग्रेएसक्यूएल (PostgreSQL) डेटाबेस में डेटा माइग्रेट करने के लिए एक औपचारिक, संरचित स्पेसिफिकेशन बनाया, जो एक ऐसी प्रक्रिया है जिसमें डेटा कैसे संग्रहीत और संसाधित किया जाता है, इसके हजारों नियमों का अनुवाद शामिल है। यह परीक्षण करने के लिए कि क्या इस स्पेसिफिकेशन ने वास्तव में मदद की, उन्होंने केवल एआई को कोड लिखने और यह जाँचने के लिए नहीं कहा कि वह कैसा दिखता है। इसके बजाय, उन्होंने एक कठोर प्रयोग बनाया जहाँ एआई प्रणालियों के एक ही समूह को दो बार माइग्रेशन करना था: एक बार विस्तृत स्पेसिफिकेशन के साथ और एक बार इसके बिना। शोधकर्ताओं ने एक लाइव ओरेकल डेटाबेस और एक नए पोस्टग्रेएसक्यूएल सिस्टम का उपयोग एक सख्त निर्णायक के रूप में किया। उन्होंने एआई द्वारा उत्पन्न कोड को मूल डेटा के विरुद्ध चलाया ताकि यह देखा जा सके कि परिणाम समान हैं या नहीं, और सॉफ्टवेयर के वास्तविक व्यवहार को ही सफलता के एकमात्र मापदंड के रूप में माना।

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

हालाँकि, कहानी तब बदल गई जब शोधकर्ताओं ने यह देखा कि क्या स्पेसिफिकेशन ने एआई सिस्टमों के बीच एक-दूसरे के प्रति सहमति बढ़ाई। अध्ययन से पहले, एक उम्मीद थी कि एक आदर्श योजना सभी एआई सिस्टमों को बिल्कुल एक जैसे निर्णय लेने के लिए मजबूर करेगी, जिससे एक एकीकृत समाधान बनेगा। डेटा ने दिखाया कि ऐसा नहीं हुआ। स्पेसिफिकेशन के बिना भी, एआई सिस्टम 83 प्रतिशत समय एक-दूसरे से सहमत थे, जो संभवतः उनके प्रशिक्षण के दौरान सीखी गई समान उद्योग प्रथाओं के कारण था। जब स्पेसिफिकेशन जोड़ा गया, तो सहमति की यह दर मुश्किल से बढ़ी, जो केवल 83.8 प्रतिशत तक पहुँची। योजना ने एआई के उन निर्णयों पर उसके मन को नहीं बदला जो वह पहले से ही ले रहा था; इसने केवल एआई को उन निर्णयों को बिना टूटे निष्पादित करने में मदद की।

शोधकर्ताओं ने यह भी पाया कि जानकारी कैसे प्रस्तुत की जाती है, यह इस बात से अधिक महत्वपूर्ण था कि कितनी जानकारी दी गई है। एक प्रयोग में, उन्होंने एक एकल नियम लिया और उसे दस्तावेज़ के विभिन्न हिस्सों में रखा। जब उस नियम को एक अनुभाग के अंत में एक पैराग्राफ में दबा दिया गया, तो एआई ने उसका पालन केवल 23 प्रतिशत समय किया। जब उसी नियम को अनुभाग के शीर्ष पर एक संरचित तालिका में रखा गया, तो अनुपालन बढ़कर 42 प्रतिशत हो गया। आश्चर्यजनक रूप से, नियम को दोनों स्थानों पर दोहराने से अनुपालन दर वास्तव में 34 प्रतिशत तक गिर गई, जिससे पता चलता है कि अतिरेक (redundancy) सिस्टम को सुदृढ़ करने के बजाय भ्रमित कर सकता है। यह निष्कर्ष इंगित करता है कि दस्तावेज़ की संरचना पाठ की मात्रा से अधिक प्रभावशाली है।

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

अंततः, शोध यह निष्कर्ष निकालता है कि एक स्पेसिफिकेशन सॉफ्टवेयर को निष्पादन योग्य बनाने और मनुष्यों को यह खोजने में मदद करने के लिए एक शक्तिशाली उपकरण है कि निर्देश कहाँ गायब हैं, लेकिन यह एक जादुई छड़ी नहीं है जो विभिन्न एआई सिस्टमों को एक जैसा सोचने के लिए मजबूर करती है। स्पेसिफिकेशन ने सफलतापूर्वक टूटे हुए प्रोग्रामों की संख्या को लगभग एक चौथाई कम कर दिया, जो यह सिद्ध करता है कि कोड चलाने में इसकी भूमिका है। फिर भी, यह विभिन्न एआई सिस्टमों के बीच सहमति बढ़ाने या स्वयं डेटा की सटीकता में सुधार करने में विफल रहा, जो दोनों नियंत्रित और अनियंत्रित समूहों में 42 परीक्षणों में से 19 सही परिणामों के रूप में अपरिवर्तित रहा। अध्ययन बताता है कि वर्तमान पीढ़ी के एआई के लिए, एक स्पेसिफिकेशन एक मार्गदर्शक के बजाय एक सुरक्षा जाल (safety net) की तरह कार्य करता है जो विनाशकारी विफलता को रोकता है। स्पेसिफिकेशन की वास्तविक शक्ति एआई को सहमत होने के लिए मजबूर करने में नहीं, बल्कि सॉफ्टवेयर बनाने की प्रक्रिया को इतना विश्वसनीय बनाने में है कि उसे जांचा और सत्यापित किया जा सके।