WildToolBench : Pourquoi aucun LLM ne dépasse 15 % de précision par session dans l'utilisation d'outils en conditions réelles
Les benchmarks d'utilisation d'outils que je suis de près — BFCL, ToolBench, τ-bench — partagent tous un défaut de conception commun : ils construisent des tâches à partir de l'imagination des auteurs sur ce que font les utilisateurs. WildToolBench, accepté à l'ICLR 2026, revient aux journaux d'utilisation réels et demande ce que les utilisateurs font réellement. La réponse invite à l'humilité : sur 57 LLM évalués, aucun ne dépasse 15 % de précision par session.
L'article
Peijie Yu, Wei Liu, Yifan Yang et leurs collègues d'Alibaba présentent WildToolBench (arXiv:2604.06185), un benchmark de 256 scénarios de dialogue multi-tours comprenant 1 024 tâches tirées de schémas de comportement d'utilisateurs authentiques et basées sur environ 1 600 API publiques. L'argument central est que les benchmarks existants saturent non pas parce que les modèles sont bons, mais parce que les tâches sont artificielles. Les utilisateurs réels regroupent leurs requêtes, omettent le contexte partagé deux tours plus tôt et passent d'une question sur un outil à une conversation informelle ou à une demande de clarification — parfois au sein d'un seul message. WildToolBench opérationnalise ces modes d'échec en trois catégories de défis structurés et mesure à la fois la précision au niveau de la tâche et la précision beaucoup plus stricte au niveau de la session, qui exige de réussir les quatre tâches d'un dialogue.
Idées clés
- La précision par session s'effondre à un chiffre pour la plupart des modèles : Gemini-2.0-Flash-Thinking mène avec 14,45 % de précision par session, suivi de Claude-4-Sonnet à 12,50 % et GPT-4o à 11,72 %. Réussir toutes les tâches d'une session de quatre tours est si difficile que même une précision de 60 % par tâche se traduit par moins de 15 % de précision par session — une taxe de probabilité composée sur chaque interaction.
- L'orchestration compositionnelle est le point de rupture le plus net : Les topologies d'outils mixtes (séquentielles et parallèles) limitent les meilleurs modèles à 25 % de précision par tâche, contre 54 à 62 % pour les chaînes purement parallèles ou séquentielles. Lorsqu'une tâche nécessite une dispersion parallèle suivie d'une fusion séquentielle, le problème de coordination dépasse ce que n'importe quel modèle actuel gère de manière fiable.
- L'intention cachée représente un écart plus important que tout ce qui a été mesuré auparavant : WildToolBench garantit que 100 % des tâches impliquent des informations implicites ou transversales aux tours de parole ; BFCL v3 n'en gère que 15,7 %. Les tâches de dépendance à longue portée — où l'information manquante remonte à plus de deux tours — sont le sous-type le plus difficile, aucun modèle ne franchissant la barre des 50 %, même au niveau de la tâche.
- Les transitions d'instructions cumulent les erreurs à un rythme linéaire : Chaque changement de politique supplémentaire (tâche d'outil → chat → clarification → tâche d'outil) fait chuter la précision d'environ 5 à 15 points de pourcentage. À trois transitions, les modèles les plus touchés perdent 30 points. Les auteurs appellent cela l'« auto-conditionnement » : les réponses précédentes biaisent l'interprétation par le modèle des instructions suivantes d'une manière difficile à corriger en milieu de session.
- Le taux de chemin optimal (Optimal Path Rate) reste inférieur à 43 % : Même lorsque les modèles terminent les tâches correctement, ils consomment des appels API excédentaires. Claude-4-Sonnet atteint le meilleur taux de chemin optimal avec 42,74 %, ce qui signifie que la majorité des exécutions correctes prennent plus d'étapes que nécessaire — un coût direct en latence et en jetons pour tout système de production.
- Les modèles spécialisés dans l'utilisation d'outils sous-performent par rapport aux modèles frontières généralistes : xLAM-2-70B et ToolACE2-8B affichent tous deux des taux d'erreur de nom de fonction incorrect dépassant 30 %, soit pire que GPT-4o ou Claude-4-Sonnet. Le réglage fin sur des corpus restreints d'utilisation d'outils semble créer de la fragilité plutôt que de la robustesse face au changement de distribution des comportements réels.
Ce qui tient la route — et ce qui ne tient pas
La conception du benchmark est solide là où cela compte le plus. La distinction entre précision par tâche et précision par session est tout à fait juste : le cumul des modes d'échec est ce qui tue les déploiements réels, et la plupart des travaux antérieurs rapportent des chiffres au niveau des tâches qui masquent cette réalité. La taxonomie des trois défis (orchestration compositionnelle, intention cachée, transitions d'instructions) est bien motivée et étayée empiriquement — les courbes de dégradation des performances selon les types de défis sont réelles et frappantes.
Le point faible est l'échelle. 1 024 tâches réparties sur 256 scénarios constituent un artefact de recherche crédible, mais c'est peu pour un classement destiné à suivre 57 modèles dans le temps. Les auteurs le reconnaissent directement et mentionnent un pipeline de mise à l'échelle automatisé pour les travaux futurs. L'autre problème est que l'expression « basé sur des journaux d'utilisateurs réels » est lourde de sens : les tâches finales sont partiellement synthétiques, construites par un système multi-agents à partir de modèles de base, puis vérifiées par des annotateurs humains. La revendication est fondée sur le réel, mais les données ne sont pas textuellement brutes — elles sont inspirées du réel. Cela compte pour l'interprétation littérale du plafond de 15 % ; une partie de l'écart pourrait se réduire si le pipeline de génération introduit une difficulté artificielle que les utilisateurs réels ne manifestent pas.
Je suis également sceptique quant à l'analyse des transitions d'instructions en tant qu'affirmation architecturale. L'article l'attribue à une limitation fondamentale, mais l'inadéquation de la distribution d'entraînement entre les objectifs de réglage fin RLHF et les sessions utilisateur multi-modales est l'explication la plus simple. C'est un problème adressable, pas structurel.
Pourquoi c'est important pour l'IA financière
Les trois modes d'échec correspondent presque parfaitement à la manière dont les utilisateurs réels interagissent avec un agent d'écriture Beancount. Un utilisateur demande : « combien ai-je dépensé en courses le mois dernier, et tant que tu y es, ajoute le reçu Whole Foods d'aujourd'hui » — c'est une tâche compositionnelle regroupée en un seul tour. Il enchaîne avec : « en fait, mets 47,23 $ et non 42 $, j'ai vérifié » — c'est une correction de paramètre exigeant que l'agent suive l'état de la session. Puis il demande : « est-ce que cette catégorie est correcte ? » — c'est une demande de clarification, et l'agent ne doit pas ré-exécuter l'opération d'écriture qu'il vient de terminer. Le plafond de 25 % sur l'orchestration mixte et la chute de 30 points due aux transitions d'instructions sont exactement les modes d'échec qui se manifesteraient chez un agent de grand livre traitant des sessions utilisateur réelles.
Le constat selon lequel les modèles spécialisés sous-performent par rapport aux modèles généralistes est particulièrement pertinent. Si nous envisagions de régler finement un modèle ouvert plus petit sur des exemples d'appels d'outils spécifiques à Beancount — la stratégie évidente de réduction des coûts — WildToolBench est un avertissement direct : la spécialisation peut sacrifier la robustesse face à la distribution des comportements réels des utilisateurs. Le résultat sur le taux de chemin optimal compte aussi : un agent qui utilise deux fois plus d'appels API pour accomplir une tâche n'est pas seulement inefficace ; pour des opérations d'écriture, des appels intermédiaires redondants peuvent laisser le grand livre dans des états intermédiaires incohérents.
Ce qu'il faut lire ensuite
- ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — le cadre d'entraînement fondamental contre lequel WildToolBench se positionne explicitement ; comprendre sa conception d'évaluation synthétique clarifie exactement ce que l'exécution en direct apporte.
- τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045) — le travail antérieur le plus proche sur l'utilisation réaliste d'outils multi-tours ; comparer les domaines de la vente au détail/compagnies aériennes de τ-bench avec la couverture d'API publiques de WildToolBench montre à quel point le défi est généralisable.
- AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — si le problème de transition d'instructions peut être résolu par la découverte automatique de meilleurs flux de travail d'agents plutôt que par l'augmentation des données d'entraînement, AFlow en est le mécanisme le plus crédible.
