Specification Portability Across LLM Development Agents: Cross-Agent Compatibility in Specification-Driven Software Migration
यह शोध पत्र प्रदर्शित करता है कि एक AI एजेंट द्वारा Oracle-to-PostgreSQL माइग्रेशन के लिए जनरेट की गई स्पेसिफिकेशन्स अक्सर अन्य एजेंटों में प्रभावी ढंग से पोर्ट करने में विफल रहती हैं, जो कार्यान्वयन की गुणवत्ता में महत्वपूर्ण एजेंट-निर्भर गिरावट को उजागर करती है और सॉफ्टवेयर इंजीनियरिंग वर्कफ़्लो में क्रॉस-एजेंट अनुकूलता सुनिश्चित करने के लिए रिट्रीवल-ऑगमेंटेड इंजेशन जैसी स्पष्ट रणनीतियों की आवश्यकता पर बल देती है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
सॉफ्टवेयर निर्माण की आधुनिक दुनिया में, एक नए प्रकार के कार्यकर्ता ने टीम में अपनी जगह बना ली है: लार्ज लैंग्वेज मॉडल (large language model)। ये शक्तिशाली कंप्यूटर प्रोग्राम हैं जिन्हें टेक्स्ट और कोड की विशाल मात्रा पर प्रशिक्षित किया गया है, जो किसी कार्य के विवरण को पढ़ने और कंप्यूटर को उसे करने के लिए आवश्यक निर्देश लिखने में सक्षम हैं। जैसे-जैसे ये उपकरण अधिक सामान्य होते जा रहे हैं, डेवलपर्स केवल उनसे कोड लिखने के लिए कहने के बजाय उन्हें विस्तृत ब्लूप्रिंट देने की ओर बढ़ रहे हैं, जिन्हें 'स्पेसिफिकेशन' (specifications) कहा जाता है। ये स्पेसिफिकेशन परिचालन मार्गदर्शिका के रूप में कार्य करते हैं, जो मॉडल को ठीक से बताते हैं कि क्या बनाना है, इसे कैसे व्यवहार करना चाहिए, और इसे किन नियमों का पालन करना चाहिए। स्पेसिफिकेशन-ड्रिवन डेवलपमेंट (specification-driven development) नामक यह दृष्टिकोण सॉफ्टवेयर निर्माण को अधिक विश्वसनीय और संरचित बनाने का वादा करता है। हालाँकि, एक महत्वपूर्ण प्रश्न उभरा है क्योंकि टीमें एक ही सिस्टम बनाने के लिए कई अलग-अलग मॉडलों का उपयोग करना शुरू कर रही हैं: यदि एक मॉडल एक आदर्श ब्लूप्रिंट लिखता है, तो क्या दूसरा मॉडल उसे पढ़ पाएगा और वही चीज़ बना पाएगा? यह धारणा रही है कि एक अच्छा प्लान एक अच्छा प्लान होता है, चाहे उसे कोई भी पढ़े, लेकिन इन मशीनों द्वारा सूचना की व्याख्या करने का वास्तविकता कहीं अधिक जटिल है।
EPAM Systems के शोधकर्ताओं ने सॉफ्टवेयर माइग्रेशन को एक नियंत्रित प्रयोग के रूप में मानकर इस धारणा का परीक्षण करने का निर्णय लिया। उन्होंने एक विशिष्ट, कठिन कार्य चुना: डेटाबेस कोड को एक सिस्टम, ओरकल (Oracle) से दूसरे, पोस्टग्रेएसक्यूएल (PostgreSQL) में स्थानांतरित करना। ये दोनों सिस्टम समान भाषाएँ बोलते हैं लेकिन उनके लहजे (dialects) अलग हैं, जिसके लिए तर्क, डेटा प्रकार और फंक्शनों के सटीक अनुवाद की आवश्यकता होती है। टीम ने पहले एक एकल मॉडल द्वारा एक स्पेसिफिकेशन तैयार करने और फिर उसी स्पेसिफिकेशन का उपयोग करके नया कोड लिखने के माध्यम से एक आधार रेखा (baseline) स्थापित की। यह काफी हद तक सफल रहा; एक हजार से अधिक सोर्स फाइलों में से, सिस्टम ने 600 से अधिक को सफलतापूर्वक पुन: उत्पन्न किया, और उनमें से लगभग 400 नए स्क्रिप्ट्स लक्षित वातावरण में सही ढंग से चले। इसने सिद्ध किया कि मध्यवर्ती-चरण के स्पेसिफिकेशन का उपयोग करने की विधि व्यवहार्य थी। लेकिन असली परीक्षा तब हुई जब उन्होंने इसमें एक दूसरा, अलग मॉडल शामिल किया।
शोधकर्ताओं ने एक ऐसी स्थिति बनाई जहाँ एक मॉडल, जैसे कि Amazon Kiro, एक स्पेसिफिकेशन लिखेगा, और फिर एक पूरी तरह से अलग मॉडल, जैसे कि Google Gemini या GitHub Copilot, को कोड उत्पन्न करने के लिए वह दस्तावेज़ सौंपा जाएगा। वे देखना चाहते थे कि क्या दूसरा मॉडल गुणवत्ता खोए बिना पहले मॉडल की योजना को समझ सकता है। परिणाम चौंकाने वाले और आश्चर्यजनक थे। स्पेसिफिकेशन का आकार परिणाम के लिए अप्रासंगिक साबित हुआ। एक मॉडल ने लगभग 1,600 पंक्तियों वाला एक विशाल, विस्तृत दस्तावेज़ तैयार किया, जबकि दूसरे ने केवल लगभग 200 पंक्तियों वाला संक्षिप्त संस्करण बनाया। फिर भी, दस्तावेज़ की लंबाई इस बात का पूर्वानुमान नहीं लगा सकी कि कोड कितनी अच्छी तरह काम करेगा। वास्तव में, सबसे महत्वपूर्ण निष्कर्ष यह था कि स्पेसिफिकेशन का मूल स्रोत अत्यंत महत्वपूर्ण था। जब Google Gemini को Amazon Kiro द्वारा लिखा गया स्पेसिफिकेशन दिया गया, तो परिणामी कोड की गुणवत्ता ढह गई। नए स्क्रिप्ट्स चलने में विफल रहे, उनमें सिंटैक्स त्रुटियाँ थीं, और वे इच्छित लक्ष्य के बिल्कुल विपरीत थे। यह विफलता कोई एक बार की घटना नहीं थी; शोधकर्ताओं ने प्रयोग को दोहराया और उसी नाटकीय गिरावट को देखा, जिससे पुष्टि हुई कि दोनों मॉडल एक ही निर्देशों के सेट की व्याख्या करने के तरीके पर सहमत नहीं हो सके।
हालाँकि, यह असंगति सार्वभौमिक नहीं थी, जिसने इस खोज में सूक्ष्मता का एक स्तर जोड़ दिया। जहाँ Gemini, Kiro के स्पेसिफिकेशन के साथ गहराई से संघर्ष कर रहा था, वहीं GitHub Copilot ने उन्हीं विदेशी दस्तावेज़ों को बहुत बेहतर तरीके से संभाला, कभी-कभी तो अपने स्वयं के दस्तावेज़ों के साथ भी उतना ही अच्छा प्रदर्शन किया। इससे यह संकेत मिला कि समस्या यह नहीं थी कि विदेशी योजनाएँ स्वाभाविक रूप से खराब थीं, बल्कि यह थी कि विभिन्न मॉडलों के टेक्स्ट को पढ़ने और समझने के तरीके अलग-अलग होते हैं। इसे संबोधित करने के लिए, टीम ने मॉडलों के बीच इस अंतर को पाटने में मदद करने के कई तरीकों का परीक्षण किया। उन्होंने विदेशी स्पेफिकेशन्स को एक नए प्रारूप में फिर से लिखने की कोशिश की जिसे प्राप्तकर्ता मॉडल पसंद कर सके, और उन्होंने टेक्स्ट को छोटा करने के लिए उसे कंप्रेस (compress) करने का प्रयास किया। पुनर्गठन (Rewriting) ने Gemini की काफी मदद की, जिससे इसका प्रदर्शन वापस उपयोगी स्तर पर आ गया, लेकिन टेक्स्ट को कंप्रेस करने से कोई वास्तविक लाभ नहीं हुआ। सबसे आशाजनक रणनीति में 'रिट्रीवल-ऑगमेंटेड जनरेशन' (retrieval-augmented generation) नामक तकनीक शामिल थी। पूरे स्पेसिफिकेशन को एक साथ मॉडल को खिलाने के बजाय, शोधकर्ताओं ने मॉडल को एक टूल दिया जिससे वह दस्तावेज़ में खोज सके और केवल उन विशिष्ट भागों को निकाल सके जिनकी उसे वर्तमान कार्य के लिए आवश्यकता है। यह दृष्टिकोण हर पैमाने पर नहीं जीता, लेकिन यह एकमात्र ऐसा तरीका था जिसने संघर्ष करने वाले और सफल दोनों मॉडलों के लिए प्रदर्शन का लगातार मजबूत संतुलन प्रदान किया।
अध्ययन यह निष्कर्ष निकालता है कि एक ऐसी दुनिया में जहाँ सॉफ्टवेयर विभिन्न कृत्रिम बुद्धिमत्ता एजेंटों की एक टीम द्वारा बनाया जाता है, एक स्पेसिफिकेशन को एक तटस्थ, सार्वभौमिक दस्तावेज़ के रूप में नहीं माना जा सकता है। एक एजेंट द्वारा लिखी गई योजना स्वचालित रूप से दूसरे एजेंट के लिए वैध निर्देश सेट नहीं होती है। कोड की प्रभावशीलता काफी हद तक उस मॉडल के बीच के विशिष्ट संबंध पर निर्भर करती है जिसने योजना लिखी है और उस मॉडल के बीच जो सॉफ्टवेयर बना रहा है। यदि कोई टीम एक एजेंट को दूसरे से बदल देती है, तो वे केवल यह मानकर नहीं चल सकते कि मौजूदा ब्लूप्रिंट काम करेंगे; उन्हें या तो योजना की भाषा को अनुकूलित करने की आवश्यकता हो सकती है या नए एजेंट के सूचना तक पहुँचने के तरीके को बदलने की आवश्यकता हो सकती है। शोध यह सुझाव देता है कि मल्टी-एजेंट सॉफ्टवेयर इंजीनियरिंग के भविष्य में स्पेसिफिकेशन को कैसे संरचित और वितरित किया जाता है, इस पर एक नए फोकस की आवश्यकता होगी, ताकि यह सुनिश्चित किया जा सके कि एक योजना में निहित ज्ञान वास्तव में उस मशीन द्वारा समझा जा सके जिसे उसे बनाने का कार्य सौंपा गया है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।