Dlaczego TOON przewyższa inne formaty

Jeśli tworzysz aplikacje LLM, w szczególności systemy lub agentów generacji rozszerzonej odzyskiwaniu (RAG), które zużywają duże zbiory danych, prawdopodobnie toczysz ciągłą wojnę na dwóch frontach: koszt tokena i limity okna kontekstowego.

Przez lata JSON był domyślnym językiem wymiany danych. Jest czytelny dla człowieka (w większości) i wszechobecny. Ale kiedy wkleisz 500-wierszową tablicę JSON do zachęty, spalasz tysiące tokenów w powtarzających się nazwach pól („id”:, „nazwa”:, „email”:`), które niosą zerową wartość semantyczną dla określonego wiersza.

Wpisz TOON. Jest to format zaprojektowany specjalnie w celu rozwiązania problemu stosunku sygnału do szumu na wejściach LLM. Przeglądałem najnowsze testy porównawcze i wyniki są zaskakujące: TOON nie tylko oszczędza miejsce; w rzeczywistości pomaga modelom takim jak GPT-5-nano i Gemini-2.5-flash lepiej rozumieć dane.

Przyjrzyjmy się, dlaczego TOON pokonuje najcięższych graczy (JSON, CSV, YAML, XML) i spójrzmy na surowe liczby.

Pułapka gadatliwości: JSON kontra TOON

Największym wrogiem wydajności tokenów jest powtarzalność struktury. Przyjrzyjmy się standardowemu zbiorowi danych analizy szeregów czasowych. W JSON każdy pojedynczy punkt danych niesie bagaż swojego schematu.

JSON (standardowy) Tokeny użyte w benchmarku: 22 250

To mnóstwo zmarnowanej przestrzeni. Teraz spójrz na odpowiednik TOON. TOON definiuje schemat raz w nagłówku, a następnie przełącza wartości na gęsty układ w stylu CSV.

TOON Tokeny użyte w benchmarku: 9120

Rezultat: Ogromna 59,0% redukcja wykorzystania tokenów.

Usuwając powtarzające się klawisze, TOON pozwala zmieścić więcej historii w oknie kontekstowym modelu. Ale co najważniejsze, w przeciwieństwie do CSV, zachowuje świadomość typu i wyraźną strukturę poprzez definicję nagłówka metrics[5]{...}.

Dlaczego nie użyć po prostu pliku CSV?

To najczęstszy kontrargument. „Jeśli chcesz mieć płaskie dane, po prostu użyj CSV”.

Problem polega na tym, że dane ze świata rzeczywistego rzadko są idealnie płaskie. CSV psuje się całkowicie w momencie zagnieżdżenia struktur, list w obiektach lub złożonych opisów zawierających przecinki i cudzysłowy.

W testach porównawczych, w szczególności w ścieżce o strukturze mieszanej (która obejmuje zamówienia e-commerce i dzienniki zdarzeń), plik CSV został całkowicie wykluczony, ponieważ nie mógł reprezentować danych bez spłaszczania strat.

TOON radzi sobie z tym z wdziękiem. Pozwala na zagnieżdżanie obiektów podczas optymalizacji tablic. W teście 100 repozytoriów GitHub (zawierających mieszane opisy tekstowe i metadane) luka w wydajności była wyraźna:

• JSON: 15 145 tokenów

• TOON: 8745 tokenów (42,3% oszczędności)

Nawet w porównaniu z JSON Compact (zminimalizowanym) TOON nadal wygenerował prawie 24% więcej oszczędności. Kiedy płacisz za milion tokenów, jest to natychmiastowy zwrot z inwestycji.

Dokładność: zwycięzca-niespodzianka

Oto część, która mnie zaskoczyła. Zwykle podczas kompresji danych tracisz przejrzystość. Można się spodziewać, że LLM będzie miał trudności z analizą gęstszego formatu. Benchmarki pokazują coś przeciwnego.

W przypadku 209 pytań dotyczących pobierania danych przetestowanych na modelach takich jak Claude Haiku, Gemini Flash i GPT-5-nano, TOON osiągnął 73,9% dokładności wyszukiwania w porównaniu do standardowego JSON 69,7%.

Dlaczego? Prawdopodobnie sprowadza się to do Obciążenia poznawczego (lub odpowiednika LLM).

1. Mniej hałasu: Model nie musi zajmować się tysiącami powtarzających się żetonów „kluczy”. Odpowiednie wartości są bliżej siebie w mechanizmie uwagi.

2. Jawne metadane: nagłówki TOON zawierają jawnie liczbę („[N]”) i nazwy pól.

3. Świadomość struktury: w testach pytających o strukturę zbioru danych (np. „Ile jest wierszy?”), TOON osiągnął 88% dokładności, podczas gdy JSON i XML pozostawały w tyle. Wyraźna liczba w nagłówku TOON („repozytoria [100]”) działa jako wskazówka, która zapobiega konieczności ręcznego „liczenia” tokenów przez model, co jest notorycznie kiepskie dla LLM.

Zmęczenie XML i YAML

Warto krótko wspomnieć o pozostałych pretendentach.

XML jest tutaj głównym przegranym. Jest gadatliwy, trudny do odczytania i kosztowny w przetwarzaniu. W testach porównawczych XML konsekwentnie wykorzystywał najwięcej tokenów (ponad 5000 dla jednolitego zestawu rekordów pracowników, które TOON reprezentował w ~2700) i miał najniższą dokładność (67,1%).

YAML działa lepiej niż XML, ale nadal cierpi z powodu rozdęcia tokenów w porównaniu z TOON. Chociaż YAML doskonale nadaje się do plików konfiguracyjnych wykonywanych przez ludzi, jego charakter uwzględniający białe znaki i powtarzalność klawiszy sprawiają, że nie jest on optymalny w kontekście danych o dużej objętości. W teście „Zamówienia e-commerce” YAML użył ~14% więcej tokenów niż TOON.

Kiedy zmienić?

Dane są dość jednoznaczne. Jeśli masz do czynienia z:

1. Listy Obiektów: Logi, historie transakcji, wyniki wyszukiwania czy katalogi produktów.

2. RAG Pipelines: Miejsce, w którym pobierasz fragmenty danych z bazy danych w celu wprowadzenia ich do podpowiedzi.

3. Interfejsy API o dużej objętości: Tam, gdzie liczy się przepustowość i opóźnienia.

TOON oferuje scenariusz „najlepszy z obu światów”. Otrzymujesz gęstość CSV z integralnością strukturalną JSON.

W testach porównawczych GPT-5-nano osiągnął zdumiewającą dokładność 90,9% danych w formacie TOON. Sugeruje to, że nowsze, inteligentniejsze modele stają się coraz bardziej biegłe w analizowaniu zoptymalizowanych formatów, co oznacza, że ​​„kara za czytelność” wynikająca z odejścia od JSON jest w rzeczywistości zerowa dla maszyny.

Jeśli nadal formatujesz kontekst RAG jako JSON.stringify(data, null, 2), w rzeczywistości płacisz „podatek od czytelności” za każde pojedyncze wywołanie API. Być może nadszedł czas na zmianę formatu.