TL;DR
Исследователи взяли повторно используемые инструкции (шаблоны задач, системные промпты — то, что они называют «навыками агента») и проверили: помогает ли их сокращение, переоформление в XML-структуры или фильтрация только нужных инструкций? Ответ: нет. Ни одна из «оптимизаций» формата не обошла обычный исходный текст инструкции — ни по качеству, ни по стоимости.
Главная боль в работе с шаблонами: Пользователи верят, что XML-теги, аккуратная структура и агрессивное сжатие делают инструкции «лучше». Тратят время на переформатирование: убирают лишние слова, раскладывают по блокам . Результат — примерно тот же или хуже, но иллюзия «оптимизированного промпта» есть.
Что реально работает: Единственный фактор с доказанным эффектом — мощность модели-исполнителя. Переход с компактной модели на сильную поднял процент решённых задач на 27 процентных пунктов. Всё остальное — шум. При этом сильная модель обошлась примерно в пять раз дороже, а никакой «оптимизированный» формат инструкции не вышел на окупаемость.
Схема метода
Это не техника с шагами, а результат разложения четырёх переменных в одном контролируемом эксперименте:
ПЕРЕМЕННАЯ 1: Сжатие (укорачивание инструкции)
→ Эффект на качество: нейтральный (±)
→ Эффект на стоимость: нейтральный (не экономит)
ПЕРЕМЕННАЯ 2: Формат (XML-структура vs. линейный текст)
→ Эффект на качество: нейтральный или хуже
→ Эффект на стоимость: нейтральный
ПЕРЕМЕННАЯ 3: Мощность «компилятора» (какая модель перепишет инструкцию)
→ Эффект на качество: нет значимого эффекта
→ Эффект на стоимость: нет
ПЕРЕМЕННАЯ 4: Мощность «исполнителя» (какая модель решает задачу)
→ Эффект на качество: ↑ +27 пп — ЕДИНСТВЕННЫЙ значимый фактор
→ Эффект на стоимость: ~×5 дороже
Каждая переменная тестировалась изолированно — это ключевое. Обычно все четыре меняют сразу и не понимают, что сработало.
Пример применения
Задача: Вы ведёте свой бизнес и у вас есть «рабочий» шаблон промпта для составления коммерческих предложений — он занимает ~400 слов и написан сплошным текстом. Команда предлагает переписать его в XML-структуру и сжать до 200 слов, чтобы «работало надёжнее».
Промпт для проверки гипотезы:
У меня есть два варианта одной инструкции для составления КП.
Вариант А (исходный, ~400 слов, обычный текст):
[вставить исходный шаблон]
Вариант Б (сжатый, ~200 слов, XML-структура):
[вставить переработанный шаблон]
Прогони оба варианта на этой задаче:
[описание конкретного КП: клиент, продукт, ключевые условия]
Напиши два КП по обоим шаблонам. Не сообщай, какой из них лучше —
просто выдай результаты. Я сравню сам.
Результат: Вы получите два КП и сможете сравнить их вживую. Исследование предсказывает: разница будет незначительной или нулевой. Время, потраченное на переформатирование шаблона, не конвертируется в качество результата. Если результат вас не устраивает — это сигнал переключиться на более сильную модель, а не точить инструкцию.
Почему это работает
Слабость LLM в работе с инструкциями: Мы интуитивно думаем о модели как о программе, которая лучше «распарсит» инструкцию, если та структурирована. XML-теги кажутся «надёжнее», чем обычный текст. Но LLM работает не как парсер — она генерирует текст по контексту, а не исполняет код. Структура помогает разделить информацию, но не улучшает понимание содержания.
Что выяснилось: Когда исследователи взяли одинаковое содержание и подали его в двух форматах — структурированном (XML-блоки) и линейном (обычный текст) — результаты оказались статистически неразличимы. Формат не нёс дополнительной ценности. А на слабой модели XML-структура иногда мешала — предположительно, потому что разбивала нарратив, из которого модель восстанавливала контекст при ошибках.
Рычаги управления, которые реально работают: - Наличие инструкции вообще → сильно лучше, чем её отсутствие (+16 пп в эксперименте). Пишите инструкцию — это важно. - Мощность модели → единственный фактор с доказанным большим эффектом. Если задача не решается — попробуйте Claude Opus или GPT-4o вместо mini-версий. - Формат и сжатие → нейтральны. Пишите так, как вам удобно читать и редактировать.
Шаблон промпта
Прямого шаблона техники здесь нет — это исследование-находка. Но из него вытекает конкретный чеклист принятия решений при работе с повторными инструкциями:
Я использую такой шаблон для задачи {название задачи}:
[вставить текущий шаблон]
Результаты меня {устраивают / не устраивают} по следующим причинам: {описание}
Помоги разобраться с проблемой. Сначала ответь на вопрос:
проблема в ФОРМУЛИРОВКЕ инструкции (непонятно, противоречиво, неполно)
или в ВОЗМОЖНОСТЯХ модели (задача требует более глубокого рассуждения)?
Если в формулировке — укажи конкретно, что улучшить.
Если в возможностях — скажи прямо, что переписывание не поможет.
Что подставлять:
- {название задачи} — коммерческое предложение, анализ текста, разбор договора и т.д.
- {описание} — конкретная боль: «выдаёт слишком общие ответы», «игнорирует ограничение по тону», «не учитывает второй пункт»
Ограничения
⚠️ Специфика задач: Эксперимент проводился на задачах с объективной проверкой — код либо работает, либо нет. Для субъективных задач (тексты, стратегия, брейншторм) картина может отличаться.
⚠️ Контекст агентных систем: Исследовались многошаговые агенты с инструментами (выполнение кода, файловая система). Для одноразового диалога в чате закономерности применимы частично.
⚠️ «Не навредит» ≠ «не нужен хороший формат»: Если ваша инструкция противоречива или неполна — это другая проблема. Исследование про формат при равном содержании, не про качество содержания.
⚠️ Сжатие и токены: Уменьшение размера инструкции не экономило токены в итоге — другие части диалога компенсировали. Не рассчитывайте на экономию от «компактного промпта».
Как исследовали
Идея была простой: взять одну инструкцию и подать её в разных формах — сокращённой, XML-структурированной, линейной, с умной фильтрацией — и посчитать, какой формат даёт больше правильных ответов и меньше тратит денег. Всё честно: 40 задач по разработке ПО, каждая с автоматическим верификатором (код либо проходит тесты, либо нет), три прогона каждого условия. Итого 1 200 запусков.
Ключевая хитрость дизайна — XML-структуру и линейный текст генерировали из одного и того же источника данных (семантического реестра), что позволило проверить именно формат, а не содержание. Это редкость для таких исследований — обычно сравнивают апельсины с яблоками.
Результат удивил: ни одна «оптимизация» не вышла на окупаемость. Сжатие инструкции уменьшало её размер в 1.5–2 раза, но итоговые затраты токенов оставались практически одинаковыми — модель «компенсировала» за счёт других частей диалога. А структурированный XML давал на 8 пп меньше успехов, чем простой линейный текст (хотя с статистической поправкой этот эффект не доказан как значимый). Единственное, что сработало статистически — смена модели на более сильную — дало +27 пп к успеху, но в пять раз дороже.
Интересный побочный эффект: токены не равны деньгам. Сильная модель использовала меньше токенов (от 41 до 44 тысяч против 46–51 тысяч у компактной), но стоила в шесть раз дороже из-за более высокой цены за токен. Исследователи специально провели два расчёта — «нормализованный» (как будто все модели одинаково стоят) и реальный (по прайсу). Выводы расходились радикально: нормализованный счётчик говорил «сильная модель дешевле», реальные деньги — «в шесть раз дороже».
Адаптации и экстраполяции
💡 Адаптация: диагностика «почему не работает»
Если LLM стабильно выдаёт слабый результат по вашем шаблонному промпту — исследование даёт конкретный диагностический путь:
Протестируй мой шаблон в трёх версиях и скажи, где провал:
ВЕРСИЯ 1 (исходная):
{вставить текущий шаблон}
ВЕРСИЯ 2 (добавь конкретики и примеров, не меняй структуру):
{попроси модель расширить содержание}
ВЕРСИЯ 3 (сократи до ключевых инструкций, убери всё лишнее):
{попроси модель сжать}
Задача: {конкретная задача}
Прогони все три на задаче. Потом скажи:
какая версия дала лучший результат и ПОЧЕМУ по твоей оценке.
Если все три дают похожий результат — проблема в модели, не в формулировке.
🔧 Техника: не тратьте время на XML — тратьте на содержание
Вывод из исследования переводится в простое правило для практики:
До: "Мне нужно переписать промпт в XML-структуру, чтобы модель лучше следовала правилам"
После: "Мне нужно проверить — все ли правила я вообще написал? Нет ли противоречий? Достаточно ли примеров?"
Инвестируйте время в полноту и непротиворечивость содержания, а не в форматирование. Форматирование — нейтральная переменная. Содержание — нет.
Ресурсы
Название работы: Compression, structure, and executor capability: a controlled real-cost decomposition of language-model agent skill optimisation
Авторы: Xiaonan Xu (Northern Arizona University, Flagstaff, AZ), Wenjing Wu (University of Colorado Boulder, Boulder, CO)
Контакт: xiaonanxu5@gmail.com