Qu’est-ce qui fait qu’un LLM local produit une sortie qui ne respecte pas un schéma JSON valide ?
La sortie d’un LLM local enfreint un schéma JSON valide lorsque la génération, la gestion des contraintes, les règles d’arrêt et la validation n’appliquent pas le même contrat.
Un workflow auto-hébergé peut fournir un schéma conforme aux normes pour les métadonnées de fichiers, les actions domotiques, l’extraction de documents ou les arguments d’outils, et recevoir malgré tout une sortie mal formée ou rejetée. « Schéma valide » décrit le document de schéma, et non l’ensemble du chemin d’exécution. Le modèle doit comprendre la tâche, le décodeur doit prendre en charge les fonctionnalités de schéma pertinentes, la génération doit se terminer avant qu’une condition d’arrêt ne l’interrompe, l’analyseur doit récupérer une valeur JSON complète et le validateur de l’application doit appliquer les règles de brouillon et de coercition attendues.
JSON valide et JSON valide selon le schéma sont deux résultats différents
Un objet peut être analysé avec succès tout en enfreignant les champs obligatoires, les types, les énumérations, les limites de tableaux ou les branches conditionnelles. Il peut également contenir les bons noms de champs tout en ajoutant des propriétés interdites par le schéma.
Le module JSON de Python définit la couche syntaxique pour décoder un document JSON, mais l’analyse ne met pas en œuvre un contrat JSON Schema distinct.
Cette cause est reconnaissable lorsque la sortie se charge sans erreur de syntaxe, mais échoue uniquement après la validation du schéma. Une accolade manquante ou une explication finale constitue un échec de sérialisation ; une chaîne à la place d’un entier requis constitue un échec du contrat.
La composition de schémas peut créer des branches difficiles à satisfaire
Des mots-clés tels que allOf, anyOf, oneOf et not combinent des contraintes. Une branche peut être valide isolément, tandis que l’objet combiné ne satisfait aucune ou plusieurs des alternatives autorisées.
Le guide JSON Schema explique comment les mots-clés de composition de schémas déterminent si un ou plusieurs sous-schémas doivent correspondre.
Un modèle local gère souvent plus fiablement une liste plate de propriétés qu’une logique conditionnelle imbriquée. Si les échecs se concentrent autour des unions ou de structures d’objets mutuellement exclusives, la difficulté principale vient de la sélection de branche plutôt que de la ponctuation JSON de base.
Le décodeur contraint peut ne prendre en charge qu’une partie du schéma
Les moteurs de sortie structurée traduisent les schémas en contraintes de jetons, grammaires, expressions régulières ou règles propres au backend. Ils n’implémentent pas tous chaque brouillon ou mot-clé JSON Schema.
vLLM expose plusieurs backends de sortie structurée, ce qui montre que les contraintes fondées sur un schéma JSON, une grammaire, une expression régulière ou des choix fixes sont des modes d’exécution distincts.
Cette cause apparaît lorsque le même schéma est correctement validé par un validateur conforme aux normes, mais échoue uniquement avec un backend d’inférence donné. La récursivité, les références, les motifs ou les mots-clés conditionnels non pris en charge peuvent être simplifiés, ignorés ou rejetés avant même que le modèle ne génère quoi que ce soit.
Les instructions du prompt peuvent entrer en conflit avec le schéma
Le prompt utilisateur peut demander des commentaires, des citations, des explications, des omissions facultatives ou une incertitude en langage naturel, tandis que le schéma exige un objet unique avec des champs fixes.
Le modèle se retrouve alors face à deux critères de réussite concurrents : répondre à l’utilisateur de manière conversationnelle et n’émettre que des jetons autorisés par le contrat machine. Un modèle local de plus petite taille peut suivre l’instruction la plus récente ou la plus marquante au lieu de concilier les deux.
Ces échecs ajoutent souvent un préambule, une clôture Markdown, une explication après l’objet ou une valeur qui répond à la demande en prose, mais enfreint l’énumération déclarée. Le schéma est valide ; la hiérarchie des instructions est incohérente.
La troncature peut transformer un plan correct en sortie invalide
Les tableaux et objets imbriqués nécessitent suffisamment de jetons générés pour fermer chaque structure. Une limite de jetons, une chaîne d’arrêt, une requête annulée ou un flux interrompu peut mettre fin à la réponse avant l’arrivée des délimiteurs finaux.
Transformers expose des contrôles de jetons maximum et d’arrêt qui déterminent le moment où la génération se termine.
Cette cause se distingue par des préfixes valides qui s’interrompent brusquement, en particulier avec les tableaux volumineux ou les champs de chaîne longs. Des violations répétées de types au début indiquent une autre cause ; des crochets fermants manquants près de la limite de sortie indiquent une génération incomplète.
La sémantique du validateur peut rejeter des valeurs que le modèle considère comme équivalentes
Un modèle peut produire "3" pour un entier, null pour un champ omis, une énumération en minuscules ou une date ISO dans un format différent de celui attendu par l’application.
Pydantic documente des catégories distinctes d’erreurs de validation pour les valeurs manquantes, le JSON invalide, les incompatibilités d’énumération, les champs supplémentaires interdits et les types incompatibles.
Si chaque échec concerne le même champ avec une valeur analysable mais rejetée, la cause n’est pas une rupture aléatoire du schéma. Il s’agit d’un désaccord sur la coercition, le mode strict, la possibilité de valeur nulle, la casse ou les formats propres à l’application.
Les contraintes de grammaire peuvent préserver la syntaxe sans préserver le sens métier
Une grammaire peut bloquer les accolades et les clés illégales tout en autorisant une combinaison sémantiquement impossible, comme une date de fin antérieure à une date de début ou un chemin de fichier inexistant.
llama-cpp-python fournit une génération contrainte par une grammaire comme contrôle d’inférence, mais la grammaire régit la structure autorisée des jetons plutôt que la réalité externe.
Un échec de schéma causé par des règles entre champs peut n’apparaître que lors d’une seconde couche de validation. La sortie peut être syntaxiquement et structurellement valide tout en restant inutilisable pour le workflow du serveur domestique.
Le post-traitement peut altérer une sortie de modèle pourtant valide
Les applications suppriment parfois le Markdown, extraient le premier bloc délimité par des accolades, fusionnent des fragments de flux, réparent les virgules ou convertissent les valeurs avant la validation.
Une réponse de modèle valide peut devenir invalide lorsqu’un fragment de flux est dupliqué, qu’Unicode est décodé incorrectement, qu’une séquence d’échappement est supprimée ou qu’une fonction de réparation modifie un contenu imbriqué. À l’inverse, une étape de réparation peut dissimuler le fait que la sortie brute du modèle était invalide.
L’explication de ZimaSpace sur les raisons pour lesquelles les petits modèles locaux hallucinent lors de la génération JSON fournit le contexte complémentaire : la validité du schéma et l’exactitude factuelle doivent être mesurées séparément, et la réponse brute doit être conservée avant les transformations de l’application.
FAQ
Un JSON valide prouve-t-il que la sortie correspond au schéma ?
Non. L’analyse JSON vérifie la syntaxe. La validation du schéma vérifie séparément les propriétés obligatoires, les types, les énumérations, les branches, les limites et les autres contraintes déclarées.
La température zéro empêchera-t-elle les échecs de schéma ?
Non. Elle peut rendre un chemin de décodage plus reproductible, mais elle n’ajoute pas la prise en charge des fonctionnalités de schéma non supportées, n’empêche pas la troncature et ne résout pas les instructions contradictoires.
Le décodage contraint garantit-il un enregistrement d’automatisation exploitable ?
Non. Il peut garantir les contraintes structurelles prises en charge, mais les règles métier, l’ancrage dans les sources, l’existence des fichiers, les autorisations et la cohérence entre les champs nécessitent toujours une validation par l’application.
Produits recommandés
Centre Tech & IA
Plus à lire
Quelles fonctionnalités permettent de créer une frontière de confiance pour l’IA domestique autour des fichiers sensibles ?
Une frontière de confiance pour l’IA à domicile combine le chiffrement des données au repos, des autorisations selon le principe du moindre privilège, un...
Pourquoi les résultats de recherche privés privilégient-ils les fichiers fréquemment modifiés ?
Les fichiers fréquemment modifiés bénéficient d’un meilleur classement lorsque chaque mise à jour ajoute des signaux de fraîcheur, des segments, des versions ou des...
Qu’est-ce qui pousse les modèles de détection de présence pour maison intelligente à confondre les invités avec les résidents ?
Les invités peuvent être pris pour des résidents lorsque le système observe des habitudes d’activité du foyer, mais ne dispose d’aucun signal d’identité stable...
