ملخص تقني: HTMLCure

بيان المشكلة

أظهرت النماذج اللغوية الكبيرة (LLMs) قدرة على توليد صفحات HTML كاملة، لكن مخرجاتها غالبًا ما تعاني من مشكلة "الصحة السطحية". فبينما قد تظهر الصفحة المولدة بشكل صحيح في لقطة شاشة ثابتة واحدة، إلا أنها كثيرًا ما تفشل تحت الظروف الديناميكية مثل التمرير، أو التحويم (hovering)، أو النقر، أو تغيير الحجم، أو اللعب. وتفتقر طرق التقييم التقليدية التي تعتمد على لقطات الشاشة الثابتة أو الآثار البصرية المتفرقة إلى رصد حالات الفشل المرتبطة بالتفاعل هذه. علاوة على ذلك، فإن مناهج تصفية البيانات القياسية تستبعد العديد من هذه الصفحات باعتبارها غير صالحة، وتفشل في إدراك أنها غالبًا ما تكون قابلة للإصلاح. وتتمثل المشكلة الجوهرية المحددة في أن بناء البيانات للـ HTML التفاعلي هو مشكلة تقدير حالة وليس مجرد مشكلة تسجيل درجات؛ فالأرصاد الثابتة لا يمكنها كشف الإخفاقات التي لا تظهر إلا بعد تفاعلات محددة من المستخدم.

المنهجية

يقدم البحث HTMLCURE، وهو إطار عمل لتجربة المتصفح مصمم لتقييم وتشخيص وإصلاح HTML التفاعلي من خلال عملية مغلقة الحلقة مدفوعة بآثار تنفيذ المتصفح.

1. خط أنابيب تقييم التجربة متعدد الأبعاد

بدلاً من الاعتماد على لقطات الشاشة الثابتة، يقوم HTMLCURE بتقييم منتج HTML ($h$) عبر تنفيذ تسلسل من إجراءات العرض والتفاعل ($\pi$).

• بروتوكول تجربة رباعي الطبقات:
  • L1 (الملاحظة البصرية): يتحقق من سلوك التحميل والتقديم الأولي.
  • L2 (التفاعل النشط): يختبر عناصر التحكم، وحالات التحويم، وربط لوحة المفاتيح، وسلوك التمرير.
  • L3 (اللعب العميق): يشغل عمليات تشغيل مدفوعة بالمهام للألعاب أو واجهات المستخدم المعقدة للتحقق من انتقالات الحالة، والعدادات، وتغييرات الـ Canvas.
  • L4 (الاستجابة): يختار إطارات رئيسية ممثلة لمسار التنفيذ مع سياق الحدث.
• الأدلة المهيكلة: ينتج المقيم أثرًا مرتبًا $E(h, \pi)$ يحتوي على أدلة بصرية ($v_t$، مثل الإطارات المُقدمة) وأدلة سلوكية ($b_t$، مثل حالة DOM، أخطاء الكونسول، ونتائج الاختبارات).
• تسجيل مكون من خمسة عناصر: يتم اشتقاق درجة $S(h)$ من خمسة أبعاد: التقديم (Rendering)، التصميم البصري، الوظيفية، التفاعلية، وجودة الكود. ومن الأهمية بمكان أن التصميم البصري هو المكون الوحيد الذي يتم الحكم عليه بواسطة نموذج لغة رؤية (VLM) بناءً على إطارات رئيسية مختارة؛ بينما تعتمد جميع الأبعاد الأخرى على تنفيذ المتصفح الحتمي والتحليل الساكن.

2. محرك الإصلاح التفاعلي المدرك للحالة

عملية الإصلاح ليست إعادة توليد عامة بل هي تدخل محكم بناءً على الحالة الحالية للصفحة.

• توجيه الحالة: يصنف النظام الصفحات إلى ثلاث حالات بناءً على درجتها $s$:
  • منخفضة (< 40): صفحات تفتقر إلى هدف محلي مستقر. الاستراتيجية: إعادة كتابة شاملة.
  • متوسطة (40–79): صفحات ذات بنية قابلة للاستخدام ولكن سلوكها معطل. الاستراتيجية: إصلاح محلي موجه بالتشخيص (مثل إصلاح أخطاء تفاعل محددة).
  • عالية (≥ 80): صفحات قوية. الاستراتيجية: الحفاظ عليها أو التحسين المستهدف لتجنب التراجع.
• التنفيذ مغلق الحلقة: يختار المتحكم عائلة الإصلاح، ويطلب من النموذج اللغوي الكبير (LLM) مرشحين، ثم يعيد تنفيذ كل مرشح في المتصفح.
• القبول الواعي بالتراجع: يتم اختيار المرشحين باستخدام درجة مركبة $S_{comp}$ تفرض عقوبة على التراجع في الوظيفية والتفاعلية، مما يضمن أن التحسينات في التصميم البصري لا تأتي على حساب المنطق المعطل.
• الإنهاء: تتوقف الحلقة عندما تصل الصفحة إلى درجة مستهدفة عالية (≥ 97)، أو تصل إلى مرحلة الثبات، أو استنفاد ميزانية الجولات.

3. بناء البيانات

يعامل HTMLCURE الإصلاح كآلية لبناء البيانات. يتم تصدير الإصلاحات المقبولة من مجموعة مطالبات الـ 97 ألف إلى مجموعة تدريب التوجيه الفائق (SFT) المنقحة. تعمل هذه العملية على توسيع مجموعة البيانات القابلة للاستخدام من مجموعة صغيرة من الصفحات "العالية" إلى مجموعة أكبر تضم 63,703 صفحة تم التحقق من جودتها، ومنها يتم بناء مجموعة تدريب نهائية مكونة من 40 ألف صفحة.

المساهمات الرئيسية

1. تجربة المتصفح كإشارة حالة للإصلاح: يوضح البحث أن تحويل آثار تنفيذ المتصفح إلى حالات صفحات مهيكلة يسمح بتحديد دقيق للحكم البصري لنموذج اللغة الرؤيوي (VLM) ويدفع قرارات إصلاح محددة.
2. الإصلاح التفاعلي المدرك للحالة: يقدم الإطار سياسة يتم فيها اختيار استراتيجية الإصلاح (إعادة كتابة مقابل تشخيص مقابل حفظ) ديناميكيًا بناءً على الحالة الملحوظة للصفحة. هذا يمنع تدمير المكونات العاملة في الصفحات عالية الجودة ويضمن إعادة البناء الهيكلي للصفحات منخفضة الجودة.
3. الإصلاح كبناء للبيانات: من خلال التحقق من الإصلاحات عبر إعادة التنفيذ، ينشئ النظام مجموعة بيانات SFT عالية الجودة ومحققة. يحول هذا النهج نموذج "التصفية" (استبعاد الصفحات السيئة) إلى نموذج "الاسترداد" (إصلاح وتحقق الصفحات).

النتائج

قيم المؤلفون المنهجية باستخدام HTMLBENCH-400، وهو معيار قابل للتنفيذ في المتصفح بشكل حتمي، وجزء التحقق من MiniAppBench.

• الأداء: تحت نفس النموذج الأساسي (Qwen3.5) ووصفة التدريب، حقق نموذج HTMLCure-27B-Refined:
  • 50.6 في HTMLBENCH-400 (الدرجة الإجمالية).
  • 45.2% معدل اجتياز حالات الاختبار الحتمية.
  • 81.2 في متوسط تقسيم التحقق من MiniAppBench.
• المقارنات: تضع هذه النتيات النموذج في نفس نطاق الأداء للأنظمة المرجعية القوية مثل Kimi-K2.6 و GPT-5.4.
• الدراسة الاستبعادية (Ablation): أكدت التجارب المنضبطة مع أحجام بيانات متساوية (12,392 مثالاً) أن مسار "المنقح" (باستخدام بيانات مُصلحة ومحققة) يتفوق على كل من مساري "الخام" (التوليدات الأصلية) و"المصفى" (الصفحات عالية الجودة الأصلية فقط)، مما يثبت أن جودة الإشراف المستمدة من تجربة المتصفح هي المحرك الرئيسي للتحسن، وليس مجرد حجم البيانات.

الأهمية والادعاءات

يزعم البحث أن HTMLCURE ينقل النموذج من "التوليد والتصفية" إلى "التجربة، الإصلاح، والتحقق".

• التنفيذ كتحكم: الادعاء المركزي هو أنه لا ينبغي استخدام تنفيذ المتصفح مجرد حكم نهائي (نجاح/فشل)، بل كإشارة تحكم مستمرة تفصل بين البنية المفقودة والتفاعل المعطل.
• جودة البيانات: يوضح العمل أن إصلاح الصفحات الضعيفة والجزئية تحت تحكم محدد الحالة يؤدي إلى إشراف أقوى لـ SFT مقارنة بمجرد اختيار الصفحات عالية الجودة الموجودة مسبقًا.
• قابلية التكرار: يوفر المؤلفون معيارًا مجمدًا (HTMLBENCH) مع حالات اختبار حتمية ومسار كامل للمقارنة القابلة للتكرار، متجاوزين التقييمات القائمة على الوكلاء (agents) التي تفتقر إلى سجلات فشل معيارية.

يبقى البحث متواضعًا فيما يتعلق بحدوده، حيث يقر بأن نموذج اللغة الرؤيوي (VLM) لا يزال مطلوبًا لتقييم التصميم البصري المحدود، وأن اختبارات المتصفح لا يمكنها تغطية كل التفاعلات الممكنة، وأن الألعاب المعقدة قد تكشف عن إخفاقات زمنية مترابطة. ويقترح أعمالًا مستقبلية قد تتضمن تعلم سياسات التوجيه والتوقف مباشرة من آثار الإصلاح.