DeepSeek: как писать промты, которые работают на модели рассуждения

DeepSeek не нужно учить мыслить — ему нужно задать цель

Модели рассуждения (R1) сами строят цепочку логики. Ваша задача — дать контекст, формат и ограничения. Гайд по промт-инженерии для новой генерации LLM.

Reasoning ModelsZero-Shot FirstXML StructureIterative Loop

Почему старые приёмы ломаются на R1

В классических моделях (GPT-4o, Claude 3.5 Sonnet) мы пишем «подумай пошагово», чтобы заставить модель вывести промежуточные токены. DeepSeek-R1 уже обучена это делать на этапе RL (Reinforcement Learning). Добавление инструкций «рассуждай» часто ухудшает результат: модель тратит бюджет токенов на повторение известного ей процесса вместо решения вашей задачи.

Парадокс: чем умнее модель в рассуждении, тем меньше инструкций по процессу ей требуется, и тем больше качественного контекста по сути.

Правило: не описывайте как думать. Опишите что нужно получить и при каких условиях.

Сравнение подходов

Обычная LLM (Chat Mode)

Нужен explícit CoT: «Reason step by step». Контекст лучше давать куском текстом. Роль задаётся мягко.

DeepSeek R1 (Reasoning Mode)

CoT встроен. Структура (XML/MD) важнее простыни текста. Роль и формат вывода — критичны. Много примеров (few-shot) могут сбить рассуждение.

Четыре столба промта, который слышит R1

Цель (Goal)

Один конкретный исход: «Написать функцию парсинга», «Сравнить два контракта», «Сгенерировать план тестов». Не «помоги с кодом».

Контекст (Context)

Что модель должна знать: стек, ограничения окружения, входные данные, аудитория, предыдущие решения. Кладём в <context>.

Формат (Format)

Жёсткая спецификация вывода: JSON Schema, Markdown-таблица, код без пояснений, diff-патч. Модель рассуждает свободно, но отдаёт строго.

Ограничения (Constraints)

Чего НЕ делать: не использовать библиотеку X, не превышать 200 строк, не выдумывать API, соблюдать стиль кода. Это «гвардии» для рассуждения.

Фреймворк G-C-F-C за 4 шага

Не запоминайте абстракции. Используйте чек-лист перед каждым сложным запросом. Порядок важен: цель определяет нужный контекст, контекст диктует формат, формат уточняет ограничения.

1
Сформулируйте Goal одной фразой
Плохо: «Оптимизируй БД». Хорошо: «Сократи время запроса getUserById до 50мс при нагрузке 1k RPS, не меняя схему».
2
Упакуйте Context в XML-теги
Теги создают иерархию внимания. Модель легче извлекает сущности из <stack>Go 1.22, PostgreSQL 16</stack>, чем из предложения.
3
Пропишите Format вывода
Требуйте валидный JSON по схеме, diff-файл, Mermaid-диаграмму. Указывайте: «Выводи ТОЛЬКО код», «Никакого поясняющего текста».
4
Добавьте Constraints как «не делай»
Отрицательные ограничения работают надежнее позитивных. «Не используй рекурсию» лучше, чем «используй итерации».

Шаблон-скелет (скопируйте и заполните)

<goal>
Ваша конкретная цель в одном предложении. Результат, который вы ожидаете увидеть.
</goal>

<context>
  <role>Senior Backend Engineer, эксперт по Highload</role>
  <stack>Go 1.22, PostgreSQL 16, Redis 7</stack>
  <input_data>
    {JSON-схема или пример входных данных}
  </input_data>
  <constraints_env>Нет внешних вызовов, только stdlib + pgx</constraints_env>
</context>

<output_format>
Валидный JSON по схеме:
{
  "optimized_query": "string",
  "indexes": ["string"],
  "explanation": "string (max 3 sentences)"
}
Никакого Markdown, только raw JSON.
</output_format>

<negative_constraints>
- Не предлагай шардинг и репликацию.
- Не используй ORM.
- Не меняй контракт API.
</negative_constraints>

DeepSeek R1 vs Обычный чат: где меняется тактика

Режим DeepThink (R1)

Zero-shot по умолчанию. Сначала пробуйте без примеров. Few-shot нужен только для очень специфических форматов вывода.
Большой контекст — друг. R1 имеет окно 128k+. Загружайте логи, схемы, документацию. Модель сама найдёт релевантное в процессе рассуждения.
Итерации в диалоге. Не переделывайте промт с нуля. Пишите след. сообщением: «В рассуждении шаг 3 упущен кейс X. Пересчитай с учетом Y».
Температура 0.6 — 1.0. Для креативных задач поднимайте. Для кода/математики — 0.1-0.3. Top-p 0.95.

Обычный чат (V3 / GPT-4o)

Few-shot обязателен. 3-5 примеров вход-выход кардинально поднимают качество сложных задач.
Контекст резать. Окно внимания размывается. RAG и суммаризация обязательны при больших объёмах.
System prompt — закон. Роль, стиль, правила задаются один раз в system. В R1 system prompt слабее влияет на рассуждение.
Температура 0 — 0.7. Детерминизм важнее. Высокая T ломает следование инструкциям.

Три ловушки, в которые падают даже опытные

Ловушка 1

Перегрузка инструкциями мышления

Фразы «думай глубоко», «проверь себя», «используй цепочку рассуждений» едят токены бюджета thinking и заставляют модель генерировать вербальную «воду» вместо полезных шагов. Доверяйте RL-тренингу.

Ловушка 2

Игнорирование окна вывода

R1 может выдать 8k+ токенов рассуждения и урезать итоговый ответ по лимиту max_tokens. Всегда ставьте лимит ответа (например, 4096) с запасом под thinking или используйте параметр max_completion_tokens (если API поддерживает).

Ловушка 3

Смешивание ролей в одном промте

«Ты архитектор и кодер и тестировщик» — рассуждение размывается. Лучше: цепочка вызовов. 1. Архитектор (промт с Goal=Design) → 2. Кодер (промт с Goal=Implement + Context=Design) → 3. Ревьюер (Goal=Review).

Промт — это не заказ, это синхронизация контекста

DeepSeek R1 меняет метафору. Вы не «программируете» модель инструкциями. Вы загружаете в неё состояние задачи (Goal + Context), задаёте форму результата (Format) и ставите границы (Constraints). Остальное — работа движка рассуждения.

Начните с нуля. Напишите <goal> прямо сейчас.