Большие языковые модели (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, валидаторов и контрактов.
Вступайте в нашу телеграмм-группу Инфостарт