IBM Research a analysé où les agents AI échouent face aux API, aux documents et aux règles dans VAKRA

IBM Research a mené une analyse détaillée de la raison pour laquelle même les puissants modèles de langage échouent toujours aux tâches des systèmes d'agents. Une nouvelle analyse du benchmark VAKRA montre : faire un élégant appel API ne suffit pas — les problèmes commencent lorsque vous devez passer par plusieurs étapes, sélectionner la bonne source de données et ne pas violer les règles d'utilisation des outils.

Comment VAKRA est structuré

VAKRA est un benchmark exécutable pour les agents d'entreprise. Au lieu d'appels de fonction basiques, il fournit aux modèles un environnement de travail avec plus de 8 000 API déployées localement, des bases de données réelles dans 62 domaines et des collections de documents pour des domaines de spécialisation spécifiques. Un scénario typique exige non pas une réponse unique, mais une chaîne de 3–7 étapes : obtenir des données, sélectionner le bon outil, extraire un fait d'un document, transmettre le résultat à l'appel suivant et ensuite seulement assembler la réponse finale.

L'idée clé est que VAKRA évalue non seulement la réponse finale du modèle, mais toute sa trajectoire d'actions. Pour les tâches complexes, le système vérifie d'abord si l'agent a respecté les contraintes textuelles sur l'utilisation des outils, puis rejoue ses appels dans le même environnement, compare les résultats intermédiaires avec l'étalon et évalue enfin la réponse finale. Cette approche est importante car un agent peut deviner accidentellement la conclusion finale tout en y arrivant par le mauvais chemin — et pour la production, c'est presque inutile.

Quatre types de tâches

Les auteurs divisent VAKRA en quatre modes, chacun testant une couche distincte du comportement de l'agent. Ensemble, ils couvrent le chemin allant du chaînage simple d'API au raisonnement multi-étapes sur les API et les documents avec des contraintes externes. Cela importe car de nombreux agents semblent confiants sur les appels isolés mais se perdent rapidement quand ils doivent simultanément planifier les étapes, basculer entre les sources, maintenir le contexte du dialogue et respecter les règles d'accès aux outils.

• Business Intelligence APIs : 2 077 tâches dans 54 domaines, où l'agent doit appeler séquentiellement 1–12 outils et travailler soigneusement avec les paramètres et le filtrage des données.
• Dashboard APIs : 1 597 tâches dans 17 domaines, où la principale complexité est de sélectionner le bon endpoint parmi 6–328 outils disponibles.
• Multi-hop over APIs : 869 tâches dans 38 domaines, où la réponse est assemblée via plusieurs transitions logiques, de une à cinq.
• Multi-source + policies : 644 tâches dans 41 domaines, où l'agent alterne entre API et recherche de documents, tient compte de l'historique du dialogue et suit des règles textuelles comme « utilise uniquement retriever, ne touche pas aux autres outils ».

Où les agents échouent

La partie la plus utile de l'article est l'analyse de l'endroit où les modèles échouent. Les auteurs divisent les erreurs par étape : choisir le mauvais outil, omettre les arguments nécessaires ou les halluciner, des valeurs de paramètres incorrectes et enfin, une réponse finale incorrecte même après des appels corrects. Sur le segment API de BI, GPT-OSS-120B a obtenu les meilleurs résultats : il a nettement mieux compris les schémas d'outils et a commis moins d'erreurs dans les noms et le remplissage des paramètres.

Mais même là, le succès sur les étapes individuelles ne garantissait pas des résultats stables d'un bout à l'autre. Sur les tâches avec un grand ensemble d'API de tableau de bord, Gemini-3-flash-preview s'est avéré meilleur, ce qui a du sens : là, la capacité à dresser une liste courte d'outils et à sélectionner avec précision un endpoint est la plus importante. À mesure que la profondeur du raisonnement augmentait, la qualité baissait pour tous les modèles : les questions 2-hop et surtout 3+ hop montraient une précision notablement plus faible.

C'était encore pire quand les API devaient être combinées avec la récupération de documents. Les auteurs notent spécifiquement un échec révélateur : sur certaines tâches RAG 1-hop, GPT-OSS-120B n'appelait parfois pas du tout le retriever et tentait de répondre « de mémoire », ce qui dans un tel benchmark compte comme une erreur. Les politiques ajoutaient une autre couche de complexité : les modèles violaient les contraintes ou les respectaient mais ne parvenaient pas à rassembler les informations nécessaires pour la réponse.

Que cela signifie

VAKRA montre une vérité désagréable mais utile sur les systèmes d'agents : la capacité à faire une belle démo avec tool calling ne signifie pas être prêt pour les vrais processus métier. Pour les équipes choisissant un modèle pour le support, l'analyse, la conformité ou les workflows internes, la question principale n'est désormais plus « peut-il appeler des outils », mais « maintient-il une séquence d'actions correcte sous contraintes, entre plusieurs sources et sans raccourcis excessivement confiants ».