JSONSchemaBench : la complexité des schémas réels brise les garanties de sortie structurée des LLM

La plupart des équipes traitent le décodage contraint comme un problème résolu — ajoutez un schéma JSON, obtenez du JSON valide. JSONSchemaBench (arXiv:2501.10868) est la première tentative systématique de tester cette hypothèse par rapport à 9 558 schémas réels, et les résultats sont moins rassurants que ce que le marketing suggère.

L'article

Saibo Geng, Hudson Cooper, Michał Moskal et leurs collègues de Microsoft Research présentent JSONSchemaBench, un benchmark de 9 558 schémas issus de sources de production réelles : signatures d'appels de fonctions GlaiveAI, dépôts GitHub stratifiés par complexité de triviale à ultra, configurations d'API Kubernetes, schémas d'analyse d'événements Snowplow et la collection JSONSchemaStore. Ils évaluent six frameworks de décodage contraint — Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs et Gemini — selon trois axes : la couverture (quelle fraction de schémas le framework peut traiter), l'efficacité (surcharge de jetons par seconde par rapport à la génération non contrainte) et la qualité (précision de la tâche en aval). La grille d'évaluation inclut également la suite de tests officielle JSON Schema, qui documente 45 catégories de fonctionnalités que tout moteur conforme devrait supporter.

L'affirmation centrale est que la complexité du schéma est la variable décisive qui sépare les frameworks performants des frameworks fragiles, et qu'aucun framework ne domine sur les trois axes.

Idées clés

• La couverture s'effondre sous la complexité des schémas. Sur les schémas simples de GlaiveAI, tous les frameworks obtiennent un score supérieur à 86 %. Mais sur les schémas GitHub-Hard — imbrication à plusieurs niveaux, définitions récursives, contraintes de motifs complexes — Guidance chute à 41 %, Llamacpp à 39 %, XGrammar à 28 % et Outlines à un catastrophique 3 %. OpenAI n'atteint que 9 % sur GitHub-Hard, et Gemini ne produit aucune sortie valide sur les schémas de complexité moyenne ou supérieure.
• Kubernetes expose une faiblesse spécifique dans XGrammar. Malgré les promesses de vitesse de XGrammar, il n'atteint que 7 % de couverture sur les schémas Kubernetes, probablement parce que ces schémas reposent sur des motifs dépendants du contexte que le pré-calcul indépendant du contexte de XGrammar ne peut pas gérer. La couverture face à un benchmark incluant des configurations Kubernetes n'est pas optionnelle pour les agents en production.
• Le manque de contraintes est plus dangereux qu'un échec de compilation. XGrammar présente 38 échecs de sous-contrainte par rapport à la suite de tests JSON Schema — ce qui signifie qu'il émet du JSON qui viole le schéma déclaré tout en signalant silencieusement un succès. Guidance n'a qu'un seul échec de ce type. Pour un agent d'écriture, une erreur de compilation est détectée au moment de la conception ; une défaillance par sous-contrainte corrompt les données au moment de l'exécution sans aucun signal.
• L'avance rapide de Guidance offre un gain de vitesse réel de 50 %. Lorsque de longues séquences déterministes sont présentes (par exemple, des noms de champs dans une structure d'objet fixe), Guidance peut avancer de plusieurs jetons par étape de décodage. Sur Llama-3.1-8B sur un A100, Guidance tourne à 6–9 ms par jeton de sortie, tandis que la génération non contrainte tourne à 15–16 ms. Outlines est plus lent que la génération non contrainte avec 30–46 ms, principalement en raison de la compilation de son automate qui prend 3 à 8 secondes par schéma.
• Le décodage contraint améliore modestement la précision du raisonnement. Sur GSM8K (mathématiques), Guidance augmente la précision de 80,1 % (non contraint) à 83,8 %. Sur Last Letter et Shuffle Objects, les gains sont de l'ordre de 1 à 3 points. Cela contredit l'inquiétude largement citée selon laquelle forcer le format JSON dégraderait la qualité des réponses — mais la taille de l'effet est suffisamment faible pour que le choix du format ne soit pas le moteur de la sélection du framework.
• Aucun framework ne couvre les 45 catégories de fonctionnalités de JSON Schema. Guidance en couvre 13, Llamacpp et XGrammar en couvrent 1 chacun, et Outlines 0. L'implication pratique est que tout schéma utilisant if/then/else, unevaluatedProperties ou des définitions $ref récursives se comportera de manière imprévisible selon le moteur utilisé.

Ce qui tient la route — et ce qui ne la tient pas

La contribution la plus forte du benchmark est le sourcing des schémas. Les évaluations précédentes utilisaient des schémas simplistes ou des collections provenant d'une seule source. Inclure des configurations Kubernetes aux côtés de signatures d'appels de fonctions est le bon type de diversité adverse. La stratification de la complexité (de triviale à ultra) donne également aux praticiens une courbe d'étalonnage : si vos schémas ressemblent à des appels de fonctions GlaiveAI, XGrammar ou Guidance conviennent tous les deux ; s'ils ressemblent à des manifestes Kubernetes, vos options se réduisent rapidement.

La principale faiblesse est l'évaluation gloutonne sur un seul échantillon. Mesurer la couverture avec une seule génération par schéma sous-estime la capacité réelle — un framework peut échouer 20 % du temps mais réussir lors d'une nouvelle tentative. L'article le reconnaît mais ne rapporte pas les chiffres de pass@k échantillonnés avec température, ce qui importerait pour les systèmes de production qui réessayent en cas d'échec.

La comparaison mélange également des modèles incomparables. Les frameworks open-source (Guidance, Outlines, Llamacpp, XGrammar) sont testés sur Llama-3.2-1B, tandis qu'OpenAI et Gemini utilisent leurs propres modèles non divulgués. La couverture de 9 % d'OpenAI sur GitHub-Hard peut refléter la capacité du modèle autant que l'architecture de décodage contraint. Une comparaison équitable nécessiterait un accès contrôlé aux modèles — ce que les auteurs ne peuvent évidemment pas imposer aux fournisseurs propriétaires.

Pourquoi cela compte pour l'IA financière

Chaque agent d'écriture Beancount génère une sortie structurée. Si l'agent émet des directives Beancount sous forme de JSON avant de les convertir en syntaxe .beancount, ou s'il appelle des outils via des schémas JSON, la fiabilité de cette génération JSON n'est pas un détail — c'est l'enjeu principal. L'article FinTrace a montré que les modèles de pointe échouent à raisonner sur les sorties d'outils ; JSONSchemaBench révèle un problème orthogonal : même avant le raisonnement, la couche de formatage peut émettre silencieusement une sortie non conforme.

Le résultat sur Kubernetes est particulièrement révélateur pour Beancount. Les schémas de grand livre ne sont pas de simples sacs de clés-valeurs plats. Les hiérarchies de comptes, les métadonnées de transaction et les structures de balises créent des motifs récursifs imbriqués similaires aux objets de l'API Kubernetes. Un framework qui obtient un score de 7 % sur Kubernetes n'est pas prêt pour des schémas de grand livre complexes, quelle que soit la vitesse de sa surcharge par jeton.

Le mode de défaillance par sous-contrainte est celui qui m'empêcherait de dormir. Un agent Beancount utilisant XGrammar pourrait émettre une transaction qui passe la vérification de validation interne du framework mais viole le schéma réel — et l'agent n'aurait aucune raison de réessayer. La corruption silencieuse est pire qu'un échec visible.

Que lire ensuite

• XGrammar (arXiv:2411.15100, Dong et al.) — l'article technique derrière l'un des frameworks les plus rapides testés, expliquant la séparation des jetons indépendants/dépendants du contexte et pourquoi les schémas Kubernetes le mettent à l'épreuve.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024) — montre que le masquage de jetons dans le décodage contraint peut fausser la distribution de probabilité du modèle et propose un algorithme d'échantillonnage corrigé ; le fondement théorique des préoccupations de qualité que le benchmark ne mesure qu'indirectement.
• XGrammar-2 (arXiv:2601.04426) — une suite qui étend XGrammar aux schémas dynamiques dans des contextes d'agents où le schéma lui-même change au cours d'une session multi-tours, directement pertinent pour les agents Beancount qui adaptent leur format de sortie en fonction des types de comptes actifs.