Token-Oriented Object Notation vs JSON: A Benchmark of Plain and Constrained Decoding Generation

Cette étude comparative révèle que bien que le format TOON offre un potentiel d'économie de tokens prometteur pour les structures complexes, son avantage est souvent annulé par la surcharge du prompt et que la génération JSON standard, même sans contraintes, surpasse actuellement TOON en précision et en efficacité pour les structures simples.

L'essentiel

📦 Le Contexte : Deux façons de faire ses valises

Imaginez que vous devez envoyer des données (des objets) à un grand cerveau artificiel (un LLM) pour qu'il les comprenne et les utilise.

1. Le JSON (Le Standard) : C'est comme un carton à déménagement classique. Tout le monde connaît les règles : on met des étiquettes, des parenthèses () et des guillemets "". C'est lourd, ça prend de la place, mais c'est fiable. Le robot sait exactement comment le lire car il a vu des millions de ces cartons pendant son apprentissage.
2. Le TOON (Le Nouveau) : C'est comme un système de valises ultra-compactes et pliables. L'idée est de supprimer tout le "bruit" (les guillemets, les virgules inutiles) pour que le carton soit beaucoup plus petit et léger. Moins de poids = moins cher à envoyer et plus rapide à traiter.

Le problème ? Le robot n'a jamais vu ces valises TOON avant. Il faut donc lui donner un manuel d'instructions très détaillé (le "prompt") pour qu'il sache comment les plier.

---

🧪 L'Expérience : Qui gagne ?

Les chercheurs ont fait un test avec 21 robots différents (des modèles d'IA) pour voir qui arrivait à remplir ces valises le mieux, le plus vite et le moins cher. Ils ont comparé trois méthodes :

1. JSON classique : Le robot écrit tout seul.
2. JSON "Guidé" (JSO) : On met un garde-fou numérique pour empêcher le robot de faire des fautes de grammaire.
3. TOON : On donne le manuel d'instructions et on demande au robot d'utiliser le format compact.

🏆 Les Résultats Clés (Traduits en analogies)

1. La "Taxe d'entrée" (Le coût du manuel)

Pour le TOON, il faut payer un "péage" au début : le manuel d'instructions est long.

• Petits déménagements (peu de données) : Si vous n'avez qu'un seul objet à envoyer, le temps perdu à lire le manuel TOON est plus long que le temps gagné à l'envoyer. Le JSON classique gagne car le robot le connaît déjà par cœur.
• Gros déménagements (beaucoup de données) : Si vous devez envoyer 1000 objets, le gain de place du TOON finit par compenser le temps perdu à lire le manuel. C'est là que TOON devient intéressant.

2. La complexité de la structure

• Les cas "Faciles" (Tableaux, listes simples) : Pour des listes comme "Liste d'utilisateurs" ou "Factures", le TOON est très efficace. Il est précis et économise beaucoup de place.
• Les cas "Difficiles" (Arbres complexes, hiérarchies profondes) : Pour des structures compliquées (comme un organigramme d'entreprise avec des sous-sous-sous-départements), le TOON s'effondre. Le robot se perd dans les instructions. Le JSON (surtout avec le mode "Guidé") reste le roi de la fiabilité ici.

3. Le piège de la "Correction"

Si le robot fait une erreur :

• Avec le JSON, il se corrige vite.
• Avec le TOON, si le robot se trompe, il faut lui renvoyer le long manuel d'instructions + l'erreur + la correction. Cela double la taille du message. Si le robot fait souvent des erreurs, le TOON devient plus cher que le JSON, même s'il est censé être léger.

4. Le "Guide de Sécurité" (JSON Guidé)

Pour les petits robots (modèles moins puissants), le mode "JSON Guidé" est un sauveur. Il les empêche de faire des fautes de syntaxe. Parfois, ce guide est même plus efficace que le TOON pour les tâches simples, car il ne nécessite pas de long manuel d'instructions.

---

💡 La Conclusion Simple

Imaginez que vous êtes un chef de projet :

• Utilisez le JSON classique si vous avez besoin de fiabilité absolue, de structures complexes ou si vous traitez de petites quantités de données. C'est le "tout-terrain" fiable.
• Utilisez le TOON si vous avez un gros volume de données simples et répétitives (comme des milliers de lignes de base de données, des logs, ou des factures standardisées). Là, vous économiserez beaucoup d'argent et de temps, à condition que le robot ne se trompe pas trop souvent.
• Évitez le TOON pour les structures complexes ou si vous utilisez des petits robots qui ont du mal à suivre les instructions.

En résumé : Le TOON est une voiture de course très légère. Elle est incroyable sur une longue piste droite (données simples et massives), mais elle est difficile à conduire dans un quartier avec beaucoup de virages (données complexes) et elle demande un manuel de conduite long à lire avant de démarrer. Le JSON, lui, est une voiture familiale : un peu plus lourde, mais elle roule partout et tout le monde sait la conduire.

Résumé technique

1. Contexte et Problématique

L'article aborde le problème de l'efficacité des tokens lors de la génération de données structurées par les grands modèles de langage (LLM). Le format JSON est le standard actuel, mais il est souvent verbeux, ce qui augmente les coûts et la latence.

Pour y remédier, le format TOON (Token-Oriented Object Notation) a été proposé comme une alternative conçue spécifiquement pour réduire la consommation de tokens tout en conservant la lisibilité pour les LLM. Cependant, à ce jour, il manquait une évaluation rigoureuse comparant la génération TOON (via l'apprentissage en contexte "one-shot") à la génération JSON standard et à la génération JSON avec décodage contraint (Structured Output).

L'objectif principal de l'étude est de déterminer si les économies de tokens promises par TOON compensent le coût du "prompt" (l'instruction et l'exemple fournis au modèle) et si le format est robuste face à des structures de données complexes.

2. Méthodologie

L'auteur a conçu un benchmark reproductible comparant trois approches de génération sur 21 modèles LLM différents (via l'API Nebius) :

1. JSON (J) : Génération JSON standard (plain text).
2. JSON-SO (JSO) : Génération JSON avec décodage contraint (Structured Output). Le moteur d'inférence utilise un automate d'état (type xgrammar) pour masquer les logits et forcer le modèle à respecter une grammaire valide, garantissant une syntaxe correcte.
3. TOON (T) : Génération au format TOON via un exemple "one-shot" dans le prompt (in-context learning), sans données d'entraînement spécifiques au format.

Configuration de l'expérience :

• Cas de test : Quatre scénarios de complexité croissante :
  • Users : Structure tabulaire simple.
  • Order : Structure imbriquée avec tableau.
  • Company : Hiérarchie profonde (départements/employés).
  • Invoice : Articles et totaux.
• Validation : Les sorties sont décodées et validées via des modèles Pydantic.
• Boucle de réparation : Si la validation échoue, un cycle de réparation est lancé (jusqu'à 3 tentatives) en réinjectant l'erreur dans le contexte.
• Métriques clés :
  • Précision One-shot : Taux de réussite au premier essai.
  • Précision Finale : Taux de réussite après cycles de réparation.
  • Budget de tokens : Somme totale des tokens (prompt + complétion) nécessaires pour obtenir un résultat valide.

3. Résultats Clés

Les résultats révèlent des compromis complexes entre précision, coût et complexité structurelle.

A. Précision et Robustesse

• JSON Standard (J) : Offre la meilleure précision globale, tant en one-shot qu'en final, surpassant souvent le JSON contraint.
• JSON Contraint (JSO) : Agit comme un filet de sécurité pour les modèles plus petits ou moins performants (ex: Qwen-7B), passant de 0% à 75% de précision. Cependant, pour les modèles puissants (ex: Hermes-4-405B), les contraintes rigides dégradent la précision initiale (chute de 92,5% à 35% en one-shot), obligeant le modèle à suivre des chemins de tokens sous-optimaux.
• TOON :
  • Aligné (Données tabulaires/plates) : Performances prometteuses (ex: 90,5% de précision one-shot sur le cas "Users").
  • Non-aligné (Hiérarchies profondes) : Effondrement de la précision. Sur le cas "Company" (structure profonde), la précision one-shot est de 0%. Bien que la précision finale remonte à ~48% après réparation, cela s'accompagne d'un coût élevé en tokens.

B. Économie de Tokens et "Taxe de Prompt"

• Le coût du prompt : TOON nécessite un prompt explicatif lourd (règles + exemple). Pour les contextes courts ou les sorties simples, cette "taxe de prompt" annule les économies de tokens du format de sortie.
  • Exemple : Pour le modèle Qwen3-235B, le JSON standard a consommé 2772 tokens contre 4715 pour TOON, malgré un format de sortie plus léger.
• Avantage de TOON : Il ne devient efficace que lorsque la taille des données générées est suffisamment grande pour amortir le coût fixe du prompt.
• Le gagnant des petits cas : Pour les structures simples (cas "Users"), le JSON Contraint (JSO) a été le plus efficace en tokens (556 tokens), surpassant même TOON (840 tokens).

C. Hypothèse de Non-Linéarité

L'étude suggère une hypothèse de mise à l'échelle : l'efficacité de TOON suit une courbe non linéaire. Il n'est avantageux que au-delà d'un certain seuil de complexité et de volume de données, où les économies syntaxiques cumulées surpassent le surcoût initial du prompt.

4. Contributions et Conclusions Techniques

1. Dichotomie de la performance : La performance de TOON est strictement dictée par la topologie des données. Il excelle pour les documents transactionnels et tabulaires (alignés) mais échoue sur les structures récursives profondes (non-alignés).
2. Limites du décodage contraint : Bien que JSO soit excellent pour la stabilité des petits modèles, il peut nuire à la performance des modèles de raisonnement avancés en forçant des distributions de probabilité artificielles.
3. Risque de dérive d'indentation : L'utilisation de l'espacement (whitespace) dans TOON pour la structure introduit un risque accru d'erreurs dans les contextes longs, contrairement au JSON qui est plus robuste syntaxiquement.

5. Signification et Recommandations

L'article conclut que TOON n'est pas un remplacement universel pour JSON, mais un outil de niche pour des cas d'usage spécifiques :

• Cas d'usage recommandés pour TOON : Pipelines ETL à haut volume, traitement par lots, et données transactionnelles (factures, commandes, logs SQL) où les structures sont plates ou uniformément imbriquées.
• Cas d'usage à éviter : Structures de données complexes, arbres d'état profonds, ou configurations DOM-like. Pour ces cas, le JSON standard ou le JSON contraint reste préférable.
• Stratégie de production : Pour les solutions sensibles aux coûts et à la latence, TOON peut être viable si le schéma de données est strictement contrôlé et "aligné", permettant d'amortir le coût du prompt sur de grands volumes de données.

En résumé, bien que TOON offre un potentiel d'économie de tokens significatif pour des données massives et structurées, son adoption actuelle est limitée par le coût du prompt et sa fragilité face aux structures complexes, rendant le JSON contraint (JSO) souvent plus efficace pour les tâches simples.