Pourquoi les petits modèles locaux hallucinent-ils davantage lors de la génération de JSON ?
Les petits modèles locaux produisent davantage d’hallucinations lors de la génération de JSON, car ils doivent résoudre la tâche tout en préservant un schéma rigide et une syntaxe valide.
Un flux de travail d’IA à domicile peut demander à un modèle compact d’extraire des noms de fichiers, des dates, des balises, des états d’appareils ou des arguments d’automatisation et de les renvoyer sous forme de JSON lisible par une machine. Le modèle n’effectue pas une seule tâche. Il doit identifier les faits corrects, les associer aux champs prévus, respecter les types et énumérations requis, se souvenir de la ponctuation et de la structure imbriquée, puis s’arrêter sans ajouter de commentaire. Lorsque les capacités du modèle sont limitées, ces contraintes rivalisent avec le raisonnement nécessaire pour maintenir les valeurs ancrées dans les faits.
Le JSON transforme la correction en un problème à deux niveaux
La réponse doit être correcte sur le plan sémantique et valide sur le plan structurel en même temps. Une réponse en texte libre peut exprimer une incertitude ou expliquer qu’une valeur est manquante, tandis qu’un contrat JSON oblige souvent le modèle à choisir une valeur de champ même lorsque les preuves sont faibles.
Les recherches sur le compromis entre validité et correction montrent pourquoi ces mesures doivent rester distinctes : des contraintes de sortie plus fortes peuvent améliorer la validité du schéma, tandis que les valeurs sélectionnées deviennent moins précises.
Cette pression est plus visible avec un petit modèle local, car il dispose de moins de capacités disponibles pour suivre les instructions, extraire les informations et sérialiser les résultats. Un modèle plus grand peut lui aussi inventer un champ, mais un modèle compact atteint plus rapidement le point où le respect du format nuit à la qualité de la réponse.
Un objet valide peut tout de même contenir une réponse hallucinée
Le décodage contraint peut empêcher l’émission d’une accolade illégale, d’une clé inconnue ou d’une valeur d’énumération invalide. Il ne peut pas prouver que l’identifiant client, la date, le chemin ou le statut sélectionné est présent dans les données sources.
vLLM décrit les contraintes de schéma JSON comme un moyen de limiter la forme de la sortie générée. Le décodeur réduit l’ensemble des jetons légalement possibles à l’étape suivante, mais le modèle fournit toujours le sens porté par ces jetons autorisés.
Cela crée un mode de défaillance dangereux pour l’automatisation : l’objet est analysé avec succès, le code en aval lui fait donc confiance, alors qu’un champ est fabriqué. Validez les règles métier et les preuves issues des sources après la validation du schéma, au lieu de considérer la réussite de l’analyse comme une preuve de correction factuelle.
Les schémas imbriqués augmentent le nombre de choix et la charge de suivi de l’état
Chaque propriété obligatoire, branche facultative, liste imbriquée, champ nullable et énumération ajoute un état que le modèle doit suivre pendant la génération. Des noms de clés similaires ou des structures d’objets répétées facilitent le placement d’une valeur correcte au mauvais endroit.
Le guide de llama.cpp consacré au JSON contraint par grammaire distingue la grammaire de sortie autorisée de l’invite qui explique la signification des champs. Une grammaire peut imposer la structure, mais le schéma nécessite toujours des instructions sémantiques claires.
Réduisez le nombre de décisions simultanées. Aplatissez les objets profondément imbriqués, supprimez les champs facultatifs inutilisés, utilisez des noms de clés distincts et divisez une extraction volumineuse en objets plus petits lorsque le modèle local échange régulièrement les champs ou remplit des champs sans rapport.
Les invites exigeant uniquement du JSON peuvent supprimer un raisonnement utile
Une instruction stricte du type « renvoyez uniquement du JSON » pousse le modèle à formater immédiatement une réponse. Pour une extraction difficile, cela peut provoquer un choix prématuré avant que le modèle ait comparé des passages concurrents ou résolu une date ambiguë.
Les évaluations de Hugging Face montrent la sensibilité au format de l’invite : modifier la structure attendue et l’espace disponible pour le raisonnement peut changer les performances sur la tâche, même lorsque la question sous-jacente reste la même.
N’exposez pas de chaîne de raisonnement privée, mais séparez la résolution interne de la tâche de la sérialisation finale. Le flux de travail peut d’abord extraire un relevé compact des preuves ou effectuer une recherche déterministe, puis demander au modèle de restituer uniquement les champs vérifiés.
Le JSON guidé par l’invite et le décodage contraint échouent de manière différente
Le JSON généré uniquement à partir de l’invite peut contenir des blocs de code, des commentaires, des clés en double, des virgules finales ou un objet inachevé. Le décodage contraint élimine de nombreuses erreurs de syntaxe, mais il peut obliger le modèle à choisir entre des valeurs valides lorsque la valeur « inconnue » n’est pas autorisée.
Fireworks explique comment les choix de jetons restreints par le schéma maintiennent la génération dans les limites d’un contrat de sortie, tout en exigeant que l’invite décrive précisément les données attendues.
Suivez les deux familles de défaillances. Mesurez les erreurs d’analyse pour les sorties générées uniquement à partir de l’invite, puis mesurez les champs erronés mais valides, les valeurs par défaut indésirables et la fausse certitude après l’activation du décodage contraint.
L’échantillonnage et la troncature amplifient les petites erreurs
Une température plus élevée peut faire varier le choix des clés et les valeurs des champs, tandis qu’un budget de jetons insuffisant peut interrompre les listes ou supprimer les accolades fermantes. Une température plus basse réduit les variations, mais ne rend pas vraie une valeur non étayée.
Une analyse pratique d’un flux de sortie structurée local montre pourquoi la validation et la génération contrainte sont des composants distincts plutôt qu’une simple astuce de formulation d’invite.
Prévoyez suffisamment de jetons de sortie pour l’objet légal le plus volumineux, limitez la longueur des listes et ne relancez que la partie en échec. Régénérer l’objet entier peut remplacer des champs déjà corrects par de nouvelles hallucinations.
Utilisez un pipeline JSON local en deux étapes
Commencez par résoudre la tâche en un enregistrement typé minimal : l’extrait source exact, la date normalisée, l’identifiant sélectionné, l’état de confiance et toute valeur explicitement manquante. Cette étape doit pouvoir refuser la demande plutôt que d’inventer les données obligatoires.
Restituez ensuite cet enregistrement à l’aide d’un décodeur contraint par schéma, analysez-le, puis exécutez des contrôles sémantiques tels que l’existence du fichier, la plage de dates, la compatibilité avec l’énumération et la cohérence entre les champs. Un validateur doit renvoyer des erreurs ciblées indiquant le champ à corriger.
L’explication de ZimaSpace sur les raisons pour lesquelles un modèle plus petit peut être plus fiable fournit le cadre : les modèles compacts fonctionnent mieux lorsque la tâche, le contexte, l’ensemble d’outils et le contrat de sortie sont suffisamment limités pour être vérifiés.
FAQ
Un JSON valide signifie-t-il que le modèle n’a pas halluciné ?
Non. Un JSON valide prouve que l’objet respecte les règles de syntaxe ou du schéma. Cela ne prouve pas que les valeurs des champs proviennent de la source ou correspondent à l’état réel du système.
Régler la température sur zéro résoudra-t-il les hallucinations JSON ?
Non. Cela peut rendre la sortie plus reproductible, mais une valeur non étayée sélectionnée de manière systématique reste une hallucination.
Le décodage contraint suffit-il pour l’automatisation ?
Non. Utilisez-le avec une extraction ancrée dans les sources, l’analyse du schéma, la validation sémantique et une procédure de rejet sûre pour les données manquantes ou ambiguës.
Produits recommandés
Centre Tech & IA
Plus à lire
Pourquoi les prédictions de la maison connectée deviennent-elles moins précises après des changements de routine saisonniers ?
Les habitudes saisonnières modifient la relation entre le temps, les capteurs, l’occupation et les actions souhaitées, ce qui rend obsolète un modèle entraîné à...
Pourquoi un NVR domestique manque-t-il des événements brefs lorsque le suivi des objets est activé ?
Le suivi nécessite suffisamment de détections pour commencer et confirmer une trajectoire ; un objet peut donc disparaître brièvement avant que le NVR ne...
Pourquoi les étiquettes des photos générées par l’IA changent-elles après la mise à niveau d’un modèle ?
Une mise à niveau du modèle modifie la représentation et le classement utilisés pour attribuer les étiquettes, de sorte qu’une même photo peut franchir...
