JSON, TOON o CSV: in che formato passare i dati a un LLM?

JSON, TOON e CSV sono tre modi di scrivere gli stessi dati strutturati dentro un prompt, cioè il testo che si invia a un modello linguistico. Il JSON è il formato standard delle API: ogni record ripete i nomi dei campi tra parentesi e virgolette, e qualunque sistema lo sa leggere. Il CSV è una tabella in testo semplice, una riga per record e una virgola tra i valori, con i nomi delle colonne scritti una volta sola. TOON (Token-Oriented Object Notation) è una codifica compatta dello stesso modello dati del JSON, pensata per i prompt: usa l'indentazione per gli oggetti annidati e, per gli elenchi di record tutti uguali, un'intestazione come ordini[3]{id,cliente,totale}: seguita da righe di valori. La differenza pratica sta in quanti token occupano, cioè i frammenti di testo che il modello elabora e su cui si paga, e in quanto bene il modello li legge o li scrive.

Leggi anche: Output strutturato (structured outputs) · Il vincolo che obbliga un LLM a rispondere secondo uno schema JSON dichiarato, garantito in decodifica e non nel prompt.

Leggere e scrivere non sono lo stesso problema

La documentazione di TOON (specifica 4.1, licenza MIT) dichiara apertamente i propri limiti: sulle strutture profondamente annidate o irregolari vince il JSON, sui dati puramente tabellari il CSV è più piccolo, e dove conta la latenza il JSON compatto può essere più veloce pur usando più token. TOON rende quindi soprattutto in input: array lunghi di record identici, dove non ripetere i nomi dei campi a ogni riga fa risparmiare.

Quando invece è il modello a dover generare i dati, il quadro cambia. Un benchmark del febbraio 2026 ha trovato che il JSON semplice ottiene l'accuratezza migliore, anche rispetto all'output strutturato con decodifica vincolata, che usa meno token ma sbaglia un po' di più. Spesso il costo delle istruzioni necessarie per spiegare il formato al modello si mangia il vantaggio di TOON, che ripaga solo sulle strutture lunghe. Come ottenere un output affidabile è il tema degli output strutturati.

Anche la forma del prompt conta: uno studio del 2024 ha misurato su GPT-3.5-turbo differenze fino al 40% in un compito di traduzione di codice cambiando solo la struttura del prompt (testo, Markdown, JSON, YAML), mentre i modelli più grandi si sono rivelati più robusti. Nei prompt si usano spesso anche YAML, per le configurazioni annidate, e le tabelle Markdown, per poche righe da mostrare anche a una persona.

Un esempio enterprise

Un assistente per l'ufficio acquisti riceve a ogni domanda un estratto di centinaia di righe d'ordine dal gestionale, tutte con gli stessi campi. È il caso in cui CSV o TOON possono ridurre sensibilmente i token in ingresso rispetto al JSON, e TOON conserva anche eventuali campi annidati. Se però la risposta deve alimentare un altro sistema, conviene chiederla in JSON. Prima di adottare un formato si prende qualche decina di richieste reali e si misurano token e accuratezza con ciascuno: il risultato dipende dal modello e dai dati, non da un numero letto altrove.

Perché conta per chi decide

Il formato è una leva sui costi di esercizio dell'AI, ma non la prima. Prima viene la scelta di cosa mettere nella finestra di contesto, cioè il context engineering: togliere dati inutili spesso fa risparmiare più di quanto possa una codifica. Una volta deciso il contenuto, il JSON resta la scelta sicura ai confini con le API e per ciò che il modello produce, mentre CSV e TOON si valutano per gli input voluminosi, misurandoli sul proprio caso e non seguendo la moda.