Reasoning Effort

«Усилие» рассуждения — управляемая глубина мышления модели. Ключевой вопрос не «умнее = лучше», а «какое усилие нужно для этой задачи?». Регулируется параметром effort/thinking budget и числом шагов.

Суть

Четыре режима по глубине и цене:

  • Reflexive (~$0.003) — прямой ответ без рассуждения («Как вас зовут?»).
  • Standard (~$0.01) — промпт + 1 вызов.
  • Deliberate (~$0.05) — Chain-of-Thought до 5 шагов (анализ, сравнение).
  • Exhaustive (~$0.50+) — много итераций, reflection, self-correction (код, сложный reasoning).

Зачем это нужно

«Мышление — это ресурс, им нужно управлять явно, а не по умолчанию». Высокое усилие оправдано только в ~20% задач; на остальном глубокий reasoning жжёт бюджет и latency без пользы.

Как работает (три рычага усилия)

  1. Модель — младший тир против верхнего; разница цены на порядок и более (это Model Selection + Agent Routing). На линейке Claude по состоянию на 2026-08 это $1 / $5 у Haiku 4.5 против $10 / $50 у Fable 5, то есть ×10 по обеим сторонам.
  2. Глубина reasoning — параметр усилия у провайдера. У OpenAI это reasoning.effort: low/medium/high. У Claude механизм сменился, и старый способ теперь ломает запрос: см. врезку ниже.
  3. Число шагов — max_iterations в петле + early stopping при достижении цели (защита от quadratic cost growth, см. Agent CostControl).

Новая ось — test-time compute: качество растёт не только от размера модели, но и от того, сколько модель «думает» на инференсе. Reasoning-модели тратят больше токенов на рассуждение перед ответом — это «усилие» уже на уровне самой модели (связано с Chain of Thought и Emergent Abilities).

У Claude задание бюджета мышления перестало работать — и не деградацией, а ошибкой

Ранний способ управлять глубиной у Claude — выдать модели бюджет токенов на размышление: thinking: {type: "enabled", budget_tokens: N}. На поколении Claude 4.6 он объявлен устаревшим, а на Fable 5, Opus 5, Sonnet 5, Opus 4.8 и Opus 4.7 budget_tokens отвергается с ошибкой 400. Это редкий и удобный случай: устаревание не тихое, запрос просто не проходит.

Пришедший на смену механизм — адаптивное мышление: thinking: {type: "adaptive"}, где глубину выбирает сама модель по задаче, а не вызывающий код по счётчику токенов. У Fable 5 оно включено всегда и выключить его нельзя. Явное enabled-мышление из текущей линейки осталось только у Haiku 4.5.

Отдельно от этого у Claude есть параметр effort. На Opus 5 и Sonnet 5 он по умолчанию high в Claude API и Claude Code, на Opus 4.8 — high на всех поверхностях. То есть дефолт здесь не «экономный», и правило «задавай усилие явно» из раздела ниже работает в обе стороны: без явного значения вы платите за высокое усилие на всём подряд.

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

Фреймворк роняет настройку молча, провайдер — с ошибкой

Выше описан случай, когда провайдер отвечает четырёхсотым: настройка не принята, и это видно сразу. Прослойка фреймворка ведёт себя иначе, и различие стоит держать в голове при отладке.

В Pydantic AI поддержка режима размышления объявляется профилем модели, и поведение прописано в исходниках прямым текстом: при supports_thinking = False единая настройка thinking из ModelSettings молча игнорируется, а при thinking_always_enabled = True молча игнорируется попытка выключить размышление через thinking=False — модель его отключать не умеет.

Практическое следствие: одна и та же ошибка в коде даёт два разных симптома в зависимости от того, идёт вызов напрямую или через фреймворк. Напрямую — исключение и остановка; через фреймворк — рабочий прогон с другим поведением модели и без единого признака в логе. Второе дороже: счёт и качество меняются, а причина не названа.

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

Отдельно про порядок применения настроек в Pydantic AI: значения складываются от модели к агенту и к запуску, побеждает уровень запуска. Значит настройка, выставленная при создании агента, тихо перекрывается той, что передана в run(), — если её там передали.

Дефолт усилия — переменная провайдера, а не константа

Если effort не задан явно, его значение выбирает провайдер, и оно может измениться без вашего участия. Реальный случай: вендор переключил дефолт с высокого на средний, и у всех, кто не прописывал параметр руками, глубина рассуждений просела примерно на 56%. Внешне ничего не сломалось — сервис отвечал, коды ответов те же, — просто ответы стали хуже.

Отсюда практический вывод: на продакшен-путях effort задают явно, даже когда текущий дефолт устраивает. Не ради значения, а ради того, чтобы оно перестало быть чужой переменной. Это тот же класс тихих деградаций, что и в Agent Failure Modes: качество упало, а мониторинг молчит, потому что смотрит на доступность.

Как классифицировать задачу и что ставить дефолтом

Классификация не требует отдельной модели — она читается по четырём режимам выше через один признак: сколько независимых шагов рассуждения нужно, чтобы ответ стал проверяемым. Ноль (ответ извлекается из запроса или контекста) — reflexive. Один — standard. Несколько сравнений или анализ вариантов — deliberate. Требуется самопроверка и переписывание — exhaustive. Отсюда же и пропорция: высокое усилие оправдано примерно в 20% задач, а не по умолчанию.

Дефолт для агентного пайплайна — низкое или среднее усилие, заданное явно, с точечным повышением на шагах, где по признаку выше нужна глубина. Именно явно: как разобрано выше, незаданный effort — чужая переменная, которую провайдер может сменить без предупреждения, и глубина рассуждений просядет молча. Повышать усилие на весь пайплайн вместо конкретного шага — самый дорогой из возможных вариантов и обычно ошибка проектирования, а не настройка.

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

Основная линия заметки описывает усилие как «рычаги» (модель / глубина / шаги). Здесь «мышление» объясняется через декомпозицию: «давайте есть слона по кусочкам» — LLM умеет решать атомарные задачи, и суть reasoning в том, чтобы оркестратор разрезал сложное на простое и склеил результат (близко к Plan and Execute).

Нюанс про self-reflection: в основной линии рефлексия/self-correction — признак «глубокого» режима (Exhaustive). Здесь добавлено предупреждение: самокоррекция может усугубить ошибку или вызвать «когнитивный диссонанс» (модель запутывается + расход ресурсов). Вывод: рефлексия — не бесплатное добро, применять осознанно (см. Chain of Thought).

Связано с

  • Agent CostControl — усилие напрямую = деньги
  • Agent Routing — дешёвый режим по умолчанию, эскалация по необходимости
  • Model Selection — выбор tier как один из рычагов
  • Chain of Thought — CoT как форма управляемого усилия