Выход reasoning‑моделей — OpenAI o1, o3‑mini, DeepSeek R1 — изменил то, как мы общаемся с большими языковыми моделями. Вместо того чтобы сразу выдавать ответ, такие модели тратят дополнительное «время на размышление», генерируя внутреннюю цепочку рассуждений. На первый взгляд это делает промпты проще: можно просто спросить, и модель сама разберётся. Но практика показывает обратное. Обычные приёмы — просьба «думать шаг за шагом» или «объясни своё решение» — в reasoning‑моделях либо не нужны, либо мешают.
Статья основана на официальных документах OpenAI, препринте DeepSeek R1, руководстве Anthropic по промптингу и заметках практиков. Мы разберём, что изменилось, какие инструкции стоит убрать из своих промптов, а какие — добавить, и как проверить эффективность на своих задачах.
Почему старые приёмы перестают работать
Главное отличие reasoning‑моделей — они встроили chain‑of‑thought в процесс генерации. OpenAI o1 не просто выполняет вашу инструкцию, а сначала генерирует внутреннюю цепочку рассуждений, которая затем сжимается в финальный ответ. В официальном руководстве OpenAI по промптингу для o1 прямо сказано: «Не нужно инструктировать модель думать шаг за шагом или объяснять свои рассуждения — o1 уже делает это внутри» (OpenAI, Prompt engineering for o1).
DeepSeek R1 пошёл ещё дальше: в препринте (DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning, arXiv:2501.12948) авторы показывают, что модель обучалась с подкреплением генерировать длинные цепочки размышлений и даже демонстрировать «моменты озарения». Попытка добавить внешний CoT‑промпт может привести к дублированию или конфликту между внутренним и внешним рассуждением.
Практический результат: если вы вставляете в промпт фразу «Let’s think step by step» или «Давай решать по шагам», модель может проигнорировать внешнюю инструкцию или начать ещё более длинное рассуждение, увеличивая время ответа без улучшения качества. В своих тестах я заметил, что при добавлении CoT‑подсказки к DeepSeek R1 среднее время генерации росло на 20–30%, а точность оставалась той же.
Что говорят источники
Официальные рекомендации от OpenAI и DeepSeek расходятся в деталях, но сходятся в главном: промпты должны быть прямыми и конкретными.
Из документации OpenAI для o1 (раздел «Be simple and direct»):
– Используйте короткие инструкции без лишних пояснений.
– Указывайте ожидаемый формат ответа (например, JSON, список, таблица).
– Для сложных задач давайте примеры (few‑shot), но без развёрнутых рассуждений — только вход и ожидаемый выход.
DeepSeek в своих рекомендациях (пост в блоге на huggingface.co) добавляет: «R1 лучше всего работает с структурированными запросами, где чётко разделены контекст, задача и формат ответа». Это совпадает с подходом Anthropic, описанным в руководстве по промптингу: «Поместите инструкцию в конец промпта, используйте XML‑теги для структуры».
Однако есть нюанс: ни один из этих документов не предлагает готовых «рецептов» для всех случаев. Reasoning‑модели ведут себя по‑разному на разных доменах, и то, что работает для математической задачи, может не сработать для генерации кода или анализа текста.
Практический чек‑лист для промптов
Чтобы не запутаться, я составил таблицу с рекомендациями, основанными на официальных источниках и сообществе (в частности, Simon Willison, который ведёт обширные заметки по промптингу reasoning‑моделей).
| Что делать | Что не делать | Почему |
|---|---|---|
| Писать прямую инструкцию: «Ответь на вопрос: …» | Вставлять «Let’s think step by step» | Модель уже размышляет внутри; внешний CoT избыточен |
| Чётко задавать формат: «Ответ в JSON: { … }» | Оставлять формат «на усмотрение» | Reasoning‑модели могут выбрать неоптимальную структуру |
| Давать 1–2 примера (few‑shot) без рассуждений | Давать примеры с развёрнутыми объяснениями | Примеры с рассуждениями могут сбить модель на имитацию |
| Разделять контекст и задачу: «Контекст: … Задача: …» | Смешивать контекст и инструкцию в одном абзаце | Чёткая структура снижает вероятность потери информации |
| Указывать ограничения (например, «Не используй LaTeX») | Указывать ограничения в конце после примера | Лучше размещать ограничения сразу после инструкции |
Этот чек‑лист — не догма, а начальная точка. Для каждого конкретного use‑case стоит проводить A/B‑тесты.
Ограничения и ловушки
Важно понимать, что reasoning‑модели не всегда лучше. Они требуют больше вычислительных ресурсов и времени. Если ваша задача — простой перевод или извлечение фактов без логических цепочек, обычная модель (GPT‑4o, Claude 3.5 Sonnet) может быть быстрее и дешевле.
Кроме того, внутренние рассуждения o1 и DeepSeek R1 не видны пользователю — вы получаете только финальный ответ. Это затрудняет отладку: если ответ неверный, непонятно, на каком этапе модель ошиблась. В отличие от обычных моделей, где можно попросить «объясни», здесь такой возможности нет.
Ещё один момент: DeepSeek R1, по сообщениям в сообществе (Reddit r/LocalLLaMA), склонен к чрезмерной детализации в цепочках рассуждений, особенно при работе с большими контекстами. Это может приводить к «зацикливанию» и даже к сбоям. В официальном препринте авторы упоминают, что R1‑Zero (ранняя версия) иногда демонстрировал «нечитаемые» рассуждения — эту проблему исправили в финальной версии, но полностью не исключили.
Что проверить на своих задачах
Лучший способ убедиться, что ваши промпты эффективны, — провести простой эксперимент:
1. Возьмите 10–20 задач из вашего домена.
2. Для каждой задачи напишите два варианта промпта: «старый» (с CoT‑подсказкой) и «новый» (прямой, по чек‑листу выше).
3. Прогоните оба варианта через одну и ту же модель (например, o1‑mini или DeepSeek R1).
4. Сравните точность ответов и время генерации.
Если модель показывает одинаковое качество, используйте более короткий промпт — это сэкономит токены. Если старый промпт даёт лучший результат, это может означать, что ваша задача не требует полного внутреннего рассуждения, и обычная модель могла бы справиться не хуже.
Помните, что документация OpenAI и DeepSeek — это живые документы, которые обновляются. Следите за changelog релевантных моделей и не полагайтесь на единственный источник. На данный момент две главные рекомендации от производителей ясны: не мешайте модели рассуждать самостоятельно и делайте запросы максимально структурированными.