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

Гайд по промт-инженерии

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

Обычные инструкции здесь не работают. DeepSeek R1 — модель рассуждения: она думает перед ответом. Узнайте, как строить архитектуру мышления, управлять блоком <think> и получать точные результаты в коде, анализе и стратегии.

Смена парадигмы: от инструкции к архитектуре мышления

В классических LLM (GPT-4o, Claude 3.5 Sonnet) промт — это набор инструкций: «сделай это», «не делай то», «выведи в формате JSON». Модель предсказывает следующий токен сразу.

DeepSeek R1 (и V3 с включенным рассуждением) работает иначе. Перед генерацией ответа она производит скрытую цепочку рассуждений (Chain-of-Thought). Этот процесс доступен в теге <think>. Промт для такой модели — не список задач, а архитектура процесса мышления.

Если вы пишете «реши задачу», модель может «передумать» на полпути. Если вы задаёте структуру рассуждения — «сначала изучи ограничения, потом предложи три варианта, выбери лучший, проверь на граничных случаях» — модель следует этому сценарию внутри <think> и выдаёт проверенный результат.

Схема: Вход → Структурированный → Валидация → Финальный ответ

ВХОДНЫЙ ПРОМТ

System: Архитектор мышления
User: Задача + Контекст
Schema: План рассуждения

БЛОК <THINK>

Декомпозиция
Проверка гипотез
Синтез ответа
Самоисправление

ФИНАЛЬНЫЙ ОТВЕТ

JSON / Code / Text
Готовый к использованию
Без «воды» и рассуждений

Четыре столпа промта для рассуждающей модели

1. Плотный контекст (Context Density)

Модель не «знает» ваш проект. Вставьте схему БД, ключевые ограничения, глоссарий терминов, примеры правильных/неправильных ответов. Чем плотнее контекст, тем меньше моделям нужно «додумывать» в <think>.

2. Жёсткий контракт вывода (Output Contract)

Укажите точный формат: JSON Schema, Markdown-таблица, синтаксис языка. Добавьте правило: «Никакого текста вне формата». Это заставляет модель в <think> отсекать лишнее и форматировать строго.

3. Бюджет и контроль рассуждения (Reasoning Budget)

Задайте глубину: «Рассуждай не более 2000 токенов», «Остановись, если найдёшь 3 варианта», «Не углубляйся в теорию, ищи практический код». Параметр max_tokens на выходе режет ответ, но не мысли — контролируйте через промт.

4. Негативные ограничения (Negative Constraints)

Что делать НЕ надо часто важнее: «Не используй библиотеку X», «Не пиши комментарии», «Не придумывай API», «Не усложняй архитектуру». Это урезает пространство поиска в <think> и экономит бюджет токенов.

Анатомия идеального промта: разбор по слоям

Роль и манера мышления

Ты —Senior Systems Architect.
Твоё мышление: сначала архитектура,
потом реализация. Проверяй
каждое решение на:
- масштабируемость
- отказоустойчивость
- стоимость владения

Входные данные и ограничения

КОНТЕКСТ:
- Stack: Go 1.22, PostgreSQL, NATS
- Load: 50k RPS, p99 < 50ms
- Legacy: монолит на PHP 7.4
ОГРАНИЧЕНИЯ:
- Никаких новых микросервисов
- Миграция за 3 спринта
- Бюджет инфраструктуры: фиксирован

Сценарий рассуждения (Think-Plan)

В БЛОКЕ <think> ПРОЙДИ ЭТАПЫ:
1. Выдели критические пути монолита.
2. Предложи 2 стратегии страглирования.
3. Оцeni риски каждой по шкале 1-5.
4. Выбери оптимальную, обоснуй.
5. Напиши план миграции по неделям.
БЮДЖЕТ: макс. 3000 токенов мышления.

Формат финального артефакта

ВЫВОД ТОЛЬКО JSON (без markdown):
{
  "strategy": "strangler_fig",
  "risks": [{"path": "auth", "score": 2}],
  "plan": [
    {"week": 1, "deliverable": "proxy layer"}
  ]
}
ЕСЛИ ФОРМАТ НАРУШЕН — ПЕРЕДУМАЙ.

Библиотека паттернов: готовые шаблоны для типовых задач

Сохраните, адаптируйте, комбинируйте. Каждый паттерн заточен под механику <think>.

«Архитектор кода»

Для рефакторинга, дизайна API, выбора стека. Модель ведёт внутренний диалог: «Предложи 3 варианта → Сравни по критериям → Выбери → Напиши код».

План в <think>:
1. Анализ требований
2. 3 архитектурных варианта
3. Таблица сравнения (criteria)
4. Выбор + обоснование
5. Код выбранного варианта

«Детектив багов»

Даёте стек-трейс, логи, фрагмент кода. Модель в <think> строит дерево гипотез, отсекает невозможные, выдаёт минимальный воспроизводимый кейс и фикс.

Алгоритм мышления:
1. Список гипотез (min 5)
2. Проверка каждой по логам
3. Root Cause Analysis
4. Fix + Prevention

«Аналитик данных»

Загружаете схему БД/CSV заголовки. Задача: «Напиши SQL для метрики X». В <think> модель проверяет типы, индексы, нормализацию, пишет запрос, потом — EXPLAIN-план.

Шаги рассуждения:
1. Профиль таблиц и связей
2. План соединений (JOIN order)
3. Окна/агрегации
4. Оптимизация (индексы)
5. Финальный SQL + EXPLAIN

«Стратег продукта»

Вход: метрики, пользователи, ограничения. Выход: приоритизированная дорожная карта. Модель в мышлении применяет RICE/ICE, считает ROI, проверяет зависимости.

Внутренний процесс:
1. Парсинг входных данных
2. Скоринг инициатив (RICE)
3. Карта зависимостей
4. Дорожная карта по кварталам
5. Риски и митигация

«Тьютор сложных тем»

Объяснение концепций: от квантовых вычислений до микросервисов. Промт заставляет модель в <think> построить педагогическую лестницу: аналогия → формализм → пример → проверка понимания.

Структура объяснения:
1. Аналогия из жизни (ELI5)
2. Математическая суть
3. Код/диаграмма
4. Типичные ошибки
5. Мини-тест для самопроверки

Обычный промт vs Промт для DeepSeek: наглядное сравнение

Один и тот же запрос, разная архитектура промта. Результаты принципиально отличаются.

1Стиль «ЧатGPT»: Инструкция

Напиши функцию на Python для
парсинга логов nginx. Верни JSON.
Обработай ошибки.

Что происходит в модели:

Модель сразу генерирует код.
Нет этапа проверки гипотез.
Часто упускает edge-кейсы (пустые строки, нестандартные форматы).
JSON может быть невалидным из-за комментариев в коде.

2Стиль «DeepSeek R1»: Архитектура мышления

Роль: Senior Backend Engineer.
Контекст: Логи nginx combined format,
10M строк/день, могут быть битые строки.

ПЛАН В <think> (бюджет 2000 токенов):
1. Определи регэксп для combined + вариации.
2. Спроектируй стриминговый парсер (generator).
3. Обработай: malformed lines, missing fields, encoding.
4. Напиши Pydantic-модель для валидации JSON.
5. Добавь бенчмарк-памяти.

КОНТРАКТ ВЫВОДА: ТОЛЬКО КОД .py.
НЕТ КОММЕНТАРИЕВ ВНЕ КОДА.

Что происходит в модели:

<think> разбирает формат логов, проверяет регэксп на граничных случаях.
Выбирает генератор для памяти, а не список.
Пишет Pydantic-модель *до* парсера.
Финальный код проходит внутренний код-ревью в мышлении.

Продвинутое управление блоком <think>: техники экспертов

1Бюджетирование токенов рассуждения

DeepSeek позволяет управлять длиной <think> через промт и параметры API. Используйте явные лимиты: «Рассуждай ровно 3 шага», «Не трать более 1500 токенов на анализ». Это критично для продакшена: неконтролируемое рассуждение съедает квоту и время ответа.

max_tokens: 4096 (итого) thinking_budget: 2048 (в промте или параметре) output_tokens ≈ 2048

2Извлечение и скрытие мышления

По умолчанию <think> возвращается в стриме. Для пользовательских интерфейсов его скрывают (парсят теги, показывают спиннер «Думаю...»), для дебагга — логируют. В промте можно запретить вывод: «Не выводи блок think в финальном ответе, используй его только внутренне».

Параметр API: "reasoning_format": "hidden" | "raw" | "parsed" В промте: "ВНИМАНИЕ: Блок <think> СТРОГО ВНУТРИ. В ОТВЕТЕ ТОЛЬКО РЕЗУЛЬТАТ."

3Few-shot для рассуждения (Think-shots)

Давайте примеры *правильного мышления*, а не только ввода-вывода. Покажите модели, как выглядит качественный <think> для вашей задачи. Это самый мощный способ калибровки: модель копирует стиль рассуждения, глубину и структуру.

User: Задача А Assistant: <think> 1. Анализ А... 2. Проверка Б... 3. Вывод В </think> Результат А --- User: Задача Б (ваша)

4Рекурсивная самоисправление (Self-Correction Loop)

Заставьте модель критиковать себя внутри <think>. Добавьте в промт: «После черновика решения найди в нём 3 потенциальные ошибки. Исправь. Повтори, пока не станешь уверен на 95%». Это включает режим внутреннего ревью.

Шаблон цикла: 1. Черновик решения 2. Атака на черновик (Red Team) 3. Патчинг уязвимостей 4. Финальная валидация 5. Вывод

Типичные ловушки: почему DeepSeek «сходит с ума» и как чинить

1Ловушка «Будь кратким»

Фраза «Отвечай кратко» в системном промте обрезает <think>. Модель перестаёт проверять гипотезы и выдаёт первое пришедшее в голову — часто неверное.

Лекарство:

«Будь лаконичен в ФИНАЛЬНОМ ОТВЕТЕ. В блоке <think> рассуждай максимально подробно».

2Ловушка «Думай по шагам»

DeepSeek УЖЕ думает по шагам. Добавление «Let's think step by step» мусорит контекст и иногда сбивает нативную цепочку рассуждения, заставляя моделировать старый стиль CoT.

Лекарство:

Убирайте эту фразу. Вместо этого давайте СТРУКТУРУ шагов (см. паттерн «Сценарий рассуждения» выше).

3Перегруз контекстом (Context Overflow)

Сваливание всей кодовой базы в промт. <think> пытается обработать всё, упирается в лимит токенов, обрезает рассуждение посередине — ответ обрывается или галлюцинирует.

Лекарство:

RAG: отдавайте только релевантные фрагменты. Используйте «Карту кодовой базы» (файл со структурой) вместо самих файлов.

4Игнорирование формата вывода

Модель в <think> решает задачу верно, но в финале пишет поясняющий текст: «Вот ваш JSON:». Парсер падает.

Лекарство:

Жёсткий контракт: «ВЫВОД ТОЛЬКО JSON. НИКАКОГО ТЕКСТА ДО И ПОСЛЕ. ЕСЛИ НАРУШИШЬ — НАЧНИ СНАЧАЛА В <think>».

Главный сдвиг мышления

Вы не просите модель «сделать за вас». Вы проектируете её внутренний монолог. Каждый промт для DeepSeek — это сценарий для режиссера, который играет все роли: аналитик, архитектор, критик, программист.

ПРАВИЛО

Структура мышления важнее инструкции к действию.

ПРИНЦИП

Контекст + План рассуждения + Контракт вывода = Надёжный результат.

НАВЫК

Умейте читать <think> — там рождается качество ответа.

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