Résumé technique : HTMLCure

Énoncé du problème

Les modèles de langage de grande taille (LLM) ont démontré leur capacité à générer des pages HTML complètes, mais ces sorties souffrent souvent d'un problème de « justesse superficielle ». Bien qu'une page générée puisse s'afficher correctement dans une capture d'écran statique unique, elle échoue fréquemment dans des conditions dynamiques telles que le défilement, le survol, le clic, le redimensionnement ou le jeu. Les méthodes d'évaluation traditionnelles, qui reposent sur des captures d'écran statiques ou des traces visuelles éparses, ne détectent pas ces échecs spécifiques aux interactions. De plus, les approches standard de filtrage des données rejettent de nombreuses pages comme inutilisables, sans reconnaître qu'elles sont souvent réparables. Le défi central identifié est que la construction de données pour le HTML interactif est un problème d'estimation d'état plutôt qu'un simple problème de notation ; les observations statiques ne peuvent révéler les échecs qui ne se manifestent qu'après des interactions utilisateur spécifiques.

Méthodologie

L'article présente HTMLCURE, un cadre d'expérience navigateur conçu pour évaluer, diagnostiquer et réparer le HTML interactif grâce à un processus en boucle fermée piloté par des traces d'exécution navigateur.

1. Pipeline d'évaluation expérientielle multidimensionnelle

Au lieu de se fier à des captures d'écran statiques, HTMLCURE évalue un artefact HTML ($h$) en exécutant une séquence d'actions de visualisation et d'interaction ($\pi$).

• Protocole d'expérience à quatre niveaux :
  • L1 (Observation visuelle) : Vérifie le comportement de chargement et le rendu initial.
  • L2 (Interaction active) : Teste les contrôles, les états de survol, les liaisons clavier et le comportement de défilement.
  • L3 (Jeu profond) : Exécute des déploiements orientés vers des tâches pour les jeux ou les interfaces complexes afin de vérifier les transitions d'état, les compteurs et les modifications du canevas.
  • L4 (Responsive) : Sélectionne des images clés représentatives de la trajectoire d'exécution avec le contexte des événements.
• Preuve structurée : L'évaluateur produit une trace ordonnée $E(h, \pi)$ contenant des preuves visuelles ($v_t$, par exemple des images rendues) et des preuves comportementales ($b_t$, par exemple l'état du DOM, les erreurs de console, les résultats de sondage).
• Notation à cinq composantes : Un score $S(h)$ est dérivé de cinq dimensions : Rendu, Design visuel, Fonctionnalité, Interactivité et Qualité du code. Crucialement, le Design visuel est la seule composante jugée par un modèle Vision-Langage (VLM) sur la base d'images clés curatées ; toutes les autres dimensions reposent sur l'exécution déterministe du navigateur et l'analyse statique.

2. Moteur de réparation interactive sensible à l'état

Le processus de réparation n'est pas une régénération générique, mais une intervention contrôlée basée sur l'état actuel de la page.

• Routage d'état : Le système classe les pages en trois états en fonction de leur score $s$ :
  • Faible (< 40) : Pages sans cible locale stable. Stratégie : Réécriture holistique.
  • Moyen (40–79) : Pages avec une structure utilisable mais un comportement cassé. Stratégie : Réparation locale guidée par le diagnostic (par exemple, corriger des bugs d'interaction spécifiques).
  • Élevé (≥ 80) : Pages solides. Stratégie : Préservation ou Raffinement ciblé pour éviter les régressions.
• Exécution en boucle fermée : Le contrôleur sélectionne une famille de réparation, sollicite le LLM pour des candidats, et réexécute chaque candidat dans le navigateur.
• Acceptation consciente de la régression : Les candidats sont sélectionnés à l'aide d'un score composite $S_{comp}$ qui pénalise les régressions en matière de fonctionnalité et d'interactivité, garantissant que les améliorations du design visuel ne se font pas au détriment d'une logique cassée.
• Terminaison : La boucle s'arrête lorsqu'une page atteint un score cible élevé (≥ 97), que le gain plafonne ou que le budget de tours est épuisé.

3. Construction de données

HTMLCURE traite la réparation comme un mécanisme de construction de données. Les réparations acceptées issues du corpus initial de 97 000 invites sont exportées dans un pool affiné de fine-tuning supervisé (SFT). Ce processus élargit l'ensemble de données utilisable d'un petit sous-ensemble de pages « Élevées » à un pool plus large de 63 703 pages qualifiées, à partir duquel un ensemble d'entraînement final de 40 000 éléments est construit.

Contributions clés

1. L'expérience navigateur comme signal d'état de réparation : L'article démontre que la conversion des traces d'exécution navigateur en états de page structurés permet de délimiter précisément le jugement visuel du VLM et de piloter des décisions de réparation spécifiques.
2. Réparation interactive sensible à l'état : Le cadre introduit une politique où la stratégie de réparation (Réécriture vs Diagnostic vs Préservation) est sélectionnée dynamiquement en fonction de l'état observé de la page. Cela empêche la destruction de composants fonctionnels dans les pages de haute qualité et assure une reconstruction structurelle pour les pages de faible qualité.
3. La réparation comme construction de données : En validant les réparations par réexécution, le système crée un corpus SFT de haute qualité et vérifié. Cette approche transforme le paradigme de « filtrage » (rejeter les mauvaises pages) en un paradigme de « récupération » (réparer et vérifier les pages).

Résultats

Les auteurs ont évalué la méthodologie en utilisant HTMLBENCH-400, un benchmark exécutable de manière déterministe par un navigateur, et la division de validation MiniAppBench.

• Performance : Sous la même architecture de base (Qwen3.5) et la même recette d'entraînement, le modèle HTMLCure-27B-Refined a obtenu :
  • 50,6 sur HTMLBENCH-400 (Score total).
  • 45,2 % de taux de réussite des cas de test déterministes.
  • 81,2 en moyenne sur la division de validation MiniAppBench.
• Comparaisons : Ces résultats placent le modèle dans la même bande de performance que des systèmes de référence solides comme Kimi-K2.6 et GPT-5.4.
• Ablation : Des expériences contrôlées avec des tailles de données égales (12 392 exemples) ont confirmé que la voie « Refined » (utilisant des données réparées et vérifiées) surpasse à la fois les voies « Raw » (générations originales) et « Filtered » (seules les pages de haute qualité originales), prouvant que la qualité de la supervision dérivée de l'expérience navigateur est le principal moteur d'amélioration, et non simplement le volume de données.

Importance et revendications

L'article affirme que HTMLCURE fait passer le paradigme de la génération de HTML interactif de « générer et filtrer » à « expérimenter, réparer et vérifier ».

• L'exécution comme contrôle : La revendication centrale est que l'exécution navigateur ne doit pas être utilisée uniquement comme un juge final de réussite/échec, mais comme un signal de contrôle continu qui sépare la structure manquante de l'interaction cassée.
• Qualité des données : Le travail démontre que la réparation de pages faibles et partielles sous un contrôle spécifique à l'état produit une supervision plus forte pour le SFT que la simple sélection de pages de haute qualité préexistantes.
• Reproductibilité : Les auteurs fournissent un benchmark figé (HTMLBENCH) avec des cas de test déterministes et un pipeline complet pour une comparaison reproductible, allant au-delà des évaluations basées sur des agents qui manquent d'enregistrements d'échec standardisés.

L'article reste modeste concernant ses limites, reconnaissant que le VLM est toujours nécessaire pour la notation bornée du design visuel, que les sondages navigateur ne peuvent couvrir chaque interaction possible, et que des jeux complexes peuvent révéler des échecs de synchronisation couplés. Il suggère que des travaux futurs pourraient impliquer l'apprentissage direct des politiques de routage et d'arrêt à partir des traces de réparation.