Hallucination to Consensus: Multi-Agent LLMs for End-to-End JUnit Test Generation
यह शोधपत्र CANDOR को प्रस्तुत करता है, जो एक नवीन प्रॉम्प्ट इंजीनियरिंग-आधारित मल्टी-एजेंट LLM फ्रेमवर्क है जो जावा में उच्च-गुणवत्ता वाले, मतिभ्रम-प्रतिरोधी (hallucination-resistant) JUnit टेस्ट उत्पन्न करने के लिए सर्वसम्मति-संचालित तर्क और एक ड्यूल-LLM पाइपलाइन का लाभ उठाता है, जो ओरेकल शुद्धता और म्यूटेशन स्कोर में मौजूदा फाइन-ट्यूनिंग और खोज-आधारित दृष्टिकोणों से बेहतर प्रदर्शन करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक शेफ हैं जो एक रोबोट को एक जटिल व्यंजन बनाना सिखाने की कोशिश कर रहे हैं। आप रोबोट को एक रेसिपी (जिसे प्राकृतिक भाषा विवरण - Natural Language Description कहा जाता है) और सब्जियां काटने के निर्देश (जिसे सोर्स कोड - Source Code कहा जाता है) देते हैं।
आपका लक्ष्य रोबोट को एक टेस्ट (Test) लिखना सिखाना है: एक चेकलिस्ट जो यह साबित करे कि व्यंजन सही ढंग से पका है।
- टेस्ट प्रीफिक्स (The Test Prefix): रोबोट द्वारा सामग्री तैयार करना (जैसे, "पॉट में 5 गाजर डालें")।
- टेस्ट ऑरेकल (The Test Oracle): रोबोट द्वारा परिणाम की जांच करना (जैसे, "यदि गाजर नरम हैं, तो व्यंजन तैयार है")।
समस्या क्या है? रोबोट (विशेष रूप से, LLMs नामक AI मॉडल) बहुत बुद्धिमान हैं लेकिन भ्रम (Hallucinations) का शिकार भी हो सकते हैं। कभी-कभी, वे आत्मविश्वास के साथ एक ऐसी चेकलिस्ट लिख देते हैं जो कहती है, "यदि गाजर कच्ची हैं, तो व्यंजन तैयार है," क्योंकि वर्तमान (दोषपूर्ण) कोड ऐसा ही करता है, न कि वह जो रेसिपी में लिखा है।
यह पेपर CANDOR पेश करता है, जो एक नया सिस्टम है जो इस समस्या को ठीक करने के लिए विशेषज्ञों की एक टीम की तरह काम करता है। एक अकेले रोबोट के बजाय जो सब कुछ करने की कोशिश करता है, CANDOR एक "कमेटी" दृष्टिकोण का उपयोग करता है।
यह यहाँ बताया गया है कि CANDOR कैसे काम करता है, जिसे सरल चरणों में विभाजित किया गया है:
1. सेटअप: विशेषज्ञों की एक टीम
अतीत में, एक ही AI सब कुछ करने की कोशिश करता था: कोड लिखना, कवरेज की जांच करना और गलतियों को सुधारना। इससे अक्सर भ्रम पैदा होता था। CANDOR इस काम को एक विशेषज्ञ एजेंटों के पैनल में विभाजित करता है, जैसे कि एक किचन ब्रिगेड:
- इनिशियलाइज़र (The Initializer): "शिक्षार्थी (Apprentice)"। यह पहला ड्राफ्ट लिखने की कोशिश करता है। यह अक्सर सिंटैक्स संबंधी त्रुटियां करता है (जैसे, पायथन ब्रैकेट
[ ]के बजाय जावा लिस्ट का उपयोग करना), लेकिन यह काम को शुरू करता है। - प्लानर (The Planner): "हेड शेफ"। यह कोड को देखता है और कहता है, "हमने खाली कटोरे वाले हिस्से को छोड़ दिया है। आइए उसके लिए एक टेस्ट जोड़ें।" यह रसोई के हर कोने को कवर करने के लिए एक गेम प्लान बनाता है।
- टेस्टर (The Tester): "लाइन कुक"। यह प्लानर के निर्देशों का पालन करता है और वास्तविक टेस्ट कोड लिखता है।
- इंस्पेक्टर (The Inspector): "क्वालिटी कंट्रोल"। यह कोड चलाने की कोशिश करता है। यदि कोई टाइपो या कोई गायब सामग्री (इंपोर्ट स्टेटमेंट) है, तो यह इसे ठीक करने के लिए टेस्टर को वापस भेज देता है।
2. समस्या: "बग्गी कोड" का जाल
यहाँ पेचीदा हिस्सा है। यदि मूल रेसिपी (सोर्स कोड) में कोई गलती है—जैसे रोबोट को "गाजर जलाने" के लिए कहना—तो रोबोट खुशी-खुशी एक टेस्ट लिख देगा जो कहता है, "जली हुई गाजर = सफलता।" इसे रिग्रेशन ऑरेकल (Regression Oracle) कहा जाता है। यह बेकार है क्योंकि यह केवल यह पुष्टि करता है कि बग मौजूद है।
हमें रोबंतु को उस बग्गी कोड को अनदेखा करने और इसके बजाय इच्छित रेसिपी का पालन करने की आवश्यकता है।
3. समाधान: "पैनल चर्चा" (जादुई सॉस)
यहीं CANDOR रचनात्मक होता है। "जली हुई गाजर" वाली गलती को ठीक करने के लिए, यह केवल एक AI से नहीं पूछता। यह एक पैनल चर्चा (Panel Discussion) आयोजित करता है।
- पैनलिस्ट (Reasoning AIs): कल्पना कीजिए कि तीन बुद्धिमान, बहुत अधिक सोचने वाले फूड क्रिटिक्स हैं। वे रेसिपी और बग्गी कोड को पढ़ते हैं। वे आपस में बहस करते हैं।
- पैनलिस्ट 1: "रुको, कोड कहता है उन्हें जला दो, लेकिन रेसिपी कहती है उन्हें भूनो (roast)। कोड गलत है!"
- पैनलिस्ट 2: "मैं सहमत हूँ, लेकिन मुझे गणित को दोबारा जांच लेने दो..." (वे अपने ही विचारों में खो सकते हैं, जिसे "ओवरथिंकिंग" की समस्या कहा जाता है)।
- इंटरप्रिटर्स (The Interpreters): ये क्रिटिक्स के लिए सेक्रेटरी की तरह हैं। क्रिटिक्स बहुत अधिक बोलते हैं और घंटों तक इधर-उधर की बातें करते हैं। सेक्रेटरी उनकी बातों को सुनते हैं, फालतू बातों को हटाते हैं, और केवल मुख्य निष्कर्ष लिखते हैं: "गाजर को भुना जाना चाहिए, जलाया नहीं।"
- क्यूरेटर (The Curator): जज (Judge)। जज सभी सेक्रेटरीज की बात सुनता है। यदि 3 में से 2 लोग इस बात पर सहमत हैं कि गाजर को भुना जाना चाहिए, तो जज अंतिम निर्णय लेता है: "टेस्ट यह जांचना चाहिए कि गाजर भुनी हुई है।"
यह "आम सहमति" (Consensus) वाला दृष्टिकोण AI को भ्रमित होने से रोकता है। भले ही एक AI भ्रमित हो जाए, समूह उसे सुधार लेता है।
4. परिणाम: यह क्यों मायने रखता है
शोधकर्ताओं ने दो बड़े कोडिंग सेट (जैसे कोडिंग स्कूल की परीक्षा) पर CANDOR का परीक्षण किया।
- कवरेज (Coverage): CANDOR मौजूदा सर्वोत्तम टूल्स (जैसे EvoSuite) के समान ही कोड के हर हिस्से को छूने में सक्षम है।
- बग खोजना (Finding Bugs): CANDOR वास्तविक बग खोजने में बहुत बेहतर है। जहाँ अन्य टूल्स केवल यह देखते हैं कि कोड चल रहा है या नहीं, वहीं CANDOR यह जांचता है कि क्या कोड वह कर रहा है जो उसे करना चाहिए।
- विशेषज्ञों को पछाड़ना: इसने वर्तमान अत्याधुनिक टूल (TOGLL) को भारी अंतर (21% से अधिक) से पीछे छोड़ दिया। सबसे अच्छी बात? TOGLL को भारी मात्रा में डेटा पर "ट्रेन" करने की आवश्यकता थी (जैसे वर्षों तक अध्ययन करने वाला छात्र), जबकि CANDOR केवल स्मार्ट प्रॉम्प्ट्स का उपयोग करता है (जैसे एक स्मार्ट छात्र जो सही सवाल पूछना जानता है)।
मुख्य निष्कर्ष
CANDOR यह सिद्ध करता है कि आपको परफेक्ट टेस्ट लिखने के लिए एक सुपर-महंगे AI को प्रशिक्षित करने की आवश्यकता नहीं है। इसके बजाय, आप एक मानक AIs की टीम का उपयोग कर सकते हैं जो मिलकर काम करती है, बहस करती है और आम सहमति तक पहुँचती है।
यह एक व्यक्ति से गणित की समस्या हल करने के लिए कहने (जो गलती कर सकता है) और एक पूरी कक्षा से उसे हल करने, चर्चा करने और सही उत्तर के लिए वोट करने के लिए कहने के बीच का अंतर है। परिणाम एक ऐसा टेस्ट सूट है जो न केवल व्यापक है, बल्कि वास्तव में आपको बताता है कि आपका सॉफ्टवेयर अपने इच्छित कार्य के अनुसार काम कर रहा है या नहीं।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।