TOON: Un Formato Dati Ottimizzato per i Modelli AI - YourDigitalWeb

Se utilizzi modelli linguistici di grandi dimensioni (LLM) come GPT-4, Claude o Google Gemini per elaborare dati strutturati, è molto probabile che oggi tu stia usando JSON come formato di input e output. JSON è lo standard de facto per lo scambio dati tra sistemi grazie alla sua semplicità, alla diffusione enorme e al supporto nativo praticamente ovunque.

Nel contesto dei prompt per l’AI, però, JSON può diventare sorprendentemente inefficiente: ogni parentesi graffa {}, ogni quadra [], ogni virgoletta " e ogni chiave ripetuta conta come token quando viene inviato a un LLM. In un prompt corposo, questi caratteri di sintassi “invisibili” possono far lievitare il conteggio di token (e quindi i costi) senza aggiungere reale informazione. Da qui nasce l’idea di un formato più snello per dialogare con i modelli.

Questo bisogno ha portato alla creazione di TOON (Token-Oriented Object Notation), un nuovo formato dati open-source progettato apposta per i modelli AI. Presentato nell’ottobre 2025, TOON ha guadagnato popolarità rapidissima grazie alla promessa di ridurre del 30–60% i token necessari nei prompt rispetto all’equivalente JSON, mantenendo però la stessa struttura informativa.

Cos’è TOON e perché è nato

TOON è un formato di serializzazione dei dati compatto e leggibile (sia per umani che per modelli) che rappresenta le stesse strutture di JSON ma con una sintassi ottimizzata per minimizzare i token.

In altre parole, TOON conserva esattamente le stesse informazioni di un JSON equivalente (è lossless, convertibile avanti e indietro senza perdite), ma elimina punteggiatura superflua e ridondanza sintattica che pesano sui prompt per LLM. Un modo semplice per descriverlo è: “come JSON, ma riscritto con la grammatica preferita dai modelli AI”.

Formati come JSON, XML o YAML non sono nati per interagire con modelli linguistici, ma per far comunicare sistemi software. Di conseguenza includono molte strutture sintattiche ridondanti (parentesi, virgole, virgolette, chiavi ripetute) utili ai parser tradizionali ma non davvero necessarie a un LLM.

Un modello AI “vede” il testo come una sequenza di token e non trae benefici particolari da caratteri di formattazione: se in un JSON hai 100 oggetti, ciascuno con 10 campi, i nomi di quei campi verranno ripetuti 100 volte. All’aumentare della dimensione dei prompt, questa inefficienza diventa un costo nascosto significativo.

TOON nasce per risolvere proprio questo problema, con alcune idee chiave:

• Niente parentesi e virgole: TOON elimina completamente {}, [] e molte virgole separatrici, sostituendole con rientri (indentazione) e una sintassi tabellare.

• Niente doppi apici per le chiavi: i nomi dei campi non sono racchiusi tra virgolette, riducendo ulteriormente la verbosità.

• Indentazione gerarchica: come in YAML, i rientri definiscono la struttura annidata, al posto delle parentesi graffe.

• Liste in formato tabellare: gli array di oggetti assumono una forma “a tabella”: si dichiara una sola volta la lista dei campi (l’intestazione) e poi si elencano i valori riga per riga. Questo elimina ripetizioni inutili.

• Marker di lunghezza espliciti: ogni array dichiara in apertura quanti elementi contiene (es. [10]), così il modello non deve dedurre o contare il numero di elementi.

• Conversione bidirezionale: qualunque JSON valido può essere convertito in TOON e viceversa senza perdita di informazioni, fungendo da “traduttore” per i dati da inviare ai modelli (e per leggere le risposte).

Esempio pratico: JSON vs TOON a confronto

Per vedere la differenza in pratica, osserviamo un semplice esempio di dati.

JSON classico
Supponiamo di avere un oggetto con una lista di utenti:

{
"utenti": [
{ "id": 1, "nome": "Alice", "ruolo": "admin" },
{ "id": 2, "nome": "Bob", "ruolo": "user" }
]
}
TOON equivalente
Gli stessi dati vengono scritti in TOON così:

utenti[2]{id,nome,ruolo}:
1,Alice,admin
2,Bob,user


L’oggetto utenti dichiara subito di contenere [2] elementi e definisce, nella testata {id,nome,ruolo}, i campi validi per tutti. Nelle righe successive compaiono soltanto i valori, nell’ordine specificato.

Non ci sono parentesi graffe o quadre, né virgolette attorno alle chiavi. Il significato informativo è identico, ma la versione TOON è composta da molti meno simboli e, in questo caso concreto, richiede meno della metà dei token rispetto al JSON tradizionale.

TOON vs. JSON:

Vantaggi e caratteristiche di TOON

Implementando le idee sopra, TOON offre una serie di vantaggi concreti per chi lavora con i modelli AI:

• Riduzione del numero di token
  È il beneficio più evidente. Nella pratica, TOON permette di utilizzare tipicamente dal 30% al 60% di token in meno rispetto al JSON equivalente. In benchmark su dataset ampi e omogenei, i risparmi sono consistenti: ad esempio, per 10.000 record utente, TOON può richiedere circa 4.500 token per la sintassi contro i ~10.000 di un JSON strutturato in modo classico. Meno token significa meno costi e risposte più rapide.

• Leggibilità per umani e AI
  TOON mantiene una struttura chiara. La sintassi indentata e la forma tabellare facilitano la scansione visiva. Per il modello, l’input è più facile da interpretare perché privo di “rumore” sintattico; ogni token presente è più informativo. In diversi test è emerso che TOON può persino migliorare leggermente la precisione con cui l’AI estrae o riassume informazioni rispetto all’equivalente JSON.

• Meno errori di parsing
  Dichiarando esplicitamente lo schema e la lunghezza delle liste, TOON fornisce all’LLM delle guide rigide e prevedibili. Il modello sa quali campi includere e quanti elementi attendersi, cosa che riduce la probabilità di output malformati (campi mancanti, sintassi rotta, righe incomplete). Questo è particolarmente utile quando si chiede all’AI di restituire dati strutturati che devono poi essere processati automaticamente dal tuo codice.

• Compatibilità e conversione semplice
  Adottare TOON non significa abbandonare JSON. Puoi continuare a utilizzare JSON in tutta la tua applicazione (API, database, file di configurazione) e semplicemente convertirlo in TOON al momento di inviarlo al modello, per poi decodificare di nuovo in JSON l’eventuale risposta.
  TOON supporta gli stessi tipi di dati base di JSON (stringhe, numeri, boolean, null) e le stesse strutture annidate. Dove possibile comprime in formato tabellare; dove non è possibile, la struttura ricorda comunque YAML mantenendo chiarezza e compatibilità.

In sintesi, TOON non sostituisce JSON in tutti gli ambiti: JSON resta insostituibile per configurazioni complesse, API e scambio dati tra sistemi. TOON va visto come uno strumento specializzato, da usare quando il tuo interlocutore è un modello AI e il costo/token conta.

Quando utilizzare TOON

TOON dà il meglio di sé in scenari con dati strutturati omogenei, tipo tabellare, non troppo annidati. Alcuni casi d’uso tipici:

• Liste uniformi “tipo Excel”
  Se i tuoi dati assomigliano a una tabella con righe simili (elenco utenti, catalogo prodotti, registro di log, lista ordini, inventario, ecc.), TOON è particolarmente efficace. Eviti di ripetere per ogni elemento gli stessi nomi di campo, dichiarando l’header una sola volta.

• Prompt con elenchi o tabelle
  Se devi passare a un LLM una lista di elementi con struttura fissa per farci analisi, filtro, clustering o riassunti, TOON ti consente di includere nel contesto molti più elementi a parità di token. Puoi, ad esempio, far leggere al modello un catalogo prodotti, un dataset di recensioni o un log di eventi in forma compatta.

• Dataset omogenei di grandi dimensioni
  Per attività di training, test o valutazione su LLM con molti esempi strutturati (prompt tabellari, Q&A su dati, ecc.), TOON permette di iniettare nel modello più esempi per ogni finestra di contesto. Più il dataset è grande e regolare, più i benefici diventano significativi.

In breve, se i tuoi dati assomigliano a un foglio di calcolo, TOON è probabilmente la scelta giusta.

Quando evitare TOON

TOON non è sempre la soluzione ottimale. Ci sono casi in cui è meglio rimanere con JSON:

• • Dati profondamente annidati
    Se la struttura è gerarchica a molti livelli (un “albero di Natale” con molti sotto-oggetti e sotto-liste), TOON può diventare meno chiaro e persino consumare più token del JSON, perché non può sfruttare bene la modalità tabellare.

  • Strutture non uniformi o molto eterogenee