Verus-SpecGym: An Agentic Environment for Evaluating Specification Autoformalization
यह शोध पत्र Verus-SpecGym प्रस्तुत करता है, जो Rust सत्यापन के लिए अनौपचारिक प्रोग्रामिंग समस्याओं को निष्ठावान औपचारिक विनिर्देशों (formal specifications) में अनुवादित करने की LLMs की क्षमता का मूल्यांकन करने के लिए एक एजेंटिक वातावरण और बेंचमार्क है, जो यह प्रकट करता है कि जहाँ फ्रंटियर मॉडल आशाजनक दिखते हैं, वहीं उनके आउटपुट अभी भी नाजुक हैं और सूक्ष्म त्रुटियों के प्रति संवेदनशील हैं जिन्हें मानक LLM जज अक्सर अनदेखा कर देते हैं।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक शानदार लेकिन शाब्दिक अर्थ समझने वाले (literal-minded) रोबोट आर्किटेक्ट को एक घर बनाने के लिए काम पर रख रहे हैं। आप रोबोट को एक सरल, प्राकृतिक भाषा का निर्देश देते हैं: "एक आरामदायक दो-बेडरूम वाला घर बनाओ जिसमें लाल दरवाजा हो और सड़क की ओर मुख वाली एक बड़ी खिड़की हो।"
रोबोट निर्देशों का पालन करने में अद्भुत है। वह आपके विवरण से मेल खाता एक सटीक घर बना सकता है। लेकिन यहाँ एक पेंच है: आप यह कैसे जानेंगे कि रोबोट वास्तव में आपके कहने का अर्थ समझ गया था?
यदि रोबोट एक लाल दरवाजे वाला घर बनाता है लेकिन बिना खिड़कियों के, या एक नीला दरवाजा वाला घर बनाता है क्योंकि उसने "सोचा" कि आपका मतलब नीला था, तो वह विफल रहा है। कंप्यूटर विज्ञान की दुनिया में, यह कोड लिखने जो सही दिखता है और ऐसा कोड लिखने के बीच का अंतर है जो गणितीय रूप से गारंटीकृत रूप से सही है।
यह शोध पत्र, Verus-SpecGym, इस बारे में है कि AI एजेंटों को वह ब्लूप्रिंट (औपचारिक विनिर्देश/formal specification) लिखना सिखाना जो यह गारंटी देता है कि घर आपके इरादे के अनुरूप है, न कि केवल घर खुद।
मुख्य समस्या: "अनुवाद" का अंतर (The "Translation" Gap)
अतीत में, शोधकर्ताओं ने AI को कोड (घर) लिखने पर ध्यान केंद्रित किया। अब, AI इसमें अच्छा हो रहा है। नया अवरोध अनुवाद है।
- आपका इरादा: "एक लाल दरवाजे वाला घर बनाओ।" (अनौपचारिक, प्राकृतिक भाषा)
- ब्लूप्रिंट: एक सख्त गणितीय नियम जो कहता है
IF door_color == red THEN valid ELSE invalid। (औपचारिक, तार्किक भाषा)
यदि AI एक ऐसा ब्लूप्रिंट लिखता है जो कहता है "दरवाजा लाल OR नीला होना चाहिए," तो यह एक बुरा ब्लूप्रिंट है। यह बहुत ढीला है। यदि यह कहता है "दरवाजा लाल AND आकाश हरा होना चाहिए," तो यह बहुत सख्त है। AI को आपकी अस्पष्ट मानवीय इच्छा को एक पूर्ण, अटूट तार्किक नियम में अनुवादित करने की आवश्यकता है। इसे स्पेसिफिकेशन ऑटोफॉर्मलाइजेशन (Specification Autoformalization) कहा जाता है।
समाधान: Verus-SpecGym और Verus-SpecBench
लेखकों ने एक "जिम" (प्रशिक्षण और परीक्षण वातावरण) बनाया है ताकि यह देखा जा सके कि क्या AI एजेंट इस अनुवाद कार्य को कर सकते हैं।
- अरीना (Verid-SpecGym): यह एक डिजिटल खेल का मैदान है जहाँ एक AI एजेंट को एक प्रोग्रामिंग पहेली (जैसे कि Codeforces नामक प्रतियोगिता साइट से गणित की समस्या) दी जाती है। एजेंट को Verus नामक एक विशेष भाषा में "ब्लूप्रिंट" (औपचारिक विनिर्देश) लिखना होता है (जो Rust प्रोग्रामिंग भाषा का एक सुपर-स्ट्रिक्ट संस्करण जैसा है)।
- परीक्षण (Verus-SpecBench): उन्होंने 581 पहेलियों का एक विशाल टेस्ट बैंक बनाया। लेकिन उन्होंने केवल यह नहीं पूछा, "क्या AI ने ब्लूप्रिंट लिखा?" बल्कि उन्होंने पूछा, "क्या ब्लूप्रिंट वफादार (faithful) है?"
उन्होंने ब्लूप्रिंट्स का परीक्षण कैसे किया (द "एग्जीक्यूटेबल" ट्रिक)
आमतौर पर, यह जांचने के लिए कि ब्लूप्रिंट पूर्ण है या नहीं, एक मानव विशेषज्ञ को इसे पढ़ने और यह कहने की आवश्यकता होती है कि, "हाँ, यह विचार से मेल खाता है।" यह धीमा और महंगा है। या, वे दूसरे AI का उपयोग कर सकते हैं, लेकिन AI आलसी हो सकते हैं या सूक्ष्म गलतियों को छोड़ सकते हैं।
लेखकों ने एक चतुर ट्रिक खोजी: उन्होंने ब्लूप terlihat ब्लूप्रिंट्स को 'एग्जीक्यूटेबल' (executable) बना दिया।
इसे इस तरह सोचें:
- सामान्यतः, एक ब्लूपिंट कागज पर केवल एक ड्राइंग होती है। आप ड्राइंग को "रन" नहीं कर सकते।
- लेखकों ने Verus सिस्टम को इस तरह संशोधित किया कि ब्लूप्रिंट को एक मशीन में बदला जा सके।
- इसके बाद उन्होंने इस मशीन में हजारों टेस्ट केस डाले:
- वैध इनपुट (Valid Inputs): "यहाँ एक लाल दरवाजा है।" (मशीन को कहना चाहिए: पास!)
- अवैध इनपुट (Invalid Inputs): "यहाँ एक नीला दरवाजा है।" (मशीन को कहना चाहिए: फेल!)
- "हैक्स" (The "Hacks"): यही असली सीक्रेट सॉस है। प्रोग्रामिंग प्रतियोगिताओं में, इंसान "हैक्स" लिखते हैं—ट्रिकी, अजीब इनपुट जो अन्य लोगों के समाधानों को तोड़ने के लिए डिज़ाइन किए जाते हैं। लेखकों ने इन मानव-लिखित हैक्स का उपयोग "स्ट्रेस टेस्ट" के रूप में किया। यदि AI का ब्लूपिंट एक ऐसे "हैक" को स्वीकार कर लेता है जो नियमों को तोड़ता है, तो ब्लूपिंट दोषपूर्ण है।
परिणाम: स्मार्ट लेकिन नाजुक (Smart but Brittle)
उन्होंने छह सबसे स्मार्ट AI मॉडलों (दोनों क्लोज्ड-सोर्स दिग्गज और ओपन-सोर्स मॉडल) का इस जिम में परीक्षण किया।
- अच्छी खबर: सबसे अच्छे AI (Gemini 3.1 Pro) ने लगभग 78% ब्लूप्रिंट सही बनाए। यह मानवीय इरादे को सख्त नियमों में अनुवाद करने में बहुत अच्छा हो रहा है।
- बुरी खबर: भले ही AI उसी समस्या के लिए कोड को पूरी तरह से हल करने में सक्षम था, लेकिन वह अक्सर उसी समस्या के लिए ब्लूप्रिंट लिखने में विफल रहा।
- उपमा: AI एक आदर्श घर बना सकता है, लेकिन उसने एक ऐसा ब्लूप्रिंट लिखा जिसमें कहा गया "घर पनीर (cheese) से बना होना चाहिए।" घर खड़ा तो रहता है, लेकिन ब्लूप्रिंट गलत है।
- विफलता के प्रकार (Failure Modes): AI ने तीन विशिष्ट प्रकार की गलतियाँ कीं:
- मान्यताओं की कमी (Missing Assumptions): वह यह कहना भूल गया कि "दरवाजा लाल होना चाहिए," इसलिए उसने एक नीला दरवाजा स्वीकार कर लिया।
- बुरे आउटपुट को स्वीकार करना (Accepting Bad Outputs): उसने सोचा कि टूटी हुई खिड़की ठीक है।
- अच्छे आउटपुट को अस्वीकार करना (Rejecting Good Outputs): वह बहुत सख्त था और एक वैध लाल दरवाजे को खारिज कर दिया क्योंकि वह "बहुत चमकदार" था।
यह क्यों महत्वपूर्ण है (शोध पत्र के अनुसार)
शोध पत्र का तर्क है कि ब्लूप्रिंट की जांच करना घर बनाने से अधिक कठिन है।
उन्होंने यह भी पाया कि ब्लूप्रिंट को जज करने के लिए दूसरे AI (एक "LLM Judge") का उपयोग करना अविश्वसनीय है। LLM जज उन 26% त्रुटियों को मिस कर गया जिन्हें उनके "एग्जीक्यूटेबल मशीन" टेस्ट ने पकड़ा था। मशीन टेस्ट ही एकमात्र तरीका है जिससे यह सुनिश्चित किया जा सकता है कि ब्लूप्रिंट वास्तव में मानव के इरादे के प्रति वफादार है।
सारांश
यह शोध पत्र एक नए तरीके से AI का परीक्षण करता है: क्या यह आपकी अस्पष्ट इच्छा को एक पूर्ण, अटूट नियम में अनुवादित कर सकता है?
- उन्होंने वास्तविक प्रोग्रामिंग पहेलियों का उपयोग करके एक जिम (Verus-SpecGym) और एक टेस्ट बैंक (Verus-SpecBench) बनाया।
- उन्होंने नियमों को "रनेबल" (runnable) बनाया ताकि वे ट्रिकी मानव-लिखित "हैक्स" के खिलाफ उनका परीक्षण कर सकें।
- उन्होंने पाया कि हालांकि AI इस काम में अच्छा हो रहा है, लेकिन यह अभी भी नाजुक (brittle) है। यह अक्सर ऐसे नियम लिखता है जो थोड़े बहुत ढीले या बहुत सख्त होते हैं, भले ही वह समस्या को हल करना जानता हो।
- निष्कर्ष: हमें केवल AI द्वारा लिखे गए कोड पर भरोसा नहीं करना चाहिए; हमें उस नियम पर भरोसा करने की आवश्यकता है जो यह साबित करता है कि कोड सही है। और अभी, वह नियमों के साथ संघर्ष कर रहा है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।