TOON: компактный формат данных для LLM, когда JSON становится слишком «дорогим»

Большие языковые модели (LLM) работают с текстом через токены и имеют ограничение по размеру контекста. Поэтому в прикладных задачах часто упираешься не в «умность» модели, а в банальную вместимость: сколько фактов ты успел передать в запросе, прежде чем закончился лимит. На этом фоне привычный JSON внезапно оказывается не лучшей упаковкой: он удобен для машин, но слишком многословен для промпта.

TOON (Token Oriented Object Notation) — практичный текстовый формат, который сохраняет структуру «объект/массив/поля», но уплотняет представление, уменьшая долю служебного синтаксиса и повторов. Он особенно полезен, когда нужно передать модели много однотипных строк: каталоги, логи, выборки, транзакции, табличные справочники.

1) Почему JSON в промпте часто проигрывает

Главная причина — повтор ключей. В JSON массив объектов выглядит так, что в каждой строке снова и снова повторяются одинаковые имена полей. Это отлично для универсального парсинга, но в промпте повторяющиеся ключи не добавляют новой смысловой информации, занимая место, которое могло бы уйти на дополнительные строки данных.

Вторая причина — высокая «пунктуационная плотность». Кавычки, фигурные и квадратные скобки, двоеточия, запятые — всё это неизбежно. В сумме получается, что вы передаёте модели много структуры, но сравнительно мало фактов.

Третья причина — сложность смешивать «правила» и «данные». В реальном промпте вам почти всегда нужно: (а) описать задачу, формат ответа и ограничения, (б) дать данные. В JSON это часто превращается в большой мешок из вложенных объектов, который неудобно читать и отлаживать глазами.

2) Идея TOON: схема отдельно, значения отдельно

TOON делает ставку на простой принцип: если у вас массив однотипных объектов, то имена полей можно объявить один раз, а дальше передавать значения строками, как таблицу. При этом формат остаётся структурированным: можно описывать вложенные объекты, массивы, метаданные и параметры задачи.

Ниже — базовые конструкции, которых обычно достаточно для большинства сценариев:

• Скаляр: ключ: значение

• Объект: ключ: и далее блок с отступом

• Простой массив: ключ[N]: v1,v2,v3

• Табличный массив: ключ[N]{поле1,поле2,...}: и далее N строк значений

Минипример «табличного массива»:

employees[3]{name,age,city}: 
Иванов,30,Москва 
Петров,25,Казань 
Сидоров,35,Сочи

Именно табличный режим даёт основной выигрыш: ключи вынесены в заголовок и не повторяются в каждой строке.

Тот же массив в JSON:

[ 
{"name":"Иванов","age":30,"city":"Москва"}, 
{"name":"Петров","age":25,"city":"Казань"}, 
{"name":"Сидоров","age":35,"city":"Сочи"} 
]

Смысл тот же, но «лишнее» (повтор ключей, кавычки вокруг ключей) исчезает.

«Инструкция + данные» в одном формате

Практически всегда полезно держать рядом правила и входные строки. TOON делает это естественно:

request:
  task: "Сравни варианты и дай рекомендацию"
  output:
    format: "markdown"
    sections[4]: "Кратко","Плюсы","Минусы","Риски"
    style: "деловой, без воды"
  constraints:
    budget_rub: 150000
    region: "RU"
  items[4]{id,title,price,category}:
    A1,"Сервер",450000,hardware
    B2,"Лицензия 1С",85000,software
    C3,"Поддержка",120000,services
    D4,"Калибр",19900,tooling

Вверху — управляющая часть промпта, ниже — таблица сущностей. Это легко читать глазами, удобно логировать и просто расширять новыми блоками.

Логи и события

Логи — идеальный кандидат: одинаковая схема, много строк.

audit[6]{ts,level,actor,action,entity}: 
2026-02-06T09:01:12,INFO,web,login,user:124 
2026-02-06T09:03:40,WARN,web,rate_limit,ip:10.0.0.5 
2026-02-06T09:05:10,INFO,svc,update,order:771 
2026-02-06T09:06:11,ERROR,svc,timeout,endpoint:/pay 
2026-02-06T09:07:02,INFO,web,logout,user:124 
2026-02-06T09:07:30,INFO,svc,retry,endpoint:/pay

 

Дальше достаточно одной строки инструкции: «Найди причины ошибок, сгруппируй по action, предложи меры».

Неоднородные структуры (когда «таблица» уже не честная)

Если элементы массива реально разные, не надо насильно загонять их в таблицу. TOON допускает «список объектов» с отступами:

offers[3]:
  -
    id: A1
    price: 450000
    delivery_days: 14
  -
    id: B2
    price: 85000
    discount: 0.1
  -
    id: C3
    price: 120000
    notes: "Можно помесячно"

 

Практическое правило: однородность — табличный массив, неоднородность — список объектов.

4) Практика: типы, кавычки, разделители и «профиль формата»

Чтобы TOON работал устойчиво, важно один раз договориться о «профиле» — наборе правил, по которым формат пишется и читается.

Типы (рекомендуемая договорённость)

Обычно удобно поддержать простые литералы:

• true / false — булево

• null — пустое значение

• числа — с точкой в дробной части: 123, -10, 45.67

• даты/время — ISO вид: 2026-02-06, 2026-02-06T14:30:00

Главное — не оставлять это «на авось». Если один источник пишет 12,5, а другой ждёт 12.5, ошибки будут системными.

Разделитель

Чаще всего это запятая, но иногда удобнее ;, если у вас много текстовых полей с запятыми. Важно: разделитель должен быть один и тот же во всех табличных блоках.

Кавычки и экранирование

Это самая частая точка поломки. Минимальное правило:

• Если значение содержит разделитель, кавычку или перевод строки — оно должно быть в кавычках.

• Внутренние кавычки экранируются (например, удвоением "").

Пример:

 products[2]{sku,title,comment}:
  A1,"Кабель, 2 м","Подходит для ""старых"" устройств"
  B2,"Блок питания","Без комментариев"

Если эти правила не зафиксировать, данные станут неоднозначными: парсер не поймёт, где колонка, а где часть текста.

Схема и порядок полей

В табличном массиве порядок полей — часть контракта. Менять поля «на лету» нельзя: либо начинайте новый блок с новой схемой, либо переходите на неоднородный список объектов.

5) Где TOON выигрывает сильнее всего (и где может не подойти)

Лучшие сценарии

• Большие справочники и выборки: много строк, одна схема.

• Логи, события, трейсинг: структурированные записи.

• Классификация/ранжирование: матрицы признаков, сравнительные таблицы.

• Смешанные промпты: «правила + таблица данных + дополнительные таблицы».

В этих задачах TOON обычно позволяет уместить заметно больше строк данных в тот же лимит контекста. Иногда это напрямую улучшает качество ответа: меньше «угадываний», больше фактов.

Когда стоит подумать дважды

• Много многострочных текстов в ячейках (письма, описания с абзацами).

• Сильно вложенные, неоднородные структуры, где почти каждый элемент имеет уникальный набор полей.

• Требование строгой совместимости с чужими системами и готовыми библиотеками (там JSON всё ещё вне конкуренции).

TOON — инструмент упаковки для промпта, а не религия. Его удобно использовать как промежуточный формат: «данные → TOON → LLM», а дальше при необходимости возвращаться в JSON для API, валидаторов и контрактов.