IBM Research analizó dónde fallan los agentes de AI con APIs, documentos y reglas en VAKRA

IBM Research ha realizado un análisis detallado de por qué incluso los modelos de lenguaje potentes siguen fallando en tareas para sistemas de agentes. Un nuevo análisis del benchmark VAKRA muestra: hacer una elegante llamada de API no es suficiente — los problemas comienzan cuando necesitas pasar por varios pasos, seleccionar la fuente de datos correcta y no violar las reglas de uso de herramientas.

Cómo está estructurado VAKRA

VAKRA es un benchmark ejecutable para agentes empresariales. En lugar de llamadas de función básicas, proporciona a los modelos un entorno de trabajo con más de 8.000 API implementadas localmente, bases de datos reales en 62 dominios y colecciones de documentos para áreas temáticas específicas.

Un escenario típico requiere no una única respuesta, sino una cadena de 3–7 pasos: obtener datos, seleccionar la herramienta correcta, extraer un dato de un documento, pasar el resultado a la siguiente llamada y solo entonces ensamblar la respuesta final. La idea clave es que VAKRA evalúa no solo la respuesta final del modelo, sino toda su trayectoria de acciones. Para tareas complejas, el sistema primero verifica si el agente se adhirió a las restricciones textuales en el uso de herramientas, luego reproduce sus llamadas en el mismo entorno, compara resultados intermedios con el benchmark y solo entonces evalúa la respuesta final.

Este enfoque es importante porque un agente puede adivinar accidentalmente la conclusión final mientras la alcanza por el camino equivocado — y para producción, eso es casi inútil.

Cuatro tipos de tareas

Los autores dividen VAKRA en cuatro modos, cada uno probando una capa separada del comportamiento del agente. Juntos cubren el camino desde encadenamiento simple de API hasta razonamiento multi-paso sobre API y documentos con restricciones externas. Esto importa porque muchos agentes se ven seguros en llamadas individuales pero se pierden rápidamente cuando necesitan simultanear la planificación de pasos, cambiar entre fuentes, mantener el contexto del diálogo y recordar las reglas de acceso a herramientas.

• Business Intelligence APIs: 2.077 tareas en 54 dominios, donde el agente necesita llamar secuencialmente 1–12 herramientas y trabajar cuidadosamente con parámetros y filtrado de datos.
• Dashboard APIs: 1.597 tareas en 17 dominios, donde la principal complejidad es seleccionar el endpoint correcto entre 6–328 herramientas disponibles.
• Multi-hop over APIs: 869 tareas en 38 dominios, donde la respuesta se ensambla a través de varias transiciones lógicas, de una a cinco.
• Multi-source + policies: 644 tareas en 41 dominios, donde el agente alterna entre API y búsqueda de documentos, tiene en cuenta el historial de diálogo y sigue reglas textuales como "usa solo retriever, no toques otras herramientas."

Dónde fallan los agentes

La parte más útil del artículo es el análisis de dónde fallan los modelos. Los autores dividen errores por etapa: elegir la herramienta equivocada, omitir argumentos necesarios o alucinar sobre ellos, valores de parámetros incorrectos y, finalmente, una respuesta final incorrecta incluso después de llamadas correctas. En el segmento de API de BI, GPT-OSS-120B tuvo el mejor desempeño: comprendió notablemente mejor los esquemas de herramientas y cometió menos errores en nombres y relleno de parámetros.

Pero incluso allí, el éxito en pasos individuales no garantizó resultados estables de extremo a extremo. En tareas con un gran conjunto de API de dashboard, Gemini-3-flash-preview tuvo el mejor desempeño, lo que tiene sentido: allí la capacidad de hacer una lista abreviada de herramientas y seleccionar con precisión un endpoint es más importante. A medida que la profundidad del razonamiento crecía, la calidad caía para todos los modelos: las preguntas 2-hop y especialmente 3+ hop mostraban una precisión notablemente menor.

Se ponía aún peor cuando las API tenían que combinarse con recuperación de documentos. Los autores señalan específicamente un fallo revelador: en algunas tareas RAG de 1-hop, GPT-OSS-120B a veces ni siquiera llamaba al retriever e intentaba responder "de memoria", lo que en tal benchmark cuenta como error. Las políticas añadían otra capa de complejidad: los modelos violaban restricciones o las seguían pero no lograban reunir la información necesaria para la respuesta.

Qué significa esto

VAKRA muestra una verdad desagradable pero útil sobre sistemas de agentes: la capacidad de hacer una demo elegante con tool calling no significa estar listos para procesos de negocio reales. Para equipos que eligen un modelo para soporte, análisis, cumplimiento o flujos de trabajo internos, la pregunta principal ahora no es "¿puede llamar herramientas?", sino "¿mantiene una secuencia correcta de acciones bajo restricciones, entre múltiples fuentes y sin atajos excesivamente seguros?"