WildToolBench: Por qué ningún LLM supera el 15% de precisión de sesión en el uso de herramientas en el mundo real

Los benchmarks de uso de herramientas que he estado siguiendo (BFCL, ToolBench, τ-bench) comparten un defecto de diseño común: construyen tareas a partir de la imaginación de los autores sobre lo que hacen los usuarios. WildToolBench, aceptado en ICLR 2026, vuelve a los registros de usuarios reales y pregunta qué hacen los usuarios realmente. La respuesta es humillante: de 57 LLMs evaluados, ninguno supera el 15% de precisión de sesión.

El artículo

Peijie Yu, Wei Liu, Yifan Yang y sus colegas de Alibaba presentan WildToolBench (arXiv:2604.06185), una comparativa de 256 escenarios de diálogo de múltiples turnos con 1.024 tareas extraídas de patrones de comportamiento de usuarios auténticos y basadas en unas 1.600 APIs públicas. El argumento central es que los benchmarks existentes se están saturando no porque los modelos sean buenos, sino porque las tareas son artificiales. Los usuarios reales agrupan solicitudes, omiten contexto que compartieron hace dos turnos y alternan entre hacer una pregunta sobre una herramienta, charlar un poco y solicitar una aclaración, a veces dentro de un solo mensaje. WildToolBench operacionaliza estos modos de fallo en tres categorías de desafíos estructurados y mide tanto la precisión a nivel de tarea como la mucho más estricta precisión a nivel de sesión, que requiere tener éxito en las cuatro tareas de un diálogo.

Ideas clave

• La precisión por sesión se desploma a un solo dígito para la mayoría de los modelos: Gemini-2.0-Flash-Thinking lidera con un 14,45% de precisión por sesión, seguido de Claude-4-Sonnet con un 12,50% y GPT-4o con un 11,72%. Superar todas las tareas en una sesión de cuatro turnos es tan difícil que incluso una precisión de tarea del 60% se traduce en menos del 15% de precisión por sesión: un coste de probabilidad compuesta en cada interacción.
• La orquestación compositiva es el precipicio más pronunciado: Las topologías de herramientas mixtas secuenciales y paralelas limitan a los mejores modelos al 25% de precisión de tarea, frente al 54-62% para cadenas puramente paralelas o secuenciales. Cuando una tarea requiere un despliegue en paralelo seguido de una fusión secuencial, el problema de coordinación excede lo que cualquier modelo actual maneja con fiabilidad.
• La intención oculta es una brecha mayor de lo que nadie había medido antes: WildToolBench garantiza que el 100% de las tareas involucren información implícita o entre turnos; BFCL v3 solo logra un 15,7%. Las tareas con dependencias de largo alcance, donde la información faltante está a más de dos turnos de distancia, son el subtipo más difícil, y ningún modelo supera el 50% incluso a nivel de tarea.
• Las transiciones de instrucciones acumulan errores a un ritmo lineal: Cada cambio de política adicional (tarea de herramienta → chat → aclaración → tarea de herramienta) reduce la precisión en aproximadamente 5-15 puntos porcentuales. Con tres transiciones, los modelos más afectados pierden 30 puntos. Los autores llaman a esto "autocondicionamiento": las respuestas previas sesgan la interpretación del modelo de las instrucciones posteriores de formas que son difíciles de corregir a mitad de la sesión.
• La Tasa de Ruta Óptima se mantiene por debajo del 43%: Incluso cuando los modelos completan las tareas correctamente, consumen llamadas a la API en exceso. Claude-4-Sonnet logra la mejor Tasa de Ruta Óptima con un 42,74%, lo que significa que la mayoría de las finalizaciones correctas requieren más pasos de los necesarios: un coste directo en latencia y tokens para cualquier sistema en producción.
• Los modelos especializados en el uso de herramientas rinden por debajo de los modelos de frontera generales: xLAM-2-70B y ToolACE2-8B presentan tasas de error por nombre de función incorrecto superiores al 30%, peor que GPT-4o o Claude-4-Sonnet. El ajuste fino en corpus estrechos de uso de herramientas parece crear fragilidad en lugar de robustez ante el desplazamiento de la distribución hacia el comportamiento de usuarios reales.

Qué se sostiene y qué no

El diseño del benchmark es sólido donde más importa. La distinción entre precisión de tarea y precisión de sesión es totalmente acertada: la acumulación de modos de fallo es lo que arruina los despliegues reales, y la mayoría de los trabajos previos informan cifras a nivel de tarea que ocultan esto. La taxonomía de tres desafíos (orquestación compositiva, intención oculta, transiciones de instrucciones) está bien motivada y fundamentada empíricamente; las curvas de degradación del rendimiento en los distintos tipos de desafíos son reales y sorprendentes.

El punto débil es la escala. 1.024 tareas de 256 escenarios es un artefacto de investigación creíble, pero escaso para un tablero de clasificación destinado a rastrear 57 modelos a lo largo del tiempo. Los autores lo reconocen directamente y mencionan una canalización de escalado automatizada en trabajos futuros. El otro problema es que "basado en registros de usuarios reales" implica mucho trabajo: las tareas finales son parcialmente sintéticas, construidas por un sistema multiagente a partir de patrones semilla y luego verificadas por anotadores humanos. La afirmación está fundamentada, pero los datos no son literalmente "salvajes", sino "inspirados en lo salvaje". Eso importa para la interpretación literal del techo del 15%; parte de esa brecha podría cerrarse si la canalización de generación introduce una dificultad artificial que los usuarios reales no presentan en la práctica.

También soy escéptico sobre el análisis de la transición de instrucciones como una afirmación arquitectónica. El artículo lo atribuye a una limitación fundamental, pero el desajuste de la distribución de entrenamiento entre los objetivos de ajuste fino de RLHF y las sesiones de usuario multimodales es la explicación más parsimoniosa. Eso es abordable, no estructural.

Por qué esto es importante para la IA en finanzas

Los tres modos de fallo se corresponden casi a la perfección con la forma en que los usuarios reales interactúan con un agente de escritura para Beancount. Un usuario pregunta "¿cuánto gasté en comestibles el mes pasado y, ya que estás, añade el recibo de Whole Foods de hoy?"; esa es una tarea compositiva agrupada en un solo turno. Luego sigue con "en realidad pon 47,23 $ en lugar de 42, lo he comprobado"; esa es una corrección de parámetros que requiere que el agente rastree el estado de la sesión. Después preguntan "¿es correcta esa categoría?"; esa es una solicitud de aclaración, y el agente debe evitar volver a ejecutar la operación de escritura que acaba de terminar. El límite del 25% en la orquestación mixta secuencial y paralela y la caída de 30 puntos por las transiciones de instrucciones son exactamente los modos de fallo que se manifestarían en un agente de libros contables atendiendo sesiones de usuarios reales.

El hallazgo de que los modelos especializados en el uso de herramientas rinden por debajo de los modelos de frontera generales es particularmente relevante. Si estuviéramos considerando ajustar un modelo abierto más pequeño con ejemplos de llamadas a herramientas específicos de Beancount —la jugada obvia para reducir costes— WildToolBench es una advertencia directa de que la especialización puede sacrificar la robustez ante la distribución del comportamiento real del usuario. El hallazgo de la Tasa de Ruta Óptima también importa: un agente que utiliza el doble de llamadas a la API para completar una tarea no solo es ineficiente; para las operaciones de escritura, las llamadas intermedias redundantes pueden dejar el libro contable en estados intermedios inconsistentes.

Qué leer a continuación

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024): el marco de entrenamiento fundamental contra el que WildToolBench se posiciona explícitamente; comprender su diseño de evaluación sintética aclara exactamente qué añade la ejecución en vivo.
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045): el trabajo previo más cercano sobre el uso realista de herramientas en múltiples turnos; comparar los dominios de comercio minorista y aerolíneas de τ-bench con la cobertura de APIs públicas de WildToolBench muestra cuánto se generaliza el desafío.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral): si el problema de la transición de instrucciones es abordable mediante el descubrimiento automático de mejores flujos de trabajo de agentes en lugar de escalar los datos de entrenamiento, AFlow es el mecanismo más creíble para lograrlo.