COMRAD404 / HOWTO

Как заставить модель «думать вслух»: техники рассуждений

Как заставить модель «думать вслух» на практике: не вытаскивать скрытый chain-of-thought, а управлять reasoning через промпт, thinking-параметры, примеры и проверку по тестам.

Понадобится

20–30 минут
  • Доступ к API OpenAI, Claude или Gemini
  • 3–5 тестовых задач, на которых можно сравнить качество ответа
  • Понимание желаемого формата финального ответа
  • Готовность проверить актуальные pricing и model pages перед запуском

После выполнения этой инструкции вы сможете повысить качество рассуждений модели без попыток вытащить скрытый внутренний chain-of-thought: через структуру промпта, few-shot-примеры, параметры reasoning/thinking и проверку по тестам.

Главный вывод сразу: в актуальных API OpenAI, Claude и Gemini обычно нельзя рассчитывать на буквальный вывод сырого внутреннего рассуждения. Практически рабочий путь другой: дать модели больше пространства на reasoning, потребовать проверяемый формат ответа и оценивать результат по качеству решения, метаданным и поведению в многоходовом сценарии.

  • ⏱️ Время: 20–30 минут
  • 🎯 Сложность: средний
  • 💰 Стоимость: зависит от модели, токенов и режима thinking/reasoning; перед запуском проверьте официальные страницы pricing для выбранной модели
  • 🛠️ Что потребуется: доступ к API OpenAI, Claude или Gemini; 3–5 тестовых задач; возможность сравнить несколько прогонов
  • 📌 Актуальность: официальные рекомендации OpenAI, Anthropic Claude и Gemini API по состоянию на 2026-08-14; точная поддержка параметров зависит от семейства модели и API

Редакционное ограничение: эта инструкция не обещает «вытащить мысли модели дословно». По проверенным документам современные API обычно скрывают raw chain-of-thought verbatim и дают управлять глубиной или формой reasoning через параметры, шаблоны ответа, примеры и контекст.

Что на практике означает «думать вслух»

Если вы работаете с большой языковой моделью (LLM) или другой генеративной моделью, полезно разделять две цели. Первая — заставить модель выполнить более глубокую внутреннюю работу до ответа. Вторая — получить от неё удобное для проверки пользовательское объяснение: краткое резюме рассуждения, допущения, шаги проверки, список пробелов в данных.

Для практики почти всегда важнее второе. Длинный «поток мыслей» сам по себе не гарантирует качество. Официальные рекомендации в источниках сходятся на другом: задайте критерии успеха, структурируйте запрос, покажите желаемый формат, включите подходящий режим thinking/reasoning и проверяйте не многословность, а результат.

Провайдер Чем управлять Что важно помнить
OpenAI reasoning.effort, reasoning.context, previous_response_id, при необходимости reasoning.mode="pro" Responses API рекомендован для reasoning, tool-calling и multi-turn workflows; pro делает больше работы модели и увеличивает задержку
Claude thinking, interleaved thinking, adaptive thinking, few-shot-паттерны Для сложных задач часто лучше общая инструкция вроде think thoroughly, чем жёсткий пошаговый план; manual extended thinking с thinking.type="enabled" и budget_tokens deprecated на Claude 4.6 и даёт 400 на 4.7+
Gemini current: thinking_level; legacy Gemini 2.5: thinkingBudget Модели динамически думают по умолчанию; проверка возможна через thought signatures и метрики usage.total_thought_tokens/total_output_tokens

Пошаговая инструкция

  1. Шаг 1. Зафиксируйте критерии успеха до переписывания промпта.

    Начните не с «магической формулировки», а с 3–5 тестовых задач и понятной шкалы оценки. Anthropic прямо рекомендует сначала определить чёткие критерии успеха и эмпирические тесты, а уже потом составлять промпт.

    Минимальный набор для проверки: правильность ответа, полнота, число пропущенных допущений, устойчивость к неоднозначному контексту и удобство финального формата для человека.

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

  2. Шаг 2. Перенесите инструкцию в начало и разделите её от контекста.

    В руководстве OpenAI по prompt engineering рекомендовано ставить инструкции в начало, отделять инструкцию от данных разделителями, быть конкретным по контексту, ожидаемому результату и формату. Если есть выбор, начните с самой новой доступной модели в семействе.

    Используйте заготовку такого типа:

    Инструкция:
    Решите задачу аккуратно. Если данных недостаточно, не придумывайте факты.
    
    Критерии успеха:
    1) ответ должен быть проверяемым;
    2) допущения перечислены явно;
    3) неопределённость отмечена отдельно.
    
    Контекст:
    ---
    [ваши данные]
    ---
    
    Формат ответа:
    1) краткий вывод;
    2) ключевые допущения;
    3) что проверить вручную.

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

  3. Шаг 3. Покажите желаемый паттерн reasoning на примере, а не требуйте «все мысли целиком».

    OpenAI советует показывать желаемый формат на примерах. В best practices Claude отдельно отмечено, что few-shot-примеры могут показывать паттерн рассуждения с тегами <thinking>. Это полезно, если вам нужен пользовательский reasoning-блок, который вы потом читаете или парсите.

    Безопасный практический шаблон такой: вы просите не скрытый внутренний chain-of-thought, а короткое объяснение в заданной форме.

    Пример
    Вопрос: Какой вариант выбрать и почему?
    <thinking>
    Сначала проверю критерии успеха, затем сравню варианты по ограничениям.
    </thinking>
    Ответ:
    - Выбор: ...
    - Почему: ...
    - Что проверить: ...

    Для Claude в сложных задачах часто лучше дать общую установку вроде think thoroughly, чем принуждать модель к слишком жёсткому пошаговому скрипту.

    Ожидаемый результат: модель чаще возвращает не «болтовню», а объяснение в нужной вам структуре.

  4. Шаг 4. В OpenAI поднимайте глубину reasoning через параметры, а не через просьбу «думай больше».

    В актуальных рекомендациях OpenAI для reasoning-моделей указано использовать Responses API для reasoning, tool-calling и multi-turn workflows. Ключевой рычаг — reasoning.effort со значениями none, low, medium, high, xhigh, max.

    Если у вас диалог из нескольких ходов, при необходимости сохраняйте состояние через reasoning.context со значениями auto, all_turns, current_turn и через previous_response_id. Если важнее качество, чем задержка, можно проверить reasoning.mode="pro", но OpenAI отдельно предупреждает, что этот режим делает больше работы модели и увеличивает latency.

    {
      "reasoning": {
        "effort": "high",
        "context": "all_turns",
        "mode": "pro"
      },
      "previous_response_id": "..."
    }

    Начинайте с medium или high и повышайте только если это видно на тестах.

    Ожидаемый результат: на сложных задачах модель чаще замечает ограничения, но ответ может стать медленнее и дороже.

  5. Шаг 5. В Claude опирайтесь на adaptive thinking и interleaved thinking, а deprecated-режимы не используйте.

    Anthropic рекомендует thinking и interleaved thinking, а для сложных задач — adaptive thinking. В тех же рекомендациях сказано, что во многих случаях общая инструкция вроде think thoroughly лучше, чем жёсткий пошаговый план.

    Практический шаблон для Claude:

    Сначала оцени, что нужно для успешного решения.
    Если данных не хватает, перечисли пробелы.
    Для сложных мест подумай тщательнее.
    Верни:
    1) ответ,
    2) краткое объяснение,
    3) что нужно проверить вручную.

    Не опирайтесь на manual extended thinking в старом стиле. По текущей документации Anthropic режим с thinking.type:"enabled" и budget_tokens deprecated на Claude 4.6 и возвращает 400 на Claude 4.7+.

    Если у вас диалог в несколько ходов, учитывайте, что thinking blocks могут сохраняться между ходами: на новых моделях сохраняются все предыдущие turns, на старых — только последний turn.

    Ожидаемый результат: сложные задачи становятся устойчивее, особенно когда reasoning нужно чередовать с обращениями к инструментам.

  6. Шаг 6. В Gemini различайте current thinking и legacy thinking для 2.5 series.

    В текущих thinking docs Gemini указано, что модели динамически думают по умолчанию. Для current API доступны thinking_level, thought signatures как зашифрованные представления внутреннего рассуждения, а также метрики usage.total_thought_tokens и usage.total_output_tokens для проверки и сохранения контекста рассуждений.

    Но в legacy Generate Content API для Gemini 2.5 series параметр thinkingLevel не поддерживается. Там используется thinkingBudget, где 0 отключает thinking, а -1 включает dynamic thinking.

    {
      "thinkingBudget": 0
    }
    {
      "thinkingBudget": -1
    }

    Точное множество допустимых значений для current thinking_level смотрите на странице выбранной модели: в исходном пакете нет универсального списка для всех семейств, поэтому его нельзя безопасно обобщать.

    Ожидаемый результат: вы не путаете current и legacy-настройки и можете проверить, что thinking действительно участвовал в ответе.

  7. Шаг 7. Сравните варианты по качеству решения, а не по длине объяснения.

    Запустите один и тот же набор тестов в трёх режимах: базовый промпт, улучшенный промпт без thinking-параметров, улучшенный промпт с thinking/reasoning. Смотрите не на «красивость» текста, а на долю правильных решений, полноту допущений и способность удерживать контекст между ходами.

    Для OpenAI полезно смотреть, даёт ли рост reasoning.effort заметный прирост качества по сравнению с задержкой. Для Gemini проверьте usage.total_thought_tokens. Для Claude в многоходовом сценарии проверьте, что нужный thinking-контекст действительно сохраняется между turns в соответствии с семейством модели.

    Ожидаемый результат: у вас остаётся один рабочий шаблон промпта и один режим reasoning, которые оправданы тестами, а не ощущениями.

Как проверить, что всё работает

  • Прогоните минимум 3 одинаковые задачи в базовом и улучшенном вариантах. Улучшение должно быть видно по правильности, полноте и устойчивости, а не только по объёму текста.
  • В OpenAI сравните поведение при reasoning.effort=medium и high. Если качество не растёт, не поднимайте effort дальше.
  • В OpenAI для многоходового сценария убедитесь, что при передаче previous_response_id и нужного reasoning.context модель удерживает важные ограничения из предыдущего хода.
  • В Claude проверьте, что сложные задачи выигрывают от общей установки think thoroughly или adaptive thinking, а не от избыточно жёсткого скрипта.
  • В Gemini проверьте служебные метрики: usage.total_thought_tokens и usage.total_output_tokens. Если вы сохраняете thought signatures, убедитесь, что они передаются последовательно в вашем сценарии.

Частые ошибки и исправления

  • ❌ Ошибка: вы пытаетесь заставить API показать сырой внутренний chain-of-thought verbatim. ✅ Решение: переключитесь на управляемый пользовательский формат ответа: краткий вывод, допущения, проверка, пробелы в данных.
  • ❌ Ошибка: вы оцениваете успех по длине «рассуждения». ✅ Решение: сравнивайте точность, полноту и воспроизводимость на фиксированном тестовом наборе.
  • ❌ Ошибка: в Claude вы задаёте слишком жёсткий пошаговый план там, где лучше работает общая инструкция think thoroughly. ✅ Решение: протестируйте оба варианта и оставьте тот, что реально улучшает качество.
  • ❌ Ошибка: вы используете manual extended thinking в стиле thinking.type="enabled" и budget_tokens на новых Claude. ✅ Решение: учитывайте, что этот режим deprecated на Claude 4.6 и даёт 400 на 4.7+; предпочитайте adaptive thinking, если он доступен.
  • ❌ Ошибка: вы смешиваете current Gemini thinking_level и legacy Gemini 2.5 thinkingBudget. ✅ Решение: сначала проверьте, какой именно API и модель вы используете, и только затем выставляйте параметр.
  • ❌ Ошибка: в OpenAI вы ждёте, что многоходовое reasoning само сохранится между запросами. ✅ Решение: явно управляйте контекстом через reasoning.context и previous_response_id.

Безопасность и ограничения

  • Не стройте процесс на предположении, что провайдер обязан раскрывать скрытый внутренний ход рассуждений. По проверенным источникам современный стандарт — управление reasoning, а не обязательный вывод raw chain-of-thought.
  • Больше reasoning обычно означает больше задержки и затрат. Для OpenAI это особенно важно: документация по o1 прямо говорит о token-based billing; cached input дешевле, а tool-specific модели могут иметь отдельную оплату за вызов инструмента.
  • Поддержка thinking/reasoning зависит от семейства модели, аккаунта, плана, версии API и иногда от конкретного SDK. В просмотренных документах нет полной матрицы по регионам и аккаунтам.
  • Для Gemini есть явное расхождение между current и legacy API. Для Claude — между новыми подходами adaptive thinking и устаревшим manual extended thinking. Для OpenAI — между разными семействами моделей и их поведением в Responses API.
  • Практический вердикт: если вам нужна проверяемость, просите не «мысли целиком», а краткое объяснение, допущения и шаги проверки. Это стабильнее переносится между провайдерами.

Что делать дальше

Источники

Вопросы и ответы

Можно ли заставить модель показать весь внутренний chain-of-thought?

Обычно нет. По актуальным источникам провайдеры чаще дают управлять глубиной reasoning и формой итогового объяснения, а не раскрывают сырое внутреннее рассуждение verbatim.

Что лучше: жёсткий пошаговый промпт или общая инструкция?

Это надо проверять на тестах. Для Claude в best practices прямо сказано, что во многих случаях общая инструкция вроде think thoroughly лучше, чем слишком жёсткий пошаговый план.

Как понять, что thinking действительно сработал?

Смотрите на качество решения и служебные признаки. В Gemini для этого полезны usage.total_thought_tokens, total_output_tokens и thought signatures. В OpenAI и Claude важнее прирост качества на тестах и корректное удержание контекста между turns.

Почему ответы стали медленнее и дороже?

Потому что reasoning/thinking добавляет работу модели. В OpenAI режим reasoning.mode="pro" прямо описан как более трудоёмкий и более медленный. Для o1 также действует token-based billing; cached input дешевле, а tool-specific вызовы могут тарифицироваться отдельно.

Одинаково ли это работает в OpenAI, Claude и Gemini?

Нет. Параметры, режимы и даже поддерживаемые API отличаются по семейству модели и версии. Самые частые расхождения: OpenAI Responses API и его reasoning-контекст, adaptive thinking в Claude и разделение current/legacy thinking в Gemini.

Шаги

HOW-TO
  1. Зафиксируйте критерии успеха и тестовые задачи

    | Соберите 3–5 типовых задач и решите, как будете измерять улучшение: правильность, полнота, устойчивость, удобство формата.

  2. Поставьте инструкцию в начало и отделите её от контекста

    | Следуйте рекомендациям OpenAI: инструкция сначала, затем разделители, затем конкретный контекст, критерии и формат ответа.

  3. Покажите желаемый шаблон reasoning на примере

    | Используйте few-shot-пример с кратким объяснением, допущениями и шагами проверки вместо требования вывести весь скрытый chain-of-thought.

  4. Для OpenAI настройте reasoning-параметры

    | В Responses API проверьте reasoning.effort, reasoning.context, previous_response_id и при необходимости reasoning.mode="pro".

  5. Для Claude используйте adaptive thinking и избегайте deprecated-режимов

    | Начните с общей инструкции вроде think thoroughly, проверьте interleaved thinking и не используйте manual extended thinking на неподходящих версиях.

  6. Для Gemini различайте current и legacy thinking

    | В current API ориентируйтесь на thinking_level и служебные thought-метаданные, а в legacy Gemini 2.5 используйте thinkingBudget.

  7. Проведите A/B-проверку и оставьте только то, что улучшает результат

    | Сравните базовый промпт, улучшенный промпт и режим с thinking/reasoning по качеству решения, а не по длине объяснения.

Источники

SOURCES

Вопросы и ответы

FAQ
Можно ли заставить модель показать весь внутренний chain-of-thought?

Обычно нет. По актуальным источникам провайдеры чаще дают управлять глубиной reasoning и формой итогового объяснения, а не раскрывают сырое внутреннее рассуждение verbatim.

Что лучше: жёсткий пошаговый промпт или общая инструкция?

Это надо проверять на тестах. Для Claude в best practices прямо сказано, что во многих случаях общая инструкция вроде think thoroughly лучше, чем слишком жёсткий пошаговый план.

Как понять, что thinking действительно сработал?

Смотрите на качество решения и служебные признаки. В Gemini для этого полезны usage.total_thought_tokens, total_output_tokens и thought signatures. В OpenAI и Claude важнее прирост качества на тестах и корректное удержание контекста между turns.

Почему ответы стали медленнее и дороже?

Потому что reasoning/thinking добавляет работу модели. В OpenAI режим reasoning.mode="pro" прямо описан как более трудоёмкий и более медленный. Для o1 также действует token-based billing; cached input дешевле, а tool-specific вызовы могут тарифицироваться отдельно.

Одинаково ли это работает в OpenAI, Claude и Gemini?

Нет. Параметры, режимы и даже поддерживаемые API отличаются по семейству модели и версии. Самые частые расхождения: OpenAI Responses API и его reasoning-контекст, adaptive thinking в Claude и разделение current/legacy thinking в Gemini.

Читайте также

LINKS