🤖 AI

HTMLCure: Turning Browser Experience into State Guided Repair for Interactive HTML

HTMLCure introduceert een framework voor een door de staat geleide browserervaring dat interactieve HTML evalueert en repareert via deterministische interactietrajectoria, waarbij een zaadcorpus aanzienlijk wordt uitgebreid tot een hoogwaardige dataset die een 27B-model in staat stelt prestaties te behalen die vergelijkbaar zijn met toonaangevende systemen zoals Kimi-K2.6 en GPT-5.4 op interactieve webbenchmarks.

Oorspronkelijke auteurs: Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

Gepubliceerd 2026-05-27

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Het Grote Probleem: "Ziet er goed uit, maar kapot"

Stel je voor dat je een zeer getalenteerde kunstenaar (een AI) vraagt om een speelgoedauto te bouwen. De kunstenaar geeft je een prachtig model. Het ziet er perfect uit op de foto. Maar als je hem probeert te duwen, vallen de wielen eraf. Als je probeert te sturen, draait het stuurwiel nutteloos rond.

Dit is het huidige probleem met door AI gegenereerde webpagina's (HTML). Ze zien er vaak geweldig uit in een enkele momentopname (een screenshot), maar als een echt persoon probeert op knoppen te klikken, naar beneden te scrollen, het venster te verkleinen of een spelletje te spelen, gaat de pagina kapot.

De Oude Manier: Onderzoekers namen vroeger een foto van de pagina, keken of het er mooi uitzag, en beslisten of het "goed" was. Hiermee misten ze al de kapotte wielen.
Het Resultaat: Ze gooiden duizenden pagina's weg die eigenlijk te repareren waren, of ze behielden pagina's die er goed uitzagen maar niet werkten.

De Oplossing: HTMLCURE (De "Proefrit"-Mecanicien)

De auteurs bouwden een systeem genaamd HTMLCURE. In plaats van alleen naar een foto te kijken, fungeert HTMLCURE als een mecanicien die de auto voor een proefrit meeneemt.

Zo werkt het, stap voor stap:

1. De Proefrit (Browserervaring)

In plaats van alleen een foto te maken, laadt HTMLCURE de webpagina in een echte browser. Het zit er niet alleen maar bij; het interageert actief met de pagina:

Het scrollt op en neer.
Het verandert de venstergrootte (alsof je controleert of een auto in een kleine garage past).
Het klikt op knoppen, beweegt over links en probeert spelletjes te spelen.
Het legt exact vast wat er gebeurt: "De knop werkte niet", "Het spel bevriest" of "De lay-out is op mobiel kapot gegaan".

Analogie: Denk hierbij aan een rijexamen voor een auto. Je kijkt niet alleen naar de laklaag; je rijdt ermee om te zien of de motor start, of de remmen werken en of de versnelling soepel schakelt.

2. De Diagnose (Staatssignaal)

Na de proefrit geeft het systeem de pagina een "gezondheidsscore" en een diagnose. Het categoriseert de pagina in drie groepen, zoals een arts patiënten triageert:

Lage Score (De Schroot): De pagina is een puinhoop. Er ontbreken grote stukken structuur.
- De Oplossing: Totale Herschrijving. Probeer het niet te repareren; bouw een nieuwe auto vanaf de grond af.
Middelhoge Score (De Schrootbak): De pagina werkt grotendeels, maar heeft specifieke kapotte onderdelen (bijvoorbeeld de radio werkt niet, of de deurklink zit vast).
- De Oplossing: Gerichte Reparatie. Diagnose het specifieke kapotte onderdeel en repareer alleen dat.
Hoge Score (De Sportauto): De pagina is al geweldig.
- De Oplossing: Alleen Polijsten. Raak de motor niet aan; misschien alleen maar de lak waxen. Als je probeert iets "te repareren" dat niet kapot is, kun je het misschien kapot maken.

Kerninzicht: Het papier beweert dat het gebruik van dezelfde reparatiemethode voor alle pagina's een fout is. Je hebt een andere strategie nodig, afhankelijk van hoe kapot de pagina eigenlijk is.

3. De Reparatieslus (De Feedbackcyclus)

Zodra het systeem een strategie heeft bepaald (Herschrijven, Patchen of Polijsten), vraagt het de AI om de pagina te repareren.

Cruciale Stap: Het systeem vertrouwt niet zomaar het woord van de AI. Het neemt de nieuwe versie van de pagina en voert de Proefrit opnieuw uit.
De Poortwachter: Als de nieuwe versie beter is, behoudt hij deze. Als de nieuwe versie slechter is (een "regressie"), gooit hij deze weg en probeert het opnieuw.
Het Doel: Het blijft dit doen totdat de pagina een hoge kwaliteitsstandaard haalt (een score van 97/100).

Analogie: Stel je een kok voor die een soep proeft. Als het te zout is, voegen ze water toe. Dan proeven ze het opnieuw. Ze gaan er niet zomaar van uit dat het water het heeft opgelost; ze verifiëren het. Als ze te veel water toevoegen en het is nu te waterig, stoppen ze en proberen ze een ander recept.

De Resultaten: Een Betere Bibliotheek Bouwen

De auteurs gebruikten dit systeem op een enorme verzameling van 97.000 door AI gegenereerde pagina's.

Ze begonnen met een kleine stapel "perfecte" pagina's.
Ze gebruikten HTMLCURE om de "kapotte" exemplaren te repareren.
Ze eindigden met 63.000 hoogwaardige, geverifieerde pagina's (een stijging ten opzichte van de oorspronkelijke kleine set).

Vervolgens gebruikten ze deze nieuwe, opgeschoonde bibliotheek om een nieuw AI-model te trainen (genaamd HTMLCure-27B).

Het Resultaat:

Het nieuwe model is aanzienlijk beter in het maken van werkende webpagina's.
Het scoorde 50,6 op een strenge test genaamd HTMLBENCH, wat gelijkstaat aan top-tier commerciële modellen (zoals Kimi-K2.6 en GPT-5.4).
Op een andere test (MiniAppBench) verbeterde het met 15 punten ten opzichte van de ongetrainde versie.

Samenvatting in Eén Zin

HTMLCURE is een systeem dat voorkomt dat AI alleen maar "raadt" of een webpagina werkt; in plaats daarvan dwingt het de AI om elke pagina te proefrijden, exact te diagnosticeren wat er kapot is, het te repareren met de juiste strategie, en het opnieuw te testen om ervoor te zorgen dat de reparatie echt werkte, waardoor een enorme bibliotheek van hoogwaardige, werkende code ontstaat.

Technische Samenvatting: HTMLCure

Probleemstelling

Grote Taalmodellen (LLM's) hebben de capaciteit aangetoond om volledige HTML-pagina's te genereren, maar deze outputs lijden vaak onder een probleem van "oppervlakkige correctheid". Hoewel een gegenereerde pagina correct kan worden weergegeven in een enkele statische screenshot, faalt deze frequent onder dynamische omstandigheden zoals scrollen, hoveren, klikken, het wijzigen van de grootte of gameplay. Traditionele evaluatiemethoden die vertrouwen op statische screenshots of schaarse visuele sporen, missen deze interactie-specifieke fouten. Bovendien verwerpen standaard data-filteringsbenaderingen veel van deze pagina's als onbruikbaar, zonder te erkennen dat ze vaak gerepareerd kunnen worden. De kernuitdaging die is geïdentificeerd, is dat dataconstructie voor interactieve HTML een schatting van de toestand betreft en niet louter een scoreprobleem; statische waarnemingen kunnen geen fouten onthullen die zich pas manifesteren na specifieke gebruikersinteracties.

Methodologie

Het artikel introduceert HTMLCURE, een browser-ervaringsframework dat is ontworpen om interactieve HTML te evalueren, diagnosticeren en repareren via een gesloten-lusproces dat wordt aangedreven door browser-executiesporen.

1. Meerdimensionale Ervarings-evaluatiepijplijn

In plaats van te vertrouwen op statische screenshots, evalueert HTMLCURE een HTML-artefact ( $h$ ) door een reeks weergave- en interactie-acties ( $\pi$ ) uit te voeren.

Vier-laags Ervaringsprotocol:
- L1 (Visueel Observeren): Controleert laadgedrag en initiële weergave.
- L2 (Actief Interacteren): Test besturingselementen, hover-toestanden, toetsenbordkoppelingen en scroll-gedrag.
- L3 (Diepe Gameplay): Voert taakgestuurde rollouts uit voor games of complexe UI's om toestandsveranderingen, tellers en canvas-wijzigingen te verifiëren.
- L4 (Responsief): Selecteert representatieve sleutelframes uit de executietraject met gebeurteniscontext.
Gestructureerd Bewijs: De evaluator produceert een geordend spoor $E(h, \pi)$ dat visueel bewijs ( $v_t$ , bijv. gerenderde frames) en gedragsbewijs ( $b_t$ , bijv. DOM-toestand, console-fouten, uitkomsten van probes) bevat.
Scoren met Vijf Componenten: Een score $S(h)$ wordt afgeleid uit vijf dimensies: Weergave, Visueel Ontwerp, Functionaliteit, Interactiviteit en Kwaliteit van de Code. Cruciaal is dat Visueel Ontwerp het enige onderdeel is dat wordt beoordeeld door een Vision-Language Model (VLM) op basis van gecureerde sleutelframes; alle andere dimensies vertrouwen op deterministische browser-executie en statische analyse.

2. Toestandsbewuste Interactieve Reparatie-engine

Het reparatieproces is geen generieke regeneratie, maar een gecontroleerde interventie gebaseerd op de huidige toestand van de pagina.

Toestandsrouting: Het systeem classificeert pagina's in drie toestanden op basis van hun score $s$ $s$ :
- Laag (< 40): Pagina's zonder stabiel lokaal doel. Strategie: Holistische Herschrijving.
- Midden (40–79): Pagina's met bruikbare structuur maar gebroken gedrag. Strategie: Diagnose-gestuurde Lokale Reparatie (bijv. het oplossen van specifieke interactiefouten).
- Hoog (≥ 80): Sterke pagina's. Strategie: Behoud of Gerichte Verfijning om regressie te voorkomen.
Gesloten-lus Executie: De controller selecteert een reparatiefamilie, vraagt de LLM om kandidaten, en voert elke kandidaat opnieuw uit in de browser.
Regressie-bewuste Acceptatie: Kandidaten worden geselecteerd aan de hand van een samengestelde score $S_{comp}$ die regressies in functionaliteit en interactiviteit bestraft, waardoor wordt gegarandeerd dat verbeteringen in visueel ontwerp niet ten koste gaan van gebroken logica.
Beëindiging: De lus stopt wanneer een pagina een hoge doelscore bereikt (≥ 97), de winst plateaut, of het rondebudget is uitgeput.

3. Dataconstructie

HTMLCure behandelt reparatie als een mechanisme voor dataconstructie. Geaccepteerde reparaties uit het initiële corpus van 97.000 prompts worden geëxporteerd naar een verfijnde Supervised Fine-Tuning (SFT)-pool. Dit proces breidt de bruikbare dataset uit van een kleine subset van "Hoog"-pagina's naar een grotere pool van 63.703 kwaliteitsgezuiverde pagina's, waaruit een definitieve trainingsset van 40.000 wordt samengesteld.

Belangrijkste Bijdragen

Browserervaring als Signaal voor Reparatiestoestand: Het artikel toont aan dat het omzetten van browser-executiesporen in gestructureerde paginatoestanden een nauwkeurige begrenzing mogelijk maakt van visuele beoordeling door VLM's en specifieke reparatiebeslissingen stuurt.
Toestandsbewuste Interactieve Reparatie: Het framework introduceert een beleid waarbij de reparatiestrategie (Herschrijven vs. Diagnosticeren vs. Behouden) dynamisch wordt geselecteerd op basis van de waargenomen toestand van de pagina. Dit voorkomt de vernietiging van werkende componenten in hoogwaardige pagina's en zorgt voor structurele reconstructie voor laagwaardige pagina's.
Reparatie als Dataconstructie: Door reparaties te valideren via her-executie, creëert het systeem een hoogwaardig, geverifieerd SFT-corpus. Deze benadering transformeert het "filterparadigma" (het verwerpen van slechte pagina's) in een "herstelparadigma" (het repareren en verifiëren van pagina's).

Resultaten

De auteurs hebben de methodologie geëvalueerd met behulp van HTMLBENCH-400, een deterministische, browser-uitvoerbare benchmark, en de validatieverdeling van MiniAppBench.

Prestaties: Onder dezelfde backbone (Qwen3.5) en trainingsrecept bereikte het HTMLCure-27B-Refined-model:
- 50,6 op HTMLBENCH-400 (Totale Score).
- 45,2% doorlooppercentage voor deterministische testcases.
- 81,2 gemiddeld op de validatieverdeling van MiniAppBench.
Vergelijkingen: Deze resultaten plaatsen het model in hetzelfde prestatiebereik als sterke referentiesystemen zoals Kimi-K2.6 en GPT-5.4.
Ablatie: Gecontroleerde experimenten met gelijke datagroottes (12.392 voorbeelden) bevestigden dat de "Refined"-route (met gebruik van gerepareerde, geverifieerde data) beter presteert dan zowel de "Raw"-route (originele generaties) als de "Filtered"-route (alleen originele hoogwaardige pagina's). Dit bewijst dat de kwaliteit van de supervisie die voortkomt uit browserervaring de primaire drijvende kracht van verbetering is, en niet alleen de datavolume.

Betekenis en Claims

Het artikel claimt dat HTMLCure het paradigma van interactieve HTML-generatie verschuift van "genereren en filteren" naar "ervaren, repareren en verifiëren".

Executie als Controle: De centrale claim is dat browser-executie niet slechts moet worden gebruikt als een definitieve pass/fail-beoordelaar, maar als een continu controlesignaal dat ontbrekende structuur scheidt van gebroken interactie.
Datakwaliteit: Het werk toont aan dat het repareren van zwakke en gedeeltelijke pagina's onder toestand-specifieke controle sterkere supervisie oplevert voor SFT dan het simpelweg selecteren van reeds bestaande hoogwaardige pagina's.
Reproduceerbaarheid: De auteurs bieden een bevroren benchmark (HTMLBENCH) met deterministische testcases en een volledige pijplijn voor reproduceerbare vergelijking, en gaan hiermee voorbij aan agent-gebaseerde evaluaties die gebrek hebben aan gestandaardiseerde foutregistraties.

Het artikel blijft bescheiden wat betreft zijn beperkingen, en erkent dat de VLM nog steeds vereist is voor begrensd visueel ontwerpscoren, dat browserprobes niet elke mogelijke interactie kunnen dekken, en dat complexe games gekoppelde timingfouten kunnen blootleggen. Het suggereert dat toekomstig werk het leren van routing- en stoppoliën direct uit reparatiesporen zou kunnen omvatten.