Resumen Técnico: DiffSpot

Enunciado del Problema

Los modelos de visión-idioma (VLM) han logrado avances significativos en la alineación de alto nivel entre imagen y texto y en el razonamiento guiado por lenguaje. Sin embargo, su capacidad para percibir diferencias visuales de grano fino sigue siendo limitada. Esta limitación es crítica para los sistemas que operan en interfaces web renderizadas, como agentes de GUI y herramientas de diseño, los cuales deben verificar no solo que una pantalla cambió, sino exactamente qué propiedad visual cambió, dónde cambió y si el cambio se confinó al elemento previsto.

Las evaluaciones existentes para VLM carecen en gran medida de un régimen dedicado de "buscar diferencias" para interfaces web. Los enfoques actuales enfrentan dos cuellos de botella:

1. Escasez de Datos: Las páginas web reales rara vez ofrecen capturas de pantalla casi idénticas de antes/después que difieran únicamente en una pequeña propiedad de la interfaz de usuario, con una cobertura equilibrada en elementos, propiedades y niveles de dificultad.
2. Sesgo de Anotación: El etiquetado humano es selectivo y dependiente de la atención, representando a menudo en exceso cambios salientes o semánticamente significativos, mientras que pasa por alto diferencias visuales sutiles a nivel de propiedad.

Metodología: La Pipeline de DiffSpot

Los autores presentan DiffSpot, una evaluación basada en código para tareas abiertas de "buscar diferencias" en interfaces web. La idea central es trasladar la construcción de diferencias del espacio de imagen al espacio de código. Dado que las interfaces web son artefactos programáticos generados a partir de HTML/CSS, las diferencias visuales pueden definirse y controlarse antes de que ocurra el renderizado.

La pipeline de construcción consta de cinco etapas:

1. Curación del Corpus:

   • Las semillas se extraen del Informe de Experiencia de Usuario de Chrome y de los dominios Majestic Top-1M (2 millones de dominios).
   • Las URL se expanden mediante mapas del sitio y se filtran por huellas dactilares de estructura HTML para garantizar la unicidad estructural.
   • Las páginas se renderizan en Chromium sin interfaz (vista de 1280×800) y se emparejan con HTML autocontenido regenerado por un LLM para eliminar dependencias de terceros.
   • Los pares se filtran por similitud CLIP (≥0.70) para asegurar que el HTML regenerado coincida con la estructura visual original.

2. Mutación Programática:

   • El sistema aplica mutaciones atómicas y localizadas a una sola propiedad CSS de un único elemento objetivo.
   • Se definen 13 operadores de propiedad CSS en cuatro familias: Tipografía (font_weight, font_size, letter_spacing, line_height, text), Color (color, opacity, gradient), Diseño (position, spacing, justify) y Forma (border, rounded).
   • Las mutaciones se ejecutan mediante intercambios de clases de Tailwind CSS o anulación de estilos en línea.
   • Estratificación de Dificultad: Cada operador se divide en niveles Fácil, Medio y Difícil basados en la magnitud del cambio (por ejemplo, pasos de escala de Tailwind para propiedades discretas, desplazamientos en em para propiedades continuas).

3. Validación de la Puerta de Anclaje (Grounding Gate):

   • Para asegurar que la mutación corresponda a un cambio visual limpio y localizado, una "puerta de anclaje" valida el resultado renderizado.
   • Verifica tres predicados:
     1. Efectividad: El cambio de píxeles dentro del cuadro delimitador (bbox) del objetivo es distinto de cero.
     2. Localidad: El cambio de píxeles fuera del bbox del objetivo es cero (sin contaminación por reflujo de diseño).
     3. Resolución del Selector: El elemento objetivo debe resolverse correctamente en el DOM.
   • Solo se conservan los pares que superan todos los predicados.

4. Pulido y Filtrado:

   • Los registros de mutación estructurados se convierten en descripciones en lenguaje natural utilizando un LLM.
   • Los filtros de contenido eliminan casos con truncamiento de texto, desbordamiento de la vista o problemas de renderizado de fuentes.

5. Muestreo Estratificado y Control Sin Diferencia:

   • El conjunto de datos final contiene 4.400 pares de imágenes:
     • 3.900 pares "con-diferencia": 100 pares por celda a través de 13 operadores × 3 niveles de dificultad.
     • 500 pares "sin-diferencia": Capturas de pantalla idénticas renderizadas dos veces para medir las tasas de alucinación.

Configuración de la Evaluación

• Modelos: Se evaluaron 13 VLM de vanguardia en modo zero-shot, incluyendo APIs propietarias (Gemini 3.1 Pro, GPT-5.4, Claude Opus 4.7) y modelos de pesos abiertos (Kimi K2.5, Qwen3.5-VL, GLM-4.6V, InternVL3.5).
• Tarea: Los modelos reciben capturas de pantalla de antes/después y se les pide que enumeren todas las diferencias visuales observadas, sin ejemplos ni pistas.
• Métricas:
  • Precisión: (VP + VN) / Total.
  • Exhaustividad (Recall): Porcentaje de mutaciones verdaderas identificadas (desglosado por nivel de dificultad).
  • Precisión en "Sin-Diferencia" (Especificidad): Porcentaje de pares sin cambios identificados correctamente como sin cambios (1 - tasa de alucinación).
• Evaluación: Las respuestas son evaluadas por un juez LLM (gpt-oss-120b) utilizando una rúbrica de equivalencia de efecto visual que tolera la parafraseo. Las comprobaciones de robustez con dos jueces adicionales confirmaron la estabilidad de la clasificación.

Resultados Clave

1. Techo Bajo en la Percepción de Grano Fino

Incluso el modelo de mejor rendimiento, Gemini 3.1 Pro, logró solo un 40.7% de Exhaustividad en cambios visuales reales.

• La Exhaustividad en nivel Difícil fue inferior al 23% para cada modelo evaluado.
• Siete de los 13 modelos quedaron por debajo del 30% de precisión general.
• Algunos modelos (por ejemplo, InternVL3.5) apenas superaron la línea base trivial de "siempre-sin-diferencia", lo que indica un fallo en la detección de cambios y no solo una mala precisión.

2. Modos de Fallo Específicos por Propiedad

El rendimiento depende altamente de qué cambió, no de dónde apareció.

• Operadores de Alta Exhaustividad: justify (87.0% para Gemini 3.1 Pro), text (70.3% para Claude Opus 4.7) y opacity (58.3% para Kimi K2.5) son más fáciles de detectar.
• Operadores de Baja Exhaustividad: gradient (máx 26.7%), line_height (mediana 4.0%) y rounded (mediana 13.3%) siguen siendo extremadamente difíciles.
• Independencia del Dominio: La exhaustividad varió mínimamente a través de 15 dominios de origen (diferencia máxima de 7.1 pp), mientras que la variación entre operadores fue significativa. Esto sugiere que la brecha de capacidad es específica de la propiedad, no del dominio.

3. La Magnitud Visual No Predice la Dificultad

El documento demuestra que ni la magnitud de píxeles ni la distancia CLIP predicen de manera fiable el rendimiento del modelo:

• Cambio de Píxeles: Los operadores con grandes cambios de píxeles (por ejemplo, gradient, line_height) a menudo tienen baja exhaustividad, mientras que aquellos con cambios pequeños (por ejemplo, text, position) tienen alta exhaustividad. Correlación $r \approx -0.08$.
• Distancia CLIP: Las distancias de incrustación CLIP están comprimidas y muestran una correlación cercana a cero con la exhaustividad ($r \approx +0.06$).
• Conclusión: Los modelos luchan por percibir y nombrar propiedades visuales específicas a nivel CSS, en lugar de simplemente fallar al detectar grandes diferencias de imagen.

4. Compensación entre Sensibilidad y Contención

Los pares "sin-diferencia" revelaron una compensación crítica:

• Reportadores Agresivos: Modelos como GLM-4.6V-Flash alucinaron cambios en el 24.2% de los pares sin diferencia.
• Demasiado Conservadores: Modelos como InternVL3.5 reportaron casi nada, logrando un 100% de especificidad pero una exhaustividad cercana a cero.
• Frente de Pareto: Solo tres modelos de código cerrado (Gemini 3.1 Pro, Claude Opus 4.7, GPT-5.4) alcanzaron la región de "preciso y contenido" (Exhaustividad ≥30%, alucinación ≤5%). Ningún modelo de pesos abiertos logró este equilibrio.

5. Escalado y Razonamiento

• Modo de Razonamiento: Para la familia Qwen3-VL, cambiar al modo "Thinking" mejoró el rendimiento significativamente solo a una escala mayor (235B parámetros), no a 30B.
• Escalado: Aumentar el tamaño de los parámetros por sí solo (por ejemplo, de Qwen3-VL 30B a 235B en modo Instruct) no mejoró el rendimiento, lo que sugiere que la escala sin ajustes arquitectónicos o de entrenamiento específicos es insuficiente para esta tarea.

Significado y Afirmaciones

El documento afirma que DiffSpot es la primera evaluación para "buscar diferencias" abierto en interfaces web renderizadas. Su importancia radica en:

1. Cambio Metodológico: Pasar de pares de imágenes anotados por humanos a mutación programática basada en código garantiza una verdad fundamental controlada, equilibrada y libre de sesgos.
2. Precisión Diagnóstica: Revela que los VLM actuales son frágiles en la percepción visual de grano fino, con un rendimiento dictado en gran medida por la propiedad CSS específica que se muta.
3. Relevancia Práctica: La evaluación aborda directamente las necesidades de agentes de GUI y herramientas de diseño, destacando que los modelos actuales no pueden verificar de manera fiable cambios de UI localizados.
4. Rigor de Evaluación: Al incluir controles "sin-diferencia", desvincula la sensibilidad visual real de la alucinación, exponiendo una compensación entre sensibilidad y contención que las métricas agregadas a menudo ocultan.

Los autores concluyen que la detección de diferencias visuales de grano fino en interfaces web está "lejos de estar resuelta", ya que incluso los modelos más fuertes se pierden aproximadamente tres de cada cinco cambios visuales reales, particularmente en escenarios de nivel difícil.