DesignBench: A Comprehensive Benchmark for MLLM-based Front-end Code Generation

Dit paper introduceert DesignBench, een uitgebreide benchmark die multimodale grote taalmodellen evalueert op hun vermogen om front-end code te genereren, bewerken en repareren binnen meerdere populaire frameworks en diverse realistische ontwikkelingstaken.

De kern

DesignBench: De "Rijexamen" voor AI's die websites bouwen

Stel je voor dat je een zeer slimme, creatieve robot hebt die je kunt vragen om een huis te bouwen. Je geeft de robot een foto van een droomhuis, en hij moet de blauwdrukken (de code) tekenen zodat een aannemer het kan bouwen.

Vroeger konden deze robots alleen simpele houten hutten maken. Maar nu, in de moderne wereld, bouwen we complexe appartementencomplexen met specifieke regels voor elke kamer (React, Vue, Angular). De onderzoekers van dit paper, DesignBench, hebben een nieuwe test ontwikkeld om te kijken hoe goed deze robots echt zijn in het bouwen van die moderne huizen.

Hier is wat ze hebben ontdekt, vertaald naar alledaags taal:

1. Het Probleem: De oude tests waren te makkelijk

Vroeger testten ze de robots alleen op het bouwen van simpele hutten (gewone HTML/CSS). Maar in het echte leven bouwen mensen geen hutten meer; ze bouwen complexe gebouwen met specifieke bouwstijlen.

• Het gebrek: De oude tests keken alleen of de robot de eerste versie kon maken. Ze keken niet of de robot ook kon renoveren (als je zegt: "zet de muur blauw") of kon repareren (als er een raam scheef hangt).
• De oplossing: DesignBench is een nieuwe, zware test die drie dingen checkt:
  1. Bouwen: Maak een huis van een foto.
  2. Renoveren: Pas het huis aan op basis van een verzoek.
  3. Repareren: Vind en fix fouten in het huis.

2. De Testbaan: 900 huizen in 3 stijlen

De onderzoekers hebben 900 verschillende webpagina's (hun "huizen") verzameld. Ze hebben deze getest in de drie populairste "bouwstijlen" van vandaag: React, Vue en Angular.

• Vergelijking: Stel je voor dat React, Vue en Angular drie verschillende talen zijn waarin architecten spreken. De robot moet niet alleen de foto begrijpen, maar ook in die specifieke taal kunnen praten.

3. De Resultaten: De robot is slim, maar nog niet perfect

Hier zijn de belangrijkste ontdekkingen, vertaald in analogieën:

• Grote robots zijn beter dan kleine:
  De "grote" AI-modellen (zoals Claude-3.7 of GPT-4o) bouwen veel betere huizen dan de "kleine" modellen. Het is alsof een meester-architect veel minder fouten maakt dan een leerling.

• De bouwstijl maakt uit:
  De robots zijn het allerbeste in het bouwen van simpele hutten (gewone HTML). Maar zodra ze moeten bouwen in de complexe stijlen (zoals Angular), maken ze veel meer fouten.

  • Vergelijking: Het is alsof de robot gewend is om met Lego te bouwen, maar plotseling moet hij werken met ingewikkelde stalen constructies. Hij raakt dan de draad kwijt en maakt syntax-fouten (fouten in de regels van de taal).

• Het moeilijkste is niet bouwen, maar repareren:
  Het bouwen van een huis van nul af gaat nog redelijk. Maar als je de robot vraagt: "Vind die ene deur die scheef staat en maak hem recht", dan komt hij in de problemen.

  • Vergelijking: De robot kan een hele nieuwe kamer schilderen, maar als je vraagt om alleen de lijstjes op de deur te vervangen, kijkt hij vaak naar de verkeerde deur of schildert hij de hele muur verkeerd. Hij heeft moeite om precies te zien waar hij moet grijpen.

• Tekst is beter dan foto's voor aanpassingen:
  Een verrassende ontdekking: Als je de robot een foto van het huis én de bouwtekeningen geeft, doet hij het niet veel beter dan als je hem alleen de bouwtekeningen geeft.

  • Vergelijking: Als je een robot vraagt om een raam te verplaatsen, helpt het niet om een foto van het raam te tonen. De robot begrijpt de instructie ("verplaats het raam") veel beter als hij de technische specificaties (de code) leest. De foto voegt weinig extra waarde toe voor deze specifieke taken.

• Geen "herbruikbare" onderdelen:
  Moderne bouwtechniek gaat over het maken van herbruikbare onderdelen (bijvoorbeeld: "maak een standaard deur die we 10 keer gebruiken"). De robots maken echter vaak 10 keer dezelfde deur apart, in plaats van één keer een sjabloon te maken.

  • Vergelijking: In plaats van een stempel te gebruiken om 100 identieke koekjes te maken, snijdt de robot 100 koekjes één voor één uit met een mes. Het werkt, maar het is niet slim of efficiënt.

4. Wat betekent dit voor de toekomst?

De onderzoekers geven twee adviezen:

1. Voor de robotbouwers (onderzoekers): Je moet de robots meer laten oefenen met de specifieke bouwstijlen (React, Vue, Angular) en hen leren om "sjablonen" te gebruiken in plaats van alles handmatig te maken.
2. Voor de mensen die de robots gebruiken (ontwikkelaars):
   • Wees niet te vaag. Zeg niet "maak het mooier", maar "verander de knop in de hoek".
   • Als je een fout wilt laten repareren, geef dan aan waar de fout zit. Laat de robot niet raden.
   • Breek grote taken op in kleine stukjes. Vraag niet om een heel complex gebouw in één keer, maar bouw het kamer voor kamer.

Kortom: DesignBench laat zien dat AI's al indrukwekkend zijn in het bouwen van websites, maar ze zijn nog niet klaar voor de complexe, echte wereld van professionele webontwikkeling. Ze moeten nog leren om precies te zijn, fouten te vinden en slimme, herbruikbare patronen te gebruiken.

Technische samenvatting

Probleemstelling

Multimodale Large Language Models (MLLMs) hebben indrukwekkende prestaties geleverd bij het genereren van UI-code vanuit visuele ontwerpen. Echter, bestaande benchmarks voor front-end codegeneratie vertonen drie fundamentele tekortkomingen die hen ongeschikt maken voor het evalueren van modellen in realistische development-scenario's:

1. Gebrek aan framework-integratie: Moderne front-end ontwikkeling is grotendeels gebaseerd op frameworks zoals React, Vue en Angular. Bestaande benchmarks focussen echter voornamelijk op "vanilla" HTML/CSS, waardoor de capaciteiten van MLLMs voor framework-gebaseerde ontwikkeling niet worden getest.
2. Onvoldoende taakdekking: Bestaande evaluaties beperken zich tot de initiële generatie van code. In de praktijk omvat front-end ontwikkeling echter een iteratief proces dat ook het bewerken (refineren van ontwerpen) en repareren (oplossen van weergaveproblemen) van code omvat.
3. Beperkte evaluatiedimensies: Huidige benchmarks gebruiken vaak een eenzijdige evaluatie (bijv. alleen visuele overeenkomst) zonder diepgaande analyse van factoren zoals taakcomplexiteit, variaties in inputcontext (code vs. afbeelding) en code-kwaliteitsmetrieken (zoals correctheid en herbruikbaarheid).

Methodologie: DesignBench

Om deze kloof te dichten, stellen de auteurs DesignBench voor, een uitgebreid benchmark voor het evalueren van MLLMs in geautomatiseerde front-end engineering.

1. Dataset en Opbouw:

• Omvang: De dataset bevat 900 webpagina-sample's afkomstig van real-world bronnen (GitHub-projecten, Top 500 websites, Vercel/Vue0 interactiegeschiedenis).
• Frameworks: Het dekt vier technologieën: Vanilla HTML/CSS, React, Vue en Angular.
• Drie Kerntaken:
  • Design Generation: Code genereren vanuit een UI-mockup.
  • Design Edit: Bestaande code aanpassen op basis van natuurlijke taal-instructies (bijv. "verander de achtergrond naar blauw").
  • Design Repair: UI-problemen (zoals overlappende elementen of verkeerde uitlijning) detecteren en de code repareren.
• Annotatie: De dataset is zorgvuldig geannoteerd door PhD-studenten met front-end ervaring. Er zijn 11 onderwerpen, 9 bewerkings-types en 6 categorieën van UI-problemen (zoals occlusie, overloop, uitlijning) vastgelegd.

2. Evaluatie-Metrieken:
De auteurs gebruiken een combinatie van visuele, code-gebaseerde en LLM-gebaseerde beoordelingen:

• Visueel: CLIP (semantische similariteit) en SSIM (structurele similariteit).
• Code: Compilation Success Rate (CSR), Code Modification Location Similarity (CMLS) en Code Modification Content Similarity (CMCS).
• MLLM-as-Judge: GPT-4o wordt ingezet om de kwaliteit van bewerkingen en reparaties te beoordelen op een schaal van 0-10, gevalideerd door menselijke evaluatie (Kappa-score > 0.84).

3. Experimenteel Setup:
Negen toonaangevende MLLMs (waaronder Claude-3.7, GPT-4o, Gemini-2.0, Llama, Pixtral en Qwen) werden getest op deze benchmark. De evaluatie analyseerde prestaties op basis van taaktype, framework, moeilijkheidsgraad en inputcontext.

Belangrijkste Bijdragen

1. Eerste Multi-Framework, Multi-Taak Benchmark: DesignBench is de eerste benchmark die MLLMs evalueert op HTML/CSS én de drie dominante frameworks (React, Vue, Angular) voor generatie, bewerking en reparatie.
2. Uitgebreide Evaluatie: Het biedt een diepgaande analyse over meerdere dimensies, inclusief moeilijkheidsgraad (visuele complexiteit, instructie-complexiteit), inputmodaliteiten (alleen code vs. alleen afbeelding vs. multimodaal) en code-metrieken.
3. Inzichtelijke Analyse: Het paper identificeert 22 soorten fouten en biedt gedetailleerde inzichten in de beperkingen van huidige modellen, wat leidt tot concrete richtlijnen voor toekomstig onderzoek en praktijk.

Resultaten en Kerninzichten

De experimenten leverden de volgende cruciale bevindingen op:

• Framework-specifieke beperkingen: MLLMs presteren aanzienlijk slechter in framework-gebaseerde ontwikkeling dan in vanilla HTML/CSS. Ze worstelen met framework-specifieke syntax (bijv. JSX in React, templates in Vue, TypeScript in Angular) en gebruiken zelden component-gebaseerde ontwerpen (herbruikbaarheid), zelfs niet in frameworks die daarvoor ontworpen zijn.
• Taak-specifieke knelpunten:
  • Generatie: De grootste uitdagingen zijn compilatiefouten en visuele onnauwkeurigheden.
  • Bewerken & Repareren: De beperkende factor is de lokalisatie van code. Modellen kunnen vaak wel de instructie begrijpen, maar falen in het exact identificeren van welke code-segmenten aangepast moeten worden.
• Invloed van inputcontext: Voor bewerkings- en reparatietaken presteert alleen code-input consistent beter dan alleen afbeelding-input. Multimodale input (code + afbeelding) leverde geen significante verbetering op, wat suggereert dat semantische informatie in code voor deze taken belangrijker is dan visuele data.
• Moeilijkheidsgraad: De prestaties van MLLMs verslechteren aanzienlijk bij complexe scenario's: grote UI-afbeeldingen, complexe instructies en ernstige UI-problemen leiden tot catastrofale fouten bij kleinere modellen.
• Foutpatronen:
  • Bij generatie: Fouten in ruimtelijke redenering (grootte/positie) en ontbrekende elementen.
  • Bij bewerken: Problemen met het beheersen van de reikwijdte (onnodige wijzigingen of onvolledige bewerkingen).
  • Bij reparatie: Fundamentele onbekwaamheid om defecten correct te identificeren en op te lossen.

Significantie en Implicaties

DesignBench markeert een verschuiving in de evaluatie van MLLMs voor software-engineering. Het toont aan dat hoewel modellen goed zijn in het genereren van basis-HTML, ze nog niet klaar zijn voor professionele, framework-gebaseerde ontwikkeling zonder menselijke tussenkomst.

Aanbevelingen voor onderzoek en praktijk:

• Onderzoek: Trainingsdata moet worden verrijkt met framework-specifieke patronen en component-gebaseerde ontwerpen. Er is meer aandacht nodig voor effectieve fusie van visuele en code-informatie.
• Ontwikkelers: Gebruikers van MLLMs moeten complexe taken opsplitsen in kleinere, atomische taken. Voor bewerkings- en reparatietaken is het essentieel om de exacte locatie van de wijziging en de specifieke problemen expliciet te specificeren, aangezien modellen moeite hebben met zelfstandige diagnose en code-lokalisatie.

Kortom, DesignBench biedt een robuust fundament om de huidige staat van de kunst te meten en richt de weg naar de volgende generatie MLLMs die daadwerkelijk inzetbaar zijn in real-world front-end development workflows.