Промптинг reasoning-моделей

Короткая версия

Рабочее правило в 2026 такое:

1. Дайте модели задачу и успех-критерии.
2. Не прописывайте за неё внутренний chain-of-thought.
3. Разделяйте контекст секциями, XML-тегами, markdown-блоками или явными заголовками.
4. Сначала пробуйте zero-shot, потом добавляйте few-shot только если нужен строгий формат или edge-case policy.
5. Управляйте глубиной reasoning через параметры модели, а не через фразы вроде «подумай подольше».

Что обычно работает лучше всего

• ясная формулировка задачи;
• полный релевантный контекст;
• явные ограничения;
• конкретный формат финального ответа;
• routing: reasoning только на задачах, где он действительно нужен.

Что чаще всего ломает качество

• think step by step и другие CoT-инструкции по умолчанию;
• микроменеджмент вроде «шаг 1, шаг 2, шаг 3»;
• огромные few-shot блоки до попытки zero-shot;
• включение reasoning для FAQ, перевода и простого extraction;
• слишком маленький output/reasoning budget.

Какие knobs важны у разных провайдеров

Проведи code review этого Python-сервиса. Фокус: security, race conditions, scaling bottlenecks. Для каждой найденной проблемы верни severity, explanation, concrete fix. Если данных недостаточно, явно перечисли missing assumptions.

1. Что изменилось в prompting reasoning-моделей

Старый совет «reasoning-модель сама всё придумает, просто не мешайте» был полезен как антидот против CoT-overprompting, но в 2026 его уже недостаточно. Official docs у разных провайдеров показывают более точную картину:

• OpenAI советует simple and direct prompts, delimiters, zero-shot first и конкретные success criteria;
• Anthropic начинает prompt engineering не с “магических фраз”, а с определения success criteria и evals;
• Google превращает reasoning в настраиваемую capability с отдельными thinking controls.

Практический вывод: хороший prompting для reasoning-моделей похож не на «секретный набор слов», а на нормально спроектированную постановку задачи.

2. Анти-паттерны, которые чаще всего вредят

Не навязывайте модели чужой chain-of-thought

OpenAI прямо предупреждает, что prompts вроде think step by step или explain your reasoning reasoning-моделям обычно не нужны. Модель уже тратит внутренний reasoning budget и умеет сама выбирать порядок анализа.

Не микроменеджьте порядок анализа

Фразы вида шаг 1: прочитай код, шаг 2: найди баги, шаг 3: распредели по severity часто делают модель менее гибкой. Если вы уже знаете структуру финального результата, задайте output schema, а не внутренний workflow.

Не перегружайте prompt примерами до zero-shot

OpenAI рекомендует начинать с zero-shot и добавлять few-shot только если это реально нужно. Для reasoning-моделей примеры часто менее критичны, чем для обычных LLM, если задача уже чётко сформулирована.

Few-shot всё ещё полезен, когда вам нужны:

• жёсткий стиль ответа;
• сложная policy-логика;
• стабильная классификация на повторяющихся edge cases;
• строгое структурированное преобразование входа в выход.

Не путайте «не задавать CoT» с «не задавать формат»

Это важная поправка к старым статьям. Ограничивать внутреннее мышление модели бессмысленно, но финальный формат ответа задавать нужно и полезно.

Плохо:

• «не думай вслух»;
• «думай медленно и глубоко»;
• «покажи все промежуточные мысли».

Хорошо:

• «верни JSON по схеме»;
• «дай 5 пунктов с severity и fix»;
• «если данных не хватает, явно перечисли missing assumptions».

3. Что действительно работает

Формулируйте end goal, а не внутренний процесс

Лучший practical pattern:

• что нужно решить;
• что считать хорошим ответом;
• какие ограничения обязательны;
• как должен выглядеть финальный output;
• что делать при нехватке данных.

Сравни две архитектуры очередей для платёжного сервиса. Критерии: durability, replay, backpressure, operational complexity. Ограничение: команда из 4 backend-инженеров, без отдельной SRE-функции. Верни recommendation, trade-offs, top 3 risks и migration path.

Структурируйте контекст

OpenAI рекомендует delimiters. Anthropic отдельно указывает XML structuring как часть prompt engineering best practices. На практике это значит: не кидайте в модель бессвязную стену текста.

Хороший паттерн:

## Context
...

## Constraints
...

## Data
...

## Desired output
...

или

<context>...</context>
<constraints>...</constraints>
<desired_output>...</desired_output>

Добавляйте few-shot только по делу

Для reasoning few-shot обычно нужен не чтобы «научить думать», а чтобы:

• закрепить желаемый output shape;
• выровнять терминологию;
• показать borderline cases;
• уменьшить variation у self-hosted/open-weight deployment.

Если zero-shot уже даёт хороший результат, дополнительные примеры могут только раздувать latency и стоимость.

Просите проверяемый deliverable

Reasoning-модели хорошо работают, когда их можно проверить.

Слабый prompt:

«Посмотри на это и скажи, что думаешь».

Сильный prompt:

«Найди 5 самых вероятных причин. Для каждой дай evidence, confidence и следующий диагностический шаг».

4. Как разводить prompting по провайдерам

Хотя общий принцип похож, engineering knobs разные.

5. Самая частая ошибка в продакшене

Главная проблема не в wording, а в routing. Многие команды включают reasoning-модель как default для всего трафика и потом получают:

• лишнюю latency;
• перерасход токенов;
• плохую unit economics;
• отсутствие ясности, где reasoning реально улучшил качество.

Поэтому practical baseline такой:

1. Простые FAQ, extraction, translation, basic summarization держите на обычных моделях.
2. Reasoning-модели включайте на code review, debugging, planning, policy-heavy analysis и multi-step decisions.
3. Логируйте reasoning usage и сравнивайте с non-reasoning baseline.

Production-паттерны

OpenAI: Responses API + reasoning.effort

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.4",
    reasoning={"effort": "medium", "summary": "auto"},
    input=[
        {
            "role": "developer",
            "content": (
                "Ты senior code reviewer. Верни markdown-таблицу с колонками "
                "issue, severity, evidence, fix. Если данных недостаточно, "
                "отдельно перечисли missing assumptions."
            ),
        },
        {
            "role": "user",
            "content": "Проведи review этого diff и найди security и performance regressions: ...",
        },
    ],
)

print(response.output_text)

Anthropic: thinking budget вместо CoT-инструкций

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="YOUR_CURRENT_CLAUDE_MODEL_ID",
    max_tokens=4096,
    thinking={"type": "enabled", "budget_tokens": 2048},
    messages=[
        {
            "role": "user",
            "content": (
                "Сравни две стратегии миграции базы данных. "
                "Верни recommendation, trade-offs, rollback risks и rollout plan."
            ),
        }
    ],
)

print(response)

Gemini 2.5: thinkingBudget

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=(
        "Разбери лог инцидента и выдели наиболее вероятную root cause, "
        "evidence, confidence и следующие проверки."
    ),
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(thinking_budget=2048)
    ),
)

print(response.text)

Простой router

def use_reasoning(task_type: str) -> bool:
    return task_type in {
        "code_review",
        "debugging",
        "architecture_decision",
        "policy_analysis",
        "root_cause_analysis",
    }

Практический шаблон

Контекст:
- сервис обрабатывает загрузку файлов
- стек: Django + S3 + Postgres
- после релиза выросли ошибки 5xx

Задача:
Найди наиболее вероятные причины.

Критерии качества:
- опирайся только на предоставленные данные
- не выдумывай отсутствующие факты
- при нехватке данных явно укажи missing assumptions

Формат ответа:
1. Top causes
2. Evidence
3. Confidence
4. Next checks

Проверьте себя