An Iterative Test-and-Repair Framework for Competitive Code Generation
यह शोध पत्र FixAudit प्रस्तुत करता है, जो एक पुनरावृत्ति परीक्षण-और-मरम्मत (test-and-repair) ढांचा है जो कोड उम्मीदवारों को प्रगतिशील रूप से डीबग और सुधारने के लिए विशिष्ट फिक्सर (Fixer) और ऑडिटर (Auditor) भूमिकाओं वाले एक साझा मॉडल का उपयोग करता है, जो प्रतिस्पर्धी प्रोग्रामिंग बेंचमार्क पर मौजूदा विधियों और बड़े बेसलाइन की तुलना में काफी बेहतर प्रदर्शन करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक बहुत ही बुद्धिमान, लेकिन थोड़े अनाड़ी रोबोट को जटिल गणितीय पहेलियों को हल करना सिखाने की कोशिश कर रहे हैं। यह रोबोट एक लार्ज लैंग्वेज मॉडल (LLM) है। यह कोड लिखने में बेहतरीन है, लेकिन जब बात कॉम्पिटिटिव प्रोग्रामिंग (जहाँ आपको तर्क की पेचीदा समस्याओं को हल करने के लिए एकदम सटीक कोड लिखना होता है) की आती है, तो यह अक्सर सूक्ष्म गलतियाँ कर देता है।
यहाँ इस पेपर के लेखकों की कहानी है कि कैसे उन्होंने अपने रोबोट को एक मास्टर प्रॉब्लम-सॉल्वर बनाने के लिए प्रशिक्षित किया, जिसका तरीका बाकी सभी से बहुत अलग है, जिसे FixAudit कहा जाता है।
पुराना तरीका: "स्प्रे एंड प्राई" (छिड़कना और प्रार्थना करना) दृष्टिकोण
FixAudit से पहले, सबसे अच्छा तरीका (जिसे CURE कहा जाता था) एक लॉटरी मशीन की तरह काम करता था।
- रोबोट एक समाधान के 100 अलग-अलग संस्करण बनाता था (जैसे 100 लॉटरी टिकट खरीदना)।
- एक अलग "टेस्टर" रोबोट पहेली के निर्देशों के आधार पर 100 यादृच्छिक (रैंडम) टेस्ट प्रश्न बनाता था।
- वे सभी 100 समाधानों को सभी 100 प्रश्नों के विरुद्ध चलाते थे।
- जो सबसे अधिक टेस्ट पास करता, वही विजेता होता।
समस्या:
- अंधा टेस्टर: टेस्टर कोड को नहीं देखता था। यह एक ऐसे शिक्षक की तरह था जो छात्र के उत्तर पढ़े बिना ही परीक्षा का मूल्यांकन कर रहा हो, बस यह अंदाज़ा लगा रहा हो कि कौन से प्रश्न कठिन हो सकते हैं। वह कोड में छिपी हुई विशिष्ट, चालाकी भरी बग्स (गलतियों) को पकड़ने में विफल रहता था।
- "दोबारा प्रयास" की नीति: यदि कोई समाधान 99% सही था लेकिन उसमें एक छोटी सी त्रुटि थी, तो सिस्टम उसे फेंक देता था और एक नए रैंडम अनुमान के साथ शुरुआत से शुरू कर देता था। यह गलती को सुधारने के बजाय बस यह उम्मीद करता था कि अगला रैंडम अनुमान एकदम सही होगा।
नया तरीका: "FixAudit" दृष्टिकोण
लेखकों ने महसूस किया कि 100 बार अंदाज़ा लगाने के बजाय, आपको एक समाधान को तब तक ठीक करना चाहिए जब तक कि वह पूर्ण न हो जाए। उन्होंने FixAudit नामक एक फ्रेमवर्क बनाया, जो एक मास्टर डिटेक्टिव (जासूस) और एक शार्प एडिटर (संपादक) के रूप में मिलकर काम करता है।
उन्होंने एक AI मॉडल को दो भूमिकाएँ निभाने के लिए प्रशिक्षित किया:
1. द ऑडिटर (शार्प डिटेक्टिव - जासूस)
- यह क्या करता है: रैंडम प्रश्न पूछने के बजाय, ऑडिटर रोबोट द्वारा लिखे गए कोड को पढ़ता है।
- उपमा: कल्पना कीजिए कि एक जासूस संदिग्ध के बहाने (alibi) की जांच कर रहा है। जासूस केवल रैंडम सवाल नहीं पूछता; वह उस विशिष्ट झूठ को ढूंढता है। यदि कोड सड़क के बाईं ओर की जाँच करना भूल जाता है, तो ऑडिटर कहता है, "आहा! मुझे दिख गया कि आपने बाईं ओर नहीं देखा। चलिए मैं एक ऐसा टेस्ट केस बनाता हूँ जहाँ सभी लालटेन दाईं ओर हों ताकि यह साबित हो सके कि आप गलत हैं।"
- यह बेहतर क्यों है: यह उन सटीक छिपी हुई बग्स को ढूंढ निकालता है जिन्हें रोबोट मिस कर गया था।
2. द फिक्सर (शार्प एडिटर - संपादक)
- यह क्या करता है: जब ऑडिटर को एक बग मिलता है, तो फिक्सर कोड को फेंक नहीं देता। वह उस छेद को भर देता है (पैच लगा देता है)।
- उपमा: कल्पना कीजिए कि आप एक पांडुलिपि (manuscript) को एडिट कर रहे हैं। यदि आपको एक टाइपो (वर्तनी की गलती) मिलती है, तो आप पूरी किताब जलाकर पहले पन्ने से दोबारा नहीं लिखते। आप बस उस एक वाक्य को ठीक करते हैं। फिक्सर उस टूटे हुए हिस्से को देखता है, समझता है कि वह क्यों विफल हुआ, और केवल उसी हिस्से को ठीक करता है, जिससे रोबोट का पिछला सारा अच्छा काम सुरक्षित रहता है।
चार-चरणों वाला ट्रेनिंग कैंप
इस टीम को काम करने के योग्य बनाने के लिए, लेखकों ने AI को चार-चरणीय प्रशिक्षण शिविर से गुजारा:
- चरण A (ब्रेन जिम): उन्हें ठीक करने या टेस्ट करने से पहले, उन्होंने AI को यह समझने के लिए प्रशिक्षित किया कि कोड कैसे चलता है। उन्होंने इसे वास्तव में चलाने से पहले यह अनुमान लगाने के लिए प्रेरित किया कि एक प्रोग्राम क्या करेगा। इससे AI को "एक्जीक्यूशन रीजनिंग" मिली—यानी अपने दिमाग में तर्क को सोचने की क्षमता।
- चरण B (पहला रिपेयर): उन्होंने AI को एक टूटा हुआ प्रोग्राम और एक विफल टेस्ट दिया। फिक्सर ने सीखा कि उन हिस्सों को खराब किए बिना उसे कैसे सुधारा जाए जो पहले से ही काम कर रहे थे।
- चरण C (बग हंटर): अब जब प्रोग्राम "काफी हद तक ठीक" था, तो ऑडिटर ने कोड को पढ़ना और विशेष रूप से शेष छिपी हुई बग्स को तोड़ने के लिए नए, ट्रिकी टेस्ट बनाना सीखा।
- चरण D (फाइनल पॉलिश): फिक्सर ने ऑडिटर के नए, ट्रिकी टेस्ट लिए और कोड को परफेक्ट बनाने के लिए अंतिम, सूक्ष्म समायोजन किए।
परिणाम: यह क्यों मायने रखता है
इस पेपर ने तीन प्रसिद्ध कोडिंग प्रतियोगिताओं पर इसका परीक्षण किया। यहाँ जादू है:
- छोटा बनाम बड़ा: उन्होंने एक छोटे AI मॉडल (7 बिलियन पैरामीटर्स) का उपयोग किया। आमतौर पर, अच्छे परिणाम पाने के लिए आपको एक विशाल मॉडल (32 बिलियन पैरामीटर्स) की आवश्यकता होती है। FixAudit के छोटे मॉडल ने विशाल मॉडल के 'ज़ीरो-शॉट' प्रदर्शन को भी पीछे छोड़ दिया।
- दक्षता (Efficiency): पुराने "लॉटरी" तरीके को एक अच्छा समाधान खोजने के लिए दर्जनों समाधान उत्पन्न करने की आवश्यकता थी। FixAudit ने कम चरणों में सही उत्तर खोज लिया क्योंकि यह अनुमान लगाने के बजाय सीख रहा था और सुधार रहा था।
- "आहा!" क्षण: एक उदाहरण में, रोबोट यह देखना भूल गया कि संख्या शून्य हो सकती है या नहीं। ऑडिटर ने तर्क में इस विशिष्ट कमी को पकड़ा और एक ऐसा टेस्ट बनाया जिसने रोबोट को अपनी गलती का एहसास कराया। फिक्सर ने फिर एक छोटा सा बदलाव किया (
>को>=में बदलकर), और समस्या हल हो गई।
निष्कर्ष
FixAudit ने "इसे फेंक दो और फिर से शुरू करो" वाली मानसिकता को बदलकर खेल बदल दिया। इसके बजाय, यह कोडिंग को डिबगिंग की तरह मानता है:
- कोड को ध्यान से पढ़ें।
- विशिष्ट खामी को ढूंढें।
- केवल उस खामी को ठीक करें।
- इसे तब तक दोहराएं जब तक कि यह परफेक्ट न हो जाए।
यह 100 बार पासा फेंककर जीतने की कोशिश करने और नियमों को समझने, अपने प्रतिद्वंद्वी की कमजोरी को पहचानने और जीतने के लिए एक सटीक चाल चलने के बीच का अंतर है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।