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

Dit onderzoek vergelijkt de nieuwe Token-Oriented Object Notation (TOON) met JSON en concludeert dat TOON, ondanks een gunstige token-efficiëntie bij complexe taken, vaak wordt beperkt door prompt-overhead en dat geconstrueerde JSON-decodering voor eenvoudige structuren zelfs nog efficiënter kan zijn dan TOON.

De kern

De Kern: Een nieuwe taal voor AI?

Stel je voor dat je een robot (een Large Language Model of LLM) instructies geeft om een complexe lijst te maken, zoals een bestelling of een personeelsbestand. Normaal gesproken praten we met deze robots in JSON. JSON is als een zeer strikte, maar soms wat rommelige taal die computers al jaren begrijpen.

De auteur van dit paper, Ivan Matveev, heeft gekeken naar een nieuwe, experimentele taal genaamd TOON (Token-Oriented Object Notation). De belofte van TOON is simpel: "Het is korter, dus het kost minder geld en tijd om te versturen."

Maar is het echt beter? De auteur heeft een race georganiseerd tussen drie deelnemers om dat te testen.

De Drie Deelnemers in de Race

1. De Vrije Kunstenaar (Plain JSON): De robot mag gewoon JSON schrijven zoals hij dat gewend is. Geen regels, geen hulp. Hij moet het zelf weten.
2. De Strikte Bouwmeester (JSON-SO): De robot krijgt een strakke bouwtekening (constrained decoding). Hij mag alleen de juiste stenen leggen. Als hij een fout maakt, wordt de steen direct weggegooid. Dit is als een robot die een muur bouwt met een laser die elke afwijking corrigeert.
3. De Nieuwe Talenstudent (TOON): De robot moet een nieuwe, compacte taal leren. Omdat hij deze taal niet kent, moet de mens eerst een heel groot "handleiding" (prompt) geven met voorbeelden. Daarna moet hij de tekst in die nieuwe stijl schrijven.

Wat bleek er uit de race?

De resultaten zijn verrassend en hangen af van wat je precies laat bouwen.

1. De "Handleiding-Boete" (De Prompt Tax)

Dit is het grootste probleem voor TOON. Omdat de robot de taal TOON niet kent, moet je hem eerst een hele lange uitleg geven (de handleiding).

• Vergelijking: Stel je voor dat je iemand vraagt om een brief te schrijven.
  • Bij JSON zeg je gewoon: "Schrijf een brief." (Kort).
  • Bij TOON moet je eerst 3 pagina's uitleggen: "Gebruik twee spaties, zet de komma hier, en schrijf zo..." voordat je überhaupt begint met de brief.
• Het gevolg: Voor kleine taken (een korte lijst) kost TOON meer tijd en geld dan JSON, omdat de uitleg langer is dan de brief zelf. Het is alsof je een vrachtwagen huurt om een postzegel te bezorgen.

2. De "Grote Lijst" Winst (Amortisatie)

Maar als je een enorme lijst moet maken (bijvoorbeeld duizenden producten in een magazijn), verandert het spel.

• Vergelijking: Als je die vrachtwagen (TOON) gebruikt voor een heel groot pakket, bespaar je op de verpakking (de tekst zelf) veel ruimte. De lange uitleg aan het begin telt dan minder zwaar.
• Resultaat: Bij grote, gestructureerde data (zoals bestellingen of facturen) wint TOON vaak. Het is korter en efficiënter, mits de data niet te ingewikkeld is.

3. De Strikte Bouwmeester (JSON-SO) is verrassend goed

De "Strikte Bouwmeester" (JSON met beperkingen) deed het verrassend goed bij simpele taken.

• Vergelijking: Bij het maken van een simpele lijst (zoals een lijst met gebruikers) was deze methode de snelste en goedkoopste. De robot hoefde niet te denken, hij volgde gewoon de regels.
• Nadeel: Bij complexe, ingewikkelde structuren (zoals een diep vertakt bedrijfshierarchie) raakte de robot in de war. De regels werden te strak, en de robot begon vast te lopen.

De Grote Ontdekking: Het hangt af van de vorm

De paper concludeert dat TOON geen "wondermiddel" is voor alles. Het werkt alleen goed in een specifieke omgeving:

• Waar TOON wint: Bij "platte" of "uniforme" data. Denk aan tabellen, lijsten met bestellingen, of logboeken. Hier is de structuur altijd hetzelfde. TOON is hier als een strakke, efficiënte trein die op een vast spoor rijdt.
• Waar TOON faalt: Bij "diepe" en "chaotische" data. Denk aan een ingewikkeld familieboomdiagram of een software-configuratie met veel lagen. Hier faalt TOON compleet. De robot raakt de draad kwijt omdat de nieuwe taal niet is gemaakt voor zulke ingewikkelde vormen.

De Conclusie in Eén Zin

TOON is als een speciaal gereedschap: het is fantastisch om duizenden identieke schroeven in te draaien (grote lijsten), maar het is een slechte keuze om een ingewikkeld houten poppenkastje te bouwen (complexe hiërarchieën).

Voor nu is de beste strategie:

1. Gebruik gewone JSON voor alles wat complex of klein is.
2. Gebruik TOON alleen als je enorme hoeveelheden simpele, gestructureerde data (zoals bestellingen) moet verwerken en je echt elke seconde en elke cent wilt besparen.
3. Gebruik Strikte JSON (JSON-SO) als je zekerheid wilt bij simpele taken zonder de "handleiding-Boete" van TOON.

Kortom: TOON heeft potentie, maar het is nog geen vervanging voor JSON. Het is meer een gespecialiseerd hulpmiddel voor specifieke, grote taken.

Technische samenvatting

1. Probleemstelling

Large Language Models (LLM's) worden steeds vaker gebruikt voor het genereren van gestructureerde data, waarbij JSON de standaard serialisatieformaat is. Echter, JSON kan inefficiënt zijn in termen van token-gebruik, wat leidt tot hogere kosten en latentie, vooral bij grote datasets of herhaalde correctielussen (repair loops).

Token-Oriented Object Notation (TOON) is een nieuw formaat dat is ontworpen om JSON te vervangen door de token-gebruik te minimaliseren terwijl de leesbaarheid voor LLM's behouden blijft. Hoewel TOON veelbelovende resultaten liet zien bij het begrijpen van data, ontbrak er een uitgebreide benchmark voor het genereren van data. De kernvraag is of de token-besparing van het output-formaat opweegt tegen de "prompt-taks" (de extra instructies die nodig zijn om een model TOON te laten begrijpen) en of het formaat robuust is genoeg voor complexe datastructuren.

2. Methodologie

De auteurs hebben een benchmark uitgevoerd om drie output-methoden te vergelijken:

1. Plain JSON (J): Standaard generatie zonder beperkingen.
2. JSON met Structured Output (JSO): Generatie met beperkte decoding (constrained decoding), waarbij de inferentie-engine (bijv. xgrammar) de logit-maskers aanpast om alleen geldige JSON-tokens toe te staan.
3. TOON (T): Generatie in het TOON-formaat via één-shot in-context learning (met een universeel voorbeeld in de prompt).

Experimenteel Ontwerp:

• Datasets: Vier testgevallen met variërende complexiteit:
  • Users: Eenvoudige tabulaire structuur.
  • Order: Geneste structuur met een array.
  • Company: Diepe hiërarchie (afdelingen en werknemers).
  • Invoice: Items en totalen.
• Modellen: 21 verschillende LLM's (o.a. Qwen, Llama, Hermes, DeepSeek, GPT-oss) geëvalueerd via de Nebius API.
• Parameters: Temperatuur 0 voor deterministische output. Elke test werd 10 keer uitgevoerd.
• Validatie: Alle outputs werden gevalideerd via Pydantic. Als de output niet klopte, volgde een "repair cycle" (maximaal 3 pogingen) waarbij de foutmelding terug in de prompt werd gevoerd.
• Metrieken:
  • One-shot accuracy: Succespercentage bij de eerste poging.
  • Final accuracy: Succespercentage na reparatie.
  • Token budget: Totale tokens (prompt + completion) voor een correct resultaat.

3. Belangrijkste Bevindingen en Resultaten

A. De Trade-off van Beperkte Decoding (JSON-SO)

• Zwakke modellen: Voor kleinere modellen (bijv. Qwen2.5-Coder-7B) fungeerde JSON-SO als een veiligheidsnet. Het model faalde volledig bij plain JSON (0% accuraatheid, enorme token-uitstoot), maar bereikte 75% accuraatheid met JSON-SO.
• Sterke modellen: Voor grote redenerende modellen (bijv. Hermes-4-405B) verlaagden de strenge grammaticale beperkingen de initiële prestaties aanzienlijk (van 92,5% naar 35% one-shot accuraatheid). De beperkingen leken de natuurlijke waarschijnlijkheidsverdeling van het model te verstoren, hoewel ze uiteindelijk wel herstelden na reparatie.

B. TOON: Prestaties en "Prompt Tax"

• One-shot prestaties: TOON presteerde over het algemeen slechter dan plain JSON bij de eerste poging, voornamelijk door de hoge "prompt tax" (de instructies en voorbeelden die nodig zijn om het formaat uit te leggen).
• Token-efficiëntie:
  • Bij eenvoudige, tabulaire data (gealigneerd met TOON, zoals 'users' en 'orders') kon TOON de token-kosten verlagen, maar vaak niet genoeg om de prompt-kosten te compenseren in korte contexten.
  • Bij JSON-SO bleek voor zeer eenvoudige tabulaire data de meest token-efficiënte optie (556 tokens vs 840 voor TOON in de 'users' case).
• Structuurafhankelijkheid: TOON presteerde uitstekend bij "gealigneerde" gevallen (tabellen, uniforme arrays) maar faalde volledig bij de eerste poging voor diep geneste, niet-uniforme structuren ('company' case: 0% one-shot accuraatheid). Hoewel reparatie de final accuraatheid bracht naar vergelijkbare niveaus als JSON, was de token-kost voor reparatie hoog.

C. De "Scaling Hypothesis"

De resultaten suggereren dat TOON's efficiëntie niet-lineair is. De token-besparing van de syntax moet groot genoeg zijn om de vaste kosten van de instructie-prompt te amortiseren. Voor kleine datasets is plain JSON of JSON-SO vaak efficiënter; voor zeer grote datasets zou TOON de winnaar kunnen zijn, mits de structuur binnen het "gealigneerde" domein valt.

4. Kritische Analyse en Conclusies

1. Geen Universele Oplossing: TOON is geen directe vervanger voor JSON in alle scenario's. Het is een gespecialiseerd formaat dat alleen voordelen biedt bij specifieke data-topologieën (tabellen, transactiedocumenten).
2. Risico bij Diepe Hiërarchieën: Voor complexe, diep geneste data (zoals DOM-structuren of configuratiebomen) is TOON niet productieklaar. De syntactische regels van TOON lijken minder robuust te zijn voor deze complexiteit dan JSON.
3. De Rol van Constraining: Constrained decoding (JSON-SO) is een krachtige tool voor kleinere modellen om fouten te voorkomen, maar kan de prestaties van grote, redenerende modellen in de weg zitten door hun natuurlijke generatiepatronen te onderdrukken.
4. Reparatiekosten: TOON is efficiënt wanneer het werkt, maar duur wanneer het faalt. Omdat de prompt groot is, verdubbelt de token-kost bij een reparatielus sneller dan bij JSON.

5. Significantie en Aanbevelingen

Het paper biedt een realistisch beeld van de adoptie van nieuwe serialisatieformaten voor LLM's:

• Aanbevolen Gebruik: TOON is geschikt voor high-volume, kostengevoelige toepassingen met gestructureerde, tabulaire data (bijv. SQL-resultaten, bestellingen, audit logs), mits de schema's consistent zijn.
• Vermijden: Gebruik TOON niet voor complexe, diep geneste configuraties of wanneer de dataset klein is (de prompt-taks weegt niet op tegen de besparing).
• Toekomst: Er is meer onderzoek nodig naar de schaalbaarheid van TOON en de risico's van "indentation drift" in lange contextvensters. De auteurs suggereren dat het mogelijk is om TOON te combineren met state-machines (zoals xgrammar) om de inferentie te forceren, maar de huidige resultaten tonen aan dat dit niet altijd de gewenste resultaten oplevert.

Conclusie: Hoewel TOON een interessante innovatie is voor het verminderen van token-kosten, is de huidige implementatie te afhankelijk van de data-structuur en de grootte van de prompt om een algemene vervanging voor JSON te zijn. De keuze tussen Plain JSON, JSON-SO en TOON moet worden gebaseerd op de specifieke complexiteit van de data en de capaciteit van het gebruikte model.