💻 computer science

IssueExec: A Test-Driven Approach for Localizing Software Engineering Issues

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

मूल लेखक: Jiawei Liu, Yun Lin, Chenyan Liu, Yu Qian, Yiming Liu, Jiaxin Chang, Weinan Zhang, Linpeng Huang

प्रकाशित 2026-07-21

📖 8 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Jiawei Liu, Yun Lin, Chenyan Liu, Yu Qian, Yiming Liu, Jiaxin Chang, Weinan Zhang, Linpeng Huang

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

कल्पना कीजिए कि आप एक विशाल, अराजक पुस्तकालय में एक रहस्य सुलझाने की कोशिश कर रहे हैं एक जासूस के रूप में। यह पुस्तकालय एक बड़े कंप्यूटर सॉफ़्टवेयर का प्रतिनिधित्व करता है, और वह रहस्य एक "बग" (bug) है—एक ऐसी गलती जो सॉफ़्टवेयर को अजीब तरह से काम करने पर मजबूर करती है। आमतौर पर, जब कोई बग की रिपोर्ट करता है, तो वे साधारण अंग्रेजी में एक नोट लिखते हैं, जैसे "जब मैं यहाँ क्लिक करता हूँ तो मैप लोड नहीं होता।" आपका काम पुस्तकालय के उस सटीक पन्ने को ढूँढना है जहाँ वह गलती छिपी है ताकि आप उसे ठीक कर सकें। इसे "इश्यू लोकलाइजेशन" (issue localization) कहा जाता है।

लंबे समय तक, जासूसों ने इस समस्या को साधारण अंग्रेजी के नोट को पढ़कर और यह अनुमान लगाकर हल करने की कोशिश की कि वह नोट पुस्तकालय के किस पन्ने से मेल खाता है। लेकिन यह किसी शब्द को देखकर किताब खोजने जैसा है, जैसे कि अगर आपने "मैप" शब्द खोजा, लेकिन पुस्तकालय में किताबें "जियोग्राफी", "कार्टोग्राफी" और "नेविगेशन" के आधार पर व्यवस्थित हैं, और नोट में सिर्फ "मैप" लिखा है। शब्द मेल नहीं खाते, और पुस्तकालय इतना बड़ा है कि हर शेल्फ को खोजना संभव नहीं है। यह शोध पत्र सुझाव देता है कि इस समस्या को हल करने का एक शानदार नया तरीका है: पुस्तकालय के अपने "अभ्यास परीक्षणों" (practice tests) का उपयोग करना। ये उन रिहर्सल स्क्रिप्ट की तरह हैं जिन्हें लाइब्रेरियन यह सुनिश्चित करने के लिए चलाते हैं कि किताबें सही क्रम में हैं। लेखक सुझाव देते हैं कि ये स्क्रिप्ट एक गुप्त पुल (bridge) के रूप में कार्य करती हैं, जो मानव की उलझी हुई भाषा को पुस्तकालय के पन्नों की सटीक भाषा में अनुवादित करती है, जिससे बग की खोज बहुत तेज़ और अधिक सटीक हो जाती है।

समस्या: "शब्दावली का अंतर" (The Vocabulary Gap)

इस शोध पत्र के लेखक, जो चीन और सिंगापुर के शोधकर्ताओं की एक टीम है, ने कंप्यूटर द्वारा सॉफ़्टवेयर बग को ठीक करने के तरीके में एक निराशाजनक पैटर्न देखा। जब एक इंसान कहता है, "सर्वरलेस फीचर काम नहीं कर रहा है," तो कंप्यूटर अक्सर "serverless" नाम के कोड को खोजता है। लेकिन वास्तविक दुनिया में, कोड का नाम कुछ तकनीकी हो सकता है जैसे _get_db_cluster_kwargs (जो डेटाबेस क्लस्टर के लिए सेटिंग्स प्राप्त करने का एक फैंसी तरीका है)।

यह बिल्कुल वैसा ही है जैसे यदि आपने एक लाइब्रेरियन से "अंतरिक्ष के बारे में एक किताब" मांगी, और उन्होंने केवल उन किताबों को खोजा जिनके शीर्षक में "space" शब्द था, जिससे वे "एस्ट्रोनॉमी" या "कॉस्मोलॉजी" वाली किताबों को भी मिस कर गए। इंसानों द्वारा कही गई बातों (आवश्यकताओं) और प्रोग्रामर द्वारा दी गई चीज़ों के नामकरण के बीच यह बेमेल होना एक बड़ा "सिमेंटिक गैप" (semantic gap) पैदा करता है। मौजूदा उपकरण इस अंतर को सीधे पार करने की कोशिश करते हैं, लेकिन वे अक्सर लड़खड़ा जाते हैं, जिससे लंबी और महंगी खोज होती है जहाँ कंप्यूटर गलत अनुमान लगा लेता है।

नया विचार: परीक्षण "एग्जीक्यूटेबल रिक्वायरमेंट्स" के रूप में

यह शोध पत्र एक चतुर मोड़ प्रस्तावित करता है। बग रिपोर्ट से सीधे कोड पर कूदने के बजाय, लेखक सुझाव देते हैं कि परीक्षणों (tests) के माध्यम से जाना चाहिए।

एक सॉफ़्टवेयर टेस्ट को एक "अभ्यास रन" या "रिहर्सल" के रूप में सोचें। एक प्रोग्रामर यह जांचने के लिए एक टेस्ट लिखता है कि क्या कोई फीचर काम कर रहा है। महत्वपूर्ण बात यह है कि टेस्ट का नाम अक्सर बग रिपोर्ट जैसा ही सुनाई देता है। यदि बग "Serverless" के बारे में है, तो टेस्ट का नाम test_create_serverless_db_cluster हो सकता है।

लेखकों का तर्क है कि टेस्ट एक आदर्श मध्यस्थ हैं क्योंकि वे एग्जीक्यूटेबल रिक्वायरमेंट्स (executable requirements) हैं। वे मानव-पठनीय भाषा (जैसे बग रिपोर्ट) में लिखे जाते हैं लेकिन वे वास्तविक कोड से मजबूती से जुड़े होते हैं (क्योंकि उन्हें चलने और पास होने की आवश्यकता होती है)। पहले सही टेस्ट को ढूँढकर, आप एक "दो-कदम" (two-hop) वाला रास्ता बनाते हैं:

बग रिपोर्ट $\rightarrow$ टेस्ट (आसान मिलान: दोनों "serverless" जैसे शब्दों का उपयोग करते हैं)।
टेस्ट $\rightarrow$ कोड (गारंटीड मिलान: टेस्ट वास्तव में उस कोड को चलाता है)।

सिद्धांत: "भ्रम" को कम करना

अपना टूल बनाने से पहले, लेखकों ने गणित का उपयोग करके यह देखा कि क्या यह विचार वास्तव में काम करता है। उन्होंने "एन्ट्रॉपी" (entropy) नामक एक अवधारणा का उपयोग किया, जो भ्रम या अनिश्चितता को मापने का एक तरीका है। कल्पना कीजिए कि आप घास के ढेर में सुई ढूँढ रहे हैं।

प्रत्यक्ष खोज (Direct Search): यदि आप केवल बग रिपोर्ट के आधार पर अनुमान लगाते हैं, तो आपको 10,000 सुइयों को देखना पड़ सकता है। यह उच्च भ्रम (high confusion) है।
टेस्ट-मध्यस्थ खोज (Test-Mediated Search): यदि आप पहले सही "बॉक्स" (टेस्ट) को ढूँढ लेते हैं जिसमें सुई है, तो आपको केवल 100 सुइयों को देखना पड़ सकता है।

उनकी गणनाओं ने दिखाया कि टेस्ट को मध्यस्थ के रूप में उपयोग करने से "भ्रम" औसतन 7.73 बिट्स कम हो जाता है। सरल भाषा में, इसका अर्थ है कि खोज का दायरा काफी छोटा और केंद्रित हो जाता है, जिससे सही स्थान ढूँढना बहुत आसान हो जाता है।

समाधान: IssueExec

इस सिद्धांत को व्यवहार में लाने के लिए, टीम ने IssueExec नामक एक टूल बनाया। यह तीन मुख्य चरणों में काम करता है:

स्मार्ट टेस्ट रिट्रीवल (Smart Test Retrieval): टूल बग रिपोर्ट को देखता है और मिलान करने वाले टेस्ट को खोजने की कोशिश करता है। लेकिन यह जानता है कि प्रोग्रामर संक्षिप्त रूपों (abbreviations) और अंदरूनी चुटकुलों का उपयोग करते हैं। इसलिए, यह प्रोजेक्ट के इतिहास (जैसे पुराने कमिट संदेशों) की गहराई में जाता है ताकि यह सीख सके कि "tz" का अर्थ "timezone" है या "ovr" का अर्थ "OneVsRestClassifier" है। यह इसे मानक कंप्यूटर खोज की तुलना में टेस्ट के नामों को बेहतर ढंग से समझने में मदद करता है।
ट्रेस विश्लेषण (Trace Analysis): एक बार जब यह सही टेस्ट ढूँढ लेता है, तो यह वहीं नहीं रुकता। यह टेस्ट को चलाता है और देखता है कि टेस्ट वास्तव में कोड की किन लाइनों को छूता है। यह एक "ट्रेस" (trace) बनाता है, जैसे कि ब्रेडक्रंब ट्रेल (रोटी के टुकड़ों का रास्ता)। हालाँकि, टेस्ट अक्सर बहुत अधिक कोड को छूते हैं, जिसमें बोरिंग इंफ्रास्ट्रक्चर वाली चीजें भी शामिल होती हैं जिनका बग से कोई लेना-देना नहीं होता।
नॉइज़ फ़िल्टरिंग (Noise Filtering): टूल एक स्मार्ट AI का उपयोग करता है जो ब्रेडक्रंब ट्रेल को देखता है और शोर (noise) को फ़िल्टर करता है। यह पूछता है, "इनमें से कौन सी छूई गई लाइनें वास्तव में समस्या का कारण बनीं?" यह उबाऊ हिस्सों को अनदेखा करता है और उन विशिष्ट फंक्शन्स को हाइलाइट करता है जो संभावित रूप से दोषी हैं।

परिणाम: एक बड़ी जीत

टीम ने SWE-bench Lite नामक एक प्रसिद्ध बेंचमार्क पर IssueExec का परीक्षण किया, जिसमें 300 वास्तविक दुनिया के सॉफ़्टवेयर बग शामिल हैं। परिणाम प्रभावशाली थे:

बेहतर सटीकता: IssueExec ने पिछले सबसे अच्छे तरीके की तुलना में 41.57% अधिक बार सही कोड स्थान (फंक्शन स्तर पर) ढूँढा।
अधिक सुधार: जब उन्होंने IssueExec को एक स्वचालित सुधार प्रणाली (जिसे Agentless कहा जाता है) में प्लग किया, तो उस प्रणाली ने पहले की तुलना में 17.72% अधिक बग हल किए।
लागत दक्षता: भले ही यह अतिरिक्त काम (टेस्ट चलाना और ट्रेस का विश्लेषण करना) करता है, फिर भी इसने अन्य जटिल तरीकों की तुलना में पैसा बचाया, जिसका औसत खर्च प्रति बग लगभग 35% कम था।

इसकी सीमाएँ (क्या यह नहीं कर सकता)

लेखक इस बात के प्रति ईमानदार हैं कि उनका टूल कहाँ विफल हो सकता है।

मिसिंग टेस्ट्स (Missing Tests): यदि सॉफ़्टवेयर प्रोजेक्ट में उस विशिष्ट बग वाले कोड को कवर करने वाला कोई टेस्ट नहीं है, तो IssueExec उसे नहीं ढूँढ पाएगा। उनके अध्ययन से पता चला कि मौजूदा टेस्ट उन फाइलों का लगभग 96.98% कवर करते हैं जिन्हें ठीक करने की आवश्यकता है, लेकिन फिर भी एक छोटा सा अंतर (लगभग 33.30% विशिष्ट फंक्शन) रह जाता है जहाँ टूल अटक सकता है।
गहरी भूलभुलैया (Deep Mazes): कभी-कभी, कोड का रास्ता इतना लंबा और घुमावदार होता है (जैसे कि एक गहरा भूमिगत सुरंग तंत्र) कि टूल बीच की परतों में खो जाता है और अंतिम गंतव्य तक नहीं पहुँच पाता।

यह क्यों मायने रखता है

यह शोध पत्र सुझाव देता है कि हमें कंप्यूटर को मानव भाषा का बेहतर अनुमान लगाने के लिए सिखाने की आवश्यकता नहीं है। इसके बजाय, हमें उन्हें उन उपकरणों का उपयोग करना सिखाना चाहिए जो डेवलपर्स के पास पहले से मौजूद हैं: यानी टेस्ट। टेस्ट को मानव शिकायतों और कंप्यूटर कोड के बीच एक पुल के रूप में उपयोग करके, IssueExec एक अराजक खोज को एक निर्देशित टूर (guided tour) में बदल देता है। यह सुझाव देता है कि सॉफ़्टवेयर बग को ठीक करने का भविष्य अंधेरे में अनुमान लगाने वाले बड़े AI मॉडल के बारे में नहीं है, बल्कि उपलब्ध साक्ष्यों का उपयोग करके स्मार्ट, चरण-दर-चरण तर्क (reasoning) के बारे में है।

तकनीकी सारांश: IssueExec – सॉफ्टवेयर इंजीनियरिंग समस्याओं के स्थानीयकरण के लिए एक टेस्ट-ड्रिवन दृष्टिकोण

1. समस्या विवरण (Problem Statement)

स्वचालित सॉफ्टवेयर रखरखाव (automated software maintenance) काफी हद तक इश्यू लोकलाइजेशन (issue localization) पर निर्भर करता है, जो कि उन विशिष्ट कोड स्थानों (फ़ाइलों, मॉड्यूल या फ़ंक्शंस) की पहचान करने का कार्य है जिन्हें रिपोर्ट की गई समस्या को हल करने के लिए संशोधन की आवश्यकता होती है। मौजूदा दृष्टिकोण मुख्य रूप से एक प्रत्यक्ष इश्यू-कोड संरेखण प्रतिमान (direct issue–code alignment paradigm) का पालन करते हैं, जो प्राकृतिक भाषा में दिए गए इश्यू विवरणों को सीधे कोड तत्वों (जैसे, रिट्रीवल या LLM एजेंट्स के माध्यम से) से मिलाने का प्रयास करते हैं।

हालाँकि, ये विधियाँ अक्सर एक एब्स्ट्रैक्शन गैप (abstraction gap) के कारण संघर्ष करती हैं: इश्यू विवरण व्यवहार संबंधी अपेक्षाओं (आवश्यकताओं) को व्यक्त करते हैं, जबकि कोड आइडेंटिफायर तकनीकी कार्यान्वयन विवरणों को दर्शाते हैं। जैसा कि पेपर में स्पष्ट किया गया है, "ServerlessV2 support" का अनुरोध करने वाला एक इश्यू _get_db_cluster_kwargs (पैरामीटर एक्सट्रैक्शन) नामक फ़ंक्शन के साथ अर्थपूर्ण रूप से मेल नहीं खा सकता है, जिससे कमजोर सिमेंटिक एलाइनमेंट और लोकलाइजेशन विफलता होती है। हालांकि आवश्यकता दस्तावेज़ (requirement documentation) सैद्धांतिक रूप से इस अंतर को पाट सकते हैं, लेकिन वे अक्सर कार्यान्वयन से भटक जाते हैं। लेखक तर्क देते हैं कि टेस्ट सूट्स (test suites), जिन्हें पास होने के लिए कार्यान्वयन के साथ सिंक्रोनाइज़ रहना चाहिए, एक बेहतर मध्यवर्ती संकेत (intermediate signal) के रूप में कार्य करते हैं।

2. कार्यप्रणाली: IssueExec फ्रेमवर्क (Methodology: The IssueExec Framework)

लेखक IssueExec का प्रस्ताव करते हैं, जो एक टेस्ट-मध्यस्थ लोकलाइजेशन फ्रेमवर्क है जो टेस्ट सूट्स को "एग्जीक्यूटेबल रिक्वायरमेंट्स" (executable requirements) के रूप में मानता है। यह फ्रेमवर्क एक दो-हॉप (two-hop) पथ पर कार्य करता है: इश्यू $\rightarrow$ टेस्ट्स $\rightarrow$ कोड। यह तीन मुख्य चरणों में विभाजित है:

A. सैद्धांतिक और अनुभवजन्य प्रेरणा (Theoretical and Empirical Motivation)

इस दृष्टिकोण की व्यवहार्यता स्थापित करने के लिए, लेखक निम्नलिखित प्रस्तुत करते हैं:

सैद्धांतिक विश्लेषण: हार्टले एंट्रॉपी (Hartley entropy) का उपयोग करके, लेखक लोकलाइजेशन अनिश्चितता को मॉडल करते हैं। वे प्रदर्शित करते हैं कि दो-हॉप पथ (Issue $\rightarrow$ Tests $\rightarrow$ Trace-constrained Code) प्रत्यक्ष रिट्रीवल की तुलना में औसतन 7.73 बिट्स की अनिश्चितता को कम करता है, जो मुख्य रूप से सर्च स्पेस को कंप्रेस करके किया जाता है।
अनुभवजन्य अध्ययन: 18 पायथन रिपॉजिटरीज़ (929 इश्यूज़) पर एक अध्ययन से पता चलता है कि:
- मौजूदा टेस्ट्स ग्राउंड-ट्रुथ फ़ाइलों के 96.98% और ग्राउंड-ट्रुथ फ़ंक्शंस के 66.70% को कवर करते हैं।
- दो-हॉप पथ, डायरेक्ट मैचिंग की तुलना में 82.4% मामलों में मजबूत सिमेंटिक कनेक्टिविटी प्रदान करता है।

B. IssueExec के मुख्य घटक (Core Components of IssueExec)

सिमेंटिक गैप और एक्जीक्यूशन नॉइज़ की चुनौतियों को दूर करने के लिए, IssueExec निम्नलिखित पाइपलाइन को लागू करता है:

डोमेन नॉलेज एन्हांसमेंट (ऑफलाइन प्रीप्रोसेसिंग):
- चुनौती: जेनेरिक एम्बेडिंग्स डोमेन-विशिष्ट शब्दावली (जैसे, टाइमज़ोन के लिए "tz") या प्रोजेक्ट-विशिष्ट एलियास को कैप्चर करने में विफल रहते हैं।
- समाधान: सिस्टम प्रत्येक टेस्ट के लिए डोमेन नॉलेज ( $D_t$ $D_{t}$ ) निकालने के लिए ऐतिहासिक कमिट हिस्ट्री को माइन करता है। इसमें शामिल हैं:
  - टेस्ट को पेश करने वाले कमिट मैसेज (जो रिक्वायरमेंट-लेवल कॉन्टेक्स्ट प्रदान करते हैं)।
  - सह-परिवर्तित संस्थाएं (को-चेंज्ड एंटिटीज) (वे कोड जो टेस्ट के साथ अक्सर संशोधित होते हैं)।
- परिणाम: एक समृद्ध टेस्ट रिप्रेजेंटेशन $repr(t) = [sig(t); doc(t); D_t]$ , जो इश्यू और टेस्ट के बीच शब्दावली के अंतर को पाटता है।
प्रासंगिक टेस्ट रिट्रीवल (दो-चरणीय फ़िल्टरिंग):
- लेक्सिकल फ़िल्टरिंग: हजारों टेस्ट्स में से सर्च स्पेस को एक प्रबंधनीय कैंडिडेट सेट ( $N$ ) तक कम करने के लिए BM25 का उपयोग करता है।
- सिमेंटिक सिलेक्शन: एक LLM समृद्ध रिप्रेजेंटेशन का विश्लेषण करता है ताकि इश्यू के इरादे से सबसे अधिक प्रासंगिक टेस्ट्स का एक छोटा, उच्च-गुणवत्ता वाला सबसेट ( $k \ll N$ ) चुना जा सके।
ट्रेस-गाइडेड लोकलाइजेशन:
- चुनौती: एक एकल टेस्ट हजारों फ़ंक्शंस को निष्पादित कर सकता है, जिसमें अप्रासंगिक इंफ्रास्ट्रक्चर कोड भी शामिल हो सकता है, जो शोर (noise) पैदा करता है।
- समाधान: सिस्टम चयनित टेस्ट्स को एक कंटेनरीकृत वातावरण में निष्पादित करता है ताकि डायनेमिक एक्जीक्यूशन ट्रेसेस एकत्र किए जा सकें। यह कॉलर-कॉलर (caller-callee) संबंधों का प्रतिनिधित्व करने वाला एक डायरेक्टेड ट्रेस ग्राफ ( $G_t$ ) बनाता है।
- डिनोइजिंग (Denoising): एक LLM इश्यू विवरण के साथ मिलकर ट्रेस ग्राफ का विश्लेषण करता है ताकि "संदिग्ध स्थानों" (suspicious locations) की पहचान की जा सके। यह आकस्मिक इंफ्रास्ट्रक्चर को फ़िल्टर करता है और रिक्वायरमेंट-सेंट्रल कोड को हाइलाइट करता है, तथा कॉन्फिडेंस लेवल (क्रिटिकल, हाई, मीडियम) असाइन करता है।
रिफाइनमेंट और रीरैंकिंग:
- संदिग्ध सेट का विस्तार उन फ़ाइलों के स्ट्रक्चरल कॉन्टेक्स्ट (मॉड्यूल स्केलेटन) को रिट्रीव करके किया जाता है जिनमें संदिग्ध स्थान मौजूद हैं।
- एक अंतिम LLM-गाइडेड रीरैंकिंग स्टेप पूर्ण सोर्स कोड का उपयोग करके उम्मीदवारों को प्राथमिकता देता है, रूट कॉज, कॉज़ल रिलेशनशिप और आर्किटेक्चरल उपयुक्तता के बारे में तर्क देता है, ताकि एडिट लोकेशन्स की अंतिम रैंक की गई सूची ( $L^*$ ) तैयार की जा सके।

3. प्रमुख योगदान (Key Contributions)

एग्जीक्यूटेबल रिक्वायरमेंट्स का औपचारिककरण: पेपर 'एग्जीक्यूटेबल प्रॉक्सी फॉर रिक्वायरमेंट्स' के रूप में टेस्ट सूट्स का उपयोग करने की अवधारणा को औपचारिक रूप देता है, यह प्रदर्शित करते हुए कि कैसे टेस्ट-लेवल पर सिमेंटिक एलाइनमेंट और रनटाइम पर एक्जीक्यूशन ग्राउंडिंग संयुक्त रूप से इश्यू-कोड गैप को पाटते हैं।
IssueExec फ्रेमवर्क: एक प्रक्रिया-आधारित फ्रेमवर्क जो डोमेन-नॉलेज-एन्हांस्ड टेस्ट रिप्रेजेंटेशन (कमिट माइनिंग के माध्यम से) और पदानुक्रमित ट्रेस विश्लेषण (डायनेमिक एक्जीक्यूशन ग्राफ के माध्यम से) को एकीकृत करता है।
स्टेट-ऑफ-द-आर्ट प्रदर्शन: लोकलाइजेशन सटीकता और डाउनस्ट्रीम इश्यू रेजोल्यूशन दोनों में मौजूदा बेसलाइन्स की तुलना में महत्वपूर्ण सुधार दिखाने वाला अनुभवजन्य सत्यापन।

4. प्रयोगात्मक परिणाम (Experimental Results)

फ्रेमवर्क का मूल्यांकन SWE-bench Lite (11 पायथन रिपॉजिटरीज़ से 300 इश्यूज़) पर किया गया।

लोकलाइजेशन प्रदर्शन (RQ1):
- IssueExec 70.07% फ़ाइल-लेवल Recall@1 प्राप्त करता है, जो सबसे मजबूत बेसलाइन (Agentless) से 17.78% बेहतर है।
- फ़ंक्शन स्तर पर, यह 41.07% Recall@1 प्राप्त करता है, जो सबसे मजबूत बेसलाइन (MoatlessTools) से 41.57% का सुधार है।
- सुधार विभिन्न LLM बैकबोन (GPT-4o और Claude-3.5-Sonnet) में सुसंगत हैं।
इश्यू रेजोल्यूशन प्रदर्शन (RQ2):
- Agentless पाइपलाइन में एकीकृत होने पर, IssueExec 17.72% अधिक इश्यू हल करता है (37.67% बनाम 32.00% रेजोल्यूशन रेट)।
- लेखक इसका श्रेय अत्यधिक केंद्रित, फ़ंक्शन-लेवल कॉन्टेक्स्ट की उपलब्धता को देते हैं, जो डाउनस्ट्रीम पैच जनरेशन मॉडल्स के लिए व्याकुलता को कम करता है।
लागत दक्षता (RQ3):
- IssueExec जटिल एजेंट-आधारित विधियों (जैसे, SWE-Agent, OrcaLoca) की तुलना में प्रति इश्यू औसत लागत को लगभग 35.47% कम करता है, जबकि बेहतर सटीकता बनाए रखता है।
- यह ट्रेस विश्लेषण ओवरहेड के कारण प्रोसीजरल बेसलाइन Agentless की तुलना में थोड़ा महंगा है, लेकिन लेखक तर्क देते हैं कि यह प्रदर्शन लाभ के लिए उचित है।
एब्लेशन स्टडी (RQ4):
- टेस्ट-आधारित इंटरमीडिएट स्टेप को हटाने ("w/o Tests") से F1 स्कोर में महत्वपूर्ण गिरावट आती है (जैसे, फ़ंक्शन स्तर पर -12.94%), जो टेस्ट-मध्यस्थ दृष्टिकोण की केंद्रीयता की पुष्टि करता है।
- ट्रेस विश्लेषण या डोमेन नॉलेज को हटाने से भी प्रदर्शन में भारी गिरावट आती है, जो डायनेमिक एक्जीक्यूशन ग्राउंडिंग और सिमेंटिक एनरिचमेंट दोनों की आवश्यकता को प्रमाणित करता है।

5. महत्व और सीमाएँ (Significance and Limitations)

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

सीमाएँ और विफलता मोड:
लेखक स्पष्ट रूप से दो प्राथमिक विफलता मोड को स्वीकार करते हैं:

मिसिंग टेस्ट कवरेज: यदि रिपॉजिटरी के मौजूदा टेस्ट्स बग वाले कोड को निष्पादित नहीं करते हैं (अध्ययन में ग्राउंड-ट्रुथ फ़ंक्शंस में से 33.30% फुल टेस्ट कवरेज के बाहर हैं), तो ट्रेस-गाइडेड लोकलाइजेशन लक्ष्य तक नहीं पहुँच सकता। यह पूर्व-मौजूदा टेस्ट्स पर निर्भरता की एक संरचनात्मक सीमा है।
लॉन्ग कॉल चेन्स: गहरे एक्जीक्यूशन पाइपलाइन्स (जैसे, बिल्ड सिस्टम) वाले प्रोजेक्ट्स में, ग्राउंड-ट्रुथ लोकेशन उच्च-आवृत्ति वाले ऑर्केस्ट्रेशन नोड्स के नीचे दब सकती है। ट्रेस ग्राफ इन इंफ्रास्ट्रक्चर लेयर्स द्वारा हावी हो सकता है, जिससे विशिष्ट फिक्स साइट छिप सकती है, भले ही स्थान तकनीकी रूप से कवर किया गया हो।

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