← नवीनतम पेपर
💬 NLP

Asuka-Bench: Benchmarking Code Agents on Underspecified User Intent and Multi-Round Refinement

यह शोध पत्र Asuka-Bench को पेश करता है, जो एक नया बेंचमार्क है जिसे वास्तविक दुनिया के मल्टी-राउंड रिफाइनमेंट चक्रों को सिम्युलेट करके वेब डेवलपमेंट कार्यों पर कोड एजेंटों का मूल्यांकन करने के लिए डिज़ाइन किया गया है, जहाँ एजेंट स्वचालित UI टेस्टिंग और प्राकृतिक भाषा फीडबैक के आधार पर कम-निर्दिष्ट (underspecified) प्रोजेक्ट्स को बार-बार बेहतर बनाते हैं, जिससे वर्तमान मॉडलों के बीच प्रदर्शन के महत्वपूर्ण अंतर का पता चलता है।

मूल लेखक: Xin Wang, Liangtai Sun, Yaoming Zhu, Shuang Zhou, Jiaxing Liu, Fengjiao Chen, Lin Qiu, Xuezhi Cao, Xunliang Cai, Licheng Zhang, Zhendong Mao

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

मूल लेखक: Xin Wang, Liangtai Sun, Yaoming Zhu, Shuang Zhou, Jiaxing Liu, Fengjiao Chen, Lin Qiu, Xuezhi Cao, Xunliang Cai, Licheng Zhang, Zhendong Mao

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

कल्पना कीजिए कि आप एक शानदार लेकिन थोड़े शाब्दिक अर्थों में सोचने वाले (literal-minded) वास्तुकार (architect) को एक घर बनाने के लिए काम पर रख रहे हैं।

पुराना तरीका (मौजूदा बेंचमार्क)
अतीत में, इन वास्तुकारों का परीक्षण करना उन्हें एक आदर्श, 50-पेज का ब्लूप्रिंट देने जैसा था जिसमें हर एक कील, तार और पेंट के रंग का विवरण दिया गया हो। आप उनसे कहते थे, "इसे बनाओ," और वे आपको एक तैयार घर सौंप देते थे। यदि घर ब्लूप्रिंट से मेल खाता था, तो उन्हें 'A' ग्रेड मिलता था। यदि नहीं, तो उन्हें 'F' मिलता था।

समस्या यह है कि वास्तविक जीवन ऐसे काम नहीं करता। वास्तविक ग्राहकों के पास शायद ही कभी कोई सटीक 50-पेज का ब्लूप्रिंट होता है। वे आमतौर पर कहते हैं, "मुझे एक रसोई और सोने के लिए एक जगह वाला घर चाहिए," और फिर, एक बार जब वे पहला ड्राफ्ट देखते हैं, तो उन्हें एहसास होता है, "ओह, वास्तव में मैं चाहता था कि रसोई बड़ी हो," या "रुको, दरवाजा गलत दिशा में खुल रहा है।"

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

फिर, वे केवल पहले परिणाम को ग्रेड नहीं देते। वे एक तीन-सदस्यीय टीम स्थापित करते हैं जो वास्तविक दुनिया के विकास चक्र (development cycle) को निभाती है:

  1. बिल्डर (कोड एजेंट): यह वह AI है जो अस्पष्ट अनुरोध के आधार पर वेबसाइट बनाने की कोशिश कर रहा है।
  2. इंस्पेक्टर (UI एजेंट): यह एक रोबोट है जो वास्तव में वेब ब्राउज़र में वेबसाइट पर जाता है। यह कोड नहीं पढ़ता; यह एक मानव उपयोगकर्ता की तरह व्यवहार करता है। यह बटन क्लिक करता है, चीजें खरीदने की कोशिश करता है, और यह जांचता है कि पेज लोड हो रहे हैं या नहीं। यह घर के अंदर घूमकर यह देखने वाले गुणवत्ता नियंत्रण निरीक्षक की तरह है कि दरवाजे खुल रहे हैं या नहीं।
  3. क्लाइंट (यूजर LLM): यह एक अन्य AI है जो इंस्पेक्टर को देखता है। यदि इंस्पेक्टर को कोई समस्या मिलती है (जैसे, "'Buy' बटन काम नहीं कर रहा है"), तो क्लाइंट उस समस्या को बिल्डर के लिए एक विनम्र नोट में बदल देता है: "हे, बटन टूटा हुआ है। कृपया इसे ठीक करें।"

इसके बाद बिल्डर वेबसाइट को ठीक करता है, और यह चक्र दोहराया जाता है। यह तीन राउंड तक चल सकता है।

"DAG" उपमा
शोधकर्ताओं ने फीडबैक देने के लिए एक स्मार्ट तरीका भी आविष्कार किया जिसे DAG (Directed Acyclic Graph) कहा जाता है। इसे एक रेसिपी की तरह समझें।

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

उन्होंने क्या पाया
शोधकर्ताओं ने इस पद्धति का उपयोग करके 8 अलग-अलग AI मॉडल का परीक्षण किया। यहाँ उनकी खोज है:

  • कुछ AI दूसरों की तुलना में सुधार करने में बेहतर हैं: सिर्फ इसलिए कि कोई AI पहला ड्राफ्ट बनाने में अच्छा है, इसका मतलब यह नहीं है कि वह गलतियों को सुधारने में भी अच्छा है। कुछ मॉडल एक बेहतरीन पहला संस्करण बनाते थे लेकिन त्रुटियों को ठीक करने के लिए "क्लाइंट" के नोट्स को समझने में असमर्थ थे। अन्य मॉडल अव्यवस्थित शुरुआत करते थे लेकिन फीडबैक के हर दौर के साथ बेहतर होते गए।
  • अंतर बहुत बड़ा है: सबसे अच्छे मॉडल तीन राउंड के सुधार के बाद लगभग 52% प्रोजेक्ट्स को पूरी तरह से पूरा कर सके। सबसे खराब मॉडल केवल 8% पूरा कर पाए। यह एक बहुत बड़ा अंतर है।
  • यह अभी भी कठिन है: सबसे स्मार्ट AI भी हर एक प्रोजेक्ट को पूरी तरह से पूरा नहीं कर सका। यह दर्शाता है कि जबकि AI अच्छा हो रहा है, वह वास्तविक मानवीय अनुरोधों की अव्यवस्थित और उतार-चढ़ाव वाली प्रकृति के साथ संघर्ष करता है।

सारांश में
Asuka-Bench कोडर्स के लिए एक नया "ड्राइविंग टेस्ट" है। उन्हें केवल एक बिल्कुल सीधी, खाली ट्रैक (एक परफेक्ट ब्लूप्रिंट) पर कार चलाने के लिए कहने के बजाय, उन्हें शहर के ट्रैफिक में गाड़ी चलाने, गलत मोड़ लेने पर बगल में बैठे यात्री से निर्देश लेने और अपना रास्ता सुधारने के लिए कहा जाता है। यह साबित होता है कि फीडबैक सुनकर और गलतियों को सुधारना, सीधे गाड़ी चलाने के ज्ञान से पूरी तरह से अलग कौशल है।

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

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

Digest आज़माएँ →