Resumen Técnico: MM-ToolSandBox

Planteamiento del Problema

Los benchmarks actuales para evaluar agentes de Modelos de Lenguaje Extensos (LLM) son predominantemente centrados en el texto, lo que impide capturar las complejidades de las tareas de asistencia realistas que requieren entradas visuales. Si bien los marcos existentes abordan la llamada a funciones, la interacción con estado o el diálogo de múltiples turnos, a menudo tratan las imágenes como prefijos estáticos o limitan las interacciones a escenarios de un solo turno. Además, muchos operan dentro de espacios de herramientas pequeños (15–100 herramientas) y carecen de la capacidad de evaluar agentes que deban extraer información de entradas visuales dinámicas, mapear esa evidencia a llamadas a herramientas específicas y ejecutar acciones dentro de un entorno con estado a lo largo de múltiples turnos. Existe una brecha crítica en los marcos unificados capaces de estudiar sistemáticamente las capacidades de llamada de herramientas visuales bajo configuraciones dinámicas, de múltiples turnos y de gran espacio de herramientas.

Metodología

Para abordar esta brecha, los autores presentan MM-ToolSandBox, un marco unificado y benchmark diseñado para evaluar agentes de llamada de herramientas con fundamentación visual.

Arquitectura del Marco

El marco extiende los entornos de uso de herramientas con estado de ToolSandbox con un manejo explícito de imágenes y herramientas específicas de visión.

• Entorno: Simula 1s 16 dominios de aplicaciones (p. ej., Compras, Notas, Archivos, Música) que contienen 511 herramientas nativas de Python.
• Modelo de Interacción: Soporta interacciones de múltiples turnos y múltiples imágenes donde las imágenes son tratadas como artefactos visuales de primera clase almacenados en una base de datos compartida, en lugar de adjuntos estáticos al prompt. Las imágenes pueden intercambiarse mediante llamadas a herramientas (p. ej., send_message_with_image).
• Modos de Ejecución: El marco soporta dos interfaces:
  1. Ejecución de Código: Los agentes escriben código Python en un intérprete en un entorno controlado (sandboxed) para llamar a las herramientas.
  2. Uso de Herramientas Estructurado: Los agentes emiten llamadas a herramientas restringidas por esquemas a través de APIs estándar.
• Seguridad: Un sistema de salvaguardas de tres capas (verificaciones estáticas, restricciones en tiempo de ejecución, límites de ejecución) garantiza la ejecución segura del código generado por el agente.

Construcción del Benchmark

El benchmark consta de 258 escenarios nominales verificados por humanos y 50 variantes de interfaz de usuario (UI) interactivas, utilizando 1,284 imágenes únicas provenientes de ocho conjuntos de datos de visión establecidos (p. ej., DocVQA, ChartQA-Pro, ScreenSpotPro).

• Dimensiones de Diseño: Los escenarios se estructuran a lo largo de tres ejes ortogonales:
  1. Tipos de Flujo de Información: Siete tipos que incluyen agregación, comparación, filtrado, computación, validación, cadena de búsqueda y referencias cruzadas.
  2. Tipos de Desafío: Línea base cooperativa, cambios de objetivo, correcciones de errores y mutaciones de estado.
  3. Patrones de Llegada de Imágenes: Llegada anticipada, progresiva, tardía o mixta de las entradas visuales.
• Pipeline de Generación: Un pipeline automatizado de seis etapas genera escenarios utilizando planificación guiada por flujo de información, agrupamiento de imágenes basado en CLIP y filtrado de calidad de múltiples etapas. Esto reduce la carga de anotación a una revisión humana dirigida.
• Protocolo de Evaluación:
  • Verificación de Estado: Compara instantáneas del estado inicial y final del mundo contra los cambios de entidad esperados utilizando puntuaciones F1 de Entidad.
  • Jueces LLM basados en Rúbricas: Un Juez Agente evalúa cinco criterios (completitud de la tarea, seguimiento de instrucciones, validez del uso de herramientas, ausencia de efectos secundarios, precisión de la información), mientras que un Juez Usuario evalúa la coherencia del usuario simulado.

Contribuciones Clave

1. Marco Unificado: Un entorno de simulación con estado, de múltiples turnos y múltiples imágenes que abarca 511 herramientas a través de 16 dominios, soportando tanto la ejecución de código como las interfaces de uso de herramientas estructuradas.
2. Benchmark Escalable: Un conjunto de datos de 258 escenarios verificados por humanos y 50 variantes de UI, generados mediante un pipeline automatizado que asegura diversos patrones de razonamiento visual y dinámicas conversacionales.
3. Evaluación Sistemática: Una evaluación exhaustiva de 12 modelos de última generación (que van desde sistemas de pesos abiertos de 4B hasta sistemas propietarios de frontera) que revela distintos modos de falla según la escala del modelo.

Resultados Experimentales

Los autores evaluaron 12 modelos, incluyendo GPT-5.4, Gemini 3.1 Pro, Claude 4.5 Opus y la serie Qwen 3.5.

• Desempeño General: La llamada de herramientas visuales sigue siendo un desafío significativo. Incluso el modelo más fuerte, Claude 4.5 Opus, logró una Tasa de Éxito del Agente (SR) de solo el 48.8%. El mejor modelo en términos de F1 de Entidad (GPT-5.4 con alto pensamiento) alcanzó 0.865, pero su SR de Agente fue menor.
• Leyes de Escala y Modos de Falla:
  • Modelos Pequeños (<27B de parámetros): Las fallas están dominadas por errores de planificación (Falla de Tarea), donde los modelos no pueden decidir la secuencia correcta de acciones.
  • Modelos Grandes (≥27B de parámetros): Las fallas se desplazan hacia errores de precisión visual (Error Fáctico). Para Claude 4.5 Opus, el 53% de las fallas se derivaron de la extracción incorrecta de información de las imágenes (p. ej., leer mal texto o números) a pesar de ejecutar el flujo de trabajo correcto.
• Memoria de Multi-Imagen: El desempeño se degrada significamente a medida que aumenta el número de imágenes, particularmente en escenarios de "Llegada Anticipada" donde las imágenes se proporcionan al inicio, lo que indica un cuello de botella en la memoria de trabajo de múltiples imágenes.
• Sensibilidad de la Interfaz: El desempeño de los modelos varía según la interfaz de ejecución. Por ejemplo, KIMI 2.6 funcionó significativamente mejor en el modo de Uso de Herramientas, mientras que Claude 4.5 Sonnet y Qwen 3.5 prefirieron la Ejecución de Código.
• Modo UI: En un subconjunto de 50 escenarios que requieren renderizado de UI interactiva, el desempeño cayó drásticamente (por ejemplo, KIMI 2.6 bajó de un 45.0% a un 26.0% de SR), resaltando la generación de UI como una nueva frontera más difícil.

Significancia y Reivindicaciones

El artículo afirma que MM-ToolSandBox proporciona el primer marco unificado para estudiar sistemáticamente la llamada de herramientas visuales bajo configuraciones dinámicas, de múltiples turnos y de gran espacio de herramientas.

La principal significancia del trabajo reside en su análisis de fallas, el cual identifica la precisión visual como el principal cuello de botella para los modelos capaces, más que la competencia en el uso de herramientas o la planificación. Los autores observan un "cruce de planificación a precisión" a medida que aumenta la escala del modelo: los modelos más pequeños luchan con qué hacer, mientras que los modelos más grandes luchan con qué ven. Esto sugiere que las direcciones de investigación futuras deben diferir según los niveles de capacidad del modelo. Además, el trabajo destaca que la memoria de trabajo de múltiples imágenes es una limitación crítica para los agentes actuales, y que la generación de UI interactiva representa un desafío sustancialmente más difícil que la llamada de herramientas basada en texto.

Los autores concluyen que la llamada de herramientas visuales está "lejos de estar resuelta", con incluso los modelos de frontera completando menos de la mitad de las tareas, y enfatizan la necesidad de mejorar las capacidades de fundamentación y razonamiento visual.