Nasce TOON

Quando JSON è troppo:

Indice

Quando JSON è troppo: Nasce TOON

Introduzione

Cosa differenzia TOON

JSON vs TOON

Perché TOON?

Meno Token e più precisione

Quando utilizzare TOON

Conclusione

Introduzione

Chi opera regolarmente con i Large Language Models (LLM) conosce un’importante verità: i token sono la valuta fondamentale. Ogni chiamata API, ogni prompt e ogni risposta hanno un costo direttamente legato alla quantità di token trasmessi e ricevuti. Per questo motivo, l’efficienza nella rappresentazione dei dati rappresenta un fattore strategico.

Da anni JSON è lo standard praticamente universale per lo scambio di informazioni tra sistemi. È versatile, leggibile e onnipresente. Tuttavia, è anche piuttosto ridondante: parentesi graffe, virgolette e, soprattutto chiavi che si ripetono in ogni elemento lo rendono poco parsimonioso in termini di token.
Esisterebbe un modo più compatto per rappresentare gli stessi dati senza comprometterne l’integrità? Da questa esigenza nasce TOON (Token-Oriented Object Notation), una soluzione concepita per ottimizzare la comunicazione strutturata nei contesti che coinvolgono modelli linguistici di grandi dimensioni.

Cosa differenzia TOON e perché è stato creato

TOON non intende rimpiazzare JSON, ma mira ad alleggerire e migliorare l’efficienza nella comunicazione tra applicazioni e LLM. Si tratta di un formato di serializzazione senza perdita di dati, ideato per ridurre il numero di token necessari a descrivere un dataset, mantenendo una struttura chiara e leggibile. L’obiettivo è eliminare le ridondanze, rendendo i dati più snelli da elaborare per un LLM, riducendo così costi ed errori di interpretazione.

JSON vs TOON

{
  "users": [
    { "id": 1, "name": "Alice", "role": "admin" },
    { "id": 2, "name": "Bob", "role": "user" }
  ]
}

Questo formato è leggibile ma verboso: le chiavi “id”, “name” e “role” vengono ripetute per ogni elemento all’interno dell’array. Su dataset piccoli è trascurabile, ma su migliaia di record l’impatto sul consumo di token diventa rilevante.
TOON, invece, propone la medesima struttura in modo molto più compatto:

users[2]{id,name,role}:  
1,Alice,admin  
2,Bob,user

La differenza è lampante. TOON applica il principio DRY (Don’t Repeat Yourself), combinando la chiarezza gerarchica di YAML con l’efficienza tabellare del CSV. È particolarmente efficace in contesti con array di oggetti uniformi, come dataset strutturati o log applicativi.

Perché TOON?

Il vero potenziale di TOON va oltre la mera riduzione dei token; la sua forza si manifesta nel fornire una chiara struttura che semplifica il lavoro dei modelli linguistici. Analizzando l’intestazione:

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

Lunghezza esplicita: il dichiarativo [2] specifica subito che l’array contiene due elementi, permettendo al modello di sapere esattamente cosa aspettarsi ed evitando errori come parsing incompleti o dati inventati.

Schema chiaro: lo schema `{id,name,role}` esplicita la struttura dei dati, eliminando la necessità per l’LLM di dedurre o indovinare disposizioni astratte. Questo approccio aumenta l’affidabilità e sposta l’elaborazione dal “capire la struttura” al “completare la struttura”.

Meno token e maggiore precisione

Test comparativi mostrano che TOON offre vantaggi tangibili:
– Efficienza: consuma fra il 30% e il 60% di token in meno rispetto a JSON.
– Accuratezza: durante esperimenti di recupero dati, gli LLM hanno raggiunto il 73,9% di precisione con TOON contro il 69,7% con JSON.
Ciò si traduce in un risparmio sui costi e una maggiore affidabilità nei risultati. Offrendo un formato semplificato ma dettagliato, si riducono gli errori e si migliorano coerenza e comprensione delle risposte.

Quando utilizzare TOON (e quando evitarlo)

Come ogni strumento tecnologico, TOON raggiunge il massimo delle sue potenzialità se impiegato in contesti adatti alle sue caratteristiche distintive. Basandoci sulle indicazioni fornite nella documentazione ufficiale, ecco alcuni ambiti di utilizzo consigliati, insieme a quelli meno indicati:
– I casi in cui è utile utilizzare TOON includono la gestione di grandi array di dati composti da oggetti uniformi. Un esempio pratico potrebbe essere l’organizzazione di righe di database, la raccolta di dati provenienti dai log applicativi o la creazione e la gestione di cataloghi per piattaforme e-commerce. In tali scenari, TOON si rivela un alleato prezioso per ottimizzare i processi e garantire una comunicazione fluida tra sistemi.
– Al contrario, è meglio evitare TOON in situazioni dove i dati siano strutturati in modo annidato oppure particolarmente dinamico, con frequenti cambiamenti dello schema. Inoltre, per rappresentare dati tabellari semplici che possono essere gestiti facilmente attraverso file CSV tradizionali, il suo utilizzo non sarebbe necessario né vantaggioso.

Conclusione

Riassumendo, TOON non è stato progettato per eseguire una sostituzione generalizzata dei formati esistenti; il suo scopo principale è quello di ottimizzare comunicazioni strutturate, soprattutto nel contesto dell’interazione tra applicazioni e modelli linguistici avanzati.
Un approfondimento sulla sua versione Spec v2.0 mette in evidenza come TOON si configuri come una soluzione intelligente e ben progettata per risolvere specifici problemi legati all’utilizzo del formato JSON. Non tenta di reinventare ciò che già funziona; il suo obiettivo è affrontare una problematica precisa, ovvero la ridondanza tipica degli elementi JSON, proponendo un approccio più efficiente e preciso in termini di economia dei token e chiarezza semantica.

A cura di Martina D’Angelo