TL;DR
Когда ты просишь reasoning-модель (Qwen3, gpt-oss, по аналогии — Claude с extended thinking, o1/o3) сократить размышление, важно КАК ты это просишь, а не сколько токенов называешь. Исследователи сравнили два способа: "у тебя лимит N токенов" и "рассуждай кратко и дай рабочий ответ как можно раньше" — и это два разных промпта с разным эффектом.
Первый способ (назвать число) звучит логично, но не работает: модель послушно укорачивает рассуждение на 12-17%, но точность ответа при том же лимите токенов не растёт. Модель просто быстрее сдаётся, а не думает эффективнее. Хуже того — если модель обрывают посреди размышления и заставляют ответить, неправильный ответ она часто выдаёт с высокой уверенностью — по тону и уверенности нельзя понять, что ответ поспешный и ошибочный.
Второй способ — прямая инструкция "рассуждай кратко, приоритет — рабочий ответ раньше" — реально повышает точность при жёстком лимите токенов (в тесте: +3.8 процентных пункта при малом бюджете). Причина в механике: эта формулировка заставляет модель раньше по-настоящему закончить цикл рассуждения, а не просто её обрывают на середине. Закончивший цикл ответ почти всегда точнее, чем недодуманный.
Схема метода
СИТУАЦИЯ 1 (не работает): "У тебя лимит {N} токенов на размышление"
→ модель формально укорачивает рассуждение → точность не растёт при том же лимите
СИТУАЦИЯ 2 (работает): "Рассуждай кратко. Приоритет — дать рабочий ответ как можно раньше"
→ модель раньше ЗАВЕРШАЕТ цикл размышления (а не обрывается на середине)
→ точность выше именно при жёстких бюджетах токенов/времени
Оба варианта — это один промпт, разница только в формулировке инструкции.
Пример применения
Задача: Ты в дедлайне готовишь ответ клиенту и просишь Claude/ChatGPT с режимом "размышления" быстро посчитать юнит-экономику стартапа — время на генерацию ограничено (например, у тебя открыт лимит "extended thinking" на минимум).
Промпт (плохой вариант):
Отведи на размышление не больше 300 токенов, потом дай ответ.
Посчитай unit-экономику: CAC 1500 руб, LTV 4000 руб, конверсия в оплату 8%.
Промпт (рабочий вариант):
Рассуждай кратко. Твой приоритет — дать практический, пригодный к использованию ответ
как можно раньше, а не длинную цепочку рассуждений.
Посчитай unit-экономику: CAC 1500 руб, LTV 4000 руб, конверсия в оплату 8%.
Результат: Второй промпт с большей вероятностью выдаст завершённый расчёт с корректным выводом (юнит-экономика окупается/не окупается), а не оборванную на середине цепочку с угадыванием финальной цифры. Первый промпт просто заставит модель торопиться, не гарантируя, что она успеет закончить логику.
Почему это работает
Слабость reasoning-моделей: если размышление прервать на середине (по лимиту токенов, дедлайну, таймауту), модель выдаёт ответ, который выглядит уверенно, но часто ошибочен — вероятность на неправильном варианте может быть даже выше, чем на правильном. Внешний обрыв — это не то же самое, что модель "решила закончить сама".
Сильная сторона модели: если её попросить самостоятельно завершить цикл раньше (а не просто сократить длину), она реально успевает дойти до логического конца — просто более компактным путём. Завершённое рассуждение почти всегда точнее оборванного, даже если оно короче.
Метод использует это: инструкция "приоритет — ранний рабочий ответ" не режет рассуждение снаружи, а меняет внутреннюю стратегию модели — она сама решает закончить раньше, а не её прерывают. Разница между "модель сама остановилась" и "модель заставили остановиться" — и есть весь эффект.
Рычаг управления: если нет спешки — не обрубай размышление вообще, дай модели закончить: точность выше. Обрывай только когда дедлайн жёсткий, и в этом случае формулируй именно как "дай рабочий ответ раньше", а не "у тебя лимит X".
Шаблон промпта
Рассуждай кратко по задаче: {задача}.
Твой приоритет — дать практический ответ, пригодный к использованию, как можно раньше,
а не разворачивать длинную цепочку рассуждений.
Подставь {задача} — конкретный запрос (расчёт, анализ, план). Формулировка "приоритет — ранний рабочий ответ" — ключевая, не заменяй её на "уложись в N слов/токенов", это не даёт того же эффекта.
🚀 Быстрый старт — вставь в чат:
Мне нужно получать от тебя быстрые, но точные ответы в сжатых условиях.
Вот принцип из исследования: инструкция "рассуждай кратко, приоритет — ранний рабочий
ответ" работает лучше, чем просто "лимит N токенов", потому что модель успевает
закончить логику, а не обрывается на середине.
Помоги мне сформулировать промпт-инструкцию под мою задачу: {твоя задача}.
LLM спросит про специфику твоей задачи (нужна ли скорость важнее глубины, какой формат ответа нужен) — потому что от этого зависит, стоит ли вообще просить "кратко", или лучше дать модели время подумать полностью.
Ограничения
⚠️ Эффект пропадает при большем бюджете: при более щедром лимите токенов разница между "кратко и раньше" и обычным промптом становится неясной — метод работает только при жёстких ограничениях.
⚠️ Не работает объявление числа токенов: просить модель "уложись в N токенов" — не даёт прироста точности, даже если модель реально сокращает рассуждение. Работает только формулировка про приоритет раннего ответа.
⚠️ Уверенность модели — не индикатор правильности: если рассуждение прервано на середине, ответ может звучать уверенно и быть неправильным одновременно. На уверенность в тексте ответа нельзя ориентироваться, когда просишь модель поторопиться.
⚠️ Если не спешишь — не обрубай рассуждение вообще: если тебе не критична скорость, дать модели дорассуждать до конца почти всегда даёт более точный финальный ответ, чем принудительно урезанное размышление.
Как исследовали
Команда взяла две открытые reasoning-модели (Qwen3 и gpt-oss в разных размерах) и прогоняла одни и те же вопросы (научные задачи GPQA Diamond и тест на общие знания MMLU-Pro) парами: один раз модель рассуждала как обычно, второй раз — с изменённым промптом, и обе версии останавливали в одной и той же точке по числу токенов, чтобы сравнение было честным.
Главная хитрость дизайна: исследователи не просто смотрели на финальный ответ, а научились "читать" ответ модели в момент, когда её прервали — то есть заставляли модель выбрать вариант ответа прямо из недописанного рассуждения. Это позволило отличить два разных явления, которые обычно путают: "модель дала лучший ответ, потому что стратегия рассуждения лучше" и "модель дала лучший ответ, потому что просто успела закончить раньше".
Оказалось, что для gpt-oss почти весь выигрыш низкого "уровня усилия" (low effort) над высоким при той же точке остановки объясняется вторым — низкий уровень просто раньше заканчивает думать, а не думает умнее. А для инструкции "давай ранний ответ" в Qwen — наоборот, часть выигрыша шла именно от того, что модель меняла стратегию, а не только от скорости завершения. Это противоречило интуиции "чем меньше рассуждения обрубаем — тем хуже", и заставило авторов разделять в отчётах "точный завершённый ответ", "ответ на момент обрыва" и "уверенность модели в этом ответе" — как три разных, не сводимых друг к другу измерения.