Почему TOON превосходит другие форматы

Если вы создаете приложения LLM, в частности системы или агенты с расширенной генерацией данных (RAG), которые потребляют большие наборы данных, вы, вероятно, ведете постоянную войну на двух фронтах: стоимость токена и ограничения контекстного окна.

В течение многих лет JSON был языком обмена данными по умолчанию. Он удобен для чтения человеком (в основном) и вездесущ. Но когда вы вставляете в приглашение массив JSON из 500 строк, вы сжигаете тысячи токенов в повторяющихся именах полей («id»:, "name":, "email":`), которые несут нулевое семантическое значение для конкретной строки.

Введите TOON. Этот формат разработан специально для решения проблемы соотношения сигнал/шум на входах LLM. Я изучал последние тесты, и результаты поразительны: TOON не просто экономит место; на самом деле это помогает таким моделям, как GPT-5-nano и Gemini-2.5-flash, лучше понимать данные.

Давайте разберемся, почему TOON побеждает тяжеловесов (JSON, CSV, YAML, XML) и посмотрим на чистые цифры.

Ловушка многословия: JSON против TOON

Самый большой враг эффективности токена — повторение структуры. Давайте посмотрим на стандартный набор данных Time-Series Analytics. В JSON каждая точка данных несет в себе багаж своей схемы.

JSON (стандартный) Токены, использованные в тесте: 22,250

Это много пустого пространства. Теперь взгляните на эквивалент TOON. TOON определяет схему один раз в заголовке, а затем переключается на плотный формат значений в стиле CSV.

Мультфильм Токены, использованные в тесте: 9,120

Результат: Массовое сокращение использования токенов на 59,0 %.

Удалив повторяющиеся ключи, TOON позволяет вам вместить больше истории в контекстное окно модели. Но что особенно важно, в отличие от CSV, он поддерживает понимание типа и явную структуру через определение заголовка metrics[5]{...}.

Почему бы просто не использовать CSV?

Это самый распространенный контраргумент. «Если вам нужны плоские данные, просто используйте CSV».

Проблема в том, что реальные данные редко бывают идеально однородными. CSV полностью разваливается в тот момент, когда у вас есть вложенные структуры, списки внутри объектов или сложные описания, содержащие запятые и кавычки.

В тестах, в частности в режиме Смешанная структура (который включает заказы электронной коммерции и журналы событий), CSV был полностью исключен, поскольку он не мог представлять данные без выравнивания с потерями.

TOON справляется с этим изящно. Он позволяет использовать вложенные объекты при оптимизации массивов. В тесте 100 репозиториев GitHub (которые содержат смешанные текстовые описания и метаданные) разрыв в эффективности был очевиден:

• JSON: 15 145 токенов

• TOON: 8745 токенов (экономия 42,3%)

Даже по сравнению с JSON Compact (минифицированным) TOON все равно добился почти на 24 % большей экономии. Когда вы платите за миллион токенов, это немедленная окупаемость инвестиций.

Точность: неожиданный победитель

Вот та часть, которая меня удивила. Обычно при сжатии данных теряется четкость. Можно было бы ожидать, что LLM будет с трудом анализировать более плотный формат. Тесты показывают обратное.

По 209 вопросам поиска данных, протестированным на таких моделях, как Claude Haiku, Gemini Flash и GPT-5-nano, TOON достиг точности 73,9% по сравнению со стандартным JSON 69,7%.

Почему? Скорее всего, все сводится к Когнитивной нагрузке (или ее эквиваленту LLM).

1. Меньше шума: модели не нужно обрабатывать тысячи повторяющихся «ключевых» токенов. Соответствующие ценности находятся ближе друг к другу в механизме внимания.

2. Явные метаданные: Заголовки TOON явно включают счетчик ([N]) и имена полей.

3. Осведомленность о структуре. В тестах, в которых задавался вопрос о структуре набора данных (например, «Сколько строк?»), TOON достиг точности 88 %, тогда как JSON и XML отставали. Явный счетчик в заголовке TOON (repositories[100]) действует как подсказка, которая не позволяет модели «подсчитывать» токены вручную, с чем LLM, как известно, плохо справляются.

Усталость от XML и YAML

Отдельно стоит упомянуть остальных претендентов.

XML здесь сильно проигрывает. Он многословен, труден для чтения и требует больших затрат на обработку. В тестах XML последовательно использовал наибольшее количество токенов (более 5000 для единого набора записей сотрудников, который TOON представлял примерно в 2700) и имел самую низкую точность (67,1%).

YAML работает лучше, чем XML, но по-прежнему страдает от раздувания токенов по сравнению с TOON. Хотя YAML отлично подходит для файлов конфигурации, созданных человеком, его чувствительный к пробелам характер и повторение ключей делают его неоптимальным для контекста больших объемов данных. В тесте «Заказы электронной коммерции» YAML использовал примерно на 14% больше токенов, чем TOON.

Когда переключаться?

Данные достаточно убедительны. Если вы имеете дело с:

1. Списки объектов: журналы, истории транзакций, результаты поиска или каталоги продуктов.

2. Конвейеры RAG: где вы извлекаете фрагменты данных из БД для подачи в командную строку.

3. API для больших объемов трафика: там, где важны пропускная способность и задержка.

TOON предлагает сценарий «лучшего из обоих миров». Вы получаете плотность CSV со структурной целостностью JSON.

В тестах GPT-5-nano достиг ошеломляющей точности 90,9% при обработке данных в формате TOON. Это говорит о том, что новые, более умные модели становятся все более способными анализировать эти оптимизированные форматы, а это означает, что «штраф за читаемость» при отказе от JSON фактически равен нулю для машины.

Если вы по-прежнему форматируете свой контекст RAG как JSON.stringify(data, null, 2), вы фактически платите «налог на читаемость» за каждый отдельный вызов API. Возможно, пришло время сменить формат.