AesCode Infographics Rule: a métrica determinística e seu papel na avaliação de código estético

Definição da métrica Rule e sua função dentro da suíte AesCode Infographics

A métrica Rule no benchmark AesCode Infographics é definida como a média de três verificações determinísticas: Text, Bound e Chart. Estas verificações avaliam aspectos estruturais e semânticos do código gerado que podem ser extraídos programaticamente do código-fonte, do DOM ou da renderização no navegador.

Diferentemente das métricas visuais, que dependem de um juiz VLM (Vision-Language Model) para avaliar propriedades não parseáveis como hierarquia ou estilo, a Rule foca na correção verificável. Sua função é garantir que o código cumpra os requisitos exatos de conteúdo, contenção no canvas e estrutura de dados, fornecendo uma base objetiva antes de avaliar a qualidade estética.

A média de Text, Bound e Chart reúne verificações diferentes em uma única pontuação, não três versões da mesma prova. Text examina se as strings exigidas aparecem; Bound verifica se o conteúdo cabe no canvas e se respeita a proporção prevista; Chart avalia a estrutura e os dados de tabelas ou gráficos. Para interpretar Rule, portanto, é importante considerar o requisito observado por cada componente, em vez de tratar a pontuação agregada como uma descrição completa do resultado.

A separação entre verificações programáticas e julgamento visual acompanha os tipos de evidência que cada método consegue avaliar. Uma string esperada pode ser procurada no texto renderizado, enquanto certos limites e dados podem ser confrontados com informações geométricas ou estruturadas. Já decidir se a hierarquia de um infográfico é clara ou se seu estilo é coerente não se reduz à conferência de uma condição exata do código. Rule fornece uma base delimitada de correção verificável; não transforma automaticamente esses requisitos em uma medida do valor global do design.

Calcular a média dos três componentes facilita resumir o resultado, mas não elimina a necessidade de distingui-los durante a análise. As verificações de texto, limites e gráficos podem responder de maneiras diferentes diante da mesma saída. A pontuação deve ser lida junto com a definição dos componentes e com o alcance de cada verificação: ela descreve o cumprimento das condições avaliadas, não todas as propriedades relevantes para julgar um infográfico.

Metodologia de execução: como as regras de verificação são aplicadas

O harness de avaliação do AesCode requer uma renderização em um navegador (Chromium via Playwright) e o uso de PaddleOCR para extrair texto. Cada pontuação é calculada a partir desta renderização, não apenas do código-fonte, o que garante que a métrica reflita o resultado visual final.

O processo envolve comparar o gráfico de design objetivo (derivado do prompt e da imagem de referência) com o gráfico candidato gerado pelo modelo. As propriedades com evidência estruturada no código ou mensurável na renderização são atribuídas aos verificadores determinísticos. Se um canal como o PaddleOCR falhar ou não estiver presente, o canal retorna zero em vez de se abster, o que pode corromper a recompensa se não for gerenciado corretamente.

A renderização ocupa um lugar central porque o objeto avaliado não é apenas o HTML/CSS produzido, mas também o resultado que esse código apresenta no navegador. A extração posterior permite comparar a saída visível com o conteúdo exigido e medir aspectos do canvas. Assim, a pontuação depende de o processo de renderização e as ferramentas de leitura fornecerem os dados esperados pelos verificadores. Examinar somente o código-fonte não reproduz por completo o procedimento descrito.

O gráfico objetivo e o gráfico candidato desempenham funções distintas na comparação: o primeiro expressa o que deve ser verificado a partir do prompt e da imagem de referência; o segundo representa o resultado gerado pelo modelo. As regras determinísticas se aplicam às propriedades para as quais existe um sinal estruturado no código ou mensurável na renderização. Essa divisão delimita o alcance de Rule: nem toda diferença entre os gráficos se torna uma verificação automática, sobretudo quando envolve qualidades visuais que não correspondem aos requisitos observáveis de Text, Bound ou Chart.

Quando uma falha do PaddleOCR resulta em pontuação zero, a disponibilidade desse canal passa a fazer parte da interpretação do resultado. Se um problema de extração não for distinguido da ausência real do texto, o valor pode refletir a falha da ferramenta além do cumprimento pelo modelo. O mesmo cuidado se aplica à execução do navegador e às demais etapas do harness: a interpretação do resultado pressupõe que a avaliação tenha sido concluída com as ferramentas necessárias.

A ordem das operações ajuda a entender por que a métrica se refere a uma renderização específica: primeiro, o código é apresentado no Chromium; depois, são extraídos texto e geometria; em seguida, os verificadores avaliam conteúdo, limites e dados; por fim, as três pontuações são reunidas em uma média. Se os dados disponíveis mudarem em alguma dessas etapas, o valor calculado também poderá mudar. Esse fluxo não significa que Rule avalie diretamente a imagem inteira, mas apenas as propriedades que as operações descritas conseguem verificar.

Comparação com métricas visuais: estabilidade e reprodutibilidade

No benchmark de 300 instâncias de infográficos, os scores baseados em regras (Rule) são consistentemente mais altos e estáveis do que os scores visuais para os modelos de código fechado avaliados. Esta estabilidade deve-se à natureza determinística das verificações: elas não dependem da subjetividade de um modelo de linguagem visual.

No entanto, esta estabilidade não implica uma superioridade absoluta na avaliação da qualidade. Enquanto a Rule mede a correção estrutural, as métricas visuais (Content, Layout, Style) capturam a percepção humana do design. Modelos mais fracos mostram uma queda mais acentuada nas métricas visuais do que na conformidade com as regras, o que sugere que a Rule pode ser menos sensível a falhas estéticas sutis.

A estabilidade mencionada se refere ao benchmark descrito e aos modelos de código fechado avaliados em suas 300 instâncias; ela não estabelece uma característica universal de Rule para qualquer conjunto de casos ou configuração. Nesse contexto, as verificações determinísticas tendem a produzir pontuações mais altas e estáveis do que as visuais. A diferença acompanha o fato de que os canais observam aspectos distintos: um verifica requisitos delimitados, enquanto o outro avalia dimensões de design que essas regras não capturam.

A divergência entre as pontuações não significa que uma delas invalide a outra. Uma saída pode atender às strings e aos limites exigidos e, ainda assim, apresentar hierarquia visual fraca ou cores inadequadas. Nesse caso, Rule oferece uma avaliação favorável somente para os aspectos verificados, enquanto uma pontuação visual baixa indica problemas nas dimensões avaliadas por esse canal. A leitura conjunta permite distinguir esses aspectos sem transformar conformidade estrutural em julgamento estético.

A queda mais acentuada dos modelos mais fracos nas métricas visuais do que na conformidade com as regras indica uma sensibilidade diferente entre os canais, não uma equivalência entre suas pontuações. Rule pode deixar passar falhas estéticas sutis justamente porque suas verificações se concentram em conteúdo, contenção e estrutura de dados. Uma diferença entre Rule e Visual informa sobre o alcance de cada métrica, mas, isoladamente, não permite concluir que um modelo tenha competência geral nem estabelecer um limiar de competência que o benchmark não fornece.

Limites da métrica Rule para avaliar a qualidade estética real

A métrica Rule tem limites inerentes para avaliar a qualidade estética real. Ela não captura propriedades como tipografia, uso de cor, hierarquia visual ou coesão do design, que são essenciais para a percepção de 'bom design'. Estes aspectos são avaliados através do canal Visual, que utiliza uma rubrica específica de amostra (VGR) e um juiz VLM.

Além disso, a comparabilidade entre modelos pode ser afetada se a métrica Rule não capturar a percepção humana do design. Um modelo pode ter uma Rule alta, mas uma Visual baixa, o que indica que o código é estruturalmente correto, mas esteticamente deficiente. Portanto, a Rule deve ser interpretada como uma métrica de correção, não de qualidade estética.

O limite de Rule decorre do tipo de condição que suas verificações avaliam: enquanto elas examinam aspectos verificáveis, tipografia, cor, hierarquia e coesão pertencem a dimensões que a métrica não captura. Uma saída pode cumprir os requisitos verificados e ainda parecer pouco atraente ou pouco coesa. Por isso, a pontuação expressa conformidade estrutural dentro do escopo definido, não uma aprovação geral do design.

O canal Visual complementa Rule ao avaliar propriedades que não são resolvidas pelas verificações determinísticas, usando uma rubrica específica de amostra e um juiz VLM. Essa complementaridade não torna as métricas intercambiáveis, nem significa que a pontuação visual deva corrigir ou substituir a pontuação Rule. Cada resultado responde a uma pergunta diferente: se determinadas condições estruturais e de conteúdo foram cumpridas e como as dimensões visuais avaliadas foram julgadas.

Manter essa distinção explícita ajuda a interpretar comparações. Uma pontuação Rule alta não garante tipografia, cores ou hierarquia adequadas; uma pontuação Visual baixa, por sua vez, não demonstra que as verificações de conteúdo, contenção ou estrutura dos gráficos tenham falhado. Quando os canais divergem, a conclusão prudente é que apontam para aspectos diferentes do resultado. Essa divergência não define uma categoria universal de qualidade nem indica que exista uma pontuação Rule que assegure um design atraente.

Impacto na comparabilidade entre modelos e conclusões

O uso da Rule como métrica separada permite uma avaliação mais granular dos modelos de geração de código. Ao separar a correção da qualidade visual, as equipes podem identificar se um modelo falha por erros estruturais ou por limitações estéticas. Isso é crucial para a integração em pipelines de produção, onde a correção é um pré-requisito para a qualidade.

Os resultados do AesCode mostram que os modelos de código fechado tendem a ter scores mais altos na Rule do que na Visual, com Style sendo a dimensão mais fraca. Isso sugere que a correção estrutural é mais fácil de alcançar do que a qualidade estética, e que métricas determinísticas como a Rule são úteis, mas insuficientes para uma avaliação completa da qualidade do design.

Separar Rule de Visual permite um diagnóstico mais detalhado ao distinguir requisitos estruturais verificáveis da avaliação visual. Essa divisão pode ajudar a identificar se um resultado apresenta falhas nas verificações de código, conteúdo ou limites, ou se suas dificuldades aparecem nas dimensões estéticas. Esse diagnóstico depende, porém, de interpretar cada pontuação conforme sua definição: a média Rule, por si só, não identifica qual dos três componentes explica o resultado nem substitui a avaliação visual.

No benchmark de 300 instâncias com imagem de referência, os valores da tabela mostram Rule acima de Visual para os modelos selecionados. Essa comparação acompanha a observação de que Style é a dimensão mais fraca, mas não deve ser extrapolada para além dos modelos, das instâncias e da configuração descritos. Os valores tampouco formam uma escala comum de qualidade estética: Rule e Visual avaliam aspectos diferentes. A distância entre as pontuações descreve o padrão observado, mas não estabelece, sozinha, uma medida universal de superioridade.

A utilidade da métrica depende de manter visível seu alcance ao comparar modelos. Se as regras cobrem strings, limites e estrutura de tabelas ou gráficos, diferenças em Rule descrevem o desempenho nessas verificações, não todos os motivos possíveis para um infográfico parecer melhor ou pior. Uma leitura abrangente dos resultados requer considerar também as métricas visuais mencionadas, pois a qualidade estética pode variar sem uma mudança equivalente nas verificações estruturais.

A conclusão sustentada pelos resultados é delimitada: no conjunto descrito, os modelos de código fechado tendem a obter pontuações Rule maiores do que Visual, enquanto Style aparece como a dimensão mais fraca. Isso sugere que cumprir condições estruturais pode ser mais alcançável do que obter a qualidade estética avaliada pelo canal visual, mas não demonstra que a correção seja sempre mais fácil em qualquer situação. Rule ajuda a explicitar um tipo de conformidade e, por seu escopo, não basta para resumir a qualidade do design.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.