MobileDev-Bench: A Comprehensive Benchmark for Evaluating Language Models on Mobile Application Development
MobileDev-Bench एक व्यापक बेंचमार्क है जिसमें Android Native, React Native और Flutter प्लेटफॉर्म्स के 384 वास्तविक दुनिया के समस्या-समाधान कार्य शामिल हैं जो अत्याधुनिक LLMs में महत्वपूर्ण प्रदर्शन अंतराल को प्रकट करता है, जहाँ एंड-टू-एंड समाधान दर 3.39%–5.21% जितनी कम है, जिसका मुख्य कारण मल्टी-फाइल और मल्टी-आर्टिफैक्ट परिवर्तनों में फॉल्ट लोकलाइजेशन (दोष स्थानीयकरण) की चुनौतियाँ हैं।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आपके पास अविश्वसनीय रूप से स्मार्ट, सुपर-फास्ट रोबोट्स (लार्ज लैंग्वेज मॉडल्स, या LLMs) की एक टीम है जो कोड लिख सकते हैं। आपने उन्हें साधारण घर (वेब ऐप्स) बनाने और टूटे हुए फर्नीचर (स्टैंडर्ड सॉफ्टवेयर लाइब्रेरी) को ठीक करने के लिए टेस्ट किया है, और उन्होंने इसमें काफी अच्छा प्रदर्शन किया है। वे निर्देशों का पालन कर सकते हैं और एक टपकते हुए नल को ठीक कर सकते हैं या एक बुकशेल्फ़ बना सकते हैं।
लेकिन क्या होगा यदि आप उन रोबोट्स को एक हाई-स्पीड, सेल्फ-ड्राइविंग रेस कार को ठीक करने के लिए कहें जिसे एक विशिष्ट ट्रैक पर नेविगेट करना है जिसमें सख्त नियम, अजीब सेंसर और एक जटिल इंजन है? यही वह चीज़ है जिसके बारे में यह पेपर, MobileDev-Bench, है।
यहाँ इस पेपर की कहानी है, जिसे सरल भागों में विभाजित किया गया है:
1. समस्या: "रेस कार" का अंतर (The "Race Car" Gap)
लेखकों ने महसूस किया कि जबकि AI "घर" की समस्याओं (वेब ऐप्स) को ठीक करने में बहुत अच्छा है, लेकिन किसी ने वास्तव में इसे "रेस कार" की समस्याओं (मोबाइल ऐप्स जैसे कि आपके फोन पर मौजूद ऐप्स) पर टेस्ट नहीं किया था।
मोबाइल ऐप्स पेचीदा होते हैं। वे केवल कोड का एक टुकड़ा नहीं हैं। वे एक स्विस आर्मी नाइफ की तरह हैं जहाँ आपको ब्लेड, हैंडल, पेंच और निर्देश पुस्तिका (manual) सबको एक साथ बदलना पड़ता है, अन्यथा पूरी चीज़ टूट जाएगी।
- पुराने बेंचमार्क्स: एक सिंगल लेगो ब्रिक (Lego brick) पर रोबोट को टेस्ट करने जैसे थे।
- वास्तविक दुनिया: एक पूरे लेगो शहर को फिर से बनाने के लिए रोबोट से पूछने जैसा है जहाँ एक इमारत को बदलने से ट्रैफिक, बिजली ग्रिड और पानी की आपूर्ति भी प्रभावित होती है।
2. समाधान: एक नया टेस्ट ट्रैक बनाना (MobileDev-Bench)
यह देखने के लिए कि क्या ये AI रोबोट वास्तव में वास्तविक मोबाइल ऐप्स को ठीक कर सकते हैं, शोधकर्ताओं ने MobileDev-Bench नामक एक नया, सुपर-डिटेल्ड टेस्ट ट्रैक बनाया।
- स्रोत (The Source): उन्होंने काल्पनिक समस्याएँ नहीं बनाईं। वे 18 वास्तविक, लोकप्रिय मोबाइल ऐप्स (जैसे Thunderbird, WordPress, और Zulip) के पास गए और 384 वास्तविक बग्स (bugs) खोजे जिन्हें वास्तविक इंसानों ने ठीक किया था।
- टेस्ट: उन्होंने ऐप का "पहले वाला" (before) वर्शन लिया, AI को बग रिपोर्ट दी, और AI से उस बग को ठीक करने के लिए कहा। फिर, उन्होंने यह देखने के लिए ऐप के अपने टेस्ट चलाए कि क्या सुधार (fix) वास्तव में काम कर रहा है।
- जटिलता (The Complexity): ये साधारण सुधार नहीं थे। औसतन, एक बग को ठीक करने के लिए 12.5 अलग-अलग फाइलों को बदलने और 325 लाइनों के कोड को बदलने की आवश्यकता थी। कुछ सुधारों के लिए एक साथ सोर्स कोड और ऐप के "आईडी कार्ड" (manifest files) और "निर्देश पुस्तिका" (build files) को बदलने की आवश्यकता थी।
3. परिणाम: रोबोट रास्ता भटक गए
शोधकर्ताओं ने चार सबसे स्मार्ट उपलब्ध AI मॉडल्स का परीक्षण किया (GPT-5.2, Claude, Gemini, और Qwen)। परिणाम आश्चर्यजनक और AI कोडिंग के भविष्य के लिए थोड़े डरावने थे:
- स्कोर: AI मॉडल्स केवल 3.4% से 5.2% बग्स को ही ठीक कर पाए।
- उपमा (The Analogy): कल्पना कीजिए कि आप एक रोबोट को घर में खोई हुई चाबी खोजने के लिए एक नक्शा देते हैं। एक साधारण घर (वेब ऐप) पर, वह 80% बार चाबी ढूंढ लेता है। एक विशाल, बहु-मंजिला हवेली (मोबाइल ऐप) जिसमें गुप्त रास्ते हों, उस पर वह 100 में से केवल 5 बार चाबी ढूंढ पाता है।
4. वे क्यों विफल हुए? "कहाँ" बनाम "कैसे" (The "Where" vs. The "How")
शोधकर्ताओं ने गहराई से जांच की कि रोबोट क्यों विफल हुए। उन्होंने पाया कि समस्या यह नहीं थी कि रोबोट कोड नहीं लिख सकते थे (द "How")। समस्या यह थी कि वे समझ नहीं पा रहे थे कि कहाँ देखना है (द "Where")।
- अवरोध (The Bottleneck): इसे फॉल्ट लोकलाइजेशन (Fault Localization) कहा जाता है।
- एक डॉक्टर की कल्पना करें जो मरीज का इलाज करने की कोशिश कर रहा है। डॉक्टर जानता है कि सर्जरी कैसे करनी है (कोड लिखना), लेकिन वह यह नहीं ढूंढ पाता कि कौन सा अंग बीमार है (बग को लोकेट करना)।
- मोबाइल ऐप्स में, "डिस्प्ले" में एक बग वास्तव में "डेटाबेस" या "सेटिंग्स मेनू" की समस्या के कारण हो सकता है। AI मॉडल्स इन कनेक्शनों से भ्रमित हो गए।
- जब एक सुधार के लिए केवल एक फाइल बदलने की आवश्यकता थी, तो AI ने ठीक-ठाक प्रदर्शन किया (लगभग 15% सफलता)। लेकिन जब एक सुधार के लिए 6 या अधिक फाइलों को बदलने की आवश्यकता थी, तो सफलता दर गिरकर लगभग शून्य हो गई।
5. मुख्य निष्कर्ष (The Big Takeaway)
पेपर इस निष्कर्ष पर पहुँचता है कि हालांकि AI कोड लिखने में बेहतर हो रहा है, लेकिन यह अभी भी मोबाइल ऐप के भीतर कनेक्शन के जटिल जाल को समझने में बहुत खराब है।
- वर्तमान AI: एक अकेला वाक्य लिखने में बहुत अच्छा है।
- मोबाइल ऐप्स: एक पूरा पैराग्राफ लिखने की आवश्यकता होती है जहाँ हर वाक्य दूसरे पर निर्भर करता है, और आपको एक साथ फॉन्ट, कागज और स्याही का रंग भी बदलना पड़ता है।
भविष्य
लेखक कहते हैं कि हमें AI को बेहतर "लेखक" बनाने से पहले उसे एक बेहतर "जासूस" बनाना होगा। हमें AI को यह समझने में मदद करने की आवश्यकता है कि एक मोबाइल ऐप के विभिन्न हिस्से एक-दूसरे से कैसे बात करते हैं (जैसे कि बैटरी, स्क्रीन और इंटरनेट कनेक्शन मिलकर ऐप को कैसे प्रभावित करते हैं)।
तब तक, यदि आप मोबाइल ऐप में बग को ठीक करना चाहते हैं, तो आपको अभी भी एक मानव विशेषज्ञ की आवश्यकता होगी जो AI को सही दिशा दिखा सके। AI एक शक्तिशाली उपकरण है, लेकिन यह अभी अकेले रेस कार चलाने के लिए तैयार नहीं है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।