🤖 AI

Vector-Bench: Can Models Surgically Edit SVG Code?

El artículo presenta Vector-Bench, un riguroso banco de pruebas de 40 tareas de reparación de SVG diseñadas para evaluar la edición vectorial basada en instrucciones, revelando que incluso los modelos más fuertes tienen dificultades para aplicar quirúrgicamente los cambios solicitados sin alterar los elementos no solicitados, logrando solo un 15,0% de éxito de especificación completa.

Autores originales: Yug Aditi Gupta, Prannay Hebbar

Publicado 2026-07-22

📖 4 min de lectura☕ Lectura para el café

CC BY 4.0

Autores originales: Yug Aditi Gupta, Prannay Hebbar

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que le estás enseñando a un robot a ser un artista digital. Le das una imagen hecha de código —como un dibujo digital construido a partir de instrucciones en lugar de pintura— y le dices: "Oye, el sol en esta imagen es demasiado grande; encoíjalo, pero no toques las nubes ni las montañas". Este es el mundo de los gráficos vectoriales. A diferencia de una foto estándar, que es solo una cuadrícula de puntos de colores, una imagen vectorial es un programa vivo. Es una lista de comandos que le dice a una computadora cómo dibujar líneas, formas y colores. Debido a que es código, si el robot cambia la línea equivocada, no solo hace que la imagen se vea rara; podría romper todo el archivo, haciendo que sea imposible de abrir o editar más tarde.

La gran pregunta que se hacen los científicos es: ¿Pueden estos modelos de IA seguir realmente instrucciones para arreglar una parte específica de este código sin estropear el resto? Es un poco como pedirle a un chef que reemplace la sal en una sopa sin cambiar la temperatura, la olla o la receta del pan que acompaña al plato. Si la IA simplemente hace que la sopa sepa bien pero quema el pan, es un fracaso. Incluso si la sopa se ve bien, si el pan se quemó, falló. Este es el desafío de la edición basada en instrucciones: hacer exactamente lo que pediste, y solo lo que pediste, manteniendo la estructura invisible del código perfecta.

Entra en escena Vector-Bench, una prueba nueva y complicada diseñada para ver si los modelos de IA pueden ser realmente editores quirúrgicos. Los investigadores crearon 40 acertijos específicos donde una imagen SVG está "corrupta": tal vez la puerta de un tren está flotando en el lugar equivero, o una medusa ha perdido sus tentáculos. Le dieron a los modelos de IA una instrucción sencilla en lenguaje humano como: "La señal ámbar se ha apagado; arréglala y deja la estación en paz". Los modelos tenían que reescribir el código para arreglar la señal sin mover accidentalmente el tren, borrar la plataforma de la estación o romper el formato del archivo.

Los resultados fueron un golpe de realidad. Los investigadores probaron 34 modelos de IA diferentes, que iban desde los pequeños y baratos hasta los modelos "frontera" más potentes disponibles. El modelo con mejor desempeño, Claude Sonnet 5, logró completar todo el trabajo perfectamente —arreglando el error, manteniendo todo lo demás a salvo y produciendo un archivo válido— solo el 15.0% de las veces. Así es: incluso la IA más inteligente falló en seguir las instrucciones completas en más de 8 de cada 10 intentos.

Sin embargo, la historia no trata solo de fracasos; trata de cómo fallaron. El artículo encontró que los modelos eran en realidad bastante buenos en la parte de "arreglar". En promedio, lograban realizar progresos visibles en las reparaciones solicitadas aproximadamente el 43.7% de las veces. A menudo podían hacer que la señal fuera más brillante o acercar la puerta. Pero eran terribles en la parte de "dejar el resto en paz". Con frecuencia renombraban cosas que no debían, desplazaban objetos no relacionados o rompían la estructura del código de modo que el archivo resultaba inválido.

El estudio descarta explícitamente la idea de que "verse bien" es lo mismo que "funcionar correctamente". Un modelo puede producir una imagen que parezca arreglada para el ojo humano, pero si el código subyacente ha sido reescrito o dañado, es un fracaso. Los investigadores demostraron esto utilizando un juez computarizado estricto que no solo revisa la imagen, sino también el código mismo. Encontraron que, si bien los modelos pueden realizar algunas reparaciones, la capacidad de editar el código de forma quirúrgica sin daños colaterales sigue siendo un gran obstáculo.

En resumen, el artículo sugiere que, aunque la IA está mejorando en el dibujo y la reparación de imágenes, todavía lucha por ser un editor preciso y cuidadoso del código que hace que esas imágenes funcionen. La brecha entre "realizar un cambio" y "realizar el cambio correcto sin romper nada más" sigue siendo amplia. Los autores publicaron todos sus datos, código y resultados, demostrando que incluso los modelos más caros y potentes son actualmente más como pasantes entusiastas que arreglan el problema pero accidentalmente derriban la estantería, en lugar de los cirujanos precisos que necesitamos para la edición de arte digital.

Resumen Técnico: Vector-Bench

Definición del Problema
La edición de vectores basada en instrucciones requiere que un modelo ejecute un cambio específico preservando la totalidad de la estructura de código circundante. Mientras que las métricas de generación de imágenes de mapa de bits (raster) suelen juzgar el éxito basándose en la apariencia visual final, este enfoque es insuficiente para los Gráficos Vectoriales Estructurados (SVG). En SVG, las diferencias "cosméticas" —como renombrar elementos, reescribir datos de trayectorias (paths), desplazar objetos no relacionados o eliminar metadatos— alteran la semántica del artefacto ejecutable. Los benchmarks actuales suelen fallar al distinguir entre un modelo que edita con éxito un defecto visual y uno que corrompe inadvertidamente la estructura del programa subyacente. El desafío central es definir una señal de recompensa que verifique simultáneamente las reparaciones solicitadas, imponga la preservación semántica de los elementos no solicitados y garantice que la salida sea un SVG válido y utilizable.

Metodología: Vector-Bench
Los autores presentan Vector-Bench, un benchmark compacto y de alta densidad que consta de 40 tareas de reparación de SVG. El benchmark está diseñado para probar capacidades de edición "quirúrgica" a través de los siguientes componentes:

Estructura de la Tarea: Cada tarea $\tau$ empareja un SVG corrupto ( $S_0$ ) con una instrucción en lenguaje natural escrita por un autor ( $x$ ). La instrucción describe defectos visibles (por ejemplo, "la señal ámbar se ha apagado") sin exponer identificadores del DOM, coordenadas, códigos de color o datos de trayectoria. La verdad de campo (ground truth) es un SVG objetivo oculto ( $S^*$ ).
Anotaciones: El conjunto de datos incluye 202 reparaciones anotadas a través de 40 tareas (promediando 5.05 reparaciones por tarea) y define un conjunto de "objetos protegidos" (promediando 60.55 por tarea) que deben permanecer sin cambios.
Evaluación Ejecutable: Los autores proponen una recompensa de especificación binaria y determinista ( $R_{spec}$ $R_{s p ec}$ ) basada en un sistema de tres puertas:
1. Puerta de Validez: La salida debe ser un SVG bien formado y válido con referencias resolubles.
2. Puerta de Edición Solicitada: Para cada edición solicitada $e$ , un predicado sensible a los atributos verifica la salida contra el objetivo. Esto utiliza tolerancias perceptuales (por ejemplo, $\Delta E_{76}$ de CIE Lab para color, RMS para coordenadas y muestreo de trayectorias) en lugar de una coincidencia exacta de cadenas, permitiendo comandos SVG equivalentes que producen el mismo resultado visual.
3. Puerta de Preservación: La parte no solicitada del documento (enmascarada por las ubicaciones de la edición) debe permanecer semánticamente sin cambios. Esto verifica la integridad estructural, el orden de los elementos y la ausencia de modificaciones no deseadas en los objetos protegidos.
Métricas de Diagnóstico: Más allá del paso/fallo binario, el marco rastrea el "Progreso de la Reparación" (qué tan cerca está la salida del objetivo dentro de las tolerancias) y la "Tasa de Cambio No Intencionado" (UCR) para cuantificar el daño colateral.

Contribuciones Clave

Un Corpus Congelado: Un conjunto denso de 40 tareas de reparación de SVG descritas por autores con ediciones pretendidas explícitas y amplias superficies de preservación, donde las instrucciones dependen únicamente de descripciones visuales.
Un Evaluador Transparente: Un protocolo de evaluación ejecutable que combina comprobaciones de edición tolerantes con estrictas puertas de preservación semántica y validez, evitando jueces aprendidos o calificadores basados en modelos.
Evaluación Exhaustiva: Un estudio reproducible de 34 endpoints de modelos (25 de pesos abiertos, 5 controles económicos, 4 modelos cerrados de frontera) a través de 1,360 solicitudes, liberando todos los prompts, salidas, código de puntuación y costos.
Análisis de Brecha Empírica: Un recuento detallado de la divergencia entre completar reparaciones visibles y preservar la estructura completa del programa vectorial.

Resultados
La evaluación de 34 modelos revela una brecha significativa entre la capacidad de reparación visual y la edición fiel a la especificación:

Bajo Éxito Total: El endpoint más fuerte, Claude Sonnet 5, logró solo un 15.0% de éxito de especificación total (satisfaciendo las tres puertas). A través de los 1,360 resultados, solo el 2.35% pasó todas las puertas.
Alto Progreso Parcial: A pesar del bajo éxito total, el mejor modelo alcanzó un 43.7% de progreso de reparación medio, lo que indica que los modelos a menudo realizan los cambios visuales solicitados pero fallan en la preservación o la validez.
Problemas de Validez y Preservación: Muchos modelos produjeron SVGs inválidos o introdujeron cambios no deseados. Para el modelo superior, la validez de SVG fue del 62.5%, y la Tasa de Cambio No Intencionado (UCR) de la salida válida fue de 0.8%.
Modos de Fallo: La mayoría de los fallos se debieron a salidas incompletas o inutilizables (por ejemplo, truncamiento, XML inválido) o cambios colaterales en los objetos protegidos, más que a una incapacidad total de editar el objeto objetivo.
Costo vs. Capacidad: El estudio no encontró una correlación directa entre el costo del modelo y el rendimiento; los modelos de frontera costosos no superaron consistentemente a las alternativas más pequeñas o económicas en términos de éxito de especificación total.

Significancia
El artículo afirma que Vector-Bench expone una limitación crítica en los modelos de lenguaje extensos actuales: la incapacidad de realizar ediciones locales en código estructurado sin comprometer la integridad del contexto circundante. Los resultados demuestran que el "progreso de reparación aparente" (corregir el defecto visual) y la "edición fiel a la especificación" (corregir el defecto dejando el resto del programa intacto) son capacidades sustancialmente diferentes. El benchmark proporciona un estándar riguroso y determinista para evaluar la edición vectorial que va más allá de la similitud visual basada en raster, resaltando la necesidad de que los modelos comprendan y preserven mejor la estructura semántica de los artefactos ejecutables. Los autores enfatizan que sus hallazgos son estables ante cambios moderados de tolerancia, lo que sugiere que la dificultad es inherente a la tarea y no un artefacto de criterios de evaluación estrictos.

Más como este