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 nombreuses choses, comme doter les assistants AI de capacités ou créer des intégrations approfondies entre vos applications et les LLM.

Apprenez-en plus dans notre guide de développement sur l’appel de fonction.

En juin 2024, nous avons lancé les sorties structurées. Lorsque vous l’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 leur code afin de générer un schéma de fonction valide. Apprenez-en plus sur « Générer n’importe quoi » dans cet article du centre d’aide

Comment puis-je utiliser l’appel de fonction?

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

• 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 flux de travail 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 puis-je utiliser le mode JSON?

Lorsque le mode JSON est activé, la sortie du modèle est assurée d’être du JSON valide, sauf dans certains cas limites que vous devez détecter et gérer adéquatement.

Pour demander le mode JSON avec l’API Chat Completions, définissez response_format sur { "type": "json_object" } avec 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 l’une ou l’autre 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’outil 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 retourne une erreur. Dans Responses, le champ d’instructions de premier niveau à lui seul ne satisfait pas à cette validation. Lorsque l’appel de fonction est utilisé avec des modèles ou des chemins compatibles, les contraintes JSON sont appliquées automatiquement aux arguments des appels de fonction; les modèles incompatibles ou les combinaisons outil/format de réponse incompatibles peuvent être refusés ou ne pas utiliser l’échantillonnage contraint par JSON.

Remarques importantes :

• Lorsque vous utilisez le mode JSON, vous devez toujours indiquer au modèle de produire du JSON au moyen d’un message dans la conversation, par exemple 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 sans fin d’espaces blancs et la requête peut continuer à s’exécuter jusqu’à ce qu’elle atteigne la limite de tokens. Pour éviter que vous ne l’oubliiez, le mode JSON refuse les requêtes à moins que les messages d’entrée ou instructions pertinents ne contiennent le mot json sous une forme quelconque, sans tenir compte de la casse.

• Le mode JSON ne garantit pas que la sortie correspond à un schéma précis, seulement qu’elle est valide et s’analyse sans erreur. Vous devriez utiliser les sorties structurées pour vous assurer qu’elle correspond à votre schéma, ou, si ce n’est pas possible, utiliser une bibliothèque de validation et possiblement des tentatives répétées pour vous assurer que la sortie correspond au schéma souhaité.

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