Le mois dernier, j’ai effectué la même tâche d’extraction sur Claude Sonnet 3.5 à deux reprises. Première tentative : prompt non structuré, précision de 67 %. Deuxième tentative : format de sortie structuré avec validation de schéma, précision de 94 %. Même modèle, mêmes données, zéro fine-tuning. La seule différence était ma manière de demander.
Le prompt structuré n’est pas un concept nouveau. Mais la plupart des gens l’utilisent mal — ou pas du tout. Ils demandent à un modèle de « retourner du JSON » et s’étonnent que la sortie arrive mal formée. Ils spécifient un schéma mais oublient de contraindre les champs. Ils ajoutent de la structure au prompt sans la faire correspondre aux exigences de sortie.
Cet article couvre le framework qui a permis à AlgoVesta de passer d’échecs constants de parsing de sortie à des systèmes de production qui fonctionnent sans surveillance pendant des semaines. Ce n’est pas de la magie. C’est de la discipline d’ingénierie appliquée à la façon dont vous parlez aux LLM.
Ce qu’est Vraiment le Prompt Structuré (et ce qu’il n’est pas)
Le prompt structuré est une technique où vous définissez le format exact, les champs, les contraintes et les règles de validation que votre sortie doit suivre — puis vous intégrez ces règles dans le prompt lui-même.
C’est différent de :
- Demander du JSON : « Retourne du JSON » sans détail de schéma. Les modèles essaieront, mais de manière incohérente.
- Utiliser l’appel de fonction : L’appel de fonction est un outil pour appliquer une structure de sortie au niveau de l’API. Le prompt structuré est une technique de prompt qui fonctionne avec ou sans appel de fonction.
- Le templating de prompt : Remplir des variables dans un modèle statique. C’est de l’insertion de données, pas de la structure.
Le prompt structuré fonctionne car les modèles raisonnent mieux lorsque les contraintes sont explicites. Ils ont vu des milliers d’exemples où un format spécifique menait à des sorties spécifiques. Lorsque vous spécifiez ce format, vous activez des modèles appris.
Exemple réel en production : Un pipeline d’extraction financière devait extraire des données de transactions à partir des transcriptions d’appels de résultats. Sans structure, Claude retournait 4 à 7 champs supplémentaires que je n’avais pas demandés, manquait des formats de date et présentait une précision décimale incohérente. Avec un schéma intégré au prompt, il retournait exactement ce que j’avais spécifié, à chaque fois.
Le Framework Central : Quatre Couches de Structure
Voici le modèle qui s’adapte réellement :
- Définition du schéma – Définir quels champs existent et leurs types
- Spécification des contraintes – Définir les valeurs, plages, formats valides
- Modèle de sortie – Montrer la structure exacte attendue
- Règles de validation – Rendre le modèle conscient de ce qui rend la sortie invalide
Chaque couche en renforce une autre. Si vous en manquez une, le modèle dérive.
Couche 1 : Définition du Schéma
Commencez par définir les données dont vous avez besoin. Soyez précis sur les types :
# Mauvaise définition de schéma
Retourne des informations sur l'entreprise.
# Meilleure définition de schéma
Extrais les champs suivants :
- company_name (chaîne, requis)
- founded_year (entier, 4 chiffres)
- headquarters_location (chaîne, ville et pays)
- revenue_usd (nombre, en millions)La deuxième version donne quelque chose de concret au modèle. Il connaît les types qu’il doit produire.
Couche 2 : Spécification des Contraintes
Les types seuls ne suffisent pas. Ajoutez des règles sur les valeurs acceptables :
# Schéma avec contraintes
- company_name (chaîne, requis, max 100 caractères)
- founded_year (entier, doit être compris entre 1800 et 2025)
- headquarters_location (chaîne, format : « Ville, Pays » uniquement)
- revenue_usd (nombre, doit être positif, null si inconnu)Ces contraintes réduisent les hallucinations. Le modèle sait maintenant ce qui rend une sortie valide invalide. En test, l’adhérence de Claude Sonnet 3.5 aux violations de contraintes a chuté d’environ 12 % à 2 % avec des règles explicites.
Couche 3 : Modèle de Sortie
Montrez, ne dites pas. Fournissez un exemple de ce à quoi ressemble une sortie valide :
FORMAT DE SORTIE (c'est la structure exacte que vous devez suivre) :
{
