💻 computer science

Heterogeneous Prompting and Execution Feedback for SWE Issue Test Generation and Selection

यह शोध पत्र e-Otter++ प्रस्तुत करता है, जो एक नवीन टेस्ट जनरेटर है जो हेट्रोजेनियस प्रॉम्प्टिंग और एक्जीक्यूशन फीडबैक का लाभ उठाकर सॉफ्टवेयर इंजीनियरिंग इश्यूज में गायब या गलत कोड की चुनौती को दूर करता है ताकि स्वचालित रूप से रिप्रोडक्शन टेस्ट्स बना सके, जिससे TDD-Bench Verified बेंचमार्क पर 63% का स्टेट-ऑफ-द-आर्ट फेल-टू-पास रेट प्राप्त होता है।

मूल लेखक: Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

प्रकाशित 2026-01-26

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

CC BY 4.0

मूल लेखक: Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

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

कल्पना कीजिए कि आप एक जासूस हैं जो एक विशाल, अव्यवस्थित पुस्तकालय (सॉफ्टवेयर कोड) में एक रहस्य को सुलझाने की कोशिश कर रहे हैं। एक संरक्षक (डेवलपर) आपके पास आता है और कहता है, "इस किताब में कुछ गलत है, लेकिन मैं ठीक से समझा नहीं सकता कि क्या, और मेरे पास इस गलती का कोई विशिष्ट उदाहरण भी नहीं है।"

सॉफ्टवेयर की दुनिया में, इसे SWE Issue कहा जाता है। आमतौर पर, किसी बग को ठीक करने के लिए, आपको एक "पुनरुत्पादन परीक्षण" (reproduction test) की आवश्यकता होती—एक विशिष्ट स्क्रिप्ट जो कहती है, "यदि आप X करते हैं, तो लाइब्रेरी क्रैश हो जानी चाहिए।" यह साबित करता है कि बग मौजूद है। लेकिन अक्सर, ऐसे स्क्रिप्ट अभी तक मौजूद नहीं होते।

यह शोध पत्र e-Otter++ नामक एक नया जासूसी उपकरण पेश करता है। इसका काम केवल समस्या के उलझे हुए विवरण को पढ़कर उस "क्रैश स्क्रिप्ट" (परीक्षण) को स्वचालित रूप से लिखना है, इससे पहले कि वास्तविक सुधार (fix) लिखा ही जाए।

e-Otter++ कैसे काम करता है, इसे सरल उपमाओं के माध्यम से समझाया गया है:

1. समस्या: "अंधा" जासूस

आमतौर पर, यदि आप किसी बुद्धिमान AI (एक लार्ज लैंग्वेज मॉडल) से एक परीक्षण लिखने के लिए कहते हैं, तो वह अनुमान लगाने की कोशिश करता है। यदि आप एक बार पूछते हैं, तो यह गलत हो सकता है। यदि आप इसे ठीक 10 बार एक ही निर्देशों के साथ पूछते हैं, तो यह आपको केवल गलत अनुमानों के 10 थोड़े अलग संस्करण दे सकता है। यह एक दोस्त से उस फिल्म का वर्णन करने के लिए पूछने जैसा है जिसे उसने केवल एक बार देखा था; यदि आप उससे 10 बार पूछते हैं, तो वह शायद वही गलती दोहराता रहेगा।

2. पहली तरकीब: "हेटरोजीनियस प्रॉम्प्टिंग" (कॉस्ट्यूम पार्टी)

बेहतर अनुमान प्राप्त करने के लिए, e-Otter++ केवल AI से 10 बार एक ही सवाल नहीं पूछता। इसके बजाय, यह पूछने के तरीके को बदल देता है, जैसे AI को अलग-अलग वेशभूषा पहनाना या उसे अलग-अलग दृष्टिकोण देना।

"मास्क" (Masks): कल्पना करें कि AI एक पहेली देख रहा है। कभी-कभी, e-Otter++ पहेली के कुछ हिस्सों को ढक देता है (कोड संदर्भ) ताकि AI कम जानकारी के आधार पर अनुमान लगा सके। अन्य समय में, यह केवल विशिष्ट हिस्से दिखाता है। यह AI को समस्या को अलग तरह से देखने के लिए मजबूर करता है।
"मॉर्फ्स" (Morphs): कल्पना करें कि बग रिपोर्ट भ्रमित करने वाली शब्दावली में लिखी गई है। e-Otter++ AI को रिपोर्ट को विभिन्न शैलियों में फिर से लिखने के लिए कहता है:
- द स्टैंडर्डाइज़र (The Standardizer): एक बिखरे हुए नोट को एक औपचारिक, संरचित रिपोर्ट में बदल देता है।
- द सिम्प्लीफायर (The Simplifier): भ्रमित करने वाली तकनीकी शब्दावली को हटा देता है ताकि इसे समझना आसान हो सके।
- द ड्रॉपर (The Dropper): विशिष्ट कोड स्निपेट्स को हटा देता है जो भ्रामक हो सकते हैं (जैसे AI को उस टूल का उपयोग करने के लिए कहना जो लाइब्रेरी के पास वास्तव में नहीं है)।
- द प्री-थिंकर (The Pre-Thinker): AI को पहले समाधान का अनुमान लगाने के लिए कहता है, फिर उस अनुमान का उपयोग परीक्षण लिखने के लिए करता है।

इन "मास्क" और "मॉर्फ्स" को मिलाकर, e-Otter++ संभावित परीक्षणों का एक विशाल, विविध पूल बनाता है। यह 10 अलग-अलग लोगों से अपराध स्थल का वर्णन करने के लिए कहने जैसा है, लेकिन प्रत्येक व्यक्ति को अलग-अलग सुराग और बोलने का अलग तरीका दिया गया है। इससे इस बात की संभावना बढ़ जाती है कि कम से कम एक व्यक्ति सही अनुमान लगा ले।

3. दूसरी तरकीब: "एग्जीक्यूशन फीडबैक" (ट्रायल रन)

एक बार जब AI एक परीक्षण बनाता है, तो e-Otter++ केवल उस पर भरोसा नहीं करता। यह परीक्षण को पुराने कोड (बग वाले संस्करण) पर चलाता है।

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

4. तीसरी तरिक: "सरोगेट पैच" (डमी फिक्स)

यहाँ सबसे कठिन हिस्सा है: यह जानने के लिए कि एक परीक्षण अच्छा है, इसे नए कोड (फिक्स) पर पास होना चाहिए। लेकिन फिक्स अभी मौजूद नहीं है! आप सबसे अच्छे परीक्षण को कैसे चुन सकते हैं?

e-Ot Otter++ एक चतुर वर्कअराउंड का उपयोग करता है:

यह एक अलग AI सिस्टम (Agentless) से कई नकली फिक्स (सरोगेट पैच) उत्पन्न करने के लिए कहता है। ये पूर्ण नहीं हैं, लेकिन करीब हैं।
यह इन नकली फिक्स के विरुद्ध सभी उम्मीदवार परीक्षणों को चलाता है।
यदि कोई परीक्षण नकली फिक्स पर पास हो जाता है, तो इसकी संभावना है कि वह एक अच्छा परीक्षण है।
अंत में, यह सबसे अच्छे परीक्षण को इस आधार पर चुनता है कि कौन सा कोड के सबसे महत्वपूर्ण हिस्सों को कवर करता है।

परिणाम: एक बड़ी छलांग

इस शोध पत्र ने दो प्रमुख बेंचमार्क (TDD-Bench और SWT-bench) पर इस प्रणाली का परीक्षण किया।

पिछला सर्वश्रेष्ठ: शीर्ष प्रणालियाँ लगभग 37% से 38% बार एक काम करने वाला परीक्षण उत्पन्न कर पाती थीं।
e-Otter++: इन नई तरकीबों (सवाल पूछने का तरीका बदलकर और फिल्टर करने के लिए नकली फिक्स का उपयोग करके) का उपयोग करते हुए, e-Otter++ ने एक बेंचमार्क पर 63% और दूसरे पर 52.5% की सफलता दर हासिल की।

यह क्यों महत्वपूर्ण है

लेखकों का कहना है कि यह मुख्य रूप से दो तरीकों से मदद करता है:

मानव के लिए: यह "टेस्ट-ड्रिवन डेवलपमेंट" (बग ठीक करने से पहले परीक्षण लिखना) के उबाऊ हिस्से को स्वचालित करता है, जिससे डेवलपर्स के लिए बग की पुष्टि करना और उन्हें ठीक करना आसान हो जाता है।
AI एजेंटों के लिए: कई AI कोडिंग एजेंट इन परीक्षणों पर निर्भर करते हैं ताकि उन्हें पता चल सके कि उन्होंने बग को ठीक किया है या नहीं। बेहतर परीक्षण प्रदान करके, e-Otter++ अन्य AI एजेंटों को अपना काम बेहतर ढंग से करने में मदद करता है।

संक्षेप में, e-Otter++ एक स्मार्ट, अधिक रचनात्मक और अधिक कठोर तरीका है जिससे AI से यह "प्रमाण" लिखने के लिए कहा जाता है कि एक सॉफ्टवेयर बग मौजूद है और उसे ठीक कर दिया गया है, बिना किसी मानव द्वारा उस प्रमाण को लिखे जाने की प्रतीक्षा किए।

तकनीकी सारांश: SWE समस्या परीक्षण जनरेशन और चयन के लिए हेट्रोजेनियस प्रॉम्प्टिंग और निष्पादन फीडबैक

समस्या विवरण
सॉफ्टवेयर इंजीनियरिंग (SWE) की समस्याएँ (issues), जो बग या गायब फीचर्स का वर्णन करती हैं, अक्सर अनौपचारिक विवरणों के साथ आती हैं जिनमें स्वचालित पुनरुत्पादन परीक्षणों (reproduction tests) का अभाव होता है। ऐसे परीक्षणों की अनुपस्थिति समस्याओं के सत्यापन और कोड पैच की स्वीकृति में बाधा डालती है। इस शोध पत्र में संबोधित विशिष्ट चुनौती समस्या विवरणों और मौजूदा (पैच-पूर्व) कोडबेस ( $c_{old}$ ) से सीधे "फेल-टू-पास" ( $F \to P$ ) पुनरुत्पादन परीक्षणों को स्वचालित रूप से उत्पन्न करना है, बिना समाधान करने वाले कोड पैच ( $c_{new}$ ) तक पहुँच के। एक वैध $F \to P$ परीक्षण $c_{old}$ पर निष्पादित होने पर विफल होना चाहिए (समस्या को पुनरुत्पादित करना) और $c_{new}$ पर निष्पादित होने पर पास होना चाहिए (फिक्स की पुष्टि करना)। यह कार्य कठिन है क्योंकि समस्या विवरण अनौपचारिक होते हैं, और परीक्षण के पास होने के लिए लक्षित कोड अभी अस्तित्व में नहीं होता है।

कार्यप्रणाली: e-Otter++
लेखक e-Otter++ पेश करते हैं, जो पूर्ववर्ती Otter++ फ्रेमवर्क का विस्तार करता है। यह सिस्टम तीन प्राथमिक घटकों के माध्यम से संचालित होता है: एक टेस्ट जनरेटर, एक कोड पैच जनरेटर, और एक टेस्ट सेलेक्टर।

हेट्रोजेनियस प्रॉम्प्टिंग के साथ परीक्षण जनरेशन:
केवल विविध उम्मीदवारों को उत्पन्न करने के लिए LLM डिकोडिंग तापमान को बढ़ाने (एक सामान्य अभ्यास जिसमें अक्सर विविधता की कमी होती है) पर निर्भर रहने के बजाय, e-Otter++ हेट्रोजेनियस प्रॉम्प्टिंग का उपयोग करता है। इसमें दो व्यवस्थित परिवर्तन शामिल हैं:

इश्यू डिस्क्रिप्शन मॉर्फ्स (Issue Description Morphs): एक LLM परीक्षण जनरेशन से पहले मूल समस्या विवरण को पाँच अलग-अलग तरीकों से फिर से लिखता है: स्टैंडर्ड (फॉर्मेटिंग), सिंपल (जार्गन को सरल बनाना), ड्रॉपकोड (संभावित भ्रामक कोड स्निपेट्स को हटाना), इनिटटेस्ट (एक प्रारंभिक परीक्षण को शामिल करना), और इनिटपैच (एक प्रारंभिक पैच प्रस्ताव को शामिल करना)।
कॉन्टेक्स्ट मास्क (Context Masks): टेस्ट जनरेशन प्रॉम्प्ट को विशिष्ट लोकलाइजेशन कॉन्टेक्स्ट (जैसे, प्लानर आउटपुट, टेस्ट लोकलाइजेशन, पैच लोकलाइजेशन) को शामिल करने या बाहर करने के लिए संशोधित किया जाता है, जिससे पाँच अलग-अलग प्रॉम्प्ट वेरिएशन्स बनते हैं।
इनका संयोजन करके, सिस्टम प्रति समस्या 10 कैंडिडेट टेस्ट का एक विविध पूल बनाता है।

एग्जीक्यूशन-ऑगमेंटेड टेस्ट रिपेयर:
जेनेरेट किए गए कैंडिडेट टेस्ट को $c_{old}$ पर निष्पादित किया जाता है। हालांकि उनसे विफल होने की अपेक्षा की जाती है, वे गलत कारणों से विफल हो सकते हैं (जैसे, सिंटैक्स एरर या असंबंधित अपवाद) न कि विशिष्ट वर्णित समस्या को पुनरुत्पादित करने के लिए। e-Otter++ एक क्रिटिक (critic) तंत्र पेश करता है:

एक LLM समस्या विवरण और निष्पादन लॉग का विश्लेषण करता है ताकि यह निर्धारित किया जा सके कि क्या परीक्षण "सही कारण" से विफल हुआ है।
यदि विफलता गलत है, तो क्रिटिक आवश्यक संदर्भ (जैसे, विशिष्ट बग वाली लाइनें, प्रासंगिक कोड स्निपेट्स, या फंक्शन सिग्नेचर) की पहचान करता है और रिपेयर प्रॉम्प्ट को समृद्ध (augment) करता है।
सिस्टम इस समृद्ध संदर्भ का उपयोग करके टेस्ट को पुनरावर्ती रूप से रिपेर करता है (10 प्रयासों तक) जब तक कि टेस्ट सही कारण से विफल न हो जाए या इटरेशन सीमा समाप्त न हो जाए।

सरोगेट पैच के माध्यम से टेस्ट चयन:
चूंकि $c_{new}$ उपलब्ध नहीं है, इसलिए e-Otter++ सीधे यह सत्यापित नहीं कर सकता कि एक परीक्षण वास्तविक फिक्स पर पास होगा या नहीं। इसे हल करने के लिए, सिस्टम 40 कैंडिडेट कोड पैच (जो $c_{new}$ के सरोगेट हैं) उत्पन्न करने के लिए Agentless का उपयोग करता है और उन्हें 5 सबसे अधिक बार आने वाले पैच तक फ़िल्टर करता है।

टेस्ट सेलेक्टर इन सरोगेट पैच पर कैंडिडेट टेस्ट को निष्पादित करता है।
जो टेस्ट सरोगेट पैच पर $F \to P$ होते हैं, उन्हें प्राथमिकता दी जाती है।
एक रूल-बेस्ड सेलेक्टर विफलताओं को वर्गीकृत करता है (असर्शन फेलियर बनाम एरर) और एकल अंतिम टेस्ट चुनने के लिए कोड कवरेज (पैच द्वारा जोड़ी गई/हटाई गई लाइनों का अनुपात जिसे टेस्ट कवर करता है) का उपयोग टाई-ब्रेकर के रूप में करता है।

प्रमुख योगदान
यह शोध पत्र तीन नवीन योगदान देता है:

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

परिणाम
सिस्टम का मूल्यांकन TDD-Bench Verified (449 नमूने) और SWT-bench Lite (276 नमूने) पर किया गया, जो दोनों SWE-bench से प्राप्त हैं।

प्रदर्शन: e-Otter++ ने TDD-Bench Verified पर 63.0% की Fail-to-Pass ( $F \to P$ ) दर और SWT-bench Lite पर 52.5% (Claude-3.7-Sonnet मॉडल का उपयोग करते हुए) हासिल की। यह पिछले सर्वश्रेष्ठ प्रकाशित परिणामों (Otter++ क्रमशः 37.0% और 29.0%) से काफी बेहतर है।
घटक प्रभावकारिता (Component Efficacy):
- एग्जीक्यूशन-ऑगमेंटेड रिपेयर ने विभिन्न कॉन्फ़िगरेशन में $F \to P$ दरों में 11.1% से 74.3% तक सुधार किया।
- हेट्रोजेनियस प्रॉम्प्टिंग (मॉर्फ्स + मास्क) ने केवल मास्क का उपयोग करने की तुलना में $F \to P@N$ (N उम्मीदवारों में से कम से कम एक सफल टेस्ट की दर) को 13% से अधिक बढ़ाया।
- टेस्ट चयन के लिए जेनेरेटेड कोड पैच का उपयोग करने से प्रदर्शन में महत्वपूर्ण वृद्धि हुई (उदाहरण के लिए, TDD-Bench Verified पर $F \to P$ में 32.9% की वृद्धि)।
सामान्यीकरण (Generalizability): दृष्टिकोण को एक कंटामिनेशन-फ्री बेंचमार्क, SWE-rebase पर मान्य किया गया, जहाँ इसने बेस Otter सिस्टम की तुलना में $F \to P$ दर में सापेक्ष 75% का सुधार किया, जो डेटा कंटामिनेशन के विरुद्ध मजबूती को प्रदर्शित करता है।
वैलिडेशन उपयोगिता: दिखाए गए कि जेनेरेटेड टेस्ट अन्य SWE एजेंटों के कोड पैच को प्रभावी ढंग से वैलिडेट करते हैं, जिससे शीर्ष लीडरबोर्ड सिस्टम द्वारा प्रस्तावित समाधानों की सटीकता में काफी सुधार होता है।

महत्व और दावे
लेखक दावा करते हैं कि e-Otter++, SWE इश्यू से रिप्रोडक्शन टेस्ट उत्पन्न करने के क्षेत्र में स्टेट-ऑफ-द-आर्ट में एक बड़ी छलांग है। पेपर का तर्क है कि हेट्रोजनियस प्रॉम्प्टिंग और निष्पादन फीडबैक का संयोजन—विशेष रूप से चयन के लिए सरोगेट पैच के नवीन उपयोग और कॉन्टेक्स्ट-ऑगमेंटेड रिपेयर का उपयोग—पिछले तरीकों की सीमाओं को दूर करता है जो टेस्ट विविधता और सत्यापन के लिए लक्षित कोडबेस की कमी के कारण संघर्ष कर रहे थे।

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