VAKRA muestra límites de agentes en razonamiento y APIs | Keryc
VAKRA es un benchmark ejecutable que prueba si los agentes de IA no solo saben llamar herramientas, sino si pueden componer pasos, manejar datos y respetar políticas en entornos parecidos a los de una empresa. ¿Tu agente realmente razona o solo adivina el siguiente API a usar? Aquí te explico cómo está hecho VAKRA, qué mide y por qué sus resultados importan para desplegar agentes en producción.
Qué es VAKRA y por qué importa
VAKRA (tool-grounded, executable benchmark) evalúa la capacidad de agentes para completar flujos de trabajo multi-paso en entornos reales: más de 8,000 APIs locales, 62 dominios y colecciones de documentos alineadas por dominio. A diferencia de benchmarks aislados, VAKRA exige composición: combinar llamadas a APIs estructuradas con recuperación de documentos no estructurados, respetando restricciones de uso cuando aplican.
¿El objetivo? Medir no solo la respuesta final, sino la trayectoria de ejecución completa: llamadas a herramientas, argumentos, salidas intermedias y la respuesta final. Esa evaluación ejecutable es lo que revela fallas sutiles que los tests clásicos no captan.
Arquitectura y colecciones de herramientas
Entorno ejecutable: un MCP server expone APIs locales y evita transferencias de datos pesadas manteniendo los datasets servidor-side.
Colecciones de herramientas:
SLOT-BIRD: 7 herramientas genéricas de manipulación de datos (filtrar, ordenar, etc.).
SEL-BIRD: colecciones más grandes con funciones específicas (p. ej. sort_data_ascending y sort_data_descending), y getters por clave como get_team_name.
REST-BIRD: APIs estilo endpoint servidas por FastAPI, cada dominio tiene entre 6 y 328 herramientas (media ~116).
Instrumento clave: la función get_data(tool_universe_id=...) que debes invocar al comenzar la instancia. Retorna una vista previa ligera y registra el dataset en el servidor.
Pequeño ejemplo de flujo (versión resumida):
{
"query": "Which football team has a build-up play speed of 31...",
"tool_calls": [
{"name": "get_data", "arguments": {"tool_universe_id": "..."}},
{"name": "select_data_equal_to", "arguments": {"key_name": "play_speed", "value": 31}},
{"name": "get_team_name", "arguments": {"n": 1}}
],
"answer": "FC Barcelona"
}
Las cuatro capacidades que mide VAKRA
BI API (SLOT-BIRD y SEL-BIRD) - 2,077 instancias: secuenciar 1-12 llamadas a herramientas para derivar respuestas desde datasets tabulares.
Tool Selection (REST-BIRD) - 1,597 instancias: elegir la API correcta dentro de un gran conjunto de endpoints.
MultiHop API (REST-BIRD) - 869 instancias: razonamiento multi-hop sobre APIs (1-5 saltos lógicos).
MultiHop MultiSource + Políticas (REST-BIRD + documentos) - 644 instancias: mezcla APIs y recuperación de documentos, diálogos multi-turno y políticas de uso de herramientas.
La capacidad 4 es la más compleja: por hop se especifica la fuente requerida (API o recuperación de documentos). Para evitar filtraciones de información, cada fuente es decontaminada: la información necesaria para un hop está disponible únicamente en la fuente designada.
Evaluación ejecutable: cómo se juzga un agente
VAKRA no se queda en comparar respuestas finales. Su evaluador usa dos entradas por muestra: la respuesta final predicha y la trayectoria de llamadas a herramientas. El pipeline es en cascada:
Para la capacidad 4, primero se verifica el cumplimiento de políticas.
Se compara la secuencia de herramientas predicha contra la verdad de base, pero con flexibilidad: se permite secuencias alternativas si las salidas recuperadas cubren la información requerida.
Si la trayectoria es válida, se evalúa la respuesta final con un juzgador LLM que verifica que esté fundamentada en las salidas de las herramientas.
Para manejar equivalencias estructurales (orden, agregación, formato), primero se hace una comprobación programática. Si hay ambigüedad, se recurre a una evaluación LLM adaptada del marco CRAG para decidir si la trayectoria predicha recupera toda la información necesaria.
Esto significa que un agente puede obtener puntos si usa rutas diferentes a las del creador del conjunto, siempre que recupere la misma información.
Métricas y scoring
Cada capacidad tiene igual peso para el puntaje final.
Dentro de capacidades 1-3, cada muestra vale igual.
En la capacidad 4 se ponderan consultas heterogéneas más alto por su complejidad.
La evaluación considera tanto la exactitud de la respuesta final como la completitud y validez de la trayectoria de herramientas.
Principales modos de falla (análisis técnico)
VAKRA clasifica fallas por el primer punto de quiebre en la ejecución, siguiendo este orden:
Selección de herramienta incorrecta.
Omisión o alucinación en los argumentos requeridos.
Valores incorrectos en los argumentos.
Respuesta final no precisa o no fundamentada en las salidas de las herramientas.
Al asignar cada muestra al primer fallo detectado se evita doble conteo y se obtiene una distribución disjunta de errores. Esto facilita interpretar dónde se rompen los agentes en la cadena de razonamiento.
Resultados y lecciones de los modelos evaluados
Rendimiento general: los modelos aún obtienen puntajes bajos en VAKRA. Seleccionar APIs aisladas no alcanza para un despliegue robusto.
BI API (SLOT vs SEL): GPT-OSS-120B lidera en esta capacidad, por su mejor manejo de esquemas y parámetros. En SLOT-BIRD (pocos tools, muchos parámetros) otros modelos fallan mucho en valores de argumentos. En SEL-BIRD (muchos tools, menos parámetros) los errores de selección de herramienta aumentan.
Tool Selection (REST-BIRD): Gemini-3-flash-preview se desempeña mejor en la selección de herramientas.
Multi-hop: la precisión cae con la profundidad del hop; 1-hop es mucho más fácil que 2-hop y 3+ hop.
Multi-source y RAG: incluir documentos complica todo. Algunos modelos, como GPT-OSS-120B, a veces omiten la llamada de recuperador en 1-hop RAG y devuelven la respuesta por memoria paramétrica, especialmente en preguntas tipo entidad de Wikipedia.
Políticas: imponer restricciones de uso de herramientas reduce el rendimiento. Muchos modelos violan políticas o no recuperan suficiente información cumpliendo las restricciones. Solo Granite-4.0-h-Small-32B muestra menos caída en ciertos tipos de políticas.
Figuras y gráficas del blog original detallan la distribución de errores por colección y por tipo de interacción (API, RAG, híbrido), y cómo la profundidad de hop y la presencia de políticas afectan la precisión.
¿Qué significa esto para quienes construyen agentes?
Dominio y esquema importan tanto como la capacidad del LLM. Un buen entendimiento de esquemas de herramientas reduce errores de argumentos.
Debes diseñar shortlisting de herramientas cuando limitaciones de API (p. ej. límite de 128 tools en la especificación OpenAI) te lo impongan.
Las políticas de uso son exigentes en producción. Pruebas tipo VAKRA ayudan a descubrir si tu agente puede seguir restricciones operativas sin perder precisión.
El evaluador ejecutable de VAKRA es una receta práctica para validar agentes de extremo a extremo: permite verificar que las rutas alternativas sean válidas y que las respuestas estén fundamentadas.
Si crees que tu agente ya está listo para producción, este es el lugar para saberlo con evidencia ejecutable. VAKRA no perdona atajos: te muestra si fallas en selección de herramientas, razonamiento multi-hop o en respetar políticas.
