Resumen Técnico: HTMLCure

Enunciado del Problema

Los Modelos de Lenguaje Grande (LLM) han demostrado la capacidad de generar páginas HTML completas, pero estos resultados a menudo sufren un problema de "corrección superficial". Aunque una página generada pueda renderizarse correctamente en una sola captura de pantalla estática, frecuentemente falla bajo condiciones dinámicas como el desplazamiento, el paso del cursor, los clics, el redimensionamiento o el juego. Los métodos de evaluación tradicionales que dependen de capturas de pantalla estáticas o trazas visuales escasas pasan por alto estas fallas específicas de la interacción. Además, los enfoques estándar de filtrado de datos descartan muchas de estas páginas como inutilizables, sin reconocer que a menudo son reparables. El desafío central identificado es que la construcción de datos para HTML interactivo es un problema de estimación de estado y no meramente un problema de puntuación; las observaciones estáticas no pueden revelar fallas que solo se manifiestan después de interacciones específicas del usuario.

Metodología

El artículo introduce HTMLCURE, un marco de experiencia de navegador diseñado para evaluar, diagnosticar y reparar HTML interactivo mediante un proceso de bucle cerrado impulsado por trazas de ejecución del navegador.

1. Pipeline de Evaluación Experiencial Multidimensional

En lugar de depender de capturas de pantalla estáticas, HTMLCURE evalúa un artefacto HTML ($h$) ejecutando una secuencia de acciones de visualización e interacción ($\pi$).

• Protocolo de Experiencia de Cuatro Capas:
  • L1 (Observar Visualmente): Verifica el comportamiento de carga y el renderizado inicial.
  • L2 (Interactuar Activamente): Ejercita controles, estados de paso del cursor, atajos de teclado y comportamiento de desplazamiento.
  • L3 (Juego Profundo): Ejecuta despliegues orientados a tareas para juegos o interfaces de usuario complejas para verificar transiciones de estado, contadores y cambios en el lienzo.
  • L4 (Responsivo): Selecciona fotogramas clave representativos de la trayectoria de ejecución con contexto de eventos.
• Evidencia Estructurada: El evaluador produce una traza ordenada $E(h, \pi)$ que contiene evidencia visual ($v_t$, por ejemplo, fotogramas renderizados) y evidencia conductual ($b_t$, por ejemplo, estado del DOM, errores de consola, resultados de sondas).
• Puntuación de Cinco Componentes: Una puntuación $S(h)$ se deriva de cinco dimensiones: Renderizado, Diseño Visual, Funcionalidad, Interactividad y Calidad del Código. Crucialmente, el Diseño Visual es el único componente juzgado por un Modelo de Lenguaje y Visión (VLM) basado en fotogramas clave curados; todas las demás dimensiones dependen de la ejecución determinista del navegador y del análisis estático.

2. Motor de Reparación Interactiva Consciente del Estado

El proceso de reparación no es una regeneración genérica, sino una intervención controlada basada en el estado actual de la página.

• Enrutamiento de Estado: El sistema clasifica las páginas en tres estados basados en su puntuación $s$:
  • Bajo (< 40): Páginas sin un objetivo local estable. Estrategia: Reescritura Holística.
  • Medio (40–79): Páginas con estructura utilizable pero comportamiento roto. Estrategia: Reparación Local Guiada por Diagnóstico (por ejemplo, corregir errores de interacción específicos).
  • Alto (≥ 80): Páginas fuertes. Estrategia: Preservación o Refinamiento Dirigido para evitar regresiones.
• Ejecución de Bucle Cerrado: El controlador selecciona una familia de reparaciones, solicita candidatos al LLM y reejecuta cada candidato en el navegador.
• Aceptación Consciente de Regresión: Los candidatos se seleccionan utilizando una puntuación compuesta $S_{comp}$ que penaliza las regresiones en funcionalidad e interactividad, asegurando que las mejoras en el diseño visual no se logren a costa de una lógica rota.
• Terminación: El bucle se detiene cuando una página alcanza una puntuación objetivo alta (≥ 97), se estabiliza la ganancia o se agota el presupuesto de rondas.

3. Construcción de Datos

HTMLCURE trata la reparación como un mecanismo de construcción de datos. Las reparaciones aceptadas del corpus inicial de 97K prompts se exportan a un pool refinado de Ajuste Fino Supervisado (SFT). Este proceso expande el conjunto de datos utilizable de un pequeño subconjunto de páginas "Altas" a un pool más grande de 63,703 páginas con calidad verificada, de las cuales se construye un conjunto de entrenamiento final de 40K.

Contribuciones Clave

1. Experiencia de Navegador como Señal de Estado de Reparación: El artículo demuestra que convertir las trazas de ejecución del navegador en estados de página estructurados permite acotar con precisión el juicio visual del VLM e impulsa decisiones de reparación específicas.
2. Reparación Interactiva Consciente del Estado: El marco introduce una política donde la estrategia de reparación (Reescribir vs. Diagnosticar vs. Preservar) se selecciona dinámicamente basándose en el estado observado de la página. Esto evita la destrucción de componentes funcionales en páginas de alta calidad y asegura la reconstrucción estructural para las de baja calidad.
3. Reparación como Construcción de Datos: Al validar reparaciones mediante reejecución, el sistema crea un corpus SFT de alta calidad y verificado. Este enfoque transforma el paradigma de "filtrado" (descartar páginas malas) en un paradigma de "recuperación" (reparar y verificar páginas).

Resultados

Los autores evaluaron la metodología utilizando HTMLBENCH-400, un benchmark ejecutable determinista en navegador, y la división de validación de MiniAppBench.

• Rendimiento: Bajo la misma arquitectura base (Qwen3.5) y receta de entrenamiento, el modelo HTMLCure-27B-Refined logró:
  • 50.6 en HTMLBENCH-400 (Puntuación Total).
  • 45.2% de tasa de aprobación de casos de prueba deterministas.
  • 81.2 de promedio en la división de validación de MiniAppBench.
• Comparaciones: Estos resultados sitúan al modelo en la misma banda de rendimiento que sistemas de referencia sólidos como Kimi-K2.6 y GPT-5.4.
• Ablación: Experimentos controlados con tamaños de datos iguales (12,392 ejemplos) confirmaron que la ruta "Refined" (utilizando datos reparados y verificados) supera tanto a la ruta "Raw" (generaciones originales) como a la ruta "Filtered" (solo páginas originales de alta calidad), demostrando que la calidad de la supervisión derivada de la experiencia del navegador es el principal impulsor de la mejora, no solo el volumen de datos.

Significado y Afirmaciones

El artículo afirma que HTMLCURE cambia el paradigma de la generación de HTML interactivo de "generar y filtrar" a "experimentar, reparar y verificar".

• Ejecución como Control: La afirmación central es que la ejecución del navegador no debe usarse meramente como un juez final de aprobado/reprobado, sino como una señal de control continua que separa la estructura faltante de la interacción rota.
• Calidad de Datos: El trabajo demuestra que reparar páginas débiles y parciales bajo control específico de estado produce una supervisión más fuerte para el SFT que simplemente seleccionar páginas de alta calidad preexistentes.
• Reproducibilidad: Los autores proporcionan un benchmark congelado (HTMLBENCH) con casos de prueba deterministas y un pipeline completo para una comparación reproducible, yendo más allá de las evaluaciones basadas en agentes que carecen de registros estandarizados de fallas.

El artículo se mantiene modesto respecto a sus limitaciones, reconociendo que el VLM aún es necesario para la puntuación acotada del diseño visual, las sondas del navegador no pueden cubrir cada interacción posible y los juegos complejos pueden exponer fallas de temporización acopladas. Sugiere que el trabajo futuro podría involucrar aprender políticas de enrutamiento y detención directamente desde las trazas de reparación.