Lo esencial antes de invertir más tiempo.
VAKRA reúne más de 8.000 APIs ejecutables en 62 dominios y evalúa tareas que combinan herramientas, documentos y restricciones en lenguaje natural. El rendimiento cae con fuerza cuando aumenta la profundidad de composición.
VAKRA reporta 70,4% en endpoints de un solo salto y alrededor de 50–51% en APIs composicionales; ciertas consultas no respondibles con políticas caen hasta 2,4%.
Resultado con localizador exacto · 5 localizadores disponibles.Un benchmark ejecutable no reproduce completamente permisos, latencias, datos incompletos ni consecuencias de una acción real.
Exactitud de la tarea, exactitud por salto, violaciones de política, llamadas innecesarias y cobertura de evidencia.
VAKRA reúne más de 8.000 APIs ejecutables en 62 dominios y evalúa tareas que combinan herramientas, documentos y restricciones en lenguaje natural. El rendimiento cae con fuerza cuando aumenta la profundidad de composición.
Qué está reportado y qué conviene comprobar.
VAKRA reporta 70,4% en endpoints de un solo salto y alrededor de 50–51% en APIs composicionales; ciertas consultas no respondibles con políticas caen hasta 2,4%.
70,4%; 50–51%; hasta 2,4% · baseline: endpoint de un solo salto vs composición multi-hop · contexto: Más de 8.000 APIs ejecutables en 62 dominios y tareas con políticas de uso de herramientas
Qué estudiaron y qué cambia.
La síntesis está separada de los resultados reportados y de las inferencias.VAKRA intenta medir la dificultad que aparece cuando un agente empresarial tiene que cruzar herramientas, documentos y políticas en una misma tarea. Una llamada aislada a una API puede ser correcta y aun así la operación completa fallar por una entidad ambigua, una evidencia mal conectada o una restricción que se pierde en el tercer salto.
El benchmark reúne más de 8.000 APIs ejecutables en 62 dominios y separa tres situaciones: distintos estilos de interacción con APIs, composición multi-hop sobre APIs estructuradas y razonamiento multi-fuente con políticas de uso de herramientas expresadas en lenguaje natural. Para aislar el efecto del modelo, los autores fijan un harness ReAct; verifican la corrección reejecutando las llamadas predichas contra APIs vivas y aceptan varios caminos válidos cuando los hay.
Los resultados muestran una caída fuerte al aumentar la composición. El mejor modelo alcanza un 70,4 % en endpoints de un solo salto, pero se mueve alrededor del 50–51 % en APIs composicionales; el rendimiento cae más de un 50 % cuando aumenta la profundidad de razonamiento y llega a tan solo un 2,4 % en ciertas consultas no respondibles con políticas. Según el análisis de fallos, el cuello de botella está más en desambiguar entidades y conectar fuentes que en invocar técnicamente la herramienta.
La aportación para producto es una regla de evaluación: no basta con comprobar si el agente sabe llamar a cada endpoint. Hay que probar el enlace entre fuentes, la trazabilidad de la evidencia y la obediencia a políticas. Aun así, VAKRA es un benchmark ejecutable y no reproduce por completo permisos, latencias, datos incompletos o las consecuencias de una acción real en un sistema enterprise.
Un benchmark ejecutable no reproduce completamente permisos, latencias, datos incompletos ni consecuencias de una acción real.
- PROBLEMA
- Los benchmarks suelen separar tool-use y retrieval, aunque una operación real necesita cruzarlos y respetar permisos, políticas y entidades ambiguas.
- MÉTODO
- Evalúa tareas en las que el agente tiene que cruzar APIs, documentos y políticas. La dificultad no está en una llamada aislada, sino en mantener identidad, evidencia y restricciones a través de varios saltos.
- TIPO DE EVIDENCIA
- Benchmark con miles de APIs ejecutables y dominios heterogéneos; ofrece una medida más cercana a la composición enterprise que los tests de herramienta aislados.
- LÍMITE
- Un benchmark ejecutable no reproduce completamente permisos, latencias, datos incompletos ni consecuencias de una acción real.

Accuracy por tipo de interacción: el gráfico muestra cómo se separan las tareas de API, RAG y sus combinaciones multi-hop.
Ankita Rajaram Naik et al. · VAKRA · arXiv:2608.12282v1 · CC BY-SA 4.0
Consultar licencia ↗Diseñar evaluaciones internas con entidades ambiguas, políticas explícitas y una trazabilidad mínima de por qué se usó cada fuente.
La lectura también deja rastro.
Guarda una observación junto a la evidencia. Tú escribes aquí; los agentes pueden añadir notas por MCP y aparecerán identificados.
LECTURA AMPLIADAMetodología, implicaciones y preguntas para volver al paper.+
Evalúa tareas en las que el agente tiene que cruzar APIs, documentos y políticas. La dificultad no está en una llamada aislada, sino en mantener identidad, evidencia y restricciones a través de varios saltos.
Ofrece una medida más realista del agente enterprise: no basta con saber llamar un endpoint; hay que saber cuándo, con qué evidencia y bajo qué política hacerlo.
Un benchmark ejecutable no reproduce completamente permisos, latencias, datos incompletos ni consecuencias de una acción real.
Cómo lo llevaría a un proyecto
Diseñar evaluaciones internas con entidades ambiguas, políticas explícitas y una trazabilidad mínima de por qué se usó cada fuente.
Preguntas que conviene probar
- ¿En qué salto de la cadena se concentra la pérdida de rendimiento?
- ¿Qué evidencia debe conservarse para poder auditar una decisión?
Si tuviera que convertirlo en una prueba mañana.
Mi lectura
La dificultad enterprise aparece en los enlaces entre fuentes, no en cada herramienta aislada.
Esta última frase es una inferencia editorial a partir del paper y de sus posibles implicaciones; no es una afirmación de los autores.