Token-Oriented Object Notation vs JSON: A Benchmark of Plain and Constrained Decoding Generation

Lo studio dimostra che, sebbene TOON offra un potenziale risparmio di token significativo per strutture complesse, il suo vantaggio è spesso annullato dall'overhead del prompt e che la generazione JSON standard, anche senza vincoli, mantiene attualmente la migliore accuratezza e un rapporto efficienza-affidabilità superiore rispetto all'apprendimento in contesto one-shot di TOON.

L'essenziale

Immagina che i Modelli di Intelligenza Artificiale (LLM) siano come cuochi stellati molto bravi, ma che hanno un problema: quando devono scrivere una ricetta complessa (i dati strutturati), tendono a usare troppe parole o a sbagliare la punteggiatura, e questo costa caro (in termini di tempo e denaro).

Il paper di Ivan Matveev è come un test di cucina per vedere quale "linguaggio" è meglio usare per dare ordini a questi cuochi.

Ecco i tre protagonisti della gara:

1. I Protagonisti della Gara

• JSON (Il Classico): È come la ricetta scritta nel modo tradizionale, con parentesi graffe {} e virgole. È lo standard mondiale. I cuochi lo conoscono a memoria perché l'hanno imparato a scuola (durante l'addestramento).
• JSON-SO (Il Classico con il "Grembiule Magico"): È lo stesso JSON, ma il cuoco indossa un grembiule speciale (decodifica vincolata) che gli impedisce fisicamente di scrivere una virgola sbagliata o di dimenticare una parentesi. Se prova a sbagliare, il grembiule lo blocca.
• TOON (Il Nuovo Linguaggio): È un nuovo formato inventato di recente. Immagina di dire al cuoco: "Non usare le parentesi graffe, usa solo due spazi per indentare e scrivi le liste in questo modo specifico". È molto più breve da scrivere (risparmia "inchiostro"), ma il cuoco non lo conosce affatto. Per farlo funzionare, devi spiegarglielo molto bene all'inizio (il "prompt").

2. La Gara: Cosa è successo?

Gli scienziati hanno fatto cucinare ai cuochi quattro tipi di piatti:

1. Utenti: Una lista semplice (come un elenco telefonico).
2. Ordini: Una ricetta con ingredienti e quantità (struttura un po' più complessa).
3. Fatture: Calcoli e totali.
4. Aziende: Una struttura molto profonda, come un albero genealogico con molti rami (padre, figlio, nipote, zio...).

Ecco le scoperte principali, spiegate con metafore:

A. Il "Costo dell'Introduzione" (La Tassa del Prompt)

Per far usare TOON al cuoco, devi spiegargli le regole all'inizio. È come dover scrivere un intero manuale di istruzioni prima di fargli cucinare un uovo sodo.

• Risultato: Per compiti piccoli (come una lista di utenti), il tempo speso a spiegare le regole di TOON è più lungo del tempo risparmiato scrivendo la ricetta in modo breve. JSON vince perché non serve spiegarlo.
• L'analogia: Se devi inviare un messaggio breve, è meglio usare la lingua che tutti conoscono (JSON) piuttosto che spiegare prima una nuova lingua (TOON) solo per scrivere due righe.

B. Il "Grembiule Magico" (JSON-SO)

Per i cuochi meno esperti (modelli piccoli), il Grembiule Magico è salvifico. Senza di esso, sbagliano tutto. Con il grembiule, riescono a cucinare bene.

• Il rovescio della medaglia: Per i cuochi geni (modelli molto grandi e intelligenti), il grembiule a volte li infastidisce. Li costringe a pensare in modo rigido, impedendo loro di usare la loro creatività naturale. A volte, questo li fa iniziare male, anche se poi riescono a recuperare dopo qualche correzione.

C. Il "Punto Debole" di TOON (L'Albero Genealogico)

TOON funziona benissimo quando i dati sono piatti e ordinati (come una lista della spesa o una fattura). È come se fosse un treno su binari dritti: veloce ed efficiente.

• Il problema: Quando i dati sono complessi e profondi (come l'azienda con molti livelli), TOON si perde. È come se il treno cercasse di correre su una montagna piena di curve: i treni (i dati) si sballano, le regole di indentazione si confondono e il cuoco impazzisce.
• Risultato: Per strutture complesse, TOON fallisce quasi sempre al primo tentativo e richiede molte correzioni, diventando costoso.

3. Le Conclusioni in Pillole

1. Per compiti semplici e ripetitivi (Fatture, Ordini, Liste): TOON ha un grande potenziale. Se devi inviare migliaia di fatture, il risparmio di "inchiostro" (token) alla fine ripaga il costo di spiegare le regole all'inizio. È come comprare un'auto elettrica: costa di più da caricare all'inizio, ma se guidi tantissimo, risparmi benzina.
2. Per compiti complessi (Strutture profonde): Non usare TOON. È come cercare di costruire un grattacielo con i LEGO: è meglio usare i mattoni classici (JSON) che sono più robusti e prevedibili.
3. Il "Grembiule" (JSON-SO) è utile per i principianti: Se usi modelli di intelligenza artificiale meno potenti, il vincolo grammaticale li aiuta a non sbagliare, anche se per i modelli più intelligenti a volte è un freno a mano.

In sintesi: Cosa dobbiamo fare?

• Se devi processare migliaia di dati semplici (come estratti conto o log di sistema), prova TOON: potrebbe farti risparmiare molto denaro.
• Se devi gestire strutture complesse o dati che cambiano molto, rimani su JSON (magari con il "grembiule" se il modello è piccolo).
• Non aspettarti che TOON sia la soluzione magica per tutto: è uno strumento specializzato, non un coltellino svizzero.

Il paper ci dice che l'efficienza non è solo "scrivere meno", ma anche "capire meglio". A volte, scrivere di più (con le istruzioni giuste) è meglio che cercare di risparmiare parole su un formato che il cuoco non conosce ancora bene.

Sommario tecnico

1. Il Problema

Con l'adozione diffusa dei Large Language Models (LLM) per la generazione di dati strutturati, il formato JSON rimane lo standard de facto. Tuttavia, JSON è noto per essere inefficiente in termini di token (a causa di parentesi, virgole e chiavi ripetute), aumentando costi e latenza.
TOON (Token-Oriented Object Notation) è stato proposto come un formato di serializzazione alternativo, progettato specificamente per ridurre drasticamente il consumo di token quando i dati vengono passati agli LLM. Sebbene TOON mostri buone capacità di comprensione da parte degli LLM, mancava una valutazione rigorosa sulla sua capacità di generazione rispetto al JSON standard e alle tecniche di decodifica vincolata (constrained decoding).
Il paper si pone l'obiettivo di determinare se i risparmi nei token del formato TOON possano compensare l'overhead del prompt necessario per insegnare il formato al modello (il "prompt tax") e se la sua efficacia vari in base alla complessità strutturale dei dati.

2. Metodologia

Gli autori hanno condotto un benchmark comparativo su 21 modelli LLM diversi (inclusi serie Qwen, Llama, Hermes, DeepSeek, Gemma) utilizzando l'API Nebius.

Formati confrontati:

1. JSON (J): Generazione JSON standard (plain generation).
2. JSON-SO (JSO): Generazione JSON con "Structured Output" (decodifica vincolata/constrained decoding), dove il motore di inferenza (es. xgrammar) forza la validità sintattica bloccando i token non conformi allo schema.
3. TOON (T): Generazione nel formato TOON tramite apprendimento one-shot in-context (senza esempi specifici per caso, ma con regole universali).

Design del Benchmark:

• Casi di Test: Quattro scenari con complessità crescente:
  • users: Struttura tabulare semplice.
  • order: Struttura annidata con array.
  • company: Gerarchia profonda (dipartimenti/impiegati).
  • invoice: Articoli e totali.
• Metriche:
  • One-shot accuracy: Percentuale di output corretti al primo tentativo.
  • Final accuracy: Percentuale di successo dopo fino a 3 cicli di riparazione (repair loops) in caso di errori.
  • Token budget: Totale token (prompt + completamento) consumati per ottenere un risultato corretto.
• Validazione: Tutti gli output sono stati convertiti in JSON canonico e validati tramite Pydantic contro un "gold standard".

3. Risultati Chiave

A. Accuratezza e Affidabilità

• JSON Standard (Plain): Ha mostrato le migliori prestazioni generali in termini di accuratezza one-shot e finale, superando spesso la decodifica vincolata.
• JSON-SO (Vincolato): Ha agito come una "rete di sicurezza" per i modelli più piccoli o meno capaci (es. Qwen2.5-Coder-7B), migliorando drasticamente l'accuratezza (da 0% a 75%) e riducendo i token. Tuttavia, per i modelli più grandi e capaci (es. Hermes-4-405B), i vincoli rigidi hanno degradato le prestazioni iniziali (da 92.5% a 35%), costringendo il modello su percorsi di token subottimali, sebbene si sia ripreso dopo i cicli di riparazione.
• TOON: Ha mostrato un'accuratezza promettente ma fortemente dipendente dalla struttura dei dati.
  • Per dati "allineati" (tabellari, documenti transazionali come ordini e fatture), TOON ha raggiunto un'accuratezza one-shot del 54.9% (media), con picchi del 78.6% per gli ordini.
  • Per dati "non allineati" (gerarchie profonde come il caso company), l'accuratezza one-shot è crollata allo 0%, richiedendo cicli di riparazione per raggiungere un successo finale (~48.6%).

B. Efficienza dei Token e "Prompt Tax"

• Il costo del Prompt: TOON richiede un prompt di istruzione sostanziale per definire la sintassi. Per output brevi, questo overhead ("prompt tax") annulla i risparmi ottenuti dalla sintassi compatta. Ad esempio, per il caso users, JSON-SO è stato il vincitore assoluto (556 token totali), battendo sia JSON standard che TOON.
• Il costo della Riparazione: Quando TOON fallisce (specialmente in strutture complesse), i cicli di riparazione raddoppiano il consumo di token a causa della necessità di reinserire il grande prompt di sistema e lo storico degli errori nel contesto.
• Soglia di Rottura: TOON diventa efficiente solo quando il volume dei dati generati è sufficientemente grande da ammortizzare il costo fisso del prompt.

C. Ipotesi di Scaling

I risultati suggeriscono un'ipotesi di scaling non lineare: TOON brilla solo oltre un certo punto di complessità e volume dei dati, dove i risparmi cumulativi della sintassi superano l'overhead iniziale. Tuttavia, ciò introduce rischi di "indentation drift" (deriva dell'indentazione) in finestre di contesto molto lunghe.

4. Contributi e Conclusioni

Contributi Principali:

1. Valutazione Empirica: Prima benchmark sistematico che confronta TOON non solo con JSON, ma anche con la decodifica vincolata (JSON-SO) su una vasta gamma di modelli.
2. Distinzione tra Efficienza Sintattica e di Inferenza: Dimostrazione che un formato più compatto (TOON) non garantisce automaticamente un risparmio totale di token a causa dell'overhead del prompt e della maggiore probabilità di errori che richiedono riparazione.
3. Analisi per Dominio: Identificazione che TOON è efficace solo per domini specifici (dati tabulari, documenti transazionali) e inadatto per strutture ricorsive profonde.

Raccomandazioni Pratiche:

• Utilizzare TOON per flussi di dati su larga scala, "allineati" e transazionali (es. dump di query SQL, log, ordini, fatture), dove il risparmio sui token di output compensa l'overhead del prompt.
• Evitare TOON per gerarchie profonde, strutture ad albero complesse o configurazioni ricorsive, dove JSON standard o JSON-SO sono più affidabili ed efficienti.
• Considerare JSON-SO per compiti semplici e tabellari, dove la decodifica vincolata offre il miglior compromesso tra accuratezza e consumo di token.

Significato:
Il paper mette in guardia contro l'adozione acritica di nuovi formati di serializzazione ottimizzati per i token. L'efficienza reale di un formato dipende da un equilibrio complesso tra la sintassi del formato, la capacità del modello di seguire istruzioni complesse (in-context learning), la struttura dei dati e i costi associati ai fallimenti e alle riparazioni. TOON ha potenziale, ma è uno strumento di nicchia per scenari specifici, non un sostituto universale del JSON.