Resumo Técnico: MM-ToolSandBox

Declaração do Problema

Os benchmarks atuais para avaliar agentes de Grandes Modelos de Linguagem (LLMs) são predominantemente centrados em texto, falhando em capturar as complexidades de tarefas de assistentes realistas que exigem entradas visuais. Embora os frameworks existentes abordem chamadas de função, interação com estado ou diálogo de múltiplos turnos, eles frequentemente tratam imagens como prefixos estáticos ou limitam as interações a cenários de turno único. Além disso, muitos operam dentro de espaços de ferramentas pequenos (15–100 ferramentas) e carecem da capacidade de avaliar agentes que devem extrair informações de entradas visuais dinâmicas, mapear essa evidência para chamadas de ferramentas específicas e executar ações dentro de um ambiente com estado ao longo de múltiplos turnos. Existe uma lacuna crítica em frameworks unificados capazes de estudar sistematicamente as capacidades de chamada de ferramentas visuais sob configurações dinâmicas, de múltiplos turnos e de grandes espaços de ferramentas.

Metodologia

Para abordar essa lacuna, os autores introduzem o MM-ToolSandBox, um framework unificado e benchmark projetado para avaliar agentes de chamada de ferramentas visualmente fundamentados.

Arquitetura do Framework

O framework estende os ambientes de uso de ferramentas com estado do ToolSandbox com manipulação explícita de imagens e ferramentas específicas para visão.

• Ambiente: Simula 16 domínios de aplicação (ex: Compras, Notas, Arquivos, Música) contendo 511 ferramentas Python nativas.
• Modelo de Interação: Suporta interações de múltiplos turnos e múltiplas imagens, onde as imagens são tratadas como artefatos visuais de primeira classe armazenados em um banco de dados compartilhado, em vez de anexos de prompt estáticos. As imagens podem ser trocadas via chamadas de ferramentas (ex: send_message_with_image).
• Modos de Execução: O framework suporta duas interfaces:
  1. Execução de Código: Agentes escrevem código Python em um intérprete em sandbox para chamar ferramentas.
  2. Uso Estruturado de Ferramentas: Agentes emitem chamadas de ferramentas com esquema restrito via APIs padrão.
• Segurança: Um sistema de salvaguarda de três camadas (verificações estáticas, restrições de tempo de execução, limites de execução) garante a execução segura do código gerado pelo agente.

Construção do Benchmark

O benchmark compreende 258 cenários verificados por humanos nominais e 50 variantes de UI interativas, utilizando 1.284 imagens únicas provenientes de oito conjuntos de dados de visão estabelecidos (ex: DocVQA, ChartQA-Pro, ScreenSpotPro).

• Dimensões de Design: Os cenários são estruturados ao longo de três eixos ortogonais:
  1. Tipos de Fluxo de Informação: Sete tipos, incluindo agregação, comparação, filtragem, computação, validação, cadeia de busca (lookup chain) e referência cruzada.
  2. Tipos de Desafio: Linha de base cooperativa, mudanças de objetivo, correções de erro e mutações de estado.
  3. Padrões de Chegada de Imagem: Chegada antecipada, progressiva, tardia ou mista de entradas visuais.
• Pipeline de Geração: Um pipeline automatizado de seis estágios gera cenários usando planejamento guiado por fluxo de informação, agrupamento de imagens baseado em CLIP e filtragem de qualidade de múltiplos estágios. Isso reduz a carga de anotação para revisão humana direcionada.
• Protocolo de Avaliação:
  • Verificação de Estado: Compara instantâneos (snapshots) do estado inicial e final do mundo contra as mudanças de entidade esperadas usando pontuações F1 de Entidade.
  • Juízes LLM Baseados em Rubrica: Um Juiz de Agente avalia cinco critérios (conclusão da tarefa, seguimento de instruções, validade do uso de ferramentas, ausência de efeitos colaterais, precisão da informação), enquanto um Juiz de Usuário avalia a coerência do usuário simulado.

Principais Contribuições

1. Framework Unificado: Um ambiente de simulação com estado, múltiplos turnos e múltiplas imagens abrangendo 511 ferramentas em 16 domínios, suportando tanto execução de código quanto interfaces de uso de ferramentas estruturadas.
2. Benchmark Escalável: Um conjunto de dados de 258 cenários verificados por humanos e 50 variantes de UI, gerados via um pipeline automatizado que garante diversos padrões de raciocínio visual e dinâmicas conversacionais.
3. Avaliação Sistemática: Uma avaliação abrangente de 12 modelos de última geração (variando de modelos de pesos abertos de 4B a sistemas proprietários de fronteira) revelando modos de falha distintos conforme a escala dos modelos.

Resultados Experimentais

Os autores avaliaram 12 modelos, incluindo GPT-5.4, Gemini 3.1 Pro, Claude 4.5 Opus e a série Qwen 3.5.

• Desempenho Geral: A chamada de ferramentas visual continua sendo um desafio significativo. Mesmo o modelo mais forte, Claude 4.5 Opus, alcançou uma Taxa de Sucesso de Agente (SR) de apenas 48,8%. O melhor modelo em termos de F1 de Entidade (GPT-5.4 com alto nível de pensamento) atingiu 0,865, mas seu SR de Agente foi menor.
• Leis de Escala e Modos de Falha:
  • Modelos Pequenos (<27B parâmetros): As falhas são dominadas por erros de planejamento (Falha de Tarefa), onde os modelos não conseguem decidir a sequência correye de ações.
  • Modelos Grandes (≥27B parâmetros): As falhas mudam para erros de precisão visual (Erro Factual). Para o Claude 4.5 Opus, 53% das falhas originaram-se de extração incorreta de informações de imagens (ex: leitura incorreta de texto ou números), apesar de executarem o fluxo de trabalho correto.
  • Memória de Múltiplas Imagens: O desempenho degrada significativamente conforme o número de imagens aumenta, particularmente em cenários "Upfront" (antecipados), onde as imagens são fornecidas no início, indicando um gargalo na memória de trabalho de múltiplas imagens.
• Sensibilidade à Interface: O desempenho do modelo varia conforme a interface de execução. Por exemplo, o KIMI 2.6 teve um desempenho significativamente melhor no modo de Uso de Ferramenta, enquanto o Claude 4.5 Sonnet e o Qwen 3.5 preferiram a Execução de Código.
• Modo de UI: Em um subconjunto de 50 cenários que exigem renderização de UI interativa, o desempenho caiu drasticamente (ex: KIMI 2.6 caiu de 45,0% para 26,0% de SR), destacando a geração de UI como uma nova e mais difícil fronteira.

Significância e Alegações

O artigo afirma que o MM-ToolSandBox fornece o primeiro framework unificado para estudar sistematicamente a chamada de ferramentas visual sob configurações dinâmicas, de múltiplos turnos e de grandes espaços de ferramentas.

A principal significância do trabalho reside em sua análise de falhas, que identifica a precisão visual como o principal gargalo para modelos capazes, em vez da competência de uso de ferramentas ou planejamento. Os autores observam um "crossover de planejamento para precisão" conforme a escala do modelo aumenta: modelos menores lutam com o que fazer, enquanto modelos maiores lutam com o que veem. Isso sugere que as direções de pesquisa futura devem diferir com base nos níveis de capacidade do modelo. Adicionalmente, o trabalho destaca que a memória de trabalho de múltiplas imagens é uma limitação crítica para os agentes atuais, e que a geração de UI interativa representa um desafio substancialmente mais difícil do que a chamada de ferramentas baseada em texto.

Os autores concluem que a chamada de ferramentas visual está "longe de ser resolvida", com até mesmo modelos de fronteira completando menos da metade das tarefas, e enfatizam a necessidade de melhorar as capacidades de fundamentação visual e de raciocínio.