← नवीनतम पेपर
🤖 AI

EvolveTool-Bench: Evaluating the Quality of LLM-Generated Tool Libraries as Software Artifacts

यह शोध पत्र EvolveTool-Bench को प्रस्तुत करता है, जो एक नैदानिक बेंचमार्क है जो पुन: उपयोग (reuse), अतिरेक (redundancy) और सुरक्षा जैसे मेट्रिक्स के माध्यम से LLM-जनित टूल लाइब्रेरीज़ की सॉफ्टवेयर गुणवत्ता का मूल्यांकन करता है, जो उन प्रणालियों के बीच महत्वपूर्ण स्वास्थ्य असमानताओं को प्रकट करता है जो केवल कार्य पूर्णता दरों (task completion rates) के आधार पर समान दिखाई देती हैं।

मूल लेखक: Alibek T. Kaliyev, Artem Maryanskyy

प्रकाशित 2026-04-02
📖 6 मिनट में पढ़ें🧠 गहराई से पढ़ें

मूल लेखक: Alibek T. Kaliyev, Artem Maryanskyy

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

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

वर्तमान में अधिकांश परीक्षण केवल यह पूछते हैं: "क्या काम पूरा हो गया?" यदि एआई ने कार्य को सफलतापूर्वक पूरा कर लिया है, तो हम उसे एक गोल्ड स्टार देते हैं।

यह शोध पत्र तर्क देता है कि सॉफ्टवेयर को आंकने का यह एक बहुत ही बुरा तरीका है।

यह एक निर्माण दल (construction crew) को काम पर रखने जैसा है और केवल यह पूछने जैसा है, "क्या घर खड़ा है?" आपको इस बात से कोई फर्क नहीं पड़ेगा कि उन्होंने सड़ी हुई लकड़ी का उपयोग किया, एक ही कमरे में तीन समान दरवाजे बनाए, या वायरिंग खुली छोड़ दी, जब तक कि छत से पानी नहीं टपक रहा है। अंततः, वह घर अपने ही वजन से ढह जाएगा।

यहाँ शोध पत्र को सरल अवधारणाओं में विभाजित किया गया है:

1. समस्या: "ब्लैक बॉक्स" का जाल

वर्तमान एआई एजेंट अपनी मर्जी से नए टूल्स बनाने में बेहतर होते जा रहे हैं। लेकिन हम उनका मूल्यांकन एक जादू के डिब्बे की तरह कर रहे हैं: इनपुट दें एक समस्या, समाधान प्राप्त करें। हम अनदेखा कर रहे हैं कि अंदर क्या हो रहा है।

  • जोखिम: एआई आज 500 लाइन का अव्यवस्थित, डुप्लिकेट या खतरनाक कोड लिखकर समस्या को हल कर सकता है। यह अभी काम करता है, लेकिन कल, वह कोड रखरखाव के लिए एक दुस्वप्न बन जाएगा, बग्स से भरा होगा, और उन चीजों को तोड़ देगा जो पहले काम करती थीं।

2. समाधान: EvolveTool-Bench

लेखकों ने एक नया "रिपोर्ट कार्ड" बनाया जिसे EvolveTool-Bench कहा जाता है। केवल यह जांचने के बजाय कि कार्य पूरा हुआ या नहीं, वे टूलबॉक्स की गुणवत्ता का निरीक्षण करते हैं।

वे कोड को एक सीनियर सॉफ्टवेयर आर्किटेक्ट की तरह देखते हैं:

  • पुन: उपयोग (Reuse): क्या एआई ने एक नया टूल लिखा, या उसने एक मौजूदा टूल को लिया और उसे फिर से इस्तेमाल किया? (अच्छे इंजीनियर पुन: उपयोग करते हैं; बुरे सब कुछ फिर से लिखते हैं)।
  • अनावश्यकता (Redundancy): क्या एआई ने गलती से दो ऐसे टूल्स बना दिए जो बिल्कुल एक जैसा काम करते हैं? (जगह की बर्बादी)।
  • सुरक्षा (Safety): क्या नए टूल ने पुराने टूल को तोड़ दिया? (रिग्रेशन/Regression)।
  • मजबूती (Robustness): क्या टूल क्रैश हो जाता है यदि आप इसे अजीब डेटा देते हैं, या यह इसे शालीनता से संभालता है?

3. प्रयोग: दौड़

उन्होंने 99 कठिन कार्यों (जैसे गुप्त बाइनरी फाइलों को डिकोड करना या जटिल API को प्रबंधित करना) पर तीन अलग-अलग प्रकार के एआई "इंजीनियरों" का परीक्षण किया:

  1. "नो-इवोल्यूशन" (No-Evolution) टीम: वे केवल उन्हीं टूल्स का उपयोग करते हैं जो उनके पास शुरुआत में थे। वे नए हुनर नहीं सीख सकते।
  2. "इवोस्किल" (EvoSkill) टीम: वे सीखने की कोशिश करते हैं, लेकिन वे केवल अपने शब्दों (प्रॉम्प्ट्स) को बदलते हैं, वास्तविक कोड को नहीं। वे एक ऐसे शेफ की तरह हैं जो रेसिपी के निर्देशों को तो बदलता है लेकिन वास्तव में नई सब्जी काटना नहीं सीखता।
  3. "एराइज" (ARISE) टीम: यह उन्नत टीम है। जब वे विफल होते हैं, तो वे वास्तविक नया कोड लिखते हैं, उसे एक सुरक्षित सैंडबॉक्स में टेस्ट करते हैं, और यदि वह काम करता है, तो वे उसे टूलबॉक्स में जोड़ देते हैं। वे यह भी जांचते हैं कि क्या नया कोड पुरानी चीजों को तोड़ रहा है।

4. चौंकाने वाले परिणाम

यहीं पर उपमा (analogy) दिलचस्प हो जाती है।

  • "कार्य पूर्णता" (Task Completion) स्कोर: सभी टीमों ने लगभग समान संख्या में कार्य पूरे किए (लगभग 63-68%)। यदि आप केवल इसे देखते, तो आप कहते, "बहुत अच्छा काम, सब बढ़िया है!"
  • "सॉफ्टवेयर स्वास्थ्य" (Software Health) स्कोर: यहीं पर टीमें पूरी तरह से अलग हो गईं।
    • EvoSkill टीम (जिसने कोड नहीं लिखा) का टूलबॉक्स भी उतना ही अव्यवस्थित था जितना कि उस टीम का जिसने कुछ नहीं किया।
    • One-Shot टीम (जिसने बिना परीक्षण के कोड लिखा) ने वास्तव में चीजों को और खराब कर दिया। उनका टूलबॉक्स टूटे हुए, खतरनाक टूल्स से भरा था।
    • ARISE टीम (जिसने कोड लिखा और टेस्ट किया) का टूलबॉक्स सबसे स्वस्थ था। भले ही उन्होंने थोड़े कम कार्य पूरे किए, लेकिन उनके टूल्स पुन: उपयोग योग्य, सुरक्षित थे और पुराने फीचर्स को नहीं तोड़ते थे।

उपमा:
कल्पना कीजिए कि तीन शेफ स्टू (stew) बना रहे हैं।

  • शेफ A (No-Evolution) एक पहले से बने मिक्स का उपयोग करता है। इसका स्वाद ठीक है, लेकिन अगर नमक खत्म हो जाए तो वे इसे ठीक नहीं कर सकते।
  • शेफ B (EvoSkill) खाना पकाने के बारे में बहुत बातें करता है लेकिन वास्तव में कोई नए सामग्रियां नहीं जोड़ता।
  • शेफ C (ARISE) एक नया मसाला मिश्रण बनाता है। स्टू पूरा करने में उन्हें थोड़ा अधिक समय लगता है, लेकिन मसाला मिश्रण उच्च गुणवत्ता वाला है, पुन: उपयोग योग्य है, और अगले सप्ताह के लिए सूप को खराब नहीं करेगा।

शोध पत्र ने पाया कि शेफ C ही एकमात्र है जो एक टिकाऊ रसोई बना रहा है।

5. वास्तविक दुनिया के लिए मुख्य निष्कर्ष

  • कार्य की सफलता एक झूठ है: केवल इसलिए कि एक एआई ने समस्या को हल कर दिया, इसका मतलब यह नहीं है कि उसने अच्छा काम किया। उसने "तकनीकी ऋण" (technical debt - एक गड़बड़) पैदा किया होगा जो बाद में भारी पड़ेगा।
  • परीक्षण अनिवार्य है: शोध पत्र ने पाया कि जो एआई टूल्स बनाए गए हैं लेकिन जिनका परीक्षण नहीं किया गया है, वे बिना किसी टूल के होने से भी बदतर हैं। वे एक देनदारी (liability) हैं।
  • "जज" (Judge) महत्वपूर्ण है: एआई को एक सख्त "जज" (एक प्रणाली जो कोड की जांच करती है) की आवश्यकता होती है ताकि यह तय किया जा सके कि क्या एक नया टूल रखने लायक है। यदि जज बहुत आसान है, तो एआई केवल कचरा कोड उगल देगा।
  • सस्ते मॉडल भी काम करते हैं: आश्चर्यजनक रूप से, एक सस्ता, तेज़ एआई मॉडल (Haiku) सही परीक्षण प्रणाली का उपयोग करने पर एक बेहतर टूलबॉक्स बनाने में अधिक स्मार्ट मॉडल (Sonnet) से थोड़ा बेहतर रहा।

निचोड़ (The Bottom Line)

हमें एआई द्वारा उत्पन्न कोड को एक "ब्लैक बॉक्स" के रूप में मानना बंद करना होगा जो बस काम करता है। हमें इसे सॉफ्टवेयर इंजीनियरिंग की तरह मानना होगा। हमें बग्स, अनावश्यकता और सुरक्षा की जांच करनी होगी। यदि हम ऐसा नहीं करते हैं, तो हम रेत पर डिजिटल घर बना रहे हैं, और वे अंततः बह जाएंगे।

EvolveTool-Bench वह नया पैमाना है जिसकी हमें न केवल यह मापने के लिए आवश्यकता है कि एआई काम करता है या नहीं, बल्कि यह भी कि वह भविष्य के लिए कितना बेहतर निर्माण करता है।

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

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

Digest आज़माएँ →