D'une réponse JSON à un flux de travail fiable

Commencer par le système récepteur

Avant de demander du JSON à un modèle, décidez de ce dont le système suivant a besoin. Choisissez les noms de champs, les types, les champs obligatoires et une représentation pour les informations manquantes. Un objet prévisible n'est utile que si sa signification correspond à la tâche. Conservez un petit schéma versionné avec l'application consommatrice.

Demander une forme explicite

Sélectionnez JSON dans le playground et décrivez les champs attendus. Par exemple, demandez une chaîne summary, un tableau next_steps de chaînes et un tableau missing_information. Précisez que le résultat doit utiliser la source fournie plutôt que des suppositions externes. L'objet suivant est illustratif, ce n'est pas un résultat généré par un modèle.

Code

{
  "summary": "The launch date has not been supplied.",
  "next_steps": ["Confirm the owner and launch date."],
  "missing_information": ["owner", "launch_date"]
}

Valider la syntaxe, la structure et les preuves

D'abord, analysez le JSON. Ensuite, rejetez les types inattendus, les champs obligatoires omis ou les chaînes dépassant vos limites métier. Enfin, vérifiez les champs factuels par rapport à la source. Un schéma valide la forme d'un objet ; il ne peut pas établir qu'une date ou un propriétaire est vrai. Conservez les identifiants source si l'étape suivante nécessite la traçabilité.

Échec	Récupération
JSON invalide	Réessayez une fois avec l'erreur du parseur et la tâche originale
Champ manquant	Demandez la forme requise ou renvoyez une erreur de validation
Fait non pris en charge	Marquez comme inconnu ; demandez une preuve source
Sortie tronquée	Augmentez le budget ou réduisez la portée de l'extraction

Traiter une sortie incomplète comme incomplète

Une réponse interrompue peut se terminer au milieu d'une chaîne ou d'un objet. Ne l'exécutez pas et ne la réparez pas silencieusement en un résultat confiant. Dans une intégration fournisseur, inspectez le statut de complétion et conservez l'erreur. Le raisonnement peut consommer des jetons de sortie, donc prévoyez-en le budget lors de l'utilisation d'un effort élevé. Le guide API explique la gestion des réponses.

Placer une limite avant les effets de bord

Un objet analysé ne doit pas automatiquement envoyer un e-mail, modifier une commande ou exécuter une commande. Validez les autorisations et l'action métier indépendamment. Utilisez une étape d'approbation là où votre application l'exige. Testez les cas négatifs — mauvais types, identifiants inconnus, champs supplémentaires et flux interrompus — avant d'activer l'automatisation. Lisez la section tool-calling pour la responsabilité de l'application.