Sortie structurée
La sortie structurée est une fonctionnalité qui force un LLM à renvoyer des réponses conformes à un schéma spécifié, généralement un schéma JSON. Au lieu d'espérer que le modèle produise du JSON analysable, le moteur d'inférence contraint l'échantillonnage des tokens pour que la sortie soit garantie valide.
La sortie structurée est une fonctionnalité qui force un LLM à renvoyer des réponses conformes à un schéma spécifié, généralement un schéma JSON. Au lieu d'espérer que le modèle produise du JSON analysable, le moteur d'inférence contraint l'échantillonnage des tokens pour que la sortie soit garantie valide.
Pourquoi c'est important
Les LLM qui renvoient du texte libre sont difficiles à exploiter par programmation. Même lorsqu'on leur demande "renvoie du JSON", les modèles ajoutent parfois de la prose, omettent des champs ou inventent des types. Cela casse le code en aval et impose une analyse défensive. La sortie structurée résout le problème au niveau du décodage, vous obtenez du JSON valide 100 % du temps, pas 95 %. OpenAI, Anthropic, Google et des moteurs open source comme vLLM et Outlines la prennent désormais en charge nativement, ce qui en fait la façon par défaut de construire des pipelines LLM fiables.
Comment ça fonctionne
Décodage contraint : à chaque étape de génération, le modèle ne peut échantillonner que des tokens qui maintiennent la sortie compatible avec le schéma. Les tokens qui violeraient le schéma sont masqués à une probabilité nulle.
Spécification du schéma : vous fournissez un schéma JSON (ou un modèle Pydantic, un schéma Zod, un type TypeScript) décrivant les champs requis, les types et les énumérations.
Analyse sans validation : l'appelant peut faire JSON.parse du résultat sans try/catch autour d'une sortie malformée.
Mode JSON vs sortie structurée
| Aspect | Mode JSON | Sortie structurée |
|---|---|---|
| Garantie | Syntaxe JSON valide | JSON valide conforme à votre schéma |
| Application du schéma | Aucune | Complète |
| Présence des champs | Non garantie | Garantie |
| Champs inventés | Possibles | Impossibles |
| Surcoût de latence | ~0 | Faible (compilation de la contrainte) |
Le mode JSON garantit seulement que la sortie s'analyse. La sortie structurée garantit qu'elle s'analyse et correspond exactement à la forme dont vous avez besoin. Pour les systèmes en production, utilisez toujours la sortie structurée lorsqu'elle est disponible.
Quand l'utiliser
Extraire des données d'un texte : tirer des noms, des dates, des adresses d'une entrée non structurée.
Construire des agents qui appellent des outils : les arguments de l'appel d'outil doivent correspondre exactement au schéma de paramètres de l'outil.
Classer en énumérations : forcer le modèle à choisir l'une d'un ensemble fixe d'étiquettes.
Générer des réponses à plusieurs champs : titres, résumés, tags, scores en une seule passe.
Partout où vous analysez actuellement la sortie du modèle par regex : c'est un bug en puissance.
Compromis
Léger surcoût de latence : le décodeur doit suivre l'état de la grammaire. Généralement négligeable.
Créativité réduite : des contraintes de schéma lourdes peuvent rendre la génération mécanique. Pour l'écriture créative, préférez le texte libre.
La conception du schéma compte : des schémas trop stricts (required : les 20 champs) forcent le modèle à inventer des valeurs. Rendez facultatif ce qui l'est vraiment.
Tous les modèles ne la prennent pas en charge : les modèles plus anciens et certains modèles open source manquent encore de support natif. Outlines et des bibliothèques similaires peuvent l'ajouter après coup.
Exemple
Schéma :
{
"type": "object",
"properties": {
"title": { "type": "string" },
"tags": { "type": "array", "items": { "type": "string" } },
"sentiment": { "enum": ["positive", "negative", "neutral"] }
},
"required": ["title", "tags", "sentiment"]
}
Sortie garantie :
{ "title": "Launch recap", "tags": ["product", "Q2"], "sentiment": "positive" }
Aucune erreur d'analyse. Aucun champ manquant. Aucune valeur d'énumération inventée.
Sources :