Resumo Técnico: HTMLCure

Declaração do Problema

Modelos de Linguagem de Grande Escala (LLMs) demonstraram a capacidade de gerar páginas HTML completas, mas essas saídas frequentemente sofrem de um problema de "correção superficial". Embora uma página gerada possa renderizar corretamente em uma única captura de tela estática, ela frequentemente falha sob condições dinâmicas, como rolagem, passagem do mouse, cliques, redimensionamento ou jogabilidade. Métodos de avaliação tradicionais, que dependem de capturas de tela estáticas ou traços visuais esparsos, ignoram essas falhas específicas de interação. Além disso, abordagens padrão de filtragem de dados descartam muitas dessas páginas como inutilizáveis, falhando em reconhecer que elas são frequentemente reparáveis. O desafio central identificado é que a construção de dados para HTML interativo é um problema de estimativa de estado e não meramente um problema de pontuação; observações estáticas não podem revelar falhas que só se manifestam após interações específicas do usuário.

Metodologia

O artigo apresenta o HTMLCURE, um framework de experiência de navegador projetado para avaliar, diagnosticar e reparar HTML interativo por meio de um processo de malha fechada impulsionado por traços de execução do navegador.

1. Pipeline de Avaliação Experiencial Multidimensional

Em vez de depender de capturas de tela estáticas, o HTMLCure avalia um artefato HTML ($h$) executando uma sequência de ações de visualização e interação ($\pi$).

• Protocolo de Experiência de Quatro Camadas:
  • L1 (Observar Visualmente): Verifica o comportamento de carregamento e a renderização inicial.
  • L2 (Interagir Ativamente): Exercita controles, estados de passagem do mouse, ligações de teclado e comportamento de rolagem.
  • L3 (Jogabilidade Profunda): Executa expansões orientadas a tarefas para jogos ou interfaces complexas, verificando transições de estado, contadores e alterações no canvas.
  • L4 (Responsivo): Seleciona quadros-chave representativos da trajetória de execução com contexto de eventos.
• Evidência Estruturada: O avaliador produz um traço ordenado $E(h, \pi)$ contendo evidência visual ($v_t$, por exemplo, quadros renderizados) e evidência comportamental ($b_t$, por exemplo, estado do DOM, erros no console, resultados de sondas).
• Pontuação de Cinco Componentes: Uma pontuação $S(h)$ é derivada de cinco dimensões: Renderização, Design Visual, Funcionalidade, Interatividade e Qualidade do Código. Crucialmente, o Design Visual é o único componente julgado por um Modelo de Linguagem e Visão (VLM) com base em quadros-chave curados; todas as outras dimensões dependem da execução determinística do navegador e da análise estática.

2. Motor de Reparo Interativo Consciente de Estado

O processo de reparo não é uma regeneração genérica, mas uma intervenção controlada baseada no estado atual da página.

• Roteamento de Estado: O sistema classifica as páginas em três estados com base em sua pontuação $s$:
  • Baixo (< 40): Páginas sem um alvo local estável. Estratégia: Reescrita Holística.
  • Médio (40–79): Páginas com estrutura utilizável, mas comportamento quebrado. Estratégia: Reparo Local Guiado por Diagnóstico (por exemplo, corrigindo bugs específicos de interação).
  • Alto (≥ 80): Páginas fortes. Estratégia: Preservação ou Refinamento Direcionado para evitar regressão.
• Execução em Malha Fechada: O controlador seleciona uma família de reparos, solicita candidatos ao LLM e reexecuta cada candidato no navegador.
• Aceitação Consciente de Regressão: Os candidatos são selecionados usando uma pontuação composta $S_{comp}$ que penaliza regressões na funcionalidade e na interatividade, garantindo que melhorias no design visual não ocorram à custa de lógica quebrada.
• Terminação: O loop para quando uma página atinge uma pontuação-alvo alta (≥ 97), ganha de platô ou o orçamento de rodadas é esgotado.

3. Construção de Dados

O HTMLCure trata o reparo como um mecanismo de construção de dados. Reparos aceitos do corpus inicial de 97 mil prompts são exportados para um pool refinado de Ajuste Fino Supervisionado (SFT). Este processo expande o conjunto de dados utilizável de um pequeno subconjunto de páginas "Altas" para um pool maior de 63.703 páginas com qualidade verificada, dos quais um conjunto de treinamento final de 40 mil é construído.

Principais Contribuições

1. Experiência de Navegador como Sinal de Estado de Reparo: O artigo demonstra que converter traços de execução do navegador em estados de página estruturados permite delimitar com precisão o julgamento visual do VLM e impulsiona decisões específicas de reparo.
2. Reparo Interativo Consciente de Estado: O framework introduz uma política onde a estratégia de reparo (Reescrever vs. Diagnosticar vs. Preservar) é selecionada dinamicamente com base no estado observado da página. Isso previne a destruição de componentes funcionais em páginas de alta qualidade e garante reconstrução estrutural para aquelas de baixa qualidade.
3. Reparo como Construção de Dados: Ao validar reparos por meio de reexecução, o sistema cria um corpus SFT de alta qualidade e verificado. Essa abordagem transforma o paradigma de "filtragem" (descartar páginas ruins) em um paradigma de "recuperação" (reparar e verificar páginas).

Resultados

Os autores avaliaram a metodologia usando o HTMLBENCH-400, um benchmark executável determinístico no navegador, e a divisão de validação do MiniAppBench.

• Desempenho: Sob a mesma base (Qwen3.5) e receita de treinamento, o modelo HTMLCure-27B-Refined alcançou:
  • 50,6 no HTMLBENCH-400 (Pontuação Total).
  • 45,2% de taxa de aprovação de casos de teste determinísticos.
  • 81,2 de média na divisão de validação do MiniAppBench.
• Comparações: Esses resultados colocam o modelo na mesma faixa de desempenho que sistemas de referência fortes como Kimi-K2.6 e GPT-5.4.
• Ablação: Experimentos controlados com tamanhos de dados iguais (12.392 exemplos) confirmaram que a rota "Refined" (usando dados reparados e verificados) supera tanto a rota "Raw" (gerações originais) quanto a rota "Filtered" (apenas páginas originais de alta qualidade), provando que a qualidade da supervisão derivada da experiência do navegador é o principal motor de melhoria, não apenas o volume de dados.

Significado e Alegações

O artigo alega que o HTMLCure muda o paradigma da geração de HTML interativo de "gerar e filtrar" para "experienciar, reparar e verificar".

• Execução como Controle: A alegação central é que a execução do navegador não deve ser usada meramente como um juiz final de aprovação/reprovação, mas como um sinal de controle contínuo que separa estrutura ausente de interação quebrada.
• Qualidade de Dados: O trabalho demonstra que reparar páginas fracas e parciais sob controle específico de estado produz supervisão mais forte para SFT do que simplesmente selecionar páginas pré-existentes de alta qualidade.
• Reprodutibilidade: Os autores fornecem um benchmark congelado (HTMLBENCH) com casos de teste determinísticos e um pipeline completo para comparação reproduzível, indo além de avaliações baseadas em agentes que carecem de registros de falhas padronizados.

O artigo permanece modesto quanto às suas limitações, reconhecendo que o VLM ainda é necessário para pontuação de design visual delimitada, sondas do navegador não podem cobrir cada interação possível e jogos complexos podem expor falhas de tempo acopladas. Sugere que trabalhos futuros poderiam envolver o aprendizado de políticas de roteamento e parada diretamente a partir de traços de reparo.