TOON réduit le gaspillage de tokens dans les modèles LLM

JSON et le gaspillage de tokens dans les modèles LLM

Le format JSON est largement apprécié pour sa simplicité et son efficacité dans les API, le stockage et la logique applicative. Cependant, lorsqu'il s'agit des pipelines de modèles de langage de grande taille (LLM), JSON peut devenir un fardeau. En effet, il génère un surcoût en tokens qui n'apporte pas de valeur ajoutée significative au modèle. Les accolades, guillemets, virgules et noms de champs répétés à chaque ligne sont autant d'éléments qui alourdissent inutilement les prompts des LLM.

Pour illustrer ce problème, imaginons que vous envoyez 100 tickets de support ou enregistrements d'utilisateur à un modèle. Chaque objet contient les mêmes noms de champs, ce qui entraîne une répétition excessive. C'est ici que TOON, ou Token-Oriented Object Notation, entre en jeu. Ce format plus récent est conçu pour conserver le même modèle de données que JSON tout en utilisant moins de tokens. Il fournit également aux modèles des indices structurels plus clairs.

TOON : une alternative compacte et efficace

TOON se présente comme une représentation compacte et sans perte de JSON, spécialement adaptée pour l'entrée des LLM. La documentation officielle décrit TOON comme particulièrement efficace pour les tableaux uniformes d'objets. En d'autres termes, TOON permet de déclarer les champs une seule fois, puis de diffuser les valeurs des lignes sous une forme tabulaire compacte. Par exemple, au lieu de répéter les champs pour chaque utilisateur, TOON les déclare une fois, réduisant ainsi la redondance.

Voici un exemple concret :

{ "id": 1, "name": "Alice", "role": "admin" },
{ "id": 2, "name": "Bob", "role": "user" },
{ "id": 3, "name": "Charlie", "role": "user" }

Avec TOON, cela devient :

users[3]{id,name,role}:

La structure reste claire, mais les clés répétées ont disparu. C'est là que TOON tire la majeure partie de sa valeur.

Quand TOON est-il le plus utile ?

TOON est un format de sérialisation qui peut représenter des objets, des tableaux, des chaînes, des nombres, des booléens et des valeurs nulles. Il est conçu pour être sans perte par rapport à JSON, ce qui signifie que vous pouvez convertir JSON en TOON et vice versa sans perdre d'informations. Cependant, il n'est pas nécessaire de remplacer JSON dans votre application. Une meilleure approche consiste à conserver JSON dans votre backend, vos API et votre stockage, puis à le convertir en TOON uniquement lorsque vous êtes sur le point d'envoyer des données structurées dans un LLM.

TOON est particulièrement utile lorsque votre prompt contient des enregistrements structurés répétés avec les mêmes champs. De bons exemples incluent les tickets de support récupérés, les lignes de catalogue, les enregistrements d'analytique, les sorties d'outils, les entrées CRM ou les instantanés de mémoire pour les systèmes d'agents. Cependant, si votre structure est profondément imbriquée, très irrégulière, purement plate ou très petite, les avantages peuvent diminuer ou disparaître.

Comment commencer avec TOON

Étape 1 : Installer l'interface en ligne de commande TOON

La manière la plus simple d'essayer TOON est avec l'interface en ligne de commande (CLI) officielle du projet TOON. Le site TOON renvoie directement à sa CLI, et le dépôt principal présente le format comme faisant partie d'un écosystème plus large de SDK et d'outils.

Pour installer le package, utilisez la commande suivante :

npm install -g @toon-format/cli

Étape 2 : Convertir un fichier JSON en TOON

Commencez par créer un dossier, puis exécutez la commande suivante pour créer le fichier JSON :

{ "id": 1, "name": "Alice", "role": "admin" },
{ "id": 2, "name": "Bob", "role": "user" },
{ "id": 3, "name": "Charlie", "role": "user" }

Ensuite, utilisez cette commande pour convertir le fichier JSON en TOON :

npx @toon-format/cli users.json -o users.toon

Vous obtiendrez un résultat compact similaire à ceci :

[3]{id,name,role}:

C'est le modèle de base de TOON : déclarer la forme une fois, puis lister les valeurs ligne par ligne. Cela s'aligne avec l'objectif de conception officiel des tableaux tabulaires pour des objets uniformes.

Étape 3 : Utiliser TOON comme entrée de modèle

Le meilleur endroit pour utiliser TOON est du côté de l'entrée de votre pipeline. Au lieu de coller un gros blob JSON dans un prompt, passez la version TOON et gardez l'instruction simple.

Les données suivantes sont au format TOON :

users[3]{id,name,role}:

Résumez les rôles des utilisateurs et signalez tout ce qui est inhabituel.

Cela fonctionne bien car TOON est conçu pour aider le modèle à lire une structure répétée avec moins de surcharge. C'est également ainsi que le projet officiel cadre ses benchmarks : comme un test de compréhension à travers différents formats d'entrée structurés.

Étape 4 : Conserver JSON pour les sorties

C'est l'une des décisions pratiques les plus importantes. TOON est très utile pour l'entrée, mais JSON est généralement le meilleur choix pour la sortie lorsque un autre système doit analyser la réponse du modèle. Cela est dû au fait que JSON bénéficie d'un support d'outils beaucoup plus solide, et les API modernes peuvent imposer une sortie JSON structurée avec des schémas.

En pratique, le modèle le plus sûr est :

• JSON dans votre application.
• TOON pour un contexte de prompt structuré important.
• JSON à nouveau pour les réponses de modèle analysables par machine.

Cela vous offre une efficacité du côté de l'entrée et une fiabilité du côté de la sortie.

Étape 5 : Évaluer dans votre propre pipeline

Ne changez pas de format uniquement en fonction de la mode.

Réalisez un petit benchmark dans votre propre flux de travail :

• Comptez les tokens d'entrée pour JSON.
• Comptez les tokens d'entrée pour TOON.
• Comparez la latence.
• Comparez la qualité des réponses.
• Comparez le coût total.

Le projet TOON officiel positionne les économies de tokens comme l'un des principaux avantages, et la couverture par des tiers répète ces affirmations, mais les discussions communautaires montrent également que les résultats dépendent fortement de la forme des données. C'est pourquoi la meilleure question n'est pas "TOON est-il meilleur que JSON ?"

La meilleure question est : "TOON est-il meilleur pour cette étape spécifique du LLM ?"

Conclusion

TOON n'est pas quelque chose que vous devez utiliser partout.

C'est une optimisation ciblée pour un problème spécifique : le gaspillage de tokens sur une structure JSON répétée à l'intérieur des prompts LLM. Si votre pipeline passe beaucoup d'enregistrements structurés répétés dans un modèle, TOON vaut la peine d'être testé. Si vos charges utiles sont petites, irrégulières ou fortement imbriquées, JSON peut encore être le meilleur choix.

La manière la plus intelligente de l'adopter est simple : gardez JSON là où JSON fonctionne déjà bien, utilisez TOON lorsque vous emballez de grandes entrées structurées dans des prompts, et évaluez les résultats sur vos propres tâches avant de vous engager à l'utiliser.