Perché TOON supera gli altri formati

Se stai creando applicazioni LLM, in particolare sistemi o agenti RAG (Retrieval-Augmented Generation) che consumano set di dati di grandi dimensioni, probabilmente stai combattendo una guerra costante su due fronti: costo token e limiti della finestra di contesto.

Per anni JSON è stata la lingua franca predefinita per lo scambio di dati. È leggibile dall’uomo (per lo più) e onnipresente. Ma quando incolli un array JSON di 500 righe in un prompt, stai bruciando migliaia di token su nomi di campi ripetuti ("id":, "name":, "email":`) che portano un valore semantico pari a zero per la riga specifica.

Inserisci TOON. È un formato progettato specificamente per risolvere il problema del rapporto segnale-rumore negli ingressi LLM. Mi sono approfondito negli ultimi benchmark e i risultati sono sorprendenti: TOON non sta solo risparmiando spazio; in realtà aiuta modelli come GPT-5-nano e Gemini-2.5-flash a comprendere meglio i dati.

Analizziamo perché TOON sta battendo i pesi massimi (JSON, CSV, YAML, XML) e guardiamo i numeri grezzi.

La trappola della verbosità: JSON contro TOON

Il più grande nemico dell’efficienza dei token è la ripetizione della struttura. Diamo un'occhiata a un set di dati standard di Time-Series Analytics. In JSON, ogni singolo punto dati porta con sé il bagaglio del proprio schema.

JSON (standard) Token utilizzati nel benchmark: 22.250

Questo è un sacco di spazio sprecato. Ora guarda l'equivalente TOON. TOON definisce lo schema una volta nell'intestazione e poi passa a un layout denso in stile CSV per i valori.

TOON Token utilizzati nel benchmark: 9.120

Il risultato: una massiccia riduzione del 59,0% nell'utilizzo dei token.

Eliminando le chiavi ripetute, TOON ti consente di inserire più cronologia nella finestra di contesto del modello. Ma, cosa fondamentale, a differenza del CSV, mantiene la consapevolezza del tipo e la struttura esplicita tramite la definizione dell'intestazione "metrics[5]{...}".

Perché non utilizzare semplicemente CSV?

Questa è la controargomentazione più comune. "Se vuoi dati flat, usa semplicemente CSV."

Il problema è che i dati del mondo reale raramente sono perfettamente piatti. Il CSV si rompe completamente nel momento in cui hai strutture nidificate, elenchi all'interno di oggetti o descrizioni complesse contenenti virgole e virgolette.

Nei benchmark, in particolare nel Mixed-Structure Track (che include ordini di e-commerce e registri eventi), CSV è stato completamente escluso perché non poteva rappresentare i dati senza appiattimento con perdite.

TOON lo gestisce con garbo. Consente oggetti nidificati ottimizzando gli array. In un test su 100 repository GitHub (che contengono descrizioni di testo e metadati misti), il divario di efficienza era chiaro:

• JSON: 15.145 token

• TOON: 8.745 token (42,3% di risparmio)

Anche rispetto a JSON Compact (minimizzato), TOON ha comunque ottenuto quasi il 24% di risparmio in più. Quando paghi per milione di token, il ROI è immediato.

Precisione: il vincitore a sorpresa

Ecco la parte che mi ha sorpreso. Di solito, quando comprimi i dati, perdi chiarezza. Ti aspetteresti che LLM abbia difficoltà ad analizzare un formato più denso. I benchmark mostrano il contrario.

Attraverso 209 domande di recupero dati testate su modelli come Claude Haiku, Gemini Flash e GPT-5-nano, TOON ha raggiunto una precisione di recupero del 73,9%, rispetto al 69,7% di JSON standard.

Perché? Probabilmente si riduce al Carico cognitivo (o all'equivalente LLM).

1. Meno rumore: il modello non deve occuparsi di migliaia di token "chiave" ripetuti. I valori rilevanti sono più vicini tra loro nel meccanismo di attenzione.

2. Metadati espliciti: le intestazioni TOON includono esplicitamente il conteggio ([N]) e i nomi dei campi.

3. Consapevolezza della struttura: nei test che chiedevano informazioni sulla struttura del set di dati (ad esempio, "Quante righe ci sono?"), TOON ha raggiunto una precisione dell'88%, mentre JSON e XML sono rimasti indietro. Il conteggio esplicito nell'intestazione TOON (repositories[100]) funge da suggerimento che impedisce al modello di dover "contare" manualmente i token, cosa in cui i LLM sono notoriamente pessimi.

La fatica di XML e YAML

Dovremmo citare brevemente gli altri contendenti.

XML è il grande perdente qui. È prolisso, difficile da leggere e costoso da elaborare. Nei benchmark, XML ha utilizzato costantemente il maggior numero di token (oltre 5.000 per un set di record di dipendenti uniforme che TOON rappresentava in circa 2.700) e aveva la precisione più bassa (67,1%).

YAML funziona meglio di XML ma soffre ancora di un gonfiaggio dei token rispetto a TOON. Sebbene YAML sia ottimo per i file di configurazione umana, la sua natura sensibile agli spazi bianchi e la ripetizione dei tasti lo rendono non ottimale per il contesto di dati ad alto volume. Nel test "Ordini e-commerce", YAML ha utilizzato circa il 14% in più di token rispetto a TOON.

Quando cambiare?

I dati sono abbastanza conclusivi. Se hai a che fare con:

1. Elenchi di oggetti: Registri, cronologie delle transazioni, risultati di ricerca o cataloghi di prodotti.

2. RAG Pipelines: dove si recuperano blocchi di dati da un DB per inserirli in un prompt.

3. API ad alto volume: dove la larghezza di banda e la latenza contano.

TOON offre uno scenario "il meglio dei due mondi". Ottieni la densità di CSV con l'integrità strutturale di JSON.

Nei benchmark, GPT-5-nano ha raggiunto un'incredibile precisione del 90,9% sui dati formattati TOON. Ciò suggerisce che i modelli più nuovi e più intelligenti stanno diventando sempre più abili nell’analizzare questi formati ottimizzati, il che significa che la “penalità di leggibilità” derivante dall’allontanamento da JSON è effettivamente pari a zero per la macchina.

Se stai ancora formattando il tuo contesto RAG come JSON.stringify(data, null, 2), stai effettivamente pagando una "tassa di leggibilità" su ogni singola chiamata API. Potrebbe essere il momento di cambiare formato.