BC-Bench: Evaluating Agentic Engineering in a Domain-Specific Language for ERP
यह शोध पत्र BC-Bench प्रस्तुत करता है, जो Microsoft Dynamics 365 Business Central के लिए AL डोमेन-विशिष्ट भाषा में 101 वास्तविक दुनिया के कार्यों से युक्त एक नवीन बेंचमार्क है, ताकि यह प्रदर्शित किया जा सके कि सामान्य बेंचमार्क पर एजेंटिक इंजीनियरिंग प्रदर्शन एंटरप्राइज ERP संदर्भों में विश्वसनीय रूप से अनुवादित नहीं होता है और यह डोमेन-विशिष्ट मूल्यांकन की महत्वपूर्ण आवश्यकता को रेखांकित करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
आधुनिक सॉफ्टवेयर की दुनिया में, एक नए प्रकार के कार्यकर्ता का उदय हुआ है: एक कृत्रिम बुद्धिमत्ता (AI) जो अपने आप कोड लिख सकती है, त्रुटियों को सुधार सकती है और प्रोग्राम बना सकती है। इन प्रणालियों को अक्सर कोडिंग एजेंट कहा जाता है, जिन्हें मानव-लिखित निर्देशों के विशाल पुस्तकालयों पर प्रशिक्षित किया गया है और उन्होंने पायथन जैसे सामान्य-उद्देश्य वाले प्रोग्रामिंग भाषाओं में उल्लेखनीय कौशल दिखाया है। वे उन पहेलियों को हल कर सकते हैं जिन्हें सुलझाने में कभी मानव इंजीनियरों को घंटों लग जाते थे। हालाँकि, व्यावसायिक सॉफ्टवेयर की वास्तविक दुनिया इतनी सरल नहीं होती है। वैश्विक वाणिज्य को चलाने वाले अधिकांश महत्वपूर्ण बुनियादी ढांचे विशिष्ट उद्योगों के लिए डिज़ाइन की गई विशेष भाषाओं पर निर्भर करते हैं, जहाँ नियम अलग होते हैं, उपकरण अद्वितीय होते हैं, और दांव बहुत ऊँचे होते हैं। ऐसा ही एक वातावरण एंटरप्राइज रिसोर्स प्लानिंग (ERP) की दुनिया है, जहाँ कंपनियाँ इन्वेंट्री से लेकर पेरोल तक सब कुछ प्रबंधित करती हैं। यहाँ, सॉफ्टवेयर एक भाषा बोलता है जिसे AL कहा जाता है, जो माइक्रोसॉफ्ट के बिजनेस सेंट्रल सिस्टम को चलाने के लिए उपयोग किया जाने वाला एक विशेष बोली (dialect) है। वर्षों से, यह स्पष्ट नहीं था कि क्या ये शक्तिशाली AI एजेंट इस जटिल, मालिकाना परिदृश्य में नेविगेट कर सकते हैं या क्या सामान्य कोडिंग में उनकी सफलता एक ऐसी घटना थी जो सामान्य कोडिंग के सामने आते ही फीकी पड़ जाती है।
इस प्रश्न का उत्तर देने के लिए, माइक्रोसॉफ्ट के शोधकर्ताओं ने BC-Bench नामक एक नया परीक्षण स्थल बनाया। उन्होंने कोई काल्पनिक पहेली का आविष्कार नहीं किया; इसके बजाय, उन्होंने दो विशाल सॉफ्टवेयर रिपॉजिटरी के वास्तविक, जीवित कोड की गहराई में खोज की जो वास्तविक व्यवसायों को शक्ति प्रदान करते हैं। इन डिजिटल अभिलेखागारों से, उन्होंने सावधानीपूर्वक 101 विशिष्ट कार्य चुने जो इंजीनियरों ने अतीत में हल किए थे। ये मनगढ़ंत उदाहरण नहीं थे बल्कि वास्तविक समस्याएँ थीं: एक बग जिसके कारण ग्राहक रिकॉर्ड विफल हो गया, एक बिक्री रिपोर्ट में एक गायब फीचर, या एक टेस्ट जिसे त्रुटि को पकड़ने के लिए लिखा जाना था। शोधकर्ताओं ने फिर दुनिया के सबसे उन्नत AI एजेंटों में से कई को इन समान कार्यों को करने के लिए कहा। एजेंटों को मूल समस्या का विवरण दिया गया, जिसमें कभी-कभी त्रुटि के स्क्रीनशॉट भी शामिल थे, और कोड का एक स्नैपशॉट दिया गया जैसा कि सुधार से पहले मौजूद था। उनका लक्ष्य ठीक वही कोड परिवर्तन लिखना था जो समस्या को हल करने के लिए आवश्यक थे, जैसा कि एक मानव इंजीनियर करता है। फिर सिस्टम ने सॉफ्टवेयर को एक सिम्युलेटेड वातावरण में चलाया यह देखने के लिए कि क्या नया कोड वास्तव में समस्या को हल करता है और बिना किसी अन्य चीज़ को तोड़े।
परिणामों ने एक ऐसा परिदृश्य प्रकट किया जहाँ AI मॉडल की पहचान उस विशिष्ट उपकरण से कहीं अधिक महत्वपूर्ण थी जिसका वह काम करने के लिए उपयोग करता है। जब शोधकर्ताओं ने विभिन्न एजेंटों के संस्करणों की तुलना की, तो उन्होंने पाया कि अंतर्निदम मस्तिष्क—लार्ज लैंग्वेज मॉडल—का चुनाव, उस सॉफ़्टवेयर रैपर या "हार्नेस" के चुनाव की तुलना में बहुत अधिक प्रभाव डालता था जो इसे निर्देशित करता है। उदाहरण के लिए, मॉडल के एक नवीनतम संस्करण, क्लाउड ओपस 4.6 ने एक मानक टूल के साथ जुड़कर लगभग 69 प्रतिशत बग-फिक्सिंग कार्यों को हल किया, जबकि उसी मॉडल के एक पुराने संस्करण ने केवल लगभग 58 प्रतिशत हल किया। इसके विपरीत, मॉडल को समान रखते हुए स्वयं टूल को बदलने से केवल मामूली, सांख्यिकीय रूप से महत्वहीन अंतर पैदा हुआ। यह सुझाव देता है कि इन जटिल व्यावसायिक कार्यों के लिए, मॉडल की बुद्धिमत्ता सफलता का प्राथमिक चालक है, न कि वह विशिष्ट इंटरफ़ेस जिसका वह कोड तक पहुँचने के लिए उपयोग करता है।
सबसे आश्चर्यजनक खोज यह थी कि सामान्य कोडिंग परीक्षणों में देखी गई प्रगति स्वचालित रूप से इस विशिष्ट दुनिया में अनुवादित नहीं होती है। सॉफ्टवेयर इंजीनियरिंग की व्यापक दुनिया में, नए मॉडल अक्सर अपने पूर्ववर्तियों की तुलना में निरंतर, अनुमानित लाभ दिखाते हैं। फिर भी, इस विशिष्ट व्यावसायिक वातावरण में, एक मॉडल जिसने हाल ही में सामान्य बेंचमार्क पर अपने पूर्ववर्ती को पीछे छोड़ दिया था, वह यहाँ वही लाभ दिखाने में विफल रहा। एक मॉडल जिसने सामान्य कार्यों पर महत्वपूर्ण सुधार किया था, वह इन व्यावसायिक तर्क पहेलियों का सामना करते समय अपने पुराने भाई से बेहतर प्रदर्शन करने में विफल रहा। यह इंगित करता है कि एक जेनेरिक पायथन स्क्रिप्ट को ठीक करने के लिए आवश्यक कौशल और एक विशेष व्यावसायिक प्रणाली में वित्तीय गणना को ठीक करने के लिए आवश्यक कौशल एक समान नहीं हैं। भाषा की विशिष्ट प्रकृति, जिसमें डेटा कैसे प्रवाहित होता है और व्यावसायिक तर्क को कैसे मान्य किया जाता है, इसके सख्त नियम हैं, जो एक ऐसा अवरोध पैदा करते है जिसे केवल सामान्य प्रशिक्षण आसानी से पार नहीं कर सकता।
शोधकर्ताओं ने यह भी बारीकी से देखा कि एजेंटों ने कब और क्यों विफलता दर्ज की। उन्होंने पाया कि मशीनें शायद ही कभी इसलिए विफल हुईं क्योंकि वे सॉफ्टवेयर नहीं बना सके या क्योंकि कोड संकलित (compile) नहीं हुआ; वे तकनीकी बाधाएं आसानी से पार कर ली गईं। इसके बजाय, विफलताएं लगभग हमेशा समस्या को समझने के बारे में थीं। विफल प्रयासों के लगभग आधे मामलों में, एजेंट ने पूरी तरह से कोड के गलत हिस्से को देखा, उन फाइलों को संपादित किया जिनका त्रुटि से कोई लेना-देना नहीं था। विफलताओं के एक अन्य बड़े समूह में, एजेंट ने सही फ़ाइल और कोड का सही अनुभाग ढूँढ लिया लेकिन फिर भी गलत तर्क लागू किया, एक ऐसा समाधान लागू किया जो दिखने में सही था लेकिन वास्तव में व्यावसायिक नियम को ठीक नहीं करता था। उदाहरण के लिए, एक एजेंट सही ढंग से पहचान सकता है कि ग्राहक का ऑर्डर नंबर गायब है लेकिन फिर ऐसा कोड लिख सकता है जो गलत प्रकार का नंबर असाइन करता है, जिससे सिस्टम टूटा हुआ रह जाता है। ये त्रुटियां बताती हैं कि एजेंट उन गहरे, परस्पर जुड़े व्यावसायिक नियमों के जाल को नेविगेट करने में संघर्ष करते हैं जो परिभाषित करते हैं कि एक कंपनी कैसे संचालित होती है, और अक्सर उस सूक्ष्म संदर्भ को मिस कर देते हैं जिसे एक मानव इंजीनियर तुरंत समझ लेगा।
कार्य की जटिलता ने भी निर्णायक भूमिका निभाई। जब सुधार के लिए केवल एक फ़ाइल या कुछ लाइनों को बदलने की आवश्यकता थी, तो एजेंट काफी सफल रहे। हालाँकि, जैसे ही समाधान के लिए कई फ़ाइलों को संशोधित करने या कोड की कुछ दर्जन से अधिक लाइनें लिखने की आवश्यकता हुई, सफलता दर तेजी से गिर गई। यह गिरावट नाटकीय थी, जब कार्य में एक से अधिक फ़ाइल शामिल थी तो सटीकता बीस प्रतिशत से अधिक गिर गई। ऐसा प्रतीत होता है कि हालांकि ये एजेंट छोटे, अलग-थलग मरम्मतों को संभाल सकते हैं, वे एक बड़े, परस्पर जुड़े सिस्टम में परिवर्तनों को समन्वय करने के लिए अभी भी संघर्ष करते हैं। इसके अलावा, व्यवसाय के क्षेत्र का प्रकार भी मायने रखता था; एजेंट इन्वेंट्री प्रबंधन की तुलना में वेयरहाउस लॉजिस्टिक्स में समस्याओं को ठीक करने में अधिक सफल थे, जो बताता है कि उनके प्रशिक्षण डेटा में कुछ व्यावसायिक डोमेन में कुछ अधिक समृद्ध हो सकता है।
अध्ययन यह निष्कर्ष निकालता है कि जबकि कृत्रिम बुद्धिमत्ता ने सामान्य कोडिंग में अविश्वसनीय प्रगति की है, विशेष व्यावसायिक वातावरण में पूर्ण स्वायत्त इंजीनियरिंग का मार्ग अभी भी स्पष्ट नहीं है। उपकरण मौजूद हैं, और मॉडल शक्तिशाली हैं, लेकिन सामान्य क्षमता और डोमेन-विशिष्ट महारत के बीच का अंतर अभी भी व्यापक बना हुआ है। शोधकर्ता इस बात पर जोर देते हैं कि आगे बढ़ने के लिए, उद्योग को सामान्य परीक्षणों पर भरोसा करने के बजाय इन विशिष्ट बेंचमार्क पर ध्यान केंद्रित करने की आवश्यकता है। वे यह भी बताते हैं कि वर्तमान सीमाएं केवल कच्ची बुद्धिमत्ता के बारे में नहीं हैं बल्कि संदर्भ को समझने, जटिल कोडबेस को नेविगेट करने और सही व्यावसायिक तर्क लागू करने की क्षमता के बारे में भी हैं। जैसे-जैसे ये सिस्टम विकसित होते हैं, उम्मीद है कि वे अंततः व्यावसायिक सॉफ्टवेयर के जटिल नियमों को उसी सहजता के साथ नेविगेट करना सीख जाएंगे जैसा कि वे अब सामान्य प्रोग्रामिंग में दिखाते हैं, लेकिन फिलहाल, वास्तविक दुनिया की जटिलताओं के माध्यम से उनका मार्गदर्शन करने के लिए मानव इंजीनियर आवश्यक है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।