VISTA: An End-to-End Benchmark for Visual Spec-to-Web-App Coding Agents
यह शोधपत्र VISTA को प्रस्तुत करता है, जो एक व्यापक बेंचमार्क है जिसे विज़ुअल विनिर्देशों (visual specifications) से एंड-टू-एंड वेब एप्लिकेशन जनरेशन पर LLM-आधारित एजेंटों का मूल्यांकन करने के लिए डिज़ाइन किया गया है, जो विविध प्रॉम्प्ट स्थितियों को परिभाषित करता है और एक बहुआयामी मूल्यांकन ढांचे का उपयोग करता है जो पारंपरिक स्क्रिप्ट-आधारित उपकरणों की सीमाओं को दूर करने के लिए DOM मिलान, व्यवहारिक परीक्षण और दृश्य समानता (visual similarity) को संयोजित करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक कस्टम घर बनाने के लिए रोबोट आर्किटेक्ट्स की एक टीम को काम पर रख रहे हैं, जिसका आधार आपके द्वारा नैपकिन पर बनाया गया एक स्केच है। कुछ आर्किटेक्ट्स घर को बिल्कुल आपके स्केच जैसा दिखने के लिए बेहतरीन चित्र बनाने में माहिर हैं, लेकिन उनके दरवाज़े खुलते नहीं हैं। अन्य लोग एक ऐसा घर बनाते हैं जो पूरी तरह से काम करता है (लाइटें जलती हैं, दरवाज़े लॉक होते हैं), लेकिन वह आपके ड्राइंग जैसा बिल्कुल भी नहीं दिखता।
VISTA एक नया "टेस्ट ड्राइव" है यह देखने के लिए कि AI कोडिंग एजेंट यह कितनी अच्छी तरह से देख सकते हैं कि शून्य से डिजिटल घर (वेबसाइट) कैसे बनाए जाते हैं, न कि केवल कोड की एक एकल पंक्ति कैसे लिखी जाती है।
यहाँ सरल उपमाओं का उपयोग करके पेपर का विवरण दिया गया है:
1. समस्या: "नैपकिन स्केच" का अंतर (The "Napkin Sketch" Gap)
AI कोडर्स के पिछले परीक्षण ऐसे थे जैसे उन्हें गणित के सवाल हल करने या इंजन के एक टूटे हुए हिस्से को ठीक करने के लिए कहना। लेकिन एक वास्तविक वेबसाइट बनाना अलग है। आप AI को एक टेक्स्ट विवरण, एक फोटो जिसे आप पसंद करते हैं, या एक विस्तृत डिज़ाइन फ़ाइल (जैसे ब्लूप्रिंट) दे सकते हैं।
- अंतर: वर्तमान परीक्षण यह जांचने में विफल रहे कि क्या AI पूरे ऐप बनाने की जटिल वास्तविकता को संभाल सकता है, सही उपकरणों का चुनाव कर सकता है (जैसे विभिन्न निर्माण सामग्री के बीच चयन करना), या जब निर्माण प्रक्रिया गलत हो जाए तो गलतियों को सुधार सकता है।
2. समाधान: VISTA टेस्ट
लेखकों ने VISTA (विजुअल स्पेक-टू-ऐप बेंचमार्क) बनाया है। इसे एक कठोर निर्माण चुनौती के रूप में समझें जिसमें 10 अलग-अलग प्रकार की इमारतें बनानी हैं (जैसे एक ट्रैवल बुकिंग साइट, एक म्यूजिक प्लेयर, या एक जॉब बोर्ड)।
उन्होंने AI को पाँच अलग-अलग स्तरों की "मदद" के तहत परखा ताकि यह देखा जा सके कि AI को सफल होने के लिए कितनी जानकारी की आवश्यकता है:
- स्तर 1 (नैपकिन): केवल एक टेक्स्ट विवरण। AI को टूल्स और लुक का अनुमान लगाना होगा।
- स्तर 2 (फोटो + फिक्स्ड टूल्स): एक टेक्स्ट विवरण + लक्ष्य की एक फोटो, लेकिन AI को विशिष्ट निर्माण उपकरणों का उपयोग करना ही होगा (जैसे, "आपको React का उपयोग करना चाहिए")।
- स्तर 3 (फोटो + फ्री टूल्स): एक टेक्स्ट विवरण + एक फोटो, लेकिन AI अपने टूल्स खुद चुन सकता है।
- स्तर 4 (ब्लूप्रिंट + फिक्स्ड टूल्स): टेक्स्ट + फोटो + एक विस्तृत डिजिटल ब्लूप्रिंट (Figma), लेकिन AI को विशिष्ट टूल्स का उपयोग करना होगा।
- स्तर 5 (ब्लूप्रिंट + फ्री टूल्स): पूरा पैकेज: टेक्स्ट + फोटो + ब्लूप्रिंट, और AI अपने टूल्स खुद चुन सकता है।
3. ग्रेडिंग सिस्टम: हमें कैसे पता चलेगा कि उन्होंने कैसा काम किया?
यह इस पेपर का सबसे रचनात्मक हिस्सा है। लेखकों ने महसूस किया कि मानक कंप्यूटर परीक्षण (जैसे यह जांचना कि बटन क्लिक होता है या नहीं) अक्सर विफल हो जाते हैं क्योंकि वे बहुत कठोर होते हैं। इसलिए, उन्होंने एक "ह्यूमन-इन-द-लूप" ग्रेडिंग सिस्टम बनाया:
- "मानवीय एनोटेटर्स" (The Human Annotators): वास्तविक मनुष्यों ने डिजाइनों को देखा और चिह्नित किया कि बटन, लिंक और मेनू कहाँ होने चाहिए। उन्होंने "लैंडमार्क्स" (जैसे सर्च बार या चेकआउट बटन) को संदर्भ बिंदुओं के रूप में भी चुना।
- "DOM ग्राउंडेड इवैल्यूएटर" (The DOM Grounded Evaluator): यह एक स्मार्ट रोबोट जज है। यह केवल एक तस्वीर नहीं देखता; यह वेबसाइट के कोड (DOM) के अंदर देखता है।
- चरण 1 (स्थान): यह जाँचता है: "क्या 'सर्च' बटन वास्तव में वहाँ है, और क्या वह सही जगह पर है?"
- चरण 2 (व्यवहार): यह जाँचता है: "यदि मैं उस बटन पर क्लिक करता हूँ, तो क्या वह वास्तव में सर्च करता है?"
- चरण 3 (विजुअल्स): यह एक "विजुअल सिमिलैरिटी" टूल (एक सुपर-स्मार्ट आँख की तरह) का उपयोग करता है यह देखने के लिए कि क्या अंतिम निर्माण मूल ब्लूप्रिंट जैसा दिखता है, भले ही पिक्सेल बिल्कुल समान न हों।
4. उन्होंने क्या पाया: "दिखावट बनाम कार्यक्षमता" का ट्रेड-ऑफ (The "Look vs. Work" Trade-off)
जब उन्होंने चार अलग-अलग AI सिस्टम का परीक्षण किया, तो उन्हें कुछ आश्चर्यजनक बातें पता चलीं:
"सुंदर लेकिन टूटा हुआ" बनाम "बदसूरत लेकिन काम करने वाला" दुविधा:
- एक AI (GPT-5.5) फोटो की तरह वेबसाइट को बिल्कुल वैसा ही दिखाने में अद्भुत था (उच्च विजुअल स्कोर), लेकिन बटन अक्सर काम नहीं करते थे (कम फंक्शनल स्कोर)।
- दूसरे AI (Claude Opus) ने ऐसी वेबसाइट बनाई जो पूरी तरह से काम करती थी (उच्च फंक्शनल स्कोर), लेकिन वे मूल फोटो की तरह बिल्कुल नहीं दिखती थीं।
- सबक: एक वेबसाइट को अच्छा दिखाना और उसे काम करवाना दो अलग-अलग कौशल हैं। एक AI किसी एक में बहुत अच्छा हो सकता है और दूसरे में खराब।
स्वतंत्रता ही कुंजी है:
- AI का प्रदर्शन सबसे अच्छा रहा जब उसे अपने टूल्स चुनने की आजादी दी गई ("फ्री स्टैक" की स्थिति में)। जब परीक्षण ने AI को विशिष्ट, संभावित रूप से कठिन टूल्स का उपयोग करने के लिए मजबूर किया, तो गुणवत्ता गिर गई। यह एक बढ़ई को केवल हथौड़े का उपयोग करके घर बनाने के लिए मजबूर करने जैसा है जब वास्तव में उसे आरी की आवश्यकता होती है।
"सर्जिकल" बनाम "डेमोलिशन" शैली:
- शोधकर्ताओं ने ट्रैक किया कि AI कोड को कैसे एडिट करता है।
- कुछ AI "सर्जन" (Surgeons) थे: वे समस्याओं को ठीक करने के लिए छोटे, सटीक कट और पैच लगाते थे।
- अन्य "डेमोलिशन क्रू" (Demolition Crews) थे: वे कोड के बड़े हिस्से को हटा देते थे और पूरी फ़ाइल को शुरू से फिर से लिखते थे।
- ट्विस्ट: "सर्जन" होना जरूरी नहीं कि AI को बेहतर घर बनाने में मदद करे। "डेमोलिशन क्रू" (Claude Opus) ने सबसे कार्यात्मक ऐप्स बनाए, भले ही वे लगातार फ़ाइलों को फिर से लिख रहे थे। "सावधानी से संपादन करने" और "एक अच्छा ऐप बनाने" के बीच कोई सीधा संबंध नहीं था।
5. यह क्यों मायने रखता है
VISTA केवल एक परीक्षण नहीं है; यह एक नया मानक है। यह साबित करता है कि AI कोडर्स को वास्तव में परखने के लिए, हम केवल उनसे कोड लिखने के लिए नहीं कह सकते। हमें यह देखना होगा कि क्या वे:
- एक विजुअल डिज़ाइन को समझ सकते हैं।
- सही टूल्स चुन सकते हैं।
- एक काम करने वाला उत्पाद बना सकते हैं।
- अपनी गलतियों को सुधार सकते हैं।
पेपर निष्कर्ष निकालता है कि हमें AI को एक साधारण कोड जनरेटर के रूप में मानना बंद करना होगा और इसे एक पूर्ण सॉफ्टवेयर इंजीनियर के रूप में मानना शुरू करना होगा जिसे ब्लूप्रिंट से लेकर अंतिम निरीक्षण तक पूरी निर्माण प्रक्रिया को प्रबंधित करने की आवश्यकता है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।