TOON – nowoczesny format danych zoptymalizowany dla AI i LLM

TOON (Token-Oriented Object Notation) to relatywnie nowy format serializacji danych zaprojektowany z myślą o modelach językowych (LLM) i aplikacjach AI. Zgodnie z oficjalną specyfikacją, TOON to kompaktowy, czytelny dla człowieka format, który pozwala przesyłać te same dane co JSON, zużywając przy tym znacznie mniej tokenów. Krótko mówiąc, TOON to sposób na reprezentowanie struktur danych w formie zbliżonej do tabeli, który ma zoptymalizować koszt i szybkość przetwarzania w systemach opartych na LLM. Wprowadzono go właśnie dlatego, że w kontekście AI „każdy znak ma znaczenie” – nadmiarowe nawiasy, cudzysłowy czy separatory z JSON-a mogą znacząco zwiększać obciążenie tokenowe promptów.

Czym TOON różni się od JSONa

TOON łączy cechy języków takich jak YAML i CSV. Zamiast tradycyjnej składni JSON ({}, [], :, ,), używa wcięć i struktury tabelarycznej do wyrażania danych. Przykładowo, zamiast pisać:

{
  "users": [
    {"id": 1, "name": "Alice"},
    {"id": 2, "name": "Bob"}
  ]
}

w TOON zrobi się to tak:

users[2]{id,name}:
  1,Alice
  2,Bob

W pierwszym wierszu podajemy nazwę tablicy (users), jej długość ([2]) oraz nagłówki kolumn ({id,name}). Kolejne linie to wiersze danych rozdzielone przecinkami. Dzięki temu znika potrzeba powtarzania klucza "id" i "name" dla każdego obiektu – klucze deklarujemy raz na początku.

Składnia i struktura. JSON jest bardzo elastyczny i powszechnie znany – używa klamr, nawiasów, cudzysłowów i przecinków do określenia struktur danych. TOON zamiast tego opiera się na wcięciach (jak YAML) oraz pojedynczych liniach z polami oddzielonymi przecinkami (jak CSV). Dzięki temu kod wygląda czyściej: nie ma zbędnych nawiasów, każdy obiekt to linia w tabeli. Zagnieżdżanie struktury uzyskujemy po prostu przez dalsze wcięcie. Na przykład obiekt zagnieżdżony w JSON:

{ 
  "user": { 
    "id": 1, 
    "name": "Alice", 
    "profile": { "age": 30, "city": "Bengaluru" } 
  } 
}

w TOON zapisze się jako:

user:
  id: 1
  name: Alice
  profile:
    age: 30
    city: Bengaluru

Elastyczność i ograniczenia. JSON potrafi wyrazić dowolne zagnieżdżenie obiektów i tablic, łącznie z mieszanymi typami danych. TOON sprawdza się najlepiej przy jednorodnych (identycznych) obiektach w tablicach – jego „słodkie miejsce” to tablice obiektów o stałej liczbie pól. Głębokie, niestandardowe zagnieżdżenia czy mieszane typy w tablicy (np. naprzemiennie obiekt i prosta wartość) wymuszają bardziej skomplikowaną składnię TOON i mogą zmniejszyć jego przewagę. Dla bardzo głęboko zagnieżdżonych struktur JSON może nawet być bardziej kompaktowy.

Czytelność. JSON jest znany większości programistów i ma świetne wsparcie w narzędziach (lint, formatowanie, edytory). TOON może wydawać się nowy, ale jego formę łatwo ogarnąć – przypomina czytanie arkusza, gdzie nazwy kolumn są wyrównane, a wiersze danych czytelnie wypisane. Przy danych tabelarycznych TOON jest często bardziej przejrzysty, bo eliminuje cały „szum” składni JSON-a. Jednak osoby przyzwyczajone do JSON-a mogą potrzebować chwili przyzwyczajenia. Ponieważ TOON używa wcięć, trzeba uważać na spójność białych znaków – podobnie jak w YAML-ie, błędne wcięcie może psuć parsowanie.

Zalety TOON w porównaniu z JSON

• Oszczędność tokenów: TOON zwykle wymaga mniej liter i symboli niż odpowiadający JSON, co przekłada się na 30–60% oszczędności tokenów w typowych przypadkach. Mniej tokenów oznacza mniejszy koszt wysłania i przetworzenia prompta przez LLM (ponieważ systemy takie jak GPT liczą koszty przetwarzania na tokeny) oraz szybsze działanie przy dużych ilościach danych.
• Kompaktowość: Dzięki jednokrotnemu zdefiniowaniu nagłówków i braku zbędnych znaków TOON ma formę zbliżoną do CSV, ale z zachowaniem pełnej struktury danych. Można powiedzieć, że to lekka forma JSON-a przystosowana do formatu arkusza. W przykładzie z tablicą użytkowników wszystkie identyczne klucze przesuwają się na górę, co eliminuje powtarzanie i zmniejsza objętość.
• Łatwiejsza walidacja w LLM: TOON jawnie podaje liczbę elementów i kolejność kolumn, co ułatwia modelom językowym przetwarzanie danych. Wiadomo np. ile wierszy się spodziewać i jakie kolumny wystąpią, co może zmniejszyć ryzyko pomyłek po stronie LLM.
• Przystosowanie do AI: Format został stworzony właśnie do kontekstu AI, więc wiele implementacji (np. w Pythonie, JavaScript, Rust itp.) oferuje narzędzia do konwersji JSON⇄TOON. W praktyce TOON często traktuje się jako „warstwę” między JSON-em używanym w kodzie, a tekstem wysyłanym do modelu. Dzięki temu można nadal pracować z JSON-em w systemach, a do promptów przekonwertować dane do TOON (i z powrotem), wykorzystując dostępne biblioteki.
• Przejrzystość przy powtarzalnych danych: Jeśli mamy duże, jednorodne zestawy danych (np. logi, zestawienia sprzedaży, duże tabele itp.), TOON potrafi zrobić je czytelniejszymi dzięki układowi w tabelę.

Wady i ograniczenia TOON

• Mniejszy ekosystem: JSON ma dziesięciolecia wsparcia – biblioteki, edytory, narzędzia do debugowania i walidacji są niemal w każdym języku programowania. TOON dopiero powstaje jako technologia „następnej generacji”, więc ekosystem jest jeszcze niewielki. O ile istnieją już oficjalne pakiety (np. @toon-format/toon dla Node.js czy python-toon), to nie wszędzie będą wtyczki czy wsparcie online. Oznacza to, że trzeba polegać na zewnętrznych konwerterach lub pisać własne rozszerzenia.
• Nie dla każdej struktury: Jak wspomniano, TOON świetnie sobie radzi z jednorodnymi tablicami obiektów, ale przy bardzo złożonych lub mieszanych danych traci przewagę. Głębokie zagnieżdżenia bez wyraźnego układu kolumn mogą wymagać „na siłę” używania list i ponownego definiowania struktur, co znów zbliża format do JSON-a lub powoduje większą złożoność. Przy silnie nieregularnych danych JSON w czystym lub skompaktowanym zapisie może być bardziej ekonomiczny tokenowo.
• Brak pełnej kompatybilności narzędzi: Różne narzędzia (edytory, generatorzy kodu, bazy danych) spodziewają się zwykle JSON-a. TOON nie jest jeszcze standardem i raczej nie wyrzuci JSON-a z istniejących API czy narzędzi. W praktyce stosowanie TOON wiąże się z koniecznością konwersji do/z JSON-a w kodzie, co może wymagać dodatkowych kroków i testów.
• Możliwy koszt początkowy nauki: Dla zespołu przyzwyczajonego do JSON-a wdrożenie TOON wymaga poznania nowych zasad składni i zwrócenia uwagi na detale (jak wcięcia czy ograniczenie cudzysłowów). Warto to uwzględnić jako początkowy nakład pracy.

Przykłady użycia

Najprościej zobrazować TOON na przykładach:

• Tablica obiektów: Mamy listę użytkowników z identyfikatorem, imieniem i rolą. JSON: { "users": [ {"id": 1, "name": "Alice", "role": "admin"}, {"id": 2, "name": "Bob", "role": "user"} ] } TOON: users[2]{id,name,role}: 1,Alice,admin 2,Bob,user Schemat {id,name,role} definiuje kolumny, a każda linia to wiersz wartości. Takie przedstawienie jest bardziej zwarte – JSON-owi potrzebne były klamry, cudzysłowy i nawiasy, tutaj podajemy tylko wartości.
• Duże zestawy danych: Jeśli przesyłamy do modelu np. 100 podobnych obiektów, JSON wielokrotnie powtarza klucze. TOON eliminuje te powtórzenia, deklarując pola raz na górze. W testach przy dużych tablicach TOON uzyskiwał ~30–60% oszczędności tokenów względem JSON-a. Przykładowo JSON wymagający 180 tokenów dla kilku wierszy można zastąpić wersją TOON z ok. 85 tokenami, co bezpośrednio przekłada się na niższe koszty i szybsze czasy odpowiedzi od LLM.
• Wysyłanie danych w promptach do LLM: W aplikacjach AI (np. chatbotach, asystentach, systemach rekomendacyjnych) często w kontekście prompta umieszczamy stan użytkownika lub fragment bazy danych. Użycie TOON zamiast JSON w takim promptcie może znacząco zmniejszyć liczbę wysyłanych tokenów bez utraty struktury danych. Przykładowo zamiast ciągu JSON {...}, w TOON możemy przesłać analogiczny zestaw danych w postaci tabelarycznej, co redukuje objętość komunikatu.
• Przygotowywanie danych treningowych: Gdy zbieramy dane etykietowane lub generujemy przykłady dla LLM, TOON może ułatwić formatowanie zestawu wejść. Szczególnie w pipeline’ach ML, gdzie dysponujemy dużymi, ustrukturyzowanymi rekordami (np. utworzyć zbiór promptów z informacjami o produktach, klientach, zdarzeniach), TOON pozwala zapisać dane w prostszej formie niż JSON i zachować strukturę, co ułatwia automatyzację.

Gdzie TOON może się przydać

TOON jest idealny dla projektów i zespołów pracujących z technologiami generatywnej AI i LLM, zwłaszcza gdy koszt tokenów lub przepustowość danych odgrywają rolę. Przykładowe scenariusze:

• Aplikacje AI/ML: Firmy budujące systemy oparte na ChatGPT, GPT-4, Google Gemini czy Claude, gdzie strukturalne dane (np. listy, tabele) trafiają do promptów.
• Analityka danych i raporty w AI: Zespoły data science przetwarzające duże zestawy wyników, gdzie przestawienie ich w formie TOON zmniejszy objętość kontekstu.
• Startupy SaaS dla LLM: Software house’y i zespoły tworzące narzędzia do prompt engineeringu lub platformy AI, dla których oszczędność tokenów przekłada się na konkurencyjną cenę usługi.
• Projekt LLM-owa integracja: Gdy standardowe API wymaga JSON-a, można dane w systemie trzymać w JSON, a do modelu wysłać TOON (konwertując po stronie serwera). Zespół backendowy nadal używa JSON, ale szablon wysyłany do LLM można zoptymalizować przez TOON.

Słowem, TOON sprawdzi się tam, gdzie strukturalne, powtarzalne dane są często wysyłane do modeli językowych i trzeba zredukować ich „objętość tokenową”. Nie znaczy to, że TOON zastąpi JSON w tradycyjnych API czy bazach danych, ale jest doskonałym kandydatem do przetestowania w projektach AI/LLM.

Zobacz także: Konwerter JSON –> Toon

Potencjalne ograniczenia

Przy wszystkich zaletach TOON ma też ograniczenia, o których warto wiedzieć:

• Ekosystem i narzędzia: Jak wspomniano, JSON ma niewiarygodnie szerokie wsparcie – TOON jest nowy, więc nie znajdziemy go bezpośrednio w większości edytorów czy języków. Na przykład zapytania RESTful i frameworki oczekują JSON-a, więc użycie TOON wymaga dodatkowej konwersji. Poza tym debugowanie wcięć czy drobnych błędów składni TOON (np. brak przecinka) może być trudniejsze, bo istnieje mniej automatycznych walidatorów.
• Kompatybilność wstecz: Jeśli migracja do TOON dotyczy systemów legacy, trzeba rozważyć konwersję danych istniejących i to, czy wszystkie integracje poradzą sobie z TOON-em. Często rozwiązaniem jest przyjąć TOON tylko na potrzeby LLM (przekształcając JSON do TOON tuż przed wysłaniem) i trzymać JSON w bazach, co zmniejsza ryzyko przerwania kompatybilności.
• Ograniczona uniwersalność: Są przypadki, w których JSON (lub inne formaty jak YAML czy czyste CSV) jest lepszy. Na przykład bardzo głęboko zagnieżdżone obiekty bez stałych struktur tablic JSON może zapisać krócej. Dla czysto tabelarycznych danych CSV jest minimalnie bardziej skompaktowany niż TOON, bo TOON dodaje niewielki narzut na podanie nagłówków i długości tablic. Dlatego warto porównać: jeśli mamy typowe dane flat (array of objects), TOON będzie świetny, ale przy nietypowych strukturach może się okazać, że korzyści są minimalne.

Podsumowanie i rekomendacja

TOON to ciekawa nowość oraz “lekkie” rozszerzenie idei JSON-a na potrzeby ery AI. Daje realne oszczędności tokenów (30–60% mniej) przy zachowaniu przejrzystości danych. Dzięki temu może pomóc zarówno deweloperom (mniejsze koszty API, szybsze prompty), jak i klientom (tańsze przetwarzanie dużych kontekstów w LLM). Jednocześnie nie należy się spodziewać, że zastąpi on JSON we wszystkich zastosowaniach – to raczej format specjalistyczny, uzupełniający ekosystem narzędzi do budowy systemów AI.

Źródła:

• https://github.com/toon-format/toon
• https://dev.to/sreeni5018/toon-vs-json-a-modern-data-format-showdown-2ooc