# VAKRA: Evaluating Multi-Hop Reasoning Across APIs and Retrieval Under Tool-Use Policies
> Ficha editorial pública de Research IA. Estado: Lectura primaria completa. La interpretación editorial no sustituye la fuente primaria.

- Página canónica: https://luiseduardodemiguel.com/research-ia/papers/vakra
- Fuente primaria: https://arxiv.org/abs/2608.12282
- Versión leída: v1
- Fuente comprobada: 2026-08-20 · método, resultado y límites revisados; fuente primaria enlazada
- Autores: Ankita Rajaram Naik, Anupama Murthi, Benjamin Elder y colaboradores; IBM Research
- Fecha del corte: 12 AGO 2026
- Área: AGENTES · APIs · RAG · EVALUACIÓN

## Tesis y contexto

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.

- Problema: Los benchmarks suelen separar tool-use y retrieval, aunque una operación real necesita cruzarlos y respetar permisos, políticas y entidades ambiguas.
- Por qué importa: 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.

## Evidencia reportada

- **reported-result**: 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%. [localizador](https://arxiv.org/html/2608.12282v1#S5.F2)

## Lectura y límite

- 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.
- Límite: Un benchmark ejecutable no reproduce completamente permisos, latencias, datos incompletos ni consecuencias de una acción real.
- Confianza editorial: Alta
- Limitación: La reejecución contra APIs y políticas del benchmark controla la evaluación, pero no reproduce permisos cambiantes, latencias, datos incompletos ni el coste de una acción empresarial real.
- Limitación: La métrica de éxito acepta caminos alternativos como correctos y puede ocultar en qué salto se pierde la identidad, la evidencia o la restricción.

## Localizadores de evidencia
- [Fuente primaria · canonical](https://arxiv.org/abs/2608.12282): tipo abstract
- [HTML · evaluación](https://arxiv.org/html/2608.12282v1): tipo abstract
- [Figura 2 · accuracy multi-hop](https://arxiv.org/html/2608.12282v1#S5.F2): tipo figure
- [Código · GitHub](https://github.com/IBM/VAKRA): tipo section
- [HTML · fuente navegable](https://arxiv.org/html/2608.12282): tipo abstract

## Próxima prueba

- ¿Un registro explícito de entidades, fuentes y políticas reduce el deterioro entre uno y tres saltos de herramienta?
- Métrica: Exactitud de la tarea, exactitud por salto, violaciones de política, llamadas innecesarias y cobertura de evidencia.
- Regla de parada: Parar si el ledger no aporta 5 puntos en cadenas de tres saltos o añade más de 15% de llamadas sin recuperar exactitud.

## Recursos reproducibles
- [Código · GitHub](https://github.com/IBM/VAKRA)
- [Dataset · Hugging Face](https://huggingface.co/datasets/ibm-research/VAKRA)

## Enlaces relacionados

- [SAG](https://luiseduardodemiguel.com/research-ia/markdown/papers/sag)
- [TTT-Embed](https://luiseduardodemiguel.com/research-ia/markdown/papers/ttt-embed)
- [Diagnosis Before Recovery](https://luiseduardodemiguel.com/research-ia/markdown/papers/diagnosis-before-recovery)