TL;DR
Исследование проверяет простую идею: если просить модель отвечать не готовым кодом (HTML/JavaScript), а коротким декларативным описанием (JSON-«рецептом», который проигрывает готовая программа), то выйдет дешевле, быстрее и надёжнее. Ответ действительно получается на 25–48% короче. Но время и стоимость почти не падают. Надёжность тоже не растёт: свободный код чаще работает с первого раза.
Причина в том, что у моделей с рассуждением (reasoning-моделей) ответ — только видимая часть работы. Перед ним модель «думает» отдельным потоком токенов, и за него вы тоже платите временем и деньгами. Когда формат непривычный, Claude начинает думать заметно дольше. На задачах со спецификацией доля генераций с рассуждением у больших моделей выросла примерно с 15–20% до 85–88%. Открытая Qwen3-14B думала долго в обоих форматах, поэтому короткий ответ почти ничего не сэкономил на фоне длинного рассуждения. Ещё хуже с надёжностью: формат, который модель выучила только из пары примеров в промпте, у малой модели давал валидный результат лишь в трети случаев. Свободный HTML/JS у неё давал рабочий результат в 62% случаев против 17% у спецификации.
Метод здесь — протокол честного сравнения, а не техника промпта. Одни и те же задачи, одни и те же правила и по два рабочих примера в каждом формате. Одинаковые автоматические проверки состояния для обоих форматов. Мерить нужно всё, что модель сгенерировала: токены ответа, токены рассуждений, время, долю рабочих результатов. Одну длину ответа мерить нельзя.
Схема: как проверить формат вывода перед внедрением
ШАГ 1: Одно и то же задание в двух форматах (свободный код / ваш компактный формат)
→ одинаковый бриф, правила, по 2 рабочих примера в каждом формате
ШАГ 2: Требуем от обоих форматов один «контракт» — выдать состояние в одном виде
→ одни и те же проверки работают для обоих
ШАГ 3: Прогоняем каждую задачу несколько раз (в исследовании — по 3)
→ один запрос = одна генерация + одна попытка исправления по тексту ошибок
ШАГ 4: Сравниваем не длину ответа, а всё:
→ токены ответа, токены рассуждений, время, % валидных, % верных по смыслу
Шаги 1–2 — это промпты. Шаги 3–4 вручную делает любой человек из команды на 10–20 задачах.
Пример применения
Задача: Вы делаете для отдела продаж банка внутреннего ассистента, который объясняет клиентам ипотеку. Нужен интерактивный виджет «как растёт платёж и падает остаток долга» с ползунками «ставка» и «срок». Соблазн велик: придумать свой короткий JSON-формат («сэкономим токены, зато быстро и надёжно»). Но у вас нет рантайма, а модель знает формат только из двух примеров. Сначала проверьте на практике, что выгоднее.
Промпт (вариант «свободный HTML/JS»):
Ты делаешь интерактивное объяснение для клиента Сбера: как работает
аннуитетный платёж по ипотеке.
ЗАДАЧА
Напиши один самодостаточный HTML-файл (без сети), который анимирует
первые 24 месяца платежей и показывает, как в платеже меняется доля
процентов и доля основного долга.
ПАРАМЕТРЫ, КОТОРЫЕ МЕНЯЕТ ПОЛЬЗОВАТЕЛЬ
- sum: сумма кредита, от 1 000 000 до 20 000 000 ₽, по умолчанию 6 000 000, шаг 100 000
- rate: ставка, % годовых, от 5 до 25, по умолчанию 18, шаг 0,5
- term: срок, лет, от 1 до 30, по умолчанию 20, шаг 1
СОСТОЯНИЕ, КОТОРОЕ ОБЯЗАНО ПОКАЗЫВАТЬСЯ
- month — номер месяца (с 1)
- payment — аннуитетный платёж, ₽
- interest — часть платежа на проценты, ₽
- principal — часть платежа на основной долг, ₽
- balance — остаток долга после платежа, ₽
ПРАВИЛА
- Формула аннуитета стандартная; проценты считаются на остаток долга на начало месяца.
- Каждое состояние (каждый месяц) видно на экране не меньше 0,3 секунды.
- Рисунок и числа берутся из одних и тех же переменных.
КОНТРАКТ (обязательно)
Страница должна выставлять объект window.__explain с полями:
duration, params (текущие значения), seek(t) — детерминированный переход
к моменту t, getState() — вернуть переменные состояния в текущий момент,
setParam(name, value).
ПРИМЕР 1: [вставь рабочий пример на другой задаче]
ПРИМЕР 2: [вставь второй рабочий пример]
Затем: возьмите те же 8–10 задач и тот же бриф, но с вашим коротким форматом. Пропустите оба варианта через одинаковую проверку и сравните не длину, а итоги.
Результат: Модель выдаст HTML-страницу со стандартной структурой, анимацией и ползунками. Через getState() вы сверите числа с расчётом в Excel без визуальной проверки на глаз. Дальше сравнение покажет, дают ли короткий формат и свободный код разное время ответа, число повторных попыток и долю верных расчётов. Исследование предупреждает: не рассчитывайте на выигрыш только потому, что ответ короче.
Почему это работает
Слабость. Длина видимого ответа почти ничего не говорит о стоимости. У reasoning-моделей часть работы скрыта в «мыслях». Когда формат непривычный, модель тратит больше мыслей на то, чтобы не ошибиться в синтаксисе и в правилах. Выигрыш в ответе съедается рассуждением.
Сильная сторона. Модели отлично пишут HTML/JS, потому что в обучении видели его огромное количество. Им не нужно думать о формате, они сосредоточены на содержании. Поэтому свободный код с одной попыткой исправления почти всегда запускается, хотя он длиннее.
Как метод обходит слабость. Сравнение идёт по всей работе модели, а не по размеру ответа. Единый «контракт» состояния делает проверку одинаковой для обоих форматов и убирает субъективное «выглядит правильно».
Рычаги управления: - Число параметров и вариантов. Каждую задачу проверяют при 2–3 значениях параметров, и параметр, который объяснение игнорирует, сразу ломает проверку. Добавляйте значения, чтобы поймать «обманки». - Примеры в промпте. В исследовании по два рабочих примера в каждом формате. Дайте больше примеров на сложных схемах, чтобы снизить риск ошибок. - Попытки исправления. Одна попытка по тексту ошибок. Для вашего процесса можно ставить две-три, но считайте их в стоимость. - Контракт. Выбирайте поля, которые легко проверить вручную: итоговые числа, этапы, очередь.
Шаблон промпта
Это шаблон «свободный код + контракт состояния» из исследования, его HTML/JS-условие. Если захотите сравнить с компактным форматом, дайте во втором прогоне тот же бриф, но с описанием своего формата и примерами в нём.
Ты делаешь интерактивное объяснение: {тема}.
ЗАДАЧА
Напиши один самодостаточный HTML-файл (без доступа к сети), который
анимирует {что именно показать} и даёт пользователю элементы управления.
ПАРАМЕТРЫ, КОТОРЫЕ МЕНЯЕТ ПОЛЬЗОВАТЕЛЬ
{параметр_1}: от {мин} до {макс}, по умолчанию {знач}, шаг {шаг}
{параметр_2}: ...
СОСТОЯНИЕ, КОТОРОЕ ОБЯЗАНО ПОКАЗЫВАТЬСЯ
{переменная_1} — {смысл, единицы}
{переменная_2} — ...
ПРАВИЛА
- {правила и соглашения предметной области, например формулы, порядок шагов}
- Каждое отдельное состояние видно на экране не меньше {секунд} секунд.
- Рисунок и числа берутся из одних и тех же переменных.
КОНТРАКТ (обязательно)
Страница выставляет объект window.__explain:
- duration — общая длительность
- params — текущие значения параметров
- seek(t) — детерминированный переход к моменту t
- getState() — вернуть переменные состояния в текущий момент
- setParam(name, value) — изменить параметр
ПРИМЕР 1: {краткий рабочий пример на другой задаче}
ПРИМЕР 2: {второй рабочий пример}
Подставьте:
- {тема} и {что показать} — суть объяснения.
- параметры — только те, что реально должен менять пользователь.
- переменные состояния — всё, что вы потом будете сверять с эталоном.
- правила — спорные места предметной области, где возможны разные трактовки.
- примеры — настоящие, рабочие и из другой темы, чтобы модель не копировала содержание.
🚀 Быстрый старт — вставь в чат:
Вот шаблон задания на интерактивное объяснение с контрактом состояния.
Адаптируй под мою задачу: [твоя тема и что нужно объяснить].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про параметры, которые будет менять пользователь, переменные состояния и спорные правила предметной области. Это нужно, чтобы вы потом проверили результат по цифрам, а не «на глаз». Примеры она возьмёт из шаблона и перестроит под вашу тему.
Ограничения
⚠️ Узкая область: тестировали только анимированные объяснения (физика, алгоритмы, сети, ML, вероятность) на 20 задачах. Для текстов, таблиц и обычных JSON-ответов результат может быть другим.
⚠️ Формат учили только в промпте: модели видели компактный формат в двух примерах и в описании. Модель, которую дообучили на формате, или формат, который она знает по обучению (обычный JSON-схема, Markdown), может вести себя иначе. В описании формата из этой работы это не проверяли.
⚠️ Большая часть эффектов не достигла значимости: по времени генерации значимого ускорения нет ни у одной модели. Суммарный размер вывода достоверно упал только у самой большой модели Claude. У самой малой он вырос.
⚠️ Объяснение механизма — гипотеза: рост рассуждений у Claude на спецификациях описан как исследовательская (exploratory) находка. Предварительно заявленную проверку такого сдвига у Qwen не подтвердили.
⚠️ Правильность, а не польза: проверяли верность состояния и работоспособность, а не то, лучше ли человек поймёт объяснение. Авторы сами оговаривают, что польза анимации для обучения спорна.
⚠️ Часть цифр про Qwen — из аннотации: в обрезанном тексте подробные таблицы для Qwen не приведены.
Как исследовали
Идея была в том, чтобы убрать все смешивающие факторы. Автор написал 20 заданий на интерактивные объяснения: падение снаряда, TCP-рукопожатие, градиентный спуск, задача Монти Холла и т. д. Каждое задание получило подробный бриф: параметры, нужные переменные, строгие правила, где возможны разные конвенции (например, схема разбиения в быстрой сортировке).
Все задания решались в двух форматах: свободный HTML/JS и ExplainSpec — изобретённый автором JSON-формат с таймлайном, которым управляет готовый рантайм. Промпты были почти одинаковой длины (около 12 тыс. символов) и содержали одинаковые правила и по два рабочих примера. Три модели Claude прогнали каждую задачу по 3 раза в обоих форматах: 360 запусков с одной попыткой исправления по тексту ошибок. Потом на Qwen3-14B с включённым и выключенным рассуждением добавили ещё 240 запусков.
Чтобы проверять одинаково, оба формата обязали выставить «контракт» со getState(). Проверки сравнивают состояния с эталоном независимо от скорости анимации. Их предварительно проверили на 40 эталонных реализациях и на 1 430 намеренно испорченных вариантах. Отсеялись 98,5% испорченных. Гипотезы и план анализа зафиксировали заранее хешами файлов, чтобы не подгонять выводы.
Результаты оказались неожиданными. Токены ответа упали на 25–40% (Claude) и на 25–48% (все четыре модели). Но у Claude вырос объём рассуждений. Например, у Opus рассуждения были лишь в 9 из 60 запусков HTML, а в формате спецификации — в 51 из 60. В итоге суммарный вывод достоверно уменьшился только у Opus (в 0,81 раза), у Sonnet остался прежним, у Haiku вырос. Время генерации ни у кого не уменьшилось значимо. После исправления доли верных результатов у спецификации тоже были ниже, чем у HTML. Для Qwen3-14B валидных спецификаций было 33%, а все семантические проверки проходили в 17% (у HTML/JS — 62%).
Практический вывод: длина ответа и стоимость генерации — разные величины. Прежде чем внедрять «короткий» формат ради экономии, прогоните собственный мини-эксперимент.
Адаптации и экстраполяции
Это мои идеи по мотивам статьи, не часть оригинального метода.
🔧 Техника: добавить обязательный вывод состояния → дешёвая проверка без автотестов
Если у вас нет браузерного стенда, попросите модель в конце ответа вывести таблицу ключевых значений на нескольких наборах параметров:
В конце после кода выведи таблицу: для параметров {набор_1}, {набор_2}, {набор_3}
значения {переменные_состояния} на каждом шаге.
Вы сверяете таблицу с эталоном в Excel. Так проверка выполняется человеком из команды, как в исследовании, только без Playwright.
Экстраполяция: проверка «умного» формата в автоматизации. Если в вашей автоматизации (Make, n8n, Zapier) вы просите модель отвечать строго в JSON ради «экономии», прогоните 10–20 типовых запросов в двух вариантах:
Вариант А: ответь свободным текстом, затем отдельно выдели поля.
Вариант Б: ответь сразу в JSON по схеме {схема}.
Запишите для каждого: токены ответа, общее время, долю валидных ответов, долю верных по смыслу. Если Б не выигрывает по времени и верности, оставьте А. Прямого подтверждения этого для текстовых задач в статье нет — это идея для вашей проверки.
Ресурсы
- Работа: Shorter Is Not Cheaper: A Controlled Comparison of Declarative Animation Specifications and Free-Form Code for LLM-Generated Explanations — Jiantang Huang, Northeastern University (preprint).
- Упомянутые в статье форматы и системы: A2UI, json-render, OpenUI, ChatGPT Intelligent UI, ALGOGEN, Keyframer, DataMagic, InteractScience.
- Формат ExplainSpec и «контракт наблюдения»
window.__explainописаны в разделе 3 статьи.