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

Die Studie stellt fest, dass das neue Format TOON zwar bei komplexen Aufgaben ein vielversprechendes Verhältnis von Genauigkeit zu Token-Verbrauch bietet, dessen Vorteil jedoch durch Prompt-Overhead bei kurzen Kontexten geschmälert wird, während herkömmliches JSON in der generierten Genauigkeit überlegen bleibt und eingeschränktes Decoding trotz geringstem Token-Verbrauch oft an Genauigkeit einbüßt.

Das Wesentliche

📝 Der große Format-Duell: JSON vs. TOON

Eine Studie von Ivan Matveev (Februar 2026)

Stell dir vor, du möchtest einem sehr klugen, aber manchmal etwas verwirrten Roboter (einem KI-Modell) eine komplexe Liste von Aufgaben geben. Du musst die Daten so schreiben, dass der Roboter sie versteht und keine Fehler macht.

Bisher war JSON der Standard. Es ist wie ein sehr strenges, aber bekanntes Formular. Jeder kennt es, aber es ist oft sperrig und voller unnötiger Buchstaben (wie viele Klammern und Anführungszeichen), die den Roboter viel "Platz" (Token) im Gedächtnis kosten.

TOON ist ein neuer, experimenteller Kandidat. Er wurde speziell für KIs entwickelt, um Daten extrem kompakt zu halten – wie ein effizienter Kurierdienst, der nur das Nötigste transportiert. Aber: Da der Roboter TOON noch nie in der Schule gelernt hat, muss man ihm erst eine lange Anleitung geben.

Die Studie fragt: Lohnt sich der neue Weg, oder ist der alte Standard doch besser?

---

🏁 Das Rennen: Drei Teilnehmer

Um das herauszufinden, ließen die Forscher 21 verschiedene KI-Modelle einen Wettkampf bestreiten. Sie mussten vier verschiedene Aufgaben lösen (z. B. eine Kundenliste, eine Bestellung, eine Firmenstruktur).

Die drei Konkurrenten waren:

1. JSON (Der Klassiker): Der Roboter schreibt einfach los, wie er es kennt.
   • Vorteil: Er kennt das Formular auswendig.
   • Nachteil: Es ist oft sehr lang und voller "Luft".
2. JSON-SO (Der Zwangs-Regler): Der Roboter wird an die Hand genommen. Ein technischer Zauber (Constrained Decoding) sorgt dafür, dass er niemals einen falschen Buchstaben schreiben kann. Er muss sich strikt an das Schema halten.
   • Vorteil: Sehr wenig Platzverbrauch, da keine Fehler passieren.
   • Nachteil: Bei sehr klugen Robotern kann diese starre Handhaltung stören und sie verwirren.
3. TOON (Der Neue): Der Roboter muss erst eine lange Anleitung lesen (den "Prompt"), um zu verstehen, wie TOON aussieht. Dann schreibt er in diesem neuen, sparsamen Format.
   • Vorteil: Wenn es klappt, ist das Ergebnis winzig klein und spart enorm viel Platz.
   • Nachteil: Die Anleitung kostet am Anfang viel Platz ("Prompt-Tax").

---

🍎 Die Ergebnisse: Was hat sich bewährt?

Die Forscher haben zwei Dinge gemessen: Wie oft war das Ergebnis richtig? und Wie viel "Platz" (Token) wurde dafür verbraucht?

1. Der "Anfangs-Schmerz" (Die Prompt-Steuer)

TOON hat ein großes Problem: Da der Roboter das Format nicht kennt, muss man ihm eine lange Anleitung geben.

• Analogie: Stell dir vor, du willst eine kurze Nachricht per Telegramm schicken. Aber bevor du schreiben darfst, musst du erst ein 5-seitiges Handbuch über Telegramm lesen.
• Ergebnis: Bei kurzen Nachrichten lohnt sich das nicht. Die Anleitung kostet mehr Platz als die Nachricht selbst spart. JSON ist hier schneller.

2. Der "Flachland-Effekt" (Wann TOON gewinnt)

TOON glänzt dort, wo die Daten flach und regelmäßig sind.

• Beispiel: Eine Kundenliste (Name, Alter, Adresse) oder eine Bestellliste (Produkt, Menge, Preis).
• Analogie: TOON ist wie ein LKW für Paletten. Wenn du 1000 identische Kisten hast, passt alles perfekt auf den LKW. JSON wäre wie 1000 einzelne Briefe, die man einzeln verschicken muss.
• Ergebnis: Bei solchen "flachen" Daten ist TOON extrem effizient und spart viel Geld (Token), sobald die Nachricht lang genug ist, um die Anleitung zu rechtfertigen.

3. Der "Berg-Effekt" (Wann TOON scheitert)

Bei tief verschachtelten Strukturen (z. B. eine Firma mit Abteilungen, die wieder Abteilungen haben, die wieder Mitarbeiter haben) bricht TOON zusammen.

• Analogie: TOON ist wie ein Flachbett-LKW. Wenn du versuchst, einen komplexen, mehrstöckigen Turm darauf zu laden, rutscht alles herunter. JSON ist wie ein Kran, der jeden Winkel erreichen kann.
• Ergebnis: Bei komplexen Firmenstrukturen machte TOON in der ersten Runde fast gar keine richtigen Ergebnisse (0 % Erfolg). Die KI war verwirrt. JSON und der "Zwangs-Regler" (JSON-SO) waren hier viel zuverlässiger.

4. Die Reparatur-Kosten

Wenn die KI einen Fehler macht, muss sie es nochmal versuchen.

• Bei TOON ist das teuer. Weil die Anleitung so lang ist, kostet jeder Reparaturversuch enorm viel Platz.
• Bei JSON ist die Anleitung kurz, daher sind Reparaturversuche billiger.

---

💡 Die wichtigsten Lehren für die Praxis

Die Studie kommt zu folgenden einfachen Schlussfolgerungen:

1. Für einfache Listen (Bestellungen, Logs, Tabellen): TOON ist ein Superheld. Wenn du riesige Mengen an Daten hast, die alle gleich aufgebaut sind, spart TOON massiv Zeit und Geld. Aber du musst sicherstellen, dass die Nachricht lang genug ist, damit sich die lange Anleitung lohnt.
2. Für komplexe Strukturen (Firmenhierarchien, Baumstrukturen): Vergiss TOON. Hier ist der alte JSON (oder die gesteuerte JSON-Variante) besser. TOON ist hier noch zu unreif und macht zu viele Fehler.
3. Der "Zwangs-Regler" (JSON-SO) ist der heimliche Sieger für kleine Aufgaben: Wenn du nur eine kleine, einfache Aufgabe hast, ist die Technik, die den Roboter zwingt, korrekt zu schreiben (Constrained Decoding), oft besser als TOON. Sie ist schneller und braucht keine lange Anleitung.

🚀 Fazit in einem Satz

TOON ist wie ein Formel-1-Auto: Auf der geraden Strecke (einfache, große Datenmengen) ist es unschlagbar schnell und sparsam. Aber auf der kurvigen, steilen Bergstraße (komplexe, verschachtelte Daten) ist ein guter Geländewagen (JSON) immer noch die sicherere Wahl.

Die Zukunft von TOON sieht vielversprechend aus, aber nur für ganz bestimmte, gut strukturierte Aufgaben. Für alles andere bleiben wir vorerst beim bewährten Standard.

Technische Zusammenfassung

1. Problemstellung

Das Paper adressiert das Problem des hohen Token-Verbrauchs bei der Generierung strukturierter Daten durch Large Language Models (LLMs). JSON ist der De-facto-Standard für die Serialisierung von Daten an LLMs, verbraucht jedoch aufgrund seiner syntaktischen Redundanz (z. B. Anführungszeichen, Kommas, geschweifte Klammern) viele Token.
Token-Oriented Object Notation (TOON) wurde als Alternative vorgeschlagen, die speziell für LLMs entwickelt wurde, um den Token-Verbrauch drastisch zu reduzieren.
Die zentrale Forschungsfrage ist jedoch: Lohnt sich der Wechsel zu TOON?
Bisherige Tests zeigten zwar eine gute Verständnisfähigkeit von LLMs für TOON, aber es fehlten Vergleiche zur Generierung. Die Autoren untersuchen, ob die Einsparungen im Output die hohen Kosten für den Prompt (Anleitung/Beispiel für TOON) und potenzielle Reparaturzyklen (bei Fehlern) aufwiegen, insbesondere im Vergleich zu:

1. Plain JSON (freie Generierung).
2. JSON mit Structured Output (konstruierte Decodierung/Constrained Decoding).

2. Methodik

Die Studie vergleicht drei Output-Formate über 21 verschiedene LLM-Modelle (u.a. Qwen, Llama, Hermes, DeepSeek, GPT-OSS) hinweg.

Die drei Test-Szenarien (Tracks):

• J (JSON): Freie Generierung von JSON ohne Einschränkungen.
• JSO (JSON-SO): JSON-Generierung mittels Constrained Decoding (z. B. xgrammar). Das Modell wird gezwungen, nur Token zu wählen, die einer gültigen JSON-Grammatik entsprechen. Dies soll Syntaxfehler eliminieren.
• T (TOON): Generierung im TOON-Format mittels One-Shot In-Context Learning. Da TOON nicht im Trainingsdaten der Modelle enthalten ist, wird ein detailliertes Beispiel im Prompt bereitgestellt.

Benchmark-Design:

• Datensätze: Vier Testfälle mit unterschiedlicher struktureller Komplexität:
  • Users: Einfache tabellarische Struktur.
  • Order: Verschachtelte Struktur mit Arrays.
  • Company: Tiefe Hierarchie (Abteilungen, Mitarbeiter).
  • Invoice: Items und Summen.
• Validierung: Alle Outputs werden via Pydantic validiert. Bei Fehlern folgt ein Reparaturzyklus (bis zu 3 Versuche), bei dem der Fehler in den Prompt zurückgespeist wird.
• Metriken:
  • One-Shot-Accuracy: Trefferquote beim ersten Versuch.
  • Final-Accuracy: Trefferquote nach Reparaturzyklen.
  • Token-Budget: Gesamtkosten (Prompt + Completion) für eine korrekte Ausgabe.
• Parameter: Temperatur 0 (deterministisch), 10 Wiederholungen pro Modell und Fall.

3. Wichtige Beiträge und Erkenntnisse

A. Der Trade-off bei Constrained Decoding (JSO)

• Schwächere Modelle: Für kleinere Modelle (z. B. Qwen2.5-Coder-7B) wirkt Constrained Decoding als „Sicherheitsnetz". Es rettete die Genauigkeit von 0 % (bei Plain JSON) auf 75 % und reduzierte den Token-Verbrauch massiv (von 37k auf 4,4k Token).
• Starke Modelle: Bei großen Reasoning-Modellen (z. B. Hermes-4-405B) verschlechterte die strikte Grammatik-Enforcement die One-Shot-Genauigkeit drastisch (von 92,5 % auf 35 %). Das Modell wurde in suboptimale Token-Pfade gezwungen, obwohl es sich nach Reparaturzyklen erholte.

B. TOON: Domänen-Abhängigkeit und „Prompt Tax"

• Prompt Tax: Da TOON neu ist, erfordert der Prompt ein umfangreiches Beispiel. Bei kurzen Kontexten oder kleinen Ausgaben übersteigen diese Fixkosten oft die Einsparungen im Output.
• Domänen-Alignment:
  • Ausgerichtete Fälle (Tabellarisch/Flach): Bei einfachen Strukturen (Users, Orders) ist TOON effizient. Im Users-Fall erreichte TOON 90,5 % Genauigkeit bei 22 % weniger Token als Plain JSON.
  • Nicht-ausgerichtete Fälle (Tiefe Hierarchien): Bei komplexen, rekursiven Strukturen (Company) brach die One-Shot-Genauigkeit von TOON auf 0 % ein. Zwar erreichte TOON nach Reparaturzyklen eine ähnliche Endgenauigkeit wie JSON, aber der Token-Verbrauch war ineffizient.
• Reparatur-Kosten: Wenn TOON fehlschlägt, ist der Reparaturzyklus extrem teuer, da der große System-Prompt erneut gesendet wird. Dies verdoppelte in einigen Fällen den Token-Verbrauch im Vergleich zu JSON.

C. Token-Effizienz und Skalierung

• Constrained Decoding als Gewinner bei Einfachem: Für einfache tabellarische Daten war JSON-SO (JSO) der absolute Effizienz-Sieger (556 Token vs. 840 Token bei TOON im Users-Fall).
• Nicht-lineare Skalierung: Die Autoren hypothesieren, dass TOONs wahres Potenzial erst bei sehr großen Datenmengen (z. B. massive SQL-Resultsets oder Log-Streams) zum Tragen kommt, wo die syntaktischen Einsparungen die initiale „Prompt Tax" amortisieren.

4. Ergebnisse im Überblick

Metrik	Plain JSON (J)	JSON-SO (JSO)	TOON (T)
One-Shot Genauigkeit	Meist am höchsten (besonders bei starken Modellen)	Variabel (gut bei schwachen Modellen, schlecht bei starken)	Gering (besonders bei komplexen Strukturen), gut bei flachen Daten
Token-Verbrauch	Hoch (syntaktischer Overhead)	Sehr niedrig (bei Erfolg)	Mittel (Output spart, aber Prompt kostet)
Robustheit	Hoch (selbst bei Fehlern oft reparierbar)	Hoch (durch Grammatik-Enforcement)	Gering bei komplexen Strukturen (0 % One-Shot bei Company)
Beste Anwendung	Allgemeine Nutzung, komplexe Hierarchien	Einfache Strukturen, schwache Modelle	Große, tabellarische Datenmengen (in-domän)

5. Bedeutung und Empfehlungen

Das Paper liefert eine realistische Einschätzung für den Einsatz von TOON in der Produktion:

1. Kein Allheilmittel: TOON ersetzt JSON nicht universell. Es ist spezifisch für „ausgerichtete" (aligned) Datenstrukturen wie SQL-Tabellen, Transaktionsdokumente (Rechnungen, Bestellungen) und Audit-Logs geeignet.
2. Vermeidung bei Komplexität: Für tiefe, rekursive Hierarchien (DOM-Strukturen, komplexe Konfigurationen) ist TOON derzeit nicht produktionsreif; hier bleibt JSON (ggf. mit Constrained Decoding) überlegen.
3. Strategie für LLMs:
   • Für High-Volume, kostensensitive Pipelines mit tabellarischen Daten kann TOON die Token-Kosten und Latenz senken.
   • Für Allgemeinzweck-Anwendungen oder komplexe Datenmodelle ist Plain JSON oder JSON-SO vorzuziehen.
4. Zukünftige Forschung: Es muss untersucht werden, wie sich TOON bei extrem großen Kontextfenstern verhält (Risiko von Einrückungsfehlern/Indentation Drift) und ob eine Anpassung des Prompts pro Schema die Fehlerquote weiter senken kann.

Fazit: TOON bietet ein vielversprechendes Verhältnis aus Genauigkeit und Token-Verbrauch, aber nur unter spezifischen Bedingungen (flache/standardisierte Datenstrukturen). Der „Prompt-Tax" und die Anfälligkeit bei Fehlern in komplexen Strukturen schränken den sofortigen breiten Einsatz ein. Constrained Decoding (JSON-SO) bleibt für einfache Aufgaben oft die effizienteste Wahl.