L’appel de fonction dans l’API OpenAI

L’appel de fonction vous permet de connecter les modèles OpenAI à des outils et systèmes externes. C’est utile pour de nombreux besoins, comme doter les assistants IA de capacités ou créer des intégrations poussées entre vos applications et les LLM.

En savoir plus dans notre guide développeur sur l’appel de fonction.

En juin 2024, nous avons lancé les sorties structurées. Lorsque vous les activez en définissant strict: true dans votre définition de fonction, les sorties structurées garantissent que les arguments générés par le modèle pour un appel de fonction correspondent exactement au schéma JSON que vous avez fourni dans la définition de fonction.

En octobre 2024, nous avons lancé la fonctionnalité « Générer n’importe quoi », qui permet aux développeurs de décrire une fonction, de la coller directement ou de coller votre code afin de générer un schéma de fonction valide. En savoir plus sur « Générer n’importe quoi » dans cet article du centre d’aide.

Comment utiliser l’appel de fonction ?

L’appel de fonction est utile pour un grand nombre de cas d’utilisation, par exemple :

• Permettre aux assistants de récupérer des données :

• Permettre aux assistants d’effectuer des actions :

• Permettre aux assistants d’effectuer des calculs :

• Créer des workflows riches :

• un pipeline d’extraction de données qui récupère du texte brut, puis le convertit en données structurées et l’enregistre dans une base de données.

L’appel de fonction est pris en charge dans l’API Responses, qui unifie des fonctionnalités auparavant réparties entre l’API Chat Completions et l’API Assistants.

Comment utiliser le mode JSON ?

Lorsque le mode JSON est activé, la sortie du modèle est garantie comme étant du JSON valide, sauf dans certains cas limites que vous devez détecter et gérer correctement.

Pour demander le mode JSON avec l’API Chat Completions, définissez response_format sur { "type": "json_object" } pour les modèles pris en charge. Avec l’API Responses, définissez text.format sur { "type": "json_object" }, par exemple text: { "format": { "type": "json_object" } }, le cas échéant. Dans les deux API, le mode JSON ne fonctionne que lorsque les prérequis liés au modèle, aux messages et aux outils sont satisfaits (par exemple, le modèle prend en charge json_object, la conversation comprend des instructions pour produire du JSON et toutes les contraintes d’outils sont compatibles). Au moins un message de requête ou message d’entrée dans le contexte d’entrée effectif doit contenir json sous une forme insensible à la casse, comme JSON, json ou Json ; sinon, l’API renvoie une erreur. Dans Responses, le champ d’instructions de premier niveau ne suffit pas à lui seul à satisfaire cette validation. Lorsque l’appel de fonction est utilisé avec des modèles ou chemins compatibles, les contraintes JSON sont appliquées automatiquement aux arguments d’appel de fonction ; les modèles ou combinaisons outil/format de réponse incompatibles peuvent être rejetés ou ne pas utiliser l’échantillonnage contraint par JSON.

Remarques importantes :

• Lorsque vous utilisez le mode JSON, vous devez toujours demander au modèle de produire du JSON via un message dans la conversation, par exemple via votre message système. Si vous n’incluez pas d’instruction explicite pour générer du JSON, le modèle peut générer un flux interminable d’espaces blancs et la requête peut continuer à s’exécuter jusqu’à atteindre la limite de tokens. Pour vous aider à ne pas oublier, le mode JSON rejette les requêtes sauf si les messages d’entrée ou instructions pertinents contiennent le mot json sous une forme quelconque, sans tenir compte de la casse.

• Le mode JSON ne garantit pas que la sortie corresponde à un schéma spécifique, mais seulement qu’elle est valide et s’analyse sans erreur. Vous devez utiliser les sorties structurées pour garantir qu’elle correspond à votre schéma ; si ce n’est pas possible, utilisez une bibliothèque de validation et éventuellement des tentatives répétées afin de vous assurer que la sortie correspond au schéma souhaité.

• Votre application doit détecter et gérer les cas limites qui peuvent faire que la sortie du modèle ne soit pas un objet JSON complet (voir ci-dessous).