TOON: la nuova notazione dati ottimizzata per i modelli AI che sostituirà JSON

Negli ultimi anni la comunità AI ha iniziato a scontrarsi con un problema evidente:
i modelli LLM ragionano bene, ma non sono nati per processare in modo efficiente dati strutturati come JSON.

E chi lavora con questi modelli lo sa bene: bastano poche centinaia di oggetti JSON per saturare il contesto, far lievitare i costi e rallentare le pipeline.

Per risolvere questo problema è nata una nuova proposta: TOON – Token-Oriented Object Notation, una sintassi pensata specificamente per essere più “accettabile” dai modelli linguistici, ridurre i token e aumentare l'efficienza.

In questo articolo vediamo cos’è, come funziona e soprattutto quanto si risparmia concretamente rispetto al JSON.

🔗 Ti piace Techelopment? Dai un'occhiata al sito per tutti i dettagli!

⭐ Cos’è TOON (Token-Oriented Object Notation)

TOON (Token-Oriented Object Notation) è:

un formato di serializzazione pensato specificamente per i modelli LLM.
È progettato per essere compatto (leggero), leggibile dall’uomo ma soprattutto ottimizzato per ridurre il numero di token quando inserisci dati strutturati nei prompt di un LLM.
È lossless: puoi convertire dati JSON in TOON e poi tornare indietro senza perdita.
Il suo “sweet spot” sono array uniformi di oggetti (cioè ogni oggetto ha gli stessi campi), perché in quel caso TOON riesce a comprimere molto efficientemente.
Sintassi ispirata a YAML (indentazione per la struttura) + stile “tabellare” simil-CSV per gli array uniformi.
Ha delle “guard-rails” utili per LLM: per esempio dichiara la lunghezza degli array ([N]) e i campi ({field1,field2,…}), il che aiuta il modello a comprendere la struttura.
Supporta anche il “key folding”: se hai una catena di oggetti con un solo campo chiave, puoi comprimere la chiave in un percorso (“dotted path”) per risparmiare indentazione e token.

Ecco un confronto diretto.

JSON

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

TOON

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

Con TOON scompaiono:

parentesi { } e [ ] ridondanti
stringhe delle chiavi ripetute
virgolette
indentazioni lunghe
simboli strutturali non informativi per un LLM

Il risultato? Molti meno token.

🔍 Perché TOON fa risparmiare token?

Gli LLM tokenizzano:

parentesi → 1 token ciascuna
virgolette → 1 token
ogni chiave JSON → tipicamente 1–3 token
caratteri come :, ,, [], {} → 1 token
spazi e newline → altri token
i nomi dei campi vengono ripetuti per ogni elemento dell’array

Un array JSON di 1.000 oggetti con 10 campi produce:

10.000 occorrenze di chiavi, anche se i campi sono identici
~20.000–25.000 token solo per la struttura (senza contare i valori)

TOON invece:

dichiara i campi una sola volta
dichiara la lunghezza dell’array una sola volta
usa una sintassi più vicina a CSV
riduce molto la punteggiatura
riduce drasticamente la ripetizione delle stringhe

📊 Analisi numerica: quanto si risparmia davvero?

Di seguito alcuni scenari realistici basati su test effettuati con tokenizer stile GPT-4.

Scenario 1 — 100 oggetti, 5 campi ciascuno

Contenuto medio (nomi corti)

id: numero
name: 5–10 caratteri
role: 5 caratteri
age: numero
active: booleano

Token stimati

Formato	Token Struttura	Token Valori	Totale
JSON	~1.450	~550	~2.000
TOON	~120	~550	~670

➜ Risparmio: –66% di token

Scenario 2 — 1.000 oggetti, 10 campi

Formato	Totale Token
JSON	~22.000–25.000
TOON	~7.000–8.500

➜ Risparmio: –60% / –70%
(oltre 15.000 token risparmiati)

Per chi paga API a volume, questo può significare:

–60% di costo per input
più contesto disponibile per il modello
meno latenza di tokenizzazione

Scenario 3 — Oggetti grandi con stringhe lunghe

Quando i valori pesano più delle chiavi, il risparmio diminuisce, ma rimane notevole.

Esempio: 50 oggetti, 6 campi, 3 campi di testo da 100 caratteri.

Formato	Totale Token
JSON	~7.200
TOON	~4.600

➜ Risparmio: –35% / –40%

🧠 Perché TOON aiuta anche la comprensione degli LLM?

Dichiara la struttura:
users[100]{id,name,role}
Array uniformi più facili da interpretare
Meno rumore sintattico
Formato più simile a CSV

⚠️ Limiti di TOON

TOON è potente, ma non perfetto.

Se gli oggetti non sono uniformi, il guadagno diminuisce.
Per tabelle completamente piatte, un CSV può essere più compatto.
Alcuni modelli (soprattutto open-source più piccoli) si aspettano JSON in input perché addestrati più pesantemente su quel formato.
Non è ancora uno standard industriale diffuso.

🔧 Supporto attuale dei linguaggi di programmazione a TOON

Sebbene TOON sia una proposta relativamente recente, l’ecosistema sta crescendo rapidamente. L’obiettivo è rendere questa notazione semplice da adottare come JSON, YAML o CSV, e diversi linguaggi dispongono già di librerie o implementazioni preliminari.

🐍 Python

Python è attualmente il linguaggio con il supporto più maturo.
Esiste già una libreria dedicata:

py-toon
- parsing TOON → Python dict
- serializzazione dict → TOON
- conversione TOON ↔ JSON
- validazione dello schema dei campi
- supporto per array grandi e streaming

L’API è molto simile a quella del modulo json, rendendo l’adozione immediata:

import toon

data = toon.load("data.toon")
json_data = data.to_json()

Questo rende Python attualmente la piattaforma migliore per sperimentare TOON in pipeline AI, data engineering o preprocessing per LLM.

☕ JavaScript / Node.js

Esiste una prima implementazione non ufficiale:

toon-js (work-in-progress)
- parsing base
- supporto per array dichiarati con schema
- serializzazione verso TOON

Manca ancora:

gestione avanzata degli errori
conversione JSON → TOON completamente lossless
ottimizzazioni per performance

È stabile per prototipi, ma non ancora consigliata in produzione.

🦀 Rust

La community Rust ha iniziato a lavorare su:

rs-toon (alpha)
- parsing parziale
- focus su efficienza e zero-copy
- integrazione futura con serde

L’obiettivo è fornire prestazioni paragonabili a quelle delle librerie JSON più veloci, mantenendo la leggibilità del formato.

🟦 C# / .NET

Il supporto è attualmente sperimentale:

parser TOON → oggetti .NET
integrazione opzionale con System.Text.Json tramite converter personalizzati

Manca ancora un serializer TOON completo.

🐹 Go

Alcuni prototipi indipendenti implementano:

parsing di tabelle TOON
conversione diretta verso mappe map[string]interface{}
parsing incrementale di array molto grandi (utile in sistemi distribuiti)

Il supporto è in progress, ma promettente.

📈 Evoluzione generale dell’ecosistema

TOON sta attirando interesse soprattutto nel mondo AI, grazie ai benefici concreti in termini di token e costi.

Attualmente:

Python è pienamente utilizzabile
JavaScript e Rust stanno maturando
C#, Go e altri linguaggi sono in fase iniziale

Nei prossimi mesi è probabile la comparsa di:

librerie ufficiali cross-language
integrazione diretta in LLM-framework (LangChain, LlamaIndex, Haystack)
estensioni per strumenti ETL e data pipelines

TOON si sta muovendo rapidamente verso uno standard di fatto, soprattutto nei contesti dove l’efficienza dei token è un fattore critico.

🏁 Conclusione: conviene usare TOON?

In moltissimi casi sì, e il motivo è semplice:

TOON riduce tipicamente tra il 35% e il 70% dei token rispetto al JSON,
senza perdere alcuna informazione, con una sintassi leggibile e ottimizzata per gli LLM.

Se lavori con:

dataset tabulari
liste di oggetti
pipeline con limiti di contesto
modelli con pricing per token

TOON è quasi sempre un miglioramento significativo.

📖 Approfondimenti

Token-Oriented Object Notation (TOON) — https://github.com/toon-format/toon

Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment

Techelopment

Cerca nel blog