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

IBM Research ha publicado un análisis detallado de por qué incluso los modelos de lenguaje potentes siguen tropezando en tareas para sistemas agénticos. El nuevo estudio del benchmark VAKRA muestra que llamar bien a una sola API no basta: los problemas empiezan cuando hay que dar varios pasos, elegir la fuente de datos correcta y no violar las reglas de uso de las herramientas.

Cómo funciona VAKRA

VAKRA es un benchmark ejecutable para agentes corporativos. En lugar de llamadas a funciones de juguete, ofrece a los modelos un entorno de trabajo con más de 8 mil APIs alojadas localmente, bases de datos reales en 62 dominios y colecciones de documentos para áreas temáticas concretas. Un escenario típico exige no una respuesta, sino una cadena de 3–7 pasos: obtener datos, elegir la herramienta adecuada, extraer un dato de un documento, pasar el resultado a la siguiente llamada y solo entonces componer la respuesta final.

La idea clave es que VAKRA evalúa no solo la respuesta final del modelo, sino toda la trayectoria de sus acciones. En las tareas complejas, el sistema primero comprueba si el agente respetó las restricciones textuales sobre el uso de herramientas, después reproduce sus llamadas en el mismo entorno, compara los resultados intermedios con una referencia y solo entonces califica la respuesta final. Este enfoque importa porque un agente puede acertar la conclusión final por casualidad y llegar a ella por un camino equivocado, algo casi inútil en producción.

Cuatro tipos de tareas

Los autores dividen VAKRA en cuatro modos, y cada uno prueba una capa distinta del comportamiento agéntico. Juntos cubren desde el simple encadenamiento de APIs hasta el razonamiento multipaso sobre APIs y documentos con restricciones externas. Es relevante porque muchos agentes parecen seguros en llamadas aisladas, pero se pierden rápido cuando deben planificar pasos, alternar entre fuentes, mantener el contexto del diálogo y recordar las reglas de acceso a las herramientas al mismo tiempo.

• Business Intelligence APIs: 2 077 tareas en 54 dominios, en las que el agente debe llamar de forma secuencial a entre 1 y 12 herramientas y manejar con cuidado los parámetros y el filtrado de datos.
• Dashboard APIs: 1 597 tareas en 17 dominios, donde la principal dificultad es elegir el endpoint correcto entre 6–328 herramientas disponibles.
• Multi-hop over APIs: 869 tareas en 38 dominios, donde la respuesta se construye mediante varios saltos lógicos, de uno a cinco.
• Multi-source + policies: 644 tareas en 41 dominios, donde el agente alterna entre APIs y búsqueda en documentos, tiene en cuenta el historial del diálogo y cumple reglas textuales como «usa solo el retriever, no toques otras herramientas».

Dónde se equivocan los agentes

La parte más útil del artículo es el análisis de dónde exactamente fallan los modelos. Los autores clasifican los errores por etapas: elección de una herramienta equivocada, omisión de argumentos necesarios o alucinaciones en ellos, valores de parámetros incorrectos y, por último, una respuesta final errónea incluso tras llamadas correctas.

En el segmento de BI API, el mejor fue GPT-OSS-120B: entendía notablemente mejor que los demás los esquemas de las herramientas y se equivocaba menos en los nombres y en el relleno de parámetros. Pero incluso ahí, el acierto en pasos individuales no garantizaba un resultado end-to-end estable.

En las tareas con un gran conjunto de dashboard APIs, Gemini-3-flash-preview rindió mejor que el resto, lo cual tiene sentido: allí lo más importante es preseleccionar herramientas y acertar con el endpoint.

Cuando aumentaba la profundidad del razonamiento, la calidad caía en todos los modelos: las preguntas de 2 saltos y, sobre todo, de 3 o más saltos reducían la precisión de forma notable. La situación empeoraba aún más al combinar APIs con recuperación de documentos. Los autores señalan un fallo revelador: en parte de las tareas RAG de 1 salto, GPT-OSS-120B a veces no llamaba al retriever en absoluto e intentaba responder «de memoria», algo que este benchmark cuenta como error.

Las políticas añadían otra capa de dificultad: los modelos o violaban las restricciones, o las cumplían pero no reunían la información necesaria para responder.

Qué significa

VAKRA muestra una verdad incómoda pero útil sobre los sistemas agénticos: saber montar una demo vistosa con tool calling todavía no implica estar listo para procesos de negocio reales. Para los equipos que eligen modelo para soporte, analítica, compliance o workflows internos, la pregunta principal ya no es «¿sabe llamar a herramientas?», sino «¿mantiene una cadena de acciones correcta bajo restricciones, a través de varias fuentes y sin atajos autosuficientes?».