🤖 AI

HTMLCure: Turning Browser Experience into State Guided Repair for Interactive HTML

HTMLCure एक स्टेट-गाइडेड ब्राउज़र अनुभव फ्रेमवर्क पेश करता है जो नियतात्मक इंटरेक्शन ट्रेजेक्टरीज के माध्यम से इंटरैक्टिव HTML का मूल्यांकन और मरम्मत करता है, जो एक सीड कॉर्पस को एक उच्च-गुणवत्ता वाले डेटासेट में महत्वपूर्ण रूप से विस्तारित करता है जो एक 27B मॉडल को इंटरैक्टिव वेब बेंचमार्क पर Kimi-K2.6 और GPT-5.4 जैसी अग्रणी प्रणालियों के समान प्रदर्शन प्राप्त करने में सक्षम बनाता है।

मूल लेखक: Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

प्रकाशित 2026-05-27

📖 6 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

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

यहाँ HTMLCURE पेपर का स्पष्टीकरण दिया गया है, जिसे सरल अवधारणाओं और रोज़मर्रा के उदाहरणों के माध्यम से समझाया गया है।

बड़ी समस्या: "दिखने में अच्छा, पर काम में बेकार"

कल्पना कीजिए कि आपने एक बहुत ही प्रतिभाशाली कलाकार (एक AI) को एक खिलौना कार बनाने के लिए कहा। कलाकार आपको एक सुंदर मॉडल थमा देता है। फोटो में यह एकदम परफेक्ट दिखता है। लेकिन जब आप इसे चलाने की कोशिश करते हैं, तो इसके पहिए निकल जाते हैं। जब आप स्टीयरिंग घुमाने की कोशिश करते हैं, तो स्टीयरिंग बिना किसी काम के घूमता रहता है।

यह AI द्वारा जनरेट किए गए वेब पेजों (HTML) के साथ वर्तमान समस्या है। वे एक सिंगल स्नैपशॉट (स्क्रीनशॉट) में तो बहुत अच्छे दिखते हैं, लेकिन जब कोई वास्तविक व्यक्ति बटन क्लिक करता है, नीचे स्क्रॉल करता है, विंडो का आकार बदलता है, या कोई गेम खेलता है, तो पेज टूट जाता है।

पुराना तरीका: शोधकर्ता पहले पेज की एक फोटो लेते थे, यह देखते थे कि वह दिखने में कैसा है, और तय करते थे कि वह "अच्छा" है या नहीं। इसमें "टूटे हुए पहियों" वाली बात छूट जाती थी।
परिणाम: उन्होंने हज़ारों ऐसे पेजों को फेंक दिया जो वास्तव में ठीक किए जा सकते थे, या ऐसे पेजों को रख लिया जो दिखने में तो अच्छे थे पर काम नहीं कर रहे थे।

समाधान: HTMLCURE (द "टेस्ट ड्राइव" मैकेनिक)

लेखकों ने HTMLCURE नामक एक सिस्टम बनाया है। केवल फोटो देखने के बजाय, HTMLCURE एक मैकेनिक की तरह काम करता है जो कार की टेस्ट ड्राइव (परीक्षण सवारी) लेता है।

यह इस प्रकार काम करता है, चरण-दर-चरण:

1. टेस्ट ड्राइव (ब्राउज़र अनुभव)

केवल एक तस्वीर लेने के बजाय, HTMLCURE एक वास्तविक ब्राउज़र में वेब पेज को लोड करता है। यह केवल वहाँ बैठा नहीं रहता; यह सक्रिय रूप से इसके साथ इंटरैक्ट करता है:

यह ऊपर और नीचे स्क्रॉल करता है।
यह विंडो का आकार बदलता है (जैसे यह देखना कि क्या कार एक छोटे गैरेज में फिट आती है)।
यह बटन क्लिक करता है, लिंक्स पर माउस ले जाता है, और गेम खेलने की कोशिश करता है।
यह रिकॉर्ड करता है कि वास्तव में क्या हुआ: "बटन काम नहीं किया," "गेम फ्रीज हो गया," या "मोबाइल पर लेआउट बिगड़ गया।"

उपमा: इसे एक कार के लिए ड्राइविंग टेस्ट की तरह समझें। आप केवल पेंट जॉब नहीं देखते; आप कार चलाते हैं ताकि यह देख सकें कि इंजन शुरू होता है या नहीं, ब्रेक काम करते हैं या नहीं, और ट्रांसमिशन सुचारू रूप से बदलता है या नहीं।

2. निदान (स्टेट सिग्नल)

टेस्ट ड्राइव के बाद, सिस्टम पेज को एक "हेल्थ स्कोर" और एक निदान (डायग्नोसिस) देता है। यह पेज को तीन समूहों में वर्गीकृत करता है, जैसे एक डॉक्टर मरीजों की जांच करता है:

लो स्कोर (कबाड़/The Wreck): पेज पूरी तरह अस्त-व्यस्त है। इसकी संरचना के बड़े हिस्से गायब हैं।
- समाधान: पूर्ण पुनर्लेखन (Total Rewrite)। इसे पैच करने की कोशिश न करें; शून्य से एक नई कार बनाएं।
मिड स्कोर (खटारा/The Clcler): पेज ज्यादातर काम करता है, लेकिन इसके कुछ विशिष्ट हिस्से खराब हैं (जैसे, रेडियो काम नहीं कर रहा है, या दरवाज़े का हैंडल अटक गया है)।
- समाधान: लक्षित मरम्मत (Targeted Repair)। विशिष्ट खराब हिस्से का निदान करें और केवल उसे ही ठीक करें।
हाई स्कोर (स्पोर्ट्स कार/The Sports Car): पेज पहले से ही बहुत बढ़िया है।
- समाधान: केवल पॉलिश (Polish Only)। इंजन को हाथ न लगाएं; शायद बस पेंट पर वैक्स लगा दें। यदि आप किसी ऐसी चीज़ को "ठीक" करने की कोशिश करते हैं जो खराब नहीं है, तो आप उसे बिगाड़ सकते हैं।

मुख्य अंतर्दृष्टि: पेपर का दावा है कि सभी पेजों के लिए एक ही मरम्मत विधि का उपयोग करना एक गलती है। पेज वास्तव में कितना टूटा हुआ है, इसके आधार पर आपको अलग रणनीति की आवश्यकता होती है।

3. रिपेयर लूप (फीडबैक चक्र)

एक बार जब सिस्टम रणनीति (Rewrite, Patch, या Polish) चुन लेता है, तो यह AI से पेज को ठीक करने के लिए कहता है।

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

उपमा: कल्पना कीजिए कि एक शेफ सूप चख रहा है। यदि यह बहुत नमकीन है, तो वह पानी डालता है। फिर वह फिर से चखता है। वह यह मानकर नहीं चलता कि पानी ने इसे ठीक कर दिया है; वह इसे सत्यापित करता है। यदि वह बहुत अधिक पानी डाल देता है और अब सूप बेस्वाद हो जाता है, तो वह रुक जाता है और एक अलग रेसिपी आज़माता है।

परिणाम: एक बेहतर लाइब्रेरी बनाना

लेखकों ने इस सिस्टम का उपयोग 97,000 AI-जनरेटेड पेजों के एक विशाल संग्रह पर किया।

उन्होंने "परफेक्ट" पेजों के एक छोटे ढेर से शुरुआत की।
उन्होंने "टूटे हुए" पेजों को ठीक करने के लिए HTMLCURE का उपयोग किया।
अंत में उनके पास 63,000 उच्च-गुणवत्ता वाले, सत्यापित पेज (मूल सेट से अधिक) थे।

इसके बाद उन्होंने इस नई, साफ की गई लाइब्रेरी का उपयोग एक नए AI मॉडल (जिसे HTMLCure-27B कहा जाता है) को प्रशिक्षित करने के लिए किया।

परिणाम:

नया मॉडल वेब पेज बनाने में काफी बेहतर है।
इसने एक सख्त टेस्ट (HTMLBENCH) पर 50.6 स्कोर किया, जो शीर्ष-स्तरीय कमर्शियल मॉडल्स (जैसे Kimi-K2.6 और GPT-5.4) के बराबर है।
एक अन्य टेस्ट (MiniAppBench) पर, इसने अनट्रेन्ड वर्जन की तुलना में 15 अंक का सुधार किया।

एक वाक्य में सारांश

HTMLCURE एक ऐसा सिस्टम है जो AI को केवल यह "अनुमान" लगाने से रोकता है कि वेब पेज काम करेगा; इसके बजाय, यह AI को हर पेज की टेस्ट ड्राइव लेने, सटीक रूप से निदान करने कि क्या टूटा है, सही रणनीति का उपयोग करके मरम्मत करने, और यह सुनिश्चित करने के लिए पुनः परीक्षण करने के लिए मजबूर करता है कि सुधार वास्तव में काम कर गया है, जिससे उच्च-गुणवत्ता वाले, काम करने वाले कोड की एक विशाल लाइब्रेरी तैयार होती है।

तकनीकी सारांश: HTMLCure

समस्या विवरण

लार्ज लैंग्वेज मॉडल्स (LLMs) ने पूर्ण HTML पेज उत्पन्न करने की क्षमता प्रदर्शित की है, लेकिन इनके आउटपुट अक्सर "सतही शुद्धता" (superficial correctness) की समस्या से ग्रस्त होते हैं। जबकि एक उत्पन्न पेज एकल स्थिर स्क्रीनशॉट में सही ढंग से रेंडर हो सकता है, यह अक्सर स्क्रॉलिंग, होवरिंग, क्लिकिंग, रिसाइजिंग या गेमप्ले जैसी गतिशील स्थितियों के तहत विफल हो जाता है। पारंपरिक मूल्यांकन विधियाँ जो स्थिर स्क्रीनशॉट या विरल विजुअल ट्रेसेस पर निर्भर करती हैं, वे इन इंटरैक्शन-विशिष्ट विफलताओं को पकड़ने में विफल रहती हैं। इसके अलावा, मानक डेटा फ़िल्टरिंग दृष्टिकोण कई ऐसे पेजों को अनुपयोगी मानकर त्याग देते हैं, यह पहचानने में विफल रहते हैं कि वे अक्सर मरम्मत योग्य (repairable) होते हैं। पहचाना गया मुख्य संकट यह है कि इंटरैक्टिव HTML के लिए डेटा निर्माण एक स्टेट एस्टीमेशन (state estimation) समस्या है, न कि केवल एक स्कोरिंग समस्या; स्थिर अवलोकन उन विफलताओं को प्रकट नहीं कर सकते जो विशिष्ट उपयोगकर्ता इंटरैक्शन के बाद ही सामने आती हैं।

कार्यप्रणाली (Methodology)

यह शोध पत्र HTMLCURE पेश करता है, जो एक ब्राउज़र अनुभव फ्रेमवर्क है जिसे ब्राउज़र निष्पादन ट्रेसेस (execution traces) द्वारा संचालित एक क्लोज्ड-लूप प्रक्रिया के माध्यम से इंटरैक्टिव HTML का मूल्यांकन, निदान और मरम्मत करने के लिए डिज़ाइन किया गया है।

1. बहु-आयामी अनुभवात्मक मूल्यांकन पाइपलाइन

स्थिर स्क्रीनशॉट पर निर्भर रहने के बजाय, HTMLCURE एक HTML आर्टिफैक्ट ( $h$ ) का मूल्यांकन देखने और इंटरैक्शन क्रियाओं ( $\pi$ ) के एक अनुक्रम को निष्पादित करके करता है।

चार-स्तरीय अनुभव प्रोटोकॉल:
- L1 (विजुअल ऑब्जर्व): लोडिंग व्यवहार और प्रारंभिक रेंडरिंग की जाँच करता है।
- L2 (एक्टिव इंटरैक्ट): कंट्रोल्स, होवर स्टेट्स, कीबोर्ड बाइंडिंग्स और स्क्रॉल व्यवहार का परीक्षण करता है।
- L3 (डीप गेमप्ले): गेम्स या जटिल UIs के लिए टास्क-ड्रिवन रोलआउट चलाता है ताकि स्टेट ट्रांजिशन, काउंटर्स और कैनवस परिवर्तनों को सत्यापित किया जा सके।
- L4 (रिस्पॉन्सिव): इवेंट कॉन्टेक्स्ट के साथ निष्पादन प्रक्षेपवक्र (execution trajectory) से प्रतिनिधि कीफ्रेम्स का चयन करता है।
संरचित साक्ष्य (Structured Evidence): इवैल्यूएटर एक क्रमित ट्रेस $E(h, \pi)$ उत्पन्न करता है जिसमें विजुअल साक्ष्य ( $v_t$ , जैसे रेंडर किए गए फ्रेम्स) और व्यवहारिक साक्ष्य ( $b_t$ , जैसे DOM स्टेट, कंसोल एरर, प्रोब परिणाम) शामिल होते हैं।
पांच-घटक स्कोरिंग: एक स्कोर $S(h)$ पांच आयामों से प्राप्त किया जाता है: रेंडरिंग, विजुअल डिज़ाइन, फंक्शनलिटी, इंटरैक्टिविटी और कोड क्वालिटी। महत्वपूर्ण रूप से, विजुअल डिज़ाइन एकमात्र ऐसा घटक है जिसे क्यूरेटेड कीफ्रेम्स के आधार पर विजन-लैंग्वेज मॉडल (VLM) द्वारा आंका जाता है; अन्य सभी आयाम नियत (deterministic) ब्राउज़र निष्पादन और स्टैटिक विश्लेषण पर निर्भर करते हैं।

2. स्टेट-अवेयर इंटरैक्टिव रिपेयर इंजन

मरम्मत की प्रक्रिया एक जेनेरिक पुनर्जन्म नहीं है, बल्कि पेज की वर्तमान स्थिति के आधार पर एक नियंत्रित हस्तक्षेप है।

स्टेट रूटिंग: सिस्टम स्कोर $s$ $s$ के आधार पर पेजों को तीन अवस्थाओं में वर्गीकृत करता है:
- लो (< 40): वे पेज जिनका कोई स्थिर स्थानीय लक्ष्य नहीं है। रणनीति: होलिस्टिक रीराइट (Holistic Rewrite)।
- मिड (40–79): वे पेज जिनका ढांचा उपयोगी है लेकिन व्यवहार टूटा हुआ है। रणनीति: डायग्नोसिस-गाइडेड लोकल रिपेयर (जैसे विशिष्ट इंटरैक्शन बग्स को ठीक करना)।
- हाई (≥ 80): मजबूत पेज। रणनीति: रिग्रेशन से बचने के लिए प्रिजर्वेशन (Preservation) या टारगेटेड रिफाइनमेंट।
क्लोज्ड-लूप निष्पादन: कंट्रोलर एक रिपेयर फैमिली चुनता है, LLM से उम्मीदवारों (candidates) के लिए प्रॉम्प्ट लेता है, और प्रत्येक उम्मीदवार को ब्राउज़र में पुनः निष्पादित करता है।
रिग्रेशन-अवेयर एक्सेप्टेंस: उम्मीदवारों का चयन एक कंपोजिट स्कोर $S_{comp}$ का उपयोग करके किया जाता है जो फंक्शनलिटी और इंटरैक्टिविटी में रिग्रेशन को दंडित करता है, यह सुनिश्चित करता है कि विजुअल डिज़ाइन में सुधार फंक्शनल लॉजिक के टूटने की कीमत पर न हो।
समाप्ति (Termination): लूप तब रुकता है जब पेज एक उच्च लक्षित स्कोर (≥ 97) तक पहुँच जाता है, प्लेटो (plateau) प्राप्त करता है, या राउंड बजट समाप्त हो जाता है।

3. डेटा निर्माण

HTMLCURE मरम्मत को एक डेटा निर्माण तंत्र के रूप में मानता है। प्रारंभिक 97K प्रॉम्प्ट कॉर्पस से स्वीकृत मरम्मत को एक परिष्कृत सुपरवाइज्ड फाइन-ट्यूनिंग (SFT) पूल में निर्यात किया जाता है। यह प्रक्रिया उपयोगी डेटासेट को "हाई" पेजों के एक छोटे उपसमुच्चय से बढ़ाकर 63,003 गुणवत्ता-सत्यापित पेजों के एक बड़े पूल तक विस्तृत करती है, जिससे अंतिम 40K प्रशिक्षण सेट बनाया जाता है।

मुख्य योगदान

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

परिणाम

लेखकों ने HTMLBENCH-400, जो एक नियत (deterministic) ब्राउज़र-एक्सेक्यूटेबल बेंचमार्क है, और MiniAppBench वैलिडेशन स्प्लिट का उपयोग करके कार्यप्रणाली का मूल्यांकन किया।

प्रदर्शन: समान बैकबोन (Qwen3.5) और ट्रेनिंग रेसिपी के तहत, HTMLCure-27B-Refined मॉडल ने प्राप्त किया:
- HTMLBENCH-400 पर 50.6 (टोटल स्कोर)।
- 45.2% नियत टेस्ट केस पास रेट।
- MiniAppBench वैलिडेशन स्प्लिट पर 81.2 औसत।
तुलना: ये परिणाम मॉडल को Kimi-K2.6 जैसे मजबूत रेफरेंस सिस्टम के समान प्रदर्शन बैंड में रखते हैं।
एब्लेशन (Ablation): समान डेटा आकार (12,392 उदाहरण) के साथ नियंत्रित प्रयोगों ने पुष्टि की कि "रिफाइंड" मार्ग (मरम्मत किए गए, सत्यापित डेटा का उपयोग करके) "रॉ" (मूल जनरेशन) और "फिल्टर्ड" (केवल मूल उच्च-गुणवत्ता वाले पेज) दोनों मार्गों से बेहतर प्रदर्शन करता है, जो यह सिद्ध करता है कि सुधार का प्राथमिक चालक डेटा वॉल्यूम नहीं, बल्कि ब्राउज़र अनुभव से प्राप्त सुपरविजन की गुणवत्ता है।

महत्व और दावे

शोध पत्र दावा करता है कि HTMLCURE इंटरैक्टिव HTML जनरेशन के प्रतिमान को "जेनरेट एंड फिल्टर" से बदलकर "एक्सपीरियंस, रिपेयर एंड वेरीफाई" कर देता है।

नियंत्रण के रूप में निष्पादन: केंद्रीय दावा यह है कि ब्राउज़र निष्पादन का उपयोग केवल अंतिम पास/फेल जज के रूप में नहीं, बल्कि एक निरंतर नियंत्रण सिग्नल के रूप में किया जाना चाहिए जो मिसिंग स्ट्रक्चर को टूटे हुए इंटरैक्शन से अलग करता है।
डेटा गुणवत्ता: कार्य यह प्रदर्शित करता है कि स्टेट-विशिष्ट नियंत्रण के तहत कमजोर और आंशिक पेजों की मरम्मत करना, केवल पूर्व-मौजूद उच्च-गुणवत्ता वाले पेजों को चुनने की तुलना में SFT के लिए मजबूत सुपरविजन प्रदान करता है।
पुनरुत्पादकता (Reproducibility): लेखक एक फ्रोजन बेंचमार्क (HTMLBENCH) प्रदान करते हैं जिसमें नियत टेस्ट केस और तुलना के लिए एक पूर्ण पाइपलाइन है, जो एजेंट-आधारित मूल्यांकन से आगे बढ़ता है जिनमें मानकीकृत विफलता रिकॉर्ड का अभाव होता है।

शोध पत्र अपनी सीमाओं के संबंध में विनम्र बना हुआ है, यह स्वीकार करता है कि बाउंडेड विजुअल डिज़ाइन स्कोरिंग के लिए अभी भी VLM की आवश्यकता है, ब्राउज़र प्रोब्स हर संभावित इंटरैक्शन को कवर नहीं कर सकते हैं, और जटिल गेम्स कपल्ड टाइमिंग विफलताओं को उजागर कर सकते हैं। यह सुझाव देता है कि भविष्य के कार्य में सीधे रिपेयर ट्रेसेस से रूटिंग और स्टॉपिंग पॉलिसी सीखना शामिल हो सकता है।