Schémas d’outils et de fonctions

Les appels de fonctions permettent à un modèle de demander à votre code d'exécuter une action. Chaque outil est déclaré avec un nom, une description (indiquant quand l'utiliser) et un schéma JSON pour ses paramètres.

Le modèle n'exécute jamais de code ; il émet une demande d'appel structurée que votre environnement d'exécution distribue. Le schéma rend les arguments analysables.

Une définition d'outil est une déclaration de capacité encapsulée dans un schéma.

Lorsque de nombreux outils sont disponibles, le modèle choisit principalement en fonction de la description. Rédigez les descriptions sous forme de règles de décision :

• Indiquez quand l'utiliser et quand ne pas l'utiliser.
• Faites la distinction avec les outils apparentés.
• Mentionnez les préconditions requises.

De mauvaises descriptions entraînent plus souvent la sélection du mauvais outil que de mauvais schémas n'entraînent des erreurs d'arguments.

Les appels de fonctions se déroulent sur plusieurs tours. Le modèle émet un appel, vous l'exécutez, vous appelez append pour ajouter le résultat, puis le modèle poursuit.

Les modèles modernes peuvent demander plusieurs appels d'outils en un seul tour lorsque les actions sont indépendantes. Votre environnement d'exécution doit parcourir tous les tool_calls, les exécuter (idéalement simultanément) et renvoyer un message d'outil par tool_call_id.

Ne supposez jamais qu'il n'y a qu'un seul appel ; utilisez toujours une boucle.

Contrôlez la sélection avec tool_choice :

• auto — le modèle décide.
• required — il doit appeler un outil.
• {name: ...} — forcez l'utilisation d'un outil précis.
• none — désactivez les outils pour ce tour.

Forcer un outil précis transforme les appels de fonctions en simple extraction structurée.

Même avec des schémas stricts, considérez les arguments des outils comme des entrées non fiables. Revalidez-les par rapport au schéma et appliquez les règles métier avant d'interagir avec des systèmes réels (bases de données, systèmes de paiement, suppressions de fichiers).

Lorsqu'un outil échoue, renvoyez une erreur structurée comme résultat de l'outil plutôt que de lever une exception. Le modèle peut alors présenter ses excuses, réessayer avec des arguments corrigés ou choisir un autre outil.

Rendez les erreurs exploitables : indiquez une raison et, lorsque cela ne présente aucun risque, une piste de récupération.

Des dizaines d'outils dégradent la précision de la sélection et augmentent le coût en jetons (chaque schéma est présent dans le contexte à chaque tour). Mesures possibles :

• Regroupez les actions apparentées derrière un seul outil avec une énumération action.
• Exposez dynamiquement uniquement les outils pertinents pour l'état actuel.
• Utilisez des espaces de noms pour réduire la confusion entre les outils similaires.

Pour les actions destructrices, encodez la sécurité directement dans le schéma : exigez un champ de confirmation explicite, limitez les plages de valeurs et évitez les identifiants en texte libre au profit d’énumérations ou de motifs validés.

Traitez la sélection d’outils comme un comportement mesurable. Constituez un ensemble d’évaluation associant chaque invite à l’outil et aux arguments attendus, puis vérifiez que le modèle effectue le bon choix. Suivez les régressions lorsque vous reformulez les descriptions ou ajoutez de nouveaux outils.

Les schémas d’outils et de fonctions en pratique :

• Les descriptions orientent la sélection ; les schémas déterminent des arguments analysables.
• Parcourez tous les appels d’outils ; prenez en charge l’exécution en parallèle.
• Contrôlez le comportement avec le choix d’outil ; forcez l’utilisation d’un outil pour l’extraction pure.
• Validez de nouveau les arguments ; renvoyez des erreurs structurées.
• Gardez une surface d’outils réduite et renforcez la sécurité des actions destructrices.

Ensuite : les boucles de correction et de validation lorsque la sortie reste incorrecte.