Resumo Técnico: DiffSpot

Declaração do Problema

Os modelos visão-linguagem (VLMs) alcançaram progresso significativo no alinhamento imagem-texto de alto nível e no raciocínio guiado por linguagem. No entanto, sua capacidade de perceber diferenças visuais de alta granularidade permanece limitada. Essa limitação é crítica para sistemas que operam em interfaces web renderizadas, como agentes de GUI e ferramentas de design, que devem verificar não apenas que uma tela mudou, mas exatamente qual propriedade visual mudou, onde mudou e se a mudança foi confinada ao elemento pretendido.

Os benchmarks existentes para VLMs carecem amplamente de um regime dedicado de "encontrar as diferenças" para interfaces web. As abordagens atuais enfrentam dois gargalos:

1. Escassez de Dados: Páginas web reais raramente fornecem capturas de tela "antes/depois" quase idênticas, diferindo por apenas uma pequena propriedade de UI, com cobertura equilibrada entre elementos, propriedades e níveis de dificuldade.
2. Viés de Anotação: A rotulagem humana é seletiva e dependente da atenção, frequentemente super-representando mudanças salientes ou semanticamente significativas, enquanto perde diferenças visuais sutis, em nível de propriedade.

Metodologia: O Pipeline DiffSpot

Os autores introduzem o DiffSpot, um benchmark baseado em código para tarefas abertas de "encontrar as diferenças" em interfaces web. A ideia central é mover a construção de diferenças do espaço de imagem para o espaço de código. Como as interfaces web são artefatos programáticos gerados a partir de HTML/CSS, as diferenças visuais podem ser definidas e controladas antes que a renderização ocorra.

O pipeline de construção consiste em cinco etapas:

1. Curadoria do Corpus:

   • Sementes são extraídas do Chrome User Experience Report e dos domínios Majestic Top-1M (2 milhões de domínios).
   • URLs são expandidas via sitemaps e filtradas por impressões digitais de estrutura HTML para garantir unicidade estrutural.
   • Páginas são renderizadas em Chromium headless (viewport 1280×800) e emparelhadas com HTML autossuficiente regenerado por um LLM para remover dependências de terceiros.
   • Pares são filtrados por similaridade CLIP (≥0,70) para garantir que o HTML regenerado corresponda à estrutura visual original.

2. Mutação Programática:

   • O sistema aplica mutações atômicas e localizadas a uma única propriedade CSS de um único elemento-alvo.
   • São definidos 13 operadores de propriedade CSS em quatro famílias: Tipografia (font_weight, font_size, letter_spacing, line_height, text), Cor (color, opacity, gradient), Layout (position, spacing, justify) e Forma (border, rounded).
   • As mutações são executadas via troca de classes Tailwind CSS ou sobrescritas de estilo inline.
   • Estratificação de Dificuldade: Cada operador é dividido em níveis Fácil, Médio e Difícil com base na magnitude da mudança (por exemplo, etapas da escala Tailwind para propriedades discretas, deslocamentos em em para propriedades contínuas).

3. Validação do Portão de Ancoragem (Grounding Gate):

   • Para garantir que a mutação corresponda a uma mudança visual limpa e localizada, um "portão de ancoragem" valida o resultado renderizado.
   • Verifica três predicados:
     1. Eficácia: A mudança de pixels dentro da caixa delimitadora (bbox) do alvo é não nula.
     2. Localidade: A mudança de pixels fora da bbox do alvo é zero (sem contaminação por reflow de layout).
     3. Resolução do Seletor: O elemento-alvo deve ser resolvido corretamente no DOM.
   • Apenas pares que passam em todos os predicados são retidos.

4. Polimento e Filtragem:

   • Registros de mutação estruturados são convertidos em descrições em linguagem natural usando um LLM.
   • Filtros de conteúdo removem casos com truncamento de texto, overflow de viewport ou problemas de renderização de fonte.

5. Amostragem Estratificada e Controle Sem Diferença (No-Diff):

   • O conjunto de dados final contém 4.400 pares de imagens:
     • 3.900 pares "com-diferença": 100 pares por célula em 13 operadores × 3 níveis de dificuldade.
     • 500 pares "sem-diferença": Capturas de tela idênticas renderizadas duas vezes para medir taxas de alucinação.

Configuração de Avaliação

• Modelos: 13 VLMs de ponta foram avaliados em modo zero-shot, incluindo APIs proprietárias (Gemini 3.1 Pro, GPT-5.4, Claude Opus 4.7) e modelos de pesos abertos (Kimi K2.5, Qwen3.5-VL, GLM-4.6V, InternVL3.5).
• Tarefa: Os modelos recebem capturas de tela "antes/depois" e são solicitados a listar todas as diferenças visuais observadas, sem exemplos ou dicas.
• Métricas:
  • Acurácia: (VP + VN) / Total.
  • Recall: Porcentagem de mutações verdadeiras identificadas (desagregada por nível de dificuldade).
  • Acurácia Sem Diferença (Especificidade): Porcentagem de pares inalterados corretamente identificados como sem mudança (1 - taxa de alucinação).
• Julgamento: As respostas são avaliadas por um juiz LLM (gpt-oss-120b) usando uma rubrica de equivalência de efeito visual que tolera paráfrases. Verificações de robustez com dois outros juízes confirmaram a estabilidade da classificação.

Principais Resultados

1. Teto Baixo na Percepção de Alta Granularidade

Mesmo o modelo de melhor desempenho, o Gemini 3.1 Pro, alcançou apenas 40,7% de Recall em mudanças visuais verdadeiras.

• O Recall do nível Difícil ficou abaixo de 23% para todos os modelos avaliados.
• Sete dos 13 modelos ficaram abaixo de 30% de acurácia geral.
• Alguns modelos (por exemplo, InternVL3.5) mal superaram a trivial linha de base "sempre-sem-diferença", indicando uma falha em detectar mudanças, e não apenas baixa precisão.

2. Modos de Falha Específicos de Propriedade

O desempenho depende altamente do que mudou, e não de onde apareceu.

• Operadores de Alto Recall: justify (87,0% para Gemini 3.1 Pro), text (70,3% para Claude Opus 4.7) e opacity (58,3% para Kimi K2.5) são mais facilmente detectados.
• Operadores de Baixo Recall: gradient (máximo 26,7%), line_height (mediana 4,0%) e rounded (mediana 13,3%) permanecem extremamente difíceis.
• Independência de Domínio: O Recall variou minimamente entre 15 domínios de origem (diferença máxima de 7,1 pontos percentuais), enquanto a variação entre operadores foi significativa. Isso sugere que a lacuna de capacidade é específica da propriedade, e não do domínio.

3. Magnitude Visual Não Prevê Dificuldade

O artigo demonstra que nem a magnitude de pixels nem a distância CLIP preveem de forma confiável o desempenho do modelo:

• Mudança de Pixels: Operadores com grandes mudanças de pixels (por exemplo, gradient, line_height) frequentemente têm baixo recall, enquanto aqueles com pequenas mudanças de pixels (por exemplo, text, position) têm alto recall. Correlação $r \approx -0,08$.
• Distância CLIP: As distâncias de incorporação CLIP são comprimidas e mostram correlação próxima de zero com o recall ($r \approx +0,06$).
• Conclusão: Os modelos lutam para perceber e nomear propriedades visuais específicas em nível de CSS, em vez de simplesmente falharem em detectar grandes diferenças de imagem.

4. Compromisso entre Sensibilidade e Restrição

Os pares "sem-diferença" revelaram um compromisso crítico:

• Relatores Agressivos: Modelos como GLM-4.6V-Flash alucinaram mudanças em 24,2% dos pares sem diferença.
• Excessivamente Conservadores: Modelos como InternVL3.5 relataram quase nada, alcançando 100% de especificidade, mas recall próximo de zero.
• Fronteira de Pareto: Apenas três modelos de código fechado (Gemini 3.1 Pro, Claude Opus 4.7, GPT-5.4) alcançaram a região "precisa e contida" (Recall ≥30%, alucinação ≤5%). Nenhum modelo de pesos abertos alcançou esse equilíbrio.

5. Escalonamento e Raciocínio

• Modo de Raciocínio: Para a família Qwen3-VL, a alternância para o modo "Thinking" melhorou o desempenho significativamente apenas na escala maior (235B parâmetros), não em 30B.
• Escalonamento: O aumento do tamanho dos parâmetros sozinho (por exemplo, Qwen3-VL de 30B para 235B no modo Instruct) não melhorou o desempenho, sugerindo que a escala sem ajustes arquitetônicos ou de treinamento específicos é insuficiente para esta tarefa.

Significado e Alegações

O artigo afirma que o DiffSpot é o primeiro benchmark para "encontrar as diferenças" aberto em interfaces web renderizadas. Seu significado reside em:

1. Mudança Metodológica: A transição de pares de imagens anotados por humanos para mutação programática baseada em código garante uma verdade fundamental controlada, equilibrada e livre de viés.
2. Precisão Diagnóstica: Revela que os VLMs atuais são frágeis na percepção visual de alta granularidade, com desempenho fortemente ditado pela propriedade CSS específica sendo mutada.
3. Relevância Prática: O benchmark aborda diretamente as necessidades de agentes de GUI e ferramentas de design, destacando que os modelos atuais não podem verificar de forma confiável mudanças de UI localizadas.
4. Rigor de Avaliação: Ao incluir controles "sem-diferença", ele desentrelaça a sensibilidade visual verdadeira da alucinação, expondo um compromisso entre sensibilidade e restrição que métricas agregadas frequentemente ocultam.

Os autores concluem que a detecção de diferenças visuais de alta granularidade em interfaces web está "longe de ser resolvida", com até os modelos mais fortes perdendo aproximadamente três de cada cinco mudanças visuais verdadeiras, particularmente em cenários de nível difícil.