Sorties structurées : JSON valide, données fausses sans garde-fous

Un pipeline d’extraction de transactions montrait 2 à 3 % de discordances malgré des réponses JSON impeccables. La cause identifiée : des champs requis remplis par le modèle en l’absence d’information, souvent avec la date d’exécution. Des solutions concrètes émergent : rendre les champs nullable, exiger une preuve textuelle et valider côté code avec réessais limités.

Validation métier : contrôles Pydantic et deux réessais maximum

Certaines erreurs échappent aux schémas, comme un montant négatif ou une date future. Des consignes ajoutées à l’invite se sont révélées insuffisantes pour imposer ces règles. Un validateur Pydantic applique au contraire des contraintes déterministes, par exemple exiger un montant positif et interdire une transaction datée dans le futur. Dans les cas observés, des montants négatifs sont apparus exactement deux fois, car le texte décrivait des remboursements. L’API de génération garantit la structure, tandis que Pydantic vérifie la cohérence métier au parsing, sans faire intervenir le modèle. En cas d’échec, deux voies existent : l’orientation vers un humain ou un nouvel essai automatique. Une stratégie opérationnelle renvoie l’erreur détaillée au modèle avec une limite stricte de deux tentatives, en fournissant la sortie brute précédente et en demandant de corriger seulement le champ fautif. Prolonger indéfiniment les essais est déconseillé : après deux échecs, le problème provient presque toujours du document source, et un passage de plus consomme des appels API pour un cas qu’un humain règle rapidement.

Un champ dédié permet d’indiquer l’origine exacte de chaque donnée

Même avec des champs optionnels, une valeur renvoyée peut ne pas provenir explicitement du texte. Pour tracer l’origine, un champ sibling contenant l’extrait source exact est ajouté à côté de chaque valeur, via un wrapper générique combinant value et evidence. Ce choix remplace des types dédiés par une union et réduit la sécurité de type, mais devient rentable quand le schéma dépasse quelques types de champs. L’ordre evidence puis value contraint le modèle à citer avant de répondre, et offre aux réviseurs un élément vérifiable. Une valeur sans preuve, ou appuyée par un texte absent de la source, matérialise l’hallucination dans les données. Ce dispositif a un coût : sur quelques centaines de messages, le volume de tokens de sortie a crû d’environ un tiers et la latence a augmenté sensiblement. Il peut être évité pour des champs triviaux, comme un code postal à cinq chiffres, et retenu pour des montants financiers appelant une action.

Quand le schéma force des inventions : le cas des dates manquantes

Après trois semaines d’utilisation des Sorties Structurées sur des confirmations de paiement, une réconciliation a révélé un flux discret mais durable d’anomalies, autour de 2 à 3 % du volume hebdomadaire. Les lignes n’étaient ni cassées ni mal formées : le montant et l’expéditeur correspondaient, seule la date différait. L’hypothèse d’un problème de fuseau horaire a été écartée. Chaque cas provenait d’un message ne contenant pas de date, par exemple « Paiement reçu de Chinedu, ₦45,000, ref TXN-82K91 ». Le modèle remplissait pourtant transaction_date, presque toujours avec la date d’exécution du job, à moins d’une heure près. En cause, un schéma imposant une date requise, qui pousse le modèle à fournir une valeur acceptable pour le typage. Considérer un JSON valide comme aboutissement masque cet échec silencieux : l’absence de valeur réelle ne se voit qu’au moment où un traitement aval en dépend. Les Sorties Structurées traitent le risque de JSON invalide, pas la réalité des champs.

Nullable plutôt qu’inférence par défaut : rendre l’absence explicite

Un champ vide reflète souvent la vérité des sources. Rendre les champs nullable permet au modèle d’indiquer explicitement l’absence d’information, plutôt que d’inférer une valeur. La confusion entre extraction — rapporter exactement le texte — et inférence — déduire ce qu’il implique — naît notamment de champs requis sans donnée, comme une date ISO quand le message se contente d’un « mardi ». En rendant les champs optionnels, la décision d’inférer revient au code applicatif, qui peut par exemple solliciter des informations complémentaires lorsque la date est absente.

Ce que les Sorties Structurées apportent, et ce qu’elles n’apportent pas

Les schémas natifs et les APIs modernes ont simplifié l’obtention d’un JSON propre, là où des parseurs regex, des boucles de réessai et des invites strictes étaient auparavant nécessaires. Un modèle Pydantic avec des types explicites combiné à un appel de parsing direct produit, sur un document bien formé — par exemple avec une « Date : 11 août 2026 » — des objets valides sans gestion d’artefacts de format. Mais lorsque des champs requis manquent, le modèle peut insérer une valeur plausible qui passe les contrôles de type sans refléter la source. Ces limites et les remèdes détaillés ne sont pas spécifiques à un fournisseur donné. Le code peut ensuite consigner l’identifiant de transaction après un parsing réussi, dans un flux opérationnel débarrassé des erreurs de format mais pas, à lui seul, des erreurs de contenu.