Riepilogo Tecnico: HTMLCure

Enunciato del Problema

I Large Language Models (LLM) hanno dimostrato la capacità di generare pagine HTML complete, ma questi output soffrono spesso di un problema di "correttezza superficiale". Sebbene una pagina generata possa essere resa correttamente in un singolo screenshot statico, essa fallisce frequentemente in condizioni dinamiche come lo scorrimento, il passaggio del mouse, il clic, il ridimensionamento o il gameplay. I metodi di valutazione tradizionali, basati su screenshot statici o tracce visive sparse, trascurano questi fallimenti specifici delle interazioni. Inoltre, gli approcci standard di filtraggio dei dati scartano molte di queste pagine come inutilizzabili, non riconoscendo che esse sono spesso riparabili. La sfida fondamentale identificata è che la costruzione di dati per l'HTML interattivo è un problema di stima dello stato piuttosto che semplicemente un problema di punteggio; le osservazioni statiche non possono rivelare fallimenti che si manifestano solo dopo specifiche interazioni utente.

Metodologia

Il documento introduce HTMLCURE, un framework di esperienza browser progettato per valutare, diagnosticare e riparare l'HTML interattivo attraverso un processo a ciclo chiuso guidato dalle tracce di esecuzione del browser.

1. Pipeline di Valutazione Esperienziale Multidimensionale

Invece di affidarsi a screenshot statici, HTMLCURE valuta un artefatto HTML ($h$) eseguendo una sequenza di azioni di visualizzazione e interazione ($\pi$).

• Protocollo Esperienziale a Quattro Livelli:
  • L1 (Osservazione Visiva): Verifica il comportamento di caricamento e il rendering iniziale.
  • L2 (Interazione Attiva): Mette alla prova i controlli, gli stati di hover, i collegamenti da tastiera e il comportamento di scorrimento.
  • L3 (Gameplay Approfondito): Esegue rollout guidati da compiti per giochi o interfacce utente complesse per verificare le transizioni di stato, i contatori e le modifiche alla canvas.
  • L4 (Responsività): Seleziona fotogrammi chiave rappresentativi dalla traiettoria di esecuzione con il contesto degli eventi.
• Evidenza Strutturata: Il valutatore produce una traccia ordinata $E(h, \pi)$ contenente evidenza visiva ($v_t$, ad esempio fotogrammi renderizzati) ed evidenza comportamentale ($b_t$, ad esempio stato del DOM, errori nella console, esiti delle sonde).
• Punteggio a Cinque Componenti: Un punteggio $S(h)$ è derivato da cinque dimensioni: Rendering, Design Visivo, Funzionalità, Interattività e Qualità del Codice. Crucialmente, il Design Visivo è l'unica componente giudicata da un Modello Linguistico-Visivo (VLM) basato su fotogrammi chiave curati; tutte le altre dimensioni si affidano all'esecuzione deterministica del browser e all'analisi statica.

2. Motore di Riparazione Interattiva Consapevole dello Stato

Il processo di riparazione non è una rigenerazione generica, ma un intervento controllato basato sullo stato corrente della pagina.

• Instradamento dello Stato: Il sistema classifica le pagine in tre stati in base al loro punteggio $s$:
  • Basso (< 40): Pagine senza un target locale stabile. Strategia: Riscrittura Olistica.
  • Medio (40–79): Pagine con struttura utilizzabile ma comportamento rotto. Strategia: Riparazione Locale Guidata dalla Diagnosi (ad esempio, correzione di bug specifici di interazione).
  • Alto (≥ 80): Pagine solide. Strategia: Preservazione o Raffinamento Mirato per evitare regressioni.
• Esecuzione a Ciclo Chiuso: Il controller seleziona una famiglia di riparazioni, sollecita l'LLM per i candidati e riesegue ogni candidato nel browser.
• Accettazione Consapevole delle Regressioni: I candidati sono selezionati utilizzando un punteggio composito $S_{comp}$ che penalizza le regressioni nella funzionalità e nell'interattività, garantendo che i miglioramenti nel design visivo non avvengano a scapito di logiche rotte.
• Terminazione: Il ciclo si interrompe quando una pagina raggiunge un punteggio target elevato (≥ 97), il guadagno si stabilizza (plateau) o il budget di round è esaurito.

3. Costruzione dei Dati

HTMLCURE tratta la riparazione come un meccanismo di costruzione dei dati. Le riparazioni accettate dal corpus iniziale di 97K prompt vengono esportate in un pool raffinato di Addestramento Supervisionato (SFT). Questo processo espande il dataset utilizzabile da un piccolo sottoinsieme di pagine "Alte" a un pool più ampio di 63.703 pagine qualificate, dal quale viene costruito un set di addestramento finale di 40K.

Contributi Chiave

1. Esperienza Browser come Segnale di Stato di Riparazione: Il documento dimostra che convertire le tracce di esecuzione del browser in stati di pagina strutturati permette di delimitare con precisione il giudizio visivo del VLM e guida decisioni di riparazione specifiche.
2. Riparazione Interattiva Consapevole dello Stato: Il framework introduce una politica in cui la strategia di riparazione (Riscrittura vs. Diagnosi vs. Preservazione) viene selezionata dinamicamente in base allo stato osservato della pagina. Questo previene la distruzione di componenti funzionanti nelle pagine di alta qualità e garantisce la ricostruzione strutturale per quelle di bassa qualità.
3. Riparazione come Costruzione di Dati: Validando le riparazioni attraverso la riesecuzione, il sistema crea un corpus SFT di alta qualità e verificato. Questo approccio trasforma il paradigma di "filtraggio" (scartare pagine scadenti) in un paradigma di "recupero" (riparare e verificare le pagine).

Risultati

Gli autori hanno valutato la metodologia utilizzando HTMLBENCH-400, un benchmark deterministico eseguibile nel browser, e la divisione di validazione MiniAppBench.

• Prestazioni: Sotto lo stesso backbone (Qwen3.5) e la stessa ricetta di addestramento, il modello HTMLCure-27B-Refined ha ottenuto:
  • 50.6 su HTMLBENCH-400 (Punteggio Totale).
  • 45.2% di tasso di superamento dei casi di test deterministici.
  • 81.2 di media sulla divisione di validazione di MiniAppBench.
• Confronti: Questi risultati collocano il modello nella stessa fascia di prestazioni di sistemi di riferimento forti come Kimi-K2.6 e GPT-5.4.
• Ablazione: Esperimenti controllati con dimensioni di dati uguali (12.392 esempi) hanno confermato che la rotta "Refined" (utilizzando dati riparati e verificati) supera sia la rotta "Raw" (generazioni originali) sia la rotta "Filtered" (solo pagine originali di alta qualità), dimostrando che la qualità della supervisione derivata dall'esperienza browser è il principale motore di miglioramento, non solo il volume dei dati.

Significato e Affermazioni

Il documento afferma che HTMLCURE sposta il paradigma della generazione di HTML interattivo da "generare e filtrare" a "esperire, riparare e verificare".

• Esecuzione come Controllo: L'affermazione centrale è che l'esecuzione del browser non dovrebbe essere utilizzata meramente come giudice finale di superamento/fallimento, ma come un segnale di controllo continuo che separa la struttura mancante dall'interazione rotta.
• Qualità dei Dati: Il lavoro dimostra che riparare pagine deboli e parziali sotto un controllo specifico dello stato produce una supervisione più forte per l'SFT rispetto alla semplice selezione di pagine preesistenti di alta qualità.
• Riproducibilità: Gli autori forniscono un benchmark congelato (HTMLBENCH) con casi di test deterministici e una pipeline completa per il confronto riproducibile, andando oltre le valutazioni basate su agenti che mancano di registrazioni standardizzate dei fallimenti.

Il documento rimane modesto riguardo ai suoi limiti, riconoscendo che il VLM è ancora necessario per la valutazione del design visivo delimitata, che le sonde del browser non possono coprire ogni possibile interazione e che giochi complessi possono esporre fallimenti temporali accoppiati. Suggerisce che il lavoro futuro potrebbe coinvolgere l'apprendimento delle politiche di instradamento e arresto direttamente dalle tracce di riparazione.