Prompting de sortie structurée : JSON, schémas et contraintes

Quand du code lit la réponse d’un modèle, « presque la bonne forme » est un bogue. Le prompting de sortie structurée est l’ensemble des pratiques qui font renvoyer à un modèle des données que votre programme peut analyser à chaque fois : un format défini, des contraintes explicites et une validation.

Trois niveaux de fiabilité

Utilisez le niveau le plus fort proposé par votre fournisseur. OpenAI, Anthropic et Google offrent tous un moyen de contraindre une réponse à un schéma ou au schéma d’entrée d’un outil. Le prompt compte à tous les niveaux, car un schéma contrôle la forme de la sortie et le prompt son contenu.

Écrire des contraintes de sortie dans le prompt

Indiquez le format, les champs, les types et les valeurs autorisées. Dites ensuite ce qui ne doit pas apparaître.

Extract the order details from the email in the tags.

Return a JSON object with exactly these fields:
- "order_id": string, as written in the email
- "items": array of {"name": string, "quantity": integer}
- "total": number, without currency symbol
- "currency": one of "USD", "EUR", "GBP"

If a field is not present in the email, use null.
Return only the JSON object, with no explanation and no code fence.

<email>
{{email}}
</email>

Quatre détails de ce prompt évitent la plupart des échecs :

1. « Exactement ces champs » empêche le modèle d’ajouter des extras bien intentionnés.
2. Les valeurs autorisées pour currency évitent « US dollars » et « $ ».
3. Une règle sur null donne au modèle une façon correcte de dire « introuvable », pour qu’il n’invente pas de valeur.
4. « Renvoie uniquement le JSON » supprime la phrase de commentaire qui casse JSON.parse.

Concevez le schéma pour le modèle

Un schéma fait partie du prompt. Le modèle lit les noms et les descriptions des champs comme des instructions.

• Nommez les champs d’après ce qu’ils contiennent. shipping_address vaut mieux que addr2.
• Ajoutez des descriptions aux champs dont le sens n’est pas évident, y compris l’unité et le format : « date ISO 8601, UTC ».
• Utilisez des énumérations partout où un champ a un ensemble fixe de valeurs.
• Restez à plat. Une imbrication profonde augmente les erreurs. Découpez une extraction très complexe en prompts enchaînés.
• Placez le raisonnement avant la réponse. Si vous voulez une explication et un verdict, ordonnez les champs "reasoning" puis "verdict". Un modèle écrit les champs dans l’ordre, de sorte qu’un raisonnement écrit en premier peut éclairer le verdict.

Au-delà du JSON

La sortie structurée n’est pas que du JSON.

• Du Markdown avec des titres fixes convient aux réponses lues par des personnes : « Utilise exactement ces titres : Résumé, Risques, Prochaines étapes. »
• Les balises de type XML s’extraient facilement avec une expression régulière et tolèrent du texte libre à l’intérieur : <answer>…</answer>.
• Un seul token est le format le plus fiable de tous. Pour la classification, demandez uniquement l’étiquette.
• Le CSV ou les tableaux conviennent à des données petites et régulières ; les règles de guillemets deviennent fragiles avec du texte libre.

Choisissez le format le plus simple qui porte l’information.

Contraintes de longueur et de contenu

Les contraintes de sortie couvrent aussi la taille et le style :

- At most 3 bullet points, each under 20 words.
- Use only facts from the document. If the document does not say, write "not stated".
- Write in the present tense.

Donnez les tailles en nombres. « Bref » n’est pas une contrainte sur laquelle un analyseur ou une mise en page peut compter.

Validez toujours

Même avec une sortie contrainte par schéma, validez avant d’utiliser les données.

• Analysez et vérifiez le schéma de chaque réponse. Une réponse peut être coupée lorsqu’elle atteint la limite de tokens de sortie, ce qui laisse un JSON tronqué.
• Vérifiez la sémantique que le schéma ne peut pas exprimer : le total est égal à la somme des éléments, la date n’est pas dans le futur.
• Décidez du chemin d’échec. Réessayez une fois en incluant l’erreur de validation dans le prompt, puis repliez-vous sur une alternative ou signalez pour relecture.
• N’exécutez jamais une sortie structurée à l’aveugle. Un champ qui devient une clause SQL, un chemin de fichier ou un argument de shell demande le même assainissement qu’une entrée utilisateur. Voir la sécurité des prompts.

Modes de défaillance courants

Vérifier le prompt avant de l’exécuter

Un format de sortie manquant est le constat le plus fréquent dans les prompts qui alimentent du code. L’analyseur de prompts PromptFlowEngine le signale, avec l’absence d’indication de longueur et les variables non délimitées. Le modèle d’extraction JSON est un exemple complet qui passe tous les contrôles.

Pour voir comment cela s’intègre dans le code d’une application, voir l’ingénierie de prompts pour les développeurs.