Tool Use
Le tool use est la capacité qui permet à un LLM d'invoquer des fonctions, des API, des bases de données ou des services externes en pleine réponse, pour récupérer des données fraîches, effectuer des calculs ou agir dans le monde réel. Au lieu d'être enfermé dans ses données d'entraînement, un modèle doté du tool use peut aller chercher des informations à l'extérieur lorsque la tâche l'exige.
Le tool use est la capacité qui permet à un LLM d'invoquer des fonctions, des API, des bases de données ou des services externes en pleine réponse, pour récupérer des données fraîches, effectuer des calculs ou agir dans le monde réel. Au lieu d'être enfermé dans ses données d'entraînement, un modèle doté du tool use peut aller chercher des informations à l'extérieur lorsque la tâche l'exige.
Pourquoi c'est important
Un LLM seul a trois limites fortes : un knowledge cutoff figé, aucun accès aux données privées et aucune capacité d'action. Le tool use lève ces trois contraintes. Avec des outils, le même modèle peut répondre à « quel est le MRR actuel ? », envoyer un e-mail, réserver un vol, interroger une base de données ou exécuter du code. Le tool use est le fondement de chaque agent IA moderne, de chaque « copilote » et de presque toutes les applications LLM en production au-delà de la simple couche chatbot.
Comment ça fonctionne
1. Définitions des outils : l'application fournit au modèle une liste des outils disponibles, chacun avec un nom, une description et un schéma de paramètres.
2. Le modèle décide d'appeler : lorsque la requête de l'utilisateur nécessite un outil, le modèle produit un appel d'outil structuré (du JSON conforme au schéma) au lieu de texte ordinaire.
3. Le runtime exécute l'outil : votre code reçoit l'appel d'outil, exécute la fonction réelle et renvoie le résultat.
4. Le résultat revient au modèle : le modèle voit le résultat dans son contexte et poursuit sa réponse, soit en répondant à l'utilisateur, soit en appelant un autre outil.
5. Boucle jusqu'à la fin : les tâches multi-outils enchaînent les appels d'outils jusqu'à ce que le modèle produise une réponse textuelle finale.
Tool Use vs Function Calling
Les deux termes sont en grande partie interchangeables, avec une nuance subtile :
- Function calling : la formulation d'origine, le modèle produit des arguments JSON pour une seule fonction nommée.
- Tool use : la formulation plus large, les outils peuvent être des fonctions, des API, des actions sur ordinateur ou des serveurs MCP, et le modèle en orchestre plusieurs en séquence.
Anthropic emploie « tool use », OpenAI parlait historiquement de « function calling » et dit désormais « tools ». Les deux décrivent la même capacité sous-jacente.
Types d'outils
Récupération : récupérer des documents, chercher sur le web, interroger une base de données, consulter un enregistrement.
Calcul : exécuter du Python, faire des mathématiques, convertir des unités, analyser un fichier.
Action : envoyer un e-mail, créer un événement d'agenda, publier sur Slack, mettre à jour un CRM.
Exécution de code : un interpréteur en bac à sable dans lequel le modèle peut écrire et exécuter du code.
Computer use : cliquer, taper et lire l'écran, l'outil le plus général.
Modèle à modèle : déléguer à un autre modèle spécialisé (par exemple, la génération d'images).
Concevoir de bons schémas d'outils
Descriptions claires et courtes : la description est ce qui permet au modèle de décider quand appeler. Rendez-la sans ambiguïté.
Types de paramètres étroits : préférez les énumérations et les chaînes contraintes au texte libre, cela réduit les arguments hallucinés.
Idempotents si possible : si le modèle peut réessayer, un second appel ne doit pas envoyer l'e-mail en double.
Renvoyez des résultats structurés : redonnez au modèle du JSON, pas du texte libre, il raisonne mieux sur une structure.
Les réponses d'erreur indiquent au modèle quoi faire : « Erreur : ville introuvable, essayez une autre orthographe » est plus utile que « 500 ».
Erreurs courantes
Trop d'outils : au-delà d'environ 20 à 30 outils, les modèles commencent à choisir le mauvais. Regroupez les outils apparentés ou passez par une sélection plus restreinte.
Descriptions vagues : « utilitaire » n'indique pas au modèle quand l'appeler. Soyez précis.
Absence de gestion des erreurs : les échecs d'outils brisent la boucle. Renvoyez toujours une erreur structurée à laquelle le modèle peut réagir.
Ignorer la latence : chaque appel d'outil ajoute un aller-retour. Parallélisez les appels indépendants, regroupez-les quand c'est possible.
Négliger les garde-fous : les outils qui agissent (envoyer un e-mail, transférer de l'argent) requièrent une validation humaine ou un cadrage strict.
Sources: