Sorties structurées avec l’IA : définir, imposer et valider le format sans perdre en fiabilité

1. Concevoir le schéma à partir des besoins du système en aval

Une sortie structurée est une réponse du modèle qui respecte une forme de données prévue, par exemple un objet JSON contenant des champs définis. Le but n’est pas seulement que la réponse « ressemble à du JSON » : le système qui la reçoit doit pouvoir l’interpréter de manière cohérente. Pour y parvenir, partez du consommateur en aval et remontez le processus : déterminez les champs dont il a besoin, l’usage qu’il en fera et le comportement attendu lorsque l’entrée ne contient pas l’information demandée.

Gardez le schéma aussi restreint que le permet le cas d’usage. Pour chaque champ, précisez le type, le caractère obligatoire ou facultatif, les valeurs autorisées, les unités et la provenance attendue. Décidez également comment représenter les données manquantes. Une valeur nulle, une chaîne vide et un champ omis peuvent avoir des significations différentes : ne les utilisez pas de manière interchangeable sans règle explicite. Si une date doit alimenter une base de données, privilégiez, par exemple, un format normalisé et un fuseau horaire défini plutôt que des expressions comme « vendredi ».

Séparez la structure des consignes sémantiques. Le schéma peut imposer que `date` soit une chaîne, mais cela n’empêche pas le modèle d’inventer une date. Les descriptions des champs et le prompt peuvent orienter l’extraction ; c’est toutefois à l’application de définir les éléments de preuve acceptables et le résultat à utiliser lorsqu’aucun élément n’est disponible. Une solution plus sûre consiste à prévoir un état explicite tel que `introuvable` ou un champ contenant la preuve, plutôt que d’imposer une réponse affirmative.

La documentation d’Azure OpenAI décrit l’utilisation d’une définition de schéma JSON dans un appel d’inférence et présente des exemples avec Pydantic et Zod. La documentation de Gemini présente également des réponses JSON conformes à un schéma et des exemples faisant appel à des modèles de données. Ces fonctionnalités documentées sont propres aux API et aux configurations décrites ; elles ne prouvent pas que tous les schémas, modèles ou fournisseurs acceptent exactement les mêmes contraintes.

2. Choisir le mécanisme de sortie en fonction de la tâche et du fournisseur

Trois approches sont courantes, mais elles ne sont pas équivalentes. Le prompting pur demande au modèle, au moyen d’instructions en langage naturel, de renvoyer un format précis. Cela peut suffire pour un prototype ou lorsque la sortie est destinée à être lue par une personne, mais le format peut se dégrader : explications ajoutées autour du JSON, clés inattendues ou valeurs de types incorrects. Si le résultat alimente du code, considérez cette approche comme moins contrôlable et validez toujours la réponse.

Le mode JSON demande une réponse au format JSON. La documentation d’Azure distingue ce mode des sorties structurées avec schéma : le premier garantit un JSON valide, mais ne garantit pas le respect strict du schéma fourni. Le fait qu’une réponse puisse être analysée comme du JSON ne prouve donc pas qu’elle contienne les clés, les types ou les contraintes dont l’application a besoin.

Les sorties structurées avec schéma permettent de fournir une définition qui guide la forme de la réponse. La documentation d’Azure présente ce mécanisme dans les paramètres de format de réponse, ainsi que des exemples d’intégration avec Pydantic et Zod. Gemini documente également la configuration d’une réponse JSON fondée sur un schéma, avec des exemples d’extraction et de classification. La disponibilité exacte dépend de l’API, du modèle et de la configuration choisis : vérifiez la documentation actuelle du point de terminaison que vous utiliserez réellement, au lieu de supposer que deux produits aux noms proches fonctionnent de façon identique.

Les appels de fonctions ou d’outils conviennent lorsque le modèle doit proposer les arguments d’une opération disponible dans l’application, comme la consultation d’une commande. Ils ne signifient ni que la fonction a été exécutée ni que l’action est sûre : le serveur doit valider les arguments et appliquer ses propres contrôles avant d’agir. Pour l’usage des sorties structurées dans les appels de fonctions décrit par Azure, la documentation indique que les appels parallèles ne sont pas pris en charge et recommande de les désactiver dans cette configuration. Ne généralisez pas cette limite à d’autres API sans l’avoir vérifié.

En règle générale, choisissez une sortie avec schéma lorsque l’objectif principal est de produire un objet conforme à une définition ; un appel de fonction lorsque le modèle doit sélectionner une opération et en proposer les arguments ; et le prompting pur pour les contextes moins risqués ou les tâches où une validation locale stricte peut compenser une coercition moins forte. Dans tous les cas, la réponse doit passer par les contrôles de l’application avant d’atteindre le système en aval.

3. Valider la structure avant de traiter la réponse

Le premier contrôle consiste à analyser la réponse avec un parseur adapté au format attendu. Pour le JSON, le parseur doit rejeter le texte invalide, les valeurs tronquées et le contenu qui ne peut pas être converti en objet. Si le fournisseur renvoie une réponse déjà analysée par un SDK, vérifiez tout de même son état d’achèvement, les refus éventuels et les champs signalant une réponse incomplète. Ne partez pas du principe qu’un résultat exploitable est toujours disponible.

Le deuxième contrôle consiste à valider la réponse par rapport à un schéma local. JSON Schema permet d’exprimer des types, des champs obligatoires, des énumérations, des limites de longueur et des règles relatives aux propriétés supplémentaires, entre autres contraintes. Les bibliothèques de validation peuvent transformer ces règles en erreurs exploitables avant que la sortie n’atteigne une base de données ou une API. L’implémentation dépend du langage et de la version du schéma : vérifiez que la bibliothèque choisie prend en charge les mots-clés et le dialecte employés par votre contrat, puis testez cette combinaison dans l’intégration continue.

Ne reprenez pas sans examen le schéma accepté par le fournisseur comme contrat définitif de l’application. Le fournisseur peut n’accepter qu’un sous-ensemble des règles ou convertir le modèle de données d’une bibliothèque en définition compatible avec son API. Conservez une source de vérité pour votre contrat et, si le fournisseur impose une représentation simplifiée, générez ou adaptez le schéma de l’appel sans supprimer les règles essentielles de validation locale.

Les contrôles doivent être stricts aux frontières du système. Rejetez les propriétés inattendues si elles risquent de modifier le comportement ; ne convertissez les types que lorsque la conversion est sans équivoque et documentée ; évitez les corrections automatiques de valeurs incertaines. Si un champ doit être un entier, convertir `12,5` en `12` n’est pas une réparation anodine : le sens peut changer. Enregistrez l’erreur, l’identifiant de la requête et la version du schéma afin de diagnostiquer les échecs sans accepter silencieusement des données défectueuses.

4. Vérifier le contenu et représenter l’incertitude

Une réponse structurellement correcte peut être fausse sur le plan sémantique. Pour mesurer cet écart, évaluez chaque champ par rapport à l’entrée d’origine et aux sources de référence disponibles, et non en fonction de la fluidité de l’explication du modèle. Pour une extraction, conservez suffisamment de preuves textuelles pour localiser la donnée dans le document. Pour une classification, gardez la règle ou le signal qui a permis d’attribuer la catégorie. Pour un enrichissement, identifiez les valeurs provenant de l’entrée et celles qui dépendent d’une source externe autorisée.

Concevez une représentation explicite de l’incertitude. Selon le cas, il peut s’agir d’une valeur nulle accompagnée d’un état, d’une liste de candidats ou d’un indicateur de révision. Évitez de demander un pourcentage de confiance sans en définir le sens ni la méthode de calibration : un chiffre produit par le modèle n’est pas, à lui seul, une probabilité vérifiée. Si vous utilisez un score, mesurez-le sur un jeu de données étiquetées et fixez les seuils en fonction du coût des erreurs et des révisions, plutôt que par intuition.

La révision humaine doit être une voie normale du pipeline, et non une exception improvisée. Orientez vers une révision les cas ambigus, ceux qui manquent de preuves, ceux qui enfreignent les règles métier et ceux qui impliquent une décision à fort impact. Le réviseur doit pouvoir consulter l’entrée, la sortie proposée, les preuves et le motif de l’escalade. Si une correction humaine est conservée comme donnée d’entraînement ou exemple de régression, consignez également sa provenance et la politique applicable.

Les éléments disponibles ici étayent l’existence de sorties fondées sur un schéma pour Azure OpenAI et Gemini, mais ne quantifient pas les taux d’erreurs de format par rapport aux erreurs sémantiques. Ils ne permettent pas non plus d’établir un seuil de confiance universel. Mesurez donc ces deux types d’échec pour votre tâche : un faible taux de JSON invalide ne démontre pas que l’extraction est correcte, et un bon résultat sur un petit échantillon ne garantit pas le comportement en production.

5. Tester le système et surveiller son comportement en production

Constituez un jeu de régression avec des exemples représentatifs et des cas limites avant de déployer des modifications du prompt, du schéma, du modèle ou du SDK. Incluez des entrées propres, incomplètes ou contradictoires, des caractères inattendus, des documents longs et des cas où la bonne réponse est « introuvable ». Pour chaque cas, conservez une attente vérifiable : résultat attendu, champs qui doivent rester absents et conditions imposant une escalade.

Mesurez séparément la validité syntaxique, la conformité au schéma, l’exactitude de chaque champ et le taux d’escalade. Une métrique agrégée unique peut masquer le fait que le système produit un JSON parfait tout en classant mal, ou qu’il réussit la plupart des champs mais échoue précisément sur ceux qui ont le plus d’impact. Segmentez les résultats par type d’entrée, version du modèle, version du prompt et version du schéma.

En production, consignez des métriques qui permettent de détecter les dégradations : réponses impossibles à analyser, erreurs de validation, champs nuls, valeurs hors limites, désaccords avec les sources de référence et proportion de révisions humaines. Définissez des alertes et une procédure de récupération, par exemple la mise en attente des enregistrements douteux ou le retour à une version antérieure. Ne consignez pas inutilement de données sensibles : ne conservez que ce qui est requis pour le débogage, l’audit et le respect de la politique applicable.

Avant de changer de fournisseur ou de mécanisme, répétez les tests sur le même échantillon et selon les mêmes critères d’acceptation. Les fonctionnalités documentées ne sont pas interchangeables dans tous leurs détails, et une migration peut modifier les contraintes prises en charge ou la représentation des réponses. Traitez la configuration de production comme une partie du contrat : fournisseur, point de terminaison, modèle, schéma, SDK, prompt et politique de nouvelle tentative doivent être versionnés et auditables.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.