AesCode Infographics Rule: la métrica determinista y su papel en la evaluación de código estético

Definición de la métrica Rule y su función dentro de la suite AesCode Infographics

La métrica Rule en el benchmark de AesCode Infographics se define como el promedio de tres comprobaciones deterministas: Text, Bound y Chart. Estas verificaciones evalúan aspectos estructurales y semánticos del código generado que pueden extraerse de forma programática del código fuente, el DOM o la renderización en el navegador.

A diferencia de las métricas visuales, que dependen de un juez VLM (Vision-Language Model) para evaluar propiedades no parseables como la jerarquía o el estilo, Rule se centra en la corrección verificable. Su función es garantizar que el código cumpla con los requisitos exactos de contenido, contención en el lienzo y estructura de datos, proporcionando una base objetiva antes de evaluar la calidad estética.

El promedio de Text, Bound y Chart reúne en una sola cifra comprobaciones distintas, no tres versiones de una misma prueba. Text atiende a si aparecen las cadenas exigidas; Bound, a si el contenido queda dentro del lienzo y respeta la relación de aspecto prevista; Chart, a si las tablas o los gráficos presentan la estructura y los datos esperados. Por eso, interpretar Rule requiere recordar qué clase de requisito observa cada componente, en vez de tratar la cifra agregada como una descripción exhaustiva del resultado.

La división entre verificaciones programáticas y juicio visual responde a la clase de evidencia disponible. Una cadena esperada puede buscarse en el texto renderizado, y ciertos límites o datos pueden contrastarse con información geométrica o estructurada. En cambio, decidir si la jerarquía de una infografía resulta clara o si su estilo es coherente no se reduce a comprobar una condición exacta del código. Rule aporta así una base acotada de corrección verificable; no convierte automáticamente esos requisitos en una medida del valor global del diseño.

Que los tres componentes se promedien facilita disponer de una métrica resumida, pero no elimina la necesidad de distinguirlos al analizar un resultado. Una puntuación agregada puede ocultar que las comprobaciones de texto, límites y gráficos no tienen por qué comportarse igual ante una misma salida. La cifra debe leerse junto con la definición de sus componentes y con el alcance de cada verificación: describe el cumplimiento de esas condiciones concretas, no cualquier propiedad que pueda importar al evaluar una infografía.

Metodología de ejecución: cómo se aplican las reglas de verificación

El harness de evaluación de AesCode requiere una renderización en un navegador (Chromium vía Playwright) y el uso de PaddleOCR para extraer texto. Cada puntuación se calcula a partir de esta renderización, no solo del código fuente, lo que asegura que la métrica refleje el resultado visual final.

El proceso implica comparar el gráfico de diseño objetivo (derivado del prompt y la imagen de referencia) con el gráfico candidato generado por el modelo. Las propiedades con evidencia estructurada en el código o medible en la renderización se asignan a los verificadores deterministas. Si un canal como PaddleOCR falla o no está presente, el canal devuelve cero en lugar de abstenerse, lo que puede corromper la recompensa si no se gestiona correctamente.

La renderización es un paso central porque el objeto de comprobación no es únicamente el texto HTML/CSS producido, sino el resultado que ese código consigue mostrar en el navegador. La extracción posterior permite contrastar la salida visible con el contenido requerido y medir aspectos del lienzo. Por ello, la puntuación depende de que el proceso de renderizado y las herramientas de lectura entreguen la evidencia que esperan los verificadores; revisar solamente el código fuente no reproduce por completo el procedimiento descrito.

El gráfico objetivo y el gráfico candidato cumplen funciones diferentes en la comparación: el primero expresa lo que debe verificarse a partir del prompt y de la imagen de referencia, mientras que el segundo representa el resultado generado por el modelo. Las reglas deterministas se aplican a las propiedades para las que existe una señal estructurada o medible. Esa asignación delimita el alcance de Rule: no toda diferencia entre ambos gráficos se convierte en una comprobación automática, especialmente cuando se trata de cualidades visuales que no se representan mediante los requisitos observables de Text, Bound o Chart.

El tratamiento de un fallo de PaddleOCR como una puntuación cero hace que la disponibilidad del canal forme parte de la interpretación del resultado. Si no se separa un problema de extracción de una ausencia real del texto, el valor devuelto puede reflejar el fallo de la herramienta además del cumplimiento del modelo. El mismo cuidado aplica a la ejecución del navegador y a los demás pasos del harness: una cifra reproducible presupone que la evaluación se ha completado con las herramientas necesarias, y no debe leerse sin considerar esa condición.

El orden de las operaciones ayuda a entender por qué la métrica se refiere a una renderización concreta: primero se obtiene una salida en Chromium; después se extrae texto y geometría; luego se aplican los verificadores de contenido, límites y datos; finalmente se promedian sus puntuaciones. Si cambia la evidencia disponible en cualquiera de esas etapas, puede cambiar el valor calculado. La descripción del flujo no autoriza a atribuir a Rule una evaluación directa de toda la imagen, sino de las propiedades que los pasos indicados logran comprobar.

Comparación con métricas visuales: estabilidad y reproducibilidad

En el benchmark de 300 instancias de infografías, los scores basados en reglas (Rule) son consistentemente más altos y estables que los scores visuales para los modelos de código cerrado evaluados. Esta estabilidad se debe a la naturaleza determinista de las comprobaciones: no dependen de la subjetividad de un modelo de lenguaje visual.

Sin embargo, esta estabilidad no implica una superioridad absoluta en la evaluación de la calidad. Mientras que Rule mide la corrección estructural, las métricas visuales (Content, Layout, Style) capturan la percepción humana del diseño. Los modelos débiles muestran una caída más pronunciada en las métricas visuales que en la compliance de reglas, lo que sugiere que Rule puede ser menos sensible a los fallos estéticos sutiles.

La estabilidad mencionada corresponde al benchmark descrito y a los modelos de código cerrado evaluados en sus 300 instancias; no establece una propiedad universal de Rule para cualquier colección de casos o configuración. Dentro de ese marco, las verificaciones deterministas tienden a producir puntuaciones más altas y estables que las visuales. La diferencia se entiende porque ambos canales observan cosas distintas: uno comprueba requisitos delimitados y el otro juzga dimensiones del diseño que no se capturan mediante esas reglas.

La divergencia entre las puntuaciones no significa que una de ellas invalide a la otra. Una salida puede ajustarse a las cadenas y a los límites exigidos y, aun así, ofrecer una jerarquía visual pobre o colores inapropiados. En ese caso, Rule aporta evidencia favorable únicamente sobre los aspectos comprobados, mientras que una puntuación visual baja señala problemas en las dimensiones evaluadas por ese canal. La lectura conjunta permite localizar la clase de diferencia sin convertir el cumplimiento estructural en una valoración estética.

La caída más pronunciada de los modelos débiles en las métricas visuales que en la compliance de reglas sugiere una sensibilidad distinta entre los canales, no una equivalencia entre puntuaciones. Rule puede pasar por alto fallos estéticos sutiles precisamente porque sus verificaciones están orientadas a contenido, contención y estructura de datos. Por tanto, una diferencia entre Rule y Visual es informativa sobre el alcance de cada métrica, pero no permite inferir por sí sola que un modelo sea competente de manera general ni fijar un umbral de competencia que el benchmark no proporciona.

Límites de la métrica Rule para evaluar la calidad estética real

La métrica Rule tiene límites inherentes para evaluar la calidad estética real. No captura propiedades como la tipografía, el uso del color, la jerarquía visual o la cohesión del diseño, que son esenciales para la percepción de 'buen diseño'. Estos aspectos se evalúan a través del canal Visual, que utiliza una rúbrica específica de muestra (VGR) y un juez VLM.

Además, la comparabilidad entre modelos puede verse afectada si la métrica Rule no captura la percepción humana del diseño. Un modelo puede tener una Rule alta pero una Visual baja, lo que indica que el código es estructuralmente correcto pero estéticamente deficiente. Por lo tanto, Rule debe interpretarse como una métrica de corrección, no de calidad estética.

El límite de Rule no es un defecto accidental que se corrija interpretando la cifra con más confianza: deriva de que sus pruebas se ocupan de condiciones verificables, mientras que la tipografía, el color, la jerarquía y la cohesión pertenecen a dimensiones que la métrica no captura. Una salida puede satisfacer lo comprobado y seguir siendo poco atractiva o poco cohesionada. Por esa razón, la puntuación expresa cumplimiento estructural dentro del marco definido, no una aprobación general del diseño.

El canal Visual complementa a Rule al abordar propiedades que no se resuelven con las comprobaciones deterministas y al emplear una rúbrica específica de muestra junto con un juez VLM. Esa complementariedad no significa que las métricas sean intercambiables ni que una cifra visual deba corregir o reemplazar la cifra Rule. Cada resultado responde a una pregunta diferente: si se cumplen determinadas condiciones estructurales y de contenido, por un lado, y cómo se valoran las dimensiones visuales evaluadas, por otro.

Para comparar resultados conviene conservar explícita esta separación conceptual. Una Rule alta no garantiza que la tipografía, los colores o la jerarquía sean adecuados; una Visual baja tampoco demuestra, por sí sola, que hayan fallado las comprobaciones de contenido, contención o estructura de gráficos. Cuando ambas cifras divergen, la conclusión prudente es que los canales están señalando aspectos distintos del resultado. No hay base aquí para convertir esa divergencia en una categoría universal de calidad ni para afirmar que exista un nivel de Rule que asegure un diseño atractivo.

Impacto en la comparabilidad entre modelos y conclusiones

El uso de Rule como métrica separada permite una evaluación más granular de los modelos de generación de código. Al separar la corrección de la calidad visual, los equipos pueden identificar si un modelo falla por errores estructurales o por limitaciones estéticas. Esto es crucial para la integración en pipelines de producción, donde la corrección es un requisito previo a la calidad.

Los resultados de AesCode muestran que los modelos de código cerrado tienden a tener scores más altos en Rule que en Visual, con Style siendo la dimensión más débil. Esto sugiere que la corrección estructural es más fácil de lograr que la calidad estética, y que las métricas deterministas como Rule son útiles pero insuficientes para una evaluación completa de la calidad del diseño.

Separar Rule de Visual ofrece un diagnóstico más granular porque permite distinguir, dentro de las dimensiones medidas, entre requisitos estructurales verificables y valoración visual. Esa distinción puede ayudar a identificar si un resultado presenta errores en las comprobaciones de código, contenido o límites, o si sus dificultades aparecen en las dimensiones estéticas. Sin embargo, la granularidad depende de que se interprete cada puntuación según su definición; el promedio Rule no identifica por sí solo cuál de sus tres componentes explica un resultado ni reemplaza el examen del canal visual.

En el benchmark de 300 instancias con imagen de referencia, los valores de la tabla muestran Rule por encima de Visual para los modelos seleccionados. Esa comparación concreta acompaña la observación de que Style es la dimensión más débil, pero no debe extrapolarse más allá de los modelos, las instancias y la configuración descritos. Tampoco convierte los valores en una escala común de calidad estética: Rule y Visual corresponden a evaluaciones diferentes, de modo que su distancia sirve para describir el patrón observado, no para establecer por sí sola una medida universal de superioridad.

La utilidad de la métrica depende también de mantener visible su alcance cuando se emplea para comparar modelos. Si las reglas solo cubren cadenas, límites y estructura de tablas o gráficos, las diferencias en Rule describen el desempeño en esas comprobaciones y no todos los motivos posibles por los que una infografía puede resultar mejor o peor. Para una lectura completa de los resultados, es necesario considerar simultáneamente las métricas visuales mencionadas, en particular porque la calidad estética puede variar sin que cambien de forma equivalente las verificaciones estructurales.

La conclusión respaldada por los resultados es acotada: en el conjunto descrito, los modelos de código cerrado tienden a obtener puntuaciones Rule mayores que Visual, mientras que Style aparece como la dimensión más débil. Esto sugiere que cumplir condiciones estructurales puede resultar más alcanzable que lograr la calidad estética valorada por el canal visual, pero no demuestra que la corrección sea siempre más fácil en cualquier situación. Rule es útil para hacer explícito un tipo de cumplimiento y es insuficiente, por diseño, para resumir por sí sola la calidad del diseño.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.