La recherche en IA te passionne ?
Les papers et avancées qui comptent, expliqués simplement, chaque soir. Gratuit.
Inclus dès l'inscription : notre sélection des meilleurs guides & comparatifs IA.
Choisis ton rythme
Gratuit · Pas de spam · Désabonnement en 1 clic
Depuis des années, JSON s'est imposé comme le langage incontournable pour les API, les intégrations et la communication entre applications. Sa simplicité et sa robustesse en ont fait un outil privilégié par les développeurs. Cependant, avec l'émergence des Large Language Models (LLMs), l'utilisation de JSON révèle un coût caché, notamment en termes de gestion des tokens.
Les LLMs traitent le JSON différemment des applications traditionnelles. Chaque élément de syntaxe, chaque clé répétée et chaque structure imbriquée consomme des tokens, ce qui peut rapidement saturer la fenêtre de contexte des modèles et augmenter les coûts d'opération. Pour pallier ce problème, une nouvelle méthode, le TOON (Token-Oriented Object Notation), a été introduite.
TOON se présente comme une solution plus efficace pour gérer les tokens tout en maintenant la même structure de données que JSON. En utilisant TOON, les noms de champs sont déclarés une seule fois, les valeurs sont organisées en lignes, et la structure reste compréhensible pour le modèle. Cette approche est particulièrement avantageuse pour les LLMs traitant des schémas uniformes avec des enregistrements répétés, comme dans les résultats de récupération RAG ou les sorties d'outils d'agents.
L'article met en avant des exemples concrets de conversion de JSON en TOON, illustrant comment cette méthode peut être intégrée dans les prompts pour les LLMs. TOON offre ainsi une optimisation des tokens sans compromettre la validation des sorties, qui peut continuer à utiliser JSON.
Cependant, il est crucial de noter que TOON ne doit pas remplacer JSON dans tous les contextes. Il est recommandé de l'utiliser uniquement là où cela est pertinent, en évaluant soigneusement les performances par rapport à JSON. Les meilleures pratiques incluent la validation des sorties, la considération de la fiabilité des outils et modèles, et la gestion des cas particuliers. TOON doit être perçu comme une couche d'optimisation pour la représentation du contexte, plutôt qu'un substitut au contrat d'entreprise.
