Waarom TOON beter presteert dan andere formaten
Als u LLM-applicaties bouwt, met name Retrieval-Augmented Generation (RAG)-systemen of agenten die grote datasets verbruiken, voert u waarschijnlijk een voortdurende oorlog op twee fronten: tokenkosten en contextvensterlimieten.
Jarenlang was JSON de standaardlingua franca voor gegevensuitwisseling. Het is voor mensen leesbaar (grotendeels) en alomtegenwoordig. Maar wanneer u een JSON-array van 500 rijen in een prompt plakt, verbrandt u duizenden tokens op herhaalde veldnamen ("id":, "name":, "email":`) die geen semantische waarde hebben voor de specifieke rij.
Voer TOON in. Het is een formaat dat speciaal is ontworpen om het signaal-ruisverhoudingsprobleem in LLM-ingangen op te lossen. Ik heb me verdiept in de nieuwste benchmarks en de resultaten zijn verbluffend: TOON bespaart niet alleen ruimte; het helpt modellen als GPT-5-nano en Gemini-2.5-flash feitelijk gegevens beter te begrijpen.
Laten we eens kijken waarom TOON de zwaargewichten (JSON, CSV, YAML, XML) verslaat en naar de ruwe cijfers kijken.
De breedsprakigheidsval: JSON versus TOON
De grootste vijand van token-efficiëntie is structuurherhaling. Laten we eens kijken naar een standaard Time-Series Analytics-dataset. In JSON draagt elk afzonderlijk datapunt de bagage van zijn schema.
JSON (standaard) Tokens gebruikt in benchmark: 22.250
Dat is een hoop verloren ruimte. Kijk nu naar het TOON-equivalent. TOON definieert het schema één keer in de header en schakelt vervolgens over naar een compacte, CSV-achtige lay-out voor de waarden.
TOON Tokens gebruikt in benchmark: 9.120
Het resultaat: Een enorme vermindering van 59,0% in het tokengebruik.
Door de herhaalde sleutels weg te halen, kunt u met TOON meer geschiedenis in het contextvenster van het model passen. Maar cruciaal is dat het, in tegenstelling tot CSV, het typebewustzijn en de expliciete structuur handhaaft via de headerdefinitie metrics[5]{...}.
Waarom niet gewoon CSV gebruiken?
Dit is het meest voorkomende tegenargument. "Als je platte gegevens wilt, gebruik dan gewoon CSV."
Het probleem is dat gegevens uit de echte wereld zelden perfect vlak zijn. CSV valt volledig uiteen zodra u geneste structuren, lijsten binnen objecten of complexe beschrijvingen met komma's en aanhalingstekens heeft.
In de benchmarks, met name het Mixed-Structure Track (dat e-commercebestellingen en gebeurtenislogboeken bevat), werd CSV volledig uitgesloten omdat het de gegevens niet kon weergeven zonder verliesgevende afvlakking.
TOON gaat hier netjes mee om. Het maakt geneste objecten mogelijk terwijl de arrays worden geoptimaliseerd. In een test van 100 GitHub-repository's (die gemengde tekstbeschrijvingen en metadata bevatten) was de efficiëntiekloof duidelijk:
- JSON: 15.145 tokens
- TOON: 8.745 tokens (42,3% besparing)
Zelfs tegen JSON Compact (verkleind) wist TOON nog steeds bijna 24% meer besparingen te realiseren. Wanneer u per miljoen tokens betaalt, is dat een onmiddellijke ROI.
Nauwkeurigheid: de verrassende winnaar
Hier is het deel dat mij verraste. Wanneer u gegevens comprimeert, verliest u doorgaans de duidelijkheid. Je zou verwachten dat de LLM moeite zal hebben om een compacter formaat te ontleden. De benchmarks laten het tegenovergestelde zien.
Op basis van 209 vragen voor het ophalen van gegevens die zijn getest op modellen als Claude Haiku, Gemini Flash en GPT-5-nano, behaalde TOON een ophaalnauwkeurigheid van 73,9%, vergeleken met 69,7% van standaard JSON.
Waarom? Het komt waarschijnlijk neer op Cognitieve belasting (of het LLM-equivalent).
- Minder ruis: Het model hoeft geen rekening te houden met duizenden herhalende 'sleutel'-tokens. In het aandachtsmechanisme liggen de relevante waarden dichter bij elkaar.
- Expliciete metadata: TOON-headers bevatten expliciet het aantal (
[N]) en veldnamen.
- Structuurbewustzijn: In tests waarin werd gevraagd naar de structuur van de dataset (bijvoorbeeld: "Hoeveel rijen zijn er?"), bereikte TOON een nauwkeurigheid van 88%**, terwijl JSON en XML achterbleven. Het expliciete aantal in de TOON-header (
repositories[100]) fungeert als een hint die voorkomt dat het model tokens handmatig moet "tellen", iets waar LLM's berucht om zijn.
De XML- en YAML-vermoeidheid
We moeten de andere kanshebbers kort vermelden.
XML is hier de grote verliezer. Het is uitgebreid, moeilijk te lezen en duur om te verwerken. In de benchmarks gebruikte XML consistent de meeste tokens (meer dan 5.000 voor een uniforme werknemersrecordset die TOON vertegenwoordigde in ~2.700) en had de laagste nauwkeurigheid (67,1%).
YAML presteert beter dan XML, maar heeft nog steeds last van token-bloat vergeleken met TOON. Hoewel YAML geweldig is voor menselijke configuratiebestanden, maakt het witruimtegevoelige karakter en de sleutelherhaling het suboptimaal voor datacontext met grote volumes. In de test 'E-commerce bestellingen' gebruikte YAML ~14% meer tokens dan TOON.
Wanneer overstappen?
De gegevens zijn redelijk overtuigend. Als u te maken heeft met:
- Lijsten met objecten: Logboeken, transactiegeschiedenis, zoekresultaten of productcatalogi.
- RAG Pipelines: Waar u stukjes gegevens uit een database ophaalt en in een prompt invoert.
- API's met hoog volume: Waar bandbreedte en latentie van belang zijn.
TOON biedt een ‘best of two worlds’-scenario. U krijgt de dichtheid van CSV met de structurele integriteit van JSON.
In de benchmarks behaalde GPT-5-nano een verbluffende 90,9% nauwkeurigheid op gegevens in TOON-formaat. Dit suggereert dat nieuwere, slimmere modellen steeds bedrevener worden in het parseren van deze geoptimaliseerde formaten, wat betekent dat de "leesbaarheidsstraf" van het afstappen van JSON in feite nul is voor de machine.
Als u uw RAG-context nog steeds opmaakt als JSON.stringify(data, null, 2), betaalt u feitelijk een "leesbaarheidsbelasting" op elke afzonderlijke API-aanroep. Het is misschien tijd om van formaat te wisselen.