← नवीनतम पेपर
💻 computer science

Foundation Models as Oracles for Refactoring Correctness Detection

यह अध्ययन प्रदर्शित करता है कि फाउंडेशन मॉडल जावा प्रोग्रामों में रिफैक्टरिंग बग्स का पता लगाने के लिए अनुकूल, ज़ीरो-शॉट ओरेकल के रूप में प्रभावी ढंग से कार्य कर सकते हैं, जो विविध IDEs और रिफैक्टरिंग प्रकारों में उच्च सटीकता प्राप्त करते हुए पारंपरिक स्टैटिक और डायनेमिक विश्लेषण उपकरणों के पूरक के रूप में व्याख्यात्मक अंतर्दृष्टि प्रदान करते हैं।

मूल लेखक: Rohit Gheyi, Rian Melo, Jonhnanthan Oliveira, Marcio Ribeiro, Baldoino Fonseca

प्रकाशित 2026-07-03
📖 5 मिनट में पढ़ें🧠 गहराई से पढ़ें

मूल लेखक: Rohit Gheyi, Rian Melo, Jonhnanthan Oliveira, Marcio Ribeiro, Baldoino Fonseca

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि आप एक कुशल बढ़ई हैं जिसने सुंदर और मजबूत मेजें बनाने में कई साल बिताए हैं। आपके पास स्वचालित मशीनों (जैसे IDEs) का एक सेट है जो आपको मेज के एक पैर को एक तरफ से दूसरी ओर ले जाने या दराज बदलने में मदद कर सकते हैं। इन मशीनों को यह काम पूरी तरह से करने के लिए बनाया गया है ताकि मेज के काम करने के तरीके में कोई बदलाव न आए।

हालांकि, कभी-कभी ये मशीनें गलती कर देती हैं। वे पैर को इस तरह से हिला सकती हैं जिससे मेज डगमगाने लगे, या वे कोई ऐसा हिस्सा काट सकती हैं जिससे पूरी मेज ही ढह जाए। सॉफ्टवेयर की दुनिया में, इन गलतियों को रिफैक्टरिंग बग्स (refactoring bugs) कहा जाता है। ये सूक्ष्म हो सकते हैं (मेज डगमगाती है) या स्पष्ट हो सकते हैं (मेज ढह जाती है और खड़ी भी नहीं रह पाती)।

लंबे समय तक, इन गलतियों को पकड़ने के लिए, डेवलपर्स को हर उस तरीके के लिए बहुत विशिष्ट, मैन्युअल नियम लिखने पड़ते थे जिससे मशीन गड़बड़ी कर सकती थी। यह एक नियम पुस्तिका लिखने जैसा था कि मेज टूटने के कितने भी तरीके हो सकते हैं। यह कठिन और धीमा था, और मशीनें नए तरीके खोज लेती रहती थीं जिनसे चीजें टूट जाती थीं और वे नियम पुस्तिका उन तरीकों को कवर नहीं कर पाती थी।

नया विचार: "सुपर-इंस्पेक्टर"

यह शोध पत्र एक सरल प्रश्न पूछता है: क्या एक "सुपर-इंस्पेक्टर" (एक फाउंडेशन मॉडल, जो एक उन्नत AI का प्रकार है) मेज को हिलाने से पहले और बाद की स्थिति को देखकर बता सकता है कि क्या वह टूट गई है?

शोधकर्ताओं ने AI को मेजों के बारे में विशिष्ट नियम नहीं सिखाए। इसके बजाय, उन्होंने बस उसे टूटी हुई मेजों के उदाहरण दिखाए और पूछा, "क्या यह टूटी हुई है?" इसे जीरो-शॉट प्रॉम्प्टिंग (zero-shot prompting) कहा जाता है—जैसे किसी बुद्धिमान व्यक्ति को एक टूटी हुई कुर्सी थमाना और बिना किसी मैनुअल के पूछना, "क्या यह बैठने के लिए सुरक्षित है?"

प्रयोग

शोधकर्ताओं ने टूटी हुई मेजों के 226 वास्तविक उदाहरण एकत्र किए (सॉफ्टवेयर बग्स) जो पिछले एक दशक में IntelliJ, Eclipse और NetBeans जैसे लोकप्रिय सॉफ्टवेयर टूल्स में हुए थे। ये बग दो श्रेणियों में आते थे:

  1. "ढहना" (कंपाइलेशन एरर - Compilation Errors): कोड इतना खराब हो गया है कि वह चल ही नहीं सकता।
  2. "डगमगाना" (व्यवहार संबंधी परिवर्तन - Behavioral Changes): कोड चलता तो है, लेकिन वह वह नहीं करता जो उसे करना चाहिए (जैसे गलत नंबर प्रिंट करना या बिना किसी कारण के क्रैश हो जाना)।

उन्होंने विभिन्न "सुपर-इंस्पेक्टर्स" (AI मॉडल्स) से इन 226 मामलों को देखने और यह कहने के लिए कहा कि, "क्या यह टूटा हुआ है?"

उन्हें क्या मिला

1. AI गलतियों को पकड़ने में आश्चर्यजनक रूप से अच्छा है।

  • सबसे अच्छे AI इंस्पेक्टरों (Gemini-3.1-Pro-Preview और GPT-5.4) ने लगभग हर बार सही पकड़ा (लगभग 94% से 99% सटीकता)।
  • यहाँ तक कि एक छोटा, मुफ्त उपयोग वाला AI (GPT-OSS-20B) भी काफी अच्छा काम कर रहा था (लगभग 80% सटीकता)।
  • AI ने केवल "हाँ/नहीं" नहीं कहा। यह समझा सकता था कि मेज क्यों डगमगा रही थी, जो मानव बढ़ई को समस्या समझने में मदद करता है।

2. कुछ गलतियाँ दूसरों की तुलना में कठिन होती हैं।

  • AI "डगमगाते" (व्यवहार संबंधी परिवर्तनों) को पकड़ने में बहुत अच्छा था।
  • यह "ढहने" (कंपाइलेशन एरर्स) को पकड़ने में थोड़ा कमजोर था, खासकर जब त्रुटि बहुत सूक्ष्म हो या इसमें मेज के हिस्सों के जुड़ने के जटिल नियम शामिल हों।
  • दिलचस्प बात यह है कि AI कभी-कभी इस बात से भ्रमित हो जाता था कि मेज को कैसे वर्णित किया गया है। यदि आपने संरचना को बदले बिना एक नकली पेंच जोड़ दिया या लकड़ी का रंग बदल दिया (मेटामॉर्फिक टेस्टिंग), तो भी AI ने खराबी को पकड़ लिया। इससे पता चलता है कि वह केवल तस्वीर को याद नहीं कर रहा है, बल्कि संरचना को देख रहा है।

3. "बड़ा प्रोजेक्ट" वाली समस्या।

  • जब शोधकर्ताओं ने बहुत बड़े, वास्तविक दुनिया के प्रोजेक्ट्स पर AI का उपयोग करने की कोशिश की जहाँ उन्होंने केवल एक "डिफ" (बदलावों की सूची, बिना पूरी तस्वीर के) दिखाया, तो AI अक्सर कहता था, "मुझे नहीं पता।"
  • ऐसा लगभग 40% मामलों में हुआ। AI को समझ आ गया कि पूरे वर्कशॉप (पूरे कोडबेस) को देखे बिना, यह सुनिश्चित नहीं किया जा सकता कि एक हिस्से को हिलाने से दूसरे कमरे में छिपी हुई किसी चीज़ पर क्या असर पड़ेगा।

निष्कर्ष

यह शोध पत्र निष्कर्ष निकालता है कि ये AI "सुपर-इंस्पेक्टर्स" पुराने, सख्त नियमपुस्तिकाओं (पारंपरिक टूल्स) के पूर्ण विकल्प नहीं हैं। पुराने टूल्स लेजर लेवल (laser level) की तरह हैं: वे तेज, सस्ते और उन चीजों के लिए 100% सटीक हैं जिन्हें वे माप सकते हैं।

हालाँकि, AI एक अनुभवी, बुद्धिमान बढ़ई की तरह है।

  • यह उन पेचीदा समस्याओं को पकड़ सकता है जिन्हें लेजर लेवल मिस कर देता है।
  • यह साधारण अंग्रेजी में समझा सकता है कि क्या गलत है।
  • यह बिना नया मैनुअल लिखे नई तरह की लकड़ी (नए प्रोग्रामिंग लैंग्वेज) को भी संभाल सकता है।

सबसे अच्छी रणनीति: पहले तेज़, सस्ता लेजर लेवल इस्तेमाल करें। यदि वह सब कुछ नहीं पकड़ पाता है, या यदि समस्या अजीब है, तो AI "सुपर-इंस्पेक्टर" से दूसरी बार देखने के लिए कहें। वे प्रतिद्वंद्वी के रूप में नहीं, बल्कि एक टीम के रूप में सबसे अच्छा काम करते हैं।

महत्वपूर्ण नोट: इस शोध पत्र का परीक्षण केवल Java कोड पर किया गया है। यह दावा नहीं करता कि यह सभी भाषाओं के लिए काम करता है या यह पूरी तरह से मानवीय निर्णय की जगह ले सकता है। AI एक सहायक है, न कि कोई जादुई छड़ी जो सब कुछ अपने आप ठीक कर देती है।

अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?

आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।

Digest आज़माएँ →