TL;DR
Когда просишь модель отвечать короче, она часто обрывает рассуждение на полпути и выдаёт промежуточный результат за финальный ответ. Метод решает это так: перед тем как просить короткий ответ, модели дают не полный пример решения, а сжатую выжимку — какие переменные важны, какая операция критична, что нельзя забыть.
Исследователи заметили конкретную боль: если сжать цепочку рассуждений (Chain-of-Thought), точность рушится — модель, например, считает общее количество карточек, но забывает вычесть использованные, и выдаёт 42 вместо правильных 30. Причина не в том, что модель "меньше думает" — она теряет именно контрольные точки: шаги, которые нельзя пропустить, но которые не видны в сжатом виде.
Метод даёт модели заранее краткую абстрактную схему: тип задачи + критическая операция + типичная ошибка. Это работает как чек-лист, а не как образец для копирования — и, что удивительно, работает лучше, чем полный пример решения (few-shot).
Схема метода
ШАГ 1 (заранее, один раз): Вытащить из решённых примеров абстрактную схему
→ тип задачи, ключевые переменные, критическая операция, частая ошибка
ШАГ 2 (при новом запросе): Вставить релевантную схему в промпт + просьба отвечать кратко
→ модель рассуждает по шаблону, но короче
Оба шага можно выполнить в одном промпте — просто заранее сформулировать схему и вставить её вместе с задачей.
Пример применения
Задача: Считаешь юнит-экономику партии товара на Wildberries — сколько реально заработаешь с продажи, учитывая закупку, комиссию площадки и логистику. Модель часто "радостно" называет выручку и забывает вычесть расходы.
Промпт:
Вот схема для задач на расчёт прибыли:
- Ключевые переменные: выручка, закупочная цена, комиссия площадки, логистика
- Критическая операция, которую нельзя пропустить:
Прибыль = Выручка − (Закупка + Комиссия + Логистика)
- Частая ошибка: остановиться на выручке и назвать её "прибылью"
Реши задачу по этой схеме. Отвечай коротко — только итоговое число и краткий расчёт, без длинных пояснений.
Задача: продал 100 футболок по 1200 руб. Закупка — 400 руб/шт,
комиссия Wildberries — 20%, логистика — 60 руб/шт. Сколько чистой прибыли?
Результат: Модель выдаст короткий расчёт (2-4 строки), но пройдёт все вычеты по порядку — выручка, закупка, комиссия, логистика — и не остановится на промежуточной цифре как на финальном ответе.
Почему это работает
Модель, когда её просят быть короче, срезает цепочку рассуждений там, где первое похожее на ответ число появляется — и выдаёт его как финал. Это и есть "коллапс рассуждения" при сжатии.
Зато модель отлично считывает и следует явной структуре, если её дать заранее в контексте. Обработка контекста (то, что уже написано в промпте) для модели гораздо "дешевле", чем генерация нового текста по шагам.
Метод использует эту разницу: вместо того чтобы заставлять модель самой заново выстраивать всю логику по шагам (дорого и хрупко при сжатии), ей дают готовый скелет рассуждения — и она просто "прошивает" через него, не теряя критический шаг.
Рычаги управления: - Уровень абстракции подсказки → более общая схема для разных задач одного типа, более конкретная — для узкой задачи - Количество схем-примеров → не увеличивай без нужды: избыток подсказок в контексте (больше 5-10) ухудшает точность, особенно на сложных задачах - Summary vs полный пример → всегда выбирай краткую выжимку, а не полное решение целиком — это ключевая деталь, которая даёт основной эффект
Шаблон промпта
Вот схема для задач типа «{тип_задачи}»:
- Ключевые переменные: {переменные}
- Критическая операция, которую нельзя пропустить: {формула_или_шаг}
- Частая ошибка при сжатом ответе: {типичная_ошибка}
Реши задачу по этой схеме. Отвечай кратко, но обязательно
выполни критическую операцию до конца.
Задача: {текст_задачи}
Подставляй: {тип_задачи} — категория задач, с которыми часто работаешь (расчёт бюджета, юридический чек-лист, план проекта); {переменные} — что вводится в расчёт; {формула_или_шаг} — то самое действие, которое модель обычно пропускает; {типичная_ошибка} — что она обычно путает вместо финального ответа.
🚀 Быстрый старт — вставь в чат:
Вот шаблон для точных коротких ответов на однотипные задачи.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какой у тебя тип задачи повторяется и какую ошибку модель обычно допускает при коротких ответах — потому что именно это определяет содержание схемы. Дальше она сама заполнит шаблон под твою задачу.
Ограничения
⚠️ Избыток подсказок вредит: если добавить слишком много схем-примеров сразу, точность падает вместо роста — особенно на сложных задачах. Держи 1-3 релевантные схемы, не больше.
⚠️ Полный пример решения работает хуже схемы: если вместо краткой выжимки вставить целый пример-решение (few-shot) — эффект будет отрицательным. Это не "дай пример", это "дай чек-лист".
⚠️ Нужна повторяемость задач: метод раскрывается на однотипных, повторяющихся запросах (расчёты, задачи с чёткой структурой). Для разовой творческой задачи эффект слабый — схему просто не из чего строить.
Как исследовали
Команда протестировала метод на математических задачах (GSM8K, MATH), логических (BBH) и научных вопросах (MMLU-Sci) на моделях Qwen2.5-7B, LLaMA-3.1-8B и через API (DeepSeek, o4-mini). Сравнивали обычный длинный CoT, агрессивно сжатый CoT (Chain-of-Draft) и сжатый CoT + память.
Сжатие само по себе роняло точность драматично — иногда на 20-30 пунктов. Добавление краткой схемы восстанавливало почти всю потерянную точность, при этом ответ оставался в разы быстрее полного рассуждения.
Самое любопытное — отдельный тест форматов подсказки: полный пример решения и длинная цепочка рассуждений ухудшали результат по сравнению с базовой линией, а краткая абстрактная выжимка давала ощутимый прирост. Это прямое доказательство: работает не "больше контекста", а именно правильный тип контекста — сжатая структура, а не демонстрация.