🤖 AI

Simulating Complex Multi-Turn Tool Calling Interactions in Stateless Execution Environments

Ce papier présente DiGiT-TC, une nouvelle méthode de génération de données qui synthétise des conversations complexes d'appels d'outils multi-tours pour des environnements d'exécution sans état en représentant implicitement les appels d'outils au sein des requêtes utilisateur, permettant ainsi un réglage efficace de modèles de langage plus petits sans dépendre d'une validation avec état.

Auteurs originaux : Maxwell Crouse, Ibrahim Abdelaziz, Kshitij Fadnis, Siva Sankalp Patel, Kinjal Basu, Chulaka Gunasekara, Sadhana Kumaravel, Asim Munawar, Pavan Kapanipathi

Publié 2026-05-12

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Maxwell Crouse, Ibrahim Abdelaziz, Kshitij Fadnis, Siva Sankalp Patel, Kinjal Basu, Chulaka Gunasekara, Sadhana Kumaravel, Asim Munawar, Pavan Kapanipathi

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayiez d'enseigner à un majordome robotisé comment gérer des courses complexes, comme « Trouver un film, vérifier les horaires de projection et acheter un billet pour le premier disponible ».

Dans le monde réel, si vous testiez ce robot, vous lui permettriez d'exécuter réellement ces commandes dans un véritable système de cinéma. Vous le verriez consulter la base de données, observer les résultats, puis acheter le billet. S'il réussit, vous savez qu'il a bien appris. C'est ce que la plupart des chercheurs en IA ont fait jusqu'à présent : ils ont construit des « terrains de jeu » où le robot peut réellement toucher et modifier des choses (un environnement avec état).

Le Problème :
Mais que faire si vous ne pouvez pas laisser le robot toucher le monde réel ? Peut-être que les données sont trop sensibles (comme la liste secrète des clients d'une banque), ou peut-être que le « terrain de jeu » est trop coûteux à construire. Dans ces cas, vous ne pouvez pas tester le robot en lui permettant de s'exécuter. Vous devez l'enseigner en utilisant uniquement une liste d'instructions (spécifications d'outils) sans jamais voir les résultats réels.

La plupart des méthodes précédentes ont tenté de simuler cela en faisant semblant que le robot avait exécuté les commandes. Mais elles ont manqué un aspect crucial de la conversation humaine : les Étapes Implicites.

Lorsque vous demandez à un assistant humain de « Réserver un billet pour le premier horaire », vous ne dites pas : « D'abord, exécutez l'outil 'vérifier les horaires', puis exécutez l'outil 'réserver un billet' ». Vous donnez simplement l'objectif. L'assistant sait qu'il doit vérifier d'abord, même si vous ne l'avez pas dit. C'est un appel d'outil implicite. Les méthodes précédentes avaient du mal à créer des données d'entraînement qui enseignaient aux robots à déduire ces étapes cachées par eux-mêmes.

La Solution : DiGiT-TC (La Méthode « Ingénierie Inverse »)
Les chercheurs d'IBM ont introduit une nouvelle méthode appelée DiGiT-TC. Au lieu de demander au robot : « Que devrais-je faire ensuite ? », ils ont inversé la logique.

Pensez-y comme à un réalisateur de film travaillant à l'envers :

Le Réalisateur Écrit d'Abord le Scénario : Le système demande d'abord à une IA puissante d'écrire la séquence complète d'actions que le robot doit entreprendre pour résoudre un problème (par exemple : Vérifier les horaires -> Réserver un billet).
Le « Monteur » Cache les Indices : Le système agit ensuite comme un éditeur astucieux. Il prend ce scénario complet et décide quelles étapes cacher à l'« utilisateur ». Il garde l'objectif final (Réserver un billet) visible, mais cache l'étape intermédiaire (Vérifier les horaires).
Le « Traducteur » Écrit l'Invite : Maintenant, le système demande à l'IA d'écrire une demande utilisateur qui correspond uniquement aux parties visibles. Ainsi, l'utilisateur dit : « Réservez un billet pour le premier horaire », et l'IA sait qu'elle doit déduire l'étape cachée « Vérifier les horaires » par elle-même.
La « Double Vérification » (Traduction Inverse) : Pour s'assurer que l'IA ne s'est pas trompée, le système effectue un « test inverse ». Il prend la demande de l'utilisateur (« Réservez un billet... ») et demande à l'IA de la résoudre à partir de zéro. Si l'IA trouve exactement les mêmes étapes cachées que le scénario original, les données sont bonnes. Si l'IA se trompe, les données sont rejetées.

Pourquoi Cela Compte :
En utilisant cette approche d'« ingénierie inverse », les chercheurs ont créé une vaste bibliothèque de données d'entraînement où le robot apprend à combler les blancs. Ils ont testé cela sur des benchmarks d'« examens » standard (comme BFCL et τ-bench) et ont constaté que :

Les robots entraînés sur ces données sont nettement meilleurs pour gérer des tâches multi-étapes.
Ils ont obtenu des performances égales ou supérieures à celles des robots entraînés sur des données beaucoup plus coûteuses générées par des modèles propriétaires de premier plan.
La méthode fonctionne même sans véritable « terrain de jeu » pour tester le robot, ce qui la rend sûre pour des environnements sensibles comme les banques ou les hôpitaux.

En Résumé :
L'article affirme qu'en générant des données « à l'envers » — en commençant par la solution et en remontant vers la question — ils peuvent enseigner à des modèles d'IA plus petits et moins chers de gérer des tâches complexes et multi-étapes aussi bien que les grands modèles coûteux, sans avoir besoin d'accéder à des systèmes de données réels et sensibles pendant le processus d'entraînement. Ils ont rendu tout leur code et leurs données accessibles à tous.

Résumé technique : Simulation d'interactions complexes d'appels d'outils multi-tours dans des environnements d'exécution sans état

Énoncé du problème

Les données synthétiques constituent une ressource cruciale pour l'ajustement de modèles de langage (LLM) plus petits et économiques afin qu'ils gèrent des appels d'outils complexes sur plusieurs tours. Cependant, les cadres existants pour générer de telles données supposent fréquemment la disponibilité d'un environnement d'exécution avec état. Dans ces environnements, la validité d'une interaction est déterminée par le fait que l'état d'exécution correspond à un objectif pré-spécifié.

Cette hypothèse échoue dans de nombreux scénarios réels, en particulier dans les contextes d'entreprise où la sécurité des données interdit l'accès privilégié aux backends en direct, ou lorsque les spécifications des outils sont synthétisées à partir de multiples sources sans état unifié. De plus, de nombreux modèles de langage open-source de premier plan sont formés sur des outils synthétiques générés par des LLM, qui ne peuvent être simulés que. Les méthodes actuelles peinent à générer des interactions multi-tours significativement complexes avec des appels d'outils implicites (où la demande de l'utilisateur ne spécifie pas explicitement chaque outil nécessaire) sans accès à un backend réel avec état.

Méthodologie : DiGiT-TC

Les auteurs présentent DiGiT-TC (Data Generation and Transformation for Tool-Calling), un cadre conçu pour produire des conversations synthétiques d'appels d'outils multi-tours imitant la complexité de l'exploration avec état, malgré le fonctionnement dans un environnement sans état. L'innovation centrale est un « renversement » du processus de génération : au lieu de générer une demande utilisateur puis d'en déduire des appels d'outils, DiGiT-TC génère d'abord une séquence d'appels d'outils, puis construit une demande utilisateur correspondante.

Le cadre fonctionne selon les étapes suivantes :

Initialisation : Une conversation est initialisée avec une liste de messages vide, un ensemble d'outils échantillonnés et un persona utilisateur. Le persona est enrichi de détails spécifiques (par exemple, lieu, profession) pertinents pour les outils échantillonnés.
Distillation du plan :
- Un LLM génère une séquence brute d'appels d'outils ( $S$ ) basée sur le persona et les outils. Ces appels incluent des références inter-outils (par exemple, l'utilisation de la notation pointée Pythonique comme $1.output pour transmettre des données entre les appels).
- La séquence est traitée comme un graphe acyclique dirigé (DAG). Le cadre la distille en une sous-séquence plus concise en sélectionnant le plus grand composant connecté, en filtrant les appels d'outils redondants ou déconnectés.
Génération de la demande (Sélection d'appels d'outils implicites) :
- La séquence distillée $S$ est partitionnée en deux ensembles : Explicite ( $E$ ) et Implicite ( $I$ ).
- Un algorithme sélectionne aléatoirement une taille cible pour l'ensemble implicite. Il retire itérativement les éléments de $S$ qui ne sont pas des dépendances d'autres éléments, garantissant que l'ensemble implicite restant contient des appels d'outils nécessaires à l'ensemble explicite mais non mentionnés directement par l'utilisateur.
- Le LLM génère une demande utilisateur ( $r$ ) ciblant explicitement la séquence $E$ tout en évitant toute mention directe des outils dans $I$ .
- Validation : Pour s'assurer que la demande utilisateur n'est pas une transcription triviale de la séquence d'outils, le cadre calcule le coefficient de corrélation $\tau_b$ de Kendall entre le rang des arguments dans les appels d'outils et leur ordre d'apparition dans la demande utilisateur. Si la corrélation est trop élevée (indiquant une correspondance linéaire et explicite), l'exemple est filtré.
Retraduction :
- Pour atténuer le bruit et garantir que la demande utilisateur générée conduit effectivement à la séquence d'outils prévue, le cadre effectue une étape de retraduction.
- Un LLM est invité à prédire une nouvelle séquence d'outils ( $S'$ ) basée uniquement sur la demande utilisateur générée ( $r$ ) et les outils disponibles.
- Le système valide que les « feuilles » (sorties finales) de la séquence originale $S$ sont représentées dans $S'$ . Si la condition leaves(S) \ leaves(S') = ∅ échoue, l'exemple est rejeté.
Terminaison et Augmentation :
- Exécution et Résumé : Les appels d'outils sont simulés (exécutés via un LLM) pour substituer les valeurs des variables et générer un résumé des résultats.
- Augmentation des erreurs : Le cadre introduit de la complexité en simulant deux types d'erreurs :
  - Erreurs humaines : Demandes utilisateur insolubles ou incomplètes nécessitant des clarifications.
  - Erreurs d'exécution d'outils : Appels d'outils incorrects simulés suivis d'un indice (généré par un LLM) guidant le modèle vers la solution correcte.

Contributions clés

Génération sans état d'appels implicites : DiGiT-TC est le premier cadre à générer systématiquement des interactions multi-tours complexes avec des appels d'outils implicites sans nécessiter de backend d'exécution avec état.
Stratégie de génération sélective : En inversant l'ordre de génération (Appels d'outils $\to$ Demande utilisateur), la méthode obtient un contrôle granulaire sur quels appels sont explicites et lesquels sont implicites.
Atténuation du bruit par retraduction : L'introduction d'une étape de retraduction garantit que les demandes utilisateur générées sont robustes et correspondent fidèlement aux séquences d'outils prévues, filtrant les hallucinations ou les désalignements.
Écosystème open-source : Les auteurs ont entièrement rendu open-source le cadre de génération de données, les invites et le jeu de données résultant (5 000 points de données), tous produits en utilisant GPT-OSS-120B, un modèle enseignant à poids ouverts et sous licence favorable.

Résultats expérimentaux

Les auteurs ont évalué DiGiT-TC sur trois benchmarks standard : BFCL (Berkeley Function Calling Leaderboard), $\tau$ -bench, et ACEBench.

Gains de performance : L'ajustement fin de modèles de base (par exemple, Granite-4.1-3B, Llama3.1-8B-Inst) avec des données DiGiT-TC a entraîné des améliorations de performance significatives (allant de 6 à 25 points de pourcentage) par rapport aux modèles de base.
Comparaison des benchmarks :
- Sur la catégorie BFCL Multi-Tour, DiGiT-TC (utilisant Llama3.1-8B-Inst) a atteint une précision de 35,5 %, surpassant d'autres approches de données ouvertes comme ToolWeave (25,0 %) et Magnet (26,5 %), et se rapprochant des performances des modèles formés sur des données de pointe (par exemple, ToolACE-MT à 40,3 %).
- La méthode a démontré une forte généralisabilité sur $\tau$ -bench et ACEBench, surpassant constamment les approches antérieures formées exclusivement sur des données open-source.
Études d'ablation :
- Le retrait des appels d'outils implicites a causé une baisse de performance de 4 %, confirmant leur nécessité pour le raisonnement complexe.
- Le retrait de la retraduction a causé une baisse de 3 %, soulignant son rôle dans la réduction du bruit.
- L'utilisation d'un modèle enseignant plus petit (GPT-OSS-20B) a entraîné une baisse d'environ 2 %, suggérant que bien que les modèles plus grands aident, la méthode reste efficace avec des modèles plus petits et accessibles.

Importance et revendications

L'article affirme que DiGiT-TC comble une lacune critique dans le développement de l'IA agentique : la capacité à entraîner des modèles plus petits sur des données d'appels d'outils complexes et multi-tours sans les risques de confidentialité et les coûts associés à l'accès à des backends réels avec état.

Confidentialité et évolutivité : En s'appuyant uniquement sur les spécifications d'outils et des modèles à poids ouverts, l'approche évite les risques de sécurité des données liés à l'interface avec les backends d'entreprise.
Rentabilité : Les auteurs notent que l'utilisation de GPT-OSS-120B est nettement moins chère que l'utilisation de modèles de pointe comme GPT-4o (environ 0,015 $ par exemple contre des coûts nettement plus élevés pour GPT-4), rendant la génération de données synthétiques de haute qualité accessible à un plus large éventail de praticiens.
État de l'art pour les modèles ouverts : Ce travail établit un nouvel état de l'art pour la performance des appels d'outils multi-tours parmi les modèles formés exclusivement sur des données produites par des modèles enseignants open-source à poids ouverts.

Les auteurs reconnaissent modestement que pour les tâches où une simulation complète de l'état d'un système est disponible, les méthodes exploitant cet état pourraient encore être supérieures. Cependant, DiGiT-TC fournit un processus robuste et reproductible pour générer des données d'entraînement de haute qualité en l'absence de tels environnements.