ONTO: A Token-Efficient Columnar Notation for LLM Input Optimization

Titolo

ONTO: Una Notazione Colonnare Efficiente in Token per l'Ottimizzazione dell'Input degli LLM

1. Il Problema

L'articolo identifica un problema critico nell'uso dei Large Language Models (LLM) per l'analisi di dati operativi su larga scala (es. telemetria IoT, log di sistema, metriche).

• Inefficienza dei formati esistenti: I formati di serializzazione standard come JSON e YAML sono progettati per lo scambio di documenti tra servizi web, privilegiando l'autodescrizione e la leggibilità umana. Questo comporta la ripetizione dei nomi dei campi (chiavi) per ogni singolo record e l'uso abbondante di punteggiatura strutturale (parentesi graffe, virgolette, ecc.).
• Costo dei Token: In un dataset di 1.000 letture di sensori, il formato JSON può richiedere circa 80.000 token, la maggior parte dei quali sprecati in metadati ripetuti invece che nel contenuto sematico.
• Conseguenze: Questo spreco di token aumenta i costi API (che sono lineari rispetto all'input), riduce la capacità del contesto disponibile e aumenta la latenza di inferenza.
• Il Gap: Non esiste un formato che combini l'efficienza colonnare (nessuna ripetizione delle chiavi), il supporto per strutture nidificate, la leggibilità umana e la possibilità di essere inserito direttamente nei prompt degli LLM.

2. Metodologia: ONTO

Gli autori propongono ONTO (Object Notation for Token Optimization), una notazione colonnare progettata specificamente per l'inserimento di dati strutturati nei prompt degli LLM.

Principi di Design:

• Schema-once, Data-many: I nomi dei campi sono dichiarati una sola volta per entità, non per ogni record.
• Struttura Colonnare: I valori sono organizzati in righe separate da un pipe (|).
• Gerarchia Implicita: La nidificazione è rappresentata tramite indentazione (spazi fissi a 4) invece che tramite parentesi graffe o quadre, riducendo il numero di token strutturali.
• Delimitatori Minimali: L'uso del pipe (|) per separare i valori e del caret (^) per gli array interni riduce drasticamente la punteggiatura rispetto a JSON.

Esempio di Sintassi:
Invece di un array di oggetti JSON, ONTO dichiara l'entità e i campi una volta, seguiti dai valori allineati:

Telemetry [3]:
device_id: sensor-001|sensor-002|sensor-003
temperature: 23.5|24.1|22.9
location:
  lat: 37.77|37.78|37.79
  lon: -122.41|-122.42|-122.43

3. Contributi Chiave

1. Caratterizzazione del Problema: Dimostrano che la serializzazione per l'input degli LLM è un problema distinto dallo scambio di documenti, richiedendo criteri di ottimizzazione diversi (rimozione della ridondanza dello schema).
2. Design del Formato: Presentazione di ONTO, che riduce i token del 46-51% mantenendo la leggibilità e il supporto per dati nidificati.
3. Validazione Empirica: Test su dataset sintetici (IoT, Metriche di Sistema, Log) che confermano una riduzione stabile dei token e miglioramenti nella latenza senza degradazione della comprensione.
4. Analisi di Ablazione: Scomposizione dei risparmi per identificare che l'eliminazione delle chiavi ripetute è il fattore dominante, mentre l'indentazione introduce un piccolo sovraccarico nelle strutture nidificate.
5. Open Source: Rilascio di un parser di riferimento in Python, suite di benchmark e dataset sintetici.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su tre dataset sintetici (100, 500, 1.000 record) utilizzando modelli come Qwen2.5-7B e GPT-5.4-mini.

• Efficienza dei Token:

  • Riduzione: ONTO ottiene una riduzione dei token del 46,3% - 51,0% rispetto a JSON.
  • Scalabilità: Il rapporto di riduzione rimane costante all'aumentare del numero di record (da 100 a 1.000), confermando che i risparmi si scalano proporzionalmente con il volume dei dati.
  • Composizione: L'analisi mostra che l'eliminazione dei nomi dei campi (chiavi) risparmia oltre 41.000 token su 1.000 record, mentre la riduzione della punteggiatura ne risparmia altri 15.000. L'indentazione aggiunge circa 5.000 token per le strutture nidificate, spiegando la leggera differenza di efficienza tra dati piatti e nidificati.

• Impatto sulla Latenza:

  • La riduzione dei token si traduce in un miglioramento della latenza di inferenza: -5,3% / -7,4% nel Time-to-First-Token (TTFT) e -9,1% / -10,5% nel tempo totale di inferenza.

• Validazione della Comprensione (Accuracy):

  • Nessun degrado significativo: L'accuratezza nelle attività di ricerca (lookup), estrazione (list), e aggregazione (max) è pari o superiore a quella di JSON quando viene fornito un prompt di sistema ("warm prompt") che spiega il formato.
  • Limitazioni note: L'accuratezza nelle attività di conteggio preciso (counting) rimane bassa (15-40%) su tutti i formati, confermando che è un limite intrinseco del modello LLM e non del formato di input.

5. Significato e Implicazioni

• Nicchia Specifica: ONTO riempie un vuoto nel panorama della serializzazione, offrendo un formato ottimizzato per il consumo temporaneo (ephemeral) da parte degli LLM, a differenza di Parquet (storage) o JSON (scambio API).
• Risparmio Economico: Per carichi di lavoro su larga scala, una riduzione del 50% dei token di input si traduce direttamente in un dimezzamento dei costi di inferenza per la componente di input.
• Integrazione Semplice: ONTO funge da strato di pre-elaborazione che non richiede modifiche alle pipeline esistenti, limitandosi a convertire i dati prima dell'inserimento nel prompt.
• Limiti e Futuro: Il formato richiede record omogenei (stesso schema) e attualmente non supporta il parsing in streaming per dataset enormi. Il lavoro futuro includerà l'analisi della profondità di nidificazione e la validazione su tracce di produzione reali.

In conclusione, il paper dimostra che abbandonare i paradigmi di serializzazione tradizionali a favore di formati "schema-once" specifici per gli LLM è una necessità pratica per gestire l'esplosione dei dati strutturati nell'era dell'intelligenza artificiale operativa.