Qu’est-ce que l’utilisation d’outils par les LLM ?

Vous pouvez aussi voir ce mécanisme appelé appel d’outils ou appel de fonctions. Ces appellations désignent souvent le même mécanisme. Toutefois, certaines plateformes utilisent le terme outils comme une catégorie plus large qui comprend la recherche hébergée, l’exécution de code, la récupération de fichiers ou le contrôle d’un ordinateur, en plus des fonctions définies par les développeurs.

Le modèle mental utile

Imaginez le modèle comme un demandeur, et non comme la machine qui effectue le travail.

Le modèle peut produire une demande structurée telle que « appeler get_order_status avec l’identifiant de commande 4821 ». Cette sortie reste une réponse du modèle. Elle n’interroge pas une base de données par elle-même.

Une application environnante reçoit la demande et contrôle la suite des opérations. Elle peut rejeter l’appel, demander à l’utilisateur de le confirmer, vérifier les autorisations, exécuter du code ou renvoyer une erreur. Si elle exécute l’outil, elle transmet le résultat au modèle sous forme de nouveau contexte. Le modèle peut alors expliquer le résultat ou demander un autre outil.

Cette séparation est le fait central de l’utilisation d’outils :

User request
    ↓
Model selects a tool and proposes inputs
    ↓
Application validates, authorizes, and executes
    ↓
Tool result returns to the model
    ↓
Model answers or requests another tool

Certains fournisseurs proposent également des outils hébergés qu’ils exécutent sur leurs propres serveurs. L’API peut masquer une partie de la boucle, mais les étapes logiques restent les mêmes : le modèle demande une opération, un système d’exécution l’effectue et le résultat entre dans la conversation.

Comment fonctionne l’utilisation d’outils

1. L’application décrit chaque outil

Une définition d’outil comprend généralement :

• un nom, comme get_order_status
• une description en langage courant indiquant quand l’utiliser
• les entrées qu’il accepte
• les règles concernant la forme et le type de chaque entrée

Ces règles d’entrée sont souvent exprimées sous la forme d’un schéma JSON. Le schéma peut indiquer que order_id est une chaîne obligatoire. La description explique au modèle ce que fait l’outil ; le schéma lui indique comment formater un appel.

2. Le modèle reçoit la demande et les définitions des outils

Le modèle examine le message de l’utilisateur avec les descriptions des outils disponibles. Il peut répondre normalement, demander un outil ou en demander plusieurs lorsque l’API et l’application l’autorisent.

La sélection d’un outil est une prédiction, pas un plan garanti. Le modèle peut choisir le mauvais outil, omettre un appel nécessaire ou proposer un argument bien formé mais inapproprié.

3. Le modèle renvoie un appel d’outil structuré

À la place — ou en complément — d’un texte ordinaire, la réponse contient un appel lisible par une machine. Une version simplifiée pourrait ressembler à ceci :

{
  "name": "get_order_status",
  "arguments": {
    "order_id": "4821"
  }
}

Les API des fournisseurs encodent cela dans différents types de messages et ajoutent un identifiant afin que le résultat final puisse être associé au bon appel. L’enveloppe exacte varie, mais l’idée d’un nom accompagné d’entrées est commune aux principales API.

4. L’application décide de l’exécuter ou non

C’est à ce moment qu’une action proposée devient réelle — ou ne le devient pas.

L’application analyse les arguments et les vérifie au-delà du simple schéma. Elle peut vérifier l’utilisateur connecté, appliquer des règles d’accès, limiter les valeurs, exiger une approbation pour un effet de bord ou refuser un outil indisponible. Ce n’est qu’ensuite qu’un exécuteur d’outils appelle la base de données, l’API, la calculatrice, le système de fichiers ou un autre système.

Un schéma strict peut améliorer la fiabilité structurelle, mais ce n’est pas un système d’autorisation. "order_id": "4821" peut être un JSON valide tout en faisant référence à la commande de quelqu’un d’autre.

5. Le résultat de l’outil revient au modèle

L’application envoie la sortie dans un message de résultat associé à l’appel d’origine. La sortie peut contenir des données, une erreur ou indiquer que l’autorisation a été refusée.

Le modèle utilise ce résultat comme contexte supplémentaire. Il peut produire une réponse finale, corriger une hypothèse précédente ou effectuer un autre appel d’outil. Un agent d’IA réalisant plusieurs étapes peut répéter cette boucle jusqu’à atteindre une condition d’arrêt.

Exemple détaillé : vérifier une commande

Supposons qu’un magasin expose un outil en lecture seule :

Name: get_order_status
Purpose: Return shipping information for an order the current user owns
Input: order_id (required string)

L’utilisateur demande :

Où se trouve la commande 4821 ?

Le modèle demande :

{
  "name": "get_order_status",
  "arguments": {
    "order_id": "4821"
  }
}

Avant d’effectuer une quelconque requête, l’application vérifie la session actuelle. Si l’utilisateur est bien propriétaire de la commande 4821, elle exécute la recherche et renvoie :

{
  "status": "shipped",
  "estimated_delivery": "Friday"
}

Le modèle peut alors répondre : « La commande 4821 a été expédiée et devrait arriver vendredi. »

Si la vérification de propriété échoue, l’application ne doit ni effectuer la recherche ni révéler le statut. Elle peut renvoyer une erreur d’autorisation, que le modèle pourra expliquer sans exposer de données privées.

Rien dans l’appel du modèle n’a prouvé la propriété de la commande. Le schéma de l’outil décrivait une demande valide ; l’application a appliqué la véritable règle.

Pourquoi l’utilisation d’outils est importante

L’utilisation d’outils donne à un modèle de langage un accès contrôlé à des capacités que la génération de texte seule ne fournit pas.

• Données récentes ou privées : un outil peut récupérer des informations actuelles ou des données qui ne figuraient pas dans les données d’entraînement du modèle.
• Opérations exactes : une calculatrice, une requête de base de données ou un programme peut effectuer un travail qui ne devrait pas dépendre d’une estimation plausible en apparence.
• Actions réelles : les outils peuvent créer des enregistrements, envoyer des messages, planifier des événements ou utiliser d’autres logiciels.
• Systèmes existants : un outil peut transformer une demande en langage naturel en appel vers une API métier existante.
• Travail en plusieurs étapes : le résultat d’un appel peut guider l’appel suivant.

L’utilisation d’outils ne supprime pas les limites du modèle. Elle transfère certaines tâches à des systèmes mieux adaptés et crée une interface entre des décisions probabilistes et des logiciels déterministes.

La fiabilité et la sécurité dépendent du système environnant

Le modèle n’est pas une source fiable de commandes simplement parce que sa sortie respecte un schéma. L’utilisation d’outils en production nécessite des contrôles autour du modèle.

Validez le sens, pas seulement la forme. Vérifiez les identifiants, les plages de valeurs, l’état requis et les règles métier. La validation structurelle ne peut pas déterminer si une transaction proposée correspond à la demande de l’utilisateur.

Autorisez au moment de l’exécution. Utilisez l’identité et les autorisations détenues par l’application. Ne laissez pas le modèle s’accorder lui-même un accès en plaçant un identifiant utilisateur ou un rôle dans un argument d’outil.

Limitez les pouvoirs de chaque outil. Un outil get_order_status dont la portée est étroitement définie est plus facile à contrôler qu’un outil de base de données généraliste. Les outils en lecture seule et les outils d’écriture doivent être distincts lorsque leurs risques diffèrent.

Traitez la sortie de l’outil comme une donnée non fiable. Le contenu externe peut être erroné ou contenir du texte conçu pour rediriger le modèle. Un document renvoyé est une information à examiner, et non une nouvelle autorité pouvant remplacer la demande de l’utilisateur ou les règles du système.

Gérez délibérément les effets de bord. Envoyer un message ou émettre un remboursement n’est pas la même chose que consulter un statut. Les actions sensibles peuvent nécessiter une confirmation, une protection d’idempotence contre les exécutions en double et une trace d’audit.

Renvoyez clairement les échecs. Les délais d’attente, les services indisponibles, les autorisations refusées et les arguments invalides doivent devenir des résultats d’outil explicites. Sinon, le modèle risque de combler le vide en inventant une réussite.

Idées reçues courantes

« Le LLM a appelé mon API »

En général, le LLM a généré une demande et une application a appelé l’API. Dire que le modèle a « appelé » l’outil est un raccourci commode, mais cela masque la frontière entre l’exécution et la sécurité.

« Les appels de fonctions et les appels d’outils sont toujours différents »

Pour les fonctions définies par les développeurs, les fournisseurs et les frameworks utilisent souvent ces termes de manière interchangeable. La différence apparaît lorsqu’une plateforme utilise le terme outil comme catégorie générale regroupant les fonctions et des capacités intégrées telles que la recherche ou l’exécution de code. Consultez la taxonomie de la plateforme au lieu de supposer une distinction universelle.

« Un schéma valide signifie que l’appel est correct »

Un schéma peut exiger une chaîne, un nombre, une liste ou un objet, et rejeter une sortie mal formée. Il ne peut pas garantir que le modèle a choisi le bon outil, déduit la bonne valeur ou respecté une règle métier.

« Ajouter un outil crée un agent »

L’utilisation d’outils est une capacité. Un agent est un système plus vaste qui peut décider, agir, observer les résultats, conserver l’état pertinent, répéter la boucle et s’arrêter. Un appel structuré ponctuel peut utiliser le même mécanisme sans devenir un workflow autonome.

« Le résultat de l’outil doit être vrai »

Le modèle peut résumer fidèlement un résultat erroné. La fiabilité de l’outil, l’actualité des données, le contrôle d’accès et la résistance aux contenus malveillants sont des propriétés de l’ensemble du système, et non du seul modèle de langage.

La place de l’utilisation d’outils dans un système d’IA

L’utilisation d’outils se situe à la frontière entre un modèle de langage et les systèmes qui l’entourent.

Le modèle interprète le langage et propose une prochaine étape structurée. L’application fournit les définitions des outils, conserve l’état de la conversation, valide les appels, gère les autorisations, exécute les opérations et renvoie les observations. Les outils fournissent des capacités ciblées. Un agent peut utiliser cette organisation de manière répétée pour accomplir une tâche plus vaste.

C’est pourquoi la qualité de l’utilisation d’outils ne dépend pas uniquement du modèle. La clarté des descriptions, la distinction entre les schémas, les contrôles d’exécution, l’utilité des messages d’erreur et la pertinence des règles d’arrêt influencent tous le fonctionnement du système.

Pour aller plus loin

Lisez Qu’est-ce qu’un agent d’IA ? pour voir comment les appels d’outils s’intègrent à une boucle répétée de planification, d’action et d’observation avec un état et des règles d’arrêt. Lisez Qu’est-ce qu’un harnais d’IA ? pour découvrir les logiciels qui valident et exécutent ces appels, puis consultez Modèle d’IA, chatbot, harnais et agent : quelles différences ? pour situer l’utilisation d’outils dans l’ensemble du système.