IBM Research décortique où les agents IA échouent sur les API, les documents et les règles dans VAKRA

IBM Research a publié une analyse détaillée des raisons pour lesquelles même les modèles de langage puissants butent encore sur les tâches destinées aux systèmes agentiques. La nouvelle étude du benchmark VAKRA montre qu'appeler proprement une seule API ne suffit pas : les problèmes commencent quand il faut enchaîner plusieurs étapes, choisir la bonne source de données et ne pas enfreindre les règles d'utilisation des outils.

Comment fonctionne VAKRA

VAKRA est un benchmark exécutable pour les agents d'entreprise. Au lieu d'appels de fonctions factices, il fournit aux modèles un environnement de travail avec plus de 8 000 API hébergées localement, de vraies bases de données couvrant 62 domaines et des collections de documents adaptées à des domaines précis. Un scénario type exige non pas une réponse, mais une chaîne de 3–7 étapes : récupérer des données, choisir le bon outil, extraire un fait d'un document, transmettre le résultat à l'appel suivant et seulement ensuite composer la réponse finale.

L'idée clé est que VAKRA n'évalue pas seulement la réponse finale du modèle, mais toute la trajectoire de ses actions. Pour les tâches complexes, le système vérifie d'abord que l'agent a respecté les contraintes textuelles d'utilisation des outils, rejoue ensuite ses appels dans le même environnement, compare les résultats intermédiaires à une référence et n'évalue qu'après la réponse finale. Cette approche compte, car un agent peut deviner la conclusion par hasard tout en y arrivant par un mauvais chemin, ce qui est presque inutile en production.

Quatre types de tâches

Les auteurs répartissent VAKRA en quatre modes, chacun testant une couche distincte du comportement agentique. Ensemble, ils couvrent un spectre allant du simple enchaînement d'API au raisonnement multi-étapes sur des API et des documents sous contraintes externes. C'est important, car beaucoup d'agents paraissent assurés sur des appels isolés, mais se perdent vite quand ils doivent à la fois planifier les étapes, passer d'une source à l'autre, garder le contexte du dialogue et se souvenir des règles d'accès aux outils.

• Business Intelligence APIs : 2 077 tâches dans 54 domaines, où l'agent doit appeler successivement de 1 à 12 outils et manier avec soin les paramètres et le filtrage des données.
• Dashboard APIs : 1 597 tâches dans 17 domaines, où la principale difficulté est de choisir le bon endpoint parmi 6–328 outils disponibles.
• Multi-hop over APIs : 869 tâches dans 38 domaines, où la réponse se construit en plusieurs sauts logiques, d'un à cinq.
• Multi-source + policies : 644 tâches dans 41 domaines, où l'agent alterne entre API et recherche dans des documents, tient compte de l'historique du dialogue et respecte des règles textuelles comme « utilise uniquement le retriever, ne touche pas aux autres outils ».

Où les agents se trompent

La partie la plus utile de l'article est l'analyse de l'endroit précis où les modèles échouent. Les auteurs classent les erreurs par étape : choix d'un mauvais outil, omission d'arguments nécessaires ou hallucinations dans ceux-ci, valeurs de paramètres erronées et, enfin, réponse finale fausse même après des appels corrects.

Sur le segment BI API, GPT-OSS-120B s'est montré le meilleur : il comprenait nettement mieux les schémas d'outils que les autres et se trompait moins dans les noms et le remplissage des paramètres. Mais même là, la réussite sur des étapes isolées ne garantissait pas un résultat end-to-end stable.

Sur les tâches avec un grand nombre de dashboard APIs, Gemini-3-flash-preview a fait mieux que les autres, ce qui est logique : ce qui compte le plus ici, c'est la présélection des outils et le choix exact de l'endpoint.

À mesure que la profondeur de raisonnement augmentait, la qualité chutait pour tous les modèles : les questions à 2 sauts et surtout à 3 sauts ou plus faisaient nettement baisser la précision. Cela empirait encore quand il fallait combiner des API avec de la récupération de documents. Les auteurs relèvent un échec révélateur : sur une partie des tâches RAG à 1 saut, GPT-OSS-120B n'appelait parfois pas du tout le retriever et tentait de répondre « de mémoire », ce que ce benchmark compte comme une erreur.

Les politiques ajoutaient une couche de difficulté supplémentaire : les modèles soit enfreignaient les contraintes, soit les respectaient mais ne réunissaient pas l'information nécessaire pour répondre.

Ce que cela signifie

VAKRA met en lumière une vérité désagréable mais utile sur les systèmes agentiques : savoir réaliser une jolie démo de tool calling ne signifie pas encore être prêt pour de vrais processus métier. Pour les équipes qui choisissent un modèle pour le support, l'analytique, la conformité ou les workflows internes, la question principale n'est plus « sait-il appeler des outils ? », mais « conserve-t-il une chaîne d'actions correcte sous contraintes, à travers plusieurs sources et sans raccourcis présomptueux ? ».